What I mean is that it does not seem to me that it is the app catching the exception and printing to the log but maybe a tomcat thread on the receiving side (does that make sense?).
Would the stack trace be helpful? I will have it available on Monday morning.
Anyway, do you advise to try 5.0.14 for our matters or is it better to stay back on 5.0.12? I have just read about 5.0.14 proving "fairly stable and successful" ;-) (From Y. Shapira, about an hour ago)
Thank you very much.
Antonio Fiol
Filip Hanik wrote:
I can not reproduce the error that you have, although I ran 5.0.14Beta, but the code is the same.
Filip
I created a JSP on my environment, that looks like this.
<% request.getSession().setAttribute("test","test");
%> ok
Tomcat 1 spits out
Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.session.SimpleTcpReplicatio nManager log INFO: writeObject() storing session A8FD8BD50E14477CC57E3EBA6F9591B8 Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.session.SimpleTcpReplicatio nManager log INFO: storing attribute 'test' with value 'test' Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.tcp.ReplicationValve addClu sterSendTime INFO: Average cluster serialize/send time=16 ms for 1 requests (16ms).
Tomcat 2 spits out
Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.session.SimpleTcpReplicatio nManager log INFO: Received SessionMessage of type=SESSION-MODIFIED Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.session.SimpleTcpReplicatio nManager log INFO: Received SessionMessage sender=org.apache.catalina.cluster.mcast.McastMemb er[tcp://10.0.2.76:4001,10.0.2.76,4001] Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.session.SimpleTcpReplicatio nManager log INFO: readObject() loading session A8FD8BD50E14477CC57E3EBA6F9591B8 Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.session.SimpleTcpReplicatio nManager log INFO: loading attribute 'test' with value 'test' Nov 14, 2003 11:12:58 AM org.apache.catalina.cluster.session.SimpleTcpReplicatio nManager log INFO: Received replicated session=ReplicatedSession id=A8FD8BD50E14477CC57E3EBA6 F9591B8 ref=StandardSession[A8FD8BD50E14477CC57E3EBA6F9591B8] name=test; value=test LastAccess=1068837178625
----- Original Message ----- From: "Antonio Fiol Bonnín" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 10:51 AM Subject: Re: Session Replication problems on Tomcat 5.0.12
Sorry. I forgot to mention that the attribute is, in fact, a String. And Strings are, AFAICT, Serializable.
Something like:
String message = "Please use your XYZ user and pass"; session.setAttribute("authMessage", message); // And then redirect to the auth page.
The exception complains about "authMessage" not being Serializable.
Sorry again about being imprecise, and thank you very much for your really fast answer.
Antonio Fiol
Filip Hanik wrote:
serializable.What we get is an exception saying that some attribute is not
webappThis is according to the servlet spec.
All your attributes have to be serializable, if you want to cluster a
Filip ----- Original Message ----- From: "Antonio Fiol Bonnín" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 10:11 AM Subject: Session Replication problems on Tomcat 5.0.12
Hello,
I am having trouble with Tomcat 5.0.12 session replication under the following config:
Apache (mod_ssl+mod_jk): 1 load balancer worker configured to balance among 3 AJP13 workers. 3 Tomcat 5.0.12 servers.
If I use our application on 1 TC5, all goes well. If I start 2 or 3 TC5, I start getting session replication problems. What we get is an exception saying that some attribute is not serializable. (I do not have the logs handy at the moment, as I am writing from home). It happens under load, but it also can happen with very light number of accesses.
It usually appears (on our app) on a page that sets some session attributes and sends a redirect. Then the browser requests the redirected page, and an exception (the one mentioned before) occurs, and the browser is redirected to an error page, after setting some other attribute on the session. The error servlet cannot extract the attributes from the session either.
I have just found a note on http://www.filip.net/tomcat/ saying that there has been some trouble with session replication and mod_jk on TC4. Do you know whether this issue may apply to TC 5.0.12?
I also found a couple of somewhat related bugs, but I am clueless about the degree of relation: the exception did not look the same to me.
I have tried useDirtyFlag="false" just in case there were "dirty kludges" with session management in our app. It did not help.
I am thinking of using 5.0.14. Do you think it might help?
Our setup corresponds closely with the description found on http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html
I am sure I am doing something wrong, but I cannot figure what. I'll be thankful for any advice or pointer to the "right" document or source.
Thank you very much for your help.
Yours,
Antonio Fiol
--------------------------------------------------------------------- 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]
smime.p7s
Description: S/MIME Cryptographic Signature
