Re: 2.0.0-RC1 bug? --> IoConnectot.dispose blocks forever?

[Alexander Christian]

Are there any new findings about that?

br and a happy new year,
Alex


Emmanuel LŽcharny schrieb:

Alexander Christian a écrit :

Hi there,

I now found time to build a small reproducer... (I hope attachments are
working properly in this mailinglist?!)

Yes, it went through :)

It's a tiny maven project, containing a echo-server and a simple client
that just sends "Hello World" and exits.
Run the client&server with MINA 2.0.0-M6 and you will see, the client
terminates after sending the message.

Try the same with 2.0.0-RC1. The clients hangs in the connector.dispose()

call.
I hope someone has to to look into :-)

Will give it a try asap.

Thanks !

best regards and merry christmas,

Alex



On Sun, 13 Dec 2009 15:41:07 +0100, Alexander Christian <a...@root1.de>
wrote:

Hey there,

Am I the only one who faced this problem? No comments? No problems?

br,
Alex



Alexander Christian schrieb:

Hi there,

I recently switched from 2.0.0-M6 to 2.0.0-RC1 and now discovered a
problem with the IoConnector (I'm using the nio stuff)...

I'll try to explain:

In case of network connection shutdown I try to clean up as good as
possible. I terminate tread pools, I close the session, and finally I

try

to dispose the IoConnector.
Here's a small code-snippet from my shutdown-code:

----
CloseFuture closeFuture = ctsc.getSession().close(false);

                    closeFuture.addListener(new
IoFutureListener<IoFuture>() {

                        public void operationComplete(IoFuture future)

{

ctsc.getFilterchainWorkerPool().shutdown();

                            System.out.println("managed session count=
"+ctsc.getConnector().getManagedSessionCount());
                            ctsc.getConnector().dispose();
                        }
                    });
----

"ctsc" is a simple container which contains the session (getSession)

and

the used connection (getConnector). First I try to close the session.
Then,
if this operation is completed, I try to shutdown a thread pool and
finally
dispose the connector. I read in the api doc, that this dispose call

may

block in case of still open session related to this connector.

I tried to print out the number of still open sessions. On the console

I

get: "managed session count= 0"
But the next call, the dispose() call, blocks and prevents the

remaining

threads from shutdown to get a clean application termination.

If I switch from RC1 backt o M6, this works quite well.
Am I doing something wrong? Has the behavior changed? *little bit
confused*

br,
Alex

>