Menu
▾
▴
proxool-developer
|
From: Bill H. <bi...@lo...> - 2003-02-04 12:21:56
|
Hi all, There has been a lot of activity on bug 673073 recently. It's all to do with finalization of the house keeper and prototyper threads when the application ends. This is the transcript: --- Date: 2003-01-23 13:41 Sender: trex Logged In: YES user_id=44856 First I must to say that the implementation of this pool is very robust and high quality. However I have encountered the following problems using the pool. Connection c = DriverManager.getConnection( "proxool.alias:sun.jdbc.odbc.JdbcOdbcDriver:jdbc:odbc:test","",""); md = c.getMetaData(); // using metadata // getting the connection back to the pool md.getConnection().close() //!!!!!!!!!!!!!!!!!!!!!!!!!!!!! the line above will not bring the connection up to the pool. It just closes it messing the stuff. I know it is always possible to avoid this. Finally, I have solved this problem but the listening to the real connection state would be really nice feature to have. I mean if the pool would be able to listen to the connection state and prevent it from misusinng. Andrew S. Budarevsky --- Date: 2003-01-24 10:06 Sender: billhorsman Logged In: YES user_id=91747 Andrew, Hmm, that's interesting. I see the problem, but I'm not sure of the best way to solve it. I think the only way is to proxy the DatabaseMetaData object and override the getConnection() method. The problem is that the Connection interface doesn't provide any hooks with which to listen to a connection. Hmm. I will add a FAQ describing this problem and schedule a task to fix this. Thanks for spotting such an obscure problem! Regards, Bill --- Date: 2003-01-31 17:47 Sender: billhorsman Logged In: YES user_id=91747 I have fixed this by proxying DatabaseMetaData too. It is will be in version 0.7 (due February 5th) or you can get the latest from CVS. --- Date: 2003-02-03 12:38 Sender: trex Logged In: YES user_id=44856 Hello Bill! Good work! Though I won't change my framework to apply the newest stuff for awhile I would suject that it might help to anybody else. What I wanted to tell you more is that it seems the pool does not let application quit by means of holding a running thread. But I am not sure yet. At the moment I have System.exit executed on QUIT event. Within few days I am going to check that and inform you as soon as I have something to tell you for sure. Andrew --- Date: 2003-02-03 17:06 Sender: billhorsman Logged In: YES user_id=91747 Hi Andrew, You should call ProxoolFacade.removeAllConnectionPools(delay) when you quit. This will close all connections gracefully and kill all the threads that are running. We can't think of a way of ensuring this happens automatically. The delay is the amount of time (milliseconds) that you are prepared to wait for connections to stop being active before closing them anyway. Hope this helps, Bill --- Date: 2003-02-04 10:20 Sender: trex Logged In: YES user_id=44856 Hello Bill! Thank you for the advising. It is worth. However I would say that it breaks the general concept of proxool to be a transparent driver's proxy. I know it happens due to leak of virtual machine state events. Oops... What about a finalize method? Could it be possible to close pools on finalizing? I can explain why I am so concerned of the trasparency. I am working on a framework that manages application data flows, called streams. Database is one of data sources. In my case the data source is not a driver of database or similar. It could be something very very abstract entity resembling data source behaviour. I don't think I even need to have a method closing the end point. I would prefer to rely on system-wide finalization in case of Java. It's not requirement, it's a feature. Few years ago I have implemented a pool of tcp connections resided on servlet and connected to application server. I don't remeber but it seems I closed connections by means of overriding finalize method. What would you say? Andrew. --- Date: 2003-02-04 12:14 Sender: billhorsman Logged In: YES user_id=91747 Hi Andrew, I take your point. I don't like having code call the Proxool API directly. I would really like to come up with a transparent solution to this. Actually, Proxool already overrides the finalize method, but in my experience this doesn't always get called. I suspect that calling System.exit() means that it doesn't get called. We really need to do some more investigation into this to determine exactly what circumstances cause what behaviour. I think we need to read the specs a bit more closely and then do some testing. It would be nice to know exactly what the problem is. We have not found any robust way of determining when the application has ended. Any suggestions are welcome. --- I have suggested to Andrew that he continues this discussion on this list so that we can all get involved. Regards, -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Bas C. <ba...@ci...> - 2003-02-04 15:37:54
|
Bill Horsman wrote: > We have not found any robust way of determining when the application has > ended. Any suggestions are welcome. Runtime.addShutdownHook() is the key (JRE 1.3+). Shutdown hooks are always executed by the VM, no matter how it exits. The only drawback is an extra permission when the app is forked: permission java.lang.RuntimePermission "shutdownHooks"; According to the discussions at the JDC it is never guaranteed that the VM executes finalize(), whereas it is for shutdown hooks - I confirm this by my own practice. Kind regards, Bas -- Bas Cancrinus -> ba...@ci... Software Architect Cipherware Ltd. -> http://www.cipherware.com |
|
From: Martin C. <mus...@us...> - 2003-02-04 15:50:26
|
On Tue, 2003-02-04 at 10:36, Bas Cancrinus wrote: > Bill Horsman wrote: > > We have not found any robust way of determining when the application has > > ended. Any suggestions are welcome. > > Runtime.addShutdownHook() is the key (JRE 1.3+). Shutdown hooks are > always executed by the VM, no matter how it exits. The only drawback is > an extra permission when the app is forked: > > permission java.lang.RuntimePermission "shutdownHooks"; > > According to the discussions at the JDC it is never guaranteed that the > VM executes finalize(), whereas it is for shutdown hooks - I confirm > this by my own practice. A few notes: 1- Not all VM implementations apparently support the shutdownHook properly. I do not have any solid evidence to this available, but this is what I know I've read in places before. 2- http://java.sun.com/j2se/1.4.1/docs/guide/lang/hook-design.html Is a good place to look at. 3- Perhaps for versions -1.3 to use this Runtime.runFinalizersOnExit Martin |
|
From: Bill H. <bi...@lo...> - 2003-02-04 17:17:13
|
Hi all,
A further twist: my tests with Tomcat show that the ShutdownHook works
fine when you shutdown Tomcat. But if you simply touch the web.xml this
causes the application to be restarted. The Servlet's destroy() method
is called but not the ShutdownHook (which is as you might expect since
the JVM isn't shutting down).
As a consequence, it might make sense, for some people to use:
public void destroy() {
ProxoolFacade.removeAllConnectionPools(0);
}
as well.
Fortunately, when you do eventually shutdown Tomcat then all the hooks
are run so everything is eventually cleaned up. The only problem is that
you might have more pools running than you think.
> 1- Not all VM implementations apparently support the shutdownHook
> properly. I do not have any solid evidence to this available, but this
> is what I know I've read in places before.
Maybe it is a FAQ. Q. "I have stopped my application but Proxool keeps
running". A. "Shutdown manually."
> 3- Perhaps for versions -1.3 to use this Runtime.runFinalizersOnExit
But it's deprecated because it is unsafe. We *could* do that, or we
could just advise JDK < 1.3 users to finalize manually.
--
Bill Horsman
Proxool
http://proxool.sourceforge.net
ICQ: 119577180
|
|
From: <chr...@em...> - 2003-02-04 22:11:51
|
We should not depend on finalizers at all. As you have mentioned it might
never get called, and if it does get called you don't have any control in
wich order they are called.
The 1.3+ code should implement the shutdown hook. People that use a JVM that
does not implement the hook properly will just have to live with the unclean
shutdown I guess :( Both the housekeeper thread and the prototyping thread
are run as daemons so they should not cause any additional problems on
shutdown.
The real problem is shutting down the pool on application reloads. Our
current implementation of this has been proved to be very unpredicable, so I
think we need to document *very clearly* that all applications that expect
to be reloaded must shutdown proxool in some kind of container spesific
manner. As you mention, Servlet.destroy() is a good place to do this in a
servlet container. Most other environments will hopefully also provide
something similar (like Disposable.dispose() in a Avalon container).
We also need to be sure that shutting down Proxool several times in a row
does not cause problems. In a servlet container for example,
Servlet.destroy() will shutdown Proxool first, and then the shutdown hook
will do it again.
CHR
> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of Bill
> Horsman
> Sent: 04 February 2003 18:17
> To: Proxool Developer List
> Subject: Re: [Proxool-developer] Bug 673073
>
>
> Hi all,
>
> A further twist: my tests with Tomcat show that the ShutdownHook works
> fine when you shutdown Tomcat. But if you simply touch the web.xml this
> causes the application to be restarted. The Servlet's destroy() method
> is called but not the ShutdownHook (which is as you might expect since
> the JVM isn't shutting down).
>
> As a consequence, it might make sense, for some people to use:
>
> public void destroy() {
> ProxoolFacade.removeAllConnectionPools(0);
> }
>
> as well.
>
> Fortunately, when you do eventually shutdown Tomcat then all the hooks
> are run so everything is eventually cleaned up. The only problem is that
> you might have more pools running than you think.
>
> > 1- Not all VM implementations apparently support the shutdownHook
> > properly. I do not have any solid evidence to this available, but this
> > is what I know I've read in places before.
>
> Maybe it is a FAQ. Q. "I have stopped my application but Proxool keeps
> running". A. "Shutdown manually."
>
> > 3- Perhaps for versions -1.3 to use this Runtime.runFinalizersOnExit
>
> But it's deprecated because it is unsafe. We *could* do that, or we
> could just advise JDK < 1.3 users to finalize manually.
>
> --
> Bill Horsman
> Proxool
> http://proxool.sourceforge.net
> ICQ: 119577180
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
|
|
From: Bill H. <bi...@lo...> - 2003-02-04 23:08:51
|
On Tue, 2003-02-04 at 22:10, Christian Nedregård wrote: > We should not depend on finalizers at all. We don't. The finalizer call the "shutdown code", as does the ShutdownHook, as does ProxoolFacade.removeAllConnectionPools. > People that use a JVM that does not implement the hook properly will > just have to live with the unclean shutdown I guess :( Yep. > Both the housekeeper thread and the prototyping thread are run as > daemons so they should not cause any additional problems on shutdown. There's also a Monitor thread that logs statistics (if you configure some statistics). But that's a daemon too, I just thought I'd mention it for completeness. > The real problem is shutting down the pool on application reloads. Yes, we need to be clear about that. It is *almost* a separate problem. > We also need to be sure that shutting down Proxool several times in a row > does not cause problems. In a servlet container for example, > Servlet.destroy() will shutdown Proxool first, and then the shutdown hook > will do it again. It copes with that. You get a short debug message in the log saying something like "Ignoring duplicate attempt to shutdown pool". -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Martin C. <mus...@us...> - 2003-02-05 02:13:00
|
> The real problem is shutting down the pool on application reloads. Our > current implementation of this has been proved to be very unpredicable, so I > think we need to document *very clearly* that all applications that expect > to be reloaded must shutdown proxool in some kind of container spesific > manner. As you mention, Servlet.destroy() is a good place to do this in a > servlet container. Most other environments will hopefully also provide > something similar (like Disposable.dispose() in a Avalon container). I know, I've stated my thoughts on this before, but again I'll restate it: Proxool should not be installed at an individual web application level, but at the common classloader level. You want one instance of proxool per VM to ensure the Singleton pattern is enforced. By deploying the JAR with each individual application, you end up creating multiple instances of the Proxool framework. Thus breaking the Singleton pattern. Imagine a Servlet container connecting to the same database for several different web applications. You would not benefit from the beauty of managing your pools efficiently across all applications. Additionally, of course, you break the transparency by forcing Servlet developers to write proxool specific code within their Servlet application. And which Servlet would I write this "destroy" code if my web application has multiple Servlets? Proxool is most effective because of its transparency, I say we should foster this transparency. My 0.5 cents (Canadian dollar isn't doing to well) Martin |
|
From: Bill H. <bi...@lo...> - 2003-02-05 10:07:01
|
On Wed, 2003-02-05 at 02:12, Martin Crawford wrote: > You want one instance of proxool per VM to ensure the Singleton pattern > is enforced. By deploying the JAR with each individual application, you > end up creating multiple instances of the Proxool framework. Thus > breaking the Singleton pattern. > > Imagine a Servlet container connecting to the same database for several > different web applications. You would not benefit from the beauty of > managing your pools efficiently across all applications. We should definitely document that sort of behaviour. I just tried to test that out but came across some class loading problems with the commons-logging (I'm using Tomcat 4.1.18). Martin, have you got this working? Does it behave as expected (on application reload)? -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
|
From: Bill H. <bi...@lo...> - 2003-02-05 10:11:49
|
On Wed, 2003-02-05 at 02:12, Martin Crawford wrote: > And which Servlet would I write this "destroy" code if my > web application has multiple Servlets? Well... you could shutdown each pool individually. But I agree that that is a bit cumbersome. I only mention it as a possible solution. > Proxool is most effective because of its transparency, I say > we should foster this transparency. Absolutely. It might even make us unique? The question is, how to combine the ease of use of the XML configurators and potentially useful things like statistics whilst still retaining transparency? Is it one or the other? You either have a transparent pool with no advanced stuff, or you make a dependency on Proxool and get to use all the "bells and whistles". I mean, we should cater for both scenarios and leave it up to the user to choose. > My 0.5 cents (Canadian dollar isn't doing to well) You can spend you dollars here anytime, Martin. -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |
Thanks for helping keep SourceForge clean.
X