You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Weseloh, Nicole" <Ni...@lit.lineas.de> on 2004/06/04 12:26:05 UTC
Session Replication with Tomcat 5.0.19
Hello,
I've got two questions concerning in memory session replication:
1.) What exactly is the difference between SimpleTcpReplicationManager and DeltaManager?
I guess that SimpleTcpReplicationManager replicates the whole session, while DeltaManager replicates only the attributes which changed. Is that correct? As far as I see, DeltaManager's performance would be much better, so what reasons could there be to use a SimpleTcpReplicationManager after all?
2.) I'd like to have a logmessage each time a session gets replicated (just for "learning" purpose, I like to see what's going on... ;-) ), so one of my objects I store in each session implements HttpSessionBindingListener and HttpSessionActivationListener.
The object is definitely stored in the session (valueBound() shows me in the log..), and the session gets replicated, I guess - at least, I've got the valueBound() - log on both cluster nodes. However, willPassivate() and didActivate() are never called. (no log output there. ) Yes, I've set "useDirtyFlag = false" (otherwise, no special configurations in server.xml - just the default) and the cluster members "know" each other...
I googled a whole day, read the java doc and everything else I could find.. but still couldn't find out how SessionActivation exactly works... I assume a session "willPassivate", gets replicated and then "didActivate" - or am I completely wrong?
Thanks,
Nicole
------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Unknown error in tomcat log help
Posted by James Sherwood <js...@romulin.com>.
Hi,
I get this error in my tomcat log once and a while. It doesnt seem to
affect the site any and I was just wondering if anyone knew what it was?
I am using tomcat 5.025, apache 2.049 and mod_jk 1.25
Thanks
**********************************************************
Exception during post-request cleanup.
Session id: 6A15A35F0A762F1605E9CB9417F38967
Client address: 216.108.4.73
Exceptions:
org.apache.catalina.connector.ClientAbortException
java.net.SocketException: Connection reset by peer: socket write error
java.net.SocketOutputStream.socketWrite0(Native Method)
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
java.net.SocketOutputStream.write(SocketOutputStream.java:136)
org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:465)
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:675)
org.apache.jk.server.JkCoyoteHandler.doWrite(JkCoyoteHandler.java:251)
org.apache.coyote.Response.doWrite(Response.java:542)
org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:368)
org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:398)
org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:318)
org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:297)
org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:8
5)
org.apache.tapestry.request.ResponseOutputStream.forceFlush(ResponseOutputSt
ream.java:149)
org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:928)
org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:197
)
org.apache.tapestry.ApplicationServlet.doGet(ApplicationServlet.java:158)
javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:237)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:157)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:214)
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContext
Valve.java:198)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:152)
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137
)
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117
)
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:109)
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296)
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372)
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:694)
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:626)
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807)
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:644)
java.lang.Thread.run(Thread.java:534)
**********************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: Session Replication with Tomcat 5.0.19
Posted by "Filip Hanik (lists)" <de...@hanik.com>.
1) Yes, you assumptions are correct
imagine this code
Map map = (Map)session.getAttribute("map");
map.put("test","test");
in this scenario, the simple tcp replication manager comes in handy.
2) Session activate/passivate is not invoked. I didn't really think of it as
activation/passivation when it gets replicated. I can for sure add it in, if
there is a need for it. Enabling debug mode using log4j will show you
exactly what sessions get replicated and when,
for more info on how to do that,
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg126799.html
-----Original Message-----
From: Weseloh, Nicole [mailto:Nicole.Weseloh@lit.lineas.de]
Sent: Friday, June 04, 2004 5:26 AM
To: Tomcat Users List (E-Mail)
Subject: Session Replication with Tomcat 5.0.19
Hello,
I've got two questions concerning in memory session replication:
1.) What exactly is the difference between SimpleTcpReplicationManager and
DeltaManager?
I guess that SimpleTcpReplicationManager replicates the whole session, while
DeltaManager replicates only the attributes which changed. Is that correct?
As far as I see, DeltaManager's performance would be much better, so what
reasons could there be to use a SimpleTcpReplicationManager after all?
2.) I'd like to have a logmessage each time a session gets replicated (just
for "learning" purpose, I like to see what's going on... ;-) ), so one of my
objects I store in each session implements HttpSessionBindingListener and
HttpSessionActivationListener.
The object is definitely stored in the session (valueBound() shows me in the
log..), and the session gets replicated, I guess - at least, I've got the
valueBound() - log on both cluster nodes. However, willPassivate() and
didActivate() are never called. (no log output there. ) Yes, I've set
"useDirtyFlag = false" (otherwise, no special configurations in server.xml -
just the default) and the cluster members "know" each other...
I googled a whole day, read the java doc and everything else I could find..
but still couldn't find out how SessionActivation exactly works... I assume
a session "willPassivate", gets replicated and then "didActivate" - or am I
completely wrong?
Thanks,
Nicole
------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org