proxool-developer — Developer's discussion list

Re: [Proxool-developer] J2EE 1.2.1 compliance testing

[Bas C. <ba...@ci...>]

Alastair Calderwood wrote:
> 2.  Oracle maximum cursors exceeded error
> to the hierarchy, this never occurs.  Personally I'd say it was the 
> application programmer's responsiblity to close PreparedStatements - not 
> sure why they haven't done so in the tests - and in my opinion the 
> failure of these tests is not too important, but others might have 
> different points of view.  My next test is to run via a remote-access

"[java.sql.Connection.close()] Releases a Connection's database and JDBC 
resources immediately instead of waiting for them to be automatically 
released" [J2SE API 1.3.1].

Proxool's implementation doesn't release any JDBC resources before the 
Connection is returned to the pool. This behaviour doesn't satisfy the 
quoted description, so it is a bug in Proxool.
Perhaps there are cases when a lazy close() is more efficient then 
closing each resource immediately after usage (??)

Kind regards,
Bas

Kind regards,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

[Proxool-developer] J2EE 1.2.1 compliance testing

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

1  .class file is not found in .jar

Thanks for your tip, Christian.  I'll try with a different lock to see 
if that solves the problem. Out of interest has anyone else had this 
problem with the jar, or are you all using unjarred classes?  I'll use 
them unjarred until this problem is solved.

2.  Oracle maximum cursors exceeded error

On Friday I reported that Oracle was producing an error for certain 
tests when tested with Proxool.  The error was:

SVR-ERROR: java.rmi.RemoteException: ORA-01000: maximum open cursors
exceeded

I have researched the cause of the problem in Oracle FAQ and it appears 
that Oracle's default maximum number of cursors (300) should be quite 
sufficient.  Cursors are staying open only because the test suite does 
not close every PreparedStatement but instead relies on the close method 
of Connection, which with a plain driver (i.e. without a connection pool 
in front) would call finalize on the whole hierarchy.  In a connection 
pool where connections are not really closed, and there is no reference 
to the hierarchy, this never occurs.  Personally I'd say it was the 
application programmer's responsiblity to close PreparedStatements - not 
sure why they haven't done so in the tests - and in my opinion the 
failure of these tests is not too important, but others might have 
different points of view.  My next test is to run via a remote-access 
application (Ci-Access) that does close PreparedStatements when a 
Connection is closed, so perhaps that will yield a better result

Alastair Calderwood

RE: [Proxool-developer] J2EE compliance testing

[<chr...@em...>]

I think you get this error when one connection opens more simultanious
cursors than defined by the OPEN_CURSORS Oracle parameter.

This might signify that either your test code, or Proxool (gulp!) does not
close statements properly.

CHR


> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of
> Alastair Calderwood
> Sent: 13 December 2002 18:11
> To: pro...@li...
> Subject: [Proxool-developer] J2EE compliance testing
>
>
> Dear All,
>
> Yesterday's problems were solved and I have now run the test suite
> against the Oracle driver alone, and against Proxool with Oracle.  Most
> tests passed by Oracle were also passed by Proxool.  Doing a 'diff'
> between the output logs revealed one persistent error that occured in
> Proxool but not with the Oracle driver alone.
>
> SVR-ERROR: java.rmi.RemoteException: ORA-01000: maximum open cursors
> exceeded
>
> Do you know what this is, and is it caused by the application or
> database?
>
> I'll examine the logs more carefully (they are about 12,000 pages) and
> see if there are any other errors.
>
> Alastair Calderwood
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

[Proxool-developer] J2EE compliance testing

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

Dear All,

Yesterday's problems were solved and I have now run the test suite 
against the Oracle driver alone, and against Proxool with Oracle.  Most 
tests passed by Oracle were also passed by Proxool.  Doing a 'diff' 
between the output logs revealed one persistent error that occured in 
Proxool but not with the Oracle driver alone.

SVR-ERROR: java.rmi.RemoteException: ORA-01000: maximum open cursors 
exceeded

Do you know what this is, and is it caused by the application or database? 

I'll examine the logs more carefully (they are about 12,000 pages) and 
see if there are any other errors.

Alastair Calderwood

RE: [Proxool-developer] Re: J2EE 1.2.1 compliance testing

[<chr...@em...>]

This problem could possibly be solved by using another lock than
ConnectionPoolManager.class:

