On 05/01/2010, sebb <seb...@gmail.com> wrote:
> It looks like there may be a bug in PerUserPoolDataSource.
>
> From time to time, more than 10 of the threads acquire connections in
> the testMultipleThreads2() test case. I don't think this should
> happen, and it does not happen in the TestSharedPoolDataSource
> version.
>
> I've committed some debug code as part of r896162.
> In my tests, this sometimes shows >10 threads in state "Done", yet
> none of them had to wait for a connection.
>
> I've started looking at the code, but it's a bit complicated and the
> Javadoc is somewhat lacking (might fix that as I go) so I've yet to
> find a bug.
Found the bug: the method
PerUserPoolDataSource.getPooledConnectionAndInfo(user,pass)
has the code:
Object pool = pools.get(key); // pools = instance variable
synchronized(this) {
if (pool == null) {
try {
registerPool(username, password);
pool = pools.get(key);
[...]
The first get() call can return null to multiple threads, so multiple
threads can register the pool. Not good.
I also noticed that disabling the test case testMultipleThreads1() -
or running it after testMultipleThreads2() - would allow all the
testMultipleThreads2() threads to get connections, as the pool was
recreated multiple times. Not sure why running testMultipleThreads1()
first affects the other test case, but moving the get() inside the
synch. block fixes both problems.
I'll raise a JIRA and fix the bug.
So it was worth keeping the test case.
> Let's see if Continuum gives similar debug output.
>
>
> S
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
