Thanks, Other than this little annoyance, the clustering and session replication works great!
-----Original Message----- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 12:59 PM To: Tomcat Users List Subject: RE: Tomcat 4.1.24 clustering and server.xml changes aah, that sucks, I'm gonna have to look into that. Filip > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2003 6:32 AM > To: [EMAIL PROTECTED] > Subject: Tomcat 4.1.24 clustering and server.xml changes > > > I am currently using the clustering capabilities provided for Tomcat 4 > found at http://cvs.apache.org/~fhanik/index.html > <http://cvs.apache.org/~fhanik/index.html> . One of the nice > features this > allows for is session replication via multicasting. By using the > specified > server.xml tags (<Manager>, <Valve>, etc.) you can have a cluster > replicating session information across the various nodes. For > deploying to > the clustered environments, I use Tomcat's manager. This approach allows > for a context.xml to be placed in the META-INF directory of a given web > application which defines the necessary <Manager> and <Valve> tags to be > written into the server.xml when doing deploy tasks. I have noticed that > when the server.xml is updated via the manager when doing deployments, the > <Manager> and <Valve> tags are written completely different from the > specified context.xml provided in META-INF. An example of this would be: > > CONTEXT.XML: > > <Context className="org.apache.catalina.core.StandardContext" > cachingAllowed="true" > charsetMapperClass="org.apache.catalina.util.CharsetMapper" cookies="true" > crossContext="false" debug="0" docBase="/var/tomcat4/webapps/test" > mapperClass="org.apache.catalina.core.StandardContextMapper" > path="/test" privileged="false" reloadable="false" > swallowOutput="false" useNaming="true" > wrapperClass="org.apache.catalina.core.StandardWrapper"> > > <Valve className="org.apache.catalina.session.ReplicationValve" > filter=".*\.gif;.*\.jpg;.*\.jpeg;.*\.js" > debug="0"/> > > <Manager > className="org.apache.catalina.session.InMemoryReplicationManager" > debug="1" > printToScreen="true" > saveOnRestart="false" > maxActiveSessions="-1" > minIdleSwap="-1" > maxIdleSwap="-1" > maxIdleBackup="-1" > pathname="null" > printSessionInfo="true" > checkInterval="10" > expireSessionsOnShutdown="false" > > serviceclass="org.apache.catalina.cluster.mcast.McastService" > mcastAddr="228.1.2.3" > mcastPort="45566" > mcastFrequency="5000" > mcastDropTime="5000" > tcpListenAddress="auto" > tcpListenPort="4003" > tcpSelectorTimeout="100" > tcpThreadCount="3" > useDirtyFlag="true"> > </Manager> > > </Context> > > > MANAGER CREATED SERVER.XML: > > <Context className="org.apache.catalina.core.StandardContext" > cachingAllowed="true" > charsetMapperClass="org.apache.catalina.util.CharsetMapper" > cookies="true" crossContext="false" debug="0" > docBase="/var/tomcat4/work/Standalone/localhost/manager/test.war" > mapperClass="org.apache.catalina.core.StandardContextMapper" > path="/test" privileged="false" reloadable="false" > swallowOutput="false" useNaming="true" > wrapperClass="org.apache.catalina.core.StandardWrapper"> > > <Manager > className="org.apache.catalina.session.InMemoryReplicationManager" > algorithm="MD5" checkInterval="10" debug="1" distributable="false" > duplicates="0" > entropy="[EMAIL PROTECTED] > " > expireSessionsOnShutdown="false" expiredSessions="0" maxActive="1" > maxActiveSessions="-1" maxInactiveInterval="1728000" pathname="null" > randomClass="java.security.SecureRandom" rejectedSessions="0" > sessionCounter="0"> > </Manager> > > <Valve > className="org.apache.catalina.session.ReplicationValve" > debug="0"/> > > </Context> > > > > This redefining of the tag structure by the manager appears to prevent > the session replication via multicasting to work when the Tomcat > server is restarted. My question is why and or how does the manager > write the contents of the server.xml differently from that specified > in the context.xml? > > Any input on this process would be appreciated..... > > --------------------------------------------------------------------- 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]
