Re: seda3 improvements

That sounds fantastic.  Thank you Jean for your very detailed response.

>Le 25 Mars 2005 04:00, Justin Johnson a =E9crit :
> =20
>
>>What are the current improvements over seda?
>>   =20
>>
>
>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 muc=
h=20
>more scalable and performant than the old FiniteQueue.
>
>Also, we now support bulk enqueue and dequeue operations based on list i=
nstead=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 any=
more. =20
>This is great but, for performance reason, we need to develop a backpres=
sure=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 rea=
lly=20
>the most important feature to develop before releasing seda3.
>
>Also, stages are now lifecycled.  This means, by exemple, that we can re=
init=20
>(stop -> destroy -> init -> start) a stage with new configuration parame=
ters. =20
>The [program/deprogram] lifecycle level can be used to change on the fly=
 the=20
>implementation/version of your event handler.  So, it's possible to upda=
te an=20
>application without shuting down Sandstorm.  Note that this functionnali=
ty is=20
>not completed yet; I need to develop a custom ClassLoader.
>
>Also, our xml-like configuration file now support special properties lik=
e=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 u=
se and=20
>protects againts dandling prepare (memory leak).
>
>We have a new ProfilerHandlerIF api that is used to receives values from=
 the=20
>ProfilerIF and exports them.  It might for example, show them graphicall=
y on=20
>the screen or write them to a file.
>
>Load shedding code is now separated from the real queue code.  Indeed, w=
e use=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 queu=
e=20
> events and lower priority signals.  A signal should be enqueued=20
> unconditionally, so it must bypass load-conditioning policies like queu=
e=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 b=
e=20
> handled by the EventHandler.handleEvent() method, like others kind of=20
> events.  By exemple, I would like to use this new SignalMgr to advertiz=
e all=20
> handlers that Sandstorm is shutting down."
>
>After some discussions with users, we have decided to implement it a lit=
tle=20
>bit differently.  Our current api must probably be reviewed before the n=
ext=20
>release however.  Indeed, I have a new idea to implement very efficientl=
y=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.
>
>
> =20
>
>>Is there a roadmap for seda3?
>>   =20
>>
>
>Sure.=20
>
>- Backpressure stuff is really important.
>
>- Remove singleton in SS.
>
>- All internals components should also be lifecycled, by exemple Manager=
IF,=20
>ProfilerIF, SignalMgrIF, ThreadManagerIF should have a start() and stop(=
)=20
>method.
>
>
>Optional features for seda3:
>
>- A custom ClassLoader for reprogramming a stage (update a stage on the =
fly).
>
>- Partial event processing to increase responsiveness when we stop a sta=
ge.
>
>
>Big feature:
>
>- Be able to deploy Sandstorm on a cluster of workstations with load-bal=
ancing=20
>and fault-tolerance capability.  This should be another sub-project on t=
op of=20
>Sandstorm to keep Sandstorm lightweight and easy to use.  So, only users=
 that=20
>really need this functionnality will use this sub-project.
>
>
>Cheers,
>-Jean
>
>
>
>-------------------------------------------------------
>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_ide95&alloc_id=14396&op=3Dclick
>_______________________________________________
>SEDA-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/seda-users
>
> =20
>



-------------------------------------------------------
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=3D6595&alloc_id=3D14396&op=3Dclick