directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject [MINA] RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Wed, 16 Nov 2005 11:25:11 GMT

I do not have an account in JIRA so just posting a comment.

I took a look at the code and as far as I understand, there is really no
need to change the APIs to allow lazy copy of chains. 

Now the only thing that really needs to be changed is the practice of
caching NextFilter. Instead there is already an API that a filter can
use to request its NextFilter instance given a chain and the filter
instance or the filter name. So, really, the only thing a filter needs
to cache if any, is the Session and from there is can do
Session.getFilterChain().getNextFilter(this); Or something like that.

If the chain is copied due to modifications, all this will be
automagically relocated and there should be no issue.

The only difference here is that NextFilter instances should not be
cached but computed each time, if you do not have it as an argument. And
you should always manage the case of the above expression returning null
if the filter has been removed.

Jose Alberto

> -----Original Message-----
> From: dave irving (JIRA) []
> Sent: 16 November 2005 09:21
> To:
> Subject: [jira] Commented: (DIRMINA-121) Per-port filter chain
>     [
> 121?page=comments#action_12357772 ]
> dave irving commented on DIRMINA-121:
> -------------------------------------
> Would it be possible to have some clarifications on the scope of this
> change?
> We have discussed a basic implementation which would allow builder
> configuration of per sessionManager / port / session chains without
> copying - which is simple enough to implement.
> However, this is restrictive for some users who need control on a per
> session basis over the whole chain.
> As an example:
> Suppose during a conversation with a client they request a certain
> transport encryption mode should be employed. This may result in the
> handler wanting to configure a filter supporting such encryption at
> start of the entire (connection) chain.
> The proposed solution would only allow handlers to modify the per
> chain - as the other chains are shared by all other connections.
> One option is to extend the proposed solution, as follows:
> - In addition to a user being able to do session.getIoFilterChain()
> returns the session chain) they can also do
> session.getIoFilterChainBefore("chainName")
> - I.e, IoFilterChain prePortChain =
> session.getIoFilterChainBefore("portChain");
> - This provides a per session encapsulated chain which is inserted
> the named chain.
> - The implementation is almost the same as the initial solution
> This solves the use case described above. However, it may still be too
> restrictive for some users who want full control over the whole
> chain for a connection.
> Unfortunately, I dont see a way to provide full control without
> the current semantics of IoFilter due to the way each filter knows its
> location (we'd either have to make it possible to "copy" filters, or
> have to change the way a filter knows its location).
> So as it stands I cant really propose a patch which provides "full
> control" over the logical connection chain.
> Would it be possible to clarify whether the proposed solution is
> acceptable - or whether we should go further to enable full control as
> been requested?
> I want to make sure I provide a beneficial solution :o)
> Many thanks,
> Dave
> > Per-port filter chain
> > ---------------------
> >
> >          Key: DIRMINA-121
> >          URL:
> >      Project: Directory MINA
> >         Type: Improvement
> >     Versions: 0.8
> >     Reporter: Trustin Lee
> >     Assignee: Trustin Lee
> >      Fix For: 0.9
> >
> > MINA 0.8 provides only per-sessionmanager filter chain which is
> not so useful.  So we need to replace it with per-port filter chain
> this:
> > * IoFilterChain IoSessionManager.getFilterChain(SocketAddress
> > This method will behave a little bit differently depending on it is
> acceptor or a connector.  For an acceptor, address will be a bind
> Otherwise, it will be a remote address.  I think this is reasonable
> and it will be fine if we document this explicitly.
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> -
> For more information on JIRA, see:

View raw message