I tried to create a separate thread, pass it session reference and write in that thread an output via that reference and it works. Though I'm not sure whether Mina expects this or this just works.
2011/9/12 Hu, Mei Mei <[email protected]>: > I don't quite agree with ExecutorFilter approach. MINA is a NETWORK framework > for handling the transport level matters. For application level logic such as > access database, I think IOHandler is the place to go where you should > separate the handling from MINA - creating your own threads ... finally send > back response through session. > > > Just my 2 cents. > > > > -----Original Message----- > From: Emmanuel Lécharny [mailto:[email protected]] > Sent: Wednesday, September 07, 2011 7:43 AM > To: [email protected] > Subject: Re: "session.write" not in "messageReceived" > > 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 > > -- Kind regards, Antonio Rodriges
