[jira] [Resolved] (JCS-235) Thread leakage in JCS 3.1 with primary and secondary server configuration
[ https://issues.apache.org/jira/browse/JCS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-235. Fix Version/s: jcs-3.2.1 Resolution: Cannot Reproduce > Thread leakage in JCS 3.1 with primary and secondary server configuration > - > > Key: JCS-235 > URL: https://issues.apache.org/jira/browse/JCS-235 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Amol D >Priority: Major > Fix For: jcs-3.2.1 > > Attachments: JCS_3.1_HeapDump.log, client-remoet-cache.ccf, > primaryserver-remote-cache.ccf, secondaryserver-remote-cache.ccf > > > We are using Apache JCS as a primary cache server in our application. The > version we are using is apache-commons-jcs3 3.1. On production environment we > have observed that this specific version is having a thread leakage issue > where on the production servers, the thread count is increasing rapidly and > reaching 2 threads, and the system crashes due to the OutOfMemory error. > It is observed while degrading the JCS version from 3.1 to 3.0. The problem > is no longer reproducible. With the JCS 3.1 version we have also tried > implementing thread pooling, but it did not solve the problem . > Steps to reproduce - > 1) JCS configured to have primary and failover server > Please refer cache.ccf configurations attached > Check thread count via command > ps -o pid,comm,user,thcount -p > 2) Restart Primary server > After certain usage by JCS client check the thread count via below command > ps -o pid,comm,user,thcount -p > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-240.
Fix Version/s: jcs-3.2.1
Resolution: Fixed
Fixed in release 3.2.1
> 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
> Fix For: jcs-3.2.1
>
>
> 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)
[jira] [Comment Edited] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782280#comment-17782280
]
Thomas Vandahl edited comment on JCS-240 at 11/4/23 5:15 PM:
-
See https://bugs.openjdk.org/browse/JDK-8237213 for an explanation. The issue
JDK-8237213 hints that Java 8 from Update 241 on will show this behaviour, too,
as will JDK 11.0.6.
The recommended way of resolving this is to redeclare the methods to be called
remotely.
For the record: The actual cause seems to be the fix for
https://bugs.openjdk.java.net/browse/JDK-8230967 which is not public,
unfortunately.
was (Author: tv):
See https://bugs.openjdk.org/browse/JDK-8237213 for an explanation. The issue
JDK-8237213 hints that Java 8 from Update 241 on will show this behaviour, too.
The recommended way of resolving this is to redeclare the methods to be called
remotely.
> 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)
[jira] [Commented] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782909#comment-17782909
]
Thomas Vandahl commented on JCS-240:
I'm planning to release this as a patch release 3.2.1 because I consider this a
quite serious problem. I will be trying to find some time in next weeks.
> 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)
[jira] [Commented] (JCS-235) Thread leakage in JCS 3.1 with primary and secondary server configuration
[ https://issues.apache.org/jira/browse/JCS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782321#comment-17782321 ] Thomas Vandahl commented on JCS-235: [~Amol D]: Any news? Did the workaround help? > Thread leakage in JCS 3.1 with primary and secondary server configuration > - > > Key: JCS-235 > URL: https://issues.apache.org/jira/browse/JCS-235 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Amol D >Priority: Major > Attachments: JCS_3.1_HeapDump.log, client-remoet-cache.ccf, > primaryserver-remote-cache.ccf, secondaryserver-remote-cache.ccf > > > We are using Apache JCS as a primary cache server in our application. The > version we are using is apache-commons-jcs3 3.1. On production environment we > have observed that this specific version is having a thread leakage issue > where on the production servers, the thread count is increasing rapidly and > reaching 2 threads, and the system crashes due to the OutOfMemory error. > It is observed while degrading the JCS version from 3.1 to 3.0. The problem > is no longer reproducible. With the JCS 3.1 version we have also tried > implementing thread pooling, but it did not solve the problem . > Steps to reproduce - > 1) JCS configured to have primary and failover server > Please refer cache.ccf configurations attached > Check thread count via command > ps -o pid,comm,user,thcount -p > 2) Restart Primary server > After certain usage by JCS client check the thread count via below command > ps -o pid,comm,user,thcount -p > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-236) Request support for JDK17/Jakarta in JCS3.1
[ https://issues.apache.org/jira/browse/JCS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782320#comment-17782320 ] Thomas Vandahl commented on JCS-236: At the current time, there is no plan for this. > Request support for JDK17/Jakarta in JCS3.1 > --- > > Key: JCS-236 > URL: https://issues.apache.org/jira/browse/JCS-236 > Project: Commons JCS > Issue Type: Dependency upgrade > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Priority: Critical > > Request support for JDK17/Jakarta in JCS 3.1. > We are upgrading our project to work with JDK17/Jakarta. We are using JCS 3.1 > in our project, which is not compatible with JDK17/Jakarta. > Hence, we request to provide support and compatible libraries for JCS 3.x > with JDK17/Jakarta. Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-236) Request support for JDK17/Jakarta in JCS3.1
[ https://issues.apache.org/jira/browse/JCS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-236. Assignee: Thomas Vandahl Resolution: Won't Fix > Request support for JDK17/Jakarta in JCS3.1 > --- > > Key: JCS-236 > URL: https://issues.apache.org/jira/browse/JCS-236 > Project: Commons JCS > Issue Type: Dependency upgrade > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Assignee: Thomas Vandahl >Priority: Critical > > Request support for JDK17/Jakarta in JCS 3.1. > We are upgrading our project to work with JDK17/Jakarta. We are using JCS 3.1 > in our project, which is not compatible with JDK17/Jakarta. > Hence, we request to provide support and compatible libraries for JCS 3.x > with JDK17/Jakarta. Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-238) Every update to JCS Remote Cache update takes nearly ~2 seconds
[ https://issues.apache.org/jira/browse/JCS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-238. Fix Version/s: (was: jcs-3.1) Assignee: Thomas Vandahl Resolution: Duplicate Work will be done in JCS-240 > Every update to JCS Remote Cache update takes nearly ~2 seconds > --- > > Key: JCS-238 > URL: https://issues.apache.org/jira/browse/JCS-238 > Project: Commons JCS > Issue Type: Question > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Assignee: Thomas Vandahl >Priority: Minor > Attachments: cache-client.ccf, cache-server.ccf > > > We are using JCS Remote Cache to have cache available for all the > applications, but the every update to the remote cache takes approximately 2 > seconds. > Attaching the client and server cache.ccf files for your reference. Please > suggest if anything in the configuration to avoid this issue. > Kindly help to avoid this delay required to update the cache. > [^cache-client.ccf] > [^cache-server.ccf] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-239) CacheAccess put/remove in one application is not getting reflected in another application
[
https://issues.apache.org/jira/browse/JCS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-239.
Assignee: Thomas Vandahl
Resolution: Duplicate
Work will be done in JCS-240
> CacheAccess put/remove in one application is not getting reflected in another
> application
> -
>
> Key: JCS-239
> URL: https://issues.apache.org/jira/browse/JCS-239
> Project: Commons JCS
> Issue Type: Bug
> Components: Composite Cache, RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Murali Thirugnanam
>Assignee: Thomas Vandahl
>Priority: Blocker
> Attachments: cache-client.ccf, cache-server.ccf
>
>
> CacheAccess put/remove in one application is not getting reflected in another
> application.
> We are using Remote Cache Server which is deployed as an application in JBoss.
> We have applications like Application1 and Application2 deployed in same
> JBoss, which uses below code snippet to put/get/remove items to remote server.
> {code:java}
> final ICompositeCacheManager cacheMgr = CompositeCacheManager.getInstance();
> final RemoteCacheAttributes rca = new RemoteCacheAttributes();
> final RemoteCacheFactory factory = new RemoteCacheFactory();
> rca.setRemoteLocation("localhost", 1101);
> rca.setCacheName("testCache");
> factory.initialize();
> final RemoteCacheManager remoteCacheMgr = factory.getManager(rca , cacheMgr ,
> new CacheEventLoggerDebugLogger(), new StandardSerializer());
> AuxiliaryCache testAuxCache =
> remoteCacheMgr.getCache(rca);
> //Put:
> CacheAccess cache = JCS.getInstance("testCache");
> cache.put(key, value);
> //Get:
> cacheValue = cache.get(key);
> //Remove:
> cache.remove(key);
> {code}
> *ISSUE:1*
> Applicaiton1:
> 1) put "element1"
> 2) get "element1"
> Application2:
> 1) get "element1"
> It is retuning null. Element is not available for Application2,
> which was put in Application1.
> *ISSUE:2*
> Assume an element "element2" is available in both the applications, If that
> element "element2" is removed from Application1, then it should not be
> available for Application2, which is expected. But the same element
> "element2" is still present in Application2.
> Problem is that an put/remove in one application is not taking effect in
> other applications.
> Attaching the cache.ccf for both server and client for your reference.
> [^cache-server.ccf]
> [^cache-client.ccf]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JCS-237) Remote Cache update makes lot of log entries
[ https://issues.apache.org/jira/browse/JCS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-237. Fix Version/s: (was: jcs-3.1) Assignee: Thomas Vandahl Resolution: Duplicate Work will be done in JCS-240 > Remote Cache update makes lot of log entries > > > Key: JCS-237 > URL: https://issues.apache.org/jira/browse/JCS-237 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Assignee: Thomas Vandahl >Priority: Critical > > Remote Cache update makes lot of warnings as below in the log file. There is > no application functionality issue due to this, but still we want to get rid > these logs. Also, confirmed that there is no null values is being passed when > updating the cache and this log is being written. > Kindly help us to avoid logging these warnings, as we are not seeing any > functionality issues. Already, tried updating the log4j2.xml to log only > FATAL, still could these warning in the log file. > == > 2023-09-18 19:17:39,085 WARNING > [org.apache.commons.jcs3.engine.AbstractCacheEventQueue] > (CacheEventQueue.QProcessor-authCacheThread-317) Error while running event > from Queue: PutEvent for key: > com.interwoven.cache.model.auth.AuthTokenCacheKey@1f85b856 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/java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:214) > at > java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162) > at deployment.cache-service.war//com.sun.proxy.$Proxy210.handlePut(Unknown > Source) > at > deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:281) > at > deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:218) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated JCS-240:
---
Assignee: Thomas Vandahl
> 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)
[jira] [Commented] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782314#comment-17782314
]
Thomas Vandahl commented on JCS-240:
Would you please try branch
[release-3.2.1|https://github.com/apache/commons-jcs/tree/release-3.2.1] and
see if it fixes your problem?
> 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
>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)
[jira] [Updated] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated JCS-240:
---
Summary: Remote cache appears incompatible with JDK 8u241 and above (was:
Remote cache appears incompatible with JDK 11+)
> 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
>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)
[jira] [Commented] (JCS-240) Remote cache appears incompatible with JDK 11+
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782280#comment-17782280
]
Thomas Vandahl commented on JCS-240:
See https://bugs.openjdk.org/browse/JDK-8237213 for an explanation. The issue
JDK-8237213 hints that Java 8 from Update 241 on will show this behaviour, too.
The recommended way of resolving this is to redeclare the methods to be called
remotely.
> Remote cache appears incompatible with JDK 11+
> --
>
> 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
>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)
[jira] [Commented] (JCS-240) Remote cache appears incompatible with JDK 11+
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782256#comment-17782256
]
Thomas Vandahl commented on JCS-240:
Hi Greg,
thank you for spotting this. I need to have a closer look.
> Remote cache appears incompatible with JDK 11+
> --
>
> 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
>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)
[jira] [Commented] (JCS-238) Every update to JCS Remote Cache update takes nearly ~2 seconds
[ https://issues.apache.org/jira/browse/JCS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776584#comment-17776584 ] Thomas Vandahl commented on JCS-238: There are lots of examples in the [docs|https://commons.apache.org/proper/commons-jcs/RemoteAuxCache.html], in the [test cases|https://github.com/apache/commons-jcs/tree/master/commons-jcs3-core/src/test/java/org/apache/commons/jcs3/auxiliary/remote] and their related [configurations|https://github.com/apache/commons-jcs/tree/master/commons-jcs3-core/src/test/test-conf]. I'd suggest, however, to take a closer look at the problem you raised in JCS-237. It might be the true reason for the difficulties you face. > Every update to JCS Remote Cache update takes nearly ~2 seconds > --- > > Key: JCS-238 > URL: https://issues.apache.org/jira/browse/JCS-238 > Project: Commons JCS > Issue Type: Question > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Priority: Minor > Fix For: jcs-3.1 > > Attachments: cache-client.ccf, cache-server.ccf > > > We are using JCS Remote Cache to have cache available for all the > applications, but the every update to the remote cache takes approximately 2 > seconds. > Attaching the client and server cache.ccf files for your reference. Please > suggest if anything in the configuration to avoid this issue. > Kindly help to avoid this delay required to update the cache. > [^cache-client.ccf] > [^cache-server.ccf] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-238) Every update to JCS Remote Cache update takes nearly ~2 seconds
[ https://issues.apache.org/jira/browse/JCS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774566#comment-17774566 ] Thomas Vandahl commented on JCS-238: First, you have configured ElementAttributes in cache-client.ccf. By specifying new ElementAttributes() in put, you will use the defaults and ignore your configuration. Are you sure you want to do that? Second, your problem may be related to JCS-237. My rough guess is that you don't have the classes of your cached objects available in the server or something similar. I'm pretty sure that this is not a problem in JCS. > Every update to JCS Remote Cache update takes nearly ~2 seconds > --- > > Key: JCS-238 > URL: https://issues.apache.org/jira/browse/JCS-238 > Project: Commons JCS > Issue Type: Question > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Priority: Minor > Fix For: jcs-3.1 > > Attachments: cache-client.ccf, cache-server.ccf > > > We are using JCS Remote Cache to have cache available for all the > applications, but the every update to the remote cache takes approximately 2 > seconds. > Attaching the client and server cache.ccf files for your reference. Please > suggest if anything in the configuration to avoid this issue. > Kindly help to avoid this delay required to update the cache. > [^cache-client.ccf] > [^cache-server.ccf] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCS-238) Every update to JCS Remote Cache update takes nearly ~2 seconds
[ https://issues.apache.org/jira/browse/JCS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-238: --- Priority: Minor (was: Major) > Every update to JCS Remote Cache update takes nearly ~2 seconds > --- > > Key: JCS-238 > URL: https://issues.apache.org/jira/browse/JCS-238 > Project: Commons JCS > Issue Type: Question > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Priority: Minor > Fix For: jcs-3.1 > > Attachments: cache-client.ccf, cache-server.ccf > > > We are using JCS Remote Cache to have cache available for all the > applications, but the every update to the remote cache takes approximately 2 > seconds. > Attaching the client and server cache.ccf files for your reference. Please > suggest if anything in the configuration to avoid this issue. > Kindly help to avoid this delay required to update the cache. > [^cache-client.ccf] > [^cache-server.ccf] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCS-238) Every update to JCS Remote Cache update takes nearly ~2 seconds
[ https://issues.apache.org/jira/browse/JCS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-238: --- Issue Type: Question (was: Bug) > Every update to JCS Remote Cache update takes nearly ~2 seconds > --- > > Key: JCS-238 > URL: https://issues.apache.org/jira/browse/JCS-238 > Project: Commons JCS > Issue Type: Question > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Priority: Major > Fix For: jcs-3.1 > > Attachments: cache-client.ccf, cache-server.ccf > > > We are using JCS Remote Cache to have cache available for all the > applications, but the every update to the remote cache takes approximately 2 > seconds. > Attaching the client and server cache.ccf files for your reference. Please > suggest if anything in the configuration to avoid this issue. > Kindly help to avoid this delay required to update the cache. > [^cache-client.ccf] > [^cache-server.ccf] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCS-238) Every update to JCS Remote Cache update takes nearly ~2 seconds
[
https://issues.apache.org/jira/browse/JCS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774367#comment-17774367
]
Thomas Vandahl edited comment on JCS-238 at 10/12/23 8:16 AM:
--
Is there any reason for not using
{code:java}
...
CacheAccess testCache = JCS.getInstance( "testCache" );
...
{code}
?
Your manual initialization does not use the settings in your configuration
file. Moreover, the direct use of the AuxiliaryCache is discouraged. You should
have a memory cache in front of every AuxiliaryCache. See the
[documentation|https://commons.apache.org/proper/commons-jcs/UsingJCSBasicWeb.html].
AuxiliaryCaches are built to be used asynchronously. So a delayed write
operation is to be expected.
was (Author: tv):
Is there any reason for not using
{code:java}
...
CacheAccess testCache = JCS.getInstance( "testCache" );
...
{code}
?
Your manual initialization does not use the settings in your configuration
file. Moreover, the direct use of the AuxiliaryCache is discouraged. You should
have a memory cache in front of every AuxiliaryCache.
AuxiliaryCaches are built to be used asynchronously. So a delayed write
operation is to be expected.
> Every update to JCS Remote Cache update takes nearly ~2 seconds
> ---
>
> Key: JCS-238
> URL: https://issues.apache.org/jira/browse/JCS-238
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Murali Thirugnanam
>Priority: Major
> Fix For: jcs-3.1
>
> Attachments: cache-client.ccf, cache-server.ccf
>
>
> We are using JCS Remote Cache to have cache available for all the
> applications, but the every update to the remote cache takes approximately 2
> seconds.
> Attaching the client and server cache.ccf files for your reference. Please
> suggest if anything in the configuration to avoid this issue.
> Kindly help to avoid this delay required to update the cache.
> [^cache-client.ccf]
> [^cache-server.ccf]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCS-235) Thread leakage in JCS 3.1 with primary and secondary server configuration
[
https://issues.apache.org/jira/browse/JCS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767179#comment-17767179
]
Thomas Vandahl commented on JCS-235:
The thread dump looks strange. Obviously, you have multiple threads for the
same CacheEventQueue which should not be possible with your configuration.
There should be exactly one "CacheEventQueue.QProcessor-<>Thread-x"
per configured cache. The thread dump shows up to 10. I suggest to investigate
this.
If you want to mimic the exact behaviour of JCS 3.0, try the following thread
pool configuration and see what happens.
{code:bash}
jcs.auxiliary.RCluster1.attributes.EventQueueType=POOLED
jcs.auxiliary.RCluster1.attributes.EventQueuePoolName=cluster_cache_event_queue
# Cluster Cache pool
thread_pool.cluster_cache_event_queue.boundarySize=0
thread_pool.cluster_cache_event_queue.useBoundary=false
thread_pool.cluster_cache_event_queue.maximumPoolSize=1
thread_pool.cluster_cache_event_queue.minimumPoolSize=0
thread_pool.cluster_cache_event_queue.keepAliveTime=1
thread_pool.cluster_cache_event_queue.startUpSize=0
thread_pool.cluster_cache_event_queue.whenBlockedPolicy=RUN
{code}
> Thread leakage in JCS 3.1 with primary and secondary server configuration
> -
>
> Key: JCS-235
> URL: https://issues.apache.org/jira/browse/JCS-235
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Amol D
>Priority: Major
> Attachments: JCS_3.1_HeapDump.log, client-remoet-cache.ccf,
> primaryserver-remote-cache.ccf, secondaryserver-remote-cache.ccf
>
>
> We are using Apache JCS as a primary cache server in our application. The
> version we are using is apache-commons-jcs3 3.1. On production environment we
> have observed that this specific version is having a thread leakage issue
> where on the production servers, the thread count is increasing rapidly and
> reaching 2 threads, and the system crashes due to the OutOfMemory error.
> It is observed while degrading the JCS version from 3.1 to 3.0. The problem
> is no longer reproducible. With the JCS 3.1 version we have also tried
> implementing thread pooling, but it did not solve the problem .
> Steps to reproduce -
> 1) JCS configured to have primary and failover server
> Please refer cache.ccf configurations attached
> Check thread count via command
> ps -o pid,comm,user,thcount -p
> 2) Restart Primary server
> After certain usage by JCS client check the thread count via below command
> ps -o pid,comm,user,thcount -p
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCS-237) Remote Cache update makes lot of log entries
[
https://issues.apache.org/jira/browse/JCS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767143#comment-17767143
]
Thomas Vandahl edited comment on JCS-237 at 9/20/23 2:43 PM:
-
The error message suggests that you have a cache listener that implements
ICacheListener where it should rather implement IRemoteCacheListener.
It is not a good sign when this warning occurs because it actually shows that
something is wrong in the implementation. Watch for the warning "Dropping Event
and marking Event Queue {0} as non-functional."
Please double-check your code.
Other than that, JCS actually uses java.util.logging by default. If you did not
call JCS.setLogSystem(LogManager.LOGSYSTEM_LOG4J2) before JCS.getInstance(...),
your log4j-configuration will not take effect.
For disabling warnings for the logger LogManager.getLog(
AbstractCacheEventQueue.class ), see the documentation of your log system.
was (Author: tv):
The error message suggests that you have a cache listener that implements
ICacheListener where it should rather implement IRemoteCacheListener.
It is not a good sign when this warning occurs because it actually shows that
something is wrong in the implementation. Watch for the warning "Dropping Event
and marking Event Queue {0} as non-functional."
Please double-check your code.
Other than that, JCS actually uses java.util.logging by default. If you did not
call JCS.setLogSystem(LogManager.LOGSYSTEM_LOG4J2) before JCS.getInstance(...),
your log4j-configuration will not take effect.
For disabling warnings for the logger LogManager.getLog(
AbstractCacheEventQueue.class ), see the documentation of your log system.
> Remote Cache update makes lot of log entries
>
>
> Key: JCS-237
> URL: https://issues.apache.org/jira/browse/JCS-237
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Murali Thirugnanam
>Priority: Critical
> Fix For: jcs-3.1
>
>
> Remote Cache update makes lot of warnings as below in the log file. There is
> no application functionality issue due to this, but still we want to get rid
> these logs. Also, confirmed that there is no null values is being passed when
> updating the cache and this log is being written.
> Kindly help us to avoid logging these warnings, as we are not seeing any
> functionality issues. Already, tried updating the log4j2.xml to log only
> FATAL, still could these warning in the log file.
> ==
> 2023-09-18 19:17:39,085 WARNING
> [org.apache.commons.jcs3.engine.AbstractCacheEventQueue]
> (CacheEventQueue.QProcessor-authCacheThread-317) Error while running event
> from Queue: PutEvent for key:
> com.interwoven.cache.model.auth.AuthTokenCacheKey@1f85b856 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/java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:214)
> at
> java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162)
> at deployment.cache-service.war//com.sun.proxy.$Proxy210.handlePut(Unknown
> Source)
> at
> deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:281)
> at
> deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:218)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCS-238) Every update to JCS Remote Cache update takes nearly ~2 seconds
[ https://issues.apache.org/jira/browse/JCS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767147#comment-17767147 ] Thomas Vandahl commented on JCS-238: I don't see anything obvious in the configuration. I'd suggest using a profiler to tackle this. Delays like these tend to be a sign of networking issues. > Every update to JCS Remote Cache update takes nearly ~2 seconds > --- > > Key: JCS-238 > URL: https://issues.apache.org/jira/browse/JCS-238 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Priority: Major > Fix For: jcs-3.1 > > Attachments: cache-client.ccf, cache-server.ccf > > > We are using JCS Remote Cache to have cache available for all the > applications, but the every update to the remote cache takes approximately 2 > seconds. > Attaching the client and server cache.ccf files for your reference. Please > suggest if anything in the configuration to avoid this issue. > Kindly help to avoid this delay required to update the cache. > [^cache-client.ccf] > [^cache-server.ccf] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-237) Remote Cache update makes lot of log entries
[
https://issues.apache.org/jira/browse/JCS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767143#comment-17767143
]
Thomas Vandahl commented on JCS-237:
The error message suggests that you have a cache listener that implements
ICacheListener where it should rather implement IRemoteCacheListener.
It is not a good sign when this warning occurs because it actually shows that
something is wrong in the implementation. Watch for the warning "Dropping Event
and marking Event Queue {0} as non-functional."
Please double-check your code.
Other than that, JCS actually uses java.util.logging by default. If you did not
call JCS.setLogSystem(LogManager.LOGSYSTEM_LOG4J2) before JCS.getInstance(...),
your log4j-configuration will not take effect.
For disabling warnings for the logger LogManager.getLog(
AbstractCacheEventQueue.class ), see the documentation of your log system.
> Remote Cache update makes lot of log entries
>
>
> Key: JCS-237
> URL: https://issues.apache.org/jira/browse/JCS-237
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Murali Thirugnanam
>Priority: Critical
> Fix For: jcs-3.1
>
>
> Remote Cache update makes lot of warnings as below in the log file. There is
> no application functionality issue due to this, but still we want to get rid
> these logs. Also, confirmed that there is no null values is being passed when
> updating the cache and this log is being written.
> Kindly help us to avoid logging these warnings, as we are not seeing any
> functionality issues. Already, tried updating the log4j2.xml to log only
> FATAL, still could these warning in the log file.
> ==
> 2023-09-18 19:17:39,085 WARNING
> [org.apache.commons.jcs3.engine.AbstractCacheEventQueue]
> (CacheEventQueue.QProcessor-authCacheThread-317) Error while running event
> from Queue: PutEvent for key:
> com.interwoven.cache.model.auth.AuthTokenCacheKey@1f85b856 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/java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:214)
> at
> java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162)
> at deployment.cache-service.war//com.sun.proxy.$Proxy210.handlePut(Unknown
> Source)
> at
> deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:281)
> at
> deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:218)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCS-237) Remote Cache update makes lot of log entries
[
https://issues.apache.org/jira/browse/JCS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767143#comment-17767143
]
Thomas Vandahl edited comment on JCS-237 at 9/20/23 2:45 PM:
-
The error message suggests that you have a cache listener that implements
ICacheListener where it should rather implement IRemoteCacheListener.
It is not a good sign when this warning occurs because it actually shows that
something is wrong in the implementation. Watch for the warning "Dropping Event
and marking Event Queue \{0\} as non-functional."
Please double-check your code.
Other than that, JCS actually uses java.util.logging by default. If you did not
call JCS.setLogSystem(LogManager.LOGSYSTEM_LOG4J2) before JCS.getInstance(...),
your log4j-configuration will not take effect.
For disabling warnings for the logger LogManager.getLog(
AbstractCacheEventQueue.class ), see the documentation of your log system.
was (Author: tv):
The error message suggests that you have a cache listener that implements
ICacheListener where it should rather implement IRemoteCacheListener.
It is not a good sign when this warning occurs because it actually shows that
something is wrong in the implementation. Watch for the warning "Dropping Event
and marking Event Queue {0} as non-functional."
Please double-check your code.
Other than that, JCS actually uses java.util.logging by default. If you did not
call JCS.setLogSystem(LogManager.LOGSYSTEM_LOG4J2) before JCS.getInstance(...),
your log4j-configuration will not take effect.
For disabling warnings for the logger LogManager.getLog(
AbstractCacheEventQueue.class ), see the documentation of your log system.
> Remote Cache update makes lot of log entries
>
>
> Key: JCS-237
> URL: https://issues.apache.org/jira/browse/JCS-237
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-3.1
>Reporter: Murali Thirugnanam
>Priority: Critical
> Fix For: jcs-3.1
>
>
> Remote Cache update makes lot of warnings as below in the log file. There is
> no application functionality issue due to this, but still we want to get rid
> these logs. Also, confirmed that there is no null values is being passed when
> updating the cache and this log is being written.
> Kindly help us to avoid logging these warnings, as we are not seeing any
> functionality issues. Already, tried updating the log4j2.xml to log only
> FATAL, still could these warning in the log file.
> ==
> 2023-09-18 19:17:39,085 WARNING
> [org.apache.commons.jcs3.engine.AbstractCacheEventQueue]
> (CacheEventQueue.QProcessor-authCacheThread-317) Error while running event
> from Queue: PutEvent for key:
> com.interwoven.cache.model.auth.AuthTokenCacheKey@1f85b856 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/java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:214)
> at
> java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162)
> at deployment.cache-service.war//com.sun.proxy.$Proxy210.handlePut(Unknown
> Source)
> at
> deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:281)
> at
> deployment.cache-service.war//org.apache.commons.jcs3.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:218)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCS-233) 3.2 Release Date?
[ https://issues.apache.org/jira/browse/JCS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-233: --- Fix Version/s: jcs-3.2 > 3.2 Release Date? > - > > Key: JCS-233 > URL: https://issues.apache.org/jira/browse/JCS-233 > Project: Commons JCS > Issue Type: Question > Components: Documentation >Reporter: Jeremy Long >Priority: Major > Fix For: jcs-3.2 > > > GitHub shows the 3.2 release: > [https://github.com/apache/commons-jcs/releases/tag/commons-jcs3-3.2] > However, 3.2 has not been pushed to central. Is the tag wrong in GitHub? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-233) 3.2 Release Date?
[ https://issues.apache.org/jira/browse/JCS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-233. Resolution: Fixed JCS 3.2 released > 3.2 Release Date? > - > > Key: JCS-233 > URL: https://issues.apache.org/jira/browse/JCS-233 > Project: Commons JCS > Issue Type: Question > Components: Documentation >Reporter: Jeremy Long >Priority: Major > Fix For: jcs-3.2 > > > GitHub shows the 3.2 release: > [https://github.com/apache/commons-jcs/releases/tag/commons-jcs3-3.2] > However, 3.2 has not been pushed to central. Is the tag wrong in GitHub? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-236) Request support for JDK17/Jakarta in JCS3.1
[ https://issues.apache.org/jira/browse/JCS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761617#comment-17761617 ] Thomas Vandahl commented on JCS-236: One comment in addition to Garys (correct) statement: The said servlet is a very simple and independent class that you can easily extract, adjust with the new imports and integrate in your code. JCS does not rely on any special servlet features. > Request support for JDK17/Jakarta in JCS3.1 > --- > > Key: JCS-236 > URL: https://issues.apache.org/jira/browse/JCS-236 > Project: Commons JCS > Issue Type: Dependency upgrade > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali Thirugnanam >Priority: Critical > > Request support for JDK17/Jakarta in JCS 3.1. > We are upgrading our project to work with JDK17/Jakarta. We are using JCS 3.1 > in our project, which is not compatible with JDK17/Jakarta. > Hence, we request to provide support and compatible libraries for JCS 3.x > with JDK17/Jakarta. Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-236) Request support for JDK17/Jakarta in JCS3.1
[ https://issues.apache.org/jira/browse/JCS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757497#comment-17757497 ] Thomas Vandahl commented on JCS-236: Can you please provide more details as to what is incompatible with JDK17? You are welcome to provide a patch. > Request support for JDK17/Jakarta in JCS3.1 > --- > > Key: JCS-236 > URL: https://issues.apache.org/jira/browse/JCS-236 > Project: Commons JCS > Issue Type: Dependency upgrade > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Murali >Priority: Critical > > Request support for JDK17/Jakarta in JCS 3.1. > We are upgrading our project to work with JDK17/Jakarta. We are using JCS 3.1 > in our project, which is not compatible with JDK17/Jakarta. > Hence, we request to provide support and compatible libraries for JCS 3.x > with JDK17/Jakarta. Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-235) Thread leakage in JCS 3.1 with primary and secondary server configuration
[ https://issues.apache.org/jira/browse/JCS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757496#comment-17757496 ] Thomas Vandahl commented on JCS-235: Could you please provide a log file showing the behaviour? Please check for the names of the threads running out. As a rule, JCS thread pools have meaningful names that relate to their usage context. Can you provide a thread dump? > Thread leakage in JCS 3.1 with primary and secondary server configuration > - > > Key: JCS-235 > URL: https://issues.apache.org/jira/browse/JCS-235 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-3.1 >Reporter: Amol D >Priority: Major > Attachments: client-remoet-cache.ccf, primaryserver-remote-cache.ccf, > secondaryserver-remote-cache.ccf > > > We are using Apache JCS as a primary cache server in our application. The > version we are using is apache-commons-jcs3 3.1. On production environment we > have observed that this specific version is having a thread leakage issue > where on the production servers, the thread count is increasing rapidly and > reaching 2 threads, and the system crashes due to the OutOfMemory error. > It is observed while degrading the JCS version from 3.1 to 3.0. The problem > is no longer reproducible. With the JCS 3.1 version we have also tried > implementing thread pooling, but it did not solve the problem . > Steps to reproduce - > 1) JCS configured to have primary and failover server > Please refer cache.ccf configurations attached > Check thread count via command > ps -o pid,comm,user,thcount -p > 2) Restart Primary server > After certain usage by JCS client check the thread count via below command > ps -o pid,comm,user,thcount -p > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-234) Imported packages for OSGi manifest incorrect
[
https://issues.apache.org/jira/browse/JCS-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-234.
Fix Version/s: jcs-3.2
Resolution: Fixed
Thanks for the patch. Fixed in Git.
> Imported packages for OSGi manifest incorrect
> -
>
> Key: JCS-234
> URL: https://issues.apache.org/jira/browse/JCS-234
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.1
>Reporter: Chris Lake
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: jcs-3.2
>
> Attachments: image-2023-05-04-11-52-45-029.png,
> image-2023-05-04-11-55-51-212.png
>
>
> The Jira ticket JCS-228 attempted to make the imported packages optional in
> OSGi Manifest.
>
> However, it appears that this was done incorrectly. The change was to add:
> {code:java}
>
> javax.servlet.*;resolution=optional,
> org.apache.commons.dbcp2.*;resolution=optional,
> org.apache.http.*;resolution=optional,
> org.apache.logging.log4j.*;resolution=optional
> {code}
> However, there should be a colon between prior to the equals:
> {code:java}
>
> javax.servlet.*;resolution:=optional,
> org.apache.commons.dbcp2.*;resolution:=optional,
> org.apache.http.*;resolution:=optional,
> org.apache.logging.log4j.*;resolution:=optional
> {code}
> Without it, we can see that the import is not considered optional:
> !image-2023-05-04-11-52-45-029.png!
> But with the colon. it is correct:
> !image-2023-05-04-11-55-51-212.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCS-234) Imported packages for OSGi manifest incorrect
[
https://issues.apache.org/jira/browse/JCS-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated JCS-234:
---
Assignee: Thomas Vandahl
> Imported packages for OSGi manifest incorrect
> -
>
> Key: JCS-234
> URL: https://issues.apache.org/jira/browse/JCS-234
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.1
>Reporter: Chris Lake
>Assignee: Thomas Vandahl
>Priority: Major
> Attachments: image-2023-05-04-11-52-45-029.png,
> image-2023-05-04-11-55-51-212.png
>
>
> The Jira ticket JCS-228 attempted to make the imported packages optional in
> OSGi Manifest.
>
> However, it appears that this was done incorrectly. The change was to add:
> {code:java}
>
> javax.servlet.*;resolution=optional,
> org.apache.commons.dbcp2.*;resolution=optional,
> org.apache.http.*;resolution=optional,
> org.apache.logging.log4j.*;resolution=optional
> {code}
> However, there should be a colon between prior to the equals:
> {code:java}
>
> javax.servlet.*;resolution:=optional,
> org.apache.commons.dbcp2.*;resolution:=optional,
> org.apache.http.*;resolution:=optional,
> org.apache.logging.log4j.*;resolution:=optional
> {code}
> Without it, we can see that the import is not considered optional:
> !image-2023-05-04-11-52-45-029.png!
> But with the colon. it is correct:
> !image-2023-05-04-11-55-51-212.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCS-233) 3.2 Release Date?
[ https://issues.apache.org/jira/browse/JCS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702541#comment-17702541 ] Thomas Vandahl edited comment on JCS-233 at 3/20/23 9:29 AM: - I'm currently not able to do a release because the settings of the commons-parent POM break my release process. The tags are the remains of a failed attempt. was (Author: tv): I'm currently not able to do a release because the settings of the commons-parent POM break my release process. > 3.2 Release Date? > - > > Key: JCS-233 > URL: https://issues.apache.org/jira/browse/JCS-233 > Project: Commons JCS > Issue Type: Question > Components: Documentation >Reporter: Jeremy Long >Priority: Major > > GitHub shows the 3.2 release: > [https://github.com/apache/commons-jcs/releases/tag/commons-jcs3-3.2] > However, 3.2 has not been pushed to central. Is the tag wrong in GitHub? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-233) 3.2 Release Date?
[ https://issues.apache.org/jira/browse/JCS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702541#comment-17702541 ] Thomas Vandahl commented on JCS-233: I'm currently not able to do a release because the settings of the commons-parent POM break my release process. > 3.2 Release Date? > - > > Key: JCS-233 > URL: https://issues.apache.org/jira/browse/JCS-233 > Project: Commons JCS > Issue Type: Question > Components: Documentation >Reporter: Jeremy Long >Priority: Major > > GitHub shows the 3.2 release: > [https://github.com/apache/commons-jcs/releases/tag/commons-jcs3-3.2] > However, 3.2 has not been pushed to central. Is the tag wrong in GitHub? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
[ https://issues.apache.org/jira/browse/JCS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-232. Fix Version/s: jcs-3.2 Assignee: Thomas Vandahl Resolution: Fixed Fixed in Git > ClassNotFoundException When Using Custom Log Adapter > > > Key: JCS-232 > URL: https://issues.apache.org/jira/browse/JCS-232 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.1 >Reporter: Jeremy Long >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.2 > > > If one implements a new logging abstraction as documented: > [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction] > Unless log4j is on the classpath a ClassNotFoundException exception is thrown > because `org/apache/logging/log4j/message/MessageFactory` does not exist and > is referenced > [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30] > > I have a library that uses sl4j and is used in several other tools - so I > thought I would make an adapter to point to slf4j: > [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will > have to add an unused dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
[
https://issues.apache.org/jira/browse/JCS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641954#comment-17641954
]
Thomas Vandahl commented on JCS-232:
My proposal would be to handle the ServiceConfigurationError like so (this is
the recommended handling according to the JavaDoc of ServiceLoader):
{code:java}
try
{
for (Iterator i = factories.iterator();
i.hasNext();)
{
try
{
LogFactory factory = i.next();
if (logSystem.equalsIgnoreCase(factory.getName()))
{
return factory;
}
}
catch (ServiceConfigurationError e)
{
continue;
}
}
}
catch (ServiceConfigurationError e)
{
throw new RuntimeException("Could not create factory
implementation for log subsystem " + logSystem, e);
}
{code}
Could you please try if that helps?
> ClassNotFoundException When Using Custom Log Adapter
>
>
> Key: JCS-232
> URL: https://issues.apache.org/jira/browse/JCS-232
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.1
>Reporter: Jeremy Long
>Priority: Major
>
> If one implements a new logging abstraction as documented:
> [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction]
> Unless log4j is on the classpath a ClassNotFoundException exception is thrown
> because `org/apache/logging/log4j/message/MessageFactory` does not exist and
> is referenced
> [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30]
>
> I have a library that uses sl4j and is used in several other tools - so I
> thought I would make an adapter to point to slf4j:
> [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will
> have to add an unused dependency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
[ https://issues.apache.org/jira/browse/JCS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641889#comment-17641889 ] Thomas Vandahl commented on JCS-232: I'd rather fix the actual problem than work around it. > ClassNotFoundException When Using Custom Log Adapter > > > Key: JCS-232 > URL: https://issues.apache.org/jira/browse/JCS-232 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.1 >Reporter: Jeremy Long >Priority: Major > > If one implements a new logging abstraction as documented: > [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction] > Unless log4j is on the classpath a ClassNotFoundException exception is thrown > because `org/apache/logging/log4j/message/MessageFactory` does not exist and > is referenced > [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30] > > I have a library that uses sl4j and is used in several other tools - so I > thought I would make an adapter to point to slf4j: > [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will > have to add an unused dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
[ https://issues.apache.org/jira/browse/JCS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641885#comment-17641885 ] Thomas Vandahl commented on JCS-232: For verification purposes, do you have a stacktrace for me? > ClassNotFoundException When Using Custom Log Adapter > > > Key: JCS-232 > URL: https://issues.apache.org/jira/browse/JCS-232 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.1 >Reporter: Jeremy Long >Priority: Major > > If one implements a new logging abstraction as documented: > [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction] > Unless log4j is on the classpath a ClassNotFoundException exception is thrown > because `org/apache/logging/log4j/message/MessageFactory` does not exist and > is referenced > [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30] > > I have a library that uses sl4j and is used in several other tools - so I > thought I would make an adapter to point to slf4j: > [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will > have to add an unused dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
[ https://issues.apache.org/jira/browse/JCS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641867#comment-17641867 ] Thomas Vandahl commented on JCS-232: I don't think so. IMO, the actual problem is the way LogFactories are instantiated. Right now, all factories are loaded using the SeviceLoader which loads the classes and tries to create an instance. So that requires the log4j2 library at runtime even if it is not used. I need to rethink the initialization process. Give me a couple of days. > ClassNotFoundException When Using Custom Log Adapter > > > Key: JCS-232 > URL: https://issues.apache.org/jira/browse/JCS-232 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.1 >Reporter: Jeremy Long >Priority: Major > > If one implements a new logging abstraction as documented: > [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction] > Unless log4j is on the classpath a ClassNotFoundException exception is thrown > because `org/apache/logging/log4j/message/MessageFactory` does not exist and > is referenced > [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30] > > I have a library that uses sl4j and is used in several other tools - so I > thought I would make an adapter to point to slf4j: > [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will > have to add an unused dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCS-231) Lateral TCP cache goes in loop and consumes all available resources
[
https://issues.apache.org/jira/browse/JCS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-231.
Fix Version/s: jcs-3.2
Resolution: Fixed
Mark this as resolved for now. Fixed in Git.
> Lateral TCP cache goes in loop and consumes all available resources
> ---
>
> Key: JCS-231
> URL: https://issues.apache.org/jira/browse/JCS-231
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.1
> Environment: Linux, Tomcat 9, Adoption JDK 11
>Reporter: Andrea Vettori
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: jcs-3.2
>
>
> Hello, we upgraded from 3.0 to 3.1 and had to go back for the following
> problem.
> With this LTCP configuration
> {{jcs.auxiliary.LTCP=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory}}
> {{jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes}}
> {{jcs.auxiliary.LTCP.attributes.TcpListenerPort=1120}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=228.5.6.8}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6782}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true}}
> {{jcs.auxiliary.LTCP.attributes.Receive=true}}
> {{jcs.auxiliary.LTCP.attributes.AllowGet=false}}
> {{jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=false}}
>
> Most of the time JCS starts with the following logs
> {{{}16-Apr-2022 14:31:04.523 INFO [main]
> org.apache.commons.jcs3.auxiliary.AuxiliaryCacheConfigurator. Using standard
> serializer
> [org.apache.commons.jcs3.utils.serialization.StandardSerializer@22aa6570] for
> auxiliary [jcs.auxiliary.LTCP]{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Instance for [] is null, creating{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Creating TCP service, lca = :1120{}}}{{{}16-Apr-2022 14:31:04.531 SEVERE
> [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService. Could
> not create sender to [] – Invalid address []{}}}{{{}16-Apr-2022 14:31:04.531
> SEVERE [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Failure, lateral instance will use zombie service{}}}{{
> java.io.IOException: Invalid address []}}{{ at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPSender.(LateralTCPSender.java:104)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService.(LateralTCPService.java:96)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.lambda$getCSNLInstance$0(LateralTCPCacheFactory.java:271)}}{{
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.getCSNLInstance(LateralTCPCacheFactory.java:251)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCacheNoWait(LateralTCPCacheFactory.java:143)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:110)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:56)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseAuxiliary(CompositeCacheConfigurator.java:450)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:234)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:157)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegions(CompositeCacheConfigurator.java:135)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.doConfigure(CompositeCacheManager.java:455)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:406)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:365)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:347)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:336)}}{{
> at
>
[jira] [Updated] (JCS-231) Lateral TCP cache goes in loop and consumes all available resources
[
https://issues.apache.org/jira/browse/JCS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl updated JCS-231:
---
Assignee: Thomas Vandahl
> Lateral TCP cache goes in loop and consumes all available resources
> ---
>
> Key: JCS-231
> URL: https://issues.apache.org/jira/browse/JCS-231
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.1
> Environment: Linux, Tomcat 9, Adoption JDK 11
>Reporter: Andrea Vettori
>Assignee: Thomas Vandahl
>Priority: Major
>
> Hello, we upgraded from 3.0 to 3.1 and had to go back for the following
> problem.
> With this LTCP configuration
> {{jcs.auxiliary.LTCP=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory}}
> {{jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes}}
> {{jcs.auxiliary.LTCP.attributes.TcpListenerPort=1120}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=228.5.6.8}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6782}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true}}
> {{jcs.auxiliary.LTCP.attributes.Receive=true}}
> {{jcs.auxiliary.LTCP.attributes.AllowGet=false}}
> {{jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=false}}
>
> Most of the time JCS starts with the following logs
> {{{}16-Apr-2022 14:31:04.523 INFO [main]
> org.apache.commons.jcs3.auxiliary.AuxiliaryCacheConfigurator. Using standard
> serializer
> [org.apache.commons.jcs3.utils.serialization.StandardSerializer@22aa6570] for
> auxiliary [jcs.auxiliary.LTCP]{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Instance for [] is null, creating{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Creating TCP service, lca = :1120{}}}{{{}16-Apr-2022 14:31:04.531 SEVERE
> [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService. Could
> not create sender to [] – Invalid address []{}}}{{{}16-Apr-2022 14:31:04.531
> SEVERE [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Failure, lateral instance will use zombie service{}}}{{
> java.io.IOException: Invalid address []}}{{ at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPSender.(LateralTCPSender.java:104)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService.(LateralTCPService.java:96)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.lambda$getCSNLInstance$0(LateralTCPCacheFactory.java:271)}}{{
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.getCSNLInstance(LateralTCPCacheFactory.java:251)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCacheNoWait(LateralTCPCacheFactory.java:143)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:110)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:56)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseAuxiliary(CompositeCacheConfigurator.java:450)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:234)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:157)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegions(CompositeCacheConfigurator.java:135)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.doConfigure(CompositeCacheManager.java:455)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:406)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:365)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:347)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:336)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.getInstance(CompositeCacheManager.java:188)}}{{
[jira] [Commented] (JCS-231) Lateral TCP cache goes in loop and consumes all available resources
[
https://issues.apache.org/jira/browse/JCS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525666#comment-17525666
]
Thomas Vandahl commented on JCS-231:
Would you please test the current master? I attempted a fix.
> Lateral TCP cache goes in loop and consumes all available resources
> ---
>
> Key: JCS-231
> URL: https://issues.apache.org/jira/browse/JCS-231
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.1
> Environment: Linux, Tomcat 9, Adoption JDK 11
>Reporter: Andrea Vettori
>Priority: Major
>
> Hello, we upgraded from 3.0 to 3.1 and had to go back for the following
> problem.
> With this LTCP configuration
> {{jcs.auxiliary.LTCP=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory}}
> {{jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes}}
> {{jcs.auxiliary.LTCP.attributes.TcpListenerPort=1120}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=228.5.6.8}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6782}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true}}
> {{jcs.auxiliary.LTCP.attributes.Receive=true}}
> {{jcs.auxiliary.LTCP.attributes.AllowGet=false}}
> {{jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=false}}
>
> Most of the time JCS starts with the following logs
> {{{}16-Apr-2022 14:31:04.523 INFO [main]
> org.apache.commons.jcs3.auxiliary.AuxiliaryCacheConfigurator. Using standard
> serializer
> [org.apache.commons.jcs3.utils.serialization.StandardSerializer@22aa6570] for
> auxiliary [jcs.auxiliary.LTCP]{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Instance for [] is null, creating{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Creating TCP service, lca = :1120{}}}{{{}16-Apr-2022 14:31:04.531 SEVERE
> [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService. Could
> not create sender to [] – Invalid address []{}}}{{{}16-Apr-2022 14:31:04.531
> SEVERE [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Failure, lateral instance will use zombie service{}}}{{
> java.io.IOException: Invalid address []}}{{ at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPSender.(LateralTCPSender.java:104)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService.(LateralTCPService.java:96)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.lambda$getCSNLInstance$0(LateralTCPCacheFactory.java:271)}}{{
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.getCSNLInstance(LateralTCPCacheFactory.java:251)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCacheNoWait(LateralTCPCacheFactory.java:143)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:110)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:56)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseAuxiliary(CompositeCacheConfigurator.java:450)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:234)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:157)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegions(CompositeCacheConfigurator.java:135)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.doConfigure(CompositeCacheManager.java:455)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:406)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:365)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:347)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:336)}}{{
> at
>
[jira] [Commented] (JCS-231) Lateral TCP cache goes in loop and consumes all available resources
[
https://issues.apache.org/jira/browse/JCS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525608#comment-17525608
]
Thomas Vandahl commented on JCS-231:
Could you please re-run the process with debug-logs enabled and post the
results here?
> Lateral TCP cache goes in loop and consumes all available resources
> ---
>
> Key: JCS-231
> URL: https://issues.apache.org/jira/browse/JCS-231
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.1
> Environment: Linux, Tomcat 9, Adoption JDK 11
>Reporter: Andrea Vettori
>Priority: Major
>
> Hello, we upgraded from 3.0 to 3.1 and had to go back for the following
> problem.
> With this LTCP configuration
> {{jcs.auxiliary.LTCP=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory}}
> {{jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes}}
> {{jcs.auxiliary.LTCP.attributes.TcpListenerPort=1120}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=228.5.6.8}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6782}}
> {{jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true}}
> {{jcs.auxiliary.LTCP.attributes.Receive=true}}
> {{jcs.auxiliary.LTCP.attributes.AllowGet=false}}
> {{jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=false}}
>
> Most of the time JCS starts with the following logs
> {{{}16-Apr-2022 14:31:04.523 INFO [main]
> org.apache.commons.jcs3.auxiliary.AuxiliaryCacheConfigurator. Using standard
> serializer
> [org.apache.commons.jcs3.utils.serialization.StandardSerializer@22aa6570] for
> auxiliary [jcs.auxiliary.LTCP]{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Instance for [] is null, creating{}}}{{{}16-Apr-2022 14:31:04.524 INFO [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Creating TCP service, lca = :1120{}}}{{{}16-Apr-2022 14:31:04.531 SEVERE
> [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService. Could
> not create sender to [] – Invalid address []{}}}{{{}16-Apr-2022 14:31:04.531
> SEVERE [main]
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.
> Failure, lateral instance will use zombie service{}}}{{
> java.io.IOException: Invalid address []}}{{ at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPSender.(LateralTCPSender.java:104)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPService.(LateralTCPService.java:96)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.lambda$getCSNLInstance$0(LateralTCPCacheFactory.java:271)}}{{
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.getCSNLInstance(LateralTCPCacheFactory.java:251)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCacheNoWait(LateralTCPCacheFactory.java:143)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:110)}}{{
> at
> org.apache.commons.jcs3.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory.createCache(LateralTCPCacheFactory.java:56)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseAuxiliary(CompositeCacheConfigurator.java:450)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:234)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:157)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheConfigurator.parseRegions(CompositeCacheConfigurator.java:135)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.doConfigure(CompositeCacheManager.java:455)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:406)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:365)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:347)}}{{
> at
> org.apache.commons.jcs3.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:336)}}{{
> at
>
[jira] [Resolved] (JCS-230) UDPDiscoveryReceiver with EncryptingSerializer fails
[ https://issues.apache.org/jira/browse/JCS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-230. Fix Version/s: jcs-3.2 Resolution: Fixed Fixed in Git > UDPDiscoveryReceiver with EncryptingSerializer fails > > > Key: JCS-230 > URL: https://issues.apache.org/jira/browse/JCS-230 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.2 > > Attachments: patch.diff, unitTests.patch.diff > > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > UDPDiscoveryReceiver throws an error when trying to serialize received > message ( error bellow). > > Root cause of this error: > calling deSerialize method in line 265 : > serializer.deSerialize(byteBuffer.array(), null); > byteBuffer.array() - returns byte[] which size is the full capacity of > ByteBuffer not the size of recived message. > > > Apr 04, 2022 2:16:19 PM > org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver > SEVERE: Error receiving multicast packet > java.io.IOException: Error while decrypting > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:209) > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.deSerialize(EncryptingSerializer.java:247) > at > org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver.run(UDPDiscoveryReceiver.java:265) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: javax.crypto.IllegalBlockSizeException: Input length must be > multiple of 16 when decrypting with padded cipher > at > java.base/com.sun.crypto.provider.CipherCore.prepareInputBuffer(CipherCore.java:1005) > at > java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:848) > at > java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:203) > ... 3 more > > > Solution attached in patch.diff file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JCS-229) LateralTCPListener class uses always StandardSerializer
[ https://issues.apache.org/jira/browse/JCS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-229. Fix Version/s: jcs-3.2 Resolution: Fixed Fixed in Git > LateralTCPListener class uses always StandardSerializer > --- > > Key: JCS-229 > URL: https://issues.apache.org/jira/browse/JCS-229 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.2 > > Attachments: patch.diff > > Original Estimate: 4h > Remaining Estimate: 4h > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > synchronization does not work. > LateralTCPSender supports custom Serializer (by constructor which allowed > LateralTCPService to pass Serializer as parameter)- and it's properly sending > encripted messages. LateralTCPListener does not support custom Serializer and > uses always StandardSerializer - which in this case when received message is > encripted fails. > > > Solution attached in patch.diff file. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCS-230) UDPDiscoveryReceiver with EncryptingSerializer fails
[ https://issues.apache.org/jira/browse/JCS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517354#comment-17517354 ] Thomas Vandahl commented on JCS-230: Thank you for the patch. Would you please consider adding a test case for this bug? > UDPDiscoveryReceiver with EncryptingSerializer fails > > > Key: JCS-230 > URL: https://issues.apache.org/jira/browse/JCS-230 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Assignee: Thomas Vandahl >Priority: Major > Attachments: patch.diff > > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > UDPDiscoveryReceiver throws an error when trying to serialize received > message ( error bellow). > > Root cause of this error: > calling deSerialize method in line 265 : > serializer.deSerialize(byteBuffer.array(), null); > byteBuffer.array() - returns byte[] which size is the full capacity of > ByteBuffer not the size of recived message. > > > Apr 04, 2022 2:16:19 PM > org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver > SEVERE: Error receiving multicast packet > java.io.IOException: Error while decrypting > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:209) > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.deSerialize(EncryptingSerializer.java:247) > at > org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver.run(UDPDiscoveryReceiver.java:265) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: javax.crypto.IllegalBlockSizeException: Input length must be > multiple of 16 when decrypting with padded cipher > at > java.base/com.sun.crypto.provider.CipherCore.prepareInputBuffer(CipherCore.java:1005) > at > java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:848) > at > java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:203) > ... 3 more > > > Solution attached in patch.diff file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCS-229) LateralTCPListener class uses always StandardSerializer
[ https://issues.apache.org/jira/browse/JCS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517355#comment-17517355 ] Thomas Vandahl commented on JCS-229: Thank you for the patch. Would you please consider adding a test case for this bug? > LateralTCPListener class uses always StandardSerializer > --- > > Key: JCS-229 > URL: https://issues.apache.org/jira/browse/JCS-229 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Assignee: Thomas Vandahl >Priority: Major > Attachments: patch.diff > > Original Estimate: 4h > Remaining Estimate: 4h > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > synchronization does not work. > LateralTCPSender supports custom Serializer (by constructor which allowed > LateralTCPService to pass Serializer as parameter)- and it's properly sending > encripted messages. LateralTCPListener does not support custom Serializer and > uses always StandardSerializer - which in this case when received message is > encripted fails. > > > Solution attached in patch.diff file. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JCS-229) LateralTCPListener class uses always StandardSerializer
[ https://issues.apache.org/jira/browse/JCS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-229: --- Assignee: Thomas Vandahl > LateralTCPListener class uses always StandardSerializer > --- > > Key: JCS-229 > URL: https://issues.apache.org/jira/browse/JCS-229 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Assignee: Thomas Vandahl >Priority: Major > Attachments: patch.diff > > Original Estimate: 4h > Remaining Estimate: 4h > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > synchronization does not work. > LateralTCPSender supports custom Serializer (by constructor which allowed > LateralTCPService to pass Serializer as parameter)- and it's properly sending > encripted messages. LateralTCPListener does not support custom Serializer and > uses always StandardSerializer - which in this case when received message is > encripted fails. > > > Solution attached in patch.diff file. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JCS-230) UDPDiscoveryReceiver with EncryptingSerializer fails
[ https://issues.apache.org/jira/browse/JCS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-230: --- Assignee: Thomas Vandahl > UDPDiscoveryReceiver with EncryptingSerializer fails > > > Key: JCS-230 > URL: https://issues.apache.org/jira/browse/JCS-230 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Assignee: Thomas Vandahl >Priority: Major > Attachments: patch.diff > > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > UDPDiscoveryReceiver throws an error when trying to serialize received > message ( error bellow). > > Root cause of this error: > calling deSerialize method in line 265 : > serializer.deSerialize(byteBuffer.array(), null); > byteBuffer.array() - returns byte[] which size is the full capacity of > ByteBuffer not the size of recived message. > > > Apr 04, 2022 2:16:19 PM > org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver > SEVERE: Error receiving multicast packet > java.io.IOException: Error while decrypting > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:209) > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.deSerialize(EncryptingSerializer.java:247) > at > org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver.run(UDPDiscoveryReceiver.java:265) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: javax.crypto.IllegalBlockSizeException: Input length must be > multiple of 16 when decrypting with padded cipher > at > java.base/com.sun.crypto.provider.CipherCore.prepareInputBuffer(CipherCore.java:1005) > at > java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:848) > at > java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) > at > org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:203) > ... 3 more > > > Solution attached in patch.diff file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JCS-228) Imported packages should be optional in the OSGi manifest
[ https://issues.apache.org/jira/browse/JCS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-228: --- Assignee: Thomas Vandahl > Imported packages should be optional in the OSGi manifest > - > > Key: JCS-228 > URL: https://issues.apache.org/jira/browse/JCS-228 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.0 >Reporter: Patrick Ziegler >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > > The _commons-dbcp2_ and _log4j-api_ artifacts are marked as optional in the > pom, but are set as required in the manifest. > Meaning that those dependencies need to be provided in an Eclipse > application, even if they are not used. > I suggest making those imports optional. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JCS-228) Imported packages should be optional in the OSGi manifest
[ https://issues.apache.org/jira/browse/JCS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-228. Fix Version/s: jcs-3.1 Resolution: Fixed Fixed in Git > Imported packages should be optional in the OSGi manifest > - > > Key: JCS-228 > URL: https://issues.apache.org/jira/browse/JCS-228 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.0 >Reporter: Patrick Ziegler >Priority: Major > Fix For: jcs-3.1 > > > The _commons-dbcp2_ and _log4j-api_ artifacts are marked as optional in the > pom, but are set as required in the manifest. > Meaning that those dependencies need to be provided in an Eclipse > application, even if they are not used. > I suggest making those imports optional. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JCS-208) Minor improvements
[ https://issues.apache.org/jira/browse/JCS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-208. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed > Minor improvements > -- > > Key: JCS-208 > URL: https://issues.apache.org/jira/browse/JCS-208 > Project: Commons JCS > Issue Type: Improvement >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JCS-191) Server Failover mechanism not working
[ https://issues.apache.org/jira/browse/JCS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-191. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Fixed in Git > Server Failover mechanism not working > -- > > Key: JCS-191 > URL: https://issues.apache.org/jira/browse/JCS-191 > Project: Commons JCS > Issue Type: Question > Components: RMI Remote Cache >Affects Versions: jcs-2.2 >Reporter: prajakta Uplaikar >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > Attachments: client_cach.ccf, failure_stack.txt, primary_server.ccf, > secondary_server.ccf > > > > server failover environment set up as per guidelines mentioned in apache docs > : > [https://commons.apache.org/proper/commons-jcs/RemoteAuxCache.html] > It works well when both servers started, it fetches data from jcs and display > cache hits on admin console. but when primary server fails to start then > secondary server not picking hits from jcs > I have attached 4 files > # primary_server cache.cff > # secondary_server.cff > # client cache.cff > # failure_stack.txt > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JCS-185) NoSuchObjectException: no such object in table | RemoteCacheListener
[
https://issues.apache.org/jira/browse/JCS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-185.
Fix Version/s: jcs-3.1
Assignee: Thomas Vandahl
Resolution: Not A Bug
> NoSuchObjectException: no such object in table | RemoteCacheListener
>
>
> Key: JCS-185
> URL: https://issues.apache.org/jira/browse/JCS-185
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-2.2
>Reporter: Eduard Wirch
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: jcs-3.1
>
>
> The JCS client reports this error when starting up:
> {code}
> 20-Nov-2017 12:00:37.856 SEVERE [RMI TCP Connection(2)-127.0.0.1]
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.newRemoteCacheNoWait
> Problem adding listener. Message: RemoteException occurred in server thread;
> nested exception is:
> java.rmi.NoSuchObjectException: no such object in table |
> RemoteCacheListener =
> RemoteCacheListener:
> AbstractRemoteCacheListener:
> RemoteHost = localhost:1103
> ListenerId = 0
> java.rmi.ServerException: RemoteException occurred in server thread; nested
> exception is:
> java.rmi.NoSuchObjectException: no such object in table
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:377)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
> at com.sun.proxy.$Proxy174.addCacheListener(Unknown Source)
> at
> org.apache.commons.jcs.engine.CacheWatchRepairable.addCacheListener(CacheWatchRepairable.java:116)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.addRemoteCacheListener(RemoteCacheManager.java:183)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.newRemoteCacheNoWait(RemoteCacheManager.java:294)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.getCache(RemoteCacheManager.java:264)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheFactory.createCache(RemoteCacheFactory.java:122)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseAuxiliary(CompositeCacheConfigurator.java:500)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:261)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:161)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegions(CompositeCacheConfigurator.java:136)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.doConfigure(CompositeCacheManager.java:490)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:441)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:391)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:373)
> at org.apache.commons.jcs.JCS.getCacheManager(JCS.java:163)
> at org.apache.commons.jcs.JCS.getInstance(JCS.java:190)
>
> Caused by: java.rmi.NoSuchObjectException: no such object in table
> at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)
> at
>
[jira] [Commented] (JCS-185) NoSuchObjectException: no such object in table | RemoteCacheListener
[
https://issues.apache.org/jira/browse/JCS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17450084#comment-17450084
]
Thomas Vandahl commented on JCS-185:
This is probably not JCS-related but RMI-specific. See
[https://stackoverflow.com/questions/645208/java-rmi-nosuchobjectexception-no-such-object-in-table/854097]
for an explanation.
> NoSuchObjectException: no such object in table | RemoteCacheListener
>
>
> Key: JCS-185
> URL: https://issues.apache.org/jira/browse/JCS-185
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-2.2
>Reporter: Eduard Wirch
>Priority: Major
>
> The JCS client reports this error when starting up:
> {code}
> 20-Nov-2017 12:00:37.856 SEVERE [RMI TCP Connection(2)-127.0.0.1]
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.newRemoteCacheNoWait
> Problem adding listener. Message: RemoteException occurred in server thread;
> nested exception is:
> java.rmi.NoSuchObjectException: no such object in table |
> RemoteCacheListener =
> RemoteCacheListener:
> AbstractRemoteCacheListener:
> RemoteHost = localhost:1103
> ListenerId = 0
> java.rmi.ServerException: RemoteException occurred in server thread; nested
> exception is:
> java.rmi.NoSuchObjectException: no such object in table
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:377)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
> at com.sun.proxy.$Proxy174.addCacheListener(Unknown Source)
> at
> org.apache.commons.jcs.engine.CacheWatchRepairable.addCacheListener(CacheWatchRepairable.java:116)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.addRemoteCacheListener(RemoteCacheManager.java:183)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.newRemoteCacheNoWait(RemoteCacheManager.java:294)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheManager.getCache(RemoteCacheManager.java:264)
> at
> org.apache.commons.jcs.auxiliary.remote.RemoteCacheFactory.createCache(RemoteCacheFactory.java:122)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseAuxiliary(CompositeCacheConfigurator.java:500)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:261)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:161)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegions(CompositeCacheConfigurator.java:136)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.doConfigure(CompositeCacheManager.java:490)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:441)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:391)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:373)
> at org.apache.commons.jcs.JCS.getCacheManager(JCS.java:163)
> at org.apache.commons.jcs.JCS.getInstance(JCS.java:190)
>
> Caused by: java.rmi.NoSuchObjectException: no such object in table
> at
>
[jira] [Resolved] (JCS-223) Data not added in cache at certain scenarios
[ https://issues.apache.org/jira/browse/JCS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-223. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Not A Bug > Data not added in cache at certain scenarios > > > Key: JCS-223 > URL: https://issues.apache.org/jira/browse/JCS-223 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.0 > Environment: JAVA >Reporter: Sundharam >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > Attachments: Code.java, cache.ccf, output > > > Created a simple program to put 1000 data in the the cache and read 1000 data > from the cache. While retrieving the data nearly 200-250 entries were found > missing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCS-223) Data not added in cache at certain scenarios
[
https://issues.apache.org/jira/browse/JCS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17450069#comment-17450069
]
Thomas Vandahl commented on JCS-223:
Believe it or not, this is actually working as designed.
The disk cache uses a "purgatory" (see
[https://commons.apache.org/proper/commons-jcs/IndexedDiskAuxCache.html] for an
explanation) to queue disk update requests for asynchronous processing. By
default, the purgatory is limited in size (5000 entries). So if you put faster
than the disk updates can happen, the purgatory will overflow and it will throw
away the oldest entries.
However, you may configure the purgatory to unlimited size if you have the use
case and can afford the additional memory by setting
{code:java}
jcs.auxiliary.DC.attributes.MaxPurgatorySize=-1
{code}
BTW, for your example to work properly, you also need to set the key size of
the disk cache to a reasonable value. If you want all items to be stored on
disk, that means 1 in your example, or even
{code:java}
jcs.auxiliary.DC.attributes.MaxKeySize=-1 {code}
> Data not added in cache at certain scenarios
>
>
> Key: JCS-223
> URL: https://issues.apache.org/jira/browse/JCS-223
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.0
> Environment: JAVA
>Reporter: Sundharam
>Priority: Major
> Attachments: Code.java, cache.ccf, output
>
>
> Created a simple program to put 1000 data in the the cache and read 1000 data
> from the cache. While retrieving the data nearly 200-250 entries were found
> missing.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (JCS-227) With jdbc disk cache, when the database is down too many logs are printed causing the disk become full
[ https://issues.apache.org/jira/browse/JCS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-227. Fix Version/s: (was: jcs-3.0) Assignee: Thomas Vandahl Resolution: Not A Bug > With jdbc disk cache, when the database is down too many logs are printed > causing the disk become full > -- > > Key: JCS-227 > URL: https://issues.apache.org/jira/browse/JCS-227 > Project: Commons JCS > Issue Type: Bug > Components: JDBC Disk Cache >Affects Versions: jcs-3.0, jcs-3.1 > Environment: Linux OS, jdk8,java util logging >Reporter: Narasimha Raju >Assignee: Thomas Vandahl >Priority: Critical > Labels: newbie > Fix For: jcs-3.1 > > Original Estimate: 48h > Remaining Estimate: 48h > > Incase any restart of the database lot log execptions are thrown, since we > have millions of get and puts happenning the logs are getting filled up. > The issue here is the put or get does not throw any exception which we could > catch and handle and controll logging. > If possible we should log on severe log level, logging should not print he > expcetion stacktrace and if would be better if just print how many times such > exception has occured instead of printing all. Printing all exceptions can be > done in finest. > Bcz of high cpu the log rollup is not happening. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCS-227) With jdbc disk cache, when the database is down too many logs are printed causing the disk become full
[
https://issues.apache.org/jira/browse/JCS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358587#comment-17358587
]
Thomas Vandahl edited comment on JCS-227 at 6/7/21, 1:15 PM:
-
That is what log filters were invented for. See
https://docs.oracle.com/javase/8/docs/api/java/util/logging/Filter.html
You can add that to the configuration like
{code:java}
java.util.logging.FileHandler.filter = om.xyz.filters.MyDuplicateFilter
{code}
was (Author: tv):
That is what log filters were invented for. See
https://docs.oracle.com/javase/8/docs/api/java/util/logging/Filter.html
You can add that to the configuration like
{code:properties}
java.util.logging.FileHandler.filter = om.xyz.filters.MyDuplicateFilter
{code}
> With jdbc disk cache, when the database is down too many logs are printed
> causing the disk become full
> --
>
> Key: JCS-227
> URL: https://issues.apache.org/jira/browse/JCS-227
> Project: Commons JCS
> Issue Type: Bug
> Components: JDBC Disk Cache
>Affects Versions: jcs-3.0, jcs-3.1
> Environment: Linux OS, jdk8,java util logging
>Reporter: Narasimha Raju
>Priority: Critical
> Labels: newbie
> Fix For: jcs-3.0, jcs-3.1
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Incase any restart of the database lot log execptions are thrown, since we
> have millions of get and puts happenning the logs are getting filled up.
> The issue here is the put or get does not throw any exception which we could
> catch and handle and controll logging.
> If possible we should log on severe log level, logging should not print he
> expcetion stacktrace and if would be better if just print how many times such
> exception has occured instead of printing all. Printing all exceptions can be
> done in finest.
> Bcz of high cpu the log rollup is not happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCS-227) With jdbc disk cache, when the database is down too many logs are printed causing the disk become full
[
https://issues.apache.org/jira/browse/JCS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358587#comment-17358587
]
Thomas Vandahl commented on JCS-227:
That is what log filters were invented for. See
https://docs.oracle.com/javase/8/docs/api/java/util/logging/Filter.html
You can add that to the configuration like
{code:properties}
java.util.logging.FileHandler.filter = om.xyz.filters.MyDuplicateFilter
{code}
> With jdbc disk cache, when the database is down too many logs are printed
> causing the disk become full
> --
>
> Key: JCS-227
> URL: https://issues.apache.org/jira/browse/JCS-227
> Project: Commons JCS
> Issue Type: Bug
> Components: JDBC Disk Cache
>Affects Versions: jcs-3.0, jcs-3.1
> Environment: Linux OS, jdk8,java util logging
>Reporter: Narasimha Raju
>Priority: Critical
> Labels: newbie
> Fix For: jcs-3.0, jcs-3.1
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Incase any restart of the database lot log execptions are thrown, since we
> have millions of get and puts happenning the logs are getting filled up.
> The issue here is the put or get does not throw any exception which we could
> catch and handle and controll logging.
> If possible we should log on severe log level, logging should not print he
> expcetion stacktrace and if would be better if just print how many times such
> exception has occured instead of printing all. Printing all exceptions can be
> done in finest.
> Bcz of high cpu the log rollup is not happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JCS-222) Fix Typo "waterfal" Method
[
https://issues.apache.org/jira/browse/JCS-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-222.
Assignee: Thomas Vandahl
Resolution: Later
This probably will have to wait until 4.0. I'll make a note in the code.
> Fix Typo "waterfal" Method
> --
>
> Key: JCS-222
> URL: https://issues.apache.org/jira/browse/JCS-222
> Project: Commons JCS
> Issue Type: Sub-task
>Reporter: Arturo Bernal
>Assignee: Thomas Vandahl
>Priority: Minor
>
> Fix typo function without break the binary
>
> [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/engine/memory/behavior/IMemoryCache.java#L152]
>
>
> {code:java}
> /**
> * Spools the item contained in the provided element to disk
> *
> * @param ce
> * Description of the Parameter
> * @throws IOException
> * Description of the Exception
> */
> void waterfal( ICacheElement ce )
> throws IOException;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JCS-225) Fix Typo and Javadoc
[ https://issues.apache.org/jira/browse/JCS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-225. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed PR merged. > Fix Typo and Javadoc > > > Key: JCS-225 > URL: https://issues.apache.org/jira/browse/JCS-225 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-226) Use toArray with zero-length array argument
[ https://issues.apache.org/jira/browse/JCS-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-226. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Won't Fix PR declined. > Use toArray with zero-length array argument > --- > > Key: JCS-226 > URL: https://issues.apache.org/jira/browse/JCS-226 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-224) Remove commented code
[ https://issues.apache.org/jira/browse/JCS-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-224. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Won't Fix > Remove commented code > - > > Key: JCS-224 > URL: https://issues.apache.org/jira/browse/JCS-224 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-220) Java8 improvement
[ https://issues.apache.org/jira/browse/JCS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-220. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed PR merged. > Java8 improvement > - > > Key: JCS-220 > URL: https://issues.apache.org/jira/browse/JCS-220 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > > * -Use Comparator.comparingLong- > * Use method reference > * Use lambda -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCS-227) With jdbc disk cache, when the database is down too many logs are printed causing the disk become full
[ https://issues.apache.org/jira/browse/JCS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358087#comment-17358087 ] Thomas Vandahl edited comment on JCS-227 at 6/6/21, 11:03 AM: -- Would you care to share your JCS configuration with us? Maybe, the log configuration would be helpful, too. How long does a database restart take? How often does it happen? was (Author: tv): Would you care to share your JCS configuration with us? How long does a database restart take? How often does it happen? > With jdbc disk cache, when the database is down too many logs are printed > causing the disk become full > -- > > Key: JCS-227 > URL: https://issues.apache.org/jira/browse/JCS-227 > Project: Commons JCS > Issue Type: Bug > Components: JDBC Disk Cache >Affects Versions: jcs-3.0, jcs-3.1 > Environment: Linux OS, jdk8,java util logging >Reporter: Narasimha Raju >Priority: Critical > Labels: newbie > Fix For: jcs-3.0, jcs-3.1 > > Original Estimate: 48h > Remaining Estimate: 48h > > Incase any restart of the database lot log execptions are thrown, since we > have millions of get and puts happenning the logs are getting filled up. > The issue here is the put or get does not throw any exception which we could > catch and handle and controll logging. > If possible we should log on severe log level, logging should not print he > expcetion stacktrace and if would be better if just print how many times such > exception has occured instead of printing all. Printing all exceptions can be > done in finest. > Bcz of high cpu the log rollup is not happening. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCS-227) With jdbc disk cache, when the database is down too many logs are printed causing the disk become full
[ https://issues.apache.org/jira/browse/JCS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358087#comment-17358087 ] Thomas Vandahl commented on JCS-227: Would you care to share your JCS configuration with us? How long does a database restart take? How often does it happen? > With jdbc disk cache, when the database is down too many logs are printed > causing the disk become full > -- > > Key: JCS-227 > URL: https://issues.apache.org/jira/browse/JCS-227 > Project: Commons JCS > Issue Type: Bug > Components: JDBC Disk Cache >Affects Versions: jcs-3.0, jcs-3.1 > Environment: Linux OS, jdk8,java util logging >Reporter: Narasimha Raju >Priority: Critical > Labels: newbie > Fix For: jcs-3.0, jcs-3.1 > > Original Estimate: 48h > Remaining Estimate: 48h > > Incase any restart of the database lot log execptions are thrown, since we > have millions of get and puts happenning the logs are getting filled up. > The issue here is the put or get does not throw any exception which we could > catch and handle and controll logging. > If possible we should log on severe log level, logging should not print he > expcetion stacktrace and if would be better if just print how many times such > exception has occured instead of printing all. Printing all exceptions can be > done in finest. > Bcz of high cpu the log rollup is not happening. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-215) Minor Changes
[ https://issues.apache.org/jira/browse/JCS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-215. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed PR merged > Minor Changes > - > > Key: JCS-215 > URL: https://issues.apache.org/jira/browse/JCS-215 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > > * Change Deprecated API usage > * Inline Variable > * Remove Unused import -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-217) Minor improvements
[ https://issues.apache.org/jira/browse/JCS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-217. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed PR merged > Minor improvements > --- > > Key: JCS-217 > URL: https://issues.apache.org/jira/browse/JCS-217 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Labels: pull-request-available > Fix For: jcs-3.1 > > > * Unused import > * Make void method > * Add final var > * Remove unnecessary condition > * Simplify conditions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-188) Lateral TCP put() and putInGroup() internally causes remove from other laterals
[ https://issues.apache.org/jira/browse/JCS-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-188. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Cannot Reproduce IssueRemoveOnPut is supposed to be false by default. Based on the code, your configuration should not update anything at all. Please try again with the current version and AllowPut=true > Lateral TCP put() and putInGroup() internally causes remove from other > laterals > --- > > Key: JCS-188 > URL: https://issues.apache.org/jira/browse/JCS-188 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-1.3 >Reporter: Ramesh S >Assignee: Thomas Vandahl >Priority: Critical > Fix For: jcs-3.1 > > > We have two servers IP1 and IP2 with laterals configured. Both IP1 and IP2 > are up and running. > 1) An application page puts entries into the local cache of IP1 when the page > is visited from IP1. > 2) Same page is visited from IP2, which also puts entries into the cache of > IP2, which internally calls remove(), causing the cached entries of IP1 to > get removed. > 3) Now the user again visits the same page from IP1, which reloads the cache > as it was removed by the above event. As part of this put/putInGroup, > remove() is called, which in turn sends an event to IP2 to remove its cache > and IP2's cache gets removed now. > This seems to be a ping-pong issue. Why should the cache keep getting removed > during a put/putInGroup operation of another lateral? I would like to send a > remove event to other laterals only during an explicit remove and not during > put/putInGroup. How to address this issue? > > This is the configuration we are using. > > In IP1, > jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory > jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes > jcs.auxiliary.LTCP.attributes.TcpServers=IP2: > jcs.auxiliary.LTCP.attributes.TcpListenerPort= > jcs.auxiliary.LTCP.attributes.AllowGet=false > jcs.auxiliary.LTCP.attributes.AllowPut=false > jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false > > In IP2, > jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory > jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes > jcs.auxiliary.LTCP.attributes.TcpServers=IP1: > jcs.auxiliary.LTCP.attributes.TcpListenerPort= > jcs.auxiliary.LTCP.attributes.AllowGet=false > jcs.auxiliary.LTCP.attributes.AllowPut=false > jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-187) TCPLateralCache with multiple Server not working
[ https://issues.apache.org/jira/browse/JCS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-187. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Works for Me I guess this has been resolved in the meantime > TCPLateralCache with multiple Server not working > > > Key: JCS-187 > URL: https://issues.apache.org/jira/browse/JCS-187 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Reporter: Attila Horvath >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > > Hi, > a distributed configuration based on "Lateral TCP Auxiliary Cache" is not > working as designed. If I configure multiple servers: > jcs.auxiliary.LTCP.attributes.TcpServers=localhost:6111,192.168.1.1:6110,192.168.1.2:6110 > ..JCS creates a configuration for each server. The configurations created are > not correct, each TCPLateralCacheAttributes-Instance holds the IP/Port for > the last server entry. It is possibly a clone / deepclone issue in > TCPLateralCacheAttributes. (changing the server in one > TCPLateralCacheAttributes-Instance causes to change the server in all > TCPLateralCacheAttributes-Instances) > Thank you, > Attila Horvath -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-186) Lateral cache replication is not working with UDP discovery
[ https://issues.apache.org/jira/browse/JCS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-186. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Hopefully fixed > Lateral cache replication is not working with UDP discovery > --- > > Key: JCS-186 > URL: https://issues.apache.org/jira/browse/JCS-186 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-2.2 >Reporter: Alex L >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.1 > > > Hello, > > When using UDP discovery, the replication is not working. I'm using the basic > example from the website and although the instances discover each other, > there's no actual replication of cache objects. > This issue only occurs with UDP discovery. When specifying the TCP Servers > list everything works as exepected. > > The issue seems to be introduced with the refactorings in this commit: > [http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPDiscoveryListener.java?r1=1803806=1593843_format=h] > > As a technical note, the tcpServer of the attributes is empty when using UDP > discovery, so the DiscoveredService will never be added to the noWait list. > > Let me know if you need more details. > Thank you, > Alex > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCS-208) Minor improvements
[ https://issues.apache.org/jira/browse/JCS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310667#comment-17310667 ] Thomas Vandahl commented on JCS-208: [~arturobernalg]: Thank you for your contributions. Please keep them coming! You may use this issue as a container. I'll leave it open for the time being. > Minor improvements > -- > > Key: JCS-208 > URL: https://issues.apache.org/jira/browse/JCS-208 > Project: Commons JCS > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-209) Use Collections.singletonList insteadof Arrays.asList when there be only with few arguments.
[ https://issues.apache.org/jira/browse/JCS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-209. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Merged pull request. > Use Collections.singletonList insteadof Arrays.asList when there be only with > few arguments. > > > Key: JCS-209 > URL: https://issues.apache.org/jira/browse/JCS-209 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-212) Redundant local variable.
[ https://issues.apache.org/jira/browse/JCS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-212. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Merged pull request. > Redundant local variable. > - > > Key: JCS-212 > URL: https://issues.apache.org/jira/browse/JCS-212 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > > Inline unnecessary local variables, which add nothing to the > comprehensibility of a method -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-211) Use Map.forEach().
[ https://issues.apache.org/jira/browse/JCS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-211. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Merged pull request. > Use Map.forEach(). > -- > > Key: JCS-211 > URL: https://issues.apache.org/jira/browse/JCS-211 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-213) Redundant initialization.
[ https://issues.apache.org/jira/browse/JCS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-213. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Pull request merged. > Redundant initialization. > - > > Key: JCS-213 > URL: https://issues.apache.org/jira/browse/JCS-213 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > > Remove redundant initialization -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-210) Replace Lambda with method reference.
[ https://issues.apache.org/jira/browse/JCS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-210. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Pull request merged. > Replace Lambda with method reference. > - > > Key: JCS-210 > URL: https://issues.apache.org/jira/browse/JCS-210 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-214) Use 'compare()' method to compare numbers
[ https://issues.apache.org/jira/browse/JCS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-214. Fix Version/s: jcs-3.1 Assignee: Thomas Vandahl Resolution: Fixed Pull request merged. > Use 'compare()' method to compare numbers > -- > > Key: JCS-214 > URL: https://issues.apache.org/jira/browse/JCS-214 > Project: Commons JCS > Issue Type: Sub-task >Reporter: Arturo Bernal >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-206) Fix the homepage
[ https://issues.apache.org/jira/browse/JCS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-206. -- > Fix the homepage > > > Key: JCS-206 > URL: https://issues.apache.org/jira/browse/JCS-206 > Project: Commons JCS > Issue Type: Task > Components: Documentation >Affects Versions: jcs-3.0 >Reporter: Richard Eigenmann >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.0 > > > Thanks for the new release. Please fix the homepage > [https://commons.apache.org/proper/commons-jcs/index.html] > # The link to "Upgrading from 2.x to 3.0 runs to a 404 > # The link Core Javadoc runs to a 404 > # The examples in the JCS Users guide refer to the JCS2 class names which > have changed to jcs3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCS-207) JCSAdmin.jsp throws ClassCastException java.util.LinkedList cannot be cast to [Lorg.apache.commons.jcs3.admin.CacheRegionInfo
[
https://issues.apache.org/jira/browse/JCS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-207.
Fix Version/s: jcs-3.1
Assignee: Thomas Vandahl
Resolution: Fixed
Fixed in master
> JCSAdmin.jsp throws ClassCastException java.util.LinkedList cannot be cast to
> [Lorg.apache.commons.jcs3.admin.CacheRegionInfo
> -
>
> Key: JCS-207
> URL: https://issues.apache.org/jira/browse/JCS-207
> Project: Commons JCS
> Issue Type: Bug
> Components: Documentation
>Affects Versions: jcs-3.0
>Reporter: Reval Pal
>Assignee: Thomas Vandahl
>Priority: Minor
> Fix For: jcs-3.1
>
>
> The sample JCSAdmin.jsp on URL
> https://raw.githubusercontent.com/apache/commons-jcs/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/admin/JCSAdmin.jsp
> as referred to by https://commons.apache.org/proper/commons-jcs/faq.html
> {quote}
> Where can I get the admin jsp?
> You can download the admin jsp here .
> {quote}
> Throws exception when running:
> {code}
> org.apache.jasper.JasperException: JBWEB004038: An exception occurred
> processing JSP page /JCSAdmin.jsp at line 254
> 254
> 251: Retrieve (key)
> 252: (region)
> 253: <%
> 254: CacheRegionInfo[] listSelect = (CacheRegionInfo[]) context.get(
> "cacheInfoRecords" );
> 255: for (CacheRegionInfo record : listSelect)
> 256: {
> 257: %>
> Caused by: java.lang.ClassCastException: java.util.LinkedList cannot be cast
> to [Lorg.apache.commons.jcs3.admin.CacheRegionInfo;
> at org.apache.jsp.JCSAdmin_jsp._jspService(JCSAdmin_jsp.java:389)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> {code}
> h3. Solution
> 3 places to fix:
> 1)
> {code} line 203 :
> <%
> CacheElementInfo[] list = (CacheElementInfo[]) context.get(
> "elementInfoRecords" );
> for (CacheElementInfo element : list)
> {
> %>
> {code}
> should be
> {code}
> <%
> for (CacheElementInfo element :
> (java.util.List)context.get( "elementInfoRecords" ))
> {
> %>
> {code}
> 2)
> {code} line 253
> <%
> CacheRegionInfo[] listSelect = (CacheRegionInfo[]) context.get(
> "cacheInfoRecords" );
> for (CacheRegionInfo record : listSelect)
> {
> {code}
> should be
> {code}
> <%
> for (CacheRegionInfo record :
> (java.util.List)context.get( "cacheInfoRecords" ))
> {
> {code}
> 3)
> {code} line 279
> <%
> CacheRegionInfo[] list = (CacheRegionInfo[]) context.get(
> "cacheInfoRecords" );
> for (CacheRegionInfo record : listSelect)
> {
> %>
> {code}
> should be
> {code}
> <%
> for (CacheRegionInfo record :
> (java.util.List)context.get( "cacheInfoRecords" ))
> {
> %>
> {code}
> (*) Also some styling nitpicking:
> {code} line 229
>
> <%=stats%>
>
> {code}
> should be
> {code}
>
> <%=stats%>
>
> {code}
> (removes the spaces in the rendered page).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JCS-206) Fix the homepage
[ https://issues.apache.org/jira/browse/JCS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-206. Fix Version/s: jcs-3.0 Resolution: Fixed Published missing files > Fix the homepage > > > Key: JCS-206 > URL: https://issues.apache.org/jira/browse/JCS-206 > Project: Commons JCS > Issue Type: Task > Components: Documentation >Affects Versions: jcs-3.0 >Reporter: Richard Eigenmann >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.0 > > > Thanks for the new release. Please fix the homepage > [https://commons.apache.org/proper/commons-jcs/index.html] > # The link to "Upgrading from 2.x to 3.0 runs to a 404 > # The link Core Javadoc runs to a 404 > # The examples in the JCS Users guide refer to the JCS2 class names which > have changed to jcs3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCS-206) Fix the homepage
[ https://issues.apache.org/jira/browse/JCS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-206: --- Assignee: Thomas Vandahl > Fix the homepage > > > Key: JCS-206 > URL: https://issues.apache.org/jira/browse/JCS-206 > Project: Commons JCS > Issue Type: Task > Components: Documentation >Affects Versions: jcs-3.0 >Reporter: Richard Eigenmann >Assignee: Thomas Vandahl >Priority: Major > > Thanks for the new release. Please fix the homepage > [https://commons.apache.org/proper/commons-jcs/index.html] > # The link to "Upgrading from 2.x to 3.0 runs to a 404 > # The link Core Javadoc runs to a 404 > # The examples in the JCS Users guide refer to the JCS2 class names which > have changed to jcs3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-200) Tune logging: "Resetting cache" as info
[ https://issues.apache.org/jira/browse/JCS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-200. -- Close after release > Tune logging: "Resetting cache" as info > --- > > Key: JCS-200 > URL: https://issues.apache.org/jira/browse/JCS-200 > Project: Commons JCS > Issue Type: Improvement >Reporter: Simon Legner >Assignee: Thomas Vandahl >Priority: Minor > Labels: logging > Fix For: jcs-3.0 > > > https://github.com/apache/commons-jcs/pull/8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-205) commons-jcs3-core-3.0-20200526.132410-4-sources.jar lacks META-INF/services/org.apache.commons.jcs3.log.LogFactory
[
https://issues.apache.org/jira/browse/JCS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl closed JCS-205.
--
Close after release
> commons-jcs3-core-3.0-20200526.132410-4-sources.jar lacks
> META-INF/services/org.apache.commons.jcs3.log.LogFactory
> --
>
> Key: JCS-205
> URL: https://issues.apache.org/jira/browse/JCS-205
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-3.0
>Reporter: Simon Legner
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: jcs-3.0
>
>
> The source JAR
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-jcs3-core/3.0-SNAPSHOT/commons-jcs3-core-3.0-20200526.132410-4-sources.jar
> lacks the services file
> {{META-INF/services/org.apache.commons.jcs3.log.LogFactory}}. Instead, the
> file
> {{/home/jenkins/jenkins-slave/workspace/commons-jcs/commons-jcs-core/target/classes/META-INF/services/org.apache.commons.jcs3.log.LogFactory}}
> is present.
> JOSM bug: https://josm.openstreetmap.de/ticket/19335
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JCS-199) Disk cache directory and files not recreated after shutdown and restart
[
https://issues.apache.org/jira/browse/JCS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl closed JCS-199.
--
Close after release
> Disk cache directory and files not recreated after shutdown and restart
> ---
>
> Key: JCS-199
> URL: https://issues.apache.org/jira/browse/JCS-199
> Project: Commons JCS
> Issue Type: Bug
> Components: Composite Cache
>Affects Versions: jcs-2.2.1
>Reporter: Matthias Jordan
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: jcs-3.0
>
>
> h1. How to repro
> # Configure a composite cache with an indexed disk cache as the auxiliary.
> # Now in one single JVM (e.g. in a single main method), do the following:
> ## Create the cache, possibly putting something in.
> ## Note that the disk cache files are created
> ## JCS.shutdown()
> ## Remove the files of the disk cache
> ## Create the cache again.
> ## Put stuff in
> h1. What to observe
> The disk cache files are not created again.
> In fact, the logging for the first run shows output like this:
> {noformat}
> INFORMATION: Constructed cache with name [CACHE] and cache attributes [
> useLateral = true, useRemote = true, useDisk = true, maxObjs = 1,
> maxSpoolPerRun = 500, diskUsagePattern = SWAP, spoolChunkSize = 2 ]
> Jun 25, 2019 4:19:58 PM
> org.apache.commons.jcs.auxiliary.AuxiliaryCacheConfigurator
> parseCacheEventLogger
> INFORMATION: No cache event logger defined for auxiliary [jcs.auxiliary.DISK]
> Jun 25, 2019 4:19:58 PM
> org.apache.commons.jcs.auxiliary.AuxiliaryCacheConfigurator
> parseElementSerializer
> INFORMATION: Using standard serializer
> [org.apache.commons.jcs.utils.serialization.StandardSerializer@1ddf84b8] for
> auxiliary [jcs.auxiliary.DISK]
> [...]
> Jun 25, 2019 4:19:59 PM
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache
> INFORMATION: Region [CACHE] Indexed Disk Cache is alive.
> {noformat}
> The logging of the second run shows output like this:
> {noformat}
> INFORMATION: Constructed cache with name [CACHE] and cache attributes [
> useLateral = true, useRemote = true, useDisk = true, maxObjs = 1,
> maxSpoolPerRun = 500, diskUsagePattern = SWAP, spoolChunkSize = 2 ]
> {noformat}
> Please note that in the latter case the lines about initializing the
> {{IndexedDiskCache}} are missing, event though the configuration states that
> a disk cache is to be used.
> h1. What is expected
> In the second run, the disk cache files should be created again as a
> consequence of creating new auxiliary caches. It is expected that shutting
> down the JCS will shut down every subsystem.
> h1. Relevance
> The issue comes up when restarting a web API system including deleting the
> contents of the temporary directory.
> h1. Note
> The bug may be fixed by setting the {{instance}} field in
> {{CompositeCacheManager}} to null at some point during the shutdown process.
> Maybe in {{CompositeCacheManager.shutdown()}}.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JCS-182) Error while closing data source factory on shutdown
[ https://issues.apache.org/jira/browse/JCS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-182. -- Close after release > Error while closing data source factory on shutdown > --- > > Key: JCS-182 > URL: https://issues.apache.org/jira/browse/JCS-182 > Project: Commons JCS > Issue Type: Bug > Components: JDBC Disk Cache >Reporter: uday ogra >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.0 > > > I am using JDBC auxillary cache. Everything works fine but when server is > shutdown I get the following error. Seems JCS code is trying to close a > connection which is null > ERROR Could not close data source factory null > java.sql.SQLException: Exception caught closing data source > at org.apache.commons.jcs.auxiliary.disk.jdbc.dsfactory.SharedPoolDataSo > urceFactory.close(SharedPoolDataSourceFactory.java:99) > at org.apache.commons.jcs.auxiliary.disk.jdbc.JDBCDiskCacheFactory.dispo > se(JDBCDiskCacheFactory.java:137) > at org.apache.commons.jcs.engine.control.CompositeCacheManager.shutDown( > CompositeCacheManager.java:695) > at org.apache.commons.jcs.engine.control.CompositeCacheManager$ShutdownH > ook.run(CompositeCacheManager.java:982) > Caused by: java.lang.NullPointerException > at org.apache.commons.jcs.auxiliary.disk.jdbc.dsfactory.SharedPoolDataSo > urceFactory.close(SharedPoolDataSourceFactory.java:95) > ... 3 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-197) Getting an issue with commons-jcs-core 2.0 version, which is InstanceAlreadyExistsException
[ https://issues.apache.org/jira/browse/JCS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-197. -- Close after release > Getting an issue with commons-jcs-core 2.0 version, which is > InstanceAlreadyExistsException > --- > > Key: JCS-197 > URL: https://issues.apache.org/jira/browse/JCS-197 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache, Documentation >Affects Versions: jcs-2.0 > Environment: windows 10 >Reporter: naga kumar >Assignee: Thomas Vandahl >Priority: Critical > Labels: performance > Fix For: jcs-3.0 > > Original Estimate: 120h > Remaining Estimate: 120h > > Hi, > I have recently tried using JCS 2.0 version. my intention is to improve the > performance of my application since my application communicates data base > frequently. So, i have implemented a single service on cache, and when i run > this service as a standalone(not through web module, but using main method in > java), i am able to prove that the call is going to cache for sure for second > time since the first call must go to data base. And, finally my issue is, > when i deploy the same application, which has cache implementation, and run > the web module, i am getting below exception. Can you please solve it as soon > as possible since i am dead line. and if possible, can you share a best > cache.ccf file for best config. > > Exception details > -- > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > org.apache.commons.jcs.utils.servlet.JCSServletContextListener: implements > ServletContextListener > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > org.apache.tomcat.websocket.server.WsContextListener: implements > ServletContextListener > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > org.apache.commons.logging.impl.ServletContextCleaner: implements > ServletContextListener > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > com..otag.service.agent.ServiceBootstrapListener: implements > ServletContextListener > > org.apache.commons.jcs.engine.control.CompositeCacheManager - Could not > register JMX bean. > javax.management.InstanceAlreadyExistsException: > org.apache.commons.jcs:type=JCSAdminBean > at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.initialize(CompositeCacheManager.java:271) > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.getInstance(CompositeCacheManager.java:185) > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.getInstance(CompositeCacheManager.java:161) > at org.apache.commons.jcs.JCS.getCacheManager(JCS.java:156) > at org.apache.commons.jcs.JCS.getInstance(JCS.java:174) > > --- > Note: If you share any solution, please give it us with a sample code. > > thanks, > Nag -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-202) Tune logging: assume that info is enabled
[ https://issues.apache.org/jira/browse/JCS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-202. -- Close after release > Tune logging: assume that info is enabled > - > > Key: JCS-202 > URL: https://issues.apache.org/jira/browse/JCS-202 > Project: Commons JCS > Issue Type: Improvement >Reporter: Simon Legner >Assignee: Thomas Vandahl >Priority: Minor > Labels: logging > Fix For: jcs-3.0 > > > https://github.com/apache/commons-jcs/pull/10 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-167) AbstractDiskCache.getKeySet() returns inconsistent key set
[ https://issues.apache.org/jira/browse/JCS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-167. -- Close after release > AbstractDiskCache.getKeySet() returns inconsistent key set > -- > > Key: JCS-167 > URL: https://issues.apache.org/jira/browse/JCS-167 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache, Indexed Disk Cache >Affects Versions: jcs-1.3, jcs-2.0-beta-1 >Reporter: Alexey Stepanov >Priority: Major > Fix For: jcs-3.0 > > > _getKeySet()_ method implementations in disk caches (Block and Index) is not > aware of purgatory inside _AbstractDiskCache_. > So _CacheAccess.getCacheControl().getKeySet()_ as well as > GroupCacheAccess.getGroupKeys() returns key set that is inconsistent with > whole cache state. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-122. -- Close after release > rework logging? > --- > > Key: JCS-122 > URL: https://issues.apache.org/jira/browse/JCS-122 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.0 > > > currently JCS relies on [logging] > Would be great to get rid of this dependency. > Solutions I see: > 1) use JUL (with extensibility like in > http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) > 2) write a little factory with a jcs.Logger to be able to switch > Goal is to be able to adapt to frameworks and users. Guess first will be > often JUL (TomEE), second SLF4J, [logging]... > I'm for 1) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-194) NullPointerException in IndexedDiskCache.addToRecycleBin(...)
[
https://issues.apache.org/jira/browse/JCS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl closed JCS-194.
--
Close after release
> NullPointerException in IndexedDiskCache.addToRecycleBin(...)
> -
>
> Key: JCS-194
> URL: https://issues.apache.org/jira/browse/JCS-194
> Project: Commons JCS
> Issue Type: Bug
> Components: Indexed Disk Cache
>Affects Versions: jcs-2.2
>Reporter: Benedikt Köppel
>Assignee: Thomas Vandahl
>Priority: Major
> Fix For: jcs-3.0
>
> Attachments: jcsbug.tgz
>
>
> *Note**:* this is not the same as
> https://issues.apache.org/jira/browse/JCS-158, which has already been fixed
> in the jcs-2.2 version used here.
> With the attached mini-project, we get a NullPointerException when the cache
> is loaded from disk:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.addToRecycleBin(IndexedDiskCache.java:1145)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.processRemovedLRU(IndexedDiskCache.java:1738)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.processRemovedLRU(IndexedDiskCache.java:1637)
> at
> org.apache.commons.jcs.utils.struct.AbstractLRUMap.put(AbstractLRUMap.java:344)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.put(IndexedDiskCache.java:1685)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache$LRUMapSizeLimited.put(IndexedDiskCache.java:1637)
> at
> org.apache.commons.jcs.utils.struct.AbstractLRUMap.putAll(AbstractLRUMap.java:187)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.loadKeys(IndexedDiskCache.java:339)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.initializeStoreFromPersistedData(IndexedDiskCache.java:285)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.initializeKeysAndData(IndexedDiskCache.java:250)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.(IndexedDiskCache.java:183)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory.createCache(IndexedDiskCacheFactory.java:60)
> at
> org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory.createCache(IndexedDiskCacheFactory.java:33)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseAuxiliary(CompositeCacheConfigurator.java:500)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:261)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegion(CompositeCacheConfigurator.java:161)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseRegions(CompositeCacheConfigurator.java:136)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.doConfigure(CompositeCacheManager.java:490)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:441)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:391)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:373)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManager.java:362)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.getInstance(CompositeCacheManager.java:190)
> at
> org.apache.commons.jcs.engine.control.CompositeCacheManager.getInstance(CompositeCacheManager.java:161)
> at org.apache.commons.jcs.JCS.getCacheManager(JCS.java:172)
> at org.apache.commons.jcs.JCS.getInstance(JCS.java:190)
> at ch.locatee.test.App.main(App.java:18)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> This does not happen if (in my mini project), all the objects are the same
> size. It seems like the _last_ element inserted into the cache has to be much
> bigger.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JCS-201) Tune logging: "Using hardcoded default" as info
[ https://issues.apache.org/jira/browse/JCS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-201. -- Close after release > Tune logging: "Using hardcoded default" as info > --- > > Key: JCS-201 > URL: https://issues.apache.org/jira/browse/JCS-201 > Project: Commons JCS > Issue Type: Improvement >Reporter: Simon Legner >Assignee: Thomas Vandahl >Priority: Minor > Labels: logging > Fix For: jcs-3.0 > > > https://github.com/apache/commons-jcs/pull/9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-166) TCP Lateral cache listen on all interfaces
[ https://issues.apache.org/jira/browse/JCS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-166. -- Close after release > TCP Lateral cache listen on all interfaces > -- > > Key: JCS-166 > URL: https://issues.apache.org/jira/browse/JCS-166 > Project: Commons JCS > Issue Type: Improvement > Components: TCP Lateral Cache >Affects Versions: jcs-2.0-beta-1 > Environment: linux >Reporter: Philippe Perrault >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.0 > > > TCP lateral cache listener is listening on all interfaces. > it would be nice to be able to set a specific one -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-46) Allow TTL to be overridden for UDPDiscoverySender
[ https://issues.apache.org/jira/browse/JCS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-46. - Close after release > Allow TTL to be overridden for UDPDiscoverySender > - > > Key: JCS-46 > URL: https://issues.apache.org/jira/browse/JCS-46 > Project: Commons JCS > Issue Type: Improvement > Components: TCP Lateral Cache >Reporter: Lux Matic >Assignee: Thomas Vandahl >Priority: Minor > Fix For: jcs-3.0 > > > MulticastSocket defaults TTL for DatagramPackets to 1. This limits > usefulness of the feature. There should be a way to override the TTL through > configuration - i.e.: jcs.auxiliary.LTCP.attributes.UdpTTL=4 > Assuming m_ttlOverride is available as a member variable - the change boils > down to setting the ttl before the packet is sent - something like: > m_localSocket.setTimeToLive(m_ttlOverride); > m_localSocket.send( packet ); > See MulticastSocket for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-119) replace synchronized blocks by java locks or concurrenhashmap
[ https://issues.apache.org/jira/browse/JCS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-119. -- Close after release > replace synchronized blocks by java locks or concurrenhashmap > - > > Key: JCS-119 > URL: https://issues.apache.org/jira/browse/JCS-119 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl >Priority: Major > Fix For: jcs-3.0 > > > A cache is typically used in a concurrent environment. Since Java 6 using a > ReentrantLock is faster than synchronized so can be interesting to replace > synchronized blocks by a lock. > Places i'm thinking about: > * CompositeCache > * AbstractDoubleLinkedListMemoryCache > * LHMLRUMemoryCache > * DoubleLinkedList > * LRUMap > * SingleLinkedList > * SortedPreferentialArray > Some places where replacing a HashMap by a ConcurrentHashMap can allow to get > rid of synchronized without needing a lock: > * CacheEventQueue > * AbstractDiskCache > * CacheWatchRepairable > There are other places but this is the main I saw. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-196) Getting an issue with commons-jcs-core 2.0 version, which is InstanceAlreadyExistsException
[ https://issues.apache.org/jira/browse/JCS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-196. -- Close after release > Getting an issue with commons-jcs-core 2.0 version, which is > InstanceAlreadyExistsException > --- > > Key: JCS-196 > URL: https://issues.apache.org/jira/browse/JCS-196 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.0 >Reporter: naga kumar >Assignee: Thomas Vandahl >Priority: Blocker > Fix For: jcs-3.0 > > > Hi, > I have recently tried using JCS 2.0 version. my intention is to improve the > performance of my application since my application communicates data base > frequently. So, i have implemented a single service on cache, and when i run > this service as a standalone(not through web module, but using main method in > java), i am able to prove that the call is going to cache for sure for second > time since the first call must go to data base. And, finally my issue is, > when i deploy the same application, which has cache implementation, and run > the web module, i am getting below exception. Can you please solve it as soon > as possible since i am dead line. and if possible, can you share a best > cache.ccf file for best config. > > Exception details > -- > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > org.apache.commons.jcs.utils.servlet.JCSServletContextListener: implements > ServletContextListener > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > org.apache.tomcat.websocket.server.WsContextListener: implements > ServletContextListener > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > org.apache.commons.logging.impl.ServletContextCleaner: implements > ServletContextListener > 2019-01-04 16:47:49.426 WARN com..XXX.service.agent.XXManagementAgent - > Found potential problem class > com..otag.service.agent.ServiceBootstrapListener: implements > ServletContextListener > > org.apache.commons.jcs.engine.control.CompositeCacheManager - Could not > register JMX bean. > javax.management.InstanceAlreadyExistsException: > org.apache.commons.jcs:type=JCSAdminBean > at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.initialize(CompositeCacheManager.java:271) > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.getInstance(CompositeCacheManager.java:185) > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.getInstance(CompositeCacheManager.java:161) > at org.apache.commons.jcs.JCS.getCacheManager(JCS.java:156) > at org.apache.commons.jcs.JCS.getInstance(JCS.java:174) > > --- > Note: If you share any solution, please give it us with a sample code. > > thanks, > Naga. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JCS-195) Update element attributes size on serialization
[
https://issues.apache.org/jira/browse/JCS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl closed JCS-195.
--
Close after release
> Update element attributes size on serialization
> ---
>
> Key: JCS-195
> URL: https://issues.apache.org/jira/browse/JCS-195
> Project: Commons JCS
> Issue Type: Improvement
> Components: Composite Cache
>Affects Versions: jcs-2.2
>Reporter: quietmint
>Assignee: Thomas Vandahl
>Priority: Major
> Labels: admin-interface, beginner, documentation, easyfix,
> pull-request-available
> Fix For: jcs-3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ElementAttributes}} class has a field to store the size in bytes (e.g., for
> use in an admin-style page). Calculating the size is an expensive operation,
> so it makes sense to save the size whenever we serialize the element. Admin
> pages that want this data could then get a cheap approximation from the last
> time the element was serialized.
> Additionally, the javadocs say the size field is populated as -1 by default,
> but it's really 0 by default.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JCS-198) ConcurrentException in update of RemoteAuxiliaryCache
[ https://issues.apache.org/jira/browse/JCS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl closed JCS-198. -- Close after release > ConcurrentException in update of RemoteAuxiliaryCache > - > > Key: JCS-198 > URL: https://issues.apache.org/jira/browse/JCS-198 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-2.2 >Reporter: Renato >Priority: Critical > Fix For: jcs-3.0 > > > We have the same application that runs on two distinct node. This > application is basically a rest statefull service that uses a Remote JCS > cache in order to share sessions, but frequently we got the following > excpetion: > > ERROR RemoteCache:141 - Disabling remote cache due to error: Failed to put > [fe3e6602-d2bb-497d-b2bc-3a809d9b0d3f] to > navigationdata > java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442) > at java.util.HashMap$KeyIterator.next(HashMap.java:1466) > at java.util.HashSet.writeObject(HashSet.java:287) > at sun.reflect.GeneratedMethodAccessor173.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1140) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) > at java.util.HashMap.internalWriteEntries(HashMap.java:1790) > at java.util.HashMap.writeObject(HashMap.java:1363) > at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1140) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) > at java.util.ArrayList.writeObject(ArrayList.java:766) > at sun.reflect.GeneratedMethodAccessor172.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1140) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) > at > org.apache.commons.jcs.utils.serialization.StandardSerializer.serialize(StandardSerializer.java:55) > at > org.apache.commons.jcs.utils.serialization.SerializationConversionUtil.getSerializedCacheElement(SerializationConversionUtil.java:74) > at > org.apache.commons.jcs.auxiliary.remote.AbstractRemoteAuxiliaryCache.processUpdate(AbstractRemoteAuxiliaryCache.java:421) > at > org.apache.commons.jcs.auxiliary.AbstractAuxiliaryCacheEventLogging.updateWithEventLogging(AbstractAuxiliaryCacheEventLogging.java:65) > at > org.apache.commons.jcs.auxiliary.AbstractAuxiliaryCacheEventLogging.update(AbstractAuxiliaryCacheEventLogging.java:50) > at org.apache.commons.jcs.engine.CacheAdaptor.handlePut(CacheAdaptor.java:96) > at > org.apache.commons.jcs.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:362) > at > org.apache.commons.jcs.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:281) > at > org.apache.commons.jcs.engine.CacheEventQueue$QProcessor.run(CacheEventQueue.java:228) -- This
[jira] [Closed] (JCS-193) [JCACHE] How to configure caches used by interceptors (i.e. CacheResultInterceptor) related to JCache annotations
[
https://issues.apache.org/jira/browse/JCS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl closed JCS-193.
--
Close after release
> [JCACHE] How to configure caches used by interceptors (i.e.
> CacheResultInterceptor) related to JCache annotations
> -
>
> Key: JCS-193
> URL: https://issues.apache.org/jira/browse/JCS-193
> Project: Commons JCS
> Issue Type: Improvement
> Components: Composite Cache
>Affects Versions: jcs-2.2
>Reporter: Ricard Nàcher Roig
>Priority: Major
> Labels: pull-request-available
> Fix For: jcs-3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I started using JCS cache as a JCache implementation provider a few days ago
> and everything was fine until I needed to set up expiration for cached data
> or even the number of elements stored in the cache. I realized that caches
> were created with EternalPolicy so I started to figure out how to set up both
> implementation specific properties and Standard JCache ones. After a couple
> of days, I don't have a pretty idea about how to configure the caches related
> to methods annotated with JCache annotations like CacheResult, CacheRemove
> and so on.
> I mean that I already know that I can use the CacheDefaults annotation, both
> at class and method level, in order to set the name of the cache to be used.
> but another thing is to also set the CacheResolverFactory. Should I always
> set the CacheResolverFactory in the annotation in order to be able to create
> the cache using a specific set of properties? Or maybe the idea is to create
> the cache programmatically before is is needed? Anyway, It seems too much
> boilerplate to me. Maybe I am wrong but I think that we are not using the CDI
> power at all.
> please, let me know if there is better/simpler approach.
> Another thing that I cannot understand is the readConfig method of the
> JCSCachingManager class. It is loading the folder structure because it is
> loading the resources from the default uri of the provider!
> where uri is "jcs://jcache.ccf", so the path is "/". I think that this URI
> should not be used for this, maybe the uri should be something different (URI
> of the default configuration?) or just use another implementation specific
> property. Notice that adding an extra slash will look for /jcache.ccf file!
> maybe it is just a bug and there is a slash missing : "jcs:///jcache.ccf"
> {code:java}
> final Enumeration resources = loader.getResources(uri.getPath());
> {code}
>
> What about this?
> Add CachingProvider and CacheManager as beans if they are not already beans.
> Notice that this is what jcs-jcache-extras module already does!
> So as a developer I can configure my CachingProvider and even the cache
> manager already configured as beans. They will be injected where needed
> instead of being created without configuration.
> no configuration in CacheResolverFactory
> {code:java}
> public CacheResolverFactoryImpl()
> {
> provider = Caching.getCachingProvider();
> cacheManager = provider.getCacheManager(provider.getDefaultURI(),
> provider.getDefaultClassLoader());
> }
> {code}
> but in JCacheFilter class some properties are set
>
> {code:java}
> manager = provider.getCacheManager(URI.create(uri), classLoader, properties);
> {code}
> One step further into CDI should be to also provide the CacheResolverFactory
> as a bean and also the
> CacheResolverFactoryImpl could be also injected with the cacheProvider and
> CacheManager and some CompleteConfigurationResolver of something like that in
> order to avoid creating caches with a hard-coded MutableConfiguration.
> {code:java}
> public class CacheResolverFactoryImpl implements CacheResolverFactory
> {
> ...
> private Cache createCache(final String exceptionCacheName)
> {
> cacheManager.createCache(exceptionCacheName, new
> MutableConfiguration().setStoreByValue(false));
> return cacheManager.getCache(exceptionCacheName);
> }
> {code}
>
> with these changes, we reduce boilerplate and give more control to
> jcs-jcache library clients.
> Can we move ExtraJCacheExtension to jcs-jcache in order to be able to handle
> CachingProvider and CacheManager as beans?
> best regards,
> Ricard
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
