Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43A3CFAA.5090003@trillian.se>
Date: Sat, 17 Dec 2005 09:43:22 +0100
From: Niklas Therning <niklas@trillian.se>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [MINA] 0.9.0 - Deadlock in SocketIoProcessor
References: <4cdd6f370512161800j27aa7efawd2ac3a5c065153ab@mail.gmail.com>
In-Reply-To: <4cdd6f370512161800j27aa7efawd2ac3a5c065153ab@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

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?

HTH

/Niklas

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
>