[JBoss JIRA] (WFLY-11143) Message sent to JMSReplyTo from old client does not find correct binding
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11143?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-11143:
----------------------------------
Affects Version/s: 14.0.0.Final
> Message sent to JMSReplyTo from old client does not find correct binding
> ------------------------------------------------------------------------
>
> Key: WFLY-11143
> URL: https://issues.jboss.org/browse/WFLY-11143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Fix For: 15.0.0.Alpha1
>
>
> There is regression in backward compatibility of messaging client. JMSReplyTo destination set by older client contains incorrect address which causes that reply message does not have correct binding and such message is lost.
> Impact: Applications will stop work after upgrade to WF14/EAP 7.2.0.CD14.
> Test Scenario:
> * Start EAP 7.2.0.CD14/WF14 server (Artemis 2.x) with deployed InQueue and OutQueue
> * Send message to InQueue from older EAP 7.2.0.CD13/WF13/Artemis 1.5.5 client to InQueue. Message has JMSReplyTo header set to OutQueue. Client got "OutQueue" queue from JNDI lookup from EAP7.2.0.CD14/WF14
> * Deploy MDB to server
> ** MDB consumes message from InQueue and sends new message to destination defined in JMSReplyTo header (so to OutQueue)
> * Receive message from OutQueue
> Result:
> No message is received from OutQueue. There is debug message in server log:
> {code}
> 11:36:09,565 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@22848193)) Message CoreMessage[m
> essageID=214,durable=true,userID=c0de8bd0-cba6-11e8-840f-f496342f6705,priority=4, timestamp=Tue Oct 09 11:36:09 CEST 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=580,properties=TypedPropertie
> s[inMessageId=ID:c0383a39-cba6-11e8-95ad-f496342f6705,__AMQ_CID=c0d9349a-cba6-11e8-840f-f496342f6705,_AMQ_DUPL_ID=90d1e80e-116d-4eef-9513-84c6085549db,_AMQ_ROUTING_TYPE=0]]@1680840457 is not going anywhere as it
> didn't have a binding on address:jms.queue.OutQueue
> {code}
> which indicates that jms.queue.OutQueue address does not have a binding.
> The same happesn if older EAP/WF server (with Artemis 1.5.5x) is used and new EAP 7.2.0.CD14/WF14(Artemis 2.x) client is used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-10731) core-threads of ManagedScheduledExecutorService limits number of maximal threads
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFLY-10731?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek edited comment on WFLY-10731 at 11/7/18 7:59 AM:
---------------------------------------------------------------
[~gunterze] This is also fixed by PR. Now it returns:
{quote}"core-threads" => \{
"type" => INT,
"description" => "Provides the number of threads to keep in the executorâs pool, even if they are idle. A value of 0 means there is no limit.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min" => 0L,
"max" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},{quote}
I'll update PR because of bad symbols as a result of cli command
was (Author: jondruse):
[~gunterze] This is also fixed by PR. Now it returns:
{quote}"core-threads" => \{
"type" => INT,
"description" => "Provides the number of threads to keep in the executorâs pool, even if they are idle. A value of 0 means there is no limit.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min" => 0L,
"max" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},{quote}
> core-threads of ManagedScheduledExecutorService limits number of maximal threads
> --------------------------------------------------------------------------------
>
> Key: WFLY-10731
> URL: https://issues.jboss.org/browse/WFLY-10731
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 12.0.0.Final
> Reporter: gunter zeilinger
> Assignee: Jiri Ondrusek
> Priority: Major
>
> After changing the default configuration:
> {noformat}
> <managed-scheduled-executor-services>
> - <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
> + <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" long-running-tasks="true" core-threads="2" keepalive-time="3000"/>
> </managed-scheduled-executor-services>
> {noformat}
> only 2 (= value of core-threads) threads are used by the Scheduled Executer Service:
> {code:bash}
> $ grep ManagedScheduledExecutorService $WILDFLY/standalone/log/server.log | tail
> 2018-07-24 12:03:22,901 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,911 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,923 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,963 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,967 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,981 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,996 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,016 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:23,035 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,039 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> {code}
> I have not yet tested if the issue also effects Wildfly 13.0.0.Final ( cannot use Wildfly 13.0.0.Final because of WFLY-10531 )
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-10731) core-threads of ManagedScheduledExecutorService limits number of maximal threads
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFLY-10731?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek edited comment on WFLY-10731 at 11/7/18 7:58 AM:
---------------------------------------------------------------
[~gunterze] This is also fixed by PR. Now it returns:
{quote}"core-threads" => \{
"type" => INT,
"description" => "Provides the number of threads to keep in the executorâs pool, even if they are idle. A value of 0 means there is no limit.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min" => 0L,
"max" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},{quote}
was (Author: jondruse):
[~gunterze] This is also fixed by PR. Now it returns:
{quote}"core-threads" => {
"type" => INT,
"description" => "Provides the number of threads to keep in the executorâs pool, even if they are idle. A value of 0 means there is no limit.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min" => 0L,
"max" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},{quote}
> core-threads of ManagedScheduledExecutorService limits number of maximal threads
> --------------------------------------------------------------------------------
>
> Key: WFLY-10731
> URL: https://issues.jboss.org/browse/WFLY-10731
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 12.0.0.Final
> Reporter: gunter zeilinger
> Assignee: Jiri Ondrusek
> Priority: Major
>
> After changing the default configuration:
> {noformat}
> <managed-scheduled-executor-services>
> - <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
> + <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" long-running-tasks="true" core-threads="2" keepalive-time="3000"/>
> </managed-scheduled-executor-services>
> {noformat}
> only 2 (= value of core-threads) threads are used by the Scheduled Executer Service:
> {code:bash}
> $ grep ManagedScheduledExecutorService $WILDFLY/standalone/log/server.log | tail
> 2018-07-24 12:03:22,901 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,911 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,923 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,963 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,967 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,981 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,996 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,016 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:23,035 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,039 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> {code}
> I have not yet tested if the issue also effects Wildfly 13.0.0.Final ( cannot use Wildfly 13.0.0.Final because of WFLY-10531 )
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-10731) core-threads of ManagedScheduledExecutorService limits number of maximal threads
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFLY-10731?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek commented on WFLY-10731:
--------------------------------------
[~gunterze] This is also fixed by PR. Now it returns:
{quote}"core-threads" => {
"type" => INT,
"description" => "Provides the number of threads to keep in the executorâs pool, even if they are idle. A value of 0 means there is no limit.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min" => 0L,
"max" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},{quote}
> core-threads of ManagedScheduledExecutorService limits number of maximal threads
> --------------------------------------------------------------------------------
>
> Key: WFLY-10731
> URL: https://issues.jboss.org/browse/WFLY-10731
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 12.0.0.Final
> Reporter: gunter zeilinger
> Assignee: Jiri Ondrusek
> Priority: Major
>
> After changing the default configuration:
> {noformat}
> <managed-scheduled-executor-services>
> - <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
> + <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" long-running-tasks="true" core-threads="2" keepalive-time="3000"/>
> </managed-scheduled-executor-services>
> {noformat}
> only 2 (= value of core-threads) threads are used by the Scheduled Executer Service:
> {code:bash}
> $ grep ManagedScheduledExecutorService $WILDFLY/standalone/log/server.log | tail
> 2018-07-24 12:03:22,901 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,911 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,923 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,963 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,967 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,981 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,996 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,016 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:23,035 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,039 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> {code}
> I have not yet tested if the issue also effects Wildfly 13.0.0.Final ( cannot use Wildfly 13.0.0.Final because of WFLY-10531 )
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11029) Sometimes Artemis cluster with JGroups discovery is not formed after restart
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11029?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFLY-11029:
------------------------------
Priority: Critical (was: Blocker)
> Sometimes Artemis cluster with JGroups discovery is not formed after restart
> ----------------------------------------------------------------------------
>
> Key: WFLY-11029
> URL: https://issues.jboss.org/browse/WFLY-11029
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Critical
>
> There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
> Test scenario:
> * Start 2 server in Artemis cluster
> * Start 2 servers with MDB connected to Artemis cluster
> ** MDB resends messages from InQueue to OutQueue from/to remote cluster
> * Send messages to InQueue
> * Restart all server (one by one)
> * Consumes messages from OutQueue
> Results:
> After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11289) Artemis AMQP protocol requires proton-j...jar if SASL is used
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11289?page=com.atlassian.jira.plugin... ]
Miroslav Novak closed WFLY-11289.
---------------------------------
Resolution: Duplicate Issue
> Artemis AMQP protocol requires proton-j...jar if SASL is used
> -------------------------------------------------------------
>
> Key: WFLY-11289
> URL: https://issues.jboss.org/browse/WFLY-11289
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Reporter: Miroslav Novak
> Assignee: ehsavoie Hugonnet
> Priority: Major
>
> If AMQP client uses SASL authentication then connection fails with:
> {code}
> 2018-11-05 12:08:01,636 TRACE [org.jboss.modules] (Thread-1 (activemq-netty-threads)) Class org.apache.qpid.proton.engine.SaslListener not found from Module "org.apache.activemq.artemis.protocol.amqp" from local module loader @79b4d0f (finder: local module finder @6b2fad11 (roots: /apps/wildfly14.0/modules,/apps/wildfly14.0/modules/system/layers/base))
> 2018-11-05 12:08:01,636 WARN [org.jboss.modules.define] (Thread-1 (activemq-netty-threads)) Failed to define class org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler in Module "org.apache.activemq.artemis.protocol.amqp" from local module loader @79b4d0f (finder: local module finder @6b2fad11 (roots: /apps/wildfly14.0/modules,/apps/wildfly14.0/modules/system/layers/base)): java.lang.NoClassDefFoundError: Failed to link org/apache/activemq/artemis/protocol/amqp/proton/handler/ProtonHandler (Module "org.apache.activemq.artemis.protocol.amqp" from local module loader @79b4d0f (finder: local module finder @6b2fad11 (roots: /apps/wildfly14.0/modules,/apps/wildfly14.0/modules/system/layers/base))): org/apache/qpid/proton/engine/SaslListener
> {code}
> It requires proton-j-0.27.3.jar to be added to org.apache.activemq.artemis.protocol.amqp module. It appears to missing and should be added.
> See: https://developer.jboss.org/message/986253 for more information.
> Credit for finding this problem goes to [~ninjasftw]
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFCORE-4199) jconsole can't connect to jboss CLI process
by Jean-Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFCORE-4199?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-4199:
-----------------------------------------
Description:
Due to JBTHR-61 that is masked by a JDK bug (just logged no ID yet), as soon as CLI is connected to a server, jconsole can't connect to it. There is an invalid ObjectName registered in the MBeanServer that breaks at deserialization time.
was:
Due to JBTHR-61 that his masked by a JDK bug (just logged no ID yet), as soon as CLI is connected to a server, jconsole can't connect to it. There is an invalid ObjectName registered in the MBeanServer that breaks at deserialization time.
> jconsole can't connect to jboss CLI process
> -------------------------------------------
>
> Key: WFCORE-4199
> URL: https://issues.jboss.org/browse/WFCORE-4199
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.0.0.Alpha4
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Critical
>
> Due to JBTHR-61 that is masked by a JDK bug (just logged no ID yet), as soon as CLI is connected to a server, jconsole can't connect to it. There is an invalid ObjectName registered in the MBeanServer that breaks at deserialization time.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11143) Message sent to JMSReplyTo from old client does not find correct binding
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11143?page=com.atlassian.jira.plugin... ]
Miroslav Novak reopened WFLY-11143:
-----------------------------------
> Message sent to JMSReplyTo from old client does not find correct binding
> ------------------------------------------------------------------------
>
> Key: WFLY-11143
> URL: https://issues.jboss.org/browse/WFLY-11143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Fix For: 15.0.0.Alpha1
>
>
> There is regression in backward compatibility of messaging client. JMSReplyTo destination set by older client contains incorrect address which causes that reply message does not have correct binding and such message is lost.
> Impact: Applications will stop work after upgrade to WF14/EAP 7.2.0.CD14.
> Test Scenario:
> * Start EAP 7.2.0.CD14/WF14 server (Artemis 2.x) with deployed InQueue and OutQueue
> * Send message to InQueue from older EAP 7.2.0.CD13/WF13/Artemis 1.5.5 client to InQueue. Message has JMSReplyTo header set to OutQueue. Client got "OutQueue" queue from JNDI lookup from EAP7.2.0.CD14/WF14
> * Deploy MDB to server
> ** MDB consumes message from InQueue and sends new message to destination defined in JMSReplyTo header (so to OutQueue)
> * Receive message from OutQueue
> Result:
> No message is received from OutQueue. There is debug message in server log:
> {code}
> 11:36:09,565 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@22848193)) Message CoreMessage[m
> essageID=214,durable=true,userID=c0de8bd0-cba6-11e8-840f-f496342f6705,priority=4, timestamp=Tue Oct 09 11:36:09 CEST 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=580,properties=TypedPropertie
> s[inMessageId=ID:c0383a39-cba6-11e8-95ad-f496342f6705,__AMQ_CID=c0d9349a-cba6-11e8-840f-f496342f6705,_AMQ_DUPL_ID=90d1e80e-116d-4eef-9513-84c6085549db,_AMQ_ROUTING_TYPE=0]]@1680840457 is not going anywhere as it
> didn't have a binding on address:jms.queue.OutQueue
> {code}
> which indicates that jms.queue.OutQueue address does not have a binding.
> The same happesn if older EAP/WF server (with Artemis 1.5.5x) is used and new EAP 7.2.0.CD14/WF14(Artemis 2.x) client is used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months