January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2736) ConcurrentModificationException in StateRequestCommand

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2736: --------------------------------- Summary: ConcurrentModificationException in StateRequestCommand Key: ISPN-2736 URL: https://issues.jboss.org/browse/ISPN-2736 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.CR2 Reporter: Radim Vansa Assignee: Mircea Markus Priority: Critical I have tried async replication scenario with async marshalling (optimistic transactions) and this has occurred: {code} 04:34:15,182 ERROR [org.infinispan.remoting.rpc.RpcManagerImpl] (OOB-77,edg-perf11-48420) ISPN000073: Unexpected error while replicating java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$KeyIterator.next(HashMap.java:828) at org.infinispan.statetransfer.StateProviderImpl.collectTransactionsToTransfer(StateProviderImpl.java:239) at org.infinispan.statetransfer.StateProviderImpl.getTransactionsForSegments(StateProviderImpl.java:200) at org.infinispan.statetransfer.StateRequestCommand.perform(StateRequestCommand.java:88) at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:101) at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:122) at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:86) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:245) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:218) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:484) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598) at org.jgroups.JChannel.up(JChannel.java:707) {code} Seems that StateRequestCommand is iterating through all transactions' locked keys but the collections of these locked keys can be modified by interfering prepare/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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2717) execute(Runnable) of DistributedExecutorService doesn't show exception message in case of failure of Runnable

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-2717?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-2717: -------------------------------- Affects Version/s: 5.2.0.CR2 > execute(Runnable) of DistributedExecutorService doesn't show exception message in case of failure of Runnable > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2717 > URL: https://issues.jboss.org/browse/ISPN-2717 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.CR2 > Reporter: Anna Manukyan > Assignee: Vladimir Blagojevic > > Assume, that we have a runnable which run() method throws RuntimeException. > In case if the runnable is executed using void execute(Runnable command) for DistributedExecutorService, the execution of runnable fails - but there is no any stacktrace printed in the logs. > So it is really hard to find, what was wrong in your Runnable. > The sample test which does this is: > {code} > public void testRunnableExecution() throws InterruptedException { > //assuming cache initialization is done > DistributedExecutorService des = new DefaultExecutorService(cache); > SampleRunnable runnable = new SampleRunnable(); > des.execute(runnable); > } > static class SampleRunnable implements Runnable, Serializable { > public SampleRunnable() { > } > @Override > public void run() { > System.out.println("Running runnable"); > int i = 5 / 0; > } > } > {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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2689) Support storage of indexes of Apache Lucene 4

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2689?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-2689: --------------------------------------- Hi James, I'll be back from travels tomorrow. Had a quick preview already, but the patch doesn't apply cleanly; I'll have a better look on the planes. It would be great if you could use "unified format" for patches. Lucene 4.1 will be released very soon, possibly today. Shall we target that instead? > 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 > > Attachments: ISPN-2689-hack-main.diff, ISPN-2689-hack-test.diff > > > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2717) execute(Runnable) of DistributedExecutorService doesn't show exception message in case of failure of Runnable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2717?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2717: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=902711 > execute(Runnable) of DistributedExecutorService doesn't show exception message in case of failure of Runnable > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2717 > URL: https://issues.jboss.org/browse/ISPN-2717 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Reporter: Anna Manukyan > Assignee: Vladimir Blagojevic > > Assume, that we have a runnable which run() method throws RuntimeException. > In case if the runnable is executed using void execute(Runnable command) for DistributedExecutorService, the execution of runnable fails - but there is no any stacktrace printed in the logs. > So it is really hard to find, what was wrong in your Runnable. > The sample test which does this is: > {code} > public void testRunnableExecution() throws InterruptedException { > //assuming cache initialization is done > DistributedExecutorService des = new DefaultExecutorService(cache); > SampleRunnable runnable = new SampleRunnable(); > des.execute(runnable); > } > static class SampleRunnable implements Runnable, Serializable { > public SampleRunnable() { > } > @Override > public void run() { > System.out.println("Running runnable"); > int i = 5 / 0; > } > } > {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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2580) Do not request segments from all nodes at once

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2580?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2580: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 881070|https://bugzilla.redhat.com/show_bug.cgi?id=881070] from ON_QA to VERIFIED > Do not request segments from all nodes at once > ---------------------------------------------- > > Key: ISPN-2580 > URL: https://issues.jboss.org/browse/ISPN-2580 > Project: Infinispan > Issue Type: Enhancement > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 5.2.0.CR1 > > > When a new node joins large cluster filled with data, it gets the new CH and REBALANCE_START command, and requests data from all nodes at once (or almost all with even distribution of segments). It may be not able to handle this amount of transfers in parallel even at the JGroups level - this results in data sent to the node and discarded at the receiver, sent again and again. With a heavy congestion the node just buffers fragments of a message from one sender and never passes this up. > The number of StateRequestCommands(START_STATE_TRANSFER) should be limited so that the node is not congested. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2647) ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2647?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2647: -------------------------------- Fix Version/s: 5.2.0.Final (was: 5.3.0.Final) Priority: Blocker (was: Major) Thanks! I'm marking it as blocker for 5.2.0.Final. > ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2647 > URL: https://issues.jboss.org/browse/ISPN-2647 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 5.2.0.Final > > > The local data container does not have the entry yet so the ReplaceCommand fails. See BaseDistStateTransferConsistencyTest.testReplace() and BaseReplStateTransferConsistencyTest.testReplace(). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2647) ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2647?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2647: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 902462|https://bugzilla.redhat.com/show_bug.cgi?id=902462] see https://issues.jboss.org/browse/ISPN-2647 > ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2647 > URL: https://issues.jboss.org/browse/ISPN-2647 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Final > > > The local data container does not have the entry yet so the ReplaceCommand fails. See BaseDistStateTransferConsistencyTest.testReplace() and BaseReplStateTransferConsistencyTest.testReplace(). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2647) ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2647?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2647: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=902462 > ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2647 > URL: https://issues.jboss.org/browse/ISPN-2647 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Final > > > The local data container does not have the entry yet so the ReplaceCommand fails. See BaseDistStateTransferConsistencyTest.testReplace() and BaseReplStateTransferConsistencyTest.testReplace(). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2647) ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2647?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-2647: -------------------------------------- Hi. I just discovered that this is a blocker for REST server testing. The problem is causing HTTP status 412 when putting data on existing entry in lots of operations in our performance tests. The failing point there is the call to replace https://github.com/infinispan/infinispan/blob/master/server/rest/src/main... that returns false and that causes HttpServletResponse.SC_PRECONDITION_FAILED (status 412) This is a testcase I've created for the REST server: https://github.com/mlinhard/infinispan/commit/42dc7788715f5bad000940f4eb2... It seems to me that the root cause of this is the bug you're describing here, so I'm not creating a new bug ... > ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2647 > URL: https://issues.jboss.org/browse/ISPN-2647 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Final > > > The local data container does not have the entry yet so the ReplaceCommand fails. See BaseDistStateTransferConsistencyTest.testReplace() and BaseReplStateTransferConsistencyTest.testReplace(). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1574) Async replication timeout should not be validated

