So I tried acquiring the lock (added a new session attribute in sessionCreated as suggested) when the encoder A starts encoding and unlock after encoder B has written its output. However that didn't fix the problem. In fact I then also some exceptions where a thread was trying to unlock a resource it didn't own. I suppose it means that its not guaranteed that the same thread will encode a message through all the filters. Finally I synchronized the method that writes to a session in IoHandler itself and the problem appears to have gone. I was able to do its since I was already maintaining a wrapper around each IoSesion for some business logic - and everywhere I needed to write to a session, it was going through this wrapper.
On Wed, Nov 28, 2012 at 9:50 PM, Emmanuel Lécharny <elecha...@gmail.com>wrote: > Le 11/28/12 5:10 PM, Dhruv Chopra a écrit : > > It's difficult to tell what's going wrong without more information. Can > > you tell us more ? > > *- The use case is that the IoHandler upon receipt of a message, > broadcasts > > a message of type 'K' to a set of clients. It does so by looping through > > all the IoSessions belonging to that set of clients and calling write on > > them with this object of type 'K'. Encoder A accepts messages of type 'K' > > as input. Encoder A then encodes the message into type 'X' and writes it > to > > the given ProtocolEncoderOutput for encoder B to consume (As described > > earlier). Anything specific you would like me to tell you? Or what else I > > could log that could help.* > > If you do that, under heavy load, it's likely that a client from another > session sends a message, and tries to write. If those two operations > (your own thread injecting some message in another session's write > queue, and the session's handling an incoming message) are to happen at > the same time, you may have some collision. > > May be adding a shared lock in the session's attributes which is hold by > your thread when you write could help... > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
