You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by Pavel Zdeněk <pa...@gmail.com> on 2009/04/06 17:48:56 UTC
Cannot shutdown daemon over JMX after upgrade to MINA 2.0RC4
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
Re: Cannot shutdown daemon over JMX after upgrade to MINA 2.0RC4
Posted by Emmanuel Lecharny <el...@apache.org>.
2009/4/7 Pavel Zdeněk <pa...@gmail.com>:
> 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...
Maybe you might want to drop a few lines explaining the difference
between MINA 1 and 2, lines which will be included on the wiki.This
would help all of us to get the documentation up to date.
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Cannot shutdown daemon over JMX after upgrade to MINA 2.0RC4
Posted by Pavel Zdeněk <pa...@gmail.com>.
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 <pa...@gmail.com> 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
>>
>>
>>
>>
>>
Re: Cannot shutdown daemon over JMX after upgrade to MINA 2.0RC4
Posted by Julien Vermillard <jv...@archean.fr>.
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 <pa...@gmail.com> 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
>
>
>
>