[JBoss JIRA] (ISPN-9097) java.lang.ClassNotFoundException: org.infinispan.query.Search
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9097?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9097:
------------------------------------
Fix Version/s: 9.2.2.Final
9.3.0.Beta1
> java.lang.ClassNotFoundException: org.infinispan.query.Search
> -------------------------------------------------------------
>
> Key: ISPN-9097
> URL: https://issues.jboss.org/browse/ISPN-9097
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Remote Querying
> Affects Versions: 9.2.1.Final, 9.3.0.Alpha1
> Reporter: Sergey Chernolyas
> Assignee: Sergey Chernolyas
> Fix For: 9.2.2.Final, 9.3.0.Beta1
>
>
> Then I call
> {code:java}
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(builder.build(true));
> remoteCacheManager.administration().reindexCache("pojocache");
> {code}
> I take exception:
> _______________
> Apr 22, 2018 10:55:01 AM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus
> WARN: ISPN004005: Error received from the server: java.lang.NoClassDefFoundError: org/infinispan/query/Search
> java.lang.ClassNotFoundException: org.infinispan.query.Search from [Module "org.infinispan.server" from local module loader @1ae369b7 (finder: local module finder @6fffcba5 (roots: /home/osboxes/java/infinispan-server-9.2.1.Final/modules,/home/osboxes/java/infinispan-server-9.2.1.Final/modules/system/layers/base))]
> Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=8 returned server error (status=0x85): java.lang.NoClassDefFoundError: org/infinispan/query/Search
> java.lang.ClassNotFoundException: org.infinispan.query.Search from [Module "org.infinispan.server" from local module loader @1ae369b7 (finder: local module finder @6fffcba5 (roots: /home/osboxes/java/infinispan-server-9.2.1.Final/modules,/home/osboxes/java/infinispan-server-9.2.1.Final/modules/system/layers/base))]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:383)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:177)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:163)
> at org.infinispan.client.hotrod.impl.transport.netty.HeaderDecoder.decode(HeaderDecoder.java:85)
> at org.infinispan.client.hotrod.impl.transport.netty.HintedReplayingDecoder.callDecode(HintedReplayingDecoder.java:98)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1414)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:945)
> at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:806)
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:404)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Process finished with exit code 1
> _____
> I used remote Infinispan.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9097) java.lang.ClassNotFoundException: org.infinispan.query.Search
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9097?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9097:
------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5938, https://github.com/infinispan/infinispan/pull/5944 (was: https://github.com/infinispan/infinispan/pull/5938)
> java.lang.ClassNotFoundException: org.infinispan.query.Search
> -------------------------------------------------------------
>
> Key: ISPN-9097
> URL: https://issues.jboss.org/browse/ISPN-9097
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Remote Querying
> Affects Versions: 9.2.1.Final, 9.3.0.Alpha1
> Reporter: Sergey Chernolyas
> Assignee: Sergey Chernolyas
>
> Then I call
> {code:java}
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(builder.build(true));
> remoteCacheManager.administration().reindexCache("pojocache");
> {code}
> I take exception:
> _______________
> Apr 22, 2018 10:55:01 AM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus
> WARN: ISPN004005: Error received from the server: java.lang.NoClassDefFoundError: org/infinispan/query/Search
> java.lang.ClassNotFoundException: org.infinispan.query.Search from [Module "org.infinispan.server" from local module loader @1ae369b7 (finder: local module finder @6fffcba5 (roots: /home/osboxes/java/infinispan-server-9.2.1.Final/modules,/home/osboxes/java/infinispan-server-9.2.1.Final/modules/system/layers/base))]
> Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=8 returned server error (status=0x85): java.lang.NoClassDefFoundError: org/infinispan/query/Search
> java.lang.ClassNotFoundException: org.infinispan.query.Search from [Module "org.infinispan.server" from local module loader @1ae369b7 (finder: local module finder @6fffcba5 (roots: /home/osboxes/java/infinispan-server-9.2.1.Final/modules,/home/osboxes/java/infinispan-server-9.2.1.Final/modules/system/layers/base))]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:383)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:177)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:163)
> at org.infinispan.client.hotrod.impl.transport.netty.HeaderDecoder.decode(HeaderDecoder.java:85)
> at org.infinispan.client.hotrod.impl.transport.netty.HintedReplayingDecoder.callDecode(HintedReplayingDecoder.java:98)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1414)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:945)
> at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:806)
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:404)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Process finished with exit code 1
> _____
> I used remote Infinispan.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9107) IsolationLevel.READ_COMMITTED does not work as expected
by Tihomir Daskalov (JIRA)
[ https://issues.jboss.org/browse/ISPN-9107?page=com.atlassian.jira.plugin.... ]
Tihomir Daskalov edited comment on ISPN-9107 at 4/27/18 2:51 AM:
-----------------------------------------------------------------
The configuration we use is visible in the attached test file. It is a standalone test that depends only on Infinispan and JUnit.
We tested with local cache. Our application uses both clustered and local caches - depending on the application installation. We were not aware that READ_COMMITTED does not work in clustered environment (did not found this information in the Infinispan documentation). But, nevertheless, we tested the upgrade for now only with the local cache mode.
Our long-running transactions usually take 1-to-3 seconds. However, because of this issue, some of them now take over 20 seconds. This depends on when the transaction made cache lookup - before or after the other transaction has placed the value in it.
Our options for now are:
* Stay with Infinispan 7.2.4
* Upgrade Infinispan, but adapt the application to not rely on the READ_COMMITTED isolation level of Infinispan.
* Look for Infinispan alternative.
How can we perform the Infinispan reads outside a transaction when we are in a JavaEE XA transactional context?
was (Author: tisho2):
The configuration we use is visible in the attached test file. It is a standalone test that depends only on Infinispan and JUnit.
We tested with local cache. Our application uses both clustered and local caches - depending on the application installation. We were not aware that READ_COMMITTED does not work in clustered environment (did not found this information in the Infinispan documentation). But, nevertheless, we tested the upgrade for now only with the local cache mode.
Our long-running transactions usually take 1-to-3 seconds. However, because of this issue, some of them now take over 20 seconds. This depends on when the transaction made cache lookup - before or after the other transaction has placed the value in it.
Our options for now are:
* Stay with Infinispan 7.2.4
* Upgrade Infinispan, but adapt the application to not rely on the READ_COMMITTED isolation level of Infinispan.
* Look for Infinispan alternative.
> IsolationLevel.READ_COMMITTED does not work as expected
> -------------------------------------------------------
>
> Key: ISPN-9107
> URL: https://issues.jboss.org/browse/ISPN-9107
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.1.Final, 9.2.1.Final
> Reporter: Tihomir Daskalov
> Attachments: InfinispanTest.java
>
>
> We use Infinispan in JBoss EAP 7.0.9 as separate module. We use it in TRANSACTIONAL mode with READ_COMMITTED isolation level. After we upgraded Infinispan from 7.2.4 to 9.2.1, we notice that Infinispan does not obey the isolation level. It always behaves as REPEATABLE_READ.
> I see a similar issue in ISPN-1340 that is rejected with the argument that REPEATABLE_READ is a stronger isolation level than READ_COMMITTED and thus the later is not really needed.
> I see this as a feature loss. Our application has long-running transactions that only read from the cache and short-running transactions that read and write. This bug causes the long-running transactions to not see the changes from the short-running transactions. So, they do not profit from the cache and are slower.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9107) IsolationLevel.READ_COMMITTED does not work as expected
by Tihomir Daskalov (JIRA)
[ https://issues.jboss.org/browse/ISPN-9107?page=com.atlassian.jira.plugin.... ]
Tihomir Daskalov commented on ISPN-9107:
----------------------------------------
The configuration we use is visible in the attached test file. It is a standalone test that depends only on Infinispan and JUnit.
We tested with local cache. Our application uses both clustered and local caches - depending on the application installation. We were not aware that READ_COMMITTED does not work in clustered environment (did not found this information in the Infinispan documentation). But, nevertheless, we tested the upgrade for now only with the local cache mode.
Our long-running transactions usually take 1-to-3 seconds. However, because of this issue, some of them now take over 20 seconds. This depends on when the transaction made cache lookup - before or after the other transaction has placed the value in it.
Our options for now are:
* Stay with Infinispan 7.2.4
* Upgrade Infinispan, but adapt the application to not rely on the READ_COMMITTED isolation level of Infinispan.
* Look for Infinispan alternative.
> IsolationLevel.READ_COMMITTED does not work as expected
> -------------------------------------------------------
>
> Key: ISPN-9107
> URL: https://issues.jboss.org/browse/ISPN-9107
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.1.Final, 9.2.1.Final
> Reporter: Tihomir Daskalov
> Attachments: InfinispanTest.java
>
>
> We use Infinispan in JBoss EAP 7.0.9 as separate module. We use it in TRANSACTIONAL mode with READ_COMMITTED isolation level. After we upgraded Infinispan from 7.2.4 to 9.2.1, we notice that Infinispan does not obey the isolation level. It always behaves as REPEATABLE_READ.
> I see a similar issue in ISPN-1340 that is rejected with the argument that REPEATABLE_READ is a stronger isolation level than READ_COMMITTED and thus the later is not really needed.
> I see this as a feature loss. Our application has long-running transactions that only read from the cache and short-running transactions that read and write. This bug causes the long-running transactions to not see the changes from the short-running transactions. So, they do not profit from the cache and are slower.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9109) Commands may be executed in the wrong order after a merge
by Dan Berindei (JIRA)
Dan Berindei created ISPN-9109:
----------------------------------
Summary: Commands may be executed in the wrong order after a merge
Key: ISPN-9109
URL: https://issues.jboss.org/browse/ISPN-9109
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.3.0.Alpha1, 9.2.1.Final
Reporter: Dan Berindei
This is related to ISPN-9104, but it applies to any commands in a REPL_SYNC cache.
We have a topology id check to avoid running commands from an older topology, but if the cluster splits cleanly in 2, then both partitions rebalance and install a topology with the same id. After the partitions merge, commands that were broadcast in one partition are retransmitted by NAKACK2 to the nodes in the other partition, and they will have the right topology id (until the post-merge cache topology update is received) so they will be executed.
The worst scenario is in a transactional cache, where you could have node A in partition \[AB\] broadcast a lock acquisition command ({{LockControlCommand}} in a pessimistic cache, or {{PrepareCommand}} in an optimistic cache), wait for the responses, and then broadcast a lock release command (1-phase {{PrepareCommand}}, {{CommitCommand}}, or {{TxCompletionNotificationCommand}}). In partition \[AB\], the {{TxCompletionNotificationCommand}} is only sent after all the nodes confirmed that they acquired the lock. When partitions \[AB\] and \[CD\] merge, C and D receive both commands, but there's no guarantee that they will be processed in the right order. If the lock release command runs first, it won't do anything, then the lock acquisition command will acquire the lock, and no other command is going to release it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9107) IsolationLevel.READ_COMMITTED does not work as expected
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-9107?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-9107:
-----------------------------------
what configuration are you using?
READ_COMMITTED doesn't work in clustered environments. If the key isn't available locally, it won't perform any database read neither a remote call to re-fetch the value. But it should work in local caches.
why running long read-only transactions? can't the reads be performed outside a transaction?
> IsolationLevel.READ_COMMITTED does not work as expected
> -------------------------------------------------------
>
> Key: ISPN-9107
> URL: https://issues.jboss.org/browse/ISPN-9107
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.1.Final, 9.2.1.Final
> Reporter: Tihomir Daskalov
> Attachments: InfinispanTest.java
>
>
> We use Infinispan in JBoss EAP 7.0.9 as separate module. We use it in TRANSACTIONAL mode with READ_COMMITTED isolation level. After we upgraded Infinispan from 7.2.4 to 9.2.1, we notice that Infinispan does not obey the isolation level. It always behaves as REPEATABLE_READ.
> I see a similar issue in ISPN-1340 that is rejected with the argument that REPEATABLE_READ is a stronger isolation level than READ_COMMITTED and thus the later is not really needed.
> I see this as a feature loss. Our application has long-running transactions that only read from the cache and short-running transactions that read and write. This bug causes the long-running transactions to not see the changes from the short-running transactions. So, they do not profit from the cache and are slower.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9096) XmlPullParserException: Failed to resolve artifact 'org.infinispan.server:infinispan-server-infinispan:9.3.0-SNAPSHOT'
by Diego Lovison (JIRA)
[ https://issues.jboss.org/browse/ISPN-9096?page=com.atlassian.jira.plugin.... ]
Diego Lovison commented on ISPN-9096:
-------------------------------------
The Infinispan was built with:
{noformat}
mvn clean install -f /home_local/workspace/regression-build-infinispan/infinispan/pom.xml -s /home_local/workspace/regression-build-infinispan/jdg-qe/maven/regression/settings.xml -Dmaven.repo.local=/home/hudson/static_build_env/jdg/regression/m2repo -DskipTests=true -Dmaven.javadoc.skip=true -Dcheckstyle.skip
{noformat}
Then it result in:
{noformat}
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20:44 min
{noformat}
I am trying to start the server with:
{noformat}
10:07:08,339 INFO [org.radargun.service.InfinispanServerLifecycle] (sc-main) Starting with: [/home_local/regression/servers/server0/bin/standalone.sh, -Djboss.node.name=slave0, -Djboss.default.multicast.address=234.99.54.20, -Djboss.bind.address=172.18.1.1, -Djboss.default.jgroups.stack=udp, -Dmaven.repo.local=/home/hudson/static_build_env/jdg/regression/m2repo, -server-config, radargun-0.xml]
JAVA_OPTS already set in environment; overriding default settings with values: -Xms16g -Xmx16g -XX:+UseLargePages -XX:+UseG1GC -XX:MaxGCPauseMillis=300 -XX:InitiatingHeapOccupancyPercent=70 -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:gc-perf01-%p.log -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCCause -Djava.net.preferIPv4Stack=true
{noformat}
And then it results in:
{noformat}
[0m10:07:10,613 INFO [org.jboss.modules] (main) JBoss Modules version 1.7.0.Final
[0m[0m10:07:12,112 INFO [org.jboss.msc] (main) JBoss MSC version 1.3.2.Final
[0m[0m10:07:12,158 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.1.Final
[0m[0m10:07:12,721 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: Infinispan Server 9.3.0-SNAPSHOT (WildFly Core 4.0.0.Final) starting
[0m[0m10:07:18,564 INFO [org.jboss.as.controller] (Controller Boot Thread) OPVDX002: Failed to pretty print validation error: null
[0m[31m10:07:18,569 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
at org.jboss.as.server.ServerService.boot(ServerService.java:377)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.infinispan.extension
at org.jboss.as.controller.parsing.DeferredExtensionContext.load(DeferredExtensionContext.java:100)
at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:203)
at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:124)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:108)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:52)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
... 3 more
Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at org.jboss.as.controller.parsing.DeferredExtensionContext.load(DeferredExtensionContext.java:92)
... 10 more
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
at org.jboss.as.controller.parsing.DeferredExtensionContext.loadModule(DeferredExtensionContext.java:129)
at org.jboss.as.controller.parsing.DeferredExtensionContext.access$000(DeferredExtensionContext.java:44)
at org.jboss.as.controller.parsing.DeferredExtensionContext$1.call(DeferredExtensionContext.java:74)
at org.jboss.as.controller.parsing.DeferredExtensionContext$1.call(DeferredExtensionContext.java:71)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home_local/regression/servers/server0/modules/system/layers/base/org/infinispan/extension/main/module.xml
at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:304)
at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:260)
at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:221)
at org.jboss.modules.LocalModuleFinder.parseModuleXmlFile(LocalModuleFinder.java:250)
at org.jboss.modules.LocalModuleFinder.lambda$findModule$1(LocalModuleFinder.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:195)
at org.jboss.modules.ModuleLoader.findModule0(ModuleLoader.java:693)
at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:686)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:496)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:399)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:292)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:280)
at org.jboss.as.controller.parsing.DeferredExtensionContext.loadModule(DeferredExtensionContext.java:111)
... 10 more
Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'org.infinispan.server:infinispan-server-infinispan:9.3.0-SNAPSHOT' (position: END_TAG seen ...g.infinispan.server:infinispan-server-infinispan:9.3.0-SNAPSHOT"/>... @8:91)
at org.jboss.modules.xml.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:981)
at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:869)
at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:659)
at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:426)
at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:302)
... 23 more
[0m[31m10:07:18,580 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
[0m[0m10:07:18,640 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: Infinispan Server 9.3.0-SNAPSHOT (WildFly Core 4.0.0.Final) stopped in 41ms
10:07:18,642 ERROR [org.radargun.service.InfinispanServerLifecycle] (Thread-2) Server stopped before it started!
10:07:18,672 INFO [org.radargun.stages.lifecycle.LifecycleHelper] (sc-main) Number of members=null is not the one expected: 8
[0m
{noformat}
> XmlPullParserException: Failed to resolve artifact 'org.infinispan.server:infinispan-server-infinispan:9.3.0-SNAPSHOT'
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-9096
> URL: https://issues.jboss.org/browse/ISPN-9096
> Project: Infinispan
> Issue Type: Bug
> Environment: Name : redhat-release-server
> Version : 7.2
> Release : 9.el7
> Architecture: x86_64
> Install Date: Dom 02 Out 2016 21:02:35 EDT
> Group : System Environment/Base
> Size : 42562
> License : GPLv2
> Signature : RSA/SHA256, Ter 27 Out 2015 04:47:46 EDT, Key ID 199e2f91fd431d51
> Source RPM : redhat-release-server-7.2-9.el7.src.rpm
> Build Date : Sex 23 Out 2015 09:25:19 EDT
> Build Host : x86-030.build.eng.bos.redhat.com
> Relocations : (not relocatable)
> Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
> Vendor : Red Hat, Inc.
> Summary : Red Hat Enterprise Linux Server release file
> Description :
> Red Hat Enterprise Linux Server release files
> Reporter: Diego Lovison
> Attachments: infinispan-server-empty-repo.log
>
>
> Unable to start the standalone server.
> {noformat}
> 15:38:23,825 INFO [org.jboss.modules] (main) JBoss Modules version 1.7.0.Final
> 15:38:24,948 INFO [org.jboss.msc] (main) JBoss MSC version 1.3.2.Final
> 15:38:24,988 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.1.Final
> 15:38:25,254 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: Infinispan Server 9.3.0-SNAPSHOT (WildFly Core 4.0.0.Final) starting
> 15:38:29,228 INFO [org.jboss.as.controller] (Controller Boot Thread) OPVDX002: Failed to pretty print validation error: null
> 15:38:29,233 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
> at org.jboss.as.server.ServerService.boot(ServerService.java:377)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.infinispan.extension
> at org.jboss.as.controller.parsing.DeferredExtensionContext.load(DeferredExtensionContext.java:100)
> at org.jboss.as.server.parsing.StandaloneXml_6.readServerElement(StandaloneXml_6.java:240)
> at org.jboss.as.server.parsing.StandaloneXml_6.readElement(StandaloneXml_6.java:140)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:114)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:52)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
> ... 3 more
> Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.jboss.as.controller.parsing.DeferredExtensionContext.load(DeferredExtensionContext.java:92)
> ... 10 more
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
> at org.jboss.as.controller.parsing.DeferredExtensionContext.loadModule(DeferredExtensionContext.java:129)
> at org.jboss.as.controller.parsing.DeferredExtensionContext.access$000(DeferredExtensionContext.java:44)
> at org.jboss.as.controller.parsing.DeferredExtensionContext$1.call(DeferredExtensionContext.java:74)
> at org.jboss.as.controller.parsing.DeferredExtensionContext$1.call(DeferredExtensionContext.java:71)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home_local/workspace/tmp_diego/infinispan/server/integration/build/target/infinispan-server-9.3.0-SNAPSHOT/modules/system/layers/base/org/infinispan/extension/main/module.xml
> at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:304)
> at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:260)
> at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:221)
> at org.jboss.modules.LocalModuleFinder.parseModuleXmlFile(LocalModuleFinder.java:250)
> at org.jboss.modules.LocalModuleFinder.lambda$findModule$1(LocalModuleFinder.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:195)
> at org.jboss.modules.ModuleLoader.findModule0(ModuleLoader.java:693)
> at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:686)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:496)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:399)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:292)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:280)
> at org.jboss.as.controller.parsing.DeferredExtensionContext.loadModule(DeferredExtensionContext.java:111)
> ... 10 more
> Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'org.infinispan.server:infinispan-server-infinispan:9.3.0-SNAPSHOT' (position: END_TAG seen ...g.infinispan.server:infinispan-server-infinispan:9.3.0-SNAPSHOT"/>... @8:91)
> at org.jboss.modules.xml.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:981)
> at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:869)
> at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:659)
> at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:426)
> at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:302)
> ... 23 more
> 15:38:29,244 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:38:29,286 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: Infinispan Server 9.3.0-SNAPSHOT (WildFly Core 4.0.0.Final) stopped in 25ms
> [hudson@edg-perf09 bin]$
> {noformat}
> I was not able to reproduce on my local machine. It is only occurring in the Jenkins servers.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9106) Cli fails with link error
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9106?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-9106:
-------------------------------
Status: Open (was: New)
> Cli fails with link error
> -------------------------
>
> Key: ISPN-9106
> URL: https://issues.jboss.org/browse/ISPN-9106
> Project: Infinispan
> Issue Type: Bug
> Components: CLI, Server
> Affects Versions: 9.3.0.Alpha1
> Reporter: Sebastian Łaskawiec
> Assignee: Ryan Emerson
> Fix For: 9.3.0.Beta1
>
>
> The readiness check returns an error on current master build:
> {code}
> opt/jboss/infinispan-server/bin/ispn-cli.sh -c --controller=172.16.26.143:9990 '/subsystem=datagrid-infinispan/cache-container=clustered/health=HEALTH:read-attribute(name=cluster-health)'
> Failed to link org/jboss/as/patching/cli/PatchCommand (Module "org.jboss.as.patching" version 4.0.0.Final from local module loader @555590 (finder: local module finder @6d1e7682 (roots: /opt/jboss/infinispan-server/modules,/opt/jboss/infinispan-server/modules/system/layers/base))): org/aesh/command/Command
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9106) Cli fails with link error
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9106?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-9106:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5943
> Cli fails with link error
> -------------------------
>
> Key: ISPN-9106
> URL: https://issues.jboss.org/browse/ISPN-9106
> Project: Infinispan
> Issue Type: Bug
> Components: CLI, Server
> Affects Versions: 9.3.0.Alpha1
> Reporter: Sebastian Łaskawiec
> Assignee: Ryan Emerson
> Fix For: 9.3.0.Beta1
>
>
> The readiness check returns an error on current master build:
> {code}
> opt/jboss/infinispan-server/bin/ispn-cli.sh -c --controller=172.16.26.143:9990 '/subsystem=datagrid-infinispan/cache-container=clustered/health=HEALTH:read-attribute(name=cluster-health)'
> Failed to link org/jboss/as/patching/cli/PatchCommand (Module "org.jboss.as.patching" version 4.0.0.Final from local module loader @555590 (finder: local module finder @6d1e7682 (roots: /opt/jboss/infinispan-server/modules,/opt/jboss/infinispan-server/modules/system/layers/base))): org/aesh/command/Command
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9106) Cli fails with link error
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9106?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-9106:
------------------------------------
[~sebastian.laskawiec] Good job you spotted this as it wasn't just the readiness probe that failed to execute, but the entire cli!
> Cli fails with link error
> -------------------------
>
> Key: ISPN-9106
> URL: https://issues.jboss.org/browse/ISPN-9106
> Project: Infinispan
> Issue Type: Bug
> Components: CLI, Server
> Affects Versions: 9.3.0.Alpha1
> Reporter: Sebastian Łaskawiec
> Assignee: Ryan Emerson
> Fix For: 9.3.0.Beta1
>
>
> The readiness check returns an error on current master build:
> {code}
> opt/jboss/infinispan-server/bin/ispn-cli.sh -c --controller=172.16.26.143:9990 '/subsystem=datagrid-infinispan/cache-container=clustered/health=HEALTH:read-attribute(name=cluster-health)'
> Failed to link org/jboss/as/patching/cli/PatchCommand (Module "org.jboss.as.patching" version 4.0.0.Final from local module loader @555590 (finder: local module finder @6d1e7682 (roots: /opt/jboss/infinispan-server/modules,/opt/jboss/infinispan-server/modules/system/layers/base))): org/aesh/command/Command
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years