function call hanging - Bizarre!
My web application is equipped with a ServletContextListener. Among other
things the contextIntialized() method creates and starts a server object which
has as one of it's data members an object that inherits from
UnicastRemoteObject (the basic Java RMI server implementation).
conextDestroyed() is supposed to shut my server object down, but my shutdown
procedure is hanging in a seemingly impossible way. Here's the basic structure
of the server I'm trying to shutdown:
public class MyServer
{
MyRemoteServer r;
// bla, bla, bla
public class MyRemoteServer extends UnicastRemoteObject implements
MyRemoteInterface
{
// bla, bla, bla
public void stop()
{
System.out.println(PRINT #2);
// bla, bla, bla
}
}
public void stop()
{
// bla, bla, bla
if(r != null)
{
System.out.println(PRINT #1);
r.stop();
}
}
}
Invocation of MyServer.stop() is not returning. The confounding thing is that
I see PRINT #1 in catalina.out, but NOT PRINT #2.
Some things to note:
I'm running Tomcat 5.024 on Fedora 2.x
I can startup and shtudown MyServer without error when I run it from a
command-line java application -- I only hit the weird hang when running from
within tomcat.
Neither stop() method is synchronized, so I don't see how this could have
anything to do with thread locks. (There are other methods on both of these
objects that are synchronized, but these are not.)
I've verified that UnicastRemoteObject does NOT have it's own stop method
that I'm overriding to some ill end. In fact I changed the name of
MyRemoteServer.stop() to MyRemoteServer.doStop() just to make sure I wasn't
getting hammered by some subtle function override behavior that I'm too stupid
to fathom.
It's not obvious that the problem has anything to do with RMI, but that is
one unusual property of the inner class MyRemoteServer so I mention it.
So what on God's green Earth could cause a non-synchronous method call to hang
before the first line of that method is executed? Could a corrupt object
pointer explain this behavior? I haven't tried printing out the addresses of
the myRemoteServer object at startup and shutdown -- perhaps that would reveal
something.
Much appreciation to any genius who can propose a theory as to what's going on.
Matt
-
Do You Yahoo!?
Yahoo! Small Business - Try our new Resources site!
test
Why can't I post? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: test
Sorry my first attempt sent me backa message saying I wasn't a member. Though now I see that that message was sent to me via tomcat-user as well. I'm not sure why I got the error message. Sorry for the tripe. David Short [EMAIL PROTECTED] wrote:You just did. -Original Message- From: TK Banks [mailto:[EMAIL PROTECTED] Sent: Friday, May 27, 2005 4:52 PM To: tomcat-user@jakarta.apache.org Subject: test Why can't I post? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do You Yahoo!? Yahoo! Small Business - Try our new Resources site!
I want mutliple host names but just one context
We've set up multiple DNS entries for the same box. a.foo.com b.foo.com We've got Apache's workers2.properties files setup to forward all requests to these two machine names to tomcat: [uri:a.foo.com/*] group=lb [uri:b.foo.com/*] group=lb Now what we want is for tomcat to map requests sent to a.foo.com to directory: .../tomcat/webapps/killerApp/a and likewise map requests sent to b.foo.com to directory: .../tomcat/webapps/killerApp/b Actually, this much we can do using virtual hosts, but if we do that, then we get different application contexts for a and for b. Instead we want just one context so we can share memory between the two. If such a thing were possible, the WEB-INF directory, I presume, would be at: .../tomcat/webapps/killerApp/WEB-INF Is there a way to achieve what we desire? __ Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help me off this list!
No matter how many times I send mail to [EMAIL PROTECTED] I continue to be flooded with tomcat-user mail. Months ago I wanted to post a question to this list and found I couldn't do so unless I joined the list. So, grudgingly, I joined, posted my question and immediately unsubscribed. I checked my mail again days later to find I had gazillions of emails queued up. Since that time I've been periodically sending requests to unsubscribe and have had no success. Was there some fine print I missed that said I had to join for at least a year? __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Killing threads during context restart
I have a background thread object in my tomcat application that performs some garbage-collection like functions (i.e., wakes up periodically and does some application specific cleanup). I have tomcat configured to restart the context when I drop new class files in the WEB-INF/classes directory. Recently I have discovered multiple copies of my these background threads running simultaneously. Further investigation has shown that I get an additional copy with each context restart. I guess I don't even know what a context is, but I assumed that a context restart would kill off all application threads. How am I supposed to get all my application threads to die when the context restarts? Checking instance variables don't work since the data from the old context and the new does not appear to be shared. Thanks much, Matt __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killing threads during context restart
Thanks all. I have the threads dying cleanly now. --- Filip Hanik - Dev [EMAIL PROTECTED] wrote: you can setup context listeners, and when the context is stopped you will receive an event and can stop your bg thread Filip - Original Message - From: TK Banks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 4:40 PM Subject: Killing threads during context restart I have a background thread object in my tomcat application that performs some garbage-collection like functions (i.e., wakes up periodically and does some application specific cleanup). I have tomcat configured to restart the context when I drop new class files in the WEB-INF/classes directory. Recently I have discovered multiple copies of my these background threads running simultaneously. Further investigation has shown that I get an additional copy with each context restart. I guess I don't even know what a context is, but I assumed that a context restart would kill off all application threads. How am I supposed to get all my application threads to die when the context restarts? Checking instance variables don't work since the data from the old context and the new does not appear to be shared. Thanks much, Matt __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
