directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <>
Subject Re: [MINA] 0.9.0 - Deadlock in SocketIoProcessor
Date Sat, 17 Dec 2005 08:43:22 GMT

I think there is a simple solution to your problem. Try to add a
ThreadPoolFilter to your SocketConnector's filter chain builder. That
should make the sessionClosed() call on your DestinationHandler be
handled in a different thread (not in SocketIoProcessor's worker thread).

Of course, SSLFilter shouldn't block the thread like it does right now
in initiateClosure. Your approach should work without a
ThreadPoolFilter. I don't know enough about the implementation details
of SSLFilter to say why it does block and if it could be fixed. Trustin?



Srikanth Veeramachaneni wrote:
> Subject: [MINA] 0.9.0 - Deadlock in SocketIoProcessor
> Hello,
> 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()
>  - 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.
> thanks,
> Srikanth

View raw message