Pier: As far as package names are concerned, I'll gladly defer to the Tomcat gods for guidance.
See my response to Mika for some thoughts on 'redundant' session managers. This is certainly doable, and from a fail-over perspective, probably a requirement. Tomcat could be configured with a list of session manager rmi urls, the first one on the list to be considered the 'active' server. It could then fall-back to the 'next' one in the list if needed. My thought is that Tomcat should maintain it's own copy of the Sessions (at least for some proscribed time). It can use it's own copy of the Session if it hasn't been told (by the remote session manager) that a session is invalid (see SessionClient.invalidateSession(sessionId)). This possibly reduces the number of round-trips, and lets the server continue to operate in the event of a complete failure of the remote session manager. Tom ----- Original Message ----- From: "Pier Fumagalli" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Monday, November 12, 2001 4:28 PM Subject: Re: Tomcat: Distributed Session Management revisited | On 12/11/2001 10:19 pm, "Tom Drake" <[EMAIL PROTECTED]> wrote: | | > Tomcat Developers: | > | > This is a forward of a message that I sent to Bip and Craig a few days ago, | > regarding distributed session managment (aka Clustering). I haven't gotten | > any feedback just yet, so I thought I'd throw this out to the whole dev | > list. | | This is always the wiser choice... | | > The current implementation is broken. The following message explains | > why and describes some possible solutions to this problem. | > | > This feature (e.g. distributed session management) is an absolute | > requirement | > for any deployment that needs to scale beyond a single Tomcat instance, and | > does not want the overhead of depending on JDBC for storing sessions. | > | > I've also attached, at the bottom of this message, Two 'preliminary' RMI | > interfaces | > that describe (see scenario 1 below) how I think this session server and | > it's | > clients (e.g. tomcat instances) should converse. | > SessionServer - to be implemented by the remote session manager/server | > SessionClient - to be implemented by clients (e.g. Tomcat) of the remote | > session manager/server. | > | > I'm interested in making a contribution in this area and am anxious to | > receive | > some feedback from the dev-list members on this subject. | | I looked down at the implementation, and so far I have two comments: the | first one is very stupid (AKA, package names :), but I'm concerned about one | thing: If we have a cluster of SessionClient(s), then sessions are stored | all on the SessionServer, and that introduces a single point of failure. I | mean, what happens if the SessionServer goes down? | AFAICS, all clients will loose their own sessions (unless sessions are | persisted to disk as in JDBC, and the server doesn't come back up in a | reasonable time)... | | So, I'm wondering... Could it be possible to cluster also the server? Like | in NETBIOS networking, where each client is also server, and if the | "current" server (the one called "Primary Master") goes down, another one | takes on automagically... | | Should go back and dig a little bit back on CIFS and how they do it at this | point... | | Pier | | | -- | To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> | For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> | | | -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
