[JBoss JIRA] (WFCORE-4051) KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4051?page=com.atlassian.jira.plugi... ]
Martin Choma updated WFCORE-4051:
---------------------------------
Affects: Documentation (Ref Guide, User Guide, etc.)
> KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> -------------------------------------------------------------------------
>
> Key: WFCORE-4051
> URL: https://issues.jboss.org/browse/WFCORE-4051
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 6.0.0.CR2
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 6.0.0.CR3
>
>
> Creating 2-way SSL Context fails with error.
> {code}
> 12:04:28,689 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.ssl-context.ssl-context-client-cert: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.ssl-context-client-cert: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:982)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> 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:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:115)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:78)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:980)
> ... 9 more
> 12:04:28,690 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("server-ssl-context" => "ssl-context-client-cert")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.ssl-context-client-cert" => "java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used"}}
> {code}
> Seems DelegatingTrustManager is created always.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10557) JPA application deploy fails with "CDI BeanManager not (yet) ready to use"
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10557?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-10557.
-------------------------------
Resolution: Duplicate Issue
Duplicated by [https://hibernate.atlassian.net/browse/HHH-12912]. Since the HHH-12912 bug will be best fixed in the Hibernate ORM project, I am closing this issue.
> JPA application deploy fails with "CDI BeanManager not (yet) ready to use"
> --------------------------------------------------------------------------
>
> Key: WFLY-10557
> URL: https://issues.jboss.org/browse/WFLY-10557
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JPA / Hibernate
> Affects Versions: 13.0.0.Final
> Environment: macOS High Sierra
> Java 8
> Wildfly 13
> Reporter: Cristhian Camilo Lopez
> Assignee: Bartosz Baranowski
> Priority: Minor
> Labels: cdi, jpa2, wildfly
> Attachments: ee8-jpa-converter-1.0-SNAPSHOT.war, ee8-jpa-converter-1.0-SNAPSHOT.war, persistence-xml.png
>
>
> Deployment of app using JPA converters for enums fails with the following message
> {code:java}
> 10:01:44,044 INFO [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator] (ServerService Thread Pool -- 71) HHH000397: Using ASTQueryTranslatorFactory
> 10:01:44,047 ERROR [org.hibernate.internal.SessionFactoryImpl] (ServerService Thread Pool -- 71) HHH000177: Error in named query: findEnabledProducts: org.hibernate.QueryException: Could not format constant value to SQL literal: co.cristhian.bugs.product.entity.State.ENABLED [SELECT p FROM co.cristhian.bugs.product.entity.Product p WHERE p.state = co.cristhian.bugs.product.entity.State.ENABLED]
> at org.hibernate.QueryException.generateQueryException(QueryException.java:120)
> at org.hibernate.QueryException.wrapWithQueryString(QueryException.java:103)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:219)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:143)
> at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:120)
> at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:81)
> at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:153)
> at org.hibernate.query.spi.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:157)
> at org.hibernate.internal.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:574)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:321)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:167)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:125)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:650)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:209)
> 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:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: org.hibernate.QueryException: Could not format constant value to SQL literal: co.cristhian.bugs.product.entity.State.ENABLED
> at org.hibernate.hql.internal.ast.tree.JavaConstantNode.getRenderText(JavaConstantNode.java:111)
> at org.hibernate.hql.internal.ast.SqlGenerator.out(SqlGenerator.java:116)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.simpleExpr(SqlGeneratorBase.java:3030)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.expr(SqlGeneratorBase.java:1633)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.binaryComparisonExpression(SqlGeneratorBase.java:3325)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.comparisonExpr(SqlGeneratorBase.java:1442)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.booleanExpr(SqlGeneratorBase.java:934)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.whereExpr(SqlGeneratorBase.java:780)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.selectStatement(SqlGeneratorBase.java:213)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.statement(SqlGeneratorBase.java:146)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.generate(QueryTranslatorImpl.java:250)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:211)
> ... 20 more
> Caused by: java.lang.IllegalStateException: org.hibernate.resource.beans.container.internal.NotYetReadyException: CDI BeanManager not (yet) ready to use
> at org.hibernate.resource.beans.container.internal.JpaCompliantLifecycleStrategy$BeanImpl.initialize(JpaCompliantLifecycleStrategy.java:112)
> at org.hibernate.resource.beans.container.internal.CdiBeanContainerExtendedAccessImpl$BeanImpl.initialize(CdiBeanContainerExtendedAccessImpl.java:113)
> at org.hibernate.resource.beans.container.internal.CdiBeanContainerExtendedAccessImpl$BeanImpl.getBeanInstance(CdiBeanContainerExtendedAccessImpl.java:119)
> at org.hibernate.resource.beans.internal.ManagedBeanRegistryImpl$ContainedBeanManagedBeanAdapter.getBeanInstance(ManagedBeanRegistryImpl.java:139)
> at org.hibernate.metamodel.model.convert.internal.JpaAttributeConverterImpl.toRelationalValue(JpaAttributeConverterImpl.java:50)
> at org.hibernate.hql.internal.ast.tree.JavaConstantNode.getRenderText(JavaConstantNode.java:89)
> ... 31 more
> Caused by: org.hibernate.resource.beans.container.internal.NotYetReadyException: CDI BeanManager not (yet) ready to use
> ... 37 more
> Caused by: java.lang.NullPointerException
> at org.hibernate.resource.beans.container.internal.JpaCompliantLifecycleStrategy$BeanImpl.initialize(JpaCompliantLifecycleStrategy.java:109)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-118) [Artemis 2.x upgrade] Transaction remained in prepared state
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-118?page=com.atlassian.jira.plugin.... ]
Erich Duda updated WFWIP-118:
-----------------------------
Description:
*Scenario*
* Start group A of two servers (node-1 and node-3) Servers are not in cluster.
* Send messages to queue on node-1.
* Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
* Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
* Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
* Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
*Investigation of issue is in progress. It is not known what component causes it.*
Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
{quote}I looked at the output from the clients, and filtered the processing
for one XA that's never commited..
I looked for the XID on
base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
and filtered the onMessage that generated it (attached the log as
processingOneMessage.txt):
This XID was never commited simply because the TM never did it.
Probably because of some issue on the JDBC.. but there are no errors,
no exceptions.. totally clean on artemis side.
There are no logging for TM or the MDB itself to correlate other
failures. With the information I have I am certain there were nothing
from Artemis side that would have caused it.
In any case.. this is not replicated at all.. and not related to 87.
This is simply the TM getting confused for some issue on the JDBC.
As far as I am concerned I have fixed the replicated shutdown case.
and i will send PRs upstream now.{quote}
was:
*Scenario*
* Start group A of two servers (node-1 and node-3) Servers are not in cluster.
* Send messages to queue on node-1.
* Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
* Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
* Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
* Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
*Investigation of issue is in progress. It is not known what component causes it.*
Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
{quote}I looked at the output from the clients, and filtered the processing
for one XA that's never commited..
I looked for the XID on
base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
and filtered the onMessage that generated it (attached the log as
processingOneMessage.txt):
This XID was never commited simply because the TM never did it.
Probably because of some issue on the JDBC.. but there are no errors,
no exceptions.. totally clean on artemis side.
There are no logging for TM or the MDB itself to correlate other
failures. With the information I have I am certain there were nothing
from Artemis side that would have caused it.
In any case.. this is not replicated at all.. and not related to 87.
This is simply the TM getting confused for some issue on the JDBC.
As far as I am concerned I have fixed the replicated shutdown case.
and i will send PRs upstream now.{quote}
> [Artemis 2.x upgrade] Transaction remained in prepared state
> ------------------------------------------------------------
>
> Key: WFWIP-118
> URL: https://issues.jboss.org/browse/WFWIP-118
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Erich Duda
> Assignee: Kabir Khan
> Priority: Blocker
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SWSQE-383) Run UI tests and REST tests sequentialy not in parallel
by Filip Brychta (JIRA)
Filip Brychta created SWSQE-383:
-----------------------------------
Summary: Run UI tests and REST tests sequentialy not in parallel
Key: SWSQE-383
URL: https://issues.jboss.org/browse/SWSQE-383
Project: Kiali QE
Issue Type: Bug
Reporter: Filip Brychta
Assignee: Filip Brychta
We are running UI and REST tests in parallel but those tests are not atomic. We need to run it sequentially.
Here is the main pipeline snippet:
stage('Run Tests') {$
parallel {$
stage('Python UI tests') {$
when { environment name: 'RUN_UI_TESTS', value: 'true' }$
steps {$
build(job: 'run-python-ui-tests',$
parameters: [$
[$class: 'StringParameterValue', value: "${params.OS_USERNAME}", name: 'OS_USERNAME'],$
[$class: 'StringParameterValue', value: "${params.OS_PASSWORD}", name: 'OS_PASSWORD'],$
[$class: 'StringParameterValue', value: "https://${params.OS_HOSTNAME}:${params.OS_PORT}", name: 'OS_URL'],$
]$
)$
}$
}$
stage('REST API tests') {$
when { environment name: 'RUN_REST_TESTS', value: 'true' }$
steps {$
build(job: 'run-python-rest-tests',$
parameters: [$
[$class: 'StringParameterValue', value: "${params.OS_USERNAME}", name: 'OS_USERNAME'],$
[$class: 'StringParameterValue', value: "${params.OS_PASSWORD}", name: 'OS_PASSWORD'],$
[$class: 'StringParameterValue', value: "https://${params.OS_HOSTNAME}:${params.OS_PORT}", name: 'OS_URL'],$
]$
)$
}$
}$
}$
}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2578) [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2578?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-2578:
----------------------------------------
[~manstis] I had to focus on RHDM7.1 deliverables for basically the last 10weeks. As soon as I'm out of the tunnel for which I'm maybe starting to see the lights at the end of it.. ( and hopefully that light is not a train incoming my direction =P )
> [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
> --------------------------------------------------------------------------------
>
> Key: DROOLS-2578
> URL: https://issues.jboss.org/browse/DROOLS-2578
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Matteo Mortari
> Priority: Critical
>
> In order to correctly handle QName prefix resolution I have added {{DMNModelInstrumentedBase.getPrefixForNamespaceURI(..)}} to the UI model. I will add support for setting it appropriately as the User authors a DMN model in the UI (i.e. to new elements as and when created) however the marshaller will need to set it accordingly when going from KIE-DMN-model to UI-DMN-model too; so existing diagrams have the parental hierarchy correctly set.
> This depends on https://github.com/kiegroup/kie-wb-common/pull/1818 being merged.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-56) IndexOutOfBoundsException in JDBC HA scenario
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-56?page=com.atlassian.jira.plugin.s... ]
Erich Duda commented on WFWIP-56:
---------------------------------
[~gaohoward] The last time we saw the issue here - https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
> IndexOutOfBoundsException in JDBC HA scenario
> ---------------------------------------------
>
> Key: WFWIP-56
> URL: https://issues.jboss.org/browse/WFWIP-56
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
>
> PR: https://github.com/wildfly/wildfly/pull/11355
> *Scenario:*
> * There are two Wildfly servers each containing two Artemis brokers
> * Artemis brokers creates two live-backup pairs. Each Wildfly instance contains one live and one backup
> * Second server has MDB which resends messages from InQueue to OutQueue
> * The second server is stopped and restarted
> After the second server is restarted, everything works correctly for a while. Failback performs successfully, MDB resends messages. However after some time the server starts to print many errors \[1\]. It looks like some messages where corrupted during failover/failback and cannot be delivered.
> The reproducer always hits the issue. The issue is not relevant to particular database, I hit it with Oracle12c and DB2 11.1. I also tried to reduce amount of messages and their size, but I still hit the issue. So it is not related to paging or large messages.
> \[1\]
> {code}
> 15:20:50,010 ERROR [org.apache.activemq.artemis.ra] (Thread-7 (ActiveMQ-client-global-threads)) AMQ154004: Failed to deliver message: java.lang.IndexOutOfBoundsException
> at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readSimpleStringInternal(ChannelBufferWrapper.java:93) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:73) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.reader.TextMessageUtil.readBodyText(TextMessageUtil.java:37) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:112) [artemis-jms-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:295) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months