I will download it from CVS right now,
Thanks again. Hope it helps solving our problem, but it surely will solve *some* problem.
Antonio Fiol
Filip Hanik wrote:
ok, remember that according to the spec, your passing in null, means remove the previous one, this is the code I added.
if ( value == null ) { removeAttribute(name); return; }
Filip ----- Original Message ----- From: "Filip Hanik" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 1:22 PM Subject: Re: Session Replication problems on Tomcat 5.0.12
you can not do it with session replication, since null doesn't implement java.io.Serializable,
request.getSession().setAttribute("name",null);
I can modify my code to make it work with code like that
----- Original Message ----- From: "Antonio Fiol Bonnín" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 12:26 PM Subject: Re: Session Replication problems on Tomcat 5.0.12
Wait! That's a good one!
I am not sure whether that situation exists or not in the app. In fact, I don't see why it would be there, but...
Can't one store null as a value? Isn't this valid?
request.getSession().setAttribute("name",null);
About storing other classes, about a month ago I went through a thorough check of all our application to ensure that every setAttribute was executed with a Serializable parameter. Maybe one has slipped in since, but I doubt it: the relevant code has been very stable for about two months.
Apart from that, I'm afraid we are not catching the exception. You are giving me a lot of ideas to test on Monday morning.
Thank you very much.
Antonio Fiol
Filip Hanik wrote:
when you get the exception, why don't you actually print out the attributein
class,
maybe you are storing null or another class under the same name elsewhere
butyour app ----- Original Message ----- From: "Antonio Fiol Bonnín" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 11:53 AM Subject: Re: Session Replication problems on Tomcat 5.0.12
Unfortunately, I cannot reproduce the error in a deterministic way. What I know is that it sometimes spits the exception. I use JMeter to stress the server a little bit, and the exception appears in localhost_log (does this help?). The app logs to catalina.out.
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,
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
smime.p7s
Description: S/MIME Cryptographic Signature
