[JBoss JIRA] (WFCORE-938) Embedded host controller doesn't support --admin-mode=false option
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-938?page=com.atlassian.jira.plugin... ]
Ken Wills edited comment on WFCORE-938 at 10/27/15 5:11 PM:
------------------------------------------------------------
Embedded HC is forced into admin-only = true now, also see ReloadHandler.doHandleEmbedded for ensuring that this is preserved through reloads until we support this feature.
was (Author: luck3y):
Embedded HC is forced into admin-only = true now, also see ReloadHandler.buildRequestWithoutHeaders for ensuring that this is preserver through reloads.
> Embedded host controller doesn't support --admin-mode=false option
> ------------------------------------------------------------------
>
> Key: WFCORE-938
> URL: https://issues.jboss.org/browse/WFCORE-938
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> Embedded standalone instance supports two running modes depending on a value of admin-only option (true is default).
> * *true*
> ** only start services related to server administration
> ** do not start other services or accept end user requests.
> ** embedded instance will not be visible to remote management clients
> * *false*
> ** all services are started
> ** embedded instance is visible to remote management clients (e.g. EAP can be configured via admin console)
> Embedded host controller doesn't offer such a option and is started using --admin-only=true mode by default. Option to run embedded host controller instance with --admin-only=false should be available as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-938) Embedded host controller doesn't support --admin-mode=false option
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-938?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-938:
----------------------------------
Embedded HC is forced into admin-only = true now, also see ReloadHandler.buildRequestWithoutHeaders for ensuring that this is preserver through reloads.
> Embedded host controller doesn't support --admin-mode=false option
> ------------------------------------------------------------------
>
> Key: WFCORE-938
> URL: https://issues.jboss.org/browse/WFCORE-938
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> Embedded standalone instance supports two running modes depending on a value of admin-only option (true is default).
> * *true*
> ** only start services related to server administration
> ** do not start other services or accept end user requests.
> ** embedded instance will not be visible to remote management clients
> * *false*
> ** all services are started
> ** embedded instance is visible to remote management clients (e.g. EAP can be configured via admin console)
> Embedded host controller doesn't offer such a option and is started using --admin-only=true mode by default. Option to run embedded host controller instance with --admin-only=false should be available as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1079) Revert dependency on wildfly-common added to the protocol module
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1079:
----------------------------------------
Summary: Revert dependency on wildfly-common added to the protocol module
Key: WFCORE-1079
URL: https://issues.jboss.org/browse/WFCORE-1079
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Affects Versions: 2.0.0.CR8
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.CR9
https://github.com/wildfly/wildfly-core/commit/053d68a5 introduced a dependency of the 'protocol' module on wildfly-common. The 'protocol' module is a dep of 'controller-client' so this means wildfly-common now becomes a dep of anyone wanting to use ModelControllerClient.
I want to remove that dep, as the gains from bringing it in are really tiny; just a slightly more accurate initial sizing param for a couple of maps.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5011) OutdatedTopologyException: Cache not running on node <node_name>
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5011?page=com.atlassian.jira.plugin.... ]
Paul Ferraro resolved WFLY-5011.
--------------------------------
Fix Version/s: 10.0.0.CR3
Resolution: Done
Resolved by https://github.com/wildfly/wildfly/commit/25e62d6c854fb567aa743f3828ef34b...
> OutdatedTopologyException: Cache not running on node <node_name>
> ----------------------------------------------------------------
>
> Key: WFLY-5011
> URL: https://issues.jboss.org/browse/WFLY-5011
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 10.0.0.CR3
>
>
> Seen in our HTTP-based failover tests (no matter what failover type: jvmkill/shutdown/undeploy), with *distributed* cache used.
> Doe not occur when replicated cache is used.
> Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application.
> After failing one node(failover type: jvmkill/shutdown/undeploy) - perf18 for example, perf19,20,21 log the following error message many times (seems like one error per each session)
> {code}
> [JBossINF] [0m[31m05:48:40,646 ERROR [io.undertow.request] (default task-110) UT005023: Exception handling request to /clusterbench/session: org.infinispan.statetransfer.OutdatedTopologyException: Cache not running on node perf18
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.checkTxCommandResponses(TxDistributionInterceptor.java:274)
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitLockControlCommand(TxDistributionInterceptor.java:186)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.acquireRemoteIfNeeded(PessimisticLockingInterceptor.java:238)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:66)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:70)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:318)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:364)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:349)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:430)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:120)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:232)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:116)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1074) Intermittent failure in DeploymentScannerUnitTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1074?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-1074 at 10/27/15 3:14 PM:
--------------------------------------------------------------------
Emmanuel and I were chatting, so this is a follow up to his last comment based on our chat.
1) If an app tries to deploy and deployment doesn't go well due to some service problems, but rollback-on-runtime-failure=false is set, that app is still "deployed" in the management sense. The 'enabled' attribute will be set to 'true' in the model, and MSC will have a bunch of services installed related to the app. It just won't be functioning properly. So, sending a "deployed" notification is valid.
2) The notifications really are only relevant for cases like WFCORE-860 where the end user is directly using CLI/console to tweak the state of a scanner controlled deployment. There the scanner needs notifications to be aware of user-initiated changes. But the scanner has logic to ignore notifications emitted as a result of its *own* activity. Perhaps there is a bug there, but the logic to ignore definitely exists.
was (Author: brian.stansberry):
Emanuel and I were chatting, so this is a follow up to his last comment based on our chat.
1) If an app tries to deploy and deployment doesn't go well due to some service problems, but rollback-on-runtime-failure=false is set, that app is still "deployed" in the management sense. The 'enabled' attribute will be set to 'true' in the model, and MSC will have a bunch of services installed related to the app. It just won't be functioning properly. So, sending a "deployed" notification is valid.
2) The notifications really are only relevant for cases like WFCORE-860 where the end user is directly using CLI/console to tweak the state of a scanner controlled deployment. There the scanner needs notifications to be aware of user-initiated changes. But the scanner has logic to ignore notifications emitted as a result of its *own* activity. Perhaps there is a bug there, but the logic to ignore definitely exists.
> Intermittent failure in DeploymentScannerUnitTestCase
> -----------------------------------------------------
>
> Key: WFCORE-1074
> URL: https://issues.jboss.org/browse/WFCORE-1074
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha1
>
>
> DeploymentScannerUnitTestCase occasionally fails, 4 times in the last six weeks or so per Team City records:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
> May not be relevant but the change log associated with the first failure shows WFCORE-903 / WFCORE-860 as part of the change set:
>
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=70465&tab=buil...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1074) Intermittent failure in DeploymentScannerUnitTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1074?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1074:
------------------------------------------
Emanuel and I were chatting, so this is a follow up to his last comment based on our chat.
1) If an app tries to deploy and deployment doesn't go well due to some service problems, but rollback-on-runtime-failure=false is set, that app is still "deployed" in the management sense. The 'enabled' attribute will be set to 'true' in the model, and MSC will have a bunch of services installed related to the app. It just won't be functioning properly. So, sending a "deployed" notification is valid.
2) The notifications really are only relevant for cases like WFCORE-860 where the end user is directly using CLI/console to tweak the state of a scanner controlled deployment. There the scanner needs notifications to be aware of user-initiated changes. But the scanner has logic to ignore notifications emitted as a result of its *own* activity. Perhaps there is a bug there, but the logic to ignore definitely exists.
> Intermittent failure in DeploymentScannerUnitTestCase
> -----------------------------------------------------
>
> Key: WFCORE-1074
> URL: https://issues.jboss.org/browse/WFCORE-1074
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha1
>
>
> DeploymentScannerUnitTestCase occasionally fails, 4 times in the last six weeks or so per Team City records:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
> May not be relevant but the change log associated with the first failure shows WFCORE-903 / WFCORE-860 as part of the change set:
>
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=70465&tab=buil...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5594) ISE when configuring web/ejb clustering with invalidation cache
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-5594:
----------------------------------
Summary: ISE when configuring web/ejb clustering with invalidation cache
Key: WFLY-5594
URL: https://issues.jboss.org/browse/WFLY-5594
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR4
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Priority: Critical
Both the web and ejb clustering modules use a key affinity service to generate session IDs for replication and distribution mode - however, they currently attempt to use a key affinity service with invalidation mode as well, which throws an ISE. Neither LOCAL nor INVALIDATION caches should attempt to use a key affinity service.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5480) SPEC JMS 2007 benchmark fails with AMQ214013: Failed to decode packet
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFLY-5480?page=com.atlassian.jira.plugin.... ]
Clebert Suconic commented on WFLY-5480:
---------------------------------------
Flavia if you want to build 1.1.x on artemis, you will need this commit for wildfly:
https://github.com/clebertsuconic/wildfly/commit/8af984c656440b0398553037...
> SPEC JMS 2007 benchmark fails with AMQ214013: Failed to decode packet
> ---------------------------------------------------------------------
>
> Key: WFLY-5480
> URL: https://issues.jboss.org/browse/WFLY-5480
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Ondřej Kalman
> Assignee: Flavia Rainone
> Priority: Blocker
>
> But I have another problem, when I removed trace logs from config I'm not able to run benchmark on localhost to the end, because clients starts getting :
> AMQ214013: Failed to decode packet
> java.lang.IndexOutOfBoundsException: readerIndex: 2130706436 (expected: 0 <= readerIndex <= writerIndex(2943))
> at io.netty.buffer.AbstractByteBuf.readerIndex(AbstractByteBuf.java:73)
> at io.netty.buffer.WrappedByteBuf.readerIndex(WrappedByteBuf.java:99)
> at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readerIndex(ChannelBufferWrapper.java:405)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.decode(MessageImpl.java:1052)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.decodeFromBuffer(MessageImpl.java:459)
> at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionReceiveMessage.decode(SessionReceiveMessage.java:94)
> at org.apache.activemq.artemis.core.protocol.ClientPacketDecoder.decode(ClientPacketDecoder.java:42)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:371)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1374)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteCha
> nnel.java:131)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
> at java.lang.Thread.run(Thread.java:745)
> and
> Thread-9 (ActiveMQ-client-global-threads-1266561810): Uncaught exception.
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:542)
> at java.lang.Integer.valueOf(Integer.java:766)
> at org.apache.activemq.artemis.utils.TypedProperties.getIntProperty(TypedProperties.java:280)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.getIntProperty(MessageImpl.java:811)
> at org.apache.activemq.artemis.jms.client.ActiveMQMessage.getIntProperty(ActiveMQMessage.java:578)
> at org.spec.jms.agents.SPECWorkerThread.receivedMessage(SPECWorkerThread.java:849)
> at org.spec.jms.agents.SPECWorkerThread.onMessage(SPECWorkerThread.java:820)
> at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:100)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1089)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1224)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> 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)
> Thread-3 (ActiveMQ-client-global-threads-1266561810): Uncaught exception.
> javax.jms.IllegalStateException: AMQ119027: Could not find reference on consumer ID=0, messageId = 104,833 queue = 127\.0\.0\.1_VM1_SPAgent7_0.SP_CallForOffersEH_7_EHID_1PF0
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:410)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendACK(ActiveMQSessionContext.java:461)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.acknowledge(ClientSessionImpl.java:765)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.doAck(ClientConsumerImpl.java:1212)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.flushAcks(ClientConsumerImpl.java:830)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.flushAcks(ClientSessionImpl.java:1852)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:501)
> at org.apache.activemq.artemis.core.client.impl.DelegatingSession.commit(DelegatingSession.java:159)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.commit(ActiveMQSession.java:218)
> at org.spec.jms.eventhandler.sp.SP_CallForOffersEH.handleMessage(SP_CallForOffersEH.java:306)
> at org.spec.jms.agents.SPECWorkerThread.onMessage(SPECWorkerThread.java:821)
> at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:100)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1089)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1224)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecut
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months