[JBoss JIRA] (ISPN-3605) Configuration validation for Metadata Cache in Lucene Directory
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-3605:
---------------------------------
Summary: Configuration validation for Metadata Cache in Lucene Directory
Key: ISPN-3605
URL: https://issues.jboss.org/browse/ISPN-3605
Project: Infinispan
Issue Type: Enhancement
Components: Lucene Directory
Affects Versions: 6.0.0.CR1
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 6.0.0.Final
from ispn-dev:
Proposal:
let's be more aggressive on validation.
- make preload mandatory (for the metadata only)
- eviction not allowed (for the metadata only)
Note that I don't think we're putting much of a restriction to users, we're more likely helping with good guidance on how these caches are supposed to work.
I think it's a good thing to narrow down the possible configuration
options and make it clear what we expect people to use for this purpose.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3605) Configuration validation for Metadata Cache in Lucene Directory
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3605?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3605 started by Pedro Ruivo.
> Configuration validation for Metadata Cache in Lucene Directory
> ---------------------------------------------------------------
>
> Key: ISPN-3605
> URL: https://issues.jboss.org/browse/ISPN-3605
> Project: Infinispan
> Issue Type: Enhancement
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Final
>
>
> from ispn-dev:
> Proposal:
> let's be more aggressive on validation.
> - make preload mandatory (for the metadata only)
> - eviction not allowed (for the metadata only)
> Note that I don't think we're putting much of a restriction to users, we're more likely helping with good guidance on how these caches are supposed to work.
> I think it's a good thing to narrow down the possible configuration
> options and make it clear what we expect people to use for this purpose.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3497) getCountRowsSql() has wrong SQL syntax
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3497?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3497:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1007415|https://bugzilla.redhat.com/show_bug.cgi?id=1007415] from ON_QA to VERIFIED
> getCountRowsSql() has wrong SQL syntax
> --------------------------------------
>
> Key: ISPN-3497
> URL: https://issues.jboss.org/browse/ISPN-3497
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Alpha4
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: jdg62blocker
> Fix For: 6.0.0.Beta2
>
>
> When I run tests with mysql database following exception is thrown
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `mix_str____defaultcache`' at line 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
> at com.mysql.jdbc.Util.getInstance(Util.java:386)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1053)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4120)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4052)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2503)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2664)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2794)
> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)
> at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2322)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedStore.size(JdbcStringBasedStore.java:358)
> {code:title=TableManipulation.java|borderStyle=solid}
> public String getCountRowsSql() {
> if (countRowsSql == null) {
> countRowsSql = "SELECT COUNT (*) FROM " + getTableName(); <<< here should be COUNT(*) without space
> }
> return countRowsSql;
> }
> {code}
> MySQL is complaining when there is SPACE between COUNT and (*)
> >[Error] Script lines: 5-6 --------------------------
> You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `edg_string____defaultcache`' at line 1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3414) Infinispan ignores DatabaseType configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3414?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3414:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 997365|https://bugzilla.redhat.com/show_bug.cgi?id=997365] from ON_QA to VERIFIED
> Infinispan ignores DatabaseType configuration
> ----------------------------------------------
>
> Key: ISPN-3414
> URL: https://issues.jboss.org/browse/ISPN-3414
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 6.0.0.Alpha2
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.Beta2
>
> Attachments: standalone.xml
>
>
> When I configure DefaultCacheManager with following configuration
> {code:title=Configurator.java|borderStyle=solid}
> ConfigurationBuilder bld = new ConfigurationBuilder();
> bld.clustering().cacheMode(CacheMode.LOCAL)
> .loaders().passivation(passivation).preload(preload).shared(false)
> .addLoader(JdbcMixedCacheStoreConfigurationBuilder.class).fetchPersistentState(false).purgeOnStartup(false)
> .databaseType(DatabaseType.MYSQL)
> .stringTable()
> .dropOnExit(false)
> .createOnStart(true)
> .tableNamePrefix("ISPN6Alpha2_STRING")
> .idColumnName("ID").idColumnType("VARCHAR(255)")
> .dataColumnName("DATA").dataColumnType("VARBINARY(1000)")
> .timestampColumnName("TIMESTAMP").timestampColumnType("BIGINT")
> .binaryTable()
> .dropOnExit(false)
> .createOnStart(true)
> .tableNamePrefix("ISPN6Alpha2_BINARY")
> .idColumnName("ID").idColumnType("VARCHAR(255)")
> .dataColumnName("DATA").dataColumnType("VARBINARY(1000)")
> .timestampColumnName("TIMESTAMP").timestampColumnType("BIGINT")
> .dataSource()
> .jndiUrl("java:jboss/datasources/ExampleDS");
> {code}
> And here is TableManipulation class with getDatabaseType() method
> {code:title=TableManipulation.java|borderStyle=solid}
> private DatabaseType getDatabaseType() {
> databaseType = config.databaseType();
> System.out.println(">>>>>>> databaseType "+ databaseType);
> if (databaseType == null) {
> // need to guess from the database type!
> Connection connection = null;
> ...
> {code}
> *Got the following output when test is running*
> !!!!! is printed from my client code
> >>>>> is printed from infinispan(TableManipulation.java)
> -----
> [java] 10:59:07,347 INFO [stdout] (pool-1-thread-1) !!!!!!! databasetype MYSQL
> [java] 10:59:07,500 INFO [org.infinispan.factories.GlobalComponentRegistry] (pool-1-thread-1) ISPN000128: Infinispan version: Infinispan 'Infinium' 6.0.0.Alpha2-redhat-1
> [java] 10:59:09,851 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:11,953 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:12,644 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:12,645 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:13,393 INFO [org.infinispan.jmx.CacheJmxRegistration] (pool-1-thread-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> [java] 10:59:24,780 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:24,954 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:25,260 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:29,679 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:29,680 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:29,843 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:29,844 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:30,002 INFO [org.infinispan.jmx.CacheJmxRegistration] (pool-1-thread-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> [java] 10:59:38,626 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:38,776 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:41,806 INFO [org.jboss.arquillian.testenricher.cdi.container.BeanManagerProducer] (pool-1-thread-1) BeanManager not found.
> [java] 10:59:41,813 INFO [stdout] (pool-1-thread-1) !!!!!!! databasetype MYSQL
> [java] 10:59:41,848 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:41,848 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:42,018 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:42,020 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:42,176 INFO [org.infinispan.jmx.CacheJmxRegistration] (pool-1-thread-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> [java] 10:59:52,364 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:52,515 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:52,667 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] 10:59:57,155 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> -----
> *And other issue with postgresqlplus92 DB, infinispan cannt recognize it like DatabaseType.POSTGRES* here is a link on our jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-jdbc-cache-st...
> -----
> [java] ^[[0m^[[0m10:53:45,198 INFO [stdout] (pool-1-thread-1) !!!!!!! databasetype POSTGRES
> [java] ^[[0m^[[0m10:53:45,348 INFO [org.infinispan.factories.GlobalComponentRegistry] (pool-1-thread-1) ISPN000128: Infinispan version: Infinispan 'Infinium' 6.0.0.Alpha2-redhat-1
> [java] ^[[0m^[[0m10:53:46,845 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:53:48,939 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:53:50,429 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:53:51,456 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:53:52,994 INFO [org.infinispan.jmx.CacheJmxRegistration] (pool-1-thread-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> [java] ^[[0m^[[0m10:53:59,232 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:53:59,414 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:01,807 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:04,020 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:06,084 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:07,275 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:08,303 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:09,509 INFO [org.infinispan.jmx.CacheJmxRegistration] (pool-1-thread-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> [java] ^[[0m^[[0m10:54:13,520 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:13,693 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:16,104 INFO [org.jboss.arquillian.testenricher.cdi.container.BeanManagerProducer] (pool-1-thread-1) BeanManager not found.
> [java] ^[[0m^[[0m10:54:16,111 INFO [stdout] (pool-1-thread-1) !!!!!!! databasetype POSTGRES
> [java] ^[[0m^[[0m10:54:16,148 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:18,180 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:19,352 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:20,358 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:21,531 INFO [org.infinispan.jmx.CacheJmxRegistration] (pool-1-thread-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> [java] ^[[0m^[[0m10:54:26,078 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:26,256 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[0m10:54:27,419 INFO [stdout] (pool-1-thread-1) >>>>>>> databaseType null
> [java] ^[[0m^[[31m10:54:57,421 ERROR [org.infinispan.loaders.jdbc.connectionfactory.ManagedConnectionFactory] (pool-1-thread-1) ISPN008018: Sql failure retrieving connection from datasource: java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/ExampleDS
> [java] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:147)
> [java] at org.infinispan.loaders.jdbc.connectionfactory.ManagedConnectionFactory.getConnection(ManagedConnectionFactory.java:82) [infinispan-cachestore-jdbc.jar:6.0.0.Alpha2-redhat-1]
> [java] at org.infinispan.loaders.jdbc.TableManipulation.getDatabaseType(TableManipulation.java:396) [infinispan-cachestore-jdbc.jar:6.0.0.Alpha2-redhat-1]
> [java] at org.infinispan.loaders.jdbc.TableManipulation.getSelectRowSql(TableManipulation.java:193) [infinispan-cachestore-jdbc.jar:6.0.0.Alpha2-redhat-1]
> [java] at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.loadBucket(JdbcBinaryCacheStore.java:247) [infinispan-cachestore-jdbc.jar:6.0.0.Alpha2-redhat-1]
> -----
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3600:
--------------------------------
Labels: jdg62blocker (was: )
> ignorePreviousValue should not be set on non-origin nodes
> ---------------------------------------------------------
>
> Key: ISPN-3600
> URL: https://issues.jboss.org/browse/ISPN-3600
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
> Labels: jdg62blocker
>
> In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution.
> Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3603) Conditional command is committed when it fails on primary owner
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3603:
--------------------------------
Labels: jdg62blocker (was: )
> Conditional command is committed when it fails on primary owner
> ---------------------------------------------------------------
>
> Key: ISPN-3603
> URL: https://issues.jboss.org/browse/ISPN-3603
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
> Labels: jdg62blocker
>
> In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway.
> Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3449:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1002532|https://bugzilla.redhat.com/show_bug.cgi?id=1002532] from ON_QA to VERIFIED
> ReplaceCommand with ignorePrevValue=true does not work on null entries
> ----------------------------------------------------------------------
>
> Key: ISPN-3449
> URL: https://issues.jboss.org/browse/ISPN-3449
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.Beta2
>
>
> If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
> The command on primary owner succeeds as it does not check whether the responses are successful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3603) Conditional command is committed when it fails on primary owner
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3603:
--------------------------------
Affects Version/s: 6.0.0.CR1
> Conditional command is committed when it fails on primary owner
> ---------------------------------------------------------------
>
> Key: ISPN-3603
> URL: https://issues.jboss.org/browse/ISPN-3603
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway.
> Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3604) Provide JMX operation which shows the numberOfEntries in the entire dist-cache
by Duncan Doyle (JIRA)
Duncan Doyle created ISPN-3604:
----------------------------------
Summary: Provide JMX operation which shows the numberOfEntries in the entire dist-cache
Key: ISPN-3604
URL: https://issues.jboss.org/browse/ISPN-3604
Project: Infinispan
Issue Type: Feature Request
Components: JMX, reporting and management
Affects Versions: 6.0.0.CR1
Environment: Max OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Infinispan 5.2.4.Final
Reporter: Duncan Doyle
Assignee: Mircea Markus
The Infinispan statistics component only shows the 'numberOfEntries' in a particular node, including entries of which the node is not the primary owner (basically, doing a sum of this value of all the cluster members gives you (numberOfEntries * numOwners). The 'cache.keySet()' method does return the entire keyset, and thus you can calculate the numberOfEntries in the cache, but this requires writing custom code in a cache client. It would be nice if Infinispan would provide a JMX operation which is able to show the number of entries in the entire dist-cache cluster.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months