Re: What you get is what you want
Quartz <[email protected]> Wed, 24 Nov 2004 18:03:27 -0800 (PST)
| Newsgroups | gmane.comp.java.seda.user |
|---|---|
| Message-ID | <[email protected]> |
--- Jean Morissette <[email protected]> wrote: > Quartz wrote: > > Here, I refactored SS to have 3-level life-cycling per stage: > > [load[init[start/stop]destroy]unload] > > You said 'load' and 'unload'. I suppose that you talk about a > SandstormClassLoader? Could you tell me what is the purpose of a custom > class loader in Sandstorm? Not classloader. In my new version, imlementations of SandstormConfigIF are allowed to mutate. (remember that a ss config doesn't have to be a file...) Given a pure memory config implementation, that is extremely convenient for applications who need to pass/change details of a stage dynamically. A stage wrapper start/stop relates to the fact that a TM is running it somehow. (1 or more thread involved and calling handleEvent) A stage wrapper init/destroy relates to the signal to a handler that its config is ready and handler officially exists (wheter they are stateful handlers or not) A stage wrapper load/unload relates to its own state. It describes whether the ConfigdataIF proxy (*), queue, controllers, profilables, etc. were built/registered/installed. This gives the invaluable opportunity to stop a stage, destroy it, while keeping data in its queue (lossless), mutate the ss cfg and init the stage again with new parameterization, and start it. Note 4 things: 1-the ConfigDataIF is, for me, a proxy or a more accurately a viewport over a subsection of the ss cfg. Mutation of sscfg are reflected. 2-both the configdataif and the sscfg supports put/get object, so that you are allowed to pass complex types from the owner of the sandstorm instance that otherwise a plain config file would make very difficult to accomplish. 3-no more static code. no more sandstorm singleton instance (finally!) 4-stopping a stage involves first telling the TM to stop ressources for a stage, which in turn would first flag the stage runners involved (thread(s)) to stop looping at end of current handleEvent if any. If that stop request is not responding in let's say 100ms (should be configurable per stage), then a real interrupt would be attempted. (this is to avoid intolerance at the stop acknoledgement delay, and secure data in progress, especially things like blocking db inserts that would crap out with sqlexception!) Cool. Continue refreshing my memory, I keep recalling my added features as I go... Does anyone know about an async (nio) db driver for mysql?! ;-) __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/