Adding an event queue?
Sean Corfield
A synchronous listener is executed "immediately" when an event is
dispatched (well, as soon as Edmund hits it in the list of subscribers
for that event) and control returns to Edmund when the listener is
finished. An asynchronous listener is also executed "immediately" but
control returns to Edmund "immediately" because the listener is
executed in a thread.
I'm looking at a use case for Edmund that would be most easily solved
by adding a third type of listener: a queue.
When an event is dispatched, Edmund would go through the list of
subscribers and for a queued listener, it would simply add the event
to an internal queue and continue through the list. A separate thread
would be spawned when Edmund was initialized that would repeatedly
check the queue and actually invoke the listeners. The listeners would
effectively be synchronous and be executed in the order that events
were dispatched but they would all execute in a separate thread to the
main program.
I'm actually looking at a few implementation options for the queue:
in-memory (in the same instance as Edmund), in-database (which could,
in theory, allow for execution of listeners across multiple machines)
and perhaps others that folks can imagine up :)
First off, do folks think this would be useful?
Second, what would folks like to see in this sort of feature?
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Adam Haskell
Adam
Gavin Baumanis
Sean Corfield
> I guess I'll have to think about this more but right now I am failing to get
> the benefit of the queue over asynchronous. Is it a matter of having
> synchronous events across multiple requests?
Well, if you had a listener that has to essentially single thread a
process (it operates on a shared resource and must lock) then you're
better off queuing events for it than trying to fire them all off
asynchronously, especially if it's long-running.
There's also the possibility of making the queue cluster-aware so that
any server in a cluster could handle a given event but you'd be
guaranteed each event is only handled once. I've had scenarios in the
past where I have a cluster where every member of the cluster is
capable of handling each event but then you have to ensure whichever
one gets to the event first is the only one to handle the event (this
is a problem that comes up with scheduled tasks running in a cluster,
for example).
JMS enables both of these of course but I'm wondering if there's a way
to do it effectively within Edmund without requiring some external
agent like JMS (although of course a queue architecture that
transparently allows for multiple implementations - including JMS -
would be my ideal solution).
John Allen
Would the firing order of the listeners in the que depend on how edmond was initialized?
I also like the idea about using the db for multiple machines.
Sean Corfield
> Would the firing order of the listeners in the que depend on how edmond was
> initialized?
That would depend on whether I added a single queue for all events or
for each event or whether each listener had its own queue. I'm open to
suggestions :)