directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 11:47:10 GMT
> From: Irving, Dave [mailto:dave.irving@logicacmg.com]
> 
> 
> That's the simplest and cleanest way to do it.
> The only thing that worries me here is that acceptor / port filters
will
> be added to each and every session chain.
> This means they will be "init"ed and "destroy"ed per session.
> If this isn't a problem - then we can roll with the simple solution.
> However, Trustin was talking about filter implementations caching
their
> NextFilters so that events can be propogated asyncronously (and this
> gets harder for filter implementors to do when these filters are
reused
> in multiple sessions).
> 

Ok, can someone explain to me, how can a filter propagate an event
asynchronously (I presume to all the sessions using it) without knowing
what those sessions are? How can a filter make one call in its cached
NextFilter and the message be received by ALL the sessions sharing that
chain?

I think we are in lala-land here. 

It seem to me such a filter needs to keep track of all the sessions in
use [sessionCreated(session)] and send the event to each one of them
[for(session: sessions)
{session.getChain().getNextFilter(this).messageReceived(session,
event);}]

If you do not need to send messages to each session, then you do not
need NextFilter either.

Can someone give an example to the contrary?

Jose Alberto


Mime
View raw message