oh, I forgot to mention, useDirtyFlag is only used with
SimpleTcpReplicationManager, cause there is no AOP code that could detect
that objects inside the session have changed

Filip

-----Original Message-----
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 6:16 PM
To: Tomcat Users List
Cc: [EMAIL PROTECTED]
Subject: RE: Session problems with cluster


hi Ivan,
it took me a while to figure out what was going on.

its a coding/configuration problem on your part. Your code would have worked
if you had configured "SimpleTcpReplicationManager" with
useDirtyFlag="false" instead of DeltaManager.

to fix your code, you would need to do this

replace:
((List)session.getAttribute("list")).add(new String("foo"));

with:
((List)session.getAttribute("list")).add(new String("foo"));
session.setAttribute("list",session.getAttribute("list"));

and try again,
the delta manager only replicates session delta's, and the only way to keep
track of deltas are when the code calls setAttribute or removeAttribute

Filip

-----Original Message-----
From: Ivan Vasquez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:13 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster


Filip, here is a concrete case that you may find interesting. It's a
very simple JSP that stores a List in the session, adds an item to it on
every submission and then checks to see if there have been lost items
since the previous request.

To reproduce the error, just deploy in a cluster it and visit the page
(index.jsp) Our tests are consistent in that, the moment any other
clustered application is visited, this page will notify that it has lost
items.

Our main intention is to help identify the problem, because we believe!

Tomcat 5.0.25 (5.0.28 has the reload problem, so we downgraded)
JDK 1.4.2

Cluster config:
        <Cluster
className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"

managerClassName="org.apache.catalina.cluster.session.DeltaManager"
                 expireSessionsOnShutdown="false"
                 useDirtyFlag="false">

            <Membership

className="org.apache.catalina.cluster.mcast.McastService"
                mcastAddr="228.0.0.4"
                mcastPort="45564"
                mcastFrequency="500"
                mcastDropTime="3000"/>

            <Receiver

className="org.apache.catalina.cluster.tcp.ReplicationListener"
                tcpListenAddress="10.0.0.1"
                tcpListenPort="4001"
                tcpSelectorTimeout="100"
                tcpThreadCount="6"/>

            <Sender

className="org.apache.catalina.cluster.tcp.ReplicationTransmitter"
                replicationMode="pooled"/>

            <Valve
className="org.apache.catalina.cluster.tcp.ReplicationValve"

filter=".*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;"/>
        </Cluster>


index.jsp
-----------------------

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"; %>
<%@ page import="java.util.*" %>
<%@ page import="java.net.*" %>

<html>
<script>
function submit_frm() {
    if (document.testform.listSize.value !=
document.testform.listPrevSize.value)
        alert('List out of sync: Reported size = ' +
document.testform.listSize.value + ', expected = ' +
document.testform.listPrevSize.value);
    else
        document.testform.submit();
}
self.setTimeout('submit_frm()', 200);
</script>

<body>
        <h3><%
out.println(java.net.InetAddress.getLocalHost().getHostName()); %></h3>
        <h4>SessionID ${pageContext.session.id}</h4>
        <form name="testform" action="index.jsp">
                <%
                // Initialize list on first load or when no parameters
are passed
                if (session.getAttribute("list") == null ||
request.getParameter("listSize") == null) {
                        out.println("<b>List is null,
creating</b><br>");
                        session.setAttribute("list", new ArrayList());
                }

                out.println("<b>Collection Size</b><br>");
                ((List)session.getAttribute("list")).add(new
String("foo"));
                %>
                <br>
                <table>
                <tr><td>List size in session</td>
                        <td><input type="text" name="listSize"
value="${fn:length(sessionScope.list)}"/></td></tr>
                <tr><td>Previous list size + 1:</td>
                        <td><input type="text" name="listPrevSize"
value="${param.listSize + 1}"/></td></tr>
                </table>
                <br>
                <a href="index.jsp">Restart</a>
        </form>
</body>
</html>

-----------------------
end index.jsp

Thank you
Ivan


-----Original Message-----
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:39 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster

> Hmm, that's a bit concerning.
I found your lack of faith disturbing, you must believe in the force
luke,
especially when you wish to pay $0 for the software :)

Here is what is happening in on context reload, there is a setting in
the
server.xml called "expireSessionsOnShutdown",
if this is set to false, the sessions in that node wont get expired and
survive the context reload, hence the ClassCastException getting thrown
since your class is reloaded but the session remains in memory.
Turning expireSessionsOnShutdown to true will expire the sessions and
propagate the message to the other nodes.

I realize that this behavior is a little bit odd, perhaps even screwed
up,
and I will modify it to function this way:

1. expireSessionsOnShutdown="true" - will expire the sessions in the
node
and propage the expire message to the other nodes
2. expireSessionsOnShutdown="false" - will expire the sessions in the
local
node, but not in the other cluster nodes.

The bug described in this thread really comes into play when you reload
context, which I never do, hence I forgot to account for that scenario.

I will put in a fix for this into Tomcat 5.5 right away, and 5.0.x when
time
frees up.

Filip



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to