diff -r1.3 ConnectionPoolManager.java
23a24
>     private static final Object LOCK = new Object();
35c36
<             synchronized (ConnectionPoolManager.class) {
---
>             synchronized (LOCK) {


...but this does not tell us what the problem actually is.

Maybe theres somthing wrong with our Manifest.mf file?

CHR


> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of
> Alastair Calderwood
> Sent: 12 December 2002 23:50
> To: pro...@li...
> Subject: [Proxool-developer] Re: J2EE 1.2.1 compliance testing
>
>
> The error I mentioned earlier - NoClassDefFoundError when
> ConnectionPoolManager.class is referenced - only occurs with the Proxool
> jar, not with the normal classes.  It must have something to do with the
> getResource method in ClassLoader looking for the actual class name, and
> not being able to look in archives - but I thought that it would be
> enough to set the VM classpath to include the Proxool jar.  Anyway, for
> now I am continuing with the tests using unjarred classes.
>
> Alastair Calderwood
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

[Proxool-developer] Re: J2EE 1.2.1 compliance testing

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

The error I mentioned earlier - NoClassDefFoundError when 
ConnectionPoolManager.class is referenced - only occurs with the Proxool 
jar, not with the normal classes.  It must have something to do with the 
getResource method in ClassLoader looking for the actual class name, and 
not being able to look in archives - but I thought that it would be 
enough to set the VM classpath to include the Proxool jar.  Anyway, for 
now I am continuing with the tests using unjarred classes.

Alastair Calderwood

[Proxool-developer] J2EE 1.2.1 compliance testing

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

Dear All,

Yesterday I sent a report highlighting an error that occured when using 
Proxool with Ci-Access, a product we have developed.  It appears that 
Proxool obtained the connection and yet threw a SQLException when a 
statement was executed using that connection.  In order to investigate 
which product actually caused the problem, I today tested the Oracle 
driver by itself, which passed most (but not all!) tests in the test 
suite.  I then tested with the Proxool and Oracle drivers, and found 
that the test suite does have a strange problem with Proxool.  I think 
that it cannot find ConnectionPoolManager.class in this method:

   public static ConnectionPoolManager getInstance() {
        if (connectionPoolManager == null) {
            synchronized (ConnectionPoolManager.class) {
                if (connectionPoolManager == null) {
                    connectionPoolManager = new ConnectionPoolManager();
                }
            }
        }
        return connectionPoolManager;
    }

Here's the test-suite log:

********************************************************************************
Beginning Test:  testAllProceduresAreCallable
********************************************************************************
SVR: Using DataSource
SVR-ERROR:
SVR-ERROR: java.lang.NoClassDefFoundError
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:115)
    at org.logicalcobwebs.proxool.ConnectionPoolManager.class$(Unknown 
Source)
    at org.logicalcobwebs.proxool.ConnectionPoolManager.<clinit>(Unknown 
Source)
    at org.logicalcobwebs.proxool.ProxoolDriver.connect(Unknown Source)
    at java.sql.DriverManager.getConnection(DriverManager.java:512)
    at java.sql.DriverManager.getConnection(DriverManager.java:172)
    at 
com.sun.enterprise.resource.JdbcConnectionAllocator.createResource(JdbcConnectionAllocator.java:72)

... and so on for a few pages...

Any ideas?  I thought J2EE might need the full name, so will try that 
and see what happens.

Regards,

Alastair Calderwood

"Save paper...  don't print out stack traces!"

RE: [Proxool-developer] Re: Proxool and web apps

[Martin C. <mar...@sy...>]

On Thu, 2002-12-12 at 09:32, Christian Nedregard wrote:
> The problem is unfotunately more complex than that.
> A class uniqueness is defined by package + classname + classloader.
> Appservers reloads classes into a new classloader. So the static 
> variable in
> generation 1 is in fact another static variable than that in 
> generation 2.
> 

As I was typing my response to why statics would not work this arrived
in my box. This article (same guy who wrote Server Based Java from
Manning) explains more
http://www.javageeks.com/Papers/JavaStatics/index.html

> That is: Your problem is simply solved by calling
> "ProxoolFacade#removeAllConnectionPools" from the 'destroy' method of 
> a servlet in your app.
> 

Or, again I'll stress, the correct placement for proxool in a servlet
container really should be in a classloader higher in the classloader
hierarchy than the web app classloaders. For Tomcat this is either the
"common" directory or the "share" directory. I am not familiar if this
classloader hierarchy provided by Tomcat is part of the servlet
container spec or not so individual implementations my vary.
Additionally, it should also be noted that your JDBC drivers must be
deployed at either the same classloader level or higher for proxool to
recognise them.

This has been fun;)
Martin

RE: [Proxool-developer] Re: Proxool and web apps

[<chr...@em...>]

The problem is unfotunately more complex than that.
A class uniqueness is defined by package + classname + classloader.
Appservers reloads classes into a new classloader. So the static variable in
generation 1 is in fact another static variable than that in generation 2.

Tomcat might actually be the only appserver handling reloads *right*. Our
"fix" (taken from some code I wrote for another project) presupposes that
threads from unloaded classes are still allowed to perform actions. I'n
Tomcat the thread is obviously denied even access to JDK classes.

The problem here is to find a "hook" that notifies us when the application
is about to be unloaded. Java does unfortunately not provide a static
'finalize' method.

Me and Bill have been looking at this problem today and I think we simply
have to roll back to the old Proxool solution. This  reqires that
"ProxoolFacade#removeAllConnectionPools" is called from user code before the
application is reloaded/closed.

That is: Your problem is simply solved by calling
"ProxoolFacade#removeAllConnectionPools" from the 'destroy' method of a
servlet in your app.

This reintroduces an external dependency to Proxool that we tried to remove
with the system properties hack. Since this hack actually depends on
erroneous behaviour of appservers it can not be trusted, as the Tomcat case
exaplifies.

Oh well ;)

CHR


> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of Bas
> Cancrinus
> Sent: 12 December 2002 14:00
> Cc: Proxool Developer List
> Subject: Re: [Proxool-developer] Re: Proxool and web apps
>
>
> Martin Crawford wrote:
> > security policy to deny this. A file would be the most logical
> and friendly
> > solution, although how and where you put that file without using System
> > Props is beyond me, I guess another configurable property. Although
>
> Can't you work around the problem with static variables? Like:
>
> private static boolean reloadFlag;
>
> static {reloadFlag = true;}
> protected ReloadMonitor(...) {
> 	...
> 	reloadFlag = false;
> }
> protected boolean isProxoolReloaded() {
> 	if (reloadFlag) {
> 		...
> 		return true;
>          } else {
> 		return false;
>          }
> }
>
> Please let me know what you think.
>
> Kind regards,
> Bas
>
> --
> Bas Cancrinus   -> ba...@ci...
> Software Architect
> Cipherware Ltd. -> http://www.cipherware.com
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

Re: [Proxool-developer] Re: Proxool and web apps

[Bill H. <bi...@lo...>]

Bas,

On Thu, 2002-12-12 at 13:00, Bas Cancrinus wrote:

> Can't you work around the problem with static variables? Like:
> 
> private static boolean reloadFlag;
> 
> static {reloadFlag = true;}
> protected ReloadMonitor(...) {
> 	...
> 	reloadFlag = false;
> }
> protected boolean isProxoolReloaded() {
> 	if (reloadFlag) {
> 		...
> 		return true;
>          } else {
> 		return false;
>          }
> }

I see what you're trying to do here. It looks like it might work. It's
nice and simple. Definitely worth a try. I'll see if I can test it
later.

Bill

Re: [Proxool-developer] Re: Proxool and web apps

[Bas C. <ba...@ci...>]

Martin Crawford wrote:
> security policy to deny this. A file would be the most logical and friendly
> solution, although how and where you put that file without using System
> Props is beyond me, I guess another configurable property. Although

Can't you work around the problem with static variables? Like:

private static boolean reloadFlag;

static {reloadFlag = true;}
protected ReloadMonitor(...) {
	...
	reloadFlag = false;
}
protected boolean isProxoolReloaded() {
	if (reloadFlag) {
		...
		return true;
         } else {
		return false;
         }
}

Please let me know what you think.

Kind regards,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

RE: [Proxool-developer] Re: Proxool and web apps

[Martin C. <mus...@us...>]

> We are working on another issue at the moment that I don't believe is
> connected with this problem but is so close it would be silly not to
> mention it. The ReloadMonitor uses System Properties to record the class
> load time and Bas has informed me that this is not allowed for a J2EE
> JDBC Driver. We will be coming up with another solution (probably
> writing to file instead) shortly. I don't see how that would help your
> problem, Martin.

Don't quote me on this, but I think the servlet spec says no touching the
Systems Properties from servlet code. I'm almost positive Tomcat sets the
security policy to deny this. A file would be the most logical and friendly
solution, although how and where you put that file without using System
Props is beyond me, I guess another configurable property. Although
seriously, something like proxool belongs in the common or for Tomcat as my
Tomcat administrator pointed out the share directory. All web apps should
share JDBC drivers and Connections.

This link will provide more insight to Tomcat classloader madness:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html


> Agreed. The trick is knowing whether the URL is wrong or if the DB is
> down (assuming that no connections have been built to date). Perhaps
> this would be declared in the exception thrown by the driver? For
> instance, we should be able to spot if no delegate driver was found (the
> URL was so bad we couldn't even find a driver to accept it). After that
> it is probably driver specific - but we could have it configurable, like
> the fatal-sql-exception property.

Hmmm... perhaps I'm being a little naive, I would just try connecting x
number of times and then give-up (the number of times configurable of
course). Only if client code requests a connection specifically again for
the same URL it will try it connection routine. This number of tries
trapping routine would only run if no successful connection has been made to
that URL, otherwise then you let it do your keep-alive routine. Makes sense
(today has been an inarticulate day for me;)?

> Yes, I think that's the answer. The fatal-sql-exception property spots
> *Connections* that are no use anymore. We should also have a
> hopeless-configuration-exception property. We could list suggest values
> for common drivers on the web site. Or possibly, recognise the driver
> and do that automatically (allowing override by configuration).

Trying to support mulitple drivers this way would be a testing and
maintenace nightmare, and makes too many assumptions for the user. I know
JDBC fails for standardise exceptions in the spec which is a real short
coming.

Cheers.
Martin

RE: [Proxool-developer] Re: Proxool and web apps

[Bill H. <bi...@lo...>]

On Thu, 2002-12-12 at 00:28, Martin Crawford wrote:

> Don't quote me on this, but I think the servlet spec says no touching the
> Systems Properties from servlet code. I'm almost positive Tomcat sets the
> security policy to deny this. 

Well, Tomcat certainly seems to allow it for Proxool. Your stack trace
showed that ReloadMonitor had already made successful use of the System
Properties. However, I agree, it is still a bad idea.

> A file would be the most logical and friendly
> solution, although how and where you put that file without using System
> Props is beyond me, 

I suppose the best we can do is to write it to the working directory
unless it is configured. The log could then give a warning along the
lines of "permision was denied to write to /path/lockfile - warning,
Proxool may not close down properly during a reload".

All our configuration is done at pool level at the moment - we don't
have any Proxool-wide properties. Maybe we should have a file per pool
anyway. The pool configuration includes that directory to write the file
to, and we write a file like ".alias.lock" or something.

I know Christian (chr32) is intending to work on this over the next few
days...

> something like proxool belongs in the common or for Tomcat as my
> Tomcat administrator pointed out the share directory. All web apps should
> share JDBC drivers and Connections.

We should perhaps advocate that in the doc. But it would be nice not to
insist on it.

> This link will provide more insight to Tomcat classloader madness:
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

Interesting reading. I'm learning something here.

> Hmmm... perhaps I'm being a little naive, I would just try connecting x
> number of times and then give-up (the number of times configurable of
> course). Only if client code requests a connection specifically again for
> the same URL it will try it connection routine. This number of tries
> trapping routine would only run if no successful connection has been made to
> that URL, otherwise then you let it do your keep-alive routine. Makes sense
> (today has been an inarticulate day for me;)?

Well, my solution is a lot more complicated so I guess you must be right
:) 

