Le 11/02/16 10:10, Norbert Irmer a écrit : > If you look at the stacktraces, I sent in my previous mails, you see, that > the order, in which the > filters are called, is right: > > When receiving: > > ... > at > org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:310) > <----------- SslFilter > at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:534) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943) > at > org.apache.mina.proxy.filter.ProxyFilter.messageReceived(ProxyFilter.java:153) > > <--- ProxyFilter > ... > > > When sending: > > --- > at org.apache.mina.proxy.filter.ProxyFilter.writeData(ProxyFilter.java:208) > <-------- ProxyFilter > - waiting to lock <0x000000076ef8b1d8> (a > org.apache.mina.proxy.handlers.socks.Socks4LogicHandler) > at org.apache.mina.proxy.filter.ProxyFilter.filterWrite(ProxyFilter.java:192) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:625) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:48) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:953) > at > org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:316) > at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:653) > <---- SslFilter > .... > > > I am only writing the client part of an application. I communicate with a > FIX/SSL server behind a SOCKS proxy, > so I cannot change the order in which Ssl encryption and proxy framing must > be done. Ok, I *think* that the problem is due to the fact that the flushScheduledEvents() method was not protecting writes *and* reads, so they can be executed at the same time by two threads. Then what happens is that both reach the ProxyFilter synchronized section,
FixMessageProcessor takes the SslHandler lock FixMessageProcessor takes the ProxyFilter lock and at the same time : NioProcessor takes the ProxyFilter lock NioProcessor takes the SslHandler lock resulting in a Deadlock. NioProcessor ---->[ProxyFilter]--->[SslHandler]----> IoHandler NioProcessor <----[ProxyFilter]<---[SslHandler]<---- IoHandler The new version I have put on http://people.apache.org/~elecharny should solve the problem : instead of getting the lock whe we enter in the flushScheduledEvents() event, we exit immediately, doing nothing but incrementing the number of scheduled-events, instead of getting the lock. That means the thread which actually hold this lock will process all the enqueued messages itself, until the counter get down to 0. Can you give this version a try ?
