DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38950>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38950 ------- Additional Comments From [EMAIL PROTECTED] 2006-04-27 17:07 ------- (In reply to comment #3) > Reading the comments it is obvious to me that it is thought that using > background threads is a bad thing. A servlet container is not the same as a desktop application, this makes the approach to the problem different. If you play by some realistic rules background threads are no longer a bad thing, I have web-app with ~20 HTTP client thread workers and ~40 other threads. > This problem is occuring right when I start the thread, we are not here > talking > about something that happens when a servlet is being reloaded or tomcat is > being shut down. So while the particular http request that started the > thread > may have gone away, the servlet itself is still alive (that is init has run, > and destroy had not been called). This supprises me. If I understand correctly you are saying you start up TC and deploy the web-app (for the first time). Then as soon as you create your background thread that starts using the JDBC driver you get PhantomReference you get ThreadDeath's. Can you explain the "PhantomReference" concept to the technically naive ? I can only suggest trying another approach. The lifecycle of the attached example works differently, it does not use a Servlet#init() method. It would be possible to adapt the example so that a #init() can kick-start the thread (if you dont want it automatically started at web-app startup). But if you are using #init() are you also using #destroy() to shutdown the thread ? And have you confirmed TC is calling #destroy() when you expect ? Maybe using the Servlet lifecycle is not actually the best solution for you anyway, it relies on a request coming in or you to load-on-startup to get going. > The JDBC driver is in the WebApp WEB-INF/lib directory, although it makes no > difference to the problem if it is in the common/lib directory. Okay this point confirms that you are creating your own JDBC connection and not using a container mananged one, as for a container managed one to work you must make the driver JAR visible to TC. May I suggest you look at the META-INF/context.xml file (in attached WAR) and copy/adapt it into your own project and pickup a container managed connection. This may address the PhantomReferences problem within the JDBC driver. > The particular function I am doing here is a request queue, to remote servers > which may or may not be available. ...SNIP... Yes this is a trivial problem to address under TC as a background thread, once programmed correctly. Please take a look and fully understand the attached example of background thread control under a servlet container. Please close this report if no underlying bug exists. I'd also suggest upgrading from 5.5.9 if you can, this was a particular bad version in my experience. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
