On Fri, 14 Nov 2008 16:35:43 +0100, Emmanuel Lecharny <[EMAIL PROTECTED]>
wrote:
>> As far as I understood the apidoc, the events are forwarded in the same
> order they arrive. So the whole stuff seems to be "synchronized" again
and the
>> streams did not get corrupted.
> only on a single session. But as you mau have many sessions, and a
> limited number of processors, adding an executorFilter will spread the
> sessions decoding on many threads, potentially increasing the
scalability.
Ah, okay, that makes sense. Without this pool, all packets of all sessions
are processed by ONE thread. Okay. Now I see.
>> So what's then the benefit of the
>> OrderedThreadPoolExecutor?
>>
> Mainly to keep the packates ordered within a single session.
So, for instance, if the system would be designed so that only one client
can connect, the would be no additional performance by using the
OrderedExecutorFilter. But with multi-session system, the additional
performance would be visible...
>> I'm a little bit confused about this.
>>
> It's confusing, I agree. Lack of samples and spare doco does not help
> too...
You're right. MINA is a really great framework, and my library benefits
from it massively. But it's not that easy to get a application, bigger than
the samples working. The thing I'm mostly missing is the JavaDoc in several
source files.
But i'm quite this this will improve with the next release ?!
br,
Alex
--
It's not a bug. It's a feature!
