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 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.
I wrote the "monitor for keel direct server" which is a class that willI 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.
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.
The version in 2.0, is not the same, if I remember correctly. It's hard coded to look for the "bdc" context.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.
Sounds good, lets wait for Eric and Santanu to finish the thread changes, and we'll see where we end up.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.
I would assume that this problem also occurs in the "head" from CVS...True
is that correct?
If it is the monitor that is causing problems, we could try rewritingIf dispose() doesn't take care of it, then I agree this would be a nicer, more generic solution.
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.
Another thought is that we could create a ServletContextListener thatI Like this the best. We also need to do similar things from when Junit tests fire up and shutdown the container.
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.
Shash
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
