supreme_java_guru_1 wrote: > While I don't know the inner workings of how both dead session > routines work, is there a reason you can't both "share" a method, > with one passing in the "callback" method to the other? Or perhaps > setting up an event so that when his sweeps, it triggers an event for > yours to sweep, or vice versa?
ultimately, yes, the two should probably be coordinated. In the short term, until proven otherwise, I think my hack should work and is a lot less coding. When we get the rest of this working we will revisit this problem in the second iteration and resolve it. > > Jules, don't know if you ever got my email about clustered sessions, > I was wondering how well yours is going? I see you said Marc is > looking forward to this functionality, I take it that means > the "integration" of the Jetty session fail-over with the JBoss 3 > session failover of ejb sessions? I don't quite know how this would > be necessary or if that is even what you are saying here. I assume it > would mean (if it even does) that the HttpSession is tied to the EJB > session and both would need to be failed over together in some way if > the JVM is running both Jetty and Jboss in the one JVM. I got your last email, and replied - twice, but both bounced from your address. I'm not aware of any integration with 'EJB session failover'. We are simply working towards: 1. an initial implementation of the servlet 2.3 spec of 'distributable' sessions on top of an abstraction. One implementation of this abstraction will be a simple CMP store in Sacha's in-vm distributable cache. 2. the going beyond the spec to take regular snapshots at some configurable interval, into the same store, and on failure, retrieve and continue with the last snapshot, in much the same way as we might activate a session after passivation. > > > None the less, I have been overly busy lately at work and little time > to do anything else, including seeing my family. I doubt I will have > time to do my session fail-over plugin before Jetty 4 is locked, but > I would like to try to start on it soon. If you could point me in the > direction of what source files I should be looking at to plug in my > code, I would appreciate it. Look at plugins/jetty/src/main/org/jboss/jetty/session and the HTTP stuff in cluster/ that I consume. I wrote an initial straight CMP implementation (Coarse....SessionBean), then abstracted away from this until I could swap it out and replace it with Sacha's clustered stuff. I have a few concerns with this that we have been discussing and will keep you in the loop. I suggest that you will want to implement another subclass of AbstractStore, since you are interested in the storage side of things, and will not want to rewrite the HttpSession implementation itself. Therefore I value your input on what is currently a very narrow interface between the session and the store, and has very limited granularity. You should talk to Sacha about his in-vm distributable cache to ensure that you do not reinvent anything that he has already done, also. I enclose the text of the mail that did not reach you, Jules ----------------------------------------------------------------------------- The first iteration is there. I just checked it in. It doesn't work yet, because there appears to be a problem in Sacha's stuff, below me - but he's onto it. This first iteration is simply what the spec requires - sessions so be passivated on closedown of a node (or undeployment of a webapp) and activated the next time a request comes in for that session. JBoss' aim is much more than that. They want frequent snapshotting of session state for failover if a node suffers catastrophic failure. This opens a nasty can of worms since it goes beyond the servlet 2.3 spec. If you are interested I can dig out the last mail I sent on the subject. I plan to set the whole thing up so it is highly configurable and users can pick and choose the level of support that suits them..... Keep an eye out on jboss-development. Jules ------------------------------------------------------------------------------ > > > Thanks. > > --- In [EMAIL PROTECTED], Jules Gosnell <[EMAIL PROTECTED]> wrote: > > > > Sacha, > > > > I've just checked in a version of DistributedHttpSessionManager > (plugins/jetty) > > which delegates the necessary fn-ality to a ClusteredStore > instance. This is > > stubbed out with harmless code at the moment. I would really like > to try > > hooking up your stuff ASAP to see if it flies, and if there are any > unexpected > > problems. You were going to drop me a line when you were ready to > go - I > > haven't heard anything. > > > > I know Marc will be very keen to get this going ASAP. > > > > I foresee two problems. > > > > 1. conflict between my session garbage-collection and yours. > > > > If we sweep for dead sessions at different times it is possible > that you might > > trash a session that I though was alive. > > > > I've gone for a hack that should work. Every time I give you a > session I add 5 > > seconds to it's lifetime. I sweep every 5 seconds (a naive > algorithm that I > > shall be improving), whereas you sweep every ?30? - so I should > always get to > > clear up any live sessions first, and consequently their persistant > state > > first. > > > > This is IMPLEMENTED - but UNTESTED. > > > > 2. failsafe sessions > > > > The servlet 2.3 spec only describes session passivation in terms of > the > > controlled shutdown of a webcontainer. This is distinct from the > uncontrolled > > shutdown of the same, because it is the webcontainers duty to > notify, by way of > > event, every session attribute implementing > HttpSessionActivationListener, with > > a Passivation event on shutdown, and an Activation event on restart. > > > > If the webcontainer node goes down passivation will not occur at > shutdown, so > > we revert to our latest "snapshot" of the session. > > > > We have two choices: > > > > a). send events everytime we snapshot - expensive because > applications are > > likely to use these to acquire and release expensive resources, and > flawed, > > because unless the crash occurs after the passivation and before > the activation > > the webapp may still be left in an inconsistant state (N.B. Greg, > you thought > > this should be done, but I think it is no better than b). > > > > b). send no events, simply take the snapshot, but set a flag that > says whether > > shutdown was controlled or not. On re-activation, if shutdown was > controlled, > > send activation events and continue as normal - everything is > consistant. If > > shutdown was uncontrolled issue a large WARNING explaining the > situation and > > still send the activation events. This gives the webapp the chance > to try to > > fix itself up. > > > > One size will not fit all therefore I shall publish a few flags out > into the > > JMX config which allow selection of various parts of each option, > although I > > personally favour (b). > > > > All the code is there for the snapshotting, however only controlled > > shutdown/startup stuff is switched on, as I haven't had a chance to > test the > > other. I am still considering how we schedule the snapshots. > > > > > > If anyone out there with experience of other AppServers with > similar strategies > > for failsafe HttpSessions could comment on how they achieve the > same goals, I > > would be very grateful. > > > > > > Over and out, > > > > Jules > > > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
