July 2013 - infinispan-issues - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-3288) Putting an entry with rest gives 'Failure to marshall arguments' error

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-3288?page=com.atlassian.jira.plugin.... ] Jakub Markos updated ISPN-3288: ------------------------------- Issue Type: Bug (was: Feature Request) > Putting an entry with rest gives 'Failure to marshall arguments' error > ---------------------------------------------------------------------- > > Key: ISPN-3288 > URL: https://issues.jboss.org/browse/ISPN-3288 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Attachments: stacktrace.txt, standalone-repl.xml > > > The test has a cluster with 2 nodes. > See the attached file for the full console output and server config (same for both nodes). -- 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-3284) Remove dependency to Hibernate ORM in RHQ plugin

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3284?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3284: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove dependency to Hibernate ORM in RHQ plugin > ------------------------------------------------ > > Key: ISPN-3284 > URL: https://issues.jboss.org/browse/ISPN-3284 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha1 > > -- 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

1
0
0 / 0

[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 updated ISPN-3242: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3081) Logging produces strange beginning of lines

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-3081?page=com.atlassian.jira.plugin.... ] Michal Linhard updated ISPN-3081: --------------------------------- Attachment: configs.zip serverlogs.zip attaching the files, removing the linked jenkins job > Logging produces strange beginning of lines > ------------------------------------------- > > Key: ISPN-3081 > URL: https://issues.jboss.org/browse/ISPN-3081 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Alpha1 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > Attachments: configs.zip, serverlogs.zip > > > This is what I get on the console when running infinispan-server-5.3.0-SNAPSHOT > {code} > [0m06:38:12,718 INFO [org.jboss.modules] (main) JBoss Modules version 1.2.0.CR1 > [0m[0m06:38:13,282 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA > [0m[0m06:38:13,486 INFO [org.jboss.as] (MSC service thread 1-7) JBAS015899: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) starting > [0m[31m06:38:14,687 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > .. > {code} > configuration: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-cs-client-s... > whole logs: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-cs-client-s... -- 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

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013