Re: Session restart replication when using jsvc
Thanks Bill! I checked out the latest sources from CVS and now it works correctly. Thanks also to Wade for lots of good input. Regards Trond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session restart replication when using jsvc
Bill Barker wrote: This is the old, buggy, code that ships with Tomcat. You need to get the code from commons-daemon CVS HEAD if you want shutdowns (and restarts) to work properly. Bill, Just thinking ahead to the next 4.1.x release - do you know if there is a commons-daemon release that includes the necessary fixes or does it have to be CVS head? Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session restart replication when using jsvc
Mark Thomas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: This is the old, buggy, code that ships with Tomcat. You need to get the code from commons-daemon CVS HEAD if you want shutdowns (and restarts) to work properly. Bill, Just thinking ahead to the next 4.1.x release - do you know if there is a commons-daemon release that includes the necessary fixes or does it have to be CVS head? There has only been the c-d 1.0 release, so, yes, it has to be CVS HEAD. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session restart replication when using jsvc
Hi all! I recently switched from using Tomcat 5.0.28/jk2/Apache2 to running tomcat standalone using jsvc. This works great for me except for one thing; Sessions are not replicated when I restart tomcat. To stop Tomcat I'm using 'kill -9 `cat /var/run/jsvc.pid`'. When Tomcat is stopped this way the StandardManager does not serialize the sessions to SESSIONS.ser. Can I stop Tomcat in another way, to make it serialize the sessions? Do I have to use a PersistentManager? Write my own manager? Regards Trond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session restart replication when using jsvc
Trond G. Ziarkowski wrote: I recently switched from using Tomcat 5.0.28/jk2/Apache2 to running tomcat standalone using jsvc. This works great for me except for one thing; Sessions are not replicated when I restart tomcat. To stop Tomcat I'm using 'kill -9 `cat /var/run/jsvc.pid`'. When Tomcat is stopped this way the StandardManager does not serialize the sessions to SESSIONS.ser. Can I stop Tomcat in another way, to make it serialize the sessions? Hi Trond, by using signal 9 you give Tomcat no chance to perform any further action. Maybe you omit -9 from your kill command. Kind regards, Wolfgang - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session restart replication when using jsvc
Hi Wolfgang! by using signal 9 you give Tomcat no chance to perform any further action. Maybe you omit -9 from your kill command. Thanks for the tip. Tried it, but same results. Trond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session restart replication when using jsvc
Trond G. Ziarkowski wrote:
Hi Wolfgang!
by using signal 9 you give Tomcat no chance to perform any further
action. Maybe you omit -9 from your kill command.
Thanks for the tip. Tried it, but same results.
Trond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hmmm. Here is the source code of the jsvc-unix.c which is called upon a
signal.
static void handler(int sig) {
switch (sig) {
case SIGTERM: {
log_debug(Caught SIGTERM: Scheduling a shutdown);
if (stopping==true) {
log_error(Shutdown or reload already scheduled);
} else {
stopping=true;
}
if (handler_trm!=NULL) (*handler_trm)(sig);
break;
}
case SIGINT: {
log_debug(Caught SIGINT: Scheduling a shutdown);
if (stopping==true) {
log_error(Shutdown or reload already scheduled);
} else {
stopping=true;
}
if (handler_int!=NULL) (*handler_int)(sig);
break;
}
case SIGHUP: {
log_debug(Caught SIGHUP: Scheduling a reload);
if (stopping==true) {
log_error(Shutdown or reload already scheduled);
} else {
stopping=true;
doreload=true;
}
if (handler_hup!=NULL) (*handler_hup)(sig);
break;
}
default: {
log_debug(Caught unknown signal %d,sig);
break;
}
}
}
So, from the text I would assume SIGINT and SIGTERM should perform the
same shutdown behavior, but you can try to use
kill -s SIGTERM pid
or
kill -s SIGINT pid
and see what results you get. If it isn't behaving correctly then you
need to maybe
1) You might want to make sure you don't have the serialization of
session turned off some how...is it behaving correctly if you don't use
jsvc?
2) You are using the right tomcat class to start it up...surely or you
should get an errorI would imagine anywaysso maybe forget
this altogether.
3) You might want to search the tomcat source code for the Daemon
implementer class and locate the method stop to see if you can figure
out if it is being called. It should be I would imagine since tomcat is
stopping, but if it is not, then I guess it's a Daemon/jsvc error and
you need to talk to that list. On another note same subject.You can
look in the daemon src at the file /src/native/unix/native/java.c and
you could put some code into the java_stop function to see if you can
figure out if the function is going to call (through jni) the Daemon
stop method correctly or not. REMEMBER: The Daemon startup code does
not force the class used as a Daemon to actually implemnt the interface
through source code, but the class can simply have the correct
methods.only know this because of the source code not any
docsdon't know if Tomcat does this or not.
4) You might look in your jsvc error file...where ever you have put it
and look for the text 'Cannot stop daemon' or 'Cannot found Daemon
Loader stop entry point'that mis type of Cannot foundis really
in the logging of the 1.0 release source code. Because even though you
get this text and tomcat goes awaythe method to stop may not have
been found and the jsvc process is going to kill the JVM anyways.
Hope some of that helps
Wade
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session restart replication when using jsvc
This is the old, buggy, code that ships with Tomcat. You need to get the
code from commons-daemon CVS HEAD if you want shutdowns (and restarts) to
work properly.
Wade Chandler [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Trond G. Ziarkowski wrote:
Hi Wolfgang!
by using signal 9 you give Tomcat no chance to perform any further
action. Maybe you omit -9 from your kill command.
Thanks for the tip. Tried it, but same results.
Trond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hmmm. Here is the source code of the jsvc-unix.c which is called upon a
signal.
static void handler(int sig) {
switch (sig) {
case SIGTERM: {
log_debug(Caught SIGTERM: Scheduling a shutdown);
if (stopping==true) {
log_error(Shutdown or reload already scheduled);
} else {
stopping=true;
}
if (handler_trm!=NULL) (*handler_trm)(sig);
break;
}
case SIGINT: {
log_debug(Caught SIGINT: Scheduling a shutdown);
if (stopping==true) {
log_error(Shutdown or reload already scheduled);
} else {
stopping=true;
}
if (handler_int!=NULL) (*handler_int)(sig);
break;
}
case SIGHUP: {
log_debug(Caught SIGHUP: Scheduling a reload);
if (stopping==true) {
log_error(Shutdown or reload already scheduled);
} else {
stopping=true;
doreload=true;
}
if (handler_hup!=NULL) (*handler_hup)(sig);
break;
}
default: {
log_debug(Caught unknown signal %d,sig);
break;
}
}
}
So, from the text I would assume SIGINT and SIGTERM should perform the
same shutdown behavior, but you can try to use
kill -s SIGTERM pid
or
kill -s SIGINT pid
and see what results you get. If it isn't behaving correctly then you
need to maybe
1) You might want to make sure you don't have the serialization of session
turned off some how...is it behaving correctly if you don't use jsvc?
2) You are using the right tomcat class to start it up...surely or you
should get an errorI would imagine anywaysso maybe forget
this altogether.
3) You might want to search the tomcat source code for the Daemon
implementer class and locate the method stop to see if you can figure out
if it is being called. It should be I would imagine since tomcat is
stopping, but if it is not, then I guess it's a Daemon/jsvc error and you
need to talk to that list. On another note same subject.You can look
in the daemon src at the file /src/native/unix/native/java.c and you
could put some code into the java_stop function to see if you can figure
out if the function is going to call (through jni) the Daemon stop method
correctly or not. REMEMBER: The Daemon startup code does not force the
class used as a Daemon to actually implemnt the interface through source
code, but the class can simply have the correct methods.only know this
because of the source code not any docsdon't know if Tomcat does this
or not.
4) You might look in your jsvc error file...where ever you have put it and
look for the text 'Cannot stop daemon' or 'Cannot found Daemon Loader
stop entry point'that mis type of Cannot foundis really in the
logging of the 1.0 release source code. Because even though you get this
text and tomcat goes awaythe method to stop may not have been found
and the jsvc process is going to kill the JVM anyways.
Hope some of that helps
Wade
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
