May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3092) AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long

by Wouter De Borger (JIRA)

[ https://issues.jboss.org/browse/ISPN-3092?page=com.atlassian.jira.plugin.... ] Wouter De Borger updated ISPN-3092: ----------------------------------- Summary: AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long (was: AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is longer then 64 chars) > AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long > ----------------------------------------------------------------------------- > > Key: ISPN-3092 > URL: https://issues.jboss.org/browse/ISPN-3092 > Project: Infinispan > Issue Type: Bug > Reporter: Wouter De Borger > Assignee: Mircea Markus > > When hibernate search is used (with capedwarf for example), adding a fourth server to the cluster crashes infinispan. > I've narrowed the problem down to org.hibernate.search.backend.impl.jgroups.AutoNodeSelector:78 > Here the following formula is used to calculate an array index > int selectionRange = members.size() - 1; > int selected = ( indexName.hashCode() % selectionRange) + 1; > if indexname is long (like "default_taskworker-java__com.google.appengine.api.datastore.Entity") > the hashcode becomes negative due to integer overflow, resulting in a negative index -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3092) AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is longer then 64 chars

by Wouter De Borger (JIRA)

Wouter De Borger created ISPN-3092: -------------------------------------- Summary: AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is longer then 64 chars Key: ISPN-3092 URL: https://issues.jboss.org/browse/ISPN-3092 Project: Infinispan Issue Type: Bug Reporter: Wouter De Borger Assignee: Mircea Markus When hibernate search is used (with capedwarf for example), adding a fourth server to the cluster crashes infinispan. I've narrowed the problem down to org.hibernate.search.backend.impl.jgroups.AutoNodeSelector:78 Here the following formula is used to calculate an array index int selectionRange = members.size() - 1; int selected = ( indexName.hashCode() % selectionRange) + 1; if indexname is long (like "default_taskworker-java__com.google.appengine.api.datastore.Entity") the hashcode becomes negative due to integer overflow, resulting in a negative index -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2786) ThreadLocal memory leak in Tomcat

by Jim Crossley (JIRA)

[ https://issues.jboss.org/browse/ISPN-2786?page=com.atlassian.jira.plugin.... ] Jim Crossley commented on ISPN-2786: ------------------------------------ Good point, Johann. For the purpose of fixing IMMUTANT-280, it may be enough to make that marshaling logic more robust, but in light of the memory leaks, the benefit of having that logic in a ThreadLocal isn't clear to me, anyway. > ThreadLocal memory leak in Tomcat > --------------------------------- > > Key: ISPN-2786 > URL: https://issues.jboss.org/browse/ISPN-2786 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Transactions > Affects Versions: 5.1.8.Final > Reporter: Johann Burkard > Assignee: Galder Zamarreño > Labels: leak, local, memory, thread, threadlocal > Fix For: 5.3.0.Final > > > Just started an app using Infinispan 5.1.8.Final on Tomcat and got a few ThreadLocal problems during un-deployment: > (Shortened) > {code} > key=org.jboss.marshalling.UTFUtils.BytesHolder > value=org.jboss.marshalling.UTFUtils$BytesHolder@697a1686 > key=java.lang.ThreadLocal@36ed5ba6 > value=org.infinispan.context.SingleKeyNonTxInvocationContext{flags=null} > key=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1@75f10df7 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller.PerThreadInstanceHolder > {code} > I do call {{DefaultCacheManager#shutdown()}} during un-deployment. :) > Thanks -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2786) ThreadLocal memory leak in Tomcat

by Johann Burkard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2786?page=com.atlassian.jira.plugin.... ] Johann Burkard commented on ISPN-2786: -------------------------------------- Jim, ThreadLocal#remove needs to be called by each thread after it's done using the ThreadLocal. If you just call ThreadLocal#remove somewhere during shutdown of the application, there might still be references to old threads left. > ThreadLocal memory leak in Tomcat > --------------------------------- > > Key: ISPN-2786 > URL: https://issues.jboss.org/browse/ISPN-2786 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Transactions > Affects Versions: 5.1.8.Final > Reporter: Johann Burkard > Assignee: Galder Zamarreño > Labels: leak, local, memory, thread, threadlocal > Fix For: 5.3.0.Final > > > Just started an app using Infinispan 5.1.8.Final on Tomcat and got a few ThreadLocal problems during un-deployment: > (Shortened) > {code} > key=org.jboss.marshalling.UTFUtils.BytesHolder > value=org.jboss.marshalling.UTFUtils$BytesHolder@697a1686 > key=java.lang.ThreadLocal@36ed5ba6 > value=org.infinispan.context.SingleKeyNonTxInvocationContext{flags=null} > key=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1@75f10df7 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller.PerThreadInstanceHolder > {code} > I do call {{DefaultCacheManager#shutdown()}} during un-deployment. :) > Thanks -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2786) ThreadLocal memory leak in Tomcat

by Jim Crossley (JIRA)

[ https://issues.jboss.org/browse/ISPN-2786?page=com.atlassian.jira.plugin.... ] Jim Crossley commented on ISPN-2786: ------------------------------------ This is breaking Immutant as well, I think. Lingering ThreadLocal Marshaller's are re-used on a peer in which the collaborating application is no longer deployed. I don't think it would be a problem if ThreadLocal#remove is called when the cache is stopped. > ThreadLocal memory leak in Tomcat > --------------------------------- > > Key: ISPN-2786 > URL: https://issues.jboss.org/browse/ISPN-2786 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Transactions > Affects Versions: 5.1.8.Final > Reporter: Johann Burkard > Assignee: Galder Zamarreño > Labels: leak, local, memory, thread, threadlocal > Fix For: 5.3.0.Final > > > Just started an app using Infinispan 5.1.8.Final on Tomcat and got a few ThreadLocal problems during un-deployment: > (Shortened) > {code} > key=org.jboss.marshalling.UTFUtils.BytesHolder > value=org.jboss.marshalling.UTFUtils$BytesHolder@697a1686 > key=java.lang.ThreadLocal@36ed5ba6 > value=org.infinispan.context.SingleKeyNonTxInvocationContext{flags=null} > key=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller$1@75f10df7 > value=org.infinispan.marshall.jboss.AbstractJBossMarshaller.PerThreadInstanceHolder > {code} > I do call {{DefaultCacheManager#shutdown()}} during un-deployment. :) > Thanks -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2995) AtomicHashMap locking issue [optimistic]

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.... ] Work on ISPN-2995 started by Pedro Ruivo. > AtomicHashMap locking issue [optimistic] > ---------------------------------------- > > Key: ISPN-2995 > URL: https://issues.jboss.org/browse/ISPN-2995 > Project: Infinispan > Issue Type: Bug > Components: Fine-grained API > Affects Versions: 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: atomic_map, locking > Fix For: 5.3.0.Beta2 > > > In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node: > {code} > case ApplyDeltaCommand.COMMAND_ID: > ApplyDeltaCommand command = (ApplyDeltaCommand) wc; > if (cdl.localNodeIsOwner(command.getKey())) { > Object[] compositeKeys = command.getCompositeKeys(); > set.addAll(Arrays.asList(compositeKeys)); > } > break; > {code} > However, when we are going to acquire the lock in the node if it is the primary owner: > {code} > protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException { > if (cdl.localNodeIsPrimaryOwner(key)) { > lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking); > } else if (cdl.localNodeIsOwner(key)) { > ctx.getCacheTransaction().addBackupLockForKey(key); > } > } > {code} > The CompositeKey should always acquire the lock. > This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3055) Unreleased lock after node restart

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3055?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3055: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1816 > Unreleased lock after node restart > ---------------------------------- > > Key: ISPN-3055 > URL: https://issues.jboss.org/browse/ISPN-3055 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Environment: Debian Squeeze Amd 64, JDK 1.6.0_32 > Reporter: Deyan Pandulev > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1, 6.0.0.Final > > Attachments: SimpleClusterRead.java, SimpleClusterWriter.java, simple_cluster_node1.xml, simple_cluster_node2.xml > > > Using dummy transaction manager I was able to produce locks that are not released. The same behavior can be reproduced with Glassfish AS 3.1.1 using its own TM. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3055) Unreleased lock after node restart

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3055?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3055: ----------------------------------- I've take a look at it and the good new is it has nothing to do with the node restart :) If you start firs the Reader and then the Writer and abort a transaction, the bug will be revealed. the bug is quite simple. we are not sending the RollbackCommand if the lockingMode==PESSIMISTIC. Thanks Deyan! > Unreleased lock after node restart > ---------------------------------- > > Key: ISPN-3055 > URL: https://issues.jboss.org/browse/ISPN-3055 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Environment: Debian Squeeze Amd 64, JDK 1.6.0_32 > Reporter: Deyan Pandulev > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1, 6.0.0.Final > > Attachments: SimpleClusterRead.java, SimpleClusterWriter.java, simple_cluster_node1.xml, simple_cluster_node2.xml > > > Using dummy transaction manager I was able to produce locks that are not released. The same behavior can be reproduced with Glassfish AS 3.1.1 using its own TM. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3055) Unreleased lock after node restart

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3055?page=com.atlassian.jira.plugin.... ] Work on ISPN-3055 started by Pedro Ruivo. > Unreleased lock after node restart > ---------------------------------- > > Key: ISPN-3055 > URL: https://issues.jboss.org/browse/ISPN-3055 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Environment: Debian Squeeze Amd 64, JDK 1.6.0_32 > Reporter: Deyan Pandulev > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1, 6.0.0.Final > > Attachments: SimpleClusterRead.java, SimpleClusterWriter.java, simple_cluster_node1.xml, simple_cluster_node2.xml > > > Using dummy transaction manager I was able to produce locks that are not released. The same behavior can be reproduced with Glassfish AS 3.1.1 using its own TM. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1123) Stabilise test suite

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-1123?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-1123: ----------------------------------- org.infinispan.tx.recovery.RecoveryConfigTest re-enabled in https://github.com/infinispan/infinispan/pull/1815 > Stabilise test suite > -------------------- > > Key: ISPN-1123 > URL: https://issues.jboss.org/browse/ISPN-1123 > Project: Infinispan > Issue Type: Task > Components: Core API > Affects Versions: 5.0.0.CR2 > Reporter: Manik Surtani > Assignee: Dan Berindei > Priority: Blocker > Labels: ci, test > Fix For: 5.1.0.CR2 > > > The current test suite on http://hudson.infinispan.org is pretty unstable. Some tests have been disabled to allow it to run with 100% pass rate. Please investigate these disabled tests. -- 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, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013