Great, that was it, thanks. Where do i find this kind of crucial
information? I didn't find it in "changes between 2.x and 1.x" neither
in "2.0 Start Guides". On closer inspection, it is scattered in the
example applications. That is, once you know what you need to look for...
Cheers, Pavel
Julien Vermillard napsal(a):
Hi,
I think in 2.0 you need to .dispose() the services, what you don't need
too do with 1.X. It's perhaps what you forgot ?
Julien
Le Mon, 06 Apr 2009 17:48:56 +0200,
Pavel Zdeněk <[email protected]> a écrit :
Hi all,
i am maintaining a small specialised MINA-backed TCP server
appliance. I wanted to upgrade from 1.1 to 2.0 RC4 and it turned out
to be somewhat complicated. CloseFuture.join() is now deprecated,
replacement by awaitUninteruptibly() induced a need for adding
ExecutorFilter to the filter chain (DIRMINA-625) :
ExecutorFilter execFilter = new ExecutorFilter();
filterChainBuilder.addLast( "threadPool", execFilter);
That solved the biggest malfunction, but a strange one remains. The
appliance is being able to shutdown in two different ways:
- reacting gracefully to all kinds of OS' shutdown signals by
Runtime.addShutdownHook
- explicit command by a simple JMX management application.
Both ways it calls the same implementation of shutdown procedure,
where indeed i close all sessions, call NioSocketAcceptor.unbind and
ExecutorFilter.destroy, in that order. JMX only adds some
NotificationBroadcasterSupport.sendNotification calls after that.
Shutdown hook works correctly as it used with MINA 1.1, but JMX does
not. The JMX management finishes correctly
(NotificationListener.handleNotification is executed with expected
parameters) but the server refuses to die. Eclipse shows two
persistent threads:
Thread [NioSocketAcceptor-1] (Running)
Thread [DestroyJavaVM] (Running)
when on suspending and inspecting the first one, it changes name and
displays a following stack trace:
Thread [pool-2-thread-1] (Suspended)
Unsafe.park(boolean, long) line: not available [native
method] LockSupport.park(Object) line: 158
AbstractQueuedSynchronizer$ConditionObject.await() line: 1925
[local variables unavailable]
LinkedBlockingQueue<E>.take() line: 358 [local variables
unavailable]
ThreadPoolExecutor.getTask() line: 946 [local variables
unavailable]
ThreadPoolExecutor$Worker.run() line: 906 [local variables
unavailable]
Thread.run() line: 619 [local variables unavailable]
Thread [DestroyJavaVM] (Running)
So it's provably linked to the ExecutorFilter which is the biggest
extra requirement since MINA 1.1. Anybody has an expertise about what
could be wrong with my usage of ExecutorFilter? Or other way, how can
i implement a synchronous wait for client close in MINA 2.0 without
need for these fancy new threading models?
Best regards,
Pavel Zdenek
