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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]