August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-87) [Artemis 2.x upgrade] Transaction remained in prepared state after failover of MDB

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFWIP-87?page=com.atlassian.jira.plugin.s... ] Miroslav Novak updated WFWIP-87: -------------------------------- Component/s: Artemis > [Artemis 2.x upgrade] Transaction remained in prepared state after failover of MDB > ---------------------------------------------------------------------------------- > > Key: WFWIP-87 > URL: https://issues.jboss.org/browse/WFWIP-87 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > > There is regression in test scenario where MDB failovers from live to backup. Live is cleanly shutdown. > Problem is that after MDB failovers to backup then there is still transaction in prepared state which survive periodic recovery cycles. > Link to build: > https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-87) [Artemis 2.x upgrade] Transaction remained in prepared state after failover of MDB

by Miroslav Novak (JIRA)

Miroslav Novak created WFWIP-87: ----------------------------------- Summary: [Artemis 2.x upgrade] Transaction remained in prepared state after failover of MDB Key: WFWIP-87 URL: https://issues.jboss.org/browse/WFWIP-87 Project: WildFly WIP Issue Type: Bug Reporter: Miroslav Novak Assignee: Kabir Khan Priority: Blocker There is regression in test scenario where MDB failovers from live to backup. Live is cleanly shutdown. Problem is that after MDB failovers to backup then there is still transaction in prepared state which survive periodic recovery cycles. Link to build: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-87) [Artemis 2.x upgrade] Transaction remained in prepared state after failover of MDB

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFWIP-87?page=com.atlassian.jira.plugin.s... ] Miroslav Novak reassigned WFWIP-87: ----------------------------------- Assignee: Martyn Taylor (was: Kabir Khan) > [Artemis 2.x upgrade] Transaction remained in prepared state after failover of MDB > ---------------------------------------------------------------------------------- > > Key: WFWIP-87 > URL: https://issues.jboss.org/browse/WFWIP-87 > Project: WildFly WIP > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > > There is regression in test scenario where MDB failovers from live to backup. Live is cleanly shutdown. > Problem is that after MDB failovers to backup then there is still transaction in prepared state which survive periodic recovery cycles. > Link to build: > https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-86) [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge

by Miroslav Novak (JIRA)

