[JBoss JIRA] (ISPN-1540) Refactor distribution interceptor
by Mircea Markus (Created) (JIRA)
Refactor distribution interceptor
---------------------------------
Key: ISPN-1540
URL: https://issues.jboss.org/browse/ISPN-1540
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Reporter: Mircea Markus
Assignee: Mircea Markus
DistributionInterceptor, as it looks now is unnecessary complex. Before adding more functionality on top of it (i.e. ISPN-1539) it should be refactored:
- extract L1 logic into a different interceptor
- this would require moving the StateTransferLock logic into another interceptor as well
- now that we have separation between tx and non-tx caches, we can extract the remaining logic into TransactionalDistributionInterceptor and NonTransactional...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-1466) Async configuration tag affects communication between cache and HotRod client
by Martin Gencur (Created) (JIRA)
Async configuration tag affects communication between cache and HotRod client
-----------------------------------------------------------------------------
Key: ISPN-1466
URL: https://issues.jboss.org/browse/ISPN-1466
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.0.ALPHA1
Reporter: Martin Gencur
Assignee: Manik Surtani
When using a REPL (replicated) cache with configuration tag <async useReplQueue="true" replQueueMaxElements="3" replQueueInterval="1000" />, HotRod client cannot see a cache entry which was just stored into a cache. The entry is visible not before the replication queue is flushed (either because of MaxElements limit or QueueInterval). I'll attach a testcase but here's a test snippet that fails at first assert:
{code}
@Test
public void testQueueSize() throws Exception {
RemoteCache<String, String> asyncCache1 = rcm1.getCache(asyncCacheSize);
RemoteCache<String, String> asyncCache2 = rcm2.getCache(asyncCacheSize);
asyncCache1.clear();
asyncCache1.put("k1", "v1");
assertTrue(null != asyncCache1.get("k1"));
assertTrue(null == asyncCache2.get("k2"));
asyncCache1.put("k2", "v2");
//k3 fills up the queue -> flush
asyncCache1.put("k3", "v3");
Thread.sleep(1000); //wait for the queue to be flushed
assertTrue(null != asyncCache1.get("k1"));
assertTrue(null != asyncCache2.get("k2"));
}
{code}
IMO when I have cache A and B in a cluster and the cache entry is stored into the cache A, it should be visible at A and not in B. After flushing the queue it should be visible also at B.
Here's the test:
https://svn.devel.redhat.com/repos/jboss-qa/edg/infinispan-functional-tes...
(to run it, one has to install infinispan-arquillian-container into local maven repository, set ISPN_HOME pointing to Infinispan distribution and run "mvn clean verify")
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (ISPN-1319) topology changes makes entire cluster inconsistent
by Jan Slezak (JIRA)
topology changes makes entire cluster inconsistent
--------------------------------------------------
Key: ISPN-1319
URL: https://issues.jboss.org/browse/ISPN-1319
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 5.0.0.FINAL
Environment: linux / devel environment / 1.6.0_26
Reporter: Jan Slezak
Assignee: Manik Surtani
Priority: Blocker
Invoke timeout exception in replicated or distributed environment (the issue occurred in both) during topology change on producer node - after that the data may end up in inconsistent state on other nodes (in my case n+1 entities on some of the nodes). I tried that with many TM / ISPN configurations in sync mode using DummyTransactionManagerLookup. Same behavior using invocation batching ...
example xml:
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:5.0 http://www.infinispan.org/schemas/infinispan-config-5.0.xsd"
xmlns="urn:infinispan:config:5.0">
<global>
<transport clusterName="ifprotocluster"/>
</global>
<default>
<clustering mode="distribution">
<l1 enabled="false"/>
<hash numOwners="100" rehashRpcTimeout="120000" />
<sync/>
</clustering>
<transaction
transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
syncRollbackPhase="true"
syncCommitPhase="true"
useEagerLocking="true"
/>
</default>
</infinispan>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-1441) Better and more sensible executor configuration
by Galder Zamarreño (Created) (JIRA)
Better and more sensible executor configuration
-----------------------------------------------
Key: ISPN-1441
URL: https://issues.jboss.org/browse/ISPN-1441
Project: Infinispan
Issue Type: Enhancement
Components: Configuration
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 6.0.0.FINAL
Dan and I had a chat about ISPN-1396 and we both agreed that a better configuration and management approach is needed for Infinispan's executors:
- Firstly, out of the box for SE environments, Infinispan should have executors configured with newCachedThreadPool because they provide better queuing performance than a fixed thread pool.
- Sure, in an managed env (i.e. AS), this won't fly, which is why all executors need to be injectable. This should be in place once ISPN-1396 is in place.
- So, if we go for cached thread pools for SE environments, we don't need any of the properties of executors any more. Besides, these can be more confusing for the user (there is knowledged of at least one case where things went wrong due to bad config here). So, the configuration would be limited to injecting executors. If you need any specific executor settings, pass us the right executors. To aid these cases, we could have some executor builders available with some common executor configuration for managed envs (i.e. we could borrow settings from AS?)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months