March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7061) Allow using HOST header for routing in to REST interface

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7061?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7061: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > Allow using HOST header for routing in to REST interface > -------------------------------------------------------- > > Key: ISPN-7061 > URL: https://issues.jboss.org/browse/ISPN-7061 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Sebastian Łaskawiec > Fix For: 9.1.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7026) CacheClusterJoinTest.testIsCoordinator random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7026?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7026: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > CacheClusterJoinTest.testIsCoordinator random failures > ------------------------------------------------------ > > Key: ISPN-7026 > URL: https://issues.jboss.org/browse/ISPN-7026 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.0.Final > > > {{CacheClusterJoinTest.testIsCoordinator}} assumes that once {{JGroupsTransport}} received a view, {{JGroupsTransport.isCoordinator()}} returns the correct value. > However, only {{JGroupsTransfer.viewAccepted}} is synchronized, {{isCoordinator()}} is not, so the main thread can see {{isCoordinator() == false}} even after {{getMembers().get(0) == self}}. > {noformat} > 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] New view accepted: [Test-NodeD-36891|2] (1) [Test-NodeD-36891] > 19:32:27,556 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.api.CacheClusterJoinTest.testIsCoordinator > java.lang.AssertionError > at org.infinispan.api.CacheClusterJoinTest.testIsCoordinator(CacheClusterJoinTest.java:65) ~[test-classes/:?] > 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] Joined: [], Left: [Test-NodeC-35712] > {noformat} > It would be nice if {{isCoordinator()}}, {{getCoordinator()}}, and {{getMembers()}} were more in sync, even though the view can always change between two calls. The simplest way to do this would be to implement {{isCoordinator()}} and {{getCoordinator()}} on top of {{getMembers()}} and remove their fields, since they're not use in performance-sensitive code. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6971) Use JChannel directly instead of going through MessageDispatcher

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6971?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6971: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > Use JChannel directly instead of going through MessageDispatcher > ---------------------------------------------------------------- > > Key: ISPN-6971 > URL: https://issues.jboss.org/browse/ISPN-6971 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.1.0.Final > > > JGroups changed its serialization in 4.0, and even when using MessageDispatcher we still have to provide a JGroups-style marshaller for deserializing RPC responses. If we used JChannel directly, we could avoid this, and we'd have more control over how we process responses. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6997) PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6997?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6997: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures > ----------------------------------------------------------------------------------------------- > > Key: ISPN-6997 > URL: https://issues.jboss.org/browse/ISPN-6997 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.0.Final > > > The test starts with a cluster of 4 nodes, and splits it in 2 partitions while a transaction is trying to lock a key. After the transaction fails, it checks that the transaction has been cleaned up properly. > On one of the owners, {{transactionTable.cleanupLeaverTransactions}} is being called only before the split and after the merge, never with the list of members during the split. That means it never sees the transaction as an orphan, and doesn't remove it. > {noformat} > 15:16:18,893 TRACE (testng-PTPAMDRT:[]) [PTPAMDRT] Local tx=[], remote tx=[GlobalTx:PTPAMDRT-NodeI-3337:28616], for cache PTPAMDRT-NodeJ-27814 > 15:16:18,893 ERROR (testng-PTPAMDRT:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PTPAMDRT.testOriginatorIsolatedPartition > java.lang.AssertionError: There are pending transactions! > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:223) ~[test-classes/:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:519) ~[test-classes/:?] > at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:794) ~[test-classes/:?] > at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:96) ~[test-classes/:?] > at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:82) ~[test-classes/:?] > at org.infinispan.partitionhandling.tionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition(PessimisticTxPartitionAndMergeDuringRuntimeTest.java:33) ~[test-classes/:?] > {noformat} > {{OptimisticTxPartitionAndMergeDuringCommitTest.testPrimaryOwnerIsolatedPartition}} has similar random failures. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7672) NonTotalOrderTxPerCacheInboundInvocationHandler throws warning when adding cache entry using Spring Session

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7672?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7672: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > NonTotalOrderTxPerCacheInboundInvocationHandler throws warning when adding cache entry using Spring Session > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-7672 > URL: https://issues.jboss.org/browse/ISPN-7672 > Project: Infinispan > Issue Type: Bug > Components: Cloud Integrations, Spring Integration > Affects Versions: 9.0.0.CR4 > Reporter: Sebastian Łaskawiec > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 9.1.0.Final > > > When I'm trying to add an entry using Spring Session integration with a [transactional cache|https://github.com/slaskawi/presentations/blob/master/2017_spring_s...], the server throws a warning: > {code} > [transactions-repository-1-2cbrv] 06:53:40,773 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (remote-thread--p2-t18) ISPN000071: Caught exception when handling command DistributedExecuteCommand [cache=Cache 'sessions'@transactions-repository-1-2cbrv, keys=[], callable=ClusterEventCallable{identifier=b345211e-fbd7-4305-b3a6-6979301e0360, events=[ClusterEvent {type=CACHE_ENTRY_CREATED, cache=Cache 'sessions'@transactions-repository-1-2cbrv, key=[B@8c75820, value=[B@76856353, oldValue=null, transaction=RecoveryAwareGlobalTransaction{xid=< 131077, 29, 36, 0000000000-1-1-84170374-96-629488-44-62370001349, 0000000000-1-1-84170374-96-629488-44-62370001400000000 >, internalId=562954248388609} GlobalTx:transactions-repository-1-cwk6f:1, retryCommand=false, origin=transactions-repository-1-cwk6f}]}]: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.ClassCastException] while invoking method [public void org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(org.infinispan.notifications.cachelistener.event.CacheEntryEvent)] on listener instance: org.infinispan.server.hotrod.ClientListenerRegistry$StatelessClientEventSender@7b97a57 > [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:401) > [transactions-repository-1-2cbrv] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:20) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:419) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1512) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1508) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1503) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyClusterListeners(CacheNotifierImpl.java:711) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.cluster.ClusterEventCallable.call(ClusterEventCallable.java:49) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.cluster.ClusterEventCallable.call(ClusterEventCallable.java:25) > [transactions-repository-1-2cbrv] at org.infinispan.commands.read.DistributedExecuteCommand.invokeAsync(DistributedExecuteCommand.java:99) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:90) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:90) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:68) > [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) > [transactions-repository-1-2cbrv] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [transactions-repository-1-2cbrv] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [transactions-repository-1-2cbrv] at java.lang.Thread.run(Thread.java:745) > [transactions-repository-1-2cbrv] Caused by: java.lang.ClassCastException: org.infinispan.container.versioning.SimpleClusteredVersion cannot be cast to org.infinispan.container.versioning.NumericVersion > [transactions-repository-1-2cbrv] at org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(ClientListenerRegistry.java:363) > [transactions-repository-1-2cbrv] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [transactions-repository-1-2cbrv] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [transactions-repository-1-2cbrv] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [transactions-repository-1-2cbrv] at java.lang.reflect.Method.invoke(Method.java:498) > [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:396) > [transactions-repository-1-2cbrv] ... 16 more > [transactions-repository-1-2cbrv] > {code} > This didn't happen in {{CR2}} release, so there must be something that changed since then. I also noticed that this sometimes leads to exceptions in the Hot Rod client. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7634) SerializationConfiguration.advancedExternalizers() map should not be mutable

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7634?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7634: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > SerializationConfiguration.advancedExternalizers() map should not be mutable > ---------------------------------------------------------------------------- > > Key: ISPN-7634 > URL: https://issues.jboss.org/browse/ISPN-7634 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.1.0.Final > > > Currently {{SerializationConfiguration.advancedExternalizers()}} returns a mutable {{HashMap}}. We only read it once on startup, so modifying it won't break anything, but it should be immutable to make it clear that externalizers cannot be added at runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7670) Upgrade to Hibernate Search 5.7.1.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7670?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7670: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > Upgrade to Hibernate Search 5.7.1.Final > --------------------------------------- > > Key: ISPN-7670 > URL: https://issues.jboss.org/browse/ISPN-7670 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 9.1.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7606) DistributedExecutorMassIndexer.executeInternal should use an existing pool

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7606?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7606: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > DistributedExecutorMassIndexer.executeInternal should use an existing pool > -------------------------------------------------------------------------- > > Key: ISPN-7606 > URL: https://issues.jboss.org/browse/ISPN-7606 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Fix For: 9.1.0.Final > > > {{DistributedExecutorMassIndexer.executeInternal}} creates 2 executors: > 1. {{new DefaultExecutorService(cache)}} implicitly creates a single-threaded executor to run tasks on the local node. > 2. {{compositeFuture.whenCompleteAsync(consumer, Executors.newSingleThreadExecutor())}} explicitly creates a new single-threaded executor to run the consumer on. > Neither of these executors are shut down, and rather than complicating the code to stop them properly it would be better to use an existing executor. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7598) Core test suite leaks threads

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7598?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7598: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > Core test suite leaks threads > ----------------------------- > > Key: ISPN-7598 > URL: https://issues.jboss.org/browse/ISPN-7598 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.1.0.Final > > > Each {{LocalDistributedExecutorTest}} test method creates a new {{DefaultExecutorService}} instance, and each instance uses a new local executor created with {{Executors.newCachedThreadPool(...)}}. But the {{DefaultExecutorService}} is created with {{takeExecutorOwnership = false}}, and so the local executor is not stopped on shutdown. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7553) Replicated cache with numOwners=1 doesn't send writes to backups

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7553?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7553: ---------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.0.Final) > Replicated cache with numOwners=1 doesn't send writes to backups > ---------------------------------------------------------------- > > Key: ISPN-7553 > URL: https://issues.jboss.org/browse/ISPN-7553 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 9.1.0.Final > > > {{BaseDistributionInterceptor.primaryReturnHandler()}} doesn't replicate writes to the backups if {{cacheConfiguration.clustering().hash().numOwners() == 1}}. That check is incorrect, because a segment can have more owners than configured: > 1. In a replicated cache, the configured {{numOwners}} is ignored, and all the members are owners. > 1. Even in a distributed cache, during rebalance, the segments being moved will have more than {{numOwners}} owners. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017