> Trying to support mulitple drivers this way would be a testing and
> maintenace nightmare, and makes too many assumptions for the user. I know
> JDBC fails for standardise exceptions in the spec which is a real short
> coming.

Sometimes I do clever (i.e. complex) things just for the fun of it. It
almost always turns out to be a bad idea.

Bill

RE: [Proxool-developer] Re: Proxool and web apps

[Bill H. <bi...@lo...>]

On Wed, 2002-12-11 at 20:48, Martin Crawford wrote:

> Dec 11, 2002 3:35:25 PM org.logicalcobwebs.proxool.ConnectionPool finalize
> SEVERE: Unknown problem finalizing pool
> java.lang.NoClassDefFoundError: java/lang/Math
>         at
> org.logicalcobwebs.proxool.ConnectionPool.finalize(ConnectionPool.java:482)

!!! It can't find java.lang.Math. That's awkward. I think we might be in
a Tomcat specific area here. I have used this same feature with Resin
and it closes down the old instance just fine. It would seem that
ReloadMonitor is noticing that something needs to be done - it's just
that other classes are being unloaded around it. I'm not sure what is
going on but this might be a good question for one of the Tomcat lists.
Martin, do you know enough about this to post to Tomcat? The offending
line is fairly trivial:

long sleepTime = Math.max(0, delay + startFinalize -
System.currentTimeMillis());


We are working on another issue at the moment that I don't believe is
connected with this problem but is so close it would be silly not to
mention it. The ReloadMonitor uses System Properties to record the class
load time and Bas has informed me that this is not allowed for a J2EE
JDBC Driver. We will be coming up with another solution (probably
writing to file instead) shortly. I don't see how that would help your
problem, Martin.

> I guess I'll go back to deploying to the commons classpath. 

That seems a sensible workaround. If we don't come up with an answer for
this soon I will add a FAQ about it.

> I agree it's nice to have, but if the URL was never right to begin with it's
> like kicking a dead horse.

Agreed. The trick is knowing whether the URL is wrong or if the DB is
down (assuming that no connections have been built to date). Perhaps
this would be declared in the exception thrown by the driver? For
instance, we should be able to spot if no delegate driver was found (the
URL was so bad we couldn't even find a driver to accept it). After that
it is probably driver specific - but we could have it configurable, like
the fatal-sql-exception property.

Yes, I think that's the answer. The fatal-sql-exception property spots
*Connections* that are no use anymore. We should also have a
hopeless-configuration-exception property. We could list suggest values
for common drivers on the web site. Or possibly, recognise the driver
and do that automatically (allowing override by configuration).

Bill

RE: [Proxool-developer] Re: Proxool and web apps

[Martin C. <mus...@us...>]

> We added a ReloadMonitor in 0.5 that should fix that. As soon as Proxool
> is reloaded then it closes all the old connection pools. Can you try out
> 0.5 and let us know if it fixes it?

Ah, now I have a reason for 0.5, guess I'm using your patched version for
jxDbCon;)

Although, I tried it out and a) the following exception dump was thrown to
the Tomcat stdout, and b) I eventually ran out of connections to my
database. So I guess it didn't really fix it. Tomcat version is latest
stable 4.1.12.

