October 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2426) putForExternalRead() does not unlock if entry already exists

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-2426?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-2426: -------------------------------- Description: When performing a {{putForExternalRead()}} for an existing entry, the entry factory fails to provide the InvocationContext with the key for the entry. This makes it impossible for the locking interceptors to release the lock. (was: When performing a putIfAbsent for an existing entry with the flag PUT_FOR_EXTERNAL_READ set, the entry factory fails to provide the InvocationContext with the key for the entry. This makes it impossible for the locking interceptors to release the lock.) > putForExternalRead() does not unlock if entry already exists > ------------------------------------------------------------ > > Key: ISPN-2426 > URL: https://issues.jboss.org/browse/ISPN-2426 > Project: Infinispan > Issue Type: Patch > Affects Versions: 5.1.6.FINAL > Reporter: Jan Boehm > Assignee: Manik Surtani > Fix For: 5.2.0.CR1, 5.2.0.Final > > Attachments: ISPN-2426-Set-looked-up-key-in-InvocationContext-on-.patch > > > When performing a {{putForExternalRead()}} for an existing entry, the entry factory fails to provide the InvocationContext with the key for the entry. This makes it impossible for the locking interceptors to release the lock. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1951) Use MERGE3 in the default UDP configuration

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1951: ---------------------------------- Summary: Use MERGE3 in the default UDP configuration Key: ISPN-1951 URL: https://issues.jboss.org/browse/ISPN-1951 Project: Infinispan Issue Type: Task Components: Configuration Affects Versions: 5.1.3.CR1, 5.1.2.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.1.3.FINAL, 5.2.0.ALPHA1 Bela recommends using MERGE3 instead of MERGE2 in UDP clusters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

3
9
0 / 0

[JBoss JIRA] (ISPN-1896) ClusteredGetCommands should never fail with a SuspectException

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1896: ---------------------------------- Summary: ClusteredGetCommands should never fail with a SuspectException Key: ISPN-1896 URL: https://issues.jboss.org/browse/ISPN-1896 Project: Infinispan Issue Type: Bug Components: RPC Affects Versions: 5.1.2.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.1.2.FINAL I have seen this exception in the core test suite logs: {noformat} 2012-03-02 15:07:19,718 ERROR (testng-VersionedDistStateTransferTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Method testStateTransfer(org.infinispan.container.versioning.VersionedDistStateTransferTest) threw an exceptionorg.infinispan.CacheException: SuspectedException at org.infinispan.util.Util.rewrapAsCacheException(Util.java:524) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:168) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:478) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:148) at org.infinispan.distribution.DistributionManagerImpl.retrieveFromRemoteSource(DistributionManagerImpl.java:169) at org.infinispan.interceptors.DistributionInterceptor.realRemoteGet(DistributionInterceptor.java:212) at org.infinispan.interceptors.DistributionInterceptor.remoteGetAndStoreInL1(DistributionInterceptor.java:194) at org.infinispan.interceptors.DistributionInterceptor.remoteGetBeforeWrite(DistributionInterceptor.java:440) at org.infinispan.interceptors.DistributionInterceptor.handleWriteCommand(DistributionInterceptor.java:455) at org.infinispan.interceptors.DistributionInterceptor.visitPutKeyValueCommand(DistributionInterceptor.java:274) ... Caused by: SuspectedException at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:349) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:263) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:163) ... 60 more {noformat} The remote get command should return null instead of failing, even if it had a single target node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

3
8
0 / 0

