[
https://issues.apache.org/jira/browse/JCS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-243.
--------------------------------
Fix Version/s: jcs-4.0
Resolution: Fixed
Fixed in Git
> 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
> Assignee: Thomas Vandahl
> Priority: Minor
> Fix For: jcs-4.0
>
>
> 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([email protected]/Native Method)
> - parking to wait for <0x00000000f1964da8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:341)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block([email protected]/AbstractQueuedSynchronizer.java:506)
> at
> java.util.concurrent.ForkJoinPool.unmanagedBlock([email protected]/ForkJoinPool.java:3476)
> at
> java.util.concurrent.ForkJoinPool.managedBlock([email protected]/ForkJoinPool.java:3447)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await([email protected]/AbstractQueuedSynchronizer.java:1630)
> at
> java.util.concurrent.LinkedBlockingQueue.take([email protected]/LinkedBlockingQueue.java:435)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask([email protected]/ThreadPoolExecutor.java:1062)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.java:1122)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.java:635)
> at java.lang.Thread.run([email protected]/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)
