ConnectionState.getNextInvocationId() Null pointer exception

[mashahbazi]

I was created an issue for this bug #11995
So you added a milestone for it preview 8 and close issue. Now after preview 8 release I update my signalR core for java clients to that version the error is still accrue. Because it's a fatal exception my crush. So can you help me with this problem??

[BrennanConroy]

Can you share the stack trace of the null ref and the version of the java client you're using?

[mashahbazi]

I start signalR and invoke on start complete.
I check connection state before invoke and it's connected

com.microsoft.signalr.HubConnection.invoke + 667 (HubConnection.java:667)
MY CODE FOR INVOKE
io.reactivex.subjects.CompletableSubject.onComplete + 139 (CompletableSubject.java:139)
io.reactivex.internal.operators.single.SingleFlatMapCompletable$FlatMapCompletableObserver.onComplete + 102 (SingleFlatMapCompletable.java:102)
io.reactivex.internal.operators.completable.CompletableConcatArray$ConcatInnerObserver.next + 85 (CompletableConcatArray.java:85)
io.reactivex.internal.operators.completable.CompletableConcatArray$ConcatInnerObserver.onComplete + 65 (CompletableConcatArray.java:65)
io.reactivex.internal.operators.completable.CompletableConcatArray$ConcatInnerObserver.next + 85 (CompletableConcatArray.java:85)
io.reactivex.internal.operators.completable.CompletableConcatArray$ConcatInnerObserver.onComplete + 65 (CompletableConcatArray.java:65)
io.reactivex.internal.operators.completable.CompletableConcatArray$ConcatInnerObserver.next + 85 (CompletableConcatArray.java:85)
io.reactivex.internal.operators.completable.CompletableConcatArray$ConcatInnerObserver.onComplete + 65 (CompletableConcatArray.java:65)
io.reactivex.subjects.CompletableSubject.onComplete + 139 (CompletableSubject.java:139)
com.microsoft.signalr.HubConnection.stopConnection + 520 (HubConnection.java:520)
com.microsoft.signalr.HubConnection.lambda$start$6 + 365 (HubConnection.java:365)
com.microsoft.signalr.-$$Lambda$HubConnection$plWe2n559m5117SGBt0gopoPs3g.invoke + 2 (-.java:2)
com.microsoft.signalr.WebSocketTransport.onClose + 91 (WebSocketTransport.java:91)
com.microsoft.signalr.WebSocketTransport.lambda$start$1 + 54 (WebSocketTransport.java:54)
com.microsoft.signalr.-$$Lambda$WebSocketTransport$vlt_DXG3u2t5OJvAYlxBdjX-Br4.invoke + 2 (-.java:2)
com.microsoft.signalr.OkHttpWebSocketWrapper$SignalRWebSocketListener.onFailure + 98 (OkHttpWebSocketWrapper.java:98)
okhttp3.internal.ws.RealWebSocket.failWebSocket + 571 (RealWebSocket.java:571)
okhttp3.internal.ws.RealWebSocket$2.onResponse + 216 (RealWebSocket.java:216)
okhttp3.RealCall$AsyncCall.execute + 206 (RealCall.java:206)
okhttp3.internal.NamedRunnable.run + 32 (NamedRunnable.java:32)
java.util.concurrent.ThreadPoolExecutor.runWorker + 1162 (ThreadPoolExecutor.java:1162)
java.lang.Thread.run + 764 (Thread.java:764)

[BrennanConroy]

Where is the null ref in that stack trace?
Also, your connection is closing, is that expected/part of the scenario that causes the null ref?

Are you able to provide the code you're running that reproduces the problem?

[mashahbazi]

I commented for you fabric error stack trace.
this is where the error happen.
com.microsoft.signalr.HubConnection.invoke + 667 (HubConnection.java:667)
No I can't provide all of my code but I can say how it happen.
I write how I implement signalR for an stable connection of signalR in #13409

[BrennanConroy]

I'm still not really sure how you're getting a null ref now. However, we do have plans to clean up a lot of the connection state logic to make issues like this less likely #12138

If you can provide any more details about how you're hitting the null ref, like code examples etc. then we can try to fix it faster, or provide workarounds until a fix is made.

[analogrelay]

@mashahbazi can you also share the exact version of the Java client you are using so we can correlate the line number in the stack trace properly?

As @BrennanConroy said, it looks like the connection is closing and you're running invoke during the close event. There may be a race here causing a null-ref but even if that was fixed, you'd still probably get a RuntimeException because you're trying to invoke a method when the connection is closed.

If you can provide a code sample that illustrates how you're calling invoke that would help, even if you can't share the full code itself. It would help if you can walk us through what triggers the code that calls invoke (is it responding to a connection event of some kind, or a UI action, etc.).

[mashahbazi]

@anurse
I use signalR client in android so java version is 1.8

if (hubConnection.getConnectionState() == HubConnectionState.CONNECTED)
            hubConnection.invoke(String.class, SignalRConstants.CONNECT, connectParams)
                    .subscribe(new SingleObserver<String>() {
                        public void onSubscribe(Disposable d) {
                        }
                        public void onSuccess(String result) {
                            if (!TextUtils.isEmpty(result)) {
                                connectionId = result;
                            } else {
                                RxEventHandler.getInstance().sendEvent(new Event(MainActivity.pageName, Event.LoggingOUT, null));
                            }
                        }
                        public void onError(Throwable e) {
                            Log.e(TAG, "onError: startUp ", e);
                        }
                    });

this I my code of invoke and where I get the null pointer exception.
As you see I check connection state. It can also happen for multi threading. Maybe it close exactly after I check state and before invoke.
I will try write another code using signalR to show how I use it then can share for you

[analogrelay]

What calls this code though? The call stack is showing that you're inside the close event of the HubConnection, so I'm trying to trace that back.

As you see I check connection state. It can also happen for multi threading. Maybe it close exactly after I check state and before invoke.

Yes, this is certainly possible. We should be throwing a RuntimeException in that case (so you can catch it and identify the reason). Right now we are throwing a NullPointerException, which is wrong, but an exception should be thrown when you try to invoke on a closed connection. Your code should be prepared for an error in that case.

I use signalR client in android so java version is 1.8

I'm actually asking for the version of the SignalR client, i.e. the version of the com.microsoft.signalr:signalr Maven package you are using. I'm looking for the exact version number, including the build number. For example: 3.0.0-previewX.NNNNN.N

[mashahbazi]

What calls this code though? The call stack is showing that you're inside the close event of the HubConnection, so I'm trying to trace that back.

After I receive close event from my connection, I stop my connection so I create a new connection and call start on it. after my connection start I check signalR connection then I invoke server with code that send in previous comment.

Yes, this is certainly possible. We should be throwing a RuntimeException in that case (so you can catch it and identify the reason). Right now we are throwing a NullPointerException, which is wrong, but an exception should be thrown when you try to invoke on a closed connection. Your code should be prepared for an error in that case.

yes, Any exception that make sense and not just a NullPointerException.

I'm actually asking for the version of the SignalR client, i.e. the version of the com.microsoft.signalr:signalr Maven package you are using. I'm looking for the exact version number, including the build number. For example: 3.0.0-previewX.NNNNN.N

I use preview preview8.19405.7

[analogrelay]

Can you show the actual Java code that does this? Looking at the call stack you posted above (which has stopConnection on it), and the fact that the async model is callback-based, it seems like you might not be properly waiting for the start operation to complete, which is why you're getting this error.

[analogrelay]

Closing this as we haven't heard from you and generally close issues with no response after some time. Please feel free to comment if you're able to get the information we're looking for and we can reopen the issue to investigate further!