Originally, I though that this is caused by one of the other present bugs. Now I had a chance to look even closer and found this issue: When we start server using standalone.xml config, we are not able to monitor statistics properly. They 'disappeared'. Checked using CLI. This issue is not present while running with clustered.xml. See the difference in CLI output below: WRONG standalone.xml local cache: [standalone@localhost:9999 local-cache=default] ls backup leveldb-store store module=undefined binary-keyed-jdbc-store loader string-keyed-jdbc-store remote-cache=undefined cluster-loader locking transaction remote-site=undefined compatibility mixed-keyed-jdbc-store batching=undefined start=EAGER eviction remote-store indexing=undefined statistics=true expiration rest-store indexing-properties=undefined file-store security jndi-name=undefined GOOD clustered.xml distributed cache: [standalone@localhost:9999 cache-container=clustered] cd distributed-cache=default [standalone@localhost:9999 distributed-cache=default] ls backup activations=0 hits=0 remote-cache=undefined binary-keyed-jdbc-store async-marshalling=undefined indexing=undefined remote-site=undefined cluster-loader average-read-time=0 indexing-properties=undefined remote-timeout=30000 compatibility average-remove-time=0 invalidations=0 remove-hits=0 eviction average-replication-time=0 jndi-name=undefined remove-misses=0 expiration average-write-time=0 l1-lifespan=0 replication-count=0 file-store batching=undefined misses=0 replication-failures=0 leveldb-store cache-availability=AVAILABLE mode=SYNC rollbacks=0 loader cache-loader-loads=0 module=undefined segments=20 locking cache-loader-misses=0 number-of-entries=0 start=EAGER mixed-keyed-jdbc-store cache-loader-stores=0 number-of-locks-available=0 statistics=undefined partition-handling cache-name=default number-of-locks-held=0 stores=0 remote-store cache-status=RUNNING owners=2 success-ratio=0.0 rest-store capacity-factor=1.0 passivations=0 time-since-reset=11 security commits=0 prepares=0 version=6.2.0.Final-redhat-1 state-transfer concurrency-level=1000 queue-flush-interval=undefined virtual-nodes=1 store elapsed-time=11 queue-size=undefined string-keyed-jdbc-store evictions=0 read-write-ratio=0.0 transaction hit-ratio=0.0 rebalancing=true
Setting target release to 6.4.0 CR2 to make it more visible. Need info: Martin please, can you evaluate severity and priority? The thing is that standalone.xml started server does not provide cache-level statistics (cache manager stats are OK) and can't be monitored properly in JON. This was hard to spot because the majority of servers in our (JON) test deployment is started using clustered.xml and that one standalone.xml server had problems because other bugs -- it was hidden and tricky one.
Tomas, does it happen also in library mode or is it just client-server? If that only affect client-server mode then it's not a big problem.
Confirming that this is _SERVER_ (started via standalone*.sh scripts) related problem. Caches running in InVM which are monitored as JMX servers reports their statistics smoothly. Thanks for input. Changing priority and severity to MEDIUM.
This is not necessary to have in CR2. Unsetting the target.
Tristan Tarrant <ttarrant> updated the status of jira ISPN-5144 to Resolved
*** This bug has been marked as a duplicate of bug 1276035 ***