SSL handling & ExecutorFilter improvements

[Emmanuel Lécharny <el...@gmail.com>]

Hi !

Now that we are done with the releases, I'm looking at two areas that 
could be improved.

We have two scenario to co,nsider :

1) a SslFilter is used without any Executor filter in the chain

In this case, as each message is fully processed by a single thread 
(IoProcressor), there is little reason to synchronized on SslHandler: it 
will never be shared with another thread.

2) A ExecutorFilter is added in the chain after the SslFilter

Incoming messages are not really critical, they are processed fully. The 
problem is that outgoing messages may come from various threads. We 
currently use a Queue to store those messages that will be encrypted, 
one by one. That means we may have many threads other than the 
IoProcessor one that can encrypt a message, but they can only do that 
one after the other. As this queue is managed by the SslHandler 
instance, which is a session attribute, that guarantees we won't have 
intermixed message.

The only thing is that we have to protect the SslHandler instance 
against concurrent access


That being said, the key is that when a message is being encrypted, no 
other should be encrypted at the same time. I think we can ensure that 
without synchronizing the whole SslHandler instance - we already use a 
queue to store the message to be encrypted -


Regarding the ExecutorFilter, I also think it's suboptimal. Workers are 
created in a synchronized section, when we could use a concurrent Set to 
protect the concurrent access to the set of workers. Even if workers are 
not necessarily created frequently, this is not the best way to handle 
that situation.


Anyway, this is just a 10000 feet analysis, but I'd like to review all 
this part. AFAIR, Jonathan has also expressed some concerns about 
excessive synchronization in this part, so my guess is there is some 
room for improvement :-)


feel free to comment !

Thanks