You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Adrian Gligor <ad...@gmx.net> on 2008/08/13 17:52:28 UTC
Session values don't replicate under certain circumstances
Hello,
i have a working Tomcat 6.0.18 cluster with session replication using
DeltaManager and load balancing using mod_jk. The following problem does
not depend on having sticky sessions either on or off.
I'm putting an object into the session, and set one of its members:
vo = new ValueObject();
vo.name = "testvalue";
request.getSession().setAttribute("valueobject", vo);
The object is correctly propagated onto all cluster nodes. I'm testing
this by setting sticky sessions off and printing the node name and
object value on each refresh. My requests bounce between the nodes as
expected, but the value of my object stays the same.
However, if I subsequently change the member, replication doesn't
trigger. It's like Tomcat doesn't detect the change:
ValueObject vo = (ValueObject)
request.getSession().getAttribute("valueobject");
vo.name = "testvalue2";
By doing this, my nodes are now out of sync. If I put the object into
the session again (setAttribute), the changes get replicated. However, I
have a big application here, and it would be very complicated to find
all occurences of this pattern.
My question is, is this behavior by design, or a bug? And is there any
way to work around it without changing (too much) code? I would
appreciate any hint.
Adrian
PS: I have attached the source code and .war file of a very simple test
application that will demonstrate this behavior.
Re: Session values don't replicate under certain circumstances
Posted by Adrian Gligor <ad...@gmx.net>.
Thank you Filip,
that's not the answer I would have liked, but at least I know I cannot
get away without changing the code.
Adrian
On 13. Aug. 2008, at 18:31, Filip Hanik - Dev Lists wrote:
> that's correct. there are a number of frameworks that detect these
> kind of changes, Tomcat doesn't, everything is triggered by
> setAttribute/removeAttribute
>
> Filip
>
> Adrian Gligor wrote:
>> Hello,
>>
>> i have a working Tomcat 6.0.18 cluster with session replication using
>> DeltaManager and load balancing using mod_jk. The following problem
>> does
>> not depend on having sticky sessions either on or off.
>>
>> I'm putting an object into the session, and set one of its members:
>> vo = new ValueObject();
>> vo.name = "testvalue";
>> request.getSession().setAttribute("valueobject", vo);
>>
>> The object is correctly propagated onto all cluster nodes. I'm
>> testing
>> this by setting sticky sessions off and printing the node name and
>> object value on each refresh. My requests bounce between the nodes as
>> expected, but the value of my object stays the same.
>>
>> However, if I subsequently change the member, replication doesn't
>> trigger. It's like Tomcat doesn't detect the change:
>> ValueObject vo = (ValueObject)
>> request.getSession().getAttribute("valueobject");
>> vo.name = "testvalue2";
>>
>> By doing this, my nodes are now out of sync. If I put the object into
>> the session again (setAttribute), the changes get replicated.
>> However, I
>> have a big application here, and it would be very complicated to find
>> all occurences of this pattern.
>>
>> My question is, is this behavior by design, or a bug? And is there
>> any
>> way to work around it without changing (too much) code? I would
>> appreciate any hint.
>>
>> Adrian
>>
>> PS: I have attached the source code and .war file of a very simple
>> test
>> application that will demonstrate this behavior.
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session values don't replicate under certain circumstances
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
that's correct. there are a number of frameworks that detect these kind
of changes, Tomcat doesn't, everything is triggered by
setAttribute/removeAttribute
Filip
Adrian Gligor wrote:
> Hello,
>
> i have a working Tomcat 6.0.18 cluster with session replication using
> DeltaManager and load balancing using mod_jk. The following problem does
> not depend on having sticky sessions either on or off.
>
> I'm putting an object into the session, and set one of its members:
> vo = new ValueObject();
> vo.name = "testvalue";
> request.getSession().setAttribute("valueobject", vo);
>
> The object is correctly propagated onto all cluster nodes. I'm testing
> this by setting sticky sessions off and printing the node name and
> object value on each refresh. My requests bounce between the nodes as
> expected, but the value of my object stays the same.
>
> However, if I subsequently change the member, replication doesn't
> trigger. It's like Tomcat doesn't detect the change:
> ValueObject vo = (ValueObject)
> request.getSession().getAttribute("valueobject");
> vo.name = "testvalue2";
>
> By doing this, my nodes are now out of sync. If I put the object into
> the session again (setAttribute), the changes get replicated. However, I
> have a big application here, and it would be very complicated to find
> all occurences of this pattern.
>
> My question is, is this behavior by design, or a bug? And is there any
> way to work around it without changing (too much) code? I would
> appreciate any hint.
>
> Adrian
>
> PS: I have attached the source code and .war file of a very simple test
> application that will demonstrate this behavior.
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org