Tomcat Clustering Questions...

[Robert Mohn <ro...@hotmail.com>]

Hi, I have 2 questions about the tomcat clustering in tomcat 4.1.x and/or 
5.x:

1.  The original "in memory session replication" for tomcat 4.0 used 
JavaGroups, and JavaGroups supported and "CRYPT" flag to allow encryption of 
the session data between nodes.   Does the clustering in 4.1/5.x support ssl 
encryption of the data between the nodes, or are there plans for this in the 
future?

2.  There is a concern in our group about race conditions, meaning the 
session data doesn't get replicated to a node in the cluster before the user 
makes a request that hits that node.   From looking at the code, it seems 
like the session data is replicated before the current request is finished.  
Is this is true? If so, then this scenario wouldn't be an issue.

Thanks,
-Rob

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

RE: Tomcat Clustering Questions...

[Filip Hanik <ma...@filip.net>]

> 1.  The original "in memory session replication" for tomcat 4.0 used
> JavaGroups, and JavaGroups supported and "CRYPT" flag to allow
> encryption of
> the session data between nodes.   Does the clustering in 4.1/5.x
> support ssl
> encryption of the data between the nodes, or are there plans for
> this in the
> future?

no, unfortunately speed has been a priority, so this has not been taken in
place. Maybe later versions

> 2.  There is a concern in our group about race conditions, meaning the
> session data doesn't get replicated to a node in the cluster
> before the user
> makes a request that hits that node.   From looking at the code, it seems
> like the session data is replicated before the current request is
> finished.
> Is this is true? If so, then this scenario wouldn't be an issue.

Session data gets replicated once the request is completed. However it gets
sent out on the network using the same thread that processed the request, so
the request is not considered complete until the data has been serialized
and sent.
There is a small network overhead before the data actually is sent over to
the other node, but it should not be a major issue in a actual human
browsing experience, since a user spends more than one second to view over a
page. however, if you have a program hitting the system with simultanous
threads over multiple connections using the same session cookie, you could
run into this. We have not implemented distributed locking for the purpose
of session replication, and I don't believe we intend to either

You can set the replication mode to be asynchronous, but the difference is
minimal in my tests.

Filip


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org