Menu
▾
▴
proxool-developer
|
From: Bill H. <bi...@lo...> - 2002-12-11 17:46:41
|
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 |
|
From: Martin C. <mus...@us...> - 2002-12-11 20:37:43
|
> 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
|
|
From: Bill H. <bi...@lo...> - 2002-12-11 23:44:24
|
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 |
|
From: Martin C. <mus...@us...> - 2002-12-12 01:24:59
|
> 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 |
|
From: Bill H. <bi...@lo...> - 2002-12-12 01:20:11
|
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 |
|
From: Bas C. <ba...@ci...> - 2002-12-12 13:00:23
|
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
|
|
From: Bill H. <bi...@lo...> - 2002-12-12 13:23:52
|
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
|
|
From: <chr...@em...> - 2002-12-12 14:35:16
|
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
|
|
From: Martin C. <mar...@sy...> - 2002-12-12 15:04:00
|
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 |
Thanks for helping keep SourceForge clean.
X