Description of problem: The shindig.properties file is in shindig-common-2.0.2-CP01.jar It needs to be outside of a jar so the properties can be easily changed. For example if I want to set shindig.cache.ehcache.jmx.enabled=false it is in the shindig.properties file within deploy/gatein.ear/lib/shindig-common-2.0.2-CP01.jar Workaround: Not known - I tried exploding the jar file but deployment failed. How reproducible: very Steps to Reproduce: 1. File inspection Actual results: Can't alter the shindig.properties file Expected results: Being able to alter the shindig.properties file Additional info: As this is on by default in large installations (when JON is used) this causes great problems as JON will monitor these transient caches.
Adding Bug 802902 to See Also list as it identifies the transient and on demand cache scenario as a problem in the upstream JBoss Cache plug-in from the RHQ Project.
Increasing Severity to understand when this could be investigated
I still can't reproduce. I don't see any of those JBoss Cache MBeans in the JMX console, whatever I try in the portal. Portal is started with "-c all"
Just realized that this hasn't been updated with the new information... To reproduce, enable the JBoss platform MBean server (system property jboss.platform.mbeanserver). The reason we do not see it without this is because the MBeans are being installed into the JVM's MBean server and can only be seen with JConsole unless the JBoss and JVM MBean servers are merged using said property.
Based on a response received from Martin on a possible way to alleviate the stats being exposed for these MBeans: ... I don't know if 'transient' is the proper attribute for these JBoss Cache MBeans. To me it looks like they just don't have a defined name. Anyway, with a bit of trying, I found that these could be disabled by adding <jmxStatistics enabled="false"/> and <attribute name="exposeManagementStatistics">false</attribute> to the JBC config files in EPP 5.2. File: deploy/gatein.ear/02portal.war/WEB-INF/classes/picketlink-idm/idm-local-cache-config.xml File: deploy/gatein.ear/02portal.war/WEB-INF/conf/jbosscache/local/config.xml File: deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/jbosscache/local/config.xml File: deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/jbosscache/local/lock-config.xml File: deploy/gatein.ear/02portal.war/WEB-INF/conf/organization/picketlink-idm/jboss-cache.xml
Shaun, Larry: patch from comment 7 was applied in EPP 5.2.2 ER01 release. Is there something else what can be verified? I have two questions, why is it applied only at local configuration and not in cluster? Previous issue with shindig.properties configuration isn't solved by this issue, is it expected by above comments? or it still needs to be fixed? Thanks
(In reply to comment #10) > Shaun, Larry: patch from comment 7 was applied in EPP 5.2.2 ER01 release. Is > there something else what can be verified? For verification we just need to make certain these caches are not exposed when the system property jboss.platform.mbeanserver is used (as per comment 6). Before the fix, MBeans similar to the following would appear: jboss.cache:service=JBossCache,uniqueId=67afe177 and jboss.cache:service=JBossCache,uniqueId=67afe177,jmx-resource=TxInterceptor jboss.cache:service=JBossCache,uniqueId=67afe177,jmx-resource=RegionManager The key thing being the `uniqueId=67afe177` where the hash would change every time EPP was started. The fix should prevent these MBeans from appearing. > why is it applied only at local configuration and not in cluster? In cluster, the cache names are static. In non-cluster, the cache names are undefined resulting in a random ID being used for their name. Perhaps this change should apply to both clustered and non-clustered but it only caused issues in non-clustered. > Previous issue with shindig.properties configuration isn't solved by this issue, is it expected by above comments? or it still needs to be fixed? Correct, this bug and its resolution has no impact on shindig.properties. The original thought was that it was a configuration option in shindig.properties that was causing this bug but after further analysis, it was determined that this issue had nothing to do with property values in shindig.properties.
Thanks Larry for more details. I have just tried EPP 5.2.2 ER03 with -Djboss.platform.mbeanserver parameter and I can still see these caches at jboss.cache category: jmx-resource=CacheMgmtInterceptor,service=JBossCache,uniqueId=22d0280b jmx-resource=CacheMgmtInterceptor,service=JBossCache,uniqueId=26b9569e jmx-resource=CacheMgmtInterceptor,service=JBossCache,uniqueId=5c9a0ba2 jmx-resource=DataContainer,service=JBossCache,uniqueId=22d0280b jmx-resource=DataContainer,service=JBossCache,uniqueId=26b9569e jmx-resource=DataContainer,service=JBossCache,uniqueId=5c9a0ba2 jmx-resource=InterceptorChain,service=JBossCache,uniqueId=22d0280b jmx-resource=InterceptorChain,service=JBossCache,uniqueId=26b9569e jmx-resource=InterceptorChain,service=JBossCache,uniqueId=5c9a0ba2 jmx-resource=MVCCLockManager,service=JBossCache,uniqueId=5c9a0ba2 jmx-resource=OptimisticTxInterceptor,service=JBossCache,uniqueId=22d0280b jmx-resource=RPCManager,service=JBossCache,uniqueId=22d0280b jmx-resource=RPCManager,service=JBossCache,uniqueId=26b9569e jmx-resource=RPCManager,service=JBossCache,uniqueId=5c9a0ba2 jmx-resource=RegionManager,service=JBossCache,uniqueId=22d0280b jmx-resource=RegionManager,service=JBossCache,uniqueId=26b9569e jmx-resource=RegionManager,service=JBossCache,uniqueId=5c9a0ba2 jmx-resource=TransactionTable,service=JBossCache,uniqueId=22d0280b jmx-resource=TransactionTable,service=JBossCache,uniqueId=26b9569e jmx-resource=TransactionTable,service=JBossCache,uniqueId=5c9a0ba2 jmx-resource=TxInterceptor,service=JBossCache,uniqueId=26b9569e jmx-resource=TxInterceptor,service=JBossCache,uniqueId=5c9a0ba2 service=InvalidationManager As far as I understood Lary's comment, above MBeans shouldn't be present after fix, but they are. Above list is present when running "default" configuration, when I run "all" configuration, there are much more caches with static names but above are present as well. Assigning back...
Basicly I run EPP: run.sh -c all -Djboss.platform.mbeanserver and open http://localhost:8080/jmx-console/, set filter to jboss.cache:service=JBossCache*,* This is what I have now: cluster=DefaultPartition-HAPartitionCache,jmx-resource=CacheMgmtInterceptor,service=JBossCache cluster=DefaultPartition-HAPartitionCache,jmx-resource=DataContainer,service=JBossCache cluster=DefaultPartition-HAPartitionCache,jmx-resource=InterceptorChain,service=JBossCache cluster=DefaultPartition-HAPartitionCache,jmx-resource=RPCManager,service=JBossCache cluster=DefaultPartition-HAPartitionCache,jmx-resource=RegionManager,service=JBossCache cluster=DefaultPartition-HAPartitionCache,jmx-resource=TransactionTable,service=JBossCache cluster=DefaultPartition-HAPartitionCache,jmx-resource=TxInterceptor,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=CacheMgmtInterceptor,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=DataContainer,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=InterceptorChain,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=LegacyActivationInterceptor,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=LegacyPassivationInterceptor,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=RPCManager,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=RegionManager,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=TransactionTable,service=JBossCache cluster=DefaultPartition-SessionCache,jmx-resource=TxInterceptor,service=JBossCache jmx-resource=CacheMgmtInterceptor,service=JBossCache,uniqueId=66ca0069 jmx-resource=DataContainer,service=JBossCache,uniqueId=66ca0069 jmx-resource=InterceptorChain,service=JBossCache,uniqueId=66ca0069 jmx-resource=MVCCLockManager,service=JBossCache,uniqueId=66ca0069 jmx-resource=RPCManager,service=JBossCache,uniqueId=66ca0069 jmx-resource=RegionManager,service=JBossCache,uniqueId=66ca0069 jmx-resource=TransactionTable,service=JBossCache,uniqueId=66ca0069 jmx-resource=TxInterceptor,service=JBossCache,uniqueId=66ca0069 Patch is identical as in custommer case https://na7.salesforce.com/500A0000009eyqd
Based on my previous comment, I can still see same caches with uniqueId (same list as mentioned by Honza). I think the goal of is issue was to remove (do not expose) these caches in jmx. It seems like provided customer patch didn't fully cover the issue. @Larry, can you confirm?
Martin, can you comment here. Are the results Michal and Honza seeing the expected ones with this change? I was under the impression that the JBossCache MBeans would not be exposed. Perhaps I am mistaken and the MBeans still are exposed but have no stats methods? What are we missing for our test-case?
I just tested with ER04 and got the same results (one cache MBean with a randomly generated name showing up in jmx-console) as in comment #13. Apparently a new file has been added to EPP 5.2, which also needs the jmxStatistics element to be set to false explicitly: gatein.ear/02portal.war/WEB-INF/conf/jcr/jbosscache/local/config_portal-system.xml In addition (although it does not do any harm), the same element can be removed (twice) from idm-local-cache-config.xml (cache exposure is disabled there with the exposeManagementStatistics attribute already).
Martin, thanks for this update! I have tried with <jmxStatistics enabled="false"/> at local/config_portal-system.xml and now I get expected results - no caches with uniqueId present at jmx. Honza, can you please update this file and include in CR01? Thanks
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Exposing info by JMX is set in config. Consequence: Too many info exposet by JMX Fix: Configuration changed Result: Correct info shown by JMX
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -Cause: Exposing info by JMX is set in config. +It was discovered that exposing information for anonymous caches using JMX resulted in too much information being exposed. The configuration has been changed to ensure JMX stats for anonymous caches display the correct information.-Consequence: Too many info exposet by JMX -Fix: Configuration changed -Result: Correct info shown by JMX
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.