Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NullPointerException in MergingDatagraSocket #222

Open
astillich-igniti opened this issue Jan 26, 2021 · 3 comments
Open

NullPointerException in MergingDatagraSocket #222

astillich-igniti opened this issue Jan 26, 2021 · 3 comments

Comments

@astillich-igniti
Copy link

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?

@astillich-igniti
Copy link
Author

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.

@bgrozev
Copy link
Member

bgrozev commented Jan 29, 2021

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?

@alucryd
Copy link

alucryd commented Mar 11, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants