October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4693) Locks acquired before a partition will never be released

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4693: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1155692|https://bugzilla.redhat.com/show_bug.cgi?id=1155692] from MODIFIED to POST > Locks acquired before a partition will never be released > -------------------------------------------------------- > > Key: ISPN-4693 > URL: https://issues.jboss.org/browse/ISPN-4693 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.CR2, 7.0.0.Final > > > Consider the following case: > 1. A prepares a transaction for key K on nodes B and C. > 2. The primary owner B acquires and registers this lock. > 3. The cluster partitions and A,C remain in partition one, and B in a separate partition. > 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B. > 5. B rejoins the cluster. It still has a lock acquired for key K. > This can lead to a lock being acquired indefinitely. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4856) PartitionHandling: majority check in PreferConsistencyStrategy is incorrect

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4856?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4856: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1155602|https://bugzilla.redhat.com/show_bug.cgi?id=1155602] from MODIFIED to POST > PartitionHandling: majority check in PreferConsistencyStrategy is incorrect > --------------------------------------------------------------------------- > > Key: ISPN-4856 > URL: https://issues.jboss.org/browse/ISPN-4856 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > If the cluster has 3 members and one of them crashes, the remaining 2 should stay available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4852) PartitionHandling: support replicated caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4852?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4852: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1155606|https://bugzilla.redhat.com/show_bug.cgi?id=1155606] from MODIFIED to POST > PartitionHandling: support replicated caches > -------------------------------------------- > > Key: ISPN-4852 > URL: https://issues.jboss.org/browse/ISPN-4852 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > ISPN-4574 already did most of the job, but the PartitionHandlingManager component wasn't created for replicated caches. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4826) X-Site State transfer values not propagated correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4826?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4826: ----------------------------------------------- Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1151523|https://bugzilla.redhat.com/show_bug.cgi?id=1151523] from ON_QA to VERIFIED > X-Site State transfer values not propagated correctly > ------------------------------------------------------ > > Key: ISPN-4826 > URL: https://issues.jboss.org/browse/ISPN-4826 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 7.0.0.CR1 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Fix For: 7.0.0.CR2 > > > Used configuration: > a) SITE1: 2 nodes, cache testCacheSite1 > <backups> > <backup site="SITE2"/> > </backups> > b) SITE2: 3 nodes, cache testCacheSite1_backup – backup cache for testCacheSite1 > <backup-for remote-cache="testCacheSite1" remote-site="SITE1"/> > When using backup cache with name (testCacheSite1_backup) different from the name of the main cache in SITE1 (testCacheSite1), the data is not propagated to the backup cache completely. The issue seems to be fixed by using the same name for the backup cache (testCacheSite1). > Scenario > 1. Start site1 and write data into it (1000 entries) > 2. Start site2 and invoke XsiteAdminOperations.pushState(“SITE2”) > 3. Wait 2 minutes > 4. Check whether the state was transferred to site2 (tested on dist & repl backup cache configs) > a) distributed mode (numOwners=2) - expected 2000 entries in total, was 648 on site2 master & 0 on other nodes > b) replicated mode – expected 3000 entries in total, was 1000 on site2 master & 0 on other nodes > > Trace log: > 04:14:39,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-10,edg-perf13-23152) Silently ignoring that testCacheSite1 cache is not defined > 04:14:39,375 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-10,edg-perf13-23152) Attempting to execute command: SingleRpcCommand{cacheName='testCacheSite1_backup', command=PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}} [sender=edg-perf14-31850] > 04:14:39,376 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (OOB-10,edg-perf13-23152) Checking if transaction data was received for topology 4, current topology is 4 > 04:14:39,376 TRACE [org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl] (OOB-10,edg-perf13-23152) Added a new task: 0 task(s) are waiting > 04:14:39,376 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread--p3-t2) Calling perform() on SingleRpcCommand{cacheName='testCacheSite1_backup', command=PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}} > 04:14:39,378 TRACE [org.infinispan.commands.remote.BaseRpcInvokingCommand] (remote-thread--p3-t2) Invoking command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}, with originLocal flag set to false > 04:14:39,378 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p3-t2) Invoked with command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@266883cb] > 04:14:39,379 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] (remote-thread--p3-t2) handleNonTxWriteCommand for command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true} > 04:14:39,380 TRACE [org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor] (remote-thread--p3-t2) Are (edg-perf13-23152) we the lock owners for key 'key_0000000000000001'? false > 04:14:39,380 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) Wrapping entry 'key_0000000000000001'? true > 04:14:39,380 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Exists in context? null > 04:14:39,382 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Retrieved from container null (isL1Enabled=false, isLocal=true) > 04:14:39,382 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Creating new entry. > 04:14:39,388 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Wrap key_0000000000000001 for put. Entry=ReadCommittedEntry(197b92bc){key=key_0000000000000001, value=null, oldValue=null, isCreated=true, isChanged=false, isRemoved=false, isValid=true, skipRemoteGet=false, metadata=EmbeddedMetadata{version=null}} > 04:14:39,390 TRACE [org.infinispan.interceptors.CallInterceptor] (remote-thread--p3-t2) Executing command: PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}. > 04:14:39,391 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) About to commit entry ReadCommittedEntry(197b92bc){key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, oldValue=null, isCreated=true, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=false, metadata=EmbeddedMetadata{version=null}} > 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Trying to commit. Key=key_0000000000000001. Operation Flag=PUT_FOR_X_SITE_STATE_TRANSFER, L1 invalidation=false > 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Not committing key=key_0000000000000001. It is a state transfer key but no track is enabled! > 04:14:39,392 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) The return value is null > Suspicious lines: > 04:14:39,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-10,edg-perf13-23152) Silently ignoring that testCacheSite1 cache is not defined > 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Not committing key=key_0000000000000001. It is a state transfer key but no track is enabled! -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3830: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1155688|https://bugzilla.redhat.com/show_bug.cgi?id=1155688] from MODIFIED to POST > Conditional Operation can fail erroneously during ST > ---------------------------------------------------- > > Key: ISPN-3830 > URL: https://issues.jboss.org/browse/ISPN-3830 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Reporter: William Burns > Assignee: Dan Berindei > Fix For: 7.0.0.CR2 > > > Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful. > This however can have the following issue. > k1 owned by N1, N2 > # N3 updates k1 sending conditional command to N1 > # N1 receives command and starts running it (passes topology block) > # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container. > # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException > # N3 gets response that command failed, but it could have worked had it gone to a real owner. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4874) Cross-site replication - allow defining custom backup cache name

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4874?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4874: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1156088 > Cross-site replication - allow defining custom backup cache name > ---------------------------------------------------------------- > > Key: ISPN-4874 > URL: https://issues.jboss.org/browse/ISPN-4874 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Server > Affects Versions: 7.0.0.CR2 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > > Using client-server mode, it's currently not possible to specify custom name for backup cache (different from the name of the main cache), as "backup-for" setting is missing. The issue can be workarounded by using the same name for the main & backup cache. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4874) Cross-site replication - allow defining custom backup cache name