by Hüdaverdi Cakir (JIRA)

[ https://issues.jboss.org/browse/ISPN-1574?page=com.atlassian.jira.plugin.... ] Hüdaverdi Cakir edited comment on ISPN-1574 at 1/21/13 12:08 PM: ----------------------------------------------------------------- This issue still seems to exist. We have following config: <clustering mode="distribution"> <hash numOwners="2" /> <async/> </clustering> During setup we see following warning message: ISPN000148: Invalid <locking>:lockAcquisitionTimeout value of 20000. It can not be higher than <sync>:replTimeout which is 15000 We are using Infinispan 5.1.8.Final Same issue here: https://community.jboss.org/thread/175493 was (Author: hcakir): This issue still seems to exist. We have following config: <clustering mode="distribution"> <hash numOwners="2" /> <async/> </clustering> During setup we see following warning message: ISPN000148: Invalid <locking>:lockAcquisitionTimeout value of 20000. It can not be higher than <sync>:replTimeout which is 15000 We are using Infinispan 5.1.8.Final > Async replication timeout should not be validated > ------------------------------------------------- > > Key: ISPN-1574 > URL: https://issues.jboss.org/browse/ISPN-1574 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.1.0.BETA5 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.1.0.CR1 > > > The timeout validator shouldn't validate lock timeout and repl timeout when cache is configured with async replication. -- 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, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013