I guess that didn't come out right. What I meant was that I wrote the monitor, so I am very familiar with how the monitor works.
On Fri, 2003-10-10 at 09:51, Sasvata (Shash) Chatterjee wrote: > Phil, > > >I do know (because I wrote the code) that the keel direct server is > >waiting for a request to come across on one of the "channels" that it > >monitors. This is a blocking operation, meaning that the keeldirect > >server thread will not execute any other code until it gets a message... > >it just sits and waits for a message. > > > > > > > This is true, KeelDirectServer is in a blocking receive in one of Doug > Lea's concurrent classes. I tried marking the thread as a daemon using > setDaemon(true), so in theory the finalizer thread should not wait for > KeelDirectServer to exit. But there were other Fortress threads, using > TPCThreadManager that were waiting around. I think the cleanest way > would be to use the context shutdown hook, and then to call dispose on > the container properly. > > >I wrote the "monitor for keel direct server" which is a class that will > >check a specified thread every five seconds to see if the thread is > >still alive. When the thread that the monitor is watching finally dies, > >the monitor calls a method inside keelDirectServer to tell the server > >that it's time to quit. Then the monitor puts a message on the channels > >queue so that the keelDirectServer thread can start running again, and > >realize that it's time for it to die. > > > > > I think if we make the changes above this will not be needed. But, as > it is, this should work for the direct-server thread. Problem is that > there are other hung threads as well. > > >The thread that is watched by this monitor can be configured in your > >web.xml file. I configure it to "watch" the context that I am running > >keel out of... this way, if I use the tomcat manager pages, I can > >restart my web context without restarting the whole tomcat server, and > >keel will detect that the context has died and cause keel to die as > >well. > > > >Specifically, the entry in web.xml reads: > > > > <context-param> > > <param-name>keel.monitor.context</param-name> > > <param-value>struts</param-value> > > </context-param> > > > >gives the name of a substring to look for when searching for the process > >to monitor. > > > > > > > The version in 2.0, is not the same, if I remember correctly. It's hard > coded to look for the "bdc" context. > > >Santanu is going to be working on the code for the 1.0 branch this > >weekend to make the keel direct server in the 1.0 branch multi-threaded, > >so if the problem is only occurring in the 1.0 branch, then we should > >wait for Santanu's refactoring and see if that fixes it. > > > > > > > Sounds good, lets wait for Eric and Santanu to finish the thread > changes, and we'll see where we end up. > > >I would assume that this problem also occurs in the "head" from CVS... > >is that correct? > > > > > True > > >If it is the monitor that is causing problems, we could try rewriting > >the code that deals with the monitor. Specifically, I was reading about > >multi-threaded programming and thread locking. > > > >It seems that using thread locks(and the thread.notifyAll() method), we > >could achieve the same result as the monitor, but we would be using > >lower-level native java features instead of a higher-level, home grown > >monitor. > > > > > > > If dispose() doesn't take care of it, then I agree this would be a > nicer, more generic solution. > > >Another thought is that we could create a ServletContextListener that > >kills the keelDirectServer when the context stops. This context > >listener would be used instead of the monitorForKeelDirectServer. In > >fact, I must confess that when I wrote the monitor, I wasn't aware of > >ServletContextListener interface, otherwise I might have used it. > > > > > > > I Like this the best. We also need to do similar things from when Junit > tests fire up and shutdown the container. > > Shash > > http://keelframework.org/documentation > Keelgroup mailing list > [EMAIL PROTECTED] > http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com > http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