Dec 11, 2002 3:35:25 PM org.logicalcobwebs.proxool.ConnectionPool finalize
INFO: Closing down instance started at Wed Dec 11 15:33:55 EST 2002 -
waiting for 500 milliseconds for everything to stop.
[ReloadMonitor.proxool:org.sourceforge.jxdbcon.JXDBConDriver:jdbc:postgresql
:net//username:password@localhost:4321/database]
WebappClassLoader: Lifecycle error : CL stopped

Dec 11, 2002 3:35:25 PM org.logicalcobwebs.proxool.ConnectionPool finalize
SEVERE: Unknown problem finalizing pool
java.lang.NoClassDefFoundError: java/lang/Math
        at
org.logicalcobwebs.proxool.ConnectionPool.finalize(ConnectionPool.java:482)
        at
org.logicalcobwebs.proxool.ProxoolFacade.removeConnectionPool(ProxoolFacade.
java:295)
        at
org.logicalcobwebs.proxool.ProxoolFacade.removeAllConnectionPools(ProxoolFac
ade.java:330)
        at
org.logicalcobwebs.proxool.ReloadMonitor.isProxoolReloaded(ReloadMonitor.jav
a:79)
        at
org.logicalcobwebs.proxool.ConnectionPool$HouseKeeper.run(ConnectionPool.jav
a:608)
        at java.lang.Thread.run(Thread.java:536)

I guess I'll go back to deploying to the commons classpath. In reality, this
is the "proper" place for such a thing. It is usually recommended that JDBC
drivers are deployed to the "common" folder as they should be usable across
applications. Additionally, it would make more sense to put your connection
pool higher up so the same apps that potentially use the sames resources can
benefit from shared resources. But this is now philosophical if the
ReloadMontior works.

> Sometimes when a database is down it is nice to see Proxool
> automatically pick up the connections when it comes back up again
> though. I suppose this should be a configurable nice-to-have.

I agree it's nice to have, but if the URL was never right to begin with it's
like kicking a dead horse.

> It shouldn't actually be a very intensive background process. By
> default, the house keeping thread runs every 30 seconds and if it fails
> to make the first spare connection it gives up on the rest. So the only
> process activity is to attempt to build a connection once every 30
> seconds. And if the database is down then this activity is less than you
> would normally experience.

Even through it's a small process, every bit of memory helps. I will add
this as a feature to the tracker, but I agree it isn't the most critical
thing in the world.

Martin

RE: [Proxool-developer] configuration via properties file

[<chr...@em...>]

> > Maybe this is also the time to factor out some sub-packages like
> > org.logicalcobwebs.proxool.delegate,=20
> org.logicalcobwebs.proxool.driver and
> > org.logicalcobwebs.proxool.configuration?=20
>=20
> What goes in delegate?

I was thinking about ProxyStatement, ProxyConnection and ProxyFactory. =
Er... maybe 'proxy' is a better name :)

> > This would break backwards compatibility.=20
>=20
> Depends what you move. I think it would be reasonable to leave all the
> classes mentioned in the Simple API where they are.

Agreed.

> If you want to move
> the configuration classes into a sub-pacakge then it should have no
> effect.

Well. Only for the people allready using PropertyConfigurator.

> The other reason why the classes are all in one package is because of
> the limitations of Java's modifiers. I know this is a clumsy approach
> but it works well with small projects like this. You'll notice that =
most
> of the classes don't have public access; this makes it obvious which
> classes are there for users to play with and which ones are for =
Proxool
> use only.

I understand. This could also be done after factoring out packages by =
just bulding JavaDoc for the org.logicalcobwebs.proxool package when you =
are building the Simple (or "user") API. This is the usual way to do it. =
There is for instance a whole bunch of public classes bundled with the =
JDK that are not exposed through the JDK JavaDoc API.

I'm just worried that we end up with 75 classes in =
org.logicalcobwebs.proxool in 2 years time y'know ;)
It's very important for a project to have a sensible package structure.=20

> > It might suggest that we move the project
> > status from 'production/stable' to 'alpha'.=20
>=20
> That might be a bit worrying for people who already use it in
> production! As long as you can handle the simple API
> (http://proxool.sourceforge.net/api/index.html) remaining where it is
> then I don't see why it is necessary.

K. Does this mean that I can forget backwards compatibility regarding =
the 'ext' classes?

IMHO there is still one weakness in the public API, and thats the lack =
of a nestable ProxoolException. Theres a lot of methods (i.e. in =
ProxoolFacade and in the Configurators) that might get errors that has =
nothing to do with JDBC.

> > Could I also suggest a rename of VirtoolDriver? It's a cool=20
> sounding name,
> > but it doesen't say much about what the class actually is.
> > In fact, I don't really know what it is even after looking at=20
> the code and
> > JavaDoc ;)
>=20
> Yeah, it is a crap name :) It probably shouldn't be in the main tree =
at
> all because it's just an experimental component. Not sure where to put
> it really: either a cvs branch or a java-exp source tree?  Even =
better,
> make it part of a new project within Proxool. I suppose if someone =
grabs
> the latest code it looks bad if there is an incomplete class there.

Could certantly give a bad impression. How about a 'java-sandbox' source =
tree for experimental/unfinised stuff?

CHR

[Proxool-developer] Re: Proxool and web apps

[Bill H. <bi...@lo...>]

Martin,

On Wed, 2002-12-11 at 16:57, Martin Crawford wrote:

> What I found after numerous
> unloadings/reloadings of my web app (love the development cycle) is that
> proxool classes that were loaded were keeping alive Connections to my
> database from the previous installation, and then opening a whole new set
> when I reload my web app again 

We added a ReloadMonitor in 0.5 that should fix that. As soon as Proxool
is reloaded then it closes all the old connection pools. Can you try out
0.5 and let us know if it fixes it?

