Hi Filip,
Thanks for your help.
The programmer explicitly did a setAttribute as you mentioned, and this
seems to be working. However, we kinda had a discussion whether this is
the most effective solution.
His arguments are that he is using JSF together with some sort of scope
session bean (com.sun.rave.web.ui.appbase.AbstractSessionBean) which
according to him automatically takes care of propagating the objects and
properties to the session. I'm unable to find any information regarding
whether a user should manually invoke setAttribute to store the object
in the session.
It seems that this library is automatically enabled when creating a new
JSF project in NetBeans. I'm wondering whether it is possible that the
most current JSF implementations do not work with the default Tomcat
cluster configuration.
On Mon, 2008-12-15 at 11:16 -0700, Filip Hanik - Dev Lists wrote:
> the DeltaManager (and BackupManager 6.0) only triggers on
> setAttribute/removeAttribute
>
> so this wont work
>
> Cart cart = (Cart)session.getAttribute("cart");
> cart.addItem("cucumber");
>
> the simple tcp replication manager replicates the entire session and is
> able to capture this scenario
> but that is not the way to go, if you change something in the session,
> just call setAttribute
>
> Cart cart = (Cart)session.getAttribute("cart");
> cart.addItem("cucumber");
> session.setAttribute("cart",cart);
>
> Filip
>
> Pieter Temmerman wrote:
> > Hello everybody,
> >
> > First of all, to avoid any misunderstandings, below problems relate to
> > applications that I did not write, neither do I exactly know the
> > implementation of them. Although, if required, I can ask the programmer
> > for more information.
> >
> > That being said, the problem that I am seeing is that the application
> > that I deployed on a Tomcat 5.5.27 cluster is not correctly handling
> > session replication. (The application works perfectly on a single
> > server).
> >
> > The reason for thinking this is that the application fails, but only at
> > irregular intervals. When I press F5, then the page eventually comes
> > true. As said before, this does not happen in a single server
> > environment. According to the Tomcat logs, I can see that my request is
> > being served by Tomcat1 and by Tomcat2, and vice versa.
> >
> > My server.xml configuration:
> >
> > <Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"
> >
> > managerClassName="org.apache.catalina.cluster.session.DeltaManager"
> > expireSessionsOnShutdown="false"
> > useDirtyFlag="true"
> > notifyListenersOnReplication="true"
> > clusterLog="true"
> > clusterLogName="clusterlog">
> > <Membership
> >
> > className="org.apache.catalina.cluster.mcast.McastService"
> > mcastAddr="228.0.0.6"
> > mcastPort="45566"
> > mcastFrequency="500"
> > mcastDropTime="3000"/>
> > <Receiver
> >
> > className="org.apache.catalina.cluster.tcp.ReplicationListener"
> > tcpListenAddress="172.18.0.39"
> > tcpListenPort="4001"
> > tcpSelectorTimeout="100"
> > tcpThreadCount="25"/>
> > <Sender
> >
> > className="org.apache.catalina.cluster.tcp.ReplicationTransmitter"
> > replicationMode="pooled"
> > ackTimeout="15000"
> > keepAliveTimeout="20000"
> > waitForAck="true"/>
> > <Valve
> > className="org.apache.catalina.cluster.tcp.ReplicationValve"
> > filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*
> > \.html;.*\.css;.*\.txt;"/>
> > <!-- <Deployer
> > className="org.apache.catalina.cluster.deploy.FarmWarDeployer"
> > tempDir="/tmp/war-temp/"
> > deployDir="/tmp/war-deploy/"
> > watchDir="/tmp/war-listen/"
> > watchEnabled="false"/>-->
> > <ClusterListener
> > className="org.apache.catalina.cluster.session.ClusterSessionListener"/>
> > </Cluster>
> >
> >
> > Something interesting that I figured out is that if I change the
> > managerClass from
> > managerClassName="org.apache.catalina.cluster.session.DeltaManager"
> > to
> > managerClassName="org.apache.catalina.cluster.session.SimpleTcpReplicationManager"
> >
> > then the application works fine. (It keeps working when I set
> > useDirtyFlag to false).
> >
> > One would think that the DeltaManager is just not replicating, but I can
> > see the following messages in catalina.out:
> >
> > catalina.out:INFO: Manager[/Application1], requesting session state from
> > org.apache.catalina.cluster.mcast.McastMember[tcp://172.18.0.40:4001,catalina,172.18.0.40,4001,
> > alive=73627]. This operation will timeout if no session state has been
> > received within 60 seconds
> > catalina.out:INFO: Manager[/Application1], session state received in 104
> > ms.
> >
> > Currently the only information that I have about the application is that
> > it's using JSF and session beans.
> > The developer said he does not need to explicitly put
> > session.SetAttribute(whatever), since this is automatically taken care
> > of by the session bean object. I'm not a Java programmer, so I'm not
> > sure whether that is correct.
> >
> > I would really appreciate if someone could point me into the right
> > direction.
> >
> > Btw. I cannot change the managerclass to SimpleTcpReplicationManager, as
> > I got other applications on the same server that start failing if that
> > manager is used.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
