[JAVA-712] Disassociate connections from dead threads Created: 09/Dec/12  Updated: 25/Jun/13  Resolved: 25/Jun/13

Status: Closed
Project: Java Driver
Component/s: Connection Management
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Monitor/check if a thread is gone and if so, disassociate the thread from the connection (socket/port) so it can be used by any thread and no longer has affinity.



 Comments   
Comment by Jeffrey Yemin [ 25/Jun/13 ]

Thread affinity is being removed entirely in 3.0.

Comment by Jeffrey Yemin [ 10/Dec/12 ]

If you set max pool size to n, then you expect to need n concurrent connections at some point. So eventually your application will get to the max pool size, in which case disassociating won't really matter, as you're already at the max, and new threads will eventually steal all the connections with affinity to the dead ones.

If you want more re-use and don't actually expect to need that many connections concurrently, you can set the pool size smaller.

If you're write concern is ACKNOWLEDGED, what does thread affinity buy you? And if it's UNACKNOWLEDGED, things can work the way you expect during testing, and differently under high load when threads start stealing each other's connections.

Comment by Scott Hernandez (Inactive) [ 10/Dec/12 ]

Yes, there are some issues at high contention, but less so if you use a WriteConcern like the MongoClient does by default now. It gets a little more hairy with mongos, and non-primary reads, but that is another issue and not something that getting rid of thread affinity will fix (completely).

Not sure how this is more of an issue with maxIdleTimeMS (which is what I assume you meant instead of min).

The basic problem is that the current impl. will create a connection before it reuses one (if you are under the max pool size).

The use-case is if you create new threads to do your work then connections will not get reused until the pool has filled; if we add this support then when the thread dies the socket will be avail for use before the pool is full.

Comment by Jeffrey Yemin [ 09/Dec/12 ]

It would be safer to get rid of thread affinity altogether. Thread affinity can lead to unexpected results when running under load.

The way it is now, a connection with established affinity will already be stolen by another thread if there is any contention in the pool (pool size < thread size).

This becomes a bigger issue if we implement minIdleTimeMS, as thread affinity can artificially decrease idle time.

Generated at Thu Feb 08 08:52:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.