[JAVA-597] Update semaphore limit if connectionsPerHost or threadsAllowedToBlockForConnectionMultiplier changed after construction Created: 06/Jul/12  Updated: 05/Dec/17  Resolved: 25/Jun/13

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

Type: Improvement Priority: Minor - P4
Reporter: A. Jesse Jiryu Davis Assignee: Unassigned
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends

 Description   

User reports writing:

Mongo mongo = new Mongo("127.0.0.1", 27017);
mongo.getMongoOptions().connectionsPerHost = 100;
mongo.getMongoOptions().threadsAllowedToBlockForConnectionMultiplier = 5;

... and then spinning up 100 threads, getting "out of semaphores" error. If options are set before constructing the Mongo instance, semaphore limit is large, as expected. Semaphore limit should be updated after construction if connectionsPerHost or threadsAllowedToBlockForConnectionMultiplier changes.



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

Settings should be immutable, so closing this.

Comment by Jeffrey Yemin [ 12/Jul/12 ]

There may be some demand for this, but I wouldn't implement it this way.

Comment by Scott Hernandez (Inactive) [ 12/Jul/12 ]

Yes, not sure this one should be fixed at all; or we could just make the calculation dynamic in the pool code.

Comment by Jeffrey Yemin [ 12/Jul/12 ]

It may be, but it's typical for classes to make copies of non-immutable constructor arguments. Clients shouldn't be relying on Mongo instances not doing that for MongoOptions.

Comment by Scott Hernandez (Inactive) [ 12/Jul/12 ]

It is desirable to make changed to (some of) those setting dynamically.

Comment by Jeffrey Yemin [ 06/Jul/12 ]

It would have been better if MongoOptions were immutable.

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