[jira] [Commented] (JCS-243) JCS version 3.2.1 causes thread leak in remote cache server

["Thomas Vandahl (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986530#comment-17986530 ] 

Thomas Vandahl commented on JCS-243:
------------------------------------

Hello Henrik,

thanks for bringing this to our attention. The basic issue is probably related to JCS-240. Would it be possible to provide a test of some sorts, so that we avoid these problems in the future?


> JCS version 3.2.1 causes thread leak in remote cache server
> -----------------------------------------------------------
>
>                 Key: JCS-243
>                 URL: https://issues.apache.org/jira/browse/JCS-243
>             Project: Commons JCS
>          Issue Type: Bug
>          Components: RMI Remote Cache
>    Affects Versions: jcs-3.2.1
>            Reporter: Henrik Hiltunen
>            Priority: Minor
>
> Hello development team!
> When JCS went from version 2.x to 3.x there were some issues with RMI code not being migrated to the new version and remote caching did not work. Some of there issues were addressed with version 3.2.1, but not all it seems. We tried to upgrade to version 3.2.1 and it all seemed fine, at first, but after a little while we noticed that the cache server thread count would start to increase, and would not stop until the application crashed. There were no exceptions in the logs, but after some digging we could see that some classes in the org.apache.commons.jcs3.auxiliary.remote package still does not implement the Remote interface. Most likely the remote call would not close correctly just hang. I did a thread analysis and all hanging threads have the same stack
> {code:java}
> stackTrace:
> java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@17.0.13/Native Method)
> - parking to wait for <0x00000000f1964da8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(java.base@17.0.13/LockSupport.java:341)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base@17.0.13/AbstractQueuedSynchronizer.java:506)
> at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base@17.0.13/ForkJoinPool.java:3476)
> at java.util.concurrent.ForkJoinPool.managedBlock(java.base@17.0.13/ForkJoinPool.java:3447)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@17.0.13/AbstractQueuedSynchronizer.java:1630)
> at java.util.concurrent.LinkedBlockingQueue.take(java.base@17.0.13/LinkedBlockingQueue.java:435)
> at java.util.concurrent.ThreadPoolExecutor.getTask(java.base@17.0.13/ThreadPoolExecutor.java:1062)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.13/ThreadPoolExecutor.java:1122)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.13/ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(java.base@17.0.13/Thread.java:840) {code}
> In our own logs we also had this exception during shut down.
> {code:java}
> May 14, 2025 8:40:01 AM org.apache.commons.jcs3.auxiliary.remote.server.RemoteCacheServerFactory 
> SEVERE: Problem calling shutdown.
> java.rmi.RemoteException: Method is not Remote: interface org.apache.commons.jcs3.engine.behavior.ICacheServiceAdmin::public abstract void org.apache.commons.jcs3.engine.behavior.ICacheServiceAdmin.shutdown() throws java.io.IOException
>         at java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:212)
>         at java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:160)
>         at jdk.proxy1/jdk.proxy1.$Proxy0.shutdown(Unknown Source)
>         at org.apache.commons.jcs3.auxiliary.remote.server.RemoteCacheServerFactory.main(RemoteCacheServerFactory.java:404)
>  {code}
>  
> So, perhaps it would make sense to go through the code and make sure that Remote is implemented where it's supposed to.
> Thank you and kind regards,
> Henrik



--
This message was sent by Atlassian Jira
(v8.20.10#820010)