NullPointerException in MergingDatagraSocket
astillich-igniti opened this issue · 3 comments
Hi,
we are using Jitisi Meet Docker 5142-4. We have setup up an nginx proxy before the bridge and other components. Everything works with P2P communication. But if clients attempt to connect via the bridge, I'm running in the issue mentioned in #205:
java.lang.NullPointerException
at org.ice4j.socket.MergingDatagramSocket.initializeActive(MergingDatagramSocket.java:577)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.ComponentSocket.propertyChange(ComponentSocket.java:176)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.IceMediaStream.firePairPropertyChange(IceMediaStream.java:877)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.CandidatePair.nominate(CandidatePair.java:629)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.Agent.nominate(Agent.java:1788)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.DefaultNominator.strategyNominateFirstValid(DefaultNominator.java:144)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.DefaultNominator.propertyChange(DefaultNominator.java:120)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.IceMediaStream.firePairPropertyChange(IceMediaStream.java:877)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.CandidatePair.validate(CandidatePair.java:667)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.IceMediaStream.addToValidList(IceMediaStream.java:675)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.Agent.validatePair(Agent.java:1752)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.ConnectivityCheckClient.processSuccessResponse(ConnectivityCheckClient.java:641)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.ice.ConnectivityCheckClient.processResponse(ConnectivityCheckClient.java:405)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.stack.StunClientTransaction.handleResponse(StunClientTransaction.java:314)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.stack.StunStack.handleMessageEvent(StunStack.java:1040)
eva_jvb.1.vahxzrver0eg@node3 | at org.ice4j.stack.MessageProcessingTask.run(MessageProcessingTask.java:196)
eva_jvb.1.vahxzrver0eg@node3 | at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
eva_jvb.1.vahxzrver0eg@node3 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
eva_jvb.1.vahxzrver0eg@node3 | at java.lang.Thread.run(Thread.java:748)
The discussion mentions that setting org.ice4j.ice.harvest.BLOCKED_INTERFACES=bridge fixes the issue, but it does not help in our case.
We have set DOCKER_HOST_ADDRESS, and I tried enabling disabling STUN by commenting out the JVB_STUN_SERVERS line in the environment file. Nothing helped, I also tried setting org.ice4j.ice.harvest.ALLOWED_INTERFACES= to the interface I'm using which resulted in another exception:
eva_jvb.1.taenq2i2r7be@node3 | Jan 26, 2021 6:11:41 PM org.jitsi.utils.logging2.LoggerImpl log
eva_jvb.1.taenq2i2r7be@node3 | SEVERE: Health check failed in PT0S:
eva_jvb.1.taenq2i2r7be@node3 | java.lang.Exception: Failed to bind single-port
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.videobridge.health.JvbHealthChecker.check(JvbHealthChecker.kt:43)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.videobridge.health.JvbHealthChecker.access$check(JvbHealthChecker.kt:25)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.videobridge.health.JvbHealthChecker$healthChecker$1.invoke(JvbHealthChecker.kt:32)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.videobridge.health.JvbHealthChecker$healthChecker$1.invoke(JvbHealthChecker.kt:25)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.health.HealthChecker.run(HealthChecker.kt:144)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
eva_jvb.1.taenq2i2r7be@node3 | at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExec
Are there any outstanding fixes which have not made it into the 5142-4 release?
We have solved the issue. It was indeed a configuration problem on our side. In our opinion, ice4j should produce a meaningful error message instead of just running into a NPE.
We have solved the issue. It was indeed a configuration problem on our side. In our opinion, ice4j should produce a meaningful error message instead of just running into a NPE.
I agree. I can't promise to work on it anytime soon as there are other priorities, but for the record can you describe the configuration that triggered the exception?
@astillich-igniti I'd be very interested to learn what you changed as well because I can't for the life of me get it to work on my server.