> My thought is that proxool should give up if it cannot connect a certain
> number of times while trying to keep some connections idle. It should still
> reattempt a connection if the client code asks for it again though. Makes
> sense?

Sometimes when a database is down it is nice to see Proxool
automatically pick up the connections when it comes back up again
though. I suppose this should be a configurable nice-to-have.

It shouldn't actually be a very intensive background process. By
default, the house keeping thread runs every 30 seconds and if it fails
to make the first spare connection it gives up on the rest. So the only
process activity is to attempt to build a connection once every 30
seconds. And if the database is down then this activity is less than you
would normally experience. 

But feel free to add it as a feature request if you think it will be
useful.
 
> Also documentation should probably indicate that proxool should be deployed
> to commons folder (or set in the main classpath) for web apps.

If you upgrade to 0.5 then this shouldn't be true.

> Just some input.

Always welcome, Martin.

Bill

Re: [Proxool-developer] J2EE compliance testing

[Bill H. <bi...@lo...>]

Alastair,

On Wed, 2002-12-11 at 12:56, Alastair Calderwood wrote:

> The problem now is that 
> there is an exception thrown by the test suite itself, which is proving 
> harder to rectify.  The test suite output is as follows:
<snip>
> com.sun.cts.tests.jdbc.ee.common.dbSchema.createData(dbSchema.java:54)
<snip>
> 44  try
> 45          {
> 46              // Create the database tables
> 47              props=p;
> 48              createTable(p,conn);
> 49              TestUtil.logMsg("Created the tables " + pTableName + " 
> and " + fTableName);
> 50          }
> 51          catch (Exception e)
> 52          {
> 53             dbUnConnect(conn);
> 54              throw new RemoteException( e.getMessage() );
> 55        }

It's annoying that you don't see the actual line that causes the
exception, isn't it?

> Please bear with me and I'll keep you 
> informed of any further developments.

No problem, Alastair. We probably won't release 0.6 until next week
sometime now, I believe.

Regards,
Bill

[Proxool-developer] J2EE compliance testing

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

Dear All,

I have been attempting to run the J2EE 1.2 compliance tests with 
Proxool.  Unfortunately there have been two problems.  At first, it 
emerged that the user and password for the database needed to be the 
same (unlike the J2EE 1.3 test-suite).  I solved this rather tedious 
problem by altering the password in Oracle, and a connection to Oracle 
is now obtained via Proxool (I logged the toString() of the connection - 
i.e. the address - to make sure it is a real connection).  There are 
therefore no problems with Proxool itself.  The problem now is that 
there is an exception thrown by the test suite itself, which is proving 
harder to rectify.  The test suite output is as follows:

********************************************************************************
Beginning Test:  testAllProceduresAreCallable
********************************************************************************
SVR: Using DataSource
SVR: intTabSize: 5
SVR: intTabTypeSize: 5
SVR: createString1: create table ctstable1 (TYPE_ID int, TYPE_DESC 
varchar(32), primary key(TYPE_ID))
SVR-ERROR: SQLException creating ctstable2 or ctstable1 table
SVR-ERROR: An exception occurred on a remote host. Details: Unable to 
forward the command, java.rmi.ServerException: RemoteException occurred 
in server thread; nested exception is:
    java.rmi.RemoteException: java.rmi.ServerException: RemoteException 
occurred in server thread; nested exception is:
    java.rmi.RemoteException: java.rmi.ServerException: RemoteException 
occurred in server thread; nested exception is:
    java.rmi.RemoteException: java.rmi.RemoteException: 
java.lang.NullPointerException
SVR: Closed the database connection
SVR-ERROR: Setup Failed!

SVR-ERROR: java.rmi.RemoteException: An exception occurred on a remote 
host. Details: Unable to forward the command, java.rmi.ServerException: 
RemoteException occurred in server thread; nested exception is:
    java.rmi.RemoteException: java.rmi.ServerException: RemoteException 
occurred in server thread; nested exception is:
    java.rmi.RemoteException: java.rmi.ServerException: RemoteException 
occurred in server thread; nested exception is:
    java.rmi.RemoteException: java.rmi.RemoteException: 
java.lang.NullPointerException
    at 
com.sun.cts.tests.jdbc.ee.common.dbSchema.createData(dbSchema.java:54)
    at 
com.sun.cts.tests.jdbc.ee.dbMeta.dbMeta1.dbMetaClient1.setup(dbMetaClient1.java:123)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.sun.cts.harness.EETest.run(EETest.java:589)
    at com.sun.cts.harness.ServiceEETest.run(ServiceEETest.java:249)
    at 
com.sun.cts.harness.vehicle.ejb.EJBVehicle.runTest(EJBVehicle.java:68)
    at 
com.sun.cts.harness.vehicle.ejb.EJBVehicle_EJBObjectImpl.runTest(EJBVehicle_EJBObjectImpl.java:17)
    at 
org.omg.stub.com.sun.cts.harness.vehicle.ejb._EJBVehicle_EJBObjectImpl_Tie._invoke(Unknown 
Source)
    at 
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatchToServant(GenericPOAServerSC.java:423)
    at 
com.sun.corba.ee.internal.POA.GenericPOAServerSC.internalDispatch(GenericPOAServerSC.java:137)
    at 
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatch(GenericPOAServerSC.java:98)
    at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:227)
    at 
