directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject [eve] RE: Frontend redesign
Date Thu, 04 Dec 2003 19:34:31 GMT
<snip/>

> > However I think its best to hid this and not expose it as a
> > service interface.  It is best to use explicit listener interfaces
> > to flag a stage as recieving certain events rather than exposing
> > a generic stage enqueue() method.
> 
> Exactly!  Take a lesson from the JMS folks and write a lean mean internal
> message driven system.  Would not a more appropriate term for this module
> be
> QueueManager, rather than EventManager :-)  Seems like we are going to be
> creating and providing access to a number of queues, and modules can
> register
> with each queue to listen for events.  I assume that each queue would be
> running in its own thread and distributing events to the appropriate
> registered/concerned parties.

Just to clarify for others:

A Stage has a queue, a handler thread and a thread pool of worker threads.
Stages in Eve implement Startable (Runnable) and are services.  The 
main handler thread of the SEDA stage implementation pops off events from
the queue and hands off events to the workers which process these events.
In Eve there are a few modules/services that are implemented as stages.
The decoder for example is a stage that processes InputEvents that are 
pushed onto its queue.

Basically the enqueue operation of events onto a Stage should be deliverd
through a central service.  Again Vincent's link here was great:

http://members.ispwest.com/jeffhartkopf/notifier/

So I quote this page:

"Notice that all publication and subscription is done through the event
service. The event service maintains all information about which subscribers
are interested in which events, so that publishers and subscribers need not
be aware of each other. Moreover, anyone may publish or subscribe to events
using the well-defined interface provided by the event service without
having to implement any special logic to handle interaction with other
entities for which it has no other reason to communicate."

That's what we're looking for.  I think JMS is close but is overkill perhaps
but JMS is obviously a specific manifestation of this pattern.

> 
> Question:  If we are distributing events to registered listeners, is the
> Event
> consumed after all listeners have been notified?  I think so.

Yes it is considered consumed.  

That reminds me should we talk about multiple listeners or subscribers.  
What's the difference?  In my mind there's nothing that really sticks out
right now.

<snip/>

> > So to summarize we need to determine if we keep the ClientKey
> > concept, how we manage protecting the socket when the code is
> > not trusted.  Should we hide the socket or just carry it in a
> > event.  Or is it best to have a service that enables access to
> > the socket based on the (old implementation) and we protect the
> > access to the service rather than the key.
> 
> I don't see any reason any reason to protect the client socket.  There are
> about a half dozen ways to get to it if you really want to, including
> hacking
> the code :-)  By routing the Socket or SocketChannel through the process,
> you
> will avoid having to look it up later, and in my opinion keeps everything
> compact.

Yeah but we're going to need to protect access to it if the key
is ever to be presented to a stored procedure which technically
is not trusted code.  It is user code and runs in the server.

For now let's use it and if we need to we can re-factor the code
to protect against access to the socket.

Peter what do you think?

Alex



Mime
View raw message