Re: [Proxool-developer] JDBC API TestSuite 1.3.1 failure

[Alastair C. <ala...@ci...>]

Hello Bill,

I am a colleague of Bas in Cipherware.  I have run the tests several 
times and I hope that we'll soon have an intelligent result - here are 
some thoughts about the tests so far.

Bill Horsman wrote:

>>The TestSuite repeats all test sets in 4 batches or so, to make sure 
>>that the driver is consistent. When the TestSuite enters the second 
>>batch it starts repeating the following stack trace:
>>
>>java.lang.NoClassDefFoundError
>>     at
>>org.logicalcobwebs.proxool.ConnectionPool.<init>(ConnectionPool.java:101)
>>    
>>
>
>I don't understand that at all. Line 101 in ConnectionPool is:
>
>    reloadMonitor = new ReloadMonitor(definition.getName());
>
>Obviously, that class does exist since it is found the first time. I am
>a little suspicious because the responisibility of that class is to spot
>Proxool being reloaded (which can sometimes cause duplicate static
>instances depending on what container is doing the reload). But I can't
>see any code that would result in a class not being found! (Nor do I
>know what code would cause that).
>
The class is always found for the first batch of tests, but not on any 
subsequent tests, so I share your suspicion about the container.  On 
previous occasions, there were problems with the SecurityManager, which 
is so restrictive that it even prevented setProperty in Proxool.  I can 
understand why the setting would be restrictive within J2EE - it is 
called by remote clients - but not for the driver, which is only called 
by J2EE.  I changed all security settings to java.security.AllPermission 
(only for the tests of course) and this was the new result.

>
>How many times does that error appear? 
>
It appears for all tests except the first one.

>Why does the test suite report "ERROR: An error occurred while closing
>the database connection" whilst the stack trace seems to be related to
>creating a new connection pool?
>
This second error only occurs because the connection has not been opened 
in the first place.

>What is the reload mechanism between batches. Does the test suite
>attempt to reload the classes? (I'm a little hazy about reloading
>classes, JVMs and such). Or does it remove the connection pool and start
>again (without any JVM or class reload stuff)?
>
I'm not sure either.  There is very little support for, and no 
discussion groups about CTS testing.  I suspect that it loads the 
connection pool from within J2EE the first time and then reloads them 
from the CTS client after that.  This is because the jar has to be in 
two places: in $J2EE_HOME/lib/system and in the CLASSPATH of CTS, which 
is defined in the file $CTS_HOME/bin/cts_env

>I'm glad your looking into this. Proxool can only benefit from intensive
>testing like this. I'm confident that this problem is not appearing in
>production situations at the moment, but I still think it is very worth
>while getting to the bottom of this.
>  
>
We tested Proxool with our software, Ci-Access, and it worked perfectly. 
 I now intend to run CTS to test Ci-Access and Proxool together, to see 
if the same error occurs.  I'm afraid that we won't be ready for release 
0.5 of Proxool as the tests take about 6 hours to complete, but I hope 
to have it ready for release 0.6.

I'll keep you posted!

Kind regards,
Alastair