com.sun.corba.ee.internal.iiop.CachedWorkerThread.doWork(IIOPConnection.java:262)
    at 
com.sun.corba.ee.internal.iiop.CachedWorkerThread.run(IIOPConnection.java:230)

The NullPointerException is thrown by the following code in the method 
com.sun.cts.tests.jdbc.ee.common.dbSchema.createData:

44  try
45          {
46              // Create the database tables
47              props=p;
48              createTable(p,conn);
49              TestUtil.logMsg("Created the tables " + pTableName + " 
and " + fTableName);
50          }
51          catch (Exception e)
52          {
53             dbUnConnect(conn);
54              throw new RemoteException( e.getMessage() );
55        }

which means that either 'props' or 'conn' is null for some reason.  I am 
investigating this, but as it's not really possible to recompile the 
test-suite itself, and you have to wait about 30 minutes before the 
output for the first test (i.e. the output above) appears, it is taking 
a more time than I expected.  Please bear with me and I'll keep you 
informed of any further developments.

Regards,
Alastair Calderwood
Cipherware Ltd.
http://www.cipherware.com

[Proxool-developer] Developer's Forum

[Bill H. <bi...@lo...>]

Just a note to say that I have deleted the developer's forum since it
seems to have been superseded by this mailing list.

Bill

RE: [Proxool-developer] configuration via properties file

[Bill H. <bi...@lo...>]

On Wed, 2002-12-11 at 01:45, Christian Nedregård wrote:

> No prob. I can use delegation. Would you mind me renaming XMLConfigurator
> SAXConfigurator?

Go ahead. Nobodies using it yet anyway. (Or, at least, if they are they
must be disappointed because it doesn't work yet).

> Maybe this is also the time to factor out some sub-packages like
> org.logicalcobwebs.proxool.delegate, org.logicalcobwebs.proxool.driver and
> org.logicalcobwebs.proxool.configuration? 

What goes in delegate?

> This would break backwards compatibility. 

Depends what you move. I think it would be reasonable to leave all the
classes mentioned in the Simple API where they are. If you want to move
the configuration classes into a sub-pacakge then it should have no
effect.

The other reason why the classes are all in one package is because of
the limitations of Java's modifiers. I know this is a clumsy approach
but it works well with small projects like this. You'll notice that most
of the classes don't have public access; this makes it obvious which
classes are there for users to play with and which ones are for Proxool
use only. The ProxoolDriver has to be public, as does the ProxoolFacade
- but other than that you just get a few interfaces to use. (Note,
ConnectionResetter is incorrectly public in 0.5).

> It might suggest that we move the project
> status from 'production/stable' to 'alpha'. 

That might be a bit worrying for people who already use it in
production! As long as you can handle the simple API
(http://proxool.sourceforge.net/api/index.html) remaining where it is
then I don't see why it is necessary.

> Could I also suggest a rename of VirtoolDriver? It's a cool sounding name,
> but it doesen't say much about what the class actually is.
> In fact, I don't really know what it is even after looking at the code and
> JavaDoc ;)

Yeah, it is a crap name :) It probably shouldn't be in the main tree at
all because it's just an experimental component. Not sure where to put
it really: either a cvs branch or a java-exp source tree?  Even better,
make it part of a new project within Proxool. I suppose if someone grabs
the latest code it looks bad if there is an incomplete class there.
There is so little code done in VirtoolDriver I might just delete it for
now.

> It's unfinished non? 

I think barely started is a better description.

> Is it meant just to be a load balancer, or should it
> support various switching scheemes (like switching at certain times, or
> after a certain number of usages)?

Simple load balancer. At least at first. Maybe this should become a
post-1.0 task. It still requires a lot of work and it would be silly to
hold up 1.0 because of it.

Bill

RE: [Proxool-developer] configuration via properties file

[<chr...@em...>]

> > By the way: The XMLConfigurator does not have any dependency on JAXP,
> > only SAX. I guess we ought to write a JAXP subclass that takes care of
> > parser instaniation etc and offers a couple of "configure" methods like
> > PropertyConfigurator.
>
> Looks like you just talked your way into a job :)

Sure. 'bout time I actually started committing sumthin' eh?

> Does it have to be a sub-class? Couldn't you have a JAXPConfigurator
> that *uses* the XMLConfigurator? But I don't know much about JAXP.

No prob. I can use delegation. Would you mind me renaming XMLConfigurator
SAXConfigurator?

> > Move all the "ext" classes into Proxool proper, and remove the "ext"
> > source tree. Multiple distributions for a project as small as Proxool
> > seems uneccecary complex.
>
> But small is beautiful, right? Okay, I agree. java-ext will disappear.

Maybe this is also the time to factor out some sub-packages like
org.logicalcobwebs.proxool.delegate, org.logicalcobwebs.proxool.driver and
org.logicalcobwebs.proxool.configuration? This would break backwards
compatibility. Is this acceptable? It might suggest that we move the project
status from 'production/stable' to 'alpha'. I think this would be fitting.
As I said before: Even though the core is stable I think there's a few
wrinkles we need to iron out before the project is solid.

