Conversation
|
Ack! This may not completely fix the issue..looks like the issue has recurred even with this fix, so I have more investigation to do. |
The problem was we never put the pool in |
|
I see, I don't think that will be a problem...we probably need a pool for those distance / state events to even happen? Although I do find it confusing that we have a |
|
Made the recommended adjustment and rephrased the PR. If this is good I will also alter the CHANGELOG & commit log on merge |
Those events are coalesced and recorded in |
|
Yeah your change is what I had in mind. Does that resolve all issues in CI? |
It looks like it! Have had enough consecutive runs without the error reproducing to feel comfortable with this. I'm going to push a commit that will update change log and have the final full commit message to reflect what was done here. Cool if I merge afterwords and also merge in #1147 after? |
|
Works for me 👍 |
|
Definitely will clean that up, it's a bit of a mess at the moment 😄 |
Motivation: There is a small window where a NEW_NODE event may be sent over the control connection while a pool is initializing. This is more likely to happen in testing, where a cluster is brought up and the driver connects to it immediately. In this case, the driver would erroneously create another pool, which would create additional connections. The first pool created between the currently initializing one and the new one being created would be untracked with its connections remanining open even after the Session is closed. Modifications: Akin to the logic in processDistanceEvent and processStateEvent, only invoke createOrReconnectPool in onTopologyEvent when there is not an initializing pool future present in the pending map. Result: createOrReconnectPool is no longer invoked in onTopologyEvent if there is a pending initialization for that node.
Motivation: There is a small window where a NEW_NODE event may be sent over the control connection while a pool is initializing. This is more likely to happen in testing, where a cluster is brought up and the driver connects to it immediately. In this case, the driver would erroneously create another pool, which would create additional connections. The first pool created between the currently initializing one and the new one being created would be untracked with its connections remanining open even after the Session is closed. Modifications: Change onTopologyEvent to no longer call createOrReconnectPool, instead only call reconnectNow() if there is an already established pool. initializing pool future present in the pending map. Result: SUGGEST_UP events now only trigger reconnect on existing pool, and will no longer create a new pool.
For JAVA-2057.
This should fix an issue I noticed on our CI servers, were occasionally after forcing a node down I observed that there were still some open connections. I have CI running repeatedly against #1147, which has this fix, so assuming that continues to run well we should consider merging this. Lets wait overnight to see how things go.
Old description (see 41dec29 for actual change)
Motivation:
There is a small window where a NEW_NODE event may be sent over the
control connection while a pool is initializing. This is more likely to
happen in testing, where a cluster is brought up and the driver connects
to it immediately.
In this case, the driver would erroneously create another pool, which
would create additional connections. The first pool created between
the currently initializing one and the new one being created would be
untracked with its connections remanining open even after the Session is
closed.
Modifications:
Akin to the logic in processDistanceEvent and processStateEvent, only
invoke createOrReconnectPool in onTopologyEvent when there is not an
initializing pool future present in the pending map.
Result:
createOrReconnectPool is no longer invoked in onTopologyEvent if there
is a pending initialization for that node.