July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3227) Server loader configuration breaks when properties are specified

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3227?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3227: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] > Server loader configuration breaks when properties are specified > ---------------------------------------------------------------- > > Key: ISPN-3227 > URL: https://issues.jboss.org/browse/ISPN-3227 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.6.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.7.Final > > -- 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-3289) PutForExternalRead should only write the value on the originator once

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3289?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3289: ----------------------------------- Assignee: Dan Berindei (was: William Burns) > PutForExternalRead should only write the value on the originator once > --------------------------------------------------------------------- > > Key: ISPN-3289 > URL: https://issues.jboss.org/browse/ISPN-3289 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.Final > > > putForExternalRead behaves as an asynchronous, non-transactional write operation even in tx caches, and as such it uses lock delegation. > Let's say we have a cluster with two nodes: [A, B], and a key k with owners(k) = [A, B]. > If B is the originator of a PFER(k, v) operation, the command is first executed locally on B, then it is invoked asynchronously on the primary owner A, and A invokes it asynchronously on B (because of the FORCE_ASNCHRONOUS flag). > For regular non-tx write operations, the entry k=v is only written to the data container on B during the second invocation. For PFER, however, the entry is written twice: once during each execution. > This causes random failures in {{PutForExternalRead*Test.testNoOpWhenKeyPresent}}, because the test assumes that the PFER finished once the entry was written once on each owner. > Arguably the fact that the primary owner forwards the PFER command asynchronously is also a problem, because the put command will write the value on B without holding a lock on A, the primary owner. -- 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-3157) Realign Infinispan subsystem to match AS7.2/EAP6.1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3157?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3157: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] built and tested, now packaging > Realign Infinispan subsystem to match AS7.2/EAP6.1 > -------------------------------------------------- > > Key: ISPN-3157 > URL: https://issues.jboss.org/browse/ISPN-3157 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 5.3.0.Final > > -- 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-3227) Server loader configuration breaks when properties are specified

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3227?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3227: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] built and tested, now packaging > Server loader configuration breaks when properties are specified > ---------------------------------------------------------------- > > Key: ISPN-3227 > URL: https://issues.jboss.org/browse/ISPN-3227 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.6.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.7.Final > > -- 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 Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2161?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2161: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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-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: ----------------------------------------------- Jitka Kudrnacova <jkudrnac(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] The patch does NOT fixes this problem. See this job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-http... And the parsed client logs: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-http... > 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-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: ----------------------------------------------- Jitka Kudrnacova <jkudrnac(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from POST to MODIFIED > 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-3307) Fix Stackoverflow error in CHMv8

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-3307: -------------------------------------- Summary: Fix Stackoverflow error in CHMv8 Key: ISPN-3307 URL: https://issues.jboss.org/browse/ISPN-3307 Project: Infinispan Issue Type: Bug Affects Versions: 5.3.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 6.0.0.Alpha1, 6.0.0.Final Fix StackOverflow issue in CHMv8 implementation: http://cs.oswego.edu/pipermail/concurrency-interest/2013-July/011541.html Current version is 1.110, so update to that: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/Concurren... -- 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-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: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from ASSIGNED to POST > 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-3112) KeyAffinityService API - provide overload of getKeyForAddress()

by Ben Cotton (JIRA)

[ https://issues.jboss.org/browse/ISPN-3112?page=com.atlassian.jira.plugin.... ] Ben Cotton commented on ISPN-3112: ---------------------------------- The resolution of this JIRA fixes what we believe is a KeyAffinityService API delinquency. I.e. When my DIST_SYNC Cache’s Node X (@t=0) generates an Affinity-Key ‘aK’ for a Natural-Key ‘nK’ via aK = kas.getCollocatedKey(nK); // aK guarantees that nk will be pinned at Node X cache.put(aK, V); // pin the nK’s VALUE (via aK) at Node X Later, from my Cache’s Node Y (@t=1) I want to now get() the nK’s VALUE that was pinned at Node X (@t=0) without having Node Y to have an available reference to the previously computed AffintyKey aK. I currently cannot do that with the 5.x ISPN API. We need ISPN-3112 resolved so that from Node Y (@t=1) I can simply code // get VALUE from pinned node with nK – no need for an ‘aK’ reference V = cache.get(kas.getKeyForAddress(this.getAddress(NodeX), nK); > KeyAffinityService API - provide overload of getKeyForAddress() > --------------------------------------------------------------- > > Key: ISPN-3112 > URL: https://issues.jboss.org/browse/ISPN-3112 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Cache > Affects Versions: 5.3.0.Beta1 > Reporter: Ben Cotton > Assignee: Mircea Markus > Priority: Minor > > Add to the org.inifinispan.affinity.KeyAffinityService<K> interface an overload = > *K getKeyForAddress(Address address, K otherKey);* > //compute address specific version of 'otherKey' -- 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