[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. |