Could I also suggest a rename of VirtoolDriver? It's a cool sounding name,
but it doesen't say much about what the class actually is.
In fact, I don't really know what it is even after looking at the code and
JavaDoc ;)
It's unfinished non? Is it meant just to be a load balancer, or should it
support various switching scheemes (like switching at certain times, or
after a certain number of usages)?

> > The website only documents
> > the programmatic configuration of the driver.
>
> Yeah, that's just what Bruce said. There are two outstanding tasks that
> cover this. Actually, both configurators are untested. We also have a
> partially written AvalonConfigurator but I haven't looked at that
> recently. Certainly PropertyConfigurator and XMLConfigurator should be
> finished before 0.6 (tests and documentation).

I can have a go at the configration stuff (tasks 63172 and 63149).

CHR

Re: [Proxool-developer] configuration via properties file

[Bill H. <bi...@lo...>]

On Tue, 2002-12-10 at 21:05, Christian Nedregaard wrote:

> Just including the XMLConfigurator (and all other configurators that 
> depend on external libraries) in the binary dist would not create a 
> dependency. The dependency will only occur when somebody tries to *use* 
> these Configurators. If somebody is content using the PropertyConfigurator 
> they can use Proxool without including any external libraries.

I just tested that. It works. Cool. I think you've told me that before.
Sigh.

> By the way: The XMLConfigurator does not have any dependency on JAXP, 
> only SAX. I guess we ought to write a JAXP subclass that takes care of 
> parser instaniation etc and offers a couple of "configure" methods like 
> PropertyConfigurator. 

Looks like you just talked your way into a job :)

Does it have to be a sub-class? Couldn't you have a JAXPConfigurator
that *uses* the XMLConfigurator? But I don't know much about JAXP. 

> Unless my previous assumtion was wrong I'd like to propose the oposite: 

Why assume when you can test? :)

> Move all the "ext" classes into Proxool proper, and remove the "ext" 
> source tree. Multiple distributions for a project as small as Proxool 
> seems uneccecary complex. 

But small is beautiful, right? Okay, I agree. java-ext will disappear.

> The website only documents 
> the programmatic configuration of the driver.

Yeah, that's just what Bruce said. There are two outstanding tasks that
cover this. Actually, both configurators are untested. We also have a
partially written AvalonConfigurator but I haven't looked at that
recently. Certainly PropertyConfigurator and XMLConfigurator should be
finished before 0.6 (tests and documentation).

Bill

Re: [Proxool-developer] JDK 1.2

[Christian N. <chr...@em...>]

Bill Horsman wrote:
> What do people think about dropping 1.2 support? Or, alternatively,
> fully testing Proxool 0.5 against JDK 1.2 and then just letting 1.2
> users use that one (and requiring JDK 1.3+ for Proxool 0.6)?

This has been a big issue on the Ant dev list for months, only they are discussing dropping support for JDK 1.1 ;)

The general sentiment there seems to be that it's ok to drop the support for the old JDK as long as the users of old JDKs have access to a stable release version (in this case Ant 1.5) that is forked out and maintained for bugs.

I think we should adopt the same attitude. However I don't feel that Proxool 0.5 is sufficiently mature to be that "stable release version". The core functionality is certantly mature and stable, but I feel we need to iron out a few wrinkles concerning configuration/re-configuration and documentation before we cut off the 1.2 users. Could we keep the 1.2 support up to and including the Proxool 1.0 release, and then fork off a maintenace branch for 1.2?



CHR

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

One click access to the Top Search Engines
http://www.exactsearchbar.com/mailcom

Re: [Proxool-developer] configuration via properties file

[Christian N. <chr...@em...>]

> Bill Horsman wrote:
> > Does anyone have any thoughts of whether we should include the
> > XMLConfigurator in the binary distribution? Doing so would mean a
> > dependence for everyone on JAXP and a compliant parser. 

Just including the XMLConfigurator (and all other configurators that depend on external libraries) in the binary dist would not create a dependency. The dependency will only occur when somebody tries to *use* these Configurators. If somebody is content using the PropertyConfigurator they can use Proxool without including any external libraries.

By the way: The XMLConfigurator does not have any dependency on JAXP, only SAX. I guess we ought to write a JAXP subclass that takes care of parser instaniation etc and offers a couple of "configure" methods like PropertyConfigurator. 

> Bas wrote:
> I'd like to propose the distribution of 2 jars: one that contains the 
> basic proxool driver and another that contains your convenience classes. 
> That'll make things conveniently arranged.

Unless my previous assumtion was wrong I'd like to propose the oposite: 

Move all the "ext" classes into Proxool proper, and remove the "ext" source tree. Multiple distributions for a project as small as Proxool seems uneccecary complex. As stated above this will not create any problems for users of the binary dist that don't want to use the configurators with external dependencies. Of cource these dependecies needs to be properly documented so that users would know what libs to include if they want to use those configurators. It seems like we need to upgrade the doc on configuration anyway. The website only documents the programmatic configuration of the driver.

CHR




-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

One click access to the Top Search Engines
http://www.exactsearchbar.com/mailcom