[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, 6 months
[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, 6 months
[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, 6 months
[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, 6 months
[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, 6 months
[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, 6 months
[JBoss JIRA] (ISPN-6353) REST service fails to start during remote query server integration tests
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6353?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6353.
-------------------------------------
> REST service fails to start during remote query server integration tests
> ------------------------------------------------------------------------
>
> Key: ISPN-6353
> URL: https://issues.jboss.org/browse/ISPN-6353
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 8.1.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> Errors are logged, REST service fails to start due to classloading problems of InfinispanIndexManager. This happens because the rest cache is not defined in the configuration so it gets created automatically based on the default config which happens to be an indexed cache, using InfinispanIndexManager, which is not normally available to the REST service. The tests do not fail.
> {code}
> 8:58:51,182 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.datagrid-infinispan-endpoint.rest.rest-connector: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan-endpoint.rest.rest-connector: DGENDPT10015: Could not create the web context for the REST Server
> at org.infinispan.server.endpoint.subsystem.RestService.start(RestService.java:103)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: org.hibernate.search.engine.service.classloading.spi.ClassLoadingException: Unable to load class [org.infinispan.query.indexmanager.InfinispanIndexManager]
> at org.hibernate.search.engine.service.classloading.impl.DefaultClassLoaderService.classForName(DefaultClassLoaderService.java:64)
> at org.hibernate.search.util.impl.ClassLoaderHelper.classForName(ClassLoaderHelper.java:320)
> at org.hibernate.search.engine.impl.DefaultIndexManagerFactory.createIndexManagerByName(DefaultIndexManagerFactory.java:54)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:247)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:513)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:482)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:91)
> at org.hibernate.search.spi.SearchIntegratorBuilder.initDocumentBuilders(SearchIntegratorBuilder.java:358)
> at org.hibernate.search.spi.SearchIntegratorBuilder.buildNewSearchFactory(SearchIntegratorBuilder.java:199)
> at org.hibernate.search.spi.SearchIntegratorBuilder.buildSearchIntegrator(SearchIntegratorBuilder.java:117)
> at org.infinispan.query.impl.LifecycleManager.getSearchFactory(LifecycleManager.java:300)
> at org.infinispan.query.impl.LifecycleManager.cacheStarting(LifecycleManager.java:112)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:247)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:236)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:849)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:635)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:585)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:451)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:470)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:461)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:85)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:26)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:14)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.rest.SecurityActions.doPrivileged(SecurityActions.java:24)
> at org.infinispan.rest.SecurityActions.getCache(SecurityActions.java:31)
> at org.infinispan.rest.NettyRestServer$$anonfun$startCaches$1.apply(NettyRestServer.scala:77)
> at org.infinispan.rest.NettyRestServer$$anonfun$startCaches$1.apply(NettyRestServer.scala:77)
> at scala.collection.Iterator$class.foreach(Iterator.scala:742)
> at scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
> at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
> at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
> at org.infinispan.rest.NettyRestServer$.startCaches(NettyRestServer.scala:77)
> at org.infinispan.rest.NettyRestServer$.apply(NettyRestServer.scala:52)
> at org.infinispan.rest.NettyRestServer$.apply(NettyRestServer.scala:46)
> at org.infinispan.rest.NettyRestServer.apply(NettyRestServer.scala)
> at org.infinispan.server.endpoint.subsystem.RestService.start(RestService.java:101)
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: Could not load requested class : org.infinispan.query.indexmanager.InfinispanIndexManager
> at org.hibernate.search.util.impl.AggregatedClassLoader.findClass(AggregatedClassLoader.java:75)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.hibernate.search.engine.service.classloading.impl.DefaultClassLoaderService.classForName(DefaultClassLoaderService.java:61)
> ... 42 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months