directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [seda] How to get protocol providers to effect SEDA?
Date Sun, 28 Nov 2004 02:44:09 GMT
Trustin Lee wrote:

>>However what do you recommend we do today in the next day or two?
>I'm really sleepy now, so I'm sorry in advance if I say something wrong :)  
No worries you must have been up through the night it seems.

>Many/Single/NoReplyHandler has a handle() method which has ClientKey
>type parameter.  ClientKey.expire() has protected acess modifier
>because it directly closes the socket for now.  But this could change
>it to 'public' if we can fire DisconnectEvent, or it would be just OK
>to modifying access modifier if the usecase is blacklist only for a
Yeah this is a hack though as you hinted already.  Perhaps the best 
thing to do is enable protocol providers with a handle to the event 
router and have them capable of publishing Events.  I think this opens 
up the gambit of possibilities - not just shuting down a connection or 
enabling blacklists but much more.  We cannot possibly foresee all the 
possible interactions that can occur for all protocols and the event 
model is most excellent for this.

I hope your distaste for the many problems within SEDA does not make you 
loose faith in the usage of this pattern - it really is nice to have 
because it allows any kind of event to be published.  If this event has 
merit then something listens and responds to it.  This is an excellent 
decoupled way to have the provider talk back to the system without hard 
dependencies.  Now the in band processing of Events with the pattern is 
not the best thing as we discussed for SEDA because of performance 
issues with stage syncronization.  By in band I am referring to the 
events used for actually processing requests as opposed to events for 
setup and teardown.  Really try to give the pattern a second thought not 
for the in band processing which is expensive and needs to change but 
for loosly couple parts of the system that may need to communicate 
without performance issues in the way.  Like for setup, configuration or 
communicating things between the provider and the SEDA layer whatever 
that may be tommorrow. 


View raw message