Description of problem: JON support for setting maxEntries is supposed to be delivered as part of the JDG660.MaxEntries. The embedded plugin has been updated, but not the server plugin. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This needs to be fixed in ER1
William Burns <wburns> updated the status of jira ISPN-5888 to Coding In Progress
William Burns <wburns> updated the status of jira ISPN-5888 to Closed
PR: https://github.com/infinispan/jdg/pull/770
Tested with 6.6.ER1. After reconfiguring the cache (change in standalone.xml) to enable the EVICTION I can see EVICITION subsystem on via CLI interface. However, in JON, after JDG server restart, the EVICTION subsystem is not present under the cache resource. I've spot an stacktrace in agent log that is highly probably related: 2015-11-06 07:44:02,152 WARN [ResourceContainer.invoker.daemon-13] (org.infinispan.rhq.CacheComponent)- getValues failed for Cache.MaxEntries java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String at org.infinispan.rhq.CacheComponent.getValues(CacheComponent.java:125) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocation.call(ResourceContainer.java:759) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 2015-11-06 07:44:02,197 WARN [ResourceContainer.invoker.daemon-13] (org.infinispan.rhq.CacheComponent)- getValues failed for Cache.ConfigurationAsProperties java.lang.ClassCastException: java.util.Properties cannot be cast to java.lang.String at org.infinispan.rhq.CacheComponent.getValues(CacheComponent.java:125) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocation.call(ResourceContainer.java:759) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722)
Tomas, What version of JON are you using? And also what steps did you take when you enabled eviction? I was running with the latest JDG 6.6 as of Nov 11, 2015 and I can change the max-entries from RHQ and see it propagated by checking through the CLI. I was using RHQ 4.13.1 though for my server. Here are the steps I took. 1. I started with a JDG server where I changed the clustered.xml to have a cache with eviction enabled set to 100 entries 2. Looked on the CLI to see the cache had eviction configuration properly at 150 3. Forced discovery on the rhq-agent 4. Pulled up the RHQ server console page and navigated to the cache 5. Found the eviction child resource and under configuration I could see it was set to 100 6. I changed max-entries to 150 from RHQ 7. Then confirmed via CLI that it shows max entries was set to 150
Back, back, everything back! :)) The EVICTION subsystem registration took more time then expected. Just for a note here -- for quicker testing [update -f] (force) operation on the agent could be called to get new subsystem registered immediately. I also verified that changing evicition configuration does not need server restart and happens on-fly. Set LRU with 5 entries in standalone.xml, changed it to 6, put 7 entries -- stats telling: 7 puts, 6 entries. Exactly as expected. VERIFIED. Thank you!
Thank you Tomas!
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.