Codecov Report

Merging #199 (0ee2597) into master (eb2cf8e) will decrease coverage by 0.11%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #199      +/-   ##
============================================
- Coverage     81.83%   81.71%   -0.12%     
+ Complexity      760      759       -1     
============================================
  Files            42       42              
  Lines          3066     3068       +2     
  Branches        308      309       +1     
============================================
- Hits           2509     2507       -2     
- Misses          450      452       +2     
- Partials        107      109       +2     

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Sorry Gary, not sure what you mean about retries. When it retries it changes the name by incrementing the count - since the count is appended to the name of the MBean being registered. So I'm not sure how this gets into an infinite loop?

What if another thread, somewhere, is also using Pool, also wanting JMX...

The class docs state it's intended to be thread-safe, and that i variable's scope is limited to the method. It should be fine regarding other threads trying to instantiate it I think.

I think @garydgregory is right asking if it there is a scenario where it just keeps going in a loop trying to register jmxbean, jmxbean1, jmxbean2, ..., jmxbean9999. But I think if that's a possible scenario, that deserves a separate issue as I think that affects master too (or at least deserves a comment in the javadocs or in the code body telling others why that wouldn't happen).

Firstly I would say that this PR doesn't change the logic of the method - it just checks first whether theres already a MBean with the same name rather than trying to register an MBean and having it throw an InstanceAlreadyExistsException and this appears to improve the performance x10 despite all the additional calls to the isRegisterd() method.

On the issue of multiple threads registering multiple pools at the same time, then they will iterate until a free name is found and the only possibility I see for an infinite loop would be if all possible names had already been registered. Its hard to conceive of that being the case and I suspect that other issues would occur in that case (out of memory issues).

So locally I created a test case with two Callable instances which both create 3 thread pools in separate threads and then printed out the JMX Name of each pool and it produced the following results:

First Task:

• org.apache.commons.pool2:type=GenericObjectPool,name=pool2
• org.apache.commons.pool2:type=GenericObjectPool,name=pool4
• org.apache.commons.pool2:type=GenericObjectPool,name=pool6

Second Task:

• org.apache.commons.pool2:type=GenericObjectPool,name=pool3
• org.apache.commons.pool2:type=GenericObjectPool,name=pool5
• org.apache.commons.pool2:type=GenericObjectPool,name=pool7

If you want I can add this test case to the PR?

(Note: the reason there isn't an MBean with name=pool is because TestBaseGenericObjectPool sets up a GenericObjectPool in the setup() method of the test which is already registered)