This is how I am handling the threads using the executorfilter.
acceptor.getFilterChain().addLast( "logging", new
LoggingFilter() );
acceptor.getFilterChain().addLast( "codec", new
ProtocolCodecFilter( new CentralCodecFactory(false)));
acceptor.getFilterChain().addLast("threadPool", new
ExecutorFilter(Executors.newCachedThreadPool()));
Thanks,
Rajiv
-----Original Message-----
From: Emmanuel Lécharny [mailto:[email protected]]
Sent: Monday, July 09, 2012 2:08 PM
To: [email protected]
Subject: Fwd: RE: sessionClosed called twice
CC'd the mailing list...
So does it mean that there is no tight coupling between the thread and the
session. I was under impression that a thread will be tied to a session till it
is not closed and is released to pool only after session is closed. And at this
point it is available to process other request from clients. Was my
understanding incorrect.
Thanks once again for clarification.
Regards,
Rajiv
-----Original Message-----
From: Emmanuel Lécharny [mailto:[email protected]]
Sent: Monday, July 09, 2012 2:00 PM
To: [email protected]
Subject: Re: sessionClosed called twice
Le 7/9/12 10:11 AM, Rajiv Kasera a écrit :
> HI,
>
> In continuation to further analysis I did for this issue here is my
> observation:
>
> 1. Client 1 opens a session and processes a request. Response is sent back to
> the client but for some reason client does not disconnect the socket. Let us
> name thread used for this as pool-6-thread-6634.
> 2. Now the same thread (pool-6-thread-6634) is assigned to a new request from
> a client 2 and it also completes the processing and writes back the response.
> 3. After few seconds both the sessions are closed and use the same thread id
> (pool-6-thread-6634) for disconnecting the socket.
>
> In my production environment, I could see upto 6 active sessions linked with
> the same thread ID. And then all sessions closing with a matter of few
> seconds. Is this scenario in line with the implementation of MINA or is this
> a bug. Below is an example from the production logs. Any help in this regard
> will be highly appreciated.
>
> (2012-07-03
> 18:00:56,340)(pool-6-thread-10260)(INFO)(CentralMessageHandler.java)(m
> essageReceived)(94)--IsoMessage written...Tue Jul 03 18:00:56 IST 2012
> (2012-07-03
> 18:00:58,211)(pool-6-thread-10260)(INFO)(CentralMessageHandler.java)(m
> essageReceived)(94)--IsoMessage written...Tue Jul 03 18:00:58 IST 2012
> (2012-07-03
> 18:01:01,170)(pool-6-thread-10260)(INFO)(CentralMessageHandler.java)(m
> essageReceived)(94)--IsoMessage written...Tue Jul 03 18:01:01 IST 2012
> (2012-07-03
> 18:01:06,299)(pool-6-thread-10260)(INFO)(CentralMessageHandler.java)(m
> essageReceived)(94)--IsoMessage written...Tue Jul 03 18:01:06 IST 2012
> (2012-07-03
> 18:01:06,613)(pool-6-thread-10260)(INFO)(CentralMessageHandler.java)(m
> essageReceived)(94)--IsoMessage written...Tue Jul 03 18:01:06 IST 2012
> (2012-07-03
> 18:01:11,768)(pool-6-thread-10260)(INFO)(CentralMessageHandler.java)(m
> essageReceived)(94)--IsoMessage written...Tue Jul 03 18:01:11 IST 2012
> (2012-07-03
> 18:01:12,037)(pool-6-thread-10260)(ERROR)(CentralMessageHandler.java)(sessionClosed)(117)--session
> closed
> (2012-07-03
> 18:01:15,482)(pool-6-thread-10260)(ERROR)(CentralMessageHandler.java)(
> sessionClosed)(117)--session closed
> (2012-07-03
> 18:01:17,613)(pool-6-thread-10260)(ERROR)(CentralMessageHandler.java)(
> sessionClosed)(117)--session closed
> (2012-07-03
> 18:01:19,474)(pool-6-thread-10260)(ERROR)(CentralMessageHandler.java)(
> sessionClosed)(117)--session closed
> (2012-07-03
> 18:01:21,381)(pool-6-thread-10260)(ERROR)(CentralMessageHandler.java)(
> sessionClosed)(117)--session closed
> (2012-07-03
> 18:01:21,975)(pool-6-thread-10260)(ERROR)(CentralMessageHandler.java)(
> sessionClosed)(117)--session closed
This is plain normal. Why do you think this could be a MINA bug ?
Keep in mind that a thread will be shared by many clients in MINA, otherwise it
would fallback to be a pure blocking IO system, where each connection is
assigned a thread...m
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
