April 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6410) Fix unstable ReplicationQueueTest.testReplicationQueueMultipleThreads

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6410?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6410. ------------------------------------- > Fix unstable ReplicationQueueTest.testReplicationQueueMultipleThreads > --------------------------------------------------------------------- > > Key: ISPN-6410 > URL: https://issues.jboss.org/browse/ISPN-6410 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > Labels: testsuite_stability > Fix For: 8.2.1.Final, 9.0.0.Alpha1 > > > http://ci.infinispan.org/viewLog.html?buildId=37670&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6361) ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached random failures

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6361?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6361. ------------------------------------- > ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached random failures > ----------------------------------------------------------------------------- > > Key: ISPN-6361 > URL: https://issues.jboss.org/browse/ISPN-6361 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.1.Final, 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6391) Cache managers failing to start do not stop global components

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6391?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6391. ------------------------------------- > Cache managers failing to start do not stop global components > ------------------------------------------------------------- > > Key: ISPN-6391 > URL: https://issues.jboss.org/browse/ISPN-6391 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > If one of the global components fails to start, {{GlobalComponentRegistry.start()}} removes the volatile components, but it doesn't call {{stop()}} on those components. > The most likely reason for a global component start failure is a timeout in {{JGroupsTransport.waitForInitialNodes()}}. After such a timeout, the transport isn't stopped, so the channel's sockets and threads are only freed after a few GC cycles (via finalization). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6447) Upgrade to XStream 1.4.9

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6447?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6447. ------------------------------------- > Upgrade to XStream 1.4.9 > ------------------------ > > Key: ISPN-6447 > URL: https://issues.jboss.org/browse/ISPN-6447 > Project: Infinispan > Issue Type: Component Upgrade > Components: Remote Protocols, Server > Affects Versions: 8.2.0.Final, 8.1.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > XStream < 1.4.9 is vulernable to XXE -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5495) ConcurrentStartTest.testConcurrentStart random failures

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-5495?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-5495. ------------------------------------- > ConcurrentStartTest.testConcurrentStart random failures > ------------------------------------------------------- > > Key: ISPN-5495 > URL: https://issues.jboss.org/browse/ISPN-5495 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > {noformat} > org.testng.internal.thread.ThreadTimeoutException: Method org.testng.internal.TestNGMethod.testConcurrentStart() didn't finish within the time-out 60000 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:253) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6429) Duplicated boolean projections are broken in compat mode

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6429?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6429. ------------------------------------- > Duplicated boolean projections are broken in compat mode > -------------------------------------------------------- > > Key: ISPN-6429 > URL: https://issues.jboss.org/browse/ISPN-6429 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 8.2.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > To reproduce: > 1. a compat mode, indexed cache. > 2. a dsl projection query that selects the same boolean column twice > 3. query works ok from embedded side, fails from remote side: the second occurrence of the boolean is actually returned as String. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6275) Double invalidate of invalid Hot Rod connections

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6275?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6275. ------------------------------------- > Double invalidate of invalid Hot Rod connections > ------------------------------------------------ > > Key: ISPN-6275 > URL: https://issues.jboss.org/browse/ISPN-6275 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Galder Zamarreño > Fix For: 8.2.1.Final, 9.0.0.Final > > > When there's a problem with a Hot Rod operation, RetryOnFailureOperation invalidates the connection twice (once in a catch block, and once in a finally block). > This causes the GenericKeyedObjectPool counts to get off, and anything relying on that count (such as the maxTotal configuration for the pool) to break. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6384) JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6384?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6384. ------------------------------------- > JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout > -------------------------------------------------------------------------- > > Key: ISPN-6384 > URL: https://issues.jboss.org/browse/ISPN-6384 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final, 9.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > {{JGroupsTransport.invokeRemotelyAsync()}} has a {{ResponseFilter}} parameter that was traditionally used only with {{ResponseMode.GET_FIRST}}, for remote get commands. In that particular case, returning a {{null}} when some of the nodes timed out and other nodes returned invalid responses (i.e. {{null}}) was acceptable. > Since ISPN-4979, {{JGroupsTransport.invokeRemotelyAsync()}} is also used by {{ClusterTopologyManagerImpl}}, with {{ResponseMode.GET_ALL}}. Here, however, returning a {{null}} instead of throwing a {{TimeoutException}} is not acceptable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6446) Byteman tests fail on IBM JDK

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6446?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6446. ------------------------------------- > Byteman tests fail on IBM JDK > ----------------------------- > > Key: ISPN-6446 > URL: https://issues.jboss.org/browse/ISPN-6446 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 8.2.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > The following tests are failing: > {noformat} > org.infinispan.hibernate.search.AsyncMetadataConfigurationTest > org.infinispan.query.distributed.MassIndexerAsyncBackendTest.testMassIndexOnAsync > {noformat} > Stack trace: > {noformat} > java.net.ConnectException: Connection refused > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:375) > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:236) > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:218) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:403) > at java.net.Socket.connect(Socket.java:658) > at java.net.Socket.connect(Socket.java:604) > at java.net.Socket.<init>(Socket.java:466) > at java.net.Socket.<init>(Socket.java:237) > at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:881) > at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:787) > at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:603) > at org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptText(BMUnit.java:485) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$8.evaluate(BMUnitRunner.java:344) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > ------- Stdout: ------- > byteman jar is /opt/buildAgent/system/jetbrains.maven.runner/maven.repo.local-bt32/org/jboss/byteman/byteman/2.1.4/byteman-2.1.4.jar > ------- Stderr: ------- > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:408) > at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:433) > at com.ibm.tools.attach.javaSE.Attachment.loadAgentLibraryImpl(Native Method) > at com.ibm.tools.attach.javaSE.Attachment.loadAgentLibrary(Attachment.java:252) > at com.ibm.tools.attach.javaSE.Attachment.parseLoadAgent(Attachment.java:230) > at com.ibm.tools.attach.javaSE.Attachment.doCommand(Attachment.java:140) > at com.ibm.tools.attach.javaSE.Attachment.run(Attachment.java:101) > Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment > at sun.instrument.InstrumentationImpl.addTransformer(InstrumentationImpl.java:100) > at org.jboss.byteman.agent.Main.premain(Main.java:237) > at org.jboss.byteman.agent.Main.agentmain(Main.java:260) > ... 11 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6322) Infinispan can miss incoming commands with JGroupsChannelLookup

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6322?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec closed ISPN-6322. ------------------------------------- > Infinispan can miss incoming commands with JGroupsChannelLookup > --------------------------------------------------------------- > > Key: ISPN-6322 > URL: https://issues.jboss.org/browse/ISPN-6322 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.CR1, 8.1.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final > > > Normally, the JGroupsTransport startup sequence goes like this: > # Create the {{Channel}} > # Create the {{CommandAwareRpcDispatcher}} and install it as an {{UpHandler}} > # Connect the channel > This way, every {{RequestCorrelator}} message received by the channel is passed up to {{CommandAwareRpcDispatcher}}, which executes the appropriate command. > When using a {{JGroupsChannelLookup}}, the lookup implementation is allowed to return a {{Channel}} instance that is already connected ({{shouldConnect() == false}}). That means there is now a window where the channel doesn't have an {{UpHandler}}, and messages sent to this node are discarded. > Normally a node only receives commands after it sent a join request to the coordinator. There are however a few exceptions: > # On startup, {{LocalTopologyManagerImpl}} sends the join request to the JGroups coordinator, which may not have the {{UpHandler}} yet. This seems to be responsible for the recent hanging in {{ConcurrentStartTest}}. We have a workaround here, to use a smaller timeout on the {{CacheTopologyControlCommand(JOIN)}} command, and retry it on {{TimeoutException}}. > # When a node becomes coordinator, {{ClusterTopologyManagerImpl}} broadcasts a {{GET_STATUS}} request to all cluster members, and expects a response from each of them. The same workaround with a smaller timeout and retries might work here. > # In replicated mode, write commands are broadcasted to all cluster members. There is some commented out code in {{RpcManagerImpl.invokeRemotelyAsync()}} that might fix it by only waiting for responses from the cache topology members. > We should consider deprecating {{JGroupsChannelLookup.shouldConnect()}} and requiring that the channel is only connected by {{JGroupsTransport}}. Assuming that works with {{ForkChannel}}, of course. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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