Skip to content

[SignalR] Java Client NullPointerException #6898

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

Closed
JMaroz opened this issue Jan 21, 2019 · 11 comments
Closed

[SignalR] Java Client NullPointerException #6898

JMaroz opened this issue Jan 21, 2019 · 11 comments
Assignees
Labels
area-signalr Includes: SignalR clients and servers Done This issue has been fixed

Comments

@JMaroz
Copy link

JMaroz commented Jan 21, 2019

Describe the bug

When start the connection the SignalR HubConnection class throw an Exception

Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.microsoft.signalr.HubConnection$ConnectionState.cancelOutstandingInvocations(java.lang.Exception)' on a null object reference at com.microsoft.signalr.HubConnection.stopConnection(HubConnection.java:6) at com.microsoft.signalr.HubConnection.lambda$start$6(HubConnection.java:1) at com.microsoft.signalr.s.invoke(Unknown Source:2) at com.microsoft.signalr.WebSocketTransport.onClose(WebSocketTransport.java:4) at com.microsoft.signalr.WebSocketTransport.lambda$start$1(WebSocketTransport.java:3) at com.microsoft.signalr.A.invoke(Unknown Source:2) at com.microsoft.signalr.OkHttpWebSocketWrapper$SignalRWebSocketListener.onFailure(OkHttpWebSocketWrapper.java:3) at okhttp3.internal.ws.RealWebSocket.failWebSocket(RealWebSocket.java:84) at okhttp3.internal.ws.RealWebSocket$2.onFailure(RealWebSocket.java:1) at okhttp3.RealCall$AsyncCall.execute(RealCall.java:8) at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) at java.lang.Thread.run(Thread.java:764)

To Reproduce

Unable to reproduce the behavior, the crash happen randomly

Expected behavior

SignalR must catch the exception or not throw the exception

@jkotalik
Copy link
Contributor

@mikaelm12 @BrennanConroy

@jkotalik jkotalik added the area-signalr Includes: SignalR clients and servers label Jan 22, 2019
@mikaelm12 mikaelm12 self-assigned this Jan 22, 2019
@mikaelm12
Copy link
Contributor

I'll investigate. Thanks!

@bradygaster
Copy link
Member

@JMaroz are you connecting to a traditional server-side Hub or are you connecting through the SignalR Service? Just curious.

@mikaelm12
Copy link
Contributor

So I believe that I was running into this bug during my work on the LongPolling transport and I fixed it in that pr which is still under review #6856. The issue I believe was
the connection state wasn't being set until we received the Handshake response so if the connection is stopped before it has been fully set up you could null ref in stop. This should be fixed in the LongPolling pr. https://github.com/aspnet/AspNetCore/blob/a6f4a27abb2db0dcd65d1595c43bcde048b85228/src/SignalR/clients/java/signalr/src/main/java/com/microsoft/signalr/HubConnection.java#L326

@imperugo
Copy link

imperugo commented Jan 23, 2019

@bradygaster let me share some information about server side. The problem explained by @JMaroz happens with this configuration:

  • ASP.NET Core 2.2.0
  • SignalR 1.1.0
  • Hosting on Docker over ECS on AWS Cloud Platform (no reverse proxy, just kestrel behind the balancer)

The client connects to simple Hub service that looks like this (more or less)

public class MySuperHub : HubBase
{
   public async Task DoSomethingSpecial(string param1, Guid param2, dynamic param3 = null)
   {
      // await ....
   }
}

Let me add another error we get server side in another mobile application (maybe could be helpful).

Error message: Failed connection handshake.

HttpHeaders: [Connection, upgrade], [Upgrade, websocket], [Accept-Encoding, gzip], [Host, mydomain.mycompany.com], [User-Agent, okhttp/3.10.0], [Origin, https://mydomain.mycompany.com/], [X-Original-Proto, https], [X-Forwarded-Port, 443], [X-Amzn-Trace-Id, Root=1-5c47e65a-d7286a28e44316b8c5463ea0], [Sec-WebSocket-Key, G9xa4kZDUhAyfAgF8iypFg==], [Sec-WebSocket-Version, 13], [X-Original-For, 10.202.3.196:51446]

SourceContext: Microsoft.AspNetCore.SignalR.HubConnectionContext

Didn't understand exactly when it happens because I don't have any stack (it happens not in my code but is logged as error).

Let me know if you need more info.
Thanks

@bradygaster
Copy link
Member

@mikaelm12 and @muratg would this be ready (or is it already in) for 2.2.3?

@bradygaster bradygaster added this to the 3.0.0 milestone Jan 24, 2019
@muratg
Copy link
Contributor

muratg commented Jan 24, 2019

@bradygaster To get this in 2.2.3, we'll need a PR with the fix with the label servicing-consider. It'll show up in the next shiproom then.

@mikaelm12
Copy link
Contributor

I don't think that that would be critical to get into 2.2.3. It's an error that happens in a failure in the close logic of the Java client. Happy to discuss it more though if people have other opinions.

@JMaroz
Copy link
Author

JMaroz commented Jan 28, 2019

@mikaelm12 is there a release date w/ the fix for the java client?

@mikaelm12
Copy link
Contributor

The fix for the null ref will be coming in Preview3, but that is not why your HubConnection fails to start. The exception you posted is the result of you HubConnection failing to start, not the cause of it I believe. Do you have any more logs or a repro app we can look at?

@bradygaster bradygaster modified the milestones: 3.0.0, 3.0.0-preview3 Feb 6, 2019
@mikaelm12
Copy link
Contributor

The failure in the close logic was fixed here 3d3ad96

@mikaelm12 mikaelm12 added Done This issue has been fixed and removed Working labels Jul 9, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Dec 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-signalr Includes: SignalR clients and servers Done This issue has been fixed
Projects
None yet
Development

No branches or pull requests

7 participants