You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dennis <de...@muhlesteins.com> on 2005/07/29 19:13:00 UTC
DeltaManager for Clustering
Is there documentation on using the DeltaManager for clustering?
In the javadoc there is this statement:
--CUT--
Correct behavior of session storing and reloading depends upon external
calls to the start() and stop() methods of this class at the correct times.
--END--
The tomcat clustering howto doesn't mention this though. Are the
start/stop calls referred to for the container, or does the user
application have to do something?
I have some objects in the session that are not being syncronized
accross the cluster and am trying to figure out if I'm doing something
wrong either in the config or in the code.
Thanks
Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DeltaManager for Clustering
Posted by Dennis <de...@muhlesteins.com>.
Rainer Jung wrote:
>No, DeltaManager doesn't use that flag. It would somehow not make sense,
>because the whole pupose of DeltaManager is to only replicate changed
>attributes of a session and the flag tries to replicate every session
>accessed. So if you would impement it with DeltaManager it would behave
>the same way as the SimpleTcpReplicationManager already does.
>
>
Wouldn't there usually be only one session accessed per request? At
least in my application, when a request is processed, I don't have any
code to access another user's sessions besides the one that made the
request. So while this may be more overhead than only replicating a
session if something has changed, and again more overhead than only
replicating the changed attributes (DeltaManager), at least it solves my
problem of the 3rd party library that doesn't call setAttribute.
>Under high load that will be a problem. If that is relevant yu must do a
>stress test and observe CPU/bandwidth/latency.
>
>
I do agree that it would be important to watch bandwidth/latency to make
sure SimpleTcpReplicationManager can handle our load.
>Maybe a crude workaround: at the end of the requst do a
>getAttribute/setAttribute to the attributes you want to replicate. I think
>DeltaManager does not really check for a change, it replicates all
>attributes accessed via setAttribute.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DeltaManager for Clustering
Posted by Rainer Jung <to...@kippdata.de>.
> See, the thing is, we have a 3rd party library that saves information in
> the session. It doesn't call setAttribute every time it changes the
> data. DeltaManager appears to ignore the useDirtyFlag. With
> SimpleTcpReplicationManager, I can set useDirtyFlag to false and we get
> the desired behavior. With DeltaManager, the sessions get out of sync.
> So for the time being, I switched the managerClass back to
> SimpleTcpReplicationManager and things work the way they are supposed to.
>
> The issue is whether or not DeltaManager is supposed to use a
> useDirtyFlag or not I guess. The config option is still there in the
> sample cluster config that comes with server.xml as well as in the
> online-documentation. It has no effect though.
No, DeltaManager doesn't use that flag. It would somehow not make sense,
because the whole pupose of DeltaManager is to only replicate changed
attributes of a session and the flag tries to replicate every session
accessed. So if you would impement it with DeltaManager it would behave
the same way as the SimpleTcpReplicationManager already does.
Under high load that will be a problem. If that is relevant yu must do a
stress test and observe CPU/bandwidth/latency.
Maybe a crude workaround: at the end of the requst do a
getAttribute/setAttribute to the attributes you want to replicate. I think
DeltaManager does not really check for a change, it replicates all
attributes accessed via setAttribute.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DeltaManager for Clustering
Posted by Dennis <de...@muhlesteins.com>.
Rainer Jung wrote:
>Hi Dennis,
>
>assuming you have a valid cluster config you don't need to start/stop the
>DeltaManager yourself.
>
>
Good, that's what I thought.
>Session attributes are only replicated, if they are serializable and the
>changes to the attributes are applied via setAttribute. If your attribute
>e.g. is a HashMap and you change an entry via getAttribute and then access
>by a key, the cluster will not know about the change and not replicate the
>new data. On the other hand this way you can obscure changes you don't
>really need from the replication and save some replication load.
>
>
See, the thing is, we have a 3rd party library that saves information in
the session. It doesn't call setAttribute every time it changes the
data. DeltaManager appears to ignore the useDirtyFlag. With
SimpleTcpReplicationManager, I can set useDirtyFlag to false and we get
the desired behavior. With DeltaManager, the sessions get out of sync.
So for the time being, I switched the managerClass back to
SimpleTcpReplicationManager and things work the way they are supposed to.
The issue is whether or not DeltaManager is supposed to use a
useDirtyFlag or not I guess. The config option is still there in the
sample cluster config that comes with server.xml as well as in the
online-documentation. It has no effect though.
>Is replication working in general in your setup?
>
>
Yes
Thanks for your reply.
Dennis
>
>
>>Is there documentation on using the DeltaManager for clustering?
>>
>>In the javadoc there is this statement:
>>
>>--CUT--
>>Correct behavior of session storing and reloading depends upon external
>>calls to the start() and stop() methods of this class at the correct
>>times.
>>--END--
>>
>>The tomcat clustering howto doesn't mention this though. Are the
>>start/stop calls referred to for the container, or does the user
>>application have to do something?
>>
>>I have some objects in the session that are not being syncronized
>>accross the cluster and am trying to figure out if I'm doing something
>>wrong either in the config or in the code.
>>
>>Thanks
>>Dennis
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DeltaManager for Clustering
Posted by Rainer Jung <to...@kippdata.de>.
Hi Dennis,
assuming you have a valid cluster config you don't need to start/stop the
DeltaManager yourself.
Session attributes are only replicated, if they are serializable and the
changes to the attributes are applied via setAttribute. If your attribute
e.g. is a HashMap and you change an entry via getAttribute and then access
by a key, the cluster will not know about the change and not replicate the
new data. On the other hand this way you can obscure changes you don't
really need from the replication and save some replication load.
Is replication working in general in your setup?
> Is there documentation on using the DeltaManager for clustering?
>
> In the javadoc there is this statement:
>
> --CUT--
> Correct behavior of session storing and reloading depends upon external
> calls to the start() and stop() methods of this class at the correct
> times.
> --END--
>
> The tomcat clustering howto doesn't mention this though. Are the
> start/stop calls referred to for the container, or does the user
> application have to do something?
>
> I have some objects in the session that are not being syncronized
> accross the cluster and am trying to figure out if I'm doing something
> wrong either in the config or in the code.
>
> Thanks
> Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org