Re: seda3 improvements

Le 25 Mars 2005 04:00, Justin Johnson a =E9crit=A0:
> What are the current improvements over seda?

There is a lot of performance improvements. =20

By exemple, you can see our 2 new queue implementations,=20
DynamicArrayBlockingQueue and LinkedBlockingQueue.  These queues are much=20
more scalable and performant than the old FiniteQueue.

Also, we now support bulk enqueue and dequeue operations based on list inst=
ead=20
of array.  So, we can reuse the list instead of creating each time a new=20
array.  Thus, we don't waste cpu time for array memory allocation and GC.

We now support blocking enqueue operations, so events cannot be lost anymor=
e. =20
This is great but, for performance reason, we need to develop a backpressur=
e=20
mecanism, that will notify the ThreadManager to not allocate a thread to a=
=20
stage that is waiting to enqueue an event to another stage.  This is really=
=20
the most important feature to develop before releasing seda3.

Also, stages are now lifecycled.  This means, by exemple, that we can reini=
t=20
(stop -> destroy -> init -> start) a stage with new configuration parameter=
s. =20
The [program/deprogram] lifecycle level can be used to change on the fly th=
e=20
implementation/version of your event handler.  So, it's possible to update =
an=20
application without shuting down Sandstorm.  Note that this functionnality =
is=20
not completed yet; I need to develop a custom ClassLoader.

Also, our xml-like configuration file now support special properties like=20
${user.home} and ${config.home}, so the programmer don't need to write=20
absolute path name.

Also, we have a new Transactional Queue API.  This API is more easy to use =
and=20
protects againts dandling prepare (memory leak).

We have a new ProfilerHandlerIF api that is used to receives values from th=
e=20
ProfilerIF and exports them.  It might for example, show them graphically o=
n=20
the screen or write them to a file.

Load shedding code is now separated from the real queue code.  Indeed, we u=
se=20
a queue proxy, AdmissionControlledSinkIF.  This give us the possibility to=
=20
change the queue implementation without changing the sink proxy and=20
vice-versa.  Also, code is not duplicated.

We now have a new Signaling API.  Here is what I have already said about it=
 on=20
the mailling list:

"I see the SignalMgr like an interrupt bus in CPU/OS.  Conceptually, a=20
 signal should be like an interrupt, that is, it should preempt all queue=20
 events and lower priority signals.  A signal should be enqueued=20
 unconditionally, so it must bypass load-conditioning policies like queue=20
 capacity.  We could have two kinds of signal: user and system.  A=20
 system-signal is when the source of the signal is Sandstorm.  So,=20
 handlers cannot send system-signal, only user-signal.  Signals should be=20
 handled by the EventHandler.handleEvent() method, like others kind of=20
 events.  By exemple, I would like to use this new SignalMgr to advertize a=
ll=20
 handlers that Sandstorm is shutting down."

After some discussions with users, we have decided to implement it a little=
=20
bit differently.  Our current api must probably be reviewed before the next=
=20
release however.  Indeed, I have a new idea to implement very efficiently=20
signal preemption over normal events and I would like to give it a try.

Also, synchronization overhead has been reduced.

Also, a major refactoring in SandstormConfig has been done, so it would be=
=20
easy to use a new configuration file format.  I would like to have pure xml=
=20
instead of our current .cfg.

Also, we have a new UI Profiler.

Support Object type in SandstormConfigIF and ConfigDataIF.


> Is there a roadmap for seda3?

Sure.=20

=2D Backpressure stuff is really important.

=2D Remove singleton in SS.

=2D All internals components should also be lifecycled, by exemple ManagerI=
=46,=20
ProfilerIF, SignalMgrIF, ThreadManagerIF should have a start() and stop()=20
method.


Optional features for seda3:

=2D A custom ClassLoader for reprogramming a stage (update a stage on the f=
ly).

=2D Partial event processing to increase responsiveness when we stop a stag=
e.


Big feature:

=2D Be able to deploy Sandstorm on a cluster of workstations with load-bala=
ncing=20
and fault-tolerance capability.  This should be another sub-project on top =
of=20
Sandstorm to keep Sandstorm lightweight and easy to use.  So, only users th=
at=20
really need this functionnality will use this sub-project.


Cheers,
=2DJean



-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click