On 9/7/11 1:18 PM, Antonio Rodriges wrote:
Add an executor in your filter chain, but be careful : if you have to deal
with concurrent requests on the same session, then use a
OrderedThreadPoolExecutor.
You can add this executor at the last position in your chain.
How this will help to avoid herd effect? It is expected to have
requests to the same database from several different clients, and,
thus, sessions.
If a session is executed in its own thread, then another request for
another session can be processed by another thread.
But if your DB is the bottleneck, you are dead anyway.
Note that you may have trouble if some requests are very slow, because you
will have many threads running in parallel.
Also keep in mind that there is a backlog of incoming requests, so you won't
usually lose any requests. The only problem is that one costly request will
slow down all the others.
That's it. For example, I have 2 databases and 2 thread for each DTB1
and DTB2 with two queues for these threads: DTB_Q1 and DTB_Q2.
In this situation I need only a single separate thread which handles
incoming requests from all possible sessions and determines the queue
to place query on. This thread is very fast and it is always
available. DTB1,2 are very slow. So, for a database I will always have
a single point of query source (DTB_Q1,2) which eliminates herd
effect.
So, is there a more graceful solution with Mina to do that?
MINA is not the issue here. You have to be able to deteminate which DB
you will talk to, and it's your application business, not MINA's.
Keep in mind that MINA is *just* a NIO framework, it won't brew your
coffee...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
