Trustin Lee wrote: >Hi > > > >>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 >while. > > > 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. -Alex