March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4092) ViewChangedEvent.getOldMembers() and getNewMembers() should never be null

by Eric Bonnot (JIRA)

[ https://issues.jboss.org/browse/ISPN-4092?page=com.atlassian.jira.plugin.... ] Eric Bonnot commented on ISPN-4092: ----------------------------------- The modification of those two functions in the class org.infinispan.notifications.cachemanagerlistener.event.EventImpl doesn't work : there is now a test to check if the lists are null or not, and if they are a new list is created, but the new list is never affected or returned. Should it be : @Override public List<Address> getNewMembers() { if(newMembers == null){ this.newMembers = InfinispanCollections.emptyList(); } return this.newMembers; } and : @Override public List<Address> getOldMembers() { if(oldMembers == null){ this.oldMembers = InfinispanCollections.emptyList(); } return this.oldMembers; } > ViewChangedEvent.getOldMembers() and getNewMembers() should never be null > ------------------------------------------------------------------------- > > Key: ISPN-4092 > URL: https://issues.jboss.org/browse/ISPN-4092 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Eric Bonnot > Assignee: Thomas Fromm > Priority: Minor > > Simply for more comfort at usage I'd like to have ViewChangedEvent changed, that the list-getter never return null. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4092) ViewChangedEvent.getOldMembers() and getNewMembers() should never be null

by Eric Bonnot (JIRA)

[ https://issues.jboss.org/browse/ISPN-4092?page=com.atlassian.jira.plugin.... ] Eric Bonnot updated ISPN-4092: ------------------------------ Fix Version/s: (was: 5.2.0.Final) (was: 5.2.0.ALPHA1) > ViewChangedEvent.getOldMembers() and getNewMembers() should never be null > ------------------------------------------------------------------------- > > Key: ISPN-4092 > URL: https://issues.jboss.org/browse/ISPN-4092 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Eric Bonnot > Assignee: Thomas Fromm > Priority: Minor > > Simply for more comfort at usage I'd like to have ViewChangedEvent changed, that the list-getter never return null. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4092) ViewChangedEvent.getOldMembers() and getNewMembers() should never be null

by Eric Bonnot (JIRA)

[ https://issues.jboss.org/browse/ISPN-4092?page=com.atlassian.jira.plugin.... ] Eric Bonnot updated ISPN-4092: ------------------------------ Issue Type: Bug (was: Enhancement) > ViewChangedEvent.getOldMembers() and getNewMembers() should never be null > ------------------------------------------------------------------------- > > Key: ISPN-4092 > URL: https://issues.jboss.org/browse/ISPN-4092 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Eric Bonnot > Assignee: Thomas Fromm > Priority: Minor > > Simply for more comfort at usage I'd like to have ViewChangedEvent changed, that the list-getter never return null. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4092) ViewChangedEvent.getOldMembers() and getNewMembers() should never be null

by Eric Bonnot (JIRA)

Eric Bonnot created ISPN-4092: --------------------------------- Summary: ViewChangedEvent.getOldMembers() and getNewMembers() should never be null Key: ISPN-4092 URL: https://issues.jboss.org/browse/ISPN-4092 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 5.1.4.FINAL Reporter: Eric Bonnot Assignee: Thomas Fromm Priority: Minor Fix For: 5.2.0.ALPHA1, 5.2.0.Final Simply for more comfort at usage I'd like to have ViewChangedEvent changed, that the list-getter never return null. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4092) ViewChangedEvent.getOldMembers() and getNewMembers() should never be null

by Eric Bonnot (JIRA)

[ https://issues.jboss.org/browse/ISPN-4092?page=com.atlassian.jira.plugin.... ] Eric Bonnot updated ISPN-4092: ------------------------------ Affects Version/s: 6.0.1.Final (was: 5.1.4.FINAL) > ViewChangedEvent.getOldMembers() and getNewMembers() should never be null > ------------------------------------------------------------------------- > > Key: ISPN-4092 > URL: https://issues.jboss.org/browse/ISPN-4092 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Eric Bonnot > Assignee: Thomas Fromm > Priority: Minor > Fix For: 5.2.0.ALPHA1, 5.2.0.Final > > > Simply for more comfort at usage I'd like to have ViewChangedEvent changed, that the list-getter never return null. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4053) WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4053?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4053: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode > ----------------------------------------------------------------------- > > Key: ISPN-4053 > URL: https://issues.jboss.org/browse/ISPN-4053 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 621 > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > The writeSkewCheck flag does not work correctly for AtomicMap. When Infinispan runs in REPEATABLE_READ isolation mode for transactions, the writeSkewCheck flag is enabled, and two concurrent transactions read/write data from the same AtomicMap. The WriteSkewException exception is never thrown when committing either of the transactions. > Consequently, the data stored in the AtomicMap might be changed by another transaction, and current transaction will not register this change during commit. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4024) Cross-Site State transfer: alpha version

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4024?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4024: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Cross-Site State transfer: alpha version > ---------------------------------------- > > Key: ISPN-4024 > URL: https://issues.jboss.org/browse/ISPN-4024 > Project: Infinispan > Issue Type: Sub-task > Components: Cross-Site Replication > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > Cross-Site Replication State Transfer in a stable topology (i.e. no nodes leaving or joining during the state transfer). -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4085) Random failures in StateProviderTest due to race condition

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4085?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-4085: ----------------------------------------- Apart from the different executor, test2 still mocks some behaviours that test1 don't, uses 4 entries in the cache rather than 2, uses the isRebalance = false flag but all the rest is pretty much copy and paste. The extra behaviours mocked can be safely removed since rpcManager.invokeRemotelyInFuture is not called in the StateTransfer code (OutboundTransferTask uses the invokeRemotely), the same for the unused isRebalance flag. The alternative fix would be to delete test2(). Otherwise I can fix the ThreadPoolExecutor making it pausable/resumable so that it avoids the race condition. Were you able to reproduce the problem in your environment? > Random failures in StateProviderTest due to race condition > ---------------------------------------------------------- > > Key: ISPN-4085 > URL: https://issues.jboss.org/browse/ISPN-4085 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha1 > Environment: jgroups.bind_addr = 127.0.0.1 > java.runtime.version = 1.7.0_51-b13 > java.runtime.name =Java(TM) SE Runtime Environment > java.vm.version = 24.51-b03 > java.vm.vendor = Oracle Corporation > os.name = Mac OS X > os.version = 10.9.2 > sun.arch.data.model = 64 > sun.cpu.endian = little > protocol.stack = null > infinispan.test.jgroups.protocol = tcp > infinispan.unsafe.allow_jdk8_chm = true > java.net.preferIPv4Stack = true > java.net.preferIPv6Stack = null > log4.configuration = null > MAVEN_OPTS = null > Reporter: Gustavo Fernandes > Assignee: Dan Berindei > > In my environment the StateProviderTest .test2() fails sometimes (about 10% of the time) with the following error(s): > {code} > Tests run: 4233, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 428.06 sec <<< FAILURE! > test2(org.infinispan.statetransfer.StateProviderTest) Time elapsed: 0.042 sec <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at org.infinispan.statetransfer.StateProviderTest.test2(StateProviderTest.java:316) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > {code} > The reason why is that test2() feeds the StateProvider a ThreadPoolExecutorService to execute a OutboundTransfer task asynchronously and right after forcing a state transfer > asserts that there is a StateTransfer in progress. Sometimes the executor service manages to execute the task and as a result it clear the ‘transfersByDestination’ map, and thus the test cannot assert that the state transfer is happening > OTOH, the method test1() never fails because it users a mock executor service which never executes the task, so the state transfer map will always contain the outbound task after initiating the state transfer and thus always visible from outside > The quick fix is to also use a mock executor test for the test2() -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4021) Allow Map/Reduce task to use a custom intermediate cache

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-4021?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-4021: -------------------------------------- Summary: Allow Map/Reduce task to use a custom intermediate cache (was: Allow each Map/Reduce task to use a different cache configuration) > Allow Map/Reduce task to use a custom intermediate cache > -------------------------------------------------------- > > Key: ISPN-4021 > URL: https://issues.jboss.org/browse/ISPN-4021 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Distributed Execution and Map/Reduce > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Final > > > Some Map/Reduce tasks may need a cache store and eviction, some may not. Each task should be able to use its own cache configuration. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4091) Transactions and data should prefer to be sourced from a primary owner

by Erik Salter (JIRA)

[ https://issues.jboss.org/browse/ISPN-4091?page=com.atlassian.jira.plugin.... ] Erik Salter updated ISPN-4091: ------------------------------ Summary: Transactions and data should prefer to be sourced from a primary owner (was: Transactions and data should prefer to be sourced from a primay owner) > Transactions and data should prefer to be sourced from a primary owner > ---------------------------------------------------------------------- > > Key: ISPN-4091 > URL: https://issues.jboss.org/browse/ISPN-4091 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > > The current state transfer mechanism will ask the backup segments for transaction and state information. However, this breaks if there is a pessimistic transaction executing on the primary data owner, Consider the following use case: > A new owner joins and sources the ongoing transactions and data for key k from the backup. Meanwhile, a local transaction has started on the primary owner for k, but has not prepared on any remote nodes. So the new node does not know about the ongoing transaction. While that's going on, a new tx starts on the new owner. Since these are pessimistic, the new transaction will acquires the lock for the same key. > So we can have data inconsistency. > The state transfer mechanism should prefer to source the transaction and state information from the primary owner. This should cover all cases: if the originator is not the primary owner, then any (backup) locks must be replicated to all the owners, either directly during the tx or during a previous state transfer. -- 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

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014