You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Bruno Coelho <br...@pmelink.pt> on 2009/09/21 17:04:07 UTC
problem shuting down tomcat
hi all,
I'm having a problem shutting down the tomcat where the jackrabbit web-
app is deployed.
I have scripted a set of tests to run before and after every change in
the code.
in the script I start tomcat with the startup.sh command.
then I wait until the tomcat finishs loading and then I run the test
using junit.
after that I try to shutdown tomcat using the shutdown.sh script.
in the catalina.out log I can only see some unclosed session and
nothing else:
21.09.2009 15:16:26 *WARN * SessionImpl: Unclosed session detected.
The session was opened here: (SessionImpl.java, line 1579)
java.lang.Exception: Stack Trace
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:239)
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:255)
at org.apache.jackrabbit.core.XASessionImpl.<init>(XASessionImpl.java:
98)
at
org
.apache
.jackrabbit
.core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1456)
at
org
.apache
.jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:943)
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:
1358)
at
org
.apache
.jackrabbit.rmi.server.ServerRepository.login(ServerRepository.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:592)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport
$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:613)
...
...
...
21.09.2009 15:16:26 *INFO * SearchIndex: Index closed: /Users/bmcoelho/
opt/jackrabbit-repository-test/workspaces/default/index
(SearchIndex.java, line 678)
21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database '/Users/
bmcoelho/opt/jackrabbit-repository-test/workspaces/default/db'
shutdown. (DerbyPersistenceManager.java, line 330)
21.09.2009 15:16:26 *INFO * RepositoryImpl: workspace 'default' has
been shutdown (RepositoryImpl.java, line 1989)
21.09.2009 15:16:26 *INFO * RepositoryImpl: shutting down workspace
'security'... (RepositoryImpl.java, line 1983)
21.09.2009 15:16:26 *INFO * ObservationDispatcher: Notification of
EventListeners stopped. (ObservationDispatcher.java, line 106)
21.09.2009 15:16:26 *DEBUG* IndexMerger: dispose IndexMerger
(IndexMerger.java, line 218)
21.09.2009 15:16:26 *DEBUG* IndexMerger: quit sent (IndexMerger.java,
line 232)
21.09.2009 15:16:26 *INFO * IndexMerger: IndexMerger terminated
(IndexMerger.java, line 347)
21.09.2009 15:16:26 *DEBUG* IndexMerger: IndexMerger thread stopped
(IndexMerger.java, line 245)
21.09.2009 15:16:26 *DEBUG* IndexMerger: merge queue size: 0
(IndexMerger.java, line 247)
21.09.2009 15:16:26 *INFO * SearchIndex: Index closed: /Users/bmcoelho/
opt/jackrabbit-repository-test/workspaces/security/index
(SearchIndex.java, line 678)
21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database '/Users/
bmcoelho/opt/jackrabbit-repository-test/workspaces/security/db'
shutdown. (DerbyPersistenceManager.java, line 330)
21.09.2009 15:16:26 *INFO * RepositoryImpl: workspace 'security' has
been shutdown (RepositoryImpl.java, line 1989)
21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database '/Users/
bmcoelho/opt/jackrabbit-repository-test/version/db' shutdown.
(DerbyPersistenceManager.java, line 330)
21.09.2009 15:16:26 *INFO * RepositoryImpl: Repository has been
shutdown (RepositoryImpl.java, line 1149)
21.09.2009 15:16:26 *INFO * RepositoryStartupServlet:
RepositoryStartupServlet shut down. (RepositoryStartupServlet.java,
line 261)
Sep 21, 2009 3:16:26 PM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8180
the last entry looks that the tomcat ended just fine but if I look at
the running process tomcat is still there...
can you help me in the problem?
do you have any idea why this happens?
thank you all in advance.
cheers,
bruno coelho
Re: problem shuting down tomcat
Posted by Bruno Coelho <br...@pmelink.pt>.
thank you for the info but everything I found there tells me that the
problem is related
to some reference in the RMI server that is not unbind or unexported
properly.
I tried the following code in the RepositoryStartupServlet to see if
there were some remote object that weren't unbind or unexported but I
couldn't find any,
I inserted this line after the last line of code in the method
unregisterRMI():
try {
String[] names = registry.list();
log.info("names list lenght: " + names.length);
for(int i = 0; i < names.length; i++){
try{
log.info("trying to unbind: " + names[i]);
registry.unbind(names[i]);
log.info("trying to unexport remote obj with
name: " + names[i]);
Remote remoteobj = (Remote)
registry.lookup(names[i]);
UnicastRemoteObject.unexportObject(remoteobj,
true);
} catch(Exception ex) {
log.error("Exception " + ex);
}
}
} catch (RemoteException re) {
log.error("Remote Exception getting list: " + re);
}
but the list is empty!
so at this moment I don't know whatelse to try...
is there any other place in the code where are some objects being bind?
thanks one more time!
cheers,
bruno coelho
On Sep 22, 2009, at 4:58 PM, Sébastien Launay wrote:
> Le 22/09/2009 17:29, Bruno Coelho a écrit :
>> "RMI Reaper" prio=5 tid=0x0102cfe0 nid=0x8d2400 in Object.wait()
>> [0xb1011000..0xb1011d90]
>> at java.lang.Object.wait(Native Method)
>> - waiting on <0x29adfdd8> (a java.lang.ref.ReferenceQueue$Lock)
>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
>> - locked <0x29adfdd8> (a java.lang.ref.ReferenceQueue$Lock)
>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
>> at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:336)
>> at java.lang.Thread.run(Thread.java:613)
>
> This is the only user thread as it does not contains the "daemon"
> token.
> I don't know well how RMI and Jackrabbit works but the RMI connection
> appears to not be closed leading to this thread still alive.
>
> After googling, i find more information here:
> http://www.nabble.com/Correct-way-of-avoiding-a-shutdown-delay-caused-by-the-Reaper-thread-td5661918.html
>
> --
> Sébastien Launay
Re: problem shuting down tomcat
Posted by Sébastien Launay <se...@anyware-tech.com>.
Le 22/09/2009 17:29, Bruno Coelho a écrit :
> "RMI Reaper" prio=5 tid=0x0102cfe0 nid=0x8d2400 in Object.wait()
> [0xb1011000..0xb1011d90]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x29adfdd8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
> - locked <0x29adfdd8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
> at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:336)
> at java.lang.Thread.run(Thread.java:613)
This is the only user thread as it does not contains the "daemon" token.
I don't know well how RMI and Jackrabbit works but the RMI connection
appears to not be closed leading to this thread still alive.
After googling, i find more information here:
http://www.nabble.com/Correct-way-of-avoiding-a-shutdown-delay-caused-by-the-Reaper-thread-td5661918.html
--
Sébastien Launay
Re: problem shuting down tomcat
Posted by Bruno Coelho <br...@pmelink.pt>.
using the kill -QUIT <pid>...
just some notes:
- I'm using OraclePersistentManager
- I'm using RMI to connect to the repository... starting it with the
RepositoryStartupServlet (config in the web.xml) and
RepositoryAccessServlet to access the repository using RMI.
thanks again.
cheers,
bruno coelho
Full thread dump Java HotSpot(TM) Client VM (1.5.0_20-141 mixed mode,
sharing):
"DestroyJavaVM" prio=5 tid=0x01034a40 nid=0xb0801000 waiting on
condition [0x00000000..0xb0800060]
"RMI ConnectionExpiration-[10.100.131.165:9999]" daemon prio=5
tid=0x0104f1f0 nid=0x8c4400 waiting on condition
[0xb151b000..0xb151bd90]
at java.lang.Thread.sleep(Native Method)
at sun.rmi.transport.tcp.TCPChannel$Reaper.run(TCPChannel.java:446)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Connection(9)-10.100.131.165" daemon prio=5 tid=0x010356c0
nid=0x8c3600 runnable [0xb1194000..0xb1194d90]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
- locked <0x2a06b4e0> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:448)
at sun.rmi.transport.tcp.TCPTransport
$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:613)
"http-8180-1" daemon prio=5 tid=0x01033f30 nid=0x8bfa00 in
Object.wait() [0xb159c000..0xb159cd90]
at java.lang.Object.wait(Native Method)
- waiting on <0x2a002fa8> (a org.apache.tomcat.util.net.JIoEndpoint
$Worker)
at java.lang.Object.wait(Object.java:474)
at org.apache.tomcat.util.net.JIoEndpoint
$Worker.await(JIoEndpoint.java:423)
- locked <0x2a002fa8> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
449)
at java.lang.Thread.run(Thread.java:613)
"RMI LeaseChecker" daemon prio=5 tid=0x01034590 nid=0x8bec00 waiting
on condition [0xb161d000..0xb161dd90]
at java.lang.Thread.sleep(Native Method)
at sun.rmi.transport.DGCImpl$LeaseChecker.run(DGCImpl.java:310)
at java.lang.Thread.run(Thread.java:613)
"TP-Processor4" daemon prio=5 tid=0x010320e0 nid=0x8bb000 in
Object.wait() [0xb1419000..0xb1419d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x29e4ef38> (a org.apache.jk.common.ChannelSocket)
at java.lang.Object.wait(Object.java:474)
at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:301)
- locked <0x29e4ef38> (a org.apache.jk.common.ChannelSocket)
at
org
.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:
661)
at org.apache.jk.common.ChannelSocket
$SocketAcceptor.runIt(ChannelSocket.java:872)
at org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:613)
"http-8180-Acceptor-0" daemon prio=5 tid=0x01030860 nid=0x836e00
waiting on condition [0xb1215000..0xb1215d90]
at java.lang.Thread.sleep(Native Method)
at org.apache.tomcat.util.net.JIoEndpoint
$Acceptor.run(JIoEndpoint.java:309)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Accept-9999" daemon prio=5 tid=0x0102d960 nid=0x92f000
runnable [0xb1113000..0xb1113d90]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x29dcea38> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:340)
at java.lang.Thread.run(Thread.java:613)
"GC Daemon" daemon prio=2 tid=0x0102d3f0 nid=0x92e200 in Object.wait()
[0xb1092000..0xb1092d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x29dceb50> (a sun.misc.GC$LatencyLock)
at sun.misc.GC$Daemon.run(GC.java:100)
- locked <0x29dceb50> (a sun.misc.GC$LatencyLock)
"RMI Reaper" prio=5 tid=0x0102cfe0 nid=0x8d2400 in Object.wait()
[0xb1011000..0xb1011d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x29adfdd8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
- locked <0x29adfdd8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:336)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Accept-0" daemon prio=5 tid=0x0102cc80 nid=0x8d1600 runnable
[0xb0f90000..0xb0f90d90]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x29dcec30> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:340)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Accept-0" daemon prio=5 tid=0x0100c840 nid=0x85f000 runnable
[0xb0c8a000..0xb0c8ad90]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x29adae38> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.management.jmxremote.LocalRMIServerSocketFactory
$1.accept(LocalRMIServerSocketFactory.java:31)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:340)
at java.lang.Thread.run(Thread.java:613)
"Timer-0" daemon prio=5 tid=0x0100c480 nid=0x85e200 in Object.wait()
[0xb0c09000..0xb0c09d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x29adafe8> (a java.util.TaskQueue)
at java.util.TimerThread.mainLoop(Timer.java:509)
- locked <0x29adafe8> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:462)
"Low Memory Detector" daemon prio=5 tid=0x01009310 nid=0x818e00
runnable [0x00000000..0x00000000]
"CompilerThread0" daemon prio=9 tid=0x01008900 nid=0x818000 waiting on
condition [0x00000000..0xb0b077d8]
"Signal Dispatcher" daemon prio=9 tid=0x01008420 nid=0x817200 waiting
on condition [0x00000000..0x00000000]
"Finalizer" daemon prio=8 tid=0x01007c70 nid=0x815600 in Object.wait()
[0xb0a05000..0xb0a05d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x29a97508> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
- locked <0x29a97508> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x010078b0 nid=0x813e00 in
Object.wait() [0xb0984000..0xb0984d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x29a97590> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x29a97590> (a java.lang.ref.Reference$Lock)
"VM Thread" prio=9 tid=0x01007010 nid=0x813000 runnable
"VM Periodic Task Thread" prio=9 tid=0x0100dae0 nid=0x84d400 waiting
on condition
"Exception Catcher Thread" prio=10 tid=0x010019c0 nid=0x80ac00 runnable
On Sep 22, 2009, at 4:09 PM, Thomas Müller wrote:
> Hi,
>
> I think it's "kill -QUIT <pid>"
>
> Regards
> Thomas
>
> On Tue, Sep 22, 2009 at 5:03 PM, Sébastien Launay
> <se...@anyware-tech.com> wrote:
>> Le 22/09/2009 16:46, Bruno Coelho a écrit :
>>> I don't know how to tell apart wich ones are daemons or not... I
>>> just
>>> have the total number of thread and the total number of daemon
>>> threads
>>> (using jconsole)...
>>> so the best I can give you is a threadump of all threads. sorry
>>> about
>>> this.
>>
>> I do not see any thread about Jackrabbit nor Derby so this does not
>> seems to be a Jackrabbit related issue.
>>
>> Maybe, the jconsole connection creates a user thread which prevent
>> Tomcat from shutting down.
>>
>> If you are under UNIX a kill -KILL <tomcat-pid> will dump the JVM
>> stack trace with daemon flags in the output stream (generally
>> catalina.out).
>> If you are under Windows a CTRL+PAUSE in the tomcat console will
>> dump the same JVM stack trace with daemon flags but directly
>> into the console.
>>
>> You can try without jconsole connected to the application or without
>> JMX at all.
>> The dumped stack trace will normally contains more information.
>>
>> --
>> Sébastien Launay
>>
Re: problem shuting down tomcat
Posted by Sébastien Launay <se...@anyware-tech.com>.
Le 22/09/2009 17:09, Thomas Müller a écrit :
> Hi,
>
> I think it's "kill -QUIT <pid>"
>
> Regards
> Thomas
>
Oops yes that's right otherwise Tomcat will shutdown
but not properly ;).
kill -3 under Linux = kill -QUIT
--
Sébastien Launay
Re: problem shuting down tomcat
Posted by Thomas Müller <th...@day.com>.
Hi,
I think it's "kill -QUIT <pid>"
Regards
Thomas
On Tue, Sep 22, 2009 at 5:03 PM, Sébastien Launay
<se...@anyware-tech.com> wrote:
> Le 22/09/2009 16:46, Bruno Coelho a écrit :
>> I don't know how to tell apart wich ones are daemons or not... I just
>> have the total number of thread and the total number of daemon threads
>> (using jconsole)...
>> so the best I can give you is a threadump of all threads. sorry about
>> this.
>
> I do not see any thread about Jackrabbit nor Derby so this does not
> seems to be a Jackrabbit related issue.
>
> Maybe, the jconsole connection creates a user thread which prevent
> Tomcat from shutting down.
>
> If you are under UNIX a kill -KILL <tomcat-pid> will dump the JVM
> stack trace with daemon flags in the output stream (generally
> catalina.out).
> If you are under Windows a CTRL+PAUSE in the tomcat console will
> dump the same JVM stack trace with daemon flags but directly
> into the console.
>
> You can try without jconsole connected to the application or without
> JMX at all.
> The dumped stack trace will normally contains more information.
>
> --
> Sébastien Launay
>
Re: problem shuting down tomcat
Posted by Sébastien Launay <se...@anyware-tech.com>.
Le 22/09/2009 16:46, Bruno Coelho a écrit :
> I don't know how to tell apart wich ones are daemons or not... I just
> have the total number of thread and the total number of daemon threads
> (using jconsole)...
> so the best I can give you is a threadump of all threads. sorry about
> this.
I do not see any thread about Jackrabbit nor Derby so this does not
seems to be a Jackrabbit related issue.
Maybe, the jconsole connection creates a user thread which prevent
Tomcat from shutting down.
If you are under UNIX a kill -KILL <tomcat-pid> will dump the JVM
stack trace with daemon flags in the output stream (generally
catalina.out).
If you are under Windows a CTRL+PAUSE in the tomcat console will
dump the same JVM stack trace with daemon flags but directly
into the console.
You can try without jconsole connected to the application or without
JMX at all.
The dumped stack trace will normally contains more information.
--
Sébastien Launay
Re: problem shuting down tomcat
Posted by Bruno Coelho <br...@pmelink.pt>.
I don't know how to tell apart wich ones are daemons or not... I just
have the total number of thread and the total number of daemon threads
(using jconsole)...
so the best I can give you is a threadump of all threads. sorry about
this.
thanks a lot.
cheers,
bruno coelho
2009-09-22 15:41:15
Full thread dump Java HotSpot(TM) Client VM (1.5.0_20-141 mixed mode,
sharing):
"RMI TCP Connection(11)-10.100.131.165" - Thread t@49
java.lang.Thread.State: RUNNABLE
at sun.management.ThreadImpl.getThreadInfo0(Native Method)
at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:142)
at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:592)
at sun.management.MXBeanSupport.invoke(MXBeanSupport.java:632)
at sun.management.MXBeanSupport.invoke(MXBeanSupport.java:94)
at
com
.sun
.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:
213)
at
com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at
com
.sun
.jmx
.interceptor
.DefaultMBeanServerInterceptor
.invoke(DefaultMBeanServerInterceptor.java:815)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at
javax
.management
.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
at javax.management.remote.rmi.RMIConnectionImpl.access
$100(RMIConnectionImpl.java:81)
at javax.management.remote.rmi.RMIConnectionImpl
$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
at
javax
.management
.remote
.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:
1343)
at
javax
.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:
784)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport
$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:613)
"JMX server connection timeout 48" - Thread t@48
java.lang.Thread.State: TIMED_WAITING on [I@fe3515
at java.lang.Object.wait(Native Method)
at com.sun.jmx.remote.internal.ServerCommunicatorAdmin
$Timeout.run(ServerCommunicatorAdmin.java:150)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Connection(10)-10.100.131.165" - Thread t@47
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:
218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:
235)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:448)
at sun.rmi.transport.tcp.TCPTransport
$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:613)
"DestroyJavaVM" - Thread t@46
java.lang.Thread.State: RUNNABLE
"http-8180-1" - Thread t@40
java.lang.Thread.State: WAITING on
org.apache.tomcat.util.net.JIoEndpoint$Worker@4f092f
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at org.apache.tomcat.util.net.JIoEndpoint
$Worker.await(JIoEndpoint.java:423)
at org.apache.tomcat.util.net.JIoEndpoint
$Worker.run(JIoEndpoint.java:449)
at java.lang.Thread.run(Thread.java:613)
"RMI LeaseChecker" - Thread t@28
java.lang.Thread.State: TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at sun.rmi.transport.DGCImpl$LeaseChecker.run(DGCImpl.java:310)
at java.lang.Thread.run(Thread.java:613)
"TP-Processor4" - Thread t@23
java.lang.Thread.State: WAITING on
org.apache.jk.common.ChannelSocket@e417e7
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at
org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:301)
at
org
.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:
661)
at org.apache.jk.common.ChannelSocket
$SocketAcceptor.runIt(ChannelSocket.java:872)
at org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:613)
"http-8180-Acceptor-0" - Thread t@19
java.lang.Thread.State: TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at org.apache.tomcat.util.net.JIoEndpoint
$Acceptor.run(JIoEndpoint.java:309)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Accept-9999" - Thread t@17
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:
340)
at java.lang.Thread.run(Thread.java:613)
"GC Daemon" - Thread t@16
java.lang.Thread.State: TIMED_WAITING on sun.misc.GC
$LatencyLock@dd475a
at java.lang.Object.wait(Native Method)
at sun.misc.GC$Daemon.run(GC.java:100)
"RMI Reaper" - Thread t@15
java.lang.Thread.State: WAITING on java.lang.ref.ReferenceQueue
$Lock@779e93
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:
336)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Accept-0" - Thread t@14
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:
340)
at java.lang.Thread.run(Thread.java:613)
"RMI TCP Accept-0" - Thread t@9
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.management.jmxremote.LocalRMIServerSocketFactory
$1.accept(LocalRMIServerSocketFactory.java:31)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:
340)
at java.lang.Thread.run(Thread.java:613)
"Timer-0" - Thread t@8
java.lang.Thread.State: TIMED_WAITING on java.util.TaskQueue@4bc5a5
at java.lang.Object.wait(Native Method)
at java.util.TimerThread.mainLoop(Timer.java:509)
at java.util.TimerThread.run(Timer.java:462)
"Signal Dispatcher" - Thread t@4
java.lang.Thread.State: RUNNABLE
"Finalizer" - Thread t@3
java.lang.Thread.State: WAITING on java.lang.ref.ReferenceQueue
$Lock@9cfedf
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:
159)
"Reference Handler" - Thread t@2
java.lang.Thread.State: WAITING on java.lang.ref.Reference
$Lock@210089
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference
$ReferenceHandler.run(Reference.java:116)
On Sep 22, 2009, at 3:36 PM, Sébastien Launay wrote:
> Hi Bruno,
>
> Le 22/09/2009 16:10, Bruno Coelho a écrit :
>> with the jconsole I can see that after the shutdown script it's
>> called
>> there are still 17 or 19 threads running but only 15 or 17 are daemon
>> threads,
>> the other ones I don't know what they are.
>>
>> I suspect that the problem is related with this 2 threads that only
>> after they desapear the tomcat will die.
> Can you provide details about these 2 non deamon threads like name
> and stack trace ?
>
> --
> Sébastien Launay
Re: problem shuting down tomcat
Posted by Sébastien Launay <se...@anyware-tech.com>.
Hi Bruno,
Le 22/09/2009 16:10, Bruno Coelho a écrit :
> with the jconsole I can see that after the shutdown script it's called
> there are still 17 or 19 threads running but only 15 or 17 are daemon
> threads,
> the other ones I don't know what they are.
>
> I suspect that the problem is related with this 2 threads that only
> after they desapear the tomcat will die.
Can you provide details about these 2 non deamon threads like name
and stack trace ?
--
Sébastien Launay
Re: problem shuting down tomcat
Posted by Bruno Coelho <br...@pmelink.pt>.
hi all,
yes, I call the logout method for every session that I have created
and the problem remains...
eventually the tomcat shuts down itself after some timeout (or for any
other reason that I don't know) but only after at least 15 minutes.
with the jconsole I can see that after the shutdown script it's called
there are still 17 or 19 threads running but only 15 or 17 are daemon
threads,
the other ones I don't know what they are.
I suspect that the problem is related with this 2 threads that only
after they desapear the tomcat will die.
does anyone knows something about this?
thank you all in advance.
cheers,
bruno coelho
On Sep 22, 2009, at 10:11 AM, Nigel Sim wrote:
> I get that same issue when I try to download content from jackrabbit
> via a
> servlet. No idea why, as the logout is in the "final" clause, and I
> can
> assure you that the downloads actually work and close. I bring this
> up,
> because I don't get these straight away, only periodically (on garbage
> collection I expect), and on tomcat shutdown. Do you do anything
> similar?
>
> ObjectContentManager s = null;
> InputStream in = null;
> try {
> s = getSession();
> Node node = s.getSession().getNodeByUUID(id);
>
> // Return a blank response
> resp.setStatus(200);
> resp.setContentType("application/octet-stream");
> in = node.getProperty(data).getStream();
> IOUtils.copy(in, out);
> in.close();
> in = null;
>
> out.close();
> } catch (org.apache.jackrabbit.ocm.exception.RepositoryException e) {
> if (e.getCause() instanceof ItemNotFoundException) {
> resp.setStatus(404);
> } else {
> logger.error(e, e);
> }
> } catch (RepositoryException e) {
> logger.error(e, e); //e.printStackTrace();
> } catch (MalformedURLException e) {
> logger.error(e, e); //e.printStackTrace();
> } catch (IOException e) {
> logger.error(e, e); //e.printStackTrace();
> } finally {
> if (in != null)
> IOUtils.closeQuietly(in);
> s.logout();
> }
>
>
> 2009/9/22 Bruno Coelho <br...@pmelink.pt>
>
>> hi all,
>>
>> I'm having a problem shutting down the tomcat where the jackrabbit
>> web-app
>> is deployed.
>>
>> I have scripted a set of tests to run before and after every change
>> in the
>> code.
>>
>> in the script I start tomcat with the startup.sh command.
>> then I wait until the tomcat finishs loading and then I run the
>> test using
>> junit.
>> after that I try to shutdown tomcat using the shutdown.sh script.
>>
>> in the catalina.out log I can only see some unclosed session and
>> nothing
>> else:
>>
>> 21.09.2009 15:16:26 *WARN * SessionImpl: Unclosed session detected.
>> The
>> session was opened here: (SessionImpl.java, line 1579)
>> java.lang.Exception: Stack Trace
>> at
>> org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:239)
>> at
>> org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:255)
>> at
>> org.apache.jackrabbit.core.XASessionImpl.<init>(XASessionImpl.java:
>> 98)
>> at
>> org
>> .apache
>> .jackrabbit
>> .core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1456)
>> at
>> org
>> .apache
>> .jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:
>> 943)
>> at
>> org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:
>> 1358)
>> at
>> org
>> .apache
>> .jackrabbit.rmi.server.ServerRepository.login(ServerRepository.java:
>> 104)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:592)
>> at
>> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>> at sun.rmi.transport.Transport$1.run(Transport.java:153)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>> at
>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:
>> 466)
>> at
>> sun.rmi.transport.tcp.TCPTransport
>> $ConnectionHandler.run(TCPTransport.java:707)
>> at java.lang.Thread.run(Thread.java:613)
>>
>> ...
>> ...
>> ...
>>
>> 21.09.2009 15:16:26 *INFO * SearchIndex: Index closed:
>> /Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/default/
>> index
>> (SearchIndex.java, line 678)
>> 21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database
>> '/Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/default/
>> db'
>> shutdown. (DerbyPersistenceManager.java, line 330)
>> 21.09.2009 15:16:26 *INFO * RepositoryImpl: workspace 'default' has
>> been
>> shutdown (RepositoryImpl.java, line 1989)
>> 21.09.2009 15:16:26 *INFO * RepositoryImpl: shutting down workspace
>> 'security'... (RepositoryImpl.java, line 1983)
>> 21.09.2009 15:16:26 *INFO * ObservationDispatcher: Notification of
>> EventListeners stopped. (ObservationDispatcher.java, line 106)
>> 21.09.2009 15:16:26 *DEBUG* IndexMerger: dispose IndexMerger
>> (IndexMerger.java, line 218)
>> 21.09.2009 15:16:26 *DEBUG* IndexMerger: quit sent
>> (IndexMerger.java, line
>> 232)
>> 21.09.2009 15:16:26 *INFO * IndexMerger: IndexMerger terminated
>> (IndexMerger.java, line 347)
>> 21.09.2009 15:16:26 *DEBUG* IndexMerger: IndexMerger thread stopped
>> (IndexMerger.java, line 245)
>> 21.09.2009 15:16:26 *DEBUG* IndexMerger: merge queue size: 0
>> (IndexMerger.java, line 247)
>> 21.09.2009 15:16:26 *INFO * SearchIndex: Index closed:
>> /Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/security/
>> index
>> (SearchIndex.java, line 678)
>> 21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database
>> '/Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/security/
>> db'
>> shutdown. (DerbyPersistenceManager.java, line 330)
>> 21.09.2009 15:16:26 *INFO * RepositoryImpl: workspace 'security'
>> has been
>> shutdown (RepositoryImpl.java, line 1989)
>> 21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database
>> '/Users/bmcoelho/opt/jackrabbit-repository-test/version/db' shutdown.
>> (DerbyPersistenceManager.java, line 330)
>> 21.09.2009 15:16:26 *INFO * RepositoryImpl: Repository has been
>> shutdown
>> (RepositoryImpl.java, line 1149)
>> 21.09.2009 15:16:26 *INFO * RepositoryStartupServlet:
>> RepositoryStartupServlet shut down. (RepositoryStartupServlet.java,
>> line
>> 261)
>> Sep 21, 2009 3:16:26 PM org.apache.coyote.http11.Http11Protocol
>> destroy
>> INFO: Stopping Coyote HTTP/1.1 on http-8180
>>
>> the last entry looks that the tomcat ended just fine but if I look
>> at the
>> running process tomcat is still there...
>>
>> can you help me in the problem?
>> do you have any idea why this happens?
>>
>>
>> thank you all in advance.
>>
>>
>> cheers,
>> bruno coelho
>>
>>
>
>
> --
> JCU eResearch Centre
> School Of Business (IT)
> James Cook University
Re: problem shuting down tomcat
Posted by Nigel Sim <ni...@gmail.com>.
I get that same issue when I try to download content from jackrabbit via a
servlet. No idea why, as the logout is in the "final" clause, and I can
assure you that the downloads actually work and close. I bring this up,
because I don't get these straight away, only periodically (on garbage
collection I expect), and on tomcat shutdown. Do you do anything similar?
ObjectContentManager s = null;
InputStream in = null;
try {
s = getSession();
Node node = s.getSession().getNodeByUUID(id);
// Return a blank response
resp.setStatus(200);
resp.setContentType("application/octet-stream");
in = node.getProperty(data).getStream();
IOUtils.copy(in, out);
in.close();
in = null;
out.close();
} catch (org.apache.jackrabbit.ocm.exception.RepositoryException e) {
if (e.getCause() instanceof ItemNotFoundException) {
resp.setStatus(404);
} else {
logger.error(e, e);
}
} catch (RepositoryException e) {
logger.error(e, e); //e.printStackTrace();
} catch (MalformedURLException e) {
logger.error(e, e); //e.printStackTrace();
} catch (IOException e) {
logger.error(e, e); //e.printStackTrace();
} finally {
if (in != null)
IOUtils.closeQuietly(in);
s.logout();
}
2009/9/22 Bruno Coelho <br...@pmelink.pt>
> hi all,
>
> I'm having a problem shutting down the tomcat where the jackrabbit web-app
> is deployed.
>
> I have scripted a set of tests to run before and after every change in the
> code.
>
> in the script I start tomcat with the startup.sh command.
> then I wait until the tomcat finishs loading and then I run the test using
> junit.
> after that I try to shutdown tomcat using the shutdown.sh script.
>
> in the catalina.out log I can only see some unclosed session and nothing
> else:
>
> 21.09.2009 15:16:26 *WARN * SessionImpl: Unclosed session detected. The
> session was opened here: (SessionImpl.java, line 1579)
> java.lang.Exception: Stack Trace
> at
> org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:239)
> at
> org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:255)
> at
> org.apache.jackrabbit.core.XASessionImpl.<init>(XASessionImpl.java:98)
> at
> org.apache.jackrabbit.core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1456)
> at
> org.apache.jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:943)
> at
> org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1358)
> at
> org.apache.jackrabbit.rmi.server.ServerRepository.login(ServerRepository.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> at sun.rmi.transport.Transport$1.run(Transport.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> at java.lang.Thread.run(Thread.java:613)
>
> ...
> ...
> ...
>
> 21.09.2009 15:16:26 *INFO * SearchIndex: Index closed:
> /Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/default/index
> (SearchIndex.java, line 678)
> 21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database
> '/Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/default/db'
> shutdown. (DerbyPersistenceManager.java, line 330)
> 21.09.2009 15:16:26 *INFO * RepositoryImpl: workspace 'default' has been
> shutdown (RepositoryImpl.java, line 1989)
> 21.09.2009 15:16:26 *INFO * RepositoryImpl: shutting down workspace
> 'security'... (RepositoryImpl.java, line 1983)
> 21.09.2009 15:16:26 *INFO * ObservationDispatcher: Notification of
> EventListeners stopped. (ObservationDispatcher.java, line 106)
> 21.09.2009 15:16:26 *DEBUG* IndexMerger: dispose IndexMerger
> (IndexMerger.java, line 218)
> 21.09.2009 15:16:26 *DEBUG* IndexMerger: quit sent (IndexMerger.java, line
> 232)
> 21.09.2009 15:16:26 *INFO * IndexMerger: IndexMerger terminated
> (IndexMerger.java, line 347)
> 21.09.2009 15:16:26 *DEBUG* IndexMerger: IndexMerger thread stopped
> (IndexMerger.java, line 245)
> 21.09.2009 15:16:26 *DEBUG* IndexMerger: merge queue size: 0
> (IndexMerger.java, line 247)
> 21.09.2009 15:16:26 *INFO * SearchIndex: Index closed:
> /Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/security/index
> (SearchIndex.java, line 678)
> 21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database
> '/Users/bmcoelho/opt/jackrabbit-repository-test/workspaces/security/db'
> shutdown. (DerbyPersistenceManager.java, line 330)
> 21.09.2009 15:16:26 *INFO * RepositoryImpl: workspace 'security' has been
> shutdown (RepositoryImpl.java, line 1989)
> 21.09.2009 15:16:26 *INFO * DerbyPersistenceManager: Database
> '/Users/bmcoelho/opt/jackrabbit-repository-test/version/db' shutdown.
> (DerbyPersistenceManager.java, line 330)
> 21.09.2009 15:16:26 *INFO * RepositoryImpl: Repository has been shutdown
> (RepositoryImpl.java, line 1149)
> 21.09.2009 15:16:26 *INFO * RepositoryStartupServlet:
> RepositoryStartupServlet shut down. (RepositoryStartupServlet.java, line
> 261)
> Sep 21, 2009 3:16:26 PM org.apache.coyote.http11.Http11Protocol destroy
> INFO: Stopping Coyote HTTP/1.1 on http-8180
>
> the last entry looks that the tomcat ended just fine but if I look at the
> running process tomcat is still there...
>
> can you help me in the problem?
> do you have any idea why this happens?
>
>
> thank you all in advance.
>
>
> cheers,
> bruno coelho
>
>
--
JCU eResearch Centre
School Of Business (IT)
James Cook University
Re: problem shuting down tomcat
Posted by Sébastien Launay <se...@anyware-tech.com>.
Hi Bruno,
Le 21/09/2009 17:04, Bruno Coelho a écrit :
> hi all,
>
> in the catalina.out log I can only see some unclosed session and
> nothing else:
>
> 21.09.2009 15:16:26 *WARN * SessionImpl: Unclosed session detected.
> The session was opened here: (SessionImpl.java, line 1579)
> java.lang.Exception: Stack Trace
> at
> org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:239)
> at
> org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:255)
> at
> org.apache.jackrabbit.core.XASessionImpl.<init>(XASessionImpl.java:98)
> at
> org.apache.jackrabbit.core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1456)
>
> at
> org.apache.jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:943)
>
> at
> org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1358)
> at
> org.apache.jackrabbit.rmi.server.ServerRepository.login(ServerRepository.java:104)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:592)
> at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> at sun.rmi.transport.Transport$1.run(Transport.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>
> at java.lang.Thread.run(Thread.java:613)
This warning occurs when a session has not been closed
with session.logout() and therefore is garbage collected.
> the last entry looks that the tomcat ended just fine but if I look at
> the running process tomcat is still there...
If tomcat is still running, check if there is at least one user thread
because tomcat will really shutdown if there is only daemon threads.
Last time i checked, Jackrabbit and Derby uses only daemon threads
to prevent this behavior.
A kill -QUIT <pid> on the tomcat process launched with a Sun JVM
will dump the stack trace on the output stream (generally catalina.out)
where you can find the potential user threads.
--
Sébastien Launay