-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Acquire HubConnectionStateLock before Send/Invoke/Stream #12078
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
Conversation
src/SignalR/clients/java/signalr/src/main/java/com/microsoft/signalr/HubConnection.java
Outdated
Show resolved
Hide resolved
src/SignalR/clients/java/signalr/src/main/java/com/microsoft/signalr/HubConnection.java
Show resolved
Hide resolved
This comment was made automatically. If there is a problem contact [email protected]. I've triaged the above build. I've created/commented on the following issue(s) |
src/SignalR/clients/java/signalr/src/main/java/com/microsoft/signalr/HubConnection.java
Outdated
Show resolved
Hide resolved
I don't know if we want to do this as part of this PR, but we should really think about how we're using the hubConnectionStateLock in all the other HubConnection methods. For example, it's important that HubConnection.start() acquires the lock at the beginning of the method when it checks whether it's in the DISCONNECTED state so that it cannot race with stop(). It's also incorrect for HubConnection.start() to later transition to the CONNECTED state after the handshake completes without at least verifying that you're still connecting and HubConnection.stop() hasn't been called. This probably requires a CONNECTING state. The CONNECTING state would also help you know not to restart the transport. Right now, the second call to HubConnection.start() could actually start the transport again in parallel. HubConnection.stop() should probably move the connection into a DISCONNECTING state. I get that it's too early to move to the DISCONNECTED state since HubConnection.stopConnection() hasn't been triggered by the transport yet, but we probably want to change states to ensure that when there's two consecutive calls to HubConnection.stop(), the second call no-ops. Even simple calls like setBaseUrl() should lock since it checks that the state is disconnected. We wouldn't want allow the HubConnection to start before setBaseUrl() actually sets the baseUrl. I'm fine with us creating separate issues for these. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far. Make sure we file the follow up issue to look at locking in the other methods.
This comment was made automatically. If there is a problem contact [email protected]. I've triaged the above build. I've created/commented on the following issue(s) |
This comment was made automatically. If there is a problem contact [email protected]. I've triaged the above build. I've created/commented on the following issue(s) |
* Update WiX to signed build (#36865) - #12078 * Always download blazor-hotreload.js from app root (#36897) The middleware that we inject always listens to the root of the app. While this might not play very nicely if the app is running off a virtual path, listening to the root is what we do with the aspnet-browser-refresh.js script and we've had no issue reports with it thus far. Fixes #35555 * Improve Results.Problem and Results.ValidationProblem APIs (#36856) * [release/6.0-rc2] Update sdk to 6.0.100-rc.2.21470.55 (#36783) * Update sdk to 6.0.100-rc.2.21470.55 Co-authored-by: Will Godbe <[email protected]> Co-authored-by: Doug Bunting <[email protected]> Co-authored-by: Pranav K <[email protected]> Co-authored-by: Safia Abdalla <[email protected]> Co-authored-by: Stephen Halter <[email protected]> Co-authored-by: Will Godbe <[email protected]> Co-authored-by: Brennan <[email protected]>
* Update WiX to signed build - #12078 * Update wix to 1.0.0-v3.14.0.5722 Co-authored-by: Doug Bunting <[email protected]> Co-authored-by: Eric StJohn <[email protected]>
* [release/6.0-rc2] Retarget DOTNETHOME when installing x64 on ARM64 (#36695) * Retarget DOTNETHOME when installing x64 on ARM64 * Make platform comparison case insenstive * Address feedback * Install x64 registry keys to different path on ARM64 machine Co-authored-by: Eric StJohn <[email protected]> * Update WiX to signed build (#36865) - #12078 * Update wix to 1.0.0-v3.14.0.5722 (#37329) Co-authored-by: Eric StJohn <[email protected]> * [release/6.0] Use WIX_NATIVE_MACHINE to detect native architecture of target machine (#37335) * Use WIX_NATIVE_MACHINE to detect native architecture of target machine * Reference WIX_NATIVE_MACHINE property Final bit to resolve what I'm tracking in #37290 Co-authored-by: Eric StJohn <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Doug Bunting <[email protected]>
* [release/6.0-rc2] Retarget DOTNETHOME when installing x64 on ARM64 (#36695) * Retarget DOTNETHOME when installing x64 on ARM64 * Make platform comparison case insenstive * Address feedback * Install x64 registry keys to different path on ARM64 machine Co-authored-by: Eric StJohn <[email protected]> * Update WiX to signed build (#36865) - #12078 * Update wix to 1.0.0-v3.14.0.5722 (#37329) Co-authored-by: Eric StJohn <[email protected]> * [release/6.0] Use WIX_NATIVE_MACHINE to detect native architecture of target machine (#37335) * Use WIX_NATIVE_MACHINE to detect native architecture of target machine * Reference WIX_NATIVE_MACHINE property Final bit to resolve what I'm tracking in #37290 Co-authored-by: Eric StJohn <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Doug Bunting <[email protected]>
Issue: #11995 , #12076
We need to acquire the hubConnectionStateLock before running the hubConnectionState checks in send/invoke/stream
We actually weren't checking the state at all when calling stream.