[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
Jitka,
Can you validate that this commit fixes this issue?
https://github.com/pferraro/jboss-eap/commit/f4b710931da30a401cdd2b3aada1...
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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, 9 months
[JBoss JIRA] (ISPN-3298) Can't retrieve evicted entries from FileCacheStore
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-3298?page=com.atlassian.jira.plugin.... ]
Jakub Markos updated ISPN-3298:
-------------------------------
Issue Type: Bug (was: Feature Request)
> Can't retrieve evicted entries from FileCacheStore
> --------------------------------------------------
>
> Key: ISPN-3298
> URL: https://issues.jboss.org/browse/ISPN-3298
> Project: Infinispan
> Issue Type: Bug
> Reporter: Jakub Markos
> Assignee: Mircea Markus
> Attachments: server.log
>
>
> When using this configuration for the latest (6.0.0-SNAPSHOT) infinispan-server:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="local">
> <cache-container name="local" default-cache="default">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <eviction strategy="LRU" max-entries="5"/>
> <file-store passivation="true" path="dc" purge="true" shared="false"/>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> and running this code:
> {code}
> for (int i = 0; i < 6; i++) {
> cache.put("k" + i, "v" + i);
> }
> for (int i = 0; i < 6; i++) {
> System.out.println("k" + i + ": " + cache.get("k" + i));
> }
> {code}
> I'm getting (reproducibly):
> {quote}
> k0: null
> k1: v1
> k2: v2
> k3: null
> k4: v4
> k5: v5
> {quote}
> The directory $\{server\}/standalone/data/dc/default/ contains 2 files (with v0 and v3).
> Server trace log attached.
--
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, 9 months
[JBoss JIRA] (ISPN-3293) Putting entries with memcached is ignoring the queue-flush-interval parameter
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-3293?page=com.atlassian.jira.plugin.... ]
Jakub Markos updated ISPN-3293:
-------------------------------
Issue Type: Bug (was: Feature Request)
> Putting entries with memcached is ignoring the queue-flush-interval parameter
> -----------------------------------------------------------------------------
>
> Key: ISPN-3293
> URL: https://issues.jboss.org/browse/ISPN-3293
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jakub Markos
> Assignee: Tristan Tarrant
> Attachments: server1.log, server2.log
>
>
> I have a cluster of 2 nodes with the following configuration:
> {code:xml}
> <replicated-cache name="memcachedCache"
> start="EAGER"
> mode="ASYNC"
> batching="false"
> queue-size="1000"
> queue-flush-interval="15000">
> </replicated-cache>
> {code}
> The following code (MemcachedHelper is a memcached client)
> {code}
> mc1 = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint().getPort());
> mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint().getPort());
> mc1.set("key1", "value1");
> assertTrue(null != mc1.get("key1"));
> assertTrue(null == mc2.get("key1"));
> {code}
> fails on the 2nd assert, because the entry is retrieved.
> According to logs (attached), the replication queue is correctly flushed after 15 seconds with 1 element (and happens after the gets).
> Works correctly with hotrod (entry is replicated only after the flush happens).
--
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, 9 months
[JBoss JIRA] (ISPN-2161) InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2161?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-2161:
-----------------------------------
[~mircea.markus] [~galder.zamarreno]
I've start looking at this issue and I going to remove the InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit because what is testing is invalid.
In pessimist caches, we have only phase (PrepareCommand with onePhaseCommit to true). So we only have two scenarios:
* initiator dies before prepare (covered in testInitiatorNodeCrashesBeforePrepare)
* initiator dies after prepare (covered in testInitiatorCrashesBeforeReleasingLock)
[~galder.zamarreno] I cannot see the link and I don't know if you remember, but is testInitiatorCrashesBeforeReleasingLock only failing in the Optimistic test?
Also, I will do a cleaning service: removing assert to AssertJUnit*, fork with callable, etc...
> InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2161
> URL: https://issues.jboss.org/browse/ISPN-2161
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 6.0.0.Alpha1, 6.0.0.Final
>
> Attachments: testInitiatorNodeCrashesBeforeCommit-0.log
>
>
> Failed tests: testInitiatorNodeCrashesBeforeCommit(org.infinispan.lock.singlelock.replicated.pessimistic.InitiatorCrashPessimisticReplTest): expected key 'k' to be locked on cache Cache '___defaultcache'@InitiatorCrashPessimisticReplTest-NodeD-44283, but it is not
--
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, 9 months
[JBoss JIRA] (ISPN-3242) Require the use of Java7 for building Infinispan
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3242?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3242:
----------------------------------------
Mircea, JCache TCK requires JDK7 to be run. I sent an email to the dev list. The alternatives were: either force people to have a JDK environment variable pre-defined, or move to building with JDK7. The latter should work better, as long as we produce JDK6 binaries, which Tristan's patch achieves.
> Require the use of Java7 for building Infinispan
> ------------------------------------------------
>
> Key: ISPN-3242
> URL: https://issues.jboss.org/browse/ISPN-3242
> Project: Infinispan
> Issue Type: Feature Request
> Components: Build process
> Affects Versions: 5.3.0.Final
> Reporter: Manik Surtani
> Assignee: Tristan Tarrant
> Fix For: 6.0.0.Alpha1, 6.0.0.Final
>
>
> Note that this doesn't force Java7 at runtime, just build-time. Need to take into account continuous integration runs where the project will need to be built using Java7 but tested on Java6.
--
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, 9 months
[JBoss JIRA] (ISPN-3298) Can't retrieve evicted entries from FileCacheStore
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-3298?page=com.atlassian.jira.plugin.... ]
Jakub Markos updated ISPN-3298:
-------------------------------
Attachment: server.log
> Can't retrieve evicted entries from FileCacheStore
> --------------------------------------------------
>
> Key: ISPN-3298
> URL: https://issues.jboss.org/browse/ISPN-3298
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Jakub Markos
> Assignee: Mircea Markus
> Attachments: server.log
>
>
> When using this configuration for the latest (6.0.0-SNAPSHOT) infinispan-server:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="local">
> <cache-container name="local" default-cache="default">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <eviction strategy="LRU" max-entries="5"/>
> <file-store passivation="true" path="dc" purge="true" shared="false"/>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> and running this code:
> {code}
> for (int i = 0; i < 6; i++) {
> cache.put("k" + i, "v" + i);
> }
> for (int i = 0; i < 6; i++) {
> System.out.println("k" + i + ": " + cache.get("k" + i));
> }
> {code}
> I'm getting (reproducibly):
> {quote}
> k0: null
> k1: v1
> k2: v2
> k3: null
> k4: v4
> k5: v5
> {quote}
> The directory $\{server\}/standalone/data/dc/default/ contains 2 files (with v0 and v3).
> Server trace log attached.
--
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, 9 months