[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2402: ---------------------------------- Summary: Cache operations or transactions should never fail with SuspectException Key: ISPN-2402 URL: https://issues.jboss.org/browse/ISPN-2402 Project: Infinispan Issue Type: Task Components: RPC, State transfer Affects Versions: 5.2.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.Final This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user. After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back). For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left. -- 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

11 years, 7 months

2
3
0 / 0

[JBoss JIRA] (ISPN-2376) KeyAffinityServiceImpl.getKeyForAddress() seems to loop forever when DefaultConsistentHash is created for the non-local node owner

by Scott Marlow (JIRA)

Scott Marlow created ISPN-2376: ---------------------------------- Summary: KeyAffinityServiceImpl.getKeyForAddress() seems to loop forever when DefaultConsistentHash is created for the non-local node owner Key: ISPN-2376 URL: https://issues.jboss.org/browse/ISPN-2376 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 5.2.0.Beta1 Reporter: Scott Marlow Assignee: Mircea Markus Fix For: 5.2.0.CR1 I instrumented KeyAffinityServiceImpl and DefaultConsistentHash to show why KeyAffinityServiceImpl is looping forever when running the AS7 clustered tests with some recent changes that aren't committed yet. We are hoping to get through this failure so we can get clustered tests running again more completely on our continuous test server (lightning). We have two nodes running in the AS cluster, node-0/web and node-1/web. In my recent test run, I stopped the test after it was stuck for a while. Below is some of the instrumented logging output. {quote} KeyAffinityServiceImpl interestedInAddress() check, for address: node-1/web, filter.contains(address) returns false, filter contents [node-0/web] . . . KeyAffinityServiceImpl.getKeyForAddress() loop # 1455775 will loop again since result is null, queue [], address node-0/web {quote} We are using address "node-1/web" because... TBC (will be back in a few) -- 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

11 years, 7 months

3
9
0 / 0

[JBoss JIRA] (ISPN-2154) Use JGroups' anycast when sending messages to multiple target

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2154: ---------------------------------- Summary: Use JGroups' anycast when sending messages to multiple target Key: ISPN-2154 URL: https://issues.jboss.org/browse/ISPN-2154 Project: Infinispan Issue Type: Task Components: RPC Affects Versions: 5.2.0.ALPHA1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.ALPHA2 We currently emulate anycasts in CommandAwareRpcDispatcher by sending the message to each target sequentially and then waiting for all the responses in parallel. This doesn't work very well with JGroups' RSVP protocol: if the RSVP flag is set, the send operation will block until we have received an ACK from the target, making the operation take much longer than it should. We only use RSVP for state transfer-related commands, so this is not critical. But it should be slightly more efficient for normal commands, as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

4
5
0 / 0

[JBoss JIRA] (ISPN-2420) Increment the topology id when a node leaves the cache

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2420: ---------------------------------- Summary: Increment the topology id when a node leaves the cache Key: ISPN-2420 URL: https://issues.jboss.org/browse/ISPN-2420 Project: Infinispan Issue Type: Feature Request Components: State transfer Affects Versions: 5.2.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.Final We currently increment the topology id only when we "rebalance" the consistent hash (i.e. we add new owners). This allows us to to do some optimizations after a leave, like not forwarding commands (because there are no new owners). Unfortunately, it is not very intuitive, because it doesn't match how JGroups works, so it can cause bugs like ISPN-2417. Additionally, it turns out there are many places where we care that a node left, so the code is more complex to handle this (e.g. TransactionTable.useStrictTopologyIdComparison()), or it is more slow for the common case when there is no leaver (e.g. LocalTransaction.getCommitNodes()). -- 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

11 years, 7 months

2
1
0 / 0

[JBoss JIRA] (ISPN-2324) Add user documentation for NSBT

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2324: ----------------------------------- Summary: Add user documentation for NSBT Key: ISPN-2324 URL: https://issues.jboss.org/browse/ISPN-2324 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.2.0.Alpha3 Reporter: Mircea Markus Assignee: Adrian Nistor Fix For: 5.2.0.Final To be linked from the user guide page:https://docs.jboss.org/author/display/ISPN/User+Guide -- 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

11 years, 7 months

1
1
0 / 0

[JBoss JIRA] (ISPN-2160) ReplWriteSkewTest.testSharedCounter failing randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2160: -------------------------------------- Summary: ReplWriteSkewTest.testSharedCounter failing randomly Key: ISPN-2160 URL: https://issues.jboss.org/browse/ISPN-2160 Project: Infinispan Issue Type: Bug Components: Test Suite Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 5.2.0.ALPHA2 Failing randomly with: {code}Failed tests: testSharedCounter(org.infinispan.container.versioning.ReplWriteSkewTest): Node-2 has put a duplicate value{code} TRACE logs coming right up -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

3
12
0 / 0

[JBoss JIRA] (ISPN-2264) DistL1WriteSkewTest.testSharedCounter failing randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2264: -------------------------------------- Summary: DistL1WriteSkewTest.testSharedCounter failing randomly Key: ISPN-2264 URL: https://issues.jboss.org/browse/ISPN-2264 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 5.2.0.Alpha4 {code}Failed tests: testSharedCounter(org.infinispan.container.versioning.DistL1WriteSkewTest): Timed out waiting for updater threads{code} -- 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

11 years, 7 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2012