Well, Niklas, it is perfectly clear now for me. I was making the join just to be sure the session were closed when my business approach tells me the server should not accept any new connexion.
I have try to remove this join and it did the trick. I am a bit confused, also I used join() when I want to be sure something appened (specially the last write call when I must finished a session). I still have one question : - If I close the session in sessionCreated (without join of course), will it fire anyway the messageReceived call ? At the time writing, I set a special object in the session that I test in the beginning of every messagedReceived, just in case it could be fired even if the session is already closed. That's why before I wrote the join to be sure the session were closed. Anyway, thanks a lot for this perfect explanation. The bug can be closed ! Frederic Selon "Niklas Therning (JIRA)" <[EMAIL PROTECTED]>: > [ > http://issues.apache.org/jira/browse/DIRMINA-246?page=comments#action_12430418 > ] > > Niklas Therning commented on DIRMINA-246: > ----------------------------------------- > > Maybe I should have explained a bit more in depth. :) Each SocketAcceptor > starts an internal worker thread which handles incoming connections on the > ports you bind to. When a new connection is established the worker thread > will wrap it in a MINA Session object and call sessionCreated() on its filter > chain which ultimately is handled by your IoHandler implementation. It is > important to note that sessionCreated() will always be called within this > worker thread, even if you have a ThreadPoolFilter in your filter chain. > > After the call to sessionCreated() the worker thread will hand over the new > MINA Session to a SocketIoProcessor which handles all other events on the > session. The SocketIoProcessor has its own internal worker thread which will > fire events like messageReceived and messageSent when bytes have been > received and sent on a connection. It will also handle calls to > session.close(). > > Since you call session.close() from within the SocketAcceptor's worker thread > the session has not yet been added to a SocketIoProcessor. Remember that it > is the SocketIoProcessor which handles the close() call (and notifies the > CloseFuture). If you also join() on the CloseFuture returned by > session.close() your code will hang until the session has been added to the > SocketIoProcessor. But your code also blocks the thread which is responsible > for adding the session the SocketIoProcessor. The call to join() will never > return! > > unbindAll() doesn't return until all ports have been unbound by the > SocketAcceptor's worker thread. But the worker is hanging indefinitely on the > CloseFuture. This is why your server freezes. > > I hope this wasn't too much information! :) My suggestion is that you avoid > the join(). In fact, in most cases we discourage users to make blocking calls > in any of the IoHandler callbacks. This is particularly important for > sessionCreated() since it is called from within the acceptor's worker thread > even if there's a ThreadPoolFilter in the filter chain. > > > MINA (0.9.4) blocks with unbindAll while serveral clients were connected > > ------------------------------------------------------------------------ > > > > Key: DIRMINA-246 > > URL: http://issues.apache.org/jira/browse/DIRMINA-246 > > Project: Directory MINA > > Issue Type: Bug > > Affects Versions: 0.9.4 > > Environment: Windows XP, JDK 1.5.06 > > Reporter: Frederic Bregier > > Attachments: 2dumps.txt > > > > > > After a post on the mailing list, as asked, I post a JIRA request: > > I wanted to offer a function to shutdown gracefully the server, > > that is to say that the server doesn't accept new connection, > > but does let already connected client to finished correctly > > their session (which are multi messages related). > > In the beginning I used: > > - setDisconnectOnUnbind(false) > > - unbindAll() > > - wait in my business logic that all already connected users shutting down > > - setDisconnectOnUnbind(true) > > - unbindAll() > > I've got a lot of freeze (using 6 clients making a lot of messages) > > in either the first or the second unbindAll(). > > So I simplify like this: > > - I am waiting in my business logic that all already connected users > shutting > > down and does not accept new connection by hand (business logic). > > To make that, when I have the global static boolean shutdown as True, > > every new connexion are immediately closed by the server. > > Also, every pending connexion will finished their session, and when > > finished, the server also closed the connexion. > > The session used to send the shutdown order is closed immediately > > after receiving the order. > > - setDisconnectOnUnbind(true) > > - unbindAll() > > I still have easily a freeze in the server during the call to > > unbindAll(). > > - If I have only 1 client, unbindAll is never blocking. > > - If I have 2 to 6 clients, making their stuff, they all disconnected > > correctly from the server (the server is closing the session itself). > > I saw that every clients are getting correctly the closed event. > > But the server often blocks during the call of unbindAll(). > > I am no able at this time to see where is the problem in MINA. > > Everything seems ok for me from the point of vue of a programmer > > using MINA. But I surely make some mistakes since it seems > > that I am the only one to have this problem. > > Could it be related to the fact that this is the server that is > > forcing the close of the session ? > > The only thing I can tell now is that it is blocling during the > > call of unbindAll() in the server part. > > I attached two thread dumps in one file : the first is when the server is > > completely started and functionnal, the second after it blocks. > > I generate these dump using jdb since I was not able to generate them > directly). > > I hope this can clarify where is the problem. > > Frederic Bregier > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >
