Not sure about this one.
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 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.
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.
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...
is that correct?
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.
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.
Sash, Mike or Steve,
Any thoughts on this, or does my explanation help rule anything out
or provide some likely suspects of what might be causing the problem?
-Phil
On Sat, 2003-10-04 at 14:40, Shash Chatterjee wrote:
> Phil,
>
> Now that I am lookingfor it, I was able to see the hang with the
> nojms-cocoon + struts webapp.
>
> Attached are the stack (two screenshots, scrolled), threads and monitors
> view from Eclipse.
>
> Shash
>
> > Steve & Phil,
> >
> > I was able to reproduce the thread problem, but just once last night,
> > since then it will not happen.
> >
> > Tomcat did get the shutdown request when it happened and tried to
> > shutdown all the webapps (wathcing the logs in real-time). But
> > KeelDirectServer/AbstractServer was stuck waiting for a monitor. Phil
> > any ideas? I didn't keep the thread dump.
> >
> > When it happened I had all the Keel webapp deploys
> > (nojms-struts/cocoon/velocity, openjms-struts/cocoon/velocity and
> > axis) all present as contexts. I then deleted all but the
> > admin/manager/example webapps and retried and Tomcat shut down
> > properly. Since then I have rebooted the machine. This morning I
> > tried again with the default webapp, but doesn't happen anymore.
> > Steve, can you try a reboot once to see if the condition clears for
> > you. Else, it might have something to do with system load.
> >
> > Something to keep watch on. Until then kill - 9 <pid> works just fine.
> >
> > Shash
> >
> >> Michael Nash wrote:
> >>
> >>> Shash:
> >>>
> >>> I think Phil at Platinum did some work on this, to make the threads
> >>> all shut down correctly. He may be able to shed some light on why
> >>> it's not happening - I've not had it happen myself, at least on a
> >>> few casual attempts.
> >>>
> >>> Mike
> >>>
> >>> On Sat, 04 Oct 2003 10:10:15 -0500
> >>> Shash Chatterjee <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
> >>>> Mike,
> >>>>
> >>>> I am able to reproduce the problem Steve mentioned yesterday, and
> >>>> it has to do with Keel. After getting the direct server to run (by
> >>>> accessing any old model), call Tomcat's shutdown script. Tomcat
> >>>> continues to run. kill -3 pid shows a bunch of threads stuck,
> >>>> further kill -3 do nothing. kill -9 pid, kills it. It is stuck
> >>>> forever somewhere in KeelAbstractServer or KeelDirectServer when I
> >>>> caught it last night.
> >>>>
> >>>> Shash
> >>>>
> >>>
> >
> > Sasvata (Shash) Chatterjee wrote:
> >
> >> Steve,
> >>
> >> I have been running the entire last week on Redhat 9.0 and it works
> >> fine for me. The Solaris problem is that the ports that Tomcat
> >> wanted to use were already in use (both the HTTP port, and the port
> >> it listens on for the shutdown). Are you sure that this is a Keel
> >> issue? Can you run vanilla Tomcat without the Keel contexts and shut
> >> it down properly? That should give some clues, or at least help
> >> isolate the problem.
> >>
> >> Shash
> >>
> >> Stephen Davidson wrote:
> >>
> >>> Hi Shash.
> >>>
> >>> I forgot to mention, I can provide a Thread Dump of the JVM after
> >>> the shutdown command has been issued. It may help in chasing down
> >>> what's hanging. Do you want me to open a bug report on this?
> >>>
> >>> Regards,
> >>> Steve
> >>>
> >>> --
> >>> Java/J2EE Developer/Integrator
> >>> Currently "On the Road"
> >>> 214-724-7741
> >>> Platform Independance Rules.
> >>> Give me a stable platform, and I will give you stable code.
> >>>
> >>> ----- Original Message -----
> >>> From: Stephen Davidson
> >>> Sent: 10/3/2003 8:06:18 AM
> >>> To: [EMAIL PROTECTED]
> >>> Subject: Re: [Keelgroup] Keel nightly build on SourceForge
> >>>
> >>>
> >>>
> >>>> Hi Shash.
> >>>>
> >>>> I have had a problem on my Linux system where Tomcat won't shutdown
> >>>> in Keel. It started early this week. I have to issue a KILL
> >>>> command to Tomcat to kill it. I have been debating opening a Bug
> >>>> Report on it, but have not had the time to actually follow or chase
> >>>> this issue, yet. Looks like SF is having the same problem.
> >>>>
> >>>> If you need access to a Linux system, let me know and I will set
> >>>> you up with an account on my server. Its safely sandboxed, so
> >>>> unless I assign you trusted or root privileges, you won't have
> >>>> access to any secured areas.
> >>>>
> >>>> Also, I have not had the time to set anything up, but if you want
> >>>> to set up an automated job to download, build and test Keel on a
> >>>> Linux platform, let me know. I will be happy to set up the Cron
> >>>> entry to do this. I also don't have a problem with you setting up
> >>>> scripts for any routine type jobs (such as emailing reports).
> >>>> Webserver is also active, if you want to just make the reports
> >>>> available to the web.
> >>>>
> >>>> Regards,
> >>>> Steve
> >>>>
> >>>
> >>>
http://keelframework.org/documentation
Keelgroup mailing list
[EMAIL PROTECTED]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
