directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srikanth Veeramachaneni <>
Subject [MINA] 0.9.0 - Deadlock in SocketIoProcessor
Date Sat, 17 Dec 2005 02:00:26 GMT
Subject: [MINA] 0.9.0 - Deadlock in SocketIoProcessor


I am trying to build a prototype using MINA for a proxy-like server.
The role of the proxy server is to communicate with the client using SSL
and act as a proxy to the application server communicating with it using
plain TCP.

             TCP/SSL                           TCP
  Client -----------------> Proxy Server -----------> Application Server

I initially started with MINA 0.8.1 and was successful doing so. I recently
upgraded to 0.9.0 and am facing the following problem.

Terms used:

Source Session      - The SSL io session created when a client connects.
Source Handler      - The handler for source sessions.
Destination Session - The io session created to the application server
Destination Handler - The handler for destination sessions.

Implementation Details:

I haven't customized any of the MINA settings and so am mostly using the
defaults. So the number of threads in the SocketIoProcessor is 1.

Once the handshake is completed for the source session a destination session
is created to the application server using SocketConnector and attributes are
set so that the source and destination sessions have references to each other.

Data is piped to each other in the source and destination handlers.
Also in each sessionClosed() method of the handlers the other session is closed.

The Problem Scenario:

 - the destination session is closed for some reason by the application server
 - the sessionClosed() method of the DestinationHandler is invoked by the
   SocketIoProcessor worker thread as designed.
 - The DestinationHandler.sessionClosed() method invokes sourceSession.close()
   at which point a deadlock is occurring.

I have tried to debug what the problem is and here is what I found.

 - Since the source session is an SSL session, SSLFilter is in the filter chain.
 - the close() invocation gets propagated down the chain to
 - SSLFilter.filterClose() invokes initiateClosure()
 - SSLFilter.initiateClosure() invokes SSLHandler.closeOutbound() which creates
   SSL close_notify message to be written to the session
 - SSLFilter.initiateClosure() then invokes SSLHandler.writeNetBuffer() which
   creates a WriteFuture event for the data that needs to be written.
 - SSLFilter.filterClose() then invokes WriteFuture.join() to wait for the
   WriteFuture to complete.
 - Since the worker thread of the SocketIoProcessor is the one that invoked
   SSLFilter.filterClose() in the first place it waits here and never gets
   to process the scheduled write, there by waiting for it selves and causing
   a deadlock.

Potential solutions that I thought about:

 - Use the features in SocketIoProcessor to increase the number of worker
   threads. But I realized that this will not solve my problem because there is
   no guarantee that the Source Session and the Destination Session will be
   allocated to different worker threads.
 - Create an implementation of SSLFilter overriding the filterClose() method not
   to do the join(). I haven't researched as to why the join was being done in
   the first place. Assuming that there is a good reason to do so, this solution
   might break something else.
 - Create an implementation of ThreadPoolFilter in which filterClose() events
   will also be handled by the worker threads of the thread pool.

I am hoping that there is something simple that I am not doing,
that is causing this problem.

Please advise the best way to overcome this problem.


View raw message