Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

Consider using ReadWriteLock to protect HubConnctionState in Java client #3330

Closed
mikaelm12 opened this issue Nov 21, 2018 · 3 comments
Closed
Assignees
Labels
client: Java cost: S Will take up to 2 days to complete PRI: 2 - Preferred Preferably should be handled during the milestone. type: Bug
Milestone

Comments

@mikaelm12
Copy link
Contributor

Currently we're just using a ReEntrant lock when we update the HubConnectionState enum in the Java client. We should considering changing this to a Read Write lock.

@analogrelay analogrelay added cost: S Will take up to 2 days to complete PRI: 2 - Preferred Preferably should be handled during the milestone. client: Java labels Nov 26, 2018
@analogrelay analogrelay added this to the 3.0.0 milestone Nov 26, 2018
@analogrelay
Copy link
Contributor

We need to consider if this needs to be backported. Though if the Java Client is shipping a .1 release prior to 3.0, we can just roll it in to that. Basically I don't want people to have to wait for 3.0 for this fix :).

@mikaelm12
Copy link
Contributor Author

Do we want this for 2.2.2?

@mikaelm12
Copy link
Contributor Author

It seems like the actual issue here is that we don't do a connection state check when the invoke method is called. With that information, I'm gonna close this issue in favor for one specific to that work,

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
client: Java cost: S Will take up to 2 days to complete PRI: 2 - Preferred Preferably should be handled during the milestone. type: Bug
Projects
None yet
Development

No branches or pull requests

2 participants