Miroslav Novak created WFWIP-86: ----------------------------------- Summary: [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge Key: WFWIP-86 URL: https://issues.jboss.org/browse/WFWIP-86 Project: WildFly WIP Issue Type: Bug Components: Artemis Reporter: Miroslav Novak Assignee: Martyn Taylor Priority: Blocker There are duplicated messages in scenario where JMS bridge is stopped and started. Test Scenario: * Start 2 servers and configure JMS from node-1 to node-3 * Start sending messages to queue InQueue to node-1 * Stop JMS bridge using management operation (CLI) * Wait for 5 sec * Start JMS bridge using management operation * Start receiving mesage from node-3 from OutQueue Expected results: There are no lost/duplicated mesages. Actual Result: Receiver got duplicated messages. Link to failed Jenkins run: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2831) Memory leak when a mvel operator creates an EvaluatorWrapper

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2831: ----------------------------------- Summary: Memory leak when a mvel operator creates an EvaluatorWrapper Key: DROOLS-2831 URL: https://issues.jboss.org/browse/DROOLS-2831 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco Attachments: HxT83G5.png The EvaluatorWrapper (which is created in some cases when a constraint uses an mvel operator) holds a reference to one or two FactHandles. Those reference are retained even after the KieSession has been disposed, thus causing a memory leak. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-67) [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFWIP-67?page=com.atlassian.jira.plugin.s... ] Miroslav Novak updated WFWIP-67: -------------------------------- Steps to Reproduce: {code} git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ git checkout eap7.2.x-artemis2.x-ha-jdbc groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP7-JMS/view/early-testing/view/tooling/job/early-testing-messaging-prepare/545/artifact/jboss-eap.zip -DEAP_ZIP_URL_OLD=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP7-JMS/view/early-testing/view/tooling/job/early-testing-messaging-prepare/546/artifact/jboss-eap.zip PrepareServers7.groovy export WORKSPACE=$PWD export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap cd ../jboss-hornetq-testsuite/ mvn clean test -Dtest=ResourceAdapterCompatibilityTestCase#OldJmsNewMdbWithStaticConnectorKill -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1531748885-SNAPSHOT | tee log {code} was: {code} git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP7-JMS/view/early-testing/view/tooling/job/early-testing-messaging-prepare/545/artifact/jboss-eap.zip -DEAP_ZIP_URL_OLD=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP7-JMS/view/early-testing/view/tooling/job/early-testing-messaging-prepare/546/artifact/jboss-eap.zip PrepareServers7.groovy export WORKSPACE=$PWD export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap cd ../jboss-hornetq-testsuite/ mvn clean test -Dtest=ResourceAdapterCompatibilityTestCase#OldJmsNewMdbWithStaticConnectorKill -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1531748885-SNAPSHOT | tee log {code} > [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFWIP-67 > URL: https://issues.jboss.org/browse/WFWIP-67 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Martin Styk > Assignee: Martyn Taylor > Priority: Blocker > > *Scenario:* > Nodes A and B are in cluster. Destinations InQueue and OutQueue are deployed on them. > MDBs are deployed on node C and D. These MDBs read messages from InQueue of nodes A, B and sends them to OutQueue on A and B. > Nodes A,B are running Artemis 1.5. Nodes C,D are using Artemis 2.6. > # Client sends messages to InQueue on node A > # MDBs on nodes C,D read messages from remote InQueue and send them to remote OutQueue on nodes A,B > # During processing of messages nodes A and C are killed > # Client reads messages from OutQueue on node B. > *Issue* > At the end of the test, client is not able to read message > {code} > java.lang.IndexOutOfBoundsException: readerIndex(9) + length(128) exceeds writerIndex(133): UnpooledDuplicatedByteBuf(ridx: 9, widx: 133, cap: 606, unwrapped: UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx: 606, cap: 606)) > at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1405) > at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1392) > at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:872) > at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:880) > at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:649) > at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:183) > at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:171) > at org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:158) > at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:69) > at org.apache.activemq.artemis.reader.TextMessageUtil.readBodyText(TextMessageUtil.java:37) > at org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:112) > at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:224) > at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:132) > at org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:151) > at org.jboss.qa.hornetq.apps.clients.ReceiverTransAck.run(ReceiverTransAck.java:89) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-85) [Upgrade Artemis 2.x] MDB (Artemis 1.5.x RA) cannot connect to Artemis 2.x broker using JGroups discovery

by Miroslav Novak (JIRA)

Miroslav Novak created WFWIP-85: ----------------------------------- Summary: [Upgrade Artemis 2.x] MDB (Artemis 1.5.x RA) cannot connect to Artemis 2.x broker using JGroups discovery Key: WFWIP-85 URL: https://issues.jboss.org/browse/WFWIP-85 Project: WildFly WIP Issue Type: Bug Components: Artemis Reporter: Miroslav Novak Assignee: Martyn Taylor Priority: Blocker MDB deployed to older EAP 7.1.0.GA(Artemis 1.5 RA) cannot consume messages from newer Artemis 2.x server (build https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-...) There is no exception in the log during start however MDB does not start to consume messages. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10055) [Artemis 2.x Upgrade] Auto-create-queue creates runtime queue without jms.queue prefix

by Martin Styk (JIRA)

[ https://issues.jboss.org/browse/WFLY-10055?page=com.atlassian.jira.plugin... ] Martin Styk reopened WFLY-10055: -------------------------------- This test still fails with https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-... > [Artemis 2.x Upgrade] Auto-create-queue creates runtime queue without jms.queue prefix > --------------------------------------------------------------------------------------- > > Key: WFLY-10055 > URL: https://issues.jboss.org/browse/WFLY-10055 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Martin Styk > Assignee: Martyn Taylor > > {{Auto-create-jms-queue}} feature of EAP 7.1 creates runtime queues with name pattern {{"jms.queue.<QUEUE_NAME>"}}. > With Artemis 2.5, {{auto-create-queue}} is a successor of deprecated {{auto-create-jms-queue}} feature. {{Auto-create-queue}} creates queues with name pattern {{"<QUEUE_NAME>"}}. > {code} > session.createQueue("testQueue") > --> "jms.queue.testQueue" (EAP 7.1 + Artemis 1.5, auto-create-jms-queue=true) > --> "testQueue" (Artemis 2.5, auto-create-queue=true) > {code} > This feature is not supported. > Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-84) [Artemis 2.x upgrade] MDB deployed on EAP 7.2.0 with new Artemis cannot connect to queue deployed on EAP6

by Martin Švehla (JIRA)

Martin Švehla created WFWIP-84: ---------------------------------- Summary: [Artemis 2.x upgrade] MDB deployed on EAP 7.2.0 with new Artemis cannot connect to queue deployed on EAP6 Key: WFWIP-84 URL: https://issues.jboss.org/browse/WFWIP-84 Project: WildFly WIP Issue Type: Bug Components: Artemis, JMS Reporter: Martin Švehla Assignee: Martyn Taylor Priority: Blocker I'm not able to connect with MDB deployed on WF14/EAP 7.2.0 with new Artemis to destination deployed on EAP6. CLI for configuration EAP7: {code} /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-eap6-binding:add(port=6445) /subsystem=messaging-activemq/server=default/remote-connector=remote-eap6-connector:add(socket-bidning=remote-eap6-binding) /subsystem=messaging-activemq/server=default/pooled-connection-factory=remote-eap6:add(connectors=[remote-eap6-connector], entries=["jms/remote-eap6", "java:jboss/exported/jms/remote-eap6"], protocol-manager-factory="org.apache.activemq.artemis.core.protocol.hornetq.client.HornetQClientProtocolManagerFactory) {code} The MDB is annotated with {code} @MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "InQueue"), @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") }) @ResourceAdapter("remote-eap6") {code} This setup worked with EAP 7.1.x and EAP 7.2.0.Beta with older Artemis -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10795) Non-Elytron SSL configuration won't establish secure channel between worker and balancer

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/WFLY-10795?page=com.atlassian.jira.plugin... ] Jan Kašík updated WFLY-10795: ----------------------------- Attachment: confs.zip > Non-Elytron SSL configuration won't establish secure channel between worker and balancer > ---------------------------------------------------------------------------------------- > > Key: WFLY-10795 > URL: https://issues.jboss.org/browse/WFLY-10795 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 14.0.0.CR1 > Environment: Latest snapshot from ci.wildfly.org > Reporter: Jan Kašík > Assignee: Radoslav Husar > Attachments: confs.zip > > > When running scenario, where connection between worker and balancer is secured with SSL, worker fails to register on balancer. > Worker obviously tries to send INFO commands, though it sends it as a 'plain text' to a secured channel. > I enabled SSL debugging, and such unsecured-secured communication causes this error: > {code} > 09:42:20,456 INFO [stdout] (default I/O-4) Using SSLEngineImpl. > 09:42:20,458 INFO [stdout] (default I/O-4) Allow unsafe renegotiation: false > 09:42:20,458 INFO [stdout] (default I/O-4) Allow legacy hello messages: true > 09:42:20,458 INFO [stdout] (default I/O-4) Is initial handshake: true > 09:42:20,459 INFO [stdout] (default I/O-4) Is secure renegotiation: false > 09:42:20,459 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1 > 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1 > 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1 > 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1 > 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1 > 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1 > 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1 > 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1 > 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1 > 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1 > 09:42:20,479 INFO [stdout] (default I/O-4) default I/O-4, fatal error: 80: problem unwrapping net record > 09:42:20,480 INFO [stdout] (default I/O-4) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? > 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, SEND TLSv1.2 ALERT: fatal, description = internal_error > 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, WRITE: TLSv1.2 Alert, length = 2 > 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeInbound() > 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? > 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeOutbound() > 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, closeOutboundInternal() > {code} > What bothers me, that there are no other errors (bad certificate, CLI error...) in log regarding this. Apart from: > {code} > 09:45:42,653 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t16) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 6 from wildfly-14.0.0.Beta2-SNAPSHOT-2 > at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167) > at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87) > at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > 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) > Suppressed: org.infinispan.util.logging.TraceException > at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75) > at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525) > at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321) > at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87) > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731) > at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175) > at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37) > at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47) > ... 1 more > {code} > Configuration using non-Elytron configuration was possible before, hence this is a regression. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2018