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
