[JBoss JIRA] (ISPN-2689) Support storage of indexes of Apache Lucene 4
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-2689:
-------------------------------------
Summary: Support storage of indexes of Apache Lucene 4
Key: ISPN-2689
URL: https://issues.jboss.org/browse/ISPN-2689
Project: Infinispan
Issue Type: Feature Request
Components: Lucene Directory
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 6.0.0.Beta1, 6.0.0.Final
The current Lucene Directory supports Lucene version from 2.9 to 3.6,
but Lucene 4 made consistent changes which might need a new module.
--
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, 12 months
[JBoss JIRA] (ISPN-2473) Forwarding for non-transactional write commands should be asynchronous
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2473?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2473:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated. Thanks!
> Forwarding for non-transactional write commands should be asynchronous
> ----------------------------------------------------------------------
>
> Key: ISPN-2473
> URL: https://issues.jboss.org/browse/ISPN-2473
> Project: Infinispan
> Issue Type: Sub-task
> Components: State transfer
> Affects Versions: 5.2.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.2.0.CR1
>
>
> A write command keeps a lock on the originator while doing the RPC on the actual owners, so forwarding the command back to the originator synchronously leads to a deadlock.
> Keeping track of the real originator for forwarded commands could allow us to avoid the deadlock, but it would be too complicated. OTOH, non-tx caches don't guarantee consistency, so we could just do the forwarding asynchronously.
--
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, 12 months
[JBoss JIRA] (ISPN-2688) StateTransferLargeObjectTest.testForFailure still failing randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2688?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2688:
-------------------------------
Attachment: stlot.log.gz
TRACE log
> StateTransferLargeObjectTest.testForFailure still failing randomly
> ------------------------------------------------------------------
>
> Key: ISPN-2688
> URL: https://issues.jboss.org/browse/ISPN-2688
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta6
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.2.0.Final
>
> Attachments: stlot.log.gz
>
>
> The failure appears because the state transfer has not finished, yet the distribution interceptor doesn't go remotely for the key:
> {noformat}
> 14:06:45,872 TRACE (asyncTransportThread-1,NodeA:___defaultcache) [StateTransferManagerImpl] Installing new cache topology CacheTopology{id=7, currentCH=DefaultConsistentHash{numSegments=60, numOwners=3, members=[NodeA-52814, NodeB-62397, NodeC-63995], owners={0: 0 1 2, 1: 0 1 2, 2: 0 1 2, 3: 0 1 2, 4: 0 1 2, 5: 0 1 2, 6: 0 1 2, 7: 0 1 2, 8: 0 1 2, 9: 0 1 2, 10: 0 1 2, 11: 0 1 2, 12: 0 2, 13: 0 2, 14: 0 2, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0, 26: 2 0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0 2, 31: 1 0 2, 32: 1 0 2, 33: 1 2, 34: 1 0, 35: 1 2, 36: 1 0, 37: 1 2, 38: 1 0, 39: 1 2, 40: 1 0, 41: 1 2, 42: 1 0, 43: 1 2, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0, 48: 1 0, 49: 1 2, 50: 2 1, 51: 2 1, 52: 2 1, 53: 2 1, 54: 2 1, 55: 2 1, 56: 2 1, 57: 2 1, 58: 2 0, 59: 2 0}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=3, members=[NodeA-52814, NodeB-62397, NodeC-63995], owners={0: 0 1 2, 1: 0 1 2, 2: 0 1 2, 3: 0 1 2, 4: 0 1 2, 5: 0 1 2, 6: 0 1 2, 7: 0 1 2, 8: 0 1 2, 9: 0 1 2, 10: 0 1 2, 11: 0 1 2, 12: 0 2 1, 13: 0 2 1, 14: 0 2 1, 15: 0 1 2, 16: 0 1 2, 17: 0 1 2, 18: 0 1 2, 19: 0 1 2, 20: 2 0 1, 21: 2 0 1, 22: 2 0 1, 23: 2 0 1, 24: 2 0 1, 25: 2 0 1, 26: 2 0 1, 27: 2 0 1, 28: 2 0 1, 29: 2 0 1, 30: 1 0 2, 31: 1 0 2, 32: 1 0 2, 33: 1 2 0, 34: 1 0 2, 35: 1 2 0, 36: 1 0 2, 37: 1 2 0, 38: 1 0 2, 39: 1 2 0, 40: 1 0 2, 41: 1 2 0, 42: 1 0 2, 43: 1 2 0, 44: 1 0 2, 45: 1 0 2, 46: 1 0 2, 47: 1 0 2, 48: 1 0 2, 49: 1 2 0, 50: 2 1 0, 51: 2 1 0, 52: 2 1 0, 53: 2 1 0, 54: 2 1 0, 55: 2 1 0, 56: 2 1 0, 57: 2 1 0, 58: 2 0 1, 59: 2 0 1}} on cache ___defaultcache
> 14:06:46,287 TRACE (OOB-9,ISPN,NodeA-52814:___defaultcache) [StateConsumerImpl] Received keys [0, 2, 10, 94, 103, 117, 187, 189, 288, 305, 307, 376, 481, 487, 502, 729, 771, 994] for segment 50 of cache ___defaultcache from node NodeB-62397
> 14:06:46,338 INFO (testng-StateTransferLargeObjectTest:) [StateTransferLargeObjectTest] ----Running a get on 10
> 14:06:46,351 TRACE (OOB-9,ISPN,NodeA-52814:___defaultcache ___defaultcache) [InvocationContextInterceptor] Invoked with command PutKeyValueCommand{key=10, value=org.infinispan.statetransfer.BigObject@6ed3126d, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1, successful=true} and InvocationContext [org.infinispan.context.impl.LocalTxInvocationContext@2c6dd013]
> 14:06:46,358 TRACE (testng-StateTransferLargeObjectTest:___defaultcache) [GetKeyValueCommand] Entry not found
> 14:06:46,358 TRACE (testng-StateTransferLargeObjectTest:___defaultcache) [BaseDistributionInterceptor] Not doing a remote get for key 10 since entry is mapped to current node (NodeA-52814), or is in L1. Owners are [NodeC-63995, NodeB-62397, NodeA-52814]
> 14:06:46,359 ERROR (testng-StateTransferLargeObjectTest:) [UnitTestTestNGListener] Test testForFailure(org.infinispan.statetransfer.StateTransferLargeObjectTest) failed.
> java.lang.AssertionError: expected object to not be null
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.assertNotNull(Assert.java:399)
> at org.testng.Assert.assertNotNull(Assert.java:384)
> at org.infinispan.statetransfer.StateTransferLargeObjectTest.assertValue(StateTransferLargeObjectTest.java:145)
> at org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure(StateTransferLargeObjectTest.java:115)
> {noformat}
--
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, 12 months
[JBoss JIRA] (ISPN-2688) StateTransferLargeObjectTest.testForFailure still failing randomly
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2688:
----------------------------------
Summary: StateTransferLargeObjectTest.testForFailure still failing randomly
Key: ISPN-2688
URL: https://issues.jboss.org/browse/ISPN-2688
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta6
Reporter: Dan Berindei
Assignee: Mircea Markus
Priority: Critical
Fix For: 5.2.0.Final
The failure appears because the state transfer has not finished, yet the distribution interceptor doesn't go remotely for the key:
{noformat}
14:06:45,872 TRACE (asyncTransportThread-1,NodeA:___defaultcache) [StateTransferManagerImpl] Installing new cache topology CacheTopology{id=7, currentCH=DefaultConsistentHash{numSegments=60, numOwners=3, members=[NodeA-52814, NodeB-62397, NodeC-63995], owners={0: 0 1 2, 1: 0 1 2, 2: 0 1 2, 3: 0 1 2, 4: 0 1 2, 5: 0 1 2, 6: 0 1 2, 7: 0 1 2, 8: 0 1 2, 9: 0 1 2, 10: 0 1 2, 11: 0 1 2, 12: 0 2, 13: 0 2, 14: 0 2, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0, 26: 2 0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0 2, 31: 1 0 2, 32: 1 0 2, 33: 1 2, 34: 1 0, 35: 1 2, 36: 1 0, 37: 1 2, 38: 1 0, 39: 1 2, 40: 1 0, 41: 1 2, 42: 1 0, 43: 1 2, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0, 48: 1 0, 49: 1 2, 50: 2 1, 51: 2 1, 52: 2 1, 53: 2 1, 54: 2 1, 55: 2 1, 56: 2 1, 57: 2 1, 58: 2 0, 59: 2 0}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=3, members=[NodeA-52814, NodeB-62397, NodeC-63995], owners={0: 0 1 2, 1: 0 1 2, 2: 0 1 2, 3: 0 1 2, 4: 0 1 2, 5: 0 1 2, 6: 0 1 2, 7: 0 1 2, 8: 0 1 2, 9: 0 1 2, 10: 0 1 2, 11: 0 1 2, 12: 0 2 1, 13: 0 2 1, 14: 0 2 1, 15: 0 1 2, 16: 0 1 2, 17: 0 1 2, 18: 0 1 2, 19: 0 1 2, 20: 2 0 1, 21: 2 0 1, 22: 2 0 1, 23: 2 0 1, 24: 2 0 1, 25: 2 0 1, 26: 2 0 1, 27: 2 0 1, 28: 2 0 1, 29: 2 0 1, 30: 1 0 2, 31: 1 0 2, 32: 1 0 2, 33: 1 2 0, 34: 1 0 2, 35: 1 2 0, 36: 1 0 2, 37: 1 2 0, 38: 1 0 2, 39: 1 2 0, 40: 1 0 2, 41: 1 2 0, 42: 1 0 2, 43: 1 2 0, 44: 1 0 2, 45: 1 0 2, 46: 1 0 2, 47: 1 0 2, 48: 1 0 2, 49: 1 2 0, 50: 2 1 0, 51: 2 1 0, 52: 2 1 0, 53: 2 1 0, 54: 2 1 0, 55: 2 1 0, 56: 2 1 0, 57: 2 1 0, 58: 2 0 1, 59: 2 0 1}} on cache ___defaultcache
14:06:46,287 TRACE (OOB-9,ISPN,NodeA-52814:___defaultcache) [StateConsumerImpl] Received keys [0, 2, 10, 94, 103, 117, 187, 189, 288, 305, 307, 376, 481, 487, 502, 729, 771, 994] for segment 50 of cache ___defaultcache from node NodeB-62397
14:06:46,338 INFO (testng-StateTransferLargeObjectTest:) [StateTransferLargeObjectTest] ----Running a get on 10
14:06:46,351 TRACE (OOB-9,ISPN,NodeA-52814:___defaultcache ___defaultcache) [InvocationContextInterceptor] Invoked with command PutKeyValueCommand{key=10, value=org.infinispan.statetransfer.BigObject@6ed3126d, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1, successful=true} and InvocationContext [org.infinispan.context.impl.LocalTxInvocationContext@2c6dd013]
14:06:46,358 TRACE (testng-StateTransferLargeObjectTest:___defaultcache) [GetKeyValueCommand] Entry not found
14:06:46,358 TRACE (testng-StateTransferLargeObjectTest:___defaultcache) [BaseDistributionInterceptor] Not doing a remote get for key 10 since entry is mapped to current node (NodeA-52814), or is in L1. Owners are [NodeC-63995, NodeB-62397, NodeA-52814]
14:06:46,359 ERROR (testng-StateTransferLargeObjectTest:) [UnitTestTestNGListener] Test testForFailure(org.infinispan.statetransfer.StateTransferLargeObjectTest) failed.
java.lang.AssertionError: expected object to not be null
at org.testng.Assert.fail(Assert.java:89)
at org.testng.Assert.assertNotNull(Assert.java:399)
at org.testng.Assert.assertNotNull(Assert.java:384)
at org.infinispan.statetransfer.StateTransferLargeObjectTest.assertValue(StateTransferLargeObjectTest.java:145)
at org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure(StateTransferLargeObjectTest.java:115)
{noformat}
--
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, 12 months
[JBoss JIRA] (ISPN-2687) DistributedExecutorWithTopologyAwareNodesTest.testRunnableExecution fails randomly
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2687:
----------------------------------
Summary: DistributedExecutorWithTopologyAwareNodesTest.testRunnableExecution fails randomly
Key: ISPN-2687
URL: https://issues.jboss.org/browse/ISPN-2687
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce, Test Suite
Affects Versions: 5.2.0.Beta6
Reporter: Dan Berindei
Assignee: Vladimir Blagojevic
Fix For: 6.0.0.Final
The test assumes that a task is executed in under 100ms, which is not necessarily true when running the parallel test suite:
{noformat}
java.lang.AssertionError
at org.infinispan.distexec.LocalDistributedExecutorTest.testRunnableExecution(LocalDistributedExecutorTest.java:139)
{noformat}
It should probably use {{AbstractInfinispanTest.eventually()}} instead of sleeping for a fixed amount of time.
--
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, 12 months
[JBoss JIRA] (ISPN-2459) Rollback not preceded by Prepare sent to remote site
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2459?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2459:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Rollback not preceded by Prepare sent to remote site
> ----------------------------------------------------
>
> Key: ISPN-2459
> URL: https://issues.jboss.org/browse/ISPN-2459
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Transactions
> Affects Versions: 5.2.0.Beta3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.2.0.CR1, 5.2.0.Final
>
>
> When a {{TransactionManager.rollback()}} is called under optimistic locking, the {{RollbackCommand}} is sent to the remote site with backup cache. This makes no sense as there are no changes to roll back, and furthermore, the command fails in the remote site as the transaction which is rolled back is not known:
> {code}
> 05:37:00,727 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-2,global,_edg-perf01-58034:LON) Problems invoking command SingleRpcCommand{cacheName='nycCache', command=RollbackCommand {gtx=GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local, cacheName='nycCache', topologyId=-1}}
> org.infinispan.CacheException: Couldn't find a local transaction corresponding to remote transaction GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local
> at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.completeTransaction(BackupReceiver.java:187)
> at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.visitRollbackCommand(BackupReceiver.java:178)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:61)
> at org.infinispan.xsite.BackupReceiver.handleRemoteCommand(BackupReceiver.java:76)
> at org.infinispan.xsite.BackupReceiverRepositoryImpl.handleRemoteCommand(BackupReceiverRepositoryImpl.java:60)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromRemoteSite(CommandAwareRpcDispatcher.java:240)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604)
> at org.jgroups.JChannel.up(JChannel.java:670)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.relay.RELAY2.deliver(RELAY2.java:420)
> at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:316)
> at org.jgroups.protocols.relay.RELAY2.handleMessage(RELAY2.java:292)
> at org.jgroups.protocols.relay.RELAY2.handleRelayMessage(RELAY2.java:272)
> at org.jgroups.protocols.relay.Relayer$Bridge.receive(Relayer.java:214)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:712)
> at org.jgroups.JChannel.up(JChannel.java:673)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:188)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:769)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:601)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1293)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1856)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1829)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {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, 12 months