August 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6650) org.infinispan.server.hotrod.HotRodSingleClusteredTest.clearContent fails on Windows

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6650?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-6650: ------------------------------------------- Confirmed, doesn't happen in the upstream. Closing. > org.infinispan.server.hotrod.HotRodSingleClusteredTest.clearContent fails on Windows > ------------------------------------------------------------------------------------ > > Key: ISPN-6650 > URL: https://issues.jboss.org/browse/ISPN-6650 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Reporter: Anna Manukyan > Assignee: Sebastian Łaskawiec > Fix For: 9.0.0.Beta1, 9.0.0.Final > > > The {{org.infinispan.server.hotrod.HotRodSingleClusteredTest.clearContent}} tests are failing on Windows with the following exception: > {code} > java.lang.IllegalStateException: No caches registered! Use registerCacheManager(Cache... caches) to do that! > at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:98) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:786) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6937) infinispan-core should not depend on Kubernetes

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6937?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6937: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4492 > infinispan-core should not depend on Kubernetes > ----------------------------------------------- > > Key: ISPN-6937 > URL: https://issues.jboss.org/browse/ISPN-6937 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6937) infinispan-core should not depend on Kubernetes

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6937?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6937: -------------------------------------- Status: Open (was: New) > infinispan-core should not depend on Kubernetes > ----------------------------------------------- > > Key: ISPN-6937 > URL: https://issues.jboss.org/browse/ISPN-6937 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6937) infinispan-core should not depend on Kubernetes

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6937?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-6937: ----------------------------------------- Assignee: Sebastian Łaskawiec > infinispan-core should not depend on Kubernetes > ----------------------------------------------- > > Key: ISPN-6937 > URL: https://issues.jboss.org/browse/ISPN-6937 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-6745?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-6745: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Setting to resolved, as referenced PRs were already merged. > Locks are lost in pessimistic cache > ----------------------------------- > > Key: ISPN-6745 > URL: https://issues.jboss.org/browse/ISPN-6745 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: JBoss DataGrid 6.5.0 (6.3.1.Final-redhat-1) > 3 nodes in REPL_SYNC mode > pessimistic locking > read committed isolation > Reporter: Eugene Scripnik > Assignee: Pedro Ruivo > Fix For: 9.0.0.Beta1, 8.2.4.Final > > Attachments: InfinispanNodeFailureTest.java > > > When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction before current transaction ends. > So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully. > I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them. > I am attaching Test which reproduces this problem -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6937) infinispan-core should not depend on Kubernetes

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-6937: --------------------------------------- Summary: infinispan-core should not depend on Kubernetes Key: ISPN-6937 URL: https://issues.jboss.org/browse/ISPN-6937 Project: Infinispan Issue Type: Bug Affects Versions: 9.0.0.Alpha4 Reporter: Gustavo Fernandes -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6935) Use Collection instead of Set

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6935?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-6935: ----------------------------------- There is a similar problem with Maps: at this point we require them to be serializable/externalizable. We could use {{MarshallUtil.marshallMap}} and marshall them more effectively, but that would cause potential problems as in a). We could change the internally held value to Collection<Map.Entry> but this would render the use awkward in some cases. > Use Collection instead of Set > ----------------------------- > > Key: ISPN-6935 > URL: https://issues.jboss.org/browse/ISPN-6935 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Beta1 > > > Currently the xManyCommand commands hold the keys in a set internally. During marshalling and splitting the set (when the command goes remote), we use {{HashSet}}. However, this has drawbacks: > a) if the set passed to command uses different means of equality than {{Object.hashCode()}} and {{Object.equals()}} we may lose some keys in the derived set - we don't inject dataContainer's keyEquivalence to the commands > b) as these sets are usually just iterated through (contains() is rare) it's less effective to use complex data structures as {{HashSet}} - plain {{ArrayList}} is sufficient. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6936) Propagate exceptions from functional invocation

by Radim Vansa (JIRA)

Radim Vansa created ISPN-6936: --------------------------------- Summary: Propagate exceptions from functional invocation Key: ISPN-6936 URL: https://issues.jboss.org/browse/ISPN-6936 Project: Infinispan Issue Type: Sub-task Reporter: Radim Vansa Assignee: Radim Vansa When a function passed to functional API throws an exception, this should be rethrown on caller side without being wrapped into {{RemoteException}}s, and it should not be logged by Infinispan on the way to caller. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6935) Use Collection instead of Set

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-6935?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated ISPN-6935: --------------------------------- Description: Currently the xManyCommand commands hold the keys in a set internally. During marshalling and splitting the set (when the command goes remote), we use {{HashSet}}. However, this has drawbacks: a) if the set passed to command uses different means of equality than {{Object.hashCode()}} and {{Object.equals()}} we may lose some keys in the derived set - we don't inject dataContainer's keyEquivalence to the commands b) as these sets are usually just iterated through (contains() is rare) it's less effective to use complex data structures as {{HashSet}} - plain {{ArrayList}} is sufficient. was: Currently the xManyCommand commands hold the keys in a set internally. During marshalling and splitting the set (when the command goes remote), we use {{HashSet}}. However, this has drawbacks: a) if the set passed to command uses different means of equality than {{Object.hashCode()}} and {{Object.equals()}] we may lose some keys in the derived set - we don't inject dataContainer's keyEquivalence to the commands b) as these sets are usually just iterated through (contains() is rare) it's less effective to use complex data structures as {{HashSet}} - plain {{ArrayList}} is sufficient. > Use Collection instead of Set > ----------------------------- > > Key: ISPN-6935 > URL: https://issues.jboss.org/browse/ISPN-6935 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Beta1 > > > Currently the xManyCommand commands hold the keys in a set internally. During marshalling and splitting the set (when the command goes remote), we use {{HashSet}}. However, this has drawbacks: > a) if the set passed to command uses different means of equality than {{Object.hashCode()}} and {{Object.equals()}} we may lose some keys in the derived set - we don't inject dataContainer's keyEquivalence to the commands > b) as these sets are usually just iterated through (contains() is rare) it's less effective to use complex data structures as {{HashSet}} - plain {{ArrayList}} is sufficient. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6935) Use Collection instead of Set

by Radim Vansa (JIRA)

Radim Vansa created ISPN-6935: --------------------------------- Summary: Use Collection instead of Set Key: ISPN-6935 URL: https://issues.jboss.org/browse/ISPN-6935 Project: Infinispan Issue Type: Sub-task Components: Core Affects Versions: 9.0.0.Alpha4 Reporter: Radim Vansa Assignee: Radim Vansa Currently the xManyCommand commands hold the keys in a set internally. During marshalling and splitting the set (when the command goes remote), we use {{HashSet}}. However, this has drawbacks: a) if the set passed to command uses different means of equality than {{Object.hashCode()}} and {{Object.equals()}] we may lose some keys in the derived set - we don't inject dataContainer's keyEquivalence to the commands b) as these sets are usually just iterated through (contains() is rare) it's less effective to use complex data structures as {{HashSet}} - plain {{ArrayList}} is sufficient. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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 August 2016