by Matej Čimbora (JIRA)

Matej Čimbora created ISPN-4874: ----------------------------------- Summary: Cross-site replication - allow defining custom backup cache name Key: ISPN-4874 URL: https://issues.jboss.org/browse/ISPN-4874 Project: Infinispan Issue Type: Bug Components: Cross-Site Replication, Server Affects Versions: 7.0.0.CR2 Reporter: Matej Čimbora Assignee: Pedro Ruivo Using client-server mode, it's currently not possible to specify custom name for backup cache (different from the name of the main cache), as "backup-for" setting is missing. The issue can be workarounded by using the same name for the main & backup cache. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4854) Schema persistence does not allow 'any' for cache stores

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4854?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4854: ------------------------------ Status: Open (was: New) > Schema persistence does not allow 'any' for cache stores > -------------------------------------------------------- > > Key: ISPN-4854 > URL: https://issues.jboss.org/browse/ISPN-4854 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.CR1 > Reporter: Radim Vansa > > In 7.0 schema, the persistence element does not allow declaration of store via other schema. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4854) Schema persistence does not allow 'any' for cache stores

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4854?page=com.atlassian.jira.plugin.... ] Radim Vansa reassigned ISPN-4854: --------------------------------- Assignee: Radim Vansa > Schema persistence does not allow 'any' for cache stores > -------------------------------------------------------- > > Key: ISPN-4854 > URL: https://issues.jboss.org/browse/ISPN-4854 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.CR1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > In 7.0 schema, the persistence element does not allow declaration of store via other schema. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4854) Schema persistence does not allow 'any' for cache stores

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4854?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4854: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2983 > Schema persistence does not allow 'any' for cache stores > -------------------------------------------------------- > > Key: ISPN-4854 > URL: https://issues.jboss.org/browse/ISPN-4854 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.CR1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > In 7.0 schema, the persistence element does not allow declaration of store via other schema. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 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 October 2014