[JBoss JIRA] (ISPN-3640) Extend KeyFilter facility to the whole cache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3640?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3640:
-------------------------------------
Assignee: (was: Mircea Markus)
> Extend KeyFilter facility to the whole cache
> --------------------------------------------
>
> Key: ISPN-3640
> URL: https://issues.jboss.org/browse/ISPN-3640
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
>
> The key filter facility is very convenient for users who have multiple key types in the same cache. It would be very handy if this feature were extended to the whole cache.
> e.g.
> Cache<?, ?> cache = ...;
> KeyFilter filter = ...;
> Cache<K, V> view = cache.filter(filter);
> view.addListener(listener) // Equivalent to the current cache.addListener(listener, filter) method
> for (Map.Entry<K, V> entry: view.entrySet()) {
> ...
> }
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-2399) CacheManager.startCaches very slow when multiple caches are passed in
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2399?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2399:
-------------------------------------
Assignee: (was: Mircea Markus)
> CacheManager.startCaches very slow when multiple caches are passed in
> ---------------------------------------------------------------------
>
> Key: ISPN-2399
> URL: https://issues.jboss.org/browse/ISPN-2399
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 5.2.0.Beta1
> Reporter: Mircea Markus
> Priority: Minor
>
> the TransactionsSpanningReplicatedCachesTest uses the following code to start multiple caches:
> {code:java}
> cm1.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME);
> cm2.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME);
> waitForClusterToForm("c1", "c2", "cache1", "cache2");
> {code}
> On my machine(MBP) this executes in 12 mins.The functionally equivalent below executes in 15 secs:
> {code:java}
> private void startAllCaches() {
> startCache("c1");
> startCache("c2");
> startCache("cache1");
> startCache("cache2");
> startCache(CacheContainer.DEFAULT_CACHE_NAME);
> }
> private void startCache(String c1) {
> cm1.getCache(c1);
> cm2.getCache(c1);
> waitForClusterToForm(c1);
> }
> {code}
> We need to analyse why this takes so long and also updated the test to use the CacheManagers.startCaches..
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3520) Cassandra Cache Store is read-only by default
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3520?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3520:
-------------------------------------
Assignee: (was: Mircea Markus)
> Cassandra Cache Store is read-only by default
> ---------------------------------------------
>
> Key: ISPN-3520
> URL: https://issues.jboss.org/browse/ISPN-3520
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.6.Final, 6.0.0.Alpha4
> Reporter: Giovanni Mels
> Attachments: PassivationTest.java
>
>
> It is impossible to store any data in the Cassandra cache store, because it is created as read-only, even when specifying {{ignoreModifications = false}}. See the attached test case:
> [INFO ] ISPN000078: Starting JGroups Channel (org.infinispan.remoting.transport.jgroups.JGroupsTransport)
> [INFO ] ISPN000088: Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration! (org.infinispan.remoting.transport.jgroups.JGroupsTransport)
> [INFO ] ISPN000094: Received new cluster view: [GNELA182-53637|0] [GNELA182-53637] (org.infinispan.remoting.transport.jgroups.JGroupsTransport)
> [INFO ] ISPN000079: Cache local address is GNELA182-53637, physical addresses are [fe80:0:0:0:64f5:4fad:cd2e:b5cf:51350] (org.infinispan.remoting.transport.jgroups.JGroupsTransport)
> [INFO ] ISPN000128: Infinispan version: Infinispan 'Delirium' 5.2.6.Final (org.infinispan.factories.GlobalComponentRegistry)
> [DEBUG] automatically create keyspace (org.infinispan.loaders.cassandra.CassandraCacheStore)
> [INFO ] ConnectionPool initialized. (net.dataforte.cassandra.pool.ConnectionPool)
> [DEBUG] cleaning up expired entries... (org.infinispan.loaders.cassandra.CassandraCacheStore)
> [TRACE] purgeInternal (org.infinispan.loaders.cassandra.CassandraCacheStore)
> [INFO ] ConnectionPool initialized. (net.dataforte.cassandra.pool.ConnectionPool)
> [DEBUG] started (org.infinispan.loaders.cassandra.CassandraCacheStore)
> *[TRACE] Ignoring clear invocation (org.infinispan.loaders.decorators.ReadOnlyStore)*
> [INFO ] ISPN000031: MBeans were successfully registered to the platform MBean server. (org.infinispan.jmx.CacheJmxRegistration)
> [INFO ] creating test1 (com.agfa.aca.PassivationTest)
> [DEBUG] Key 'entry_test1' not found (org.infinispan.loaders.cassandra.CassandraCacheStore)
> *[TRACE] Ignoring removal of key (org.infinispan.loaders.decorators.ReadOnlyStore)*
> [INFO ] created test1 (com.agfa.aca.PassivationTest)
> [INFO ] creating test2 (com.agfa.aca.PassivationTest)
> [DEBUG] Key 'entry_test2' not found (org.infinispan.loaders.cassandra.CassandraCacheStore)
> [INFO ] passivating test1 (com.agfa.aca.PassivationTest)
> *[TRACE] Ignoring store invocation (org.infinispan.loaders.decorators.ReadOnlyStore)*
> [INFO ] passivated test1 (com.agfa.aca.PassivationTest)
> *[TRACE] Ignoring removal of key (org.infinispan.loaders.decorators.ReadOnlyStore)*
> [INFO ] created test2 (com.agfa.aca.PassivationTest)
> [DEBUG] Key 'entry_test1' not found (org.infinispan.loaders.cassandra.CassandraCacheStore)
> I tracked this bug down to the {{create}} method in {{CassandraCacheStoreConfigurationBuilder}}
> {code}
> @Override
> public CassandraCacheStoreConfiguration create() {
> List<CassandraServerConfiguration> remoteServers = new ArrayList<CassandraServerConfiguration>();
> for (CassandraServerConfigurationBuilder server : servers) {
> remoteServers.add(server.create());
> }
> return new CassandraCacheStoreConfiguration(autoCreateKeyspace, configurationPropertiesFile, entryColumnFamily,
> expirationColumnFamily, framed, remoteServers, keyMapper, keySpace, password, sharedKeyspace, username,
> readConsistencyLevel, writeConsistencyLevel, autoCreateKeyspace, sharedKeyspace, purgerThreads, framed,
> autoCreateKeyspace, TypedProperties.toTypedProperties(properties), async.create(), singletonStore.create());
> }
> {code}
> Note how {{autoCreateKeyspace}} is used in stead of {{purgeInternal}} and {{ignoreModifications}}, so if you explicitly set {{autoCreateKeyspace = false}} you can work around the issue.
> This is tested on 5.2.6, all versions from 5.2 on have the same error.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4799) RHQ server plugin: JDBC store columns (3) were NOT applied from RHQ console
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4799?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4799:
-------------------------------------
Assignee: (was: Mircea Markus)
> RHQ server plugin: JDBC store columns (3) were NOT applied from RHQ console
> ---------------------------------------------------------------------------
>
> Key: ISPN-4799
> URL: https://issues.jboss.org/browse/ISPN-4799
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Beta2
> Reporter: Tomas Sykora
> Labels: management, rhq
>
> Recent changes in RHQ server plugin added a possibility to configure JDBC stores (3 types - string, binary and mixed one) as a new child resource for a cache running inside of server. Those stores stand along other stores/loader possibilities.
> When a new resource is configured and set to finished (invoke creation operation), the standalone.xml file is changed respectively.
> However, we miss enlisted properties somewhere on the way and those are NOT included in modified configuration XML file.
> Data Column
> Id Column
> Timestamp Column
> are NOT set correctly and even a template is NOT included in server config either.
> Other properties are propagated and set accordingly.
> Expected result:
> {code:xml}
> <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="true" preload="false" purge="false" shared="false">
> <!-- property name="databaseType">H2</property -->
> <string-keyed-table prefix="ISPN_MC_SK">
> <id-column name="id" type="VARCHAR"/>
> <data-column name="datum" type="BINARY"/>
> <timestamp-column name="version" type="BIGINT"/>
> </string-keyed-table>
> <write-behind flush-lock-timeout="1" modification-queue-size="1024" shutdown-timeout="25000" thread-pool-size="1"/>
> </string-keyed-jdbc-store>
> {code}
> Current result (wrong, missing stuff):
> {code:xml}
> <string-keyed-jdbc-store name="string-keyed-store" datasource="java:jboss/datasources/JdbcDS" shared="false" preload="true" passivation="false" purge="false">
> <string-keyed-table/>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3632) server.memcached.MemcachedClusteredStatsTest.testSingleConnectionPerServer fails randomly
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3632?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3632:
-------------------------------------
Assignee: (was: Mircea Markus)
> server.memcached.MemcachedClusteredStatsTest.testSingleConnectionPerServer fails randomly
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-3632
> URL: https://issues.jboss.org/browse/ISPN-3632
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.CR1, 7.0.0.Alpha1, 7.0.0.Alpha2
> Environment: OPEN JDK6, RHEL5_x86
> OPEN JDK6, RHEL5_x86_64
> OPEN JDK7, RHEL6_x86_64
> Reporter: Vitalii Chepeliuk
> Labels: testsuite_stability
> Attachments: MemcachedClusteredStatsTest.testSingleConnectionPerServer.log.zip
>
>
> java.lang.AssertionError: expected [2] but found [1]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertEquals(Assert.java:118)
> at org.testng.Assert.assertEquals(Assert.java:160)
> at org.infinispan.server.core.ConnectionStatsTest$.testGlobalConnections(ConnectionStatsTest.scala:45)
> at org.infinispan.server.memcached.MemcachedClusteredStatsTest.testSingleConnectionPerServer(MemcachedClusteredStatsTest.scala:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> 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:1146)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4106) RHQ server plugin: remote store cache child creation fails
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4106?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4106:
-------------------------------------
Assignee: (was: Mircea Markus)
> RHQ server plugin: remote store cache child creation fails
> ----------------------------------------------------------
>
> Key: ISPN-4106
> URL: https://issues.jboss.org/browse/ISPN-4106
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Reporter: Tomas Sykora
>
> We are unable to configure remote cache store for a particular cache from RHQ GUI for a server.
> It does not even put any configuration fragments into standalone.xml file. The only reasonable message I was able to extract was INFO from a RHQ server itself:
> 09:45:16,719 INFO [org.rhq.enterprise.server.resource.ResourceFactoryServerServiceImpl] (http-/0.0.0.0:7080-6) Received create resource response: CreateResourceResponse[RequestId=10111, Status=Failure]
> Unfortunately, TRACE logging says nothing there.
> ISPN server and Agent logs does not contain any useful information either.
> This issue needs to be investigated further and deeply. This is just the first heads up and for a proper tracing of this bug.
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-2902) document exception handling in Infinispan
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2902?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2902:
-------------------------------------
Assignee: (was: Mircea Markus)
> document exception handling in Infinispan
> -----------------------------------------
>
> Key: ISPN-2902
> URL: https://issues.jboss.org/browse/ISPN-2902
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 5.2.3.Final
> Reporter: Mircea Markus
>
> Map/ConcurrentMap operations, as overridden by Infinispan, might throw various runtime exception to the user. These exceptions should be:
> - documented (API)
> - the user should be informed about what happens in the case of any such exceptions being thrown (e.g. the operation hasn't succeed an all nodes, the cache might be inconsistent, etc). This again should be added in the javadoc
> (ISPN-629 did part of the job for TimeoutException)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months