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/