[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782649#comment-17782649
]
Greg Parmiter commented on JCS-240:
-----------------------------------
[~tv] , just tested 3.2.1 and it works! Thanks for the quick turnaround. Will
3.2.1 be an official release, or will this just roll into 3.3? If the latter,
when is 3.3 set to release?
> Remote cache appears incompatible with JDK 8u241 and above
> ----------------------------------------------------------
>
> Key: JCS-240
> URL: https://issues.apache.org/jira/browse/JCS-240
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
> Affects Versions: jcs-3.2
> Reporter: Greg Parmiter
> Assignee: Thomas Vandahl
> Priority: Critical
>
> After setting up remote RMI cache, with the central cache service running in
> the same app server/JVM (JDK version 11) as ~4 clients, there were
> intermittent put and remove failures, as well as issues similar to JCS-237,
> JCS-238, and JCS-239.
> While investigating the intermittent put/remove issues, the remote server log
> showed the following-
> {code:java}
> Error while running event from Queue: PutEvent for key: key1 value: null.
> Retrying...
> java.rmi.RemoteException: Method is not Remote: interface
> org.apache.commons.jcs3.engine.behavior.ICacheListener::public abstract void
> org.apache.commons.jcs3.engine.behavior.ICacheListener.handlePut(org.apache.commons.jcs3.engine.behavior.ICacheElement)
> throws java.io.IOException
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:214)
> ~[?:?]
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162)
> ~[?:?]
> at com.sun.proxy.$Proxy2195.handlePut(Unknown Source) ~[?:?]
> at
> org.apache.commons.jcs3.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:277)
> ~[commons-jcs3-core-3.2.jar:3.2]
> at
> org.apache.commons.jcs3.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:216)
> ~[commons-jcs3-core-3.2.jar:3.2]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:829) ~[?:?]{code}
> This pointed to an incorrect listener being registered from the client(s),
> but when debugging, I saw that the clients were registering the correct
> listener type, which implements the Remote interface-
> {code:java}
> listener =
> RemoteCacheListener:
> AbstractRemoteCacheListener:
> RemoteHost = localhost:1101
> ListenerId = 4 {code}
> I understand there's a class hierarchy in place where the RemoveCacheListener
> implements the IRemoteCacheListener interface, which is a sub-interface of
> Remote, but therein lies the issue. When the event queue is being processed
> at runtime and the ICacheListener is being proxied to the appropriate
> concrete class, the JVM does not recognize the sub-interface and thus, the
> Remote interface is not seen. *The appears to occur in JDK 11 JVMs but not
> JDK 8. In other words, JCS 3.2 remote cache does not appear to work properly
> in JDK 11 (and higher?) runtimes.*
> I "resolved" this by implementing the Remote interface in the ICacheListener,
> and this actually resolved JCS-237, JCS-238, and JCS-239. That said, it's
> likely not the optimal solution here. Another option-
> Create another abstract class, AbstractRemoteCacheEventQueue, that passes the
> IRemoteCacheListener rather than the base ICacheListener to the applicable
> listener. This would obviously have to be added into the appropriate place(s)
> in the hierarchy (i.e., RemoteCacheListener, etc.).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
