RE: Tomcat clustering

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

sent to tomcat-user for archiving purposes.

> the Tomcat
> 5.x source code and judicious use of a decompiler we've managed to build

why did you need to decompile it only to compile it again? I've already give
you a compiled version for tomcat-replication.jar. interested to hear the
reply on this one.
I have the source code at home, can send it to you next week if you are
interested.

> From looking at the code I can see that things have changed somewhat since
> your original article on the TheServerSide and you've abandoned using

Several reasons:
- TCP is faster than UDP, and reliability is built in.
- The JavaGroups license is not accepted into Tomcat source (main reason)
- Different replication schema, replicates at the end of the request, not on
every attribute change.
- Synchronous replication, don't let the user go until the replication is
done ( in the future this might change) and hence reduce the risk of the
stuff that can happen when you don't have distributed locking in place.

> I wondered what your thoughts were on the sending of deltas rather than
> replicating the entire session. I see that you've allowed for

interesting idea, might be a future feature. For now there is a "isDirty"
flag that if set only replicates when attributes actually change.
If isDirty=false the following code would also work

HashMap map = session.getAttribute("map");
map.put("data",data);

hence allows developers to instantly have session replication without
finding the traps.
only replicating deltas, won't work in this scenario.

> How about session locking, that is when a session is accessed on
> one server

the only locking we do is synchronous replication, but other than that, you
are talking about a wormhole for performance problems. I rather not do that
right now, maybe in the future.

> Also we're interested in only replicating those attributes at the
> end of the

tomcat-replication.jar does this already, except it replicates the entire
session. see above for reasoning on deltas.

Filip



> -----Original Message-----
> From: Yao Ng [mailto:Yao.Ng@digitalrum.com]
> Sent: Wednesday, April 02, 2003 9:37 AM
> To: 'Filip Hanik'
> Cc: Sam Wilson
> Subject: RE: Tomcat clustering
>
>
> Hi Filip,
>
> Thanks for your prompt reply. Through a combination of looking at
> the Tomcat
> 5.x source code and judicious use of a decompiler we've managed to build
> from source a version of your tomcat-replication.jar and got it
> working very
> nicely with two instances of Tomcat 4.1.24. Great work!
>
> From looking at the code I can see that things have changed somewhat since
> your original article on the TheServerSide and you've abandoned using
> JavaGroups in favour of writing your own custom multicast and TCP/IP
> transports. What was the motivation for doing this? Haven't you lost the
> ability to configure the protocol stack depending on your network's
> requirements? Admittedly, the codebase is now much smaller and I daresay
> leaner. Also it benefits from not having dependencies on
> JavaGroups and it's
> parents.
>
> I wondered what your thoughts were on the sending of deltas rather than
> replicating the entire session. I see that you've allowed for
> SessionMessage
> types SESSION-ATTRIBUTE-ADDED and
> SESSION-ATTRIBUTE-REMOVED-WITH-NOTIFY but
> you only send SESSION-CREATED and SESSION-GET-ALL message types
> at present.
> The reason I ask is that in our applications the sessions could get fairly
> large (not ideal I know) and we'd rather just broadcast the session
> attributes that are modified.
>
> Also we're interested in only replicating those attributes at the
> end of the
> request rather than sending messages every time the servlet code
> needlessly
> modifies the session during the request (we might not have
> control over what
> other developers do in their servlet code).
>
> How about session locking, that is when a session is accessed on
> one server
> it broadcasts a lock message to prevent the same session being accessed on
> the other cluster nodes until the request has been serviced? This might be
> useful in safeguarding against situations when the user
> double-clicks on his
> browser and makes the same request twice. Clearly the expiring of session
> locks and how you wait for a lock to become released are important
> considerations.
>
> I'd be very interested in your thoughts on these matters and if you can
> think of any obvious pitfalls in implementing such features.
>
> Thanks for your input.
>
> Yao
>
>


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