[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-6420 at 3/29/16 9:45 AM:
------------------------------------------------------------
The attached project has tests using both JMS 1.1 and JMS 2.0 API.
Tests pass regardless of the API that is used.
was (Author: jmesnil):
The attached project has tests using both JMS 1.1 and JMS 2.0 API.
Tests pass regardless the API that is used.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-6349) JMSXGroupId has no effect on JMSProducer
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6349?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-6349.
-------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Cannot Reproduce Bug
I have not been able to reproduce your issue with the latest WildFly master branch.
I modified the helloworld-mdb quickstart to set the JMSXGroupId (and Seq) on the producer and messages are received in the correct sequence by the same MDB:
{noformat}
15:27:51,765 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-97 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 1
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=0
15:27:51,770 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-106 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 2
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=1
15:27:51,771 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-110 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 3
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=2
15:27:51,784 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-122 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 4
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=3
15:27:51,785 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-129 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 5
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=4
{noformat}
For reference, I've pushed the modified quickstart on GitHub: https://github.com/jmesnil/quickstart/tree/WFLY-6349_JMSXGroupId (relevant code snippets are https://github.com/jmesnil/quickstart/blob/WFLY-6349_JMSXGroupId/hellowor... and https://github.com/jmesnil/quickstart/blob/WFLY-6349_JMSXGroupId/hellowor...)
> JMSXGroupId has no effect on JMSProducer
> ----------------------------------------
>
> Key: WFLY-6349
> URL: https://issues.jboss.org/browse/WFLY-6349
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Harald Wellmann
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
>
> h3. Scenario
> I'm setting the {{JMSXGroupID}} on a {{JMSProducer}} to achieve message delivery in the correct order. The consumer is a message-driven bean.
> {code}
> JMSProducer producer = context.createProducer();
> producer = producer.setProperty("JMSXGroupID", "sequential");
> producer = producer.setProperty("foo", "bar");
> for (int i = 0; i < 50; i++) {
> msgNumber++;
> String text = "This is message " + msgNumber;
> producer.send(queue, text);
> }
> {code}
> h3. Expected Behaviour
> The messages are received in the correct order, the properties {{JMSXGroupID}} and {{foo}} are set on the receiver side.
> h3. Actual Behaviour
> The messages are received in random order. Property {{foo}} is set, but property {{JMSXGroupID}} is null on the receiver side.
> h3. Workaround
> Create a {{TextMessage}} and set the properties on the message, not on the producer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Tomohisa igarashi (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Tomohisa igarashi commented on WFLY-6420:
-----------------------------------------
So your pom.xml has correct dependencies right? I tried my JMS 1.1 testcase *with your pom.xml* and it reproduces the issue.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6420:
-----------------------------------
Using BOM means that you use the correct version of Artemis, Netty, etc.
The client can use either JMS 1.1 or JMS 2.0 API, that's not important. The key thing is to use the correct client libraries.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Tomohisa igarashi (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Tomohisa igarashi commented on WFLY-6420:
-----------------------------------------
No, using BOM doesn't solve the issue, just using JMS 2.0 way of client code (JMSContext) could get around the issue like I said in my previous comment. [~jmesnil] do you mean WildFly10 doesn't support JMS 1.1 client code (Connection/Session)?
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-4866.
-------------------------------
Fix Version/s: 10.0.0.CR5
(was: 10.0.0.CR3)
Resolution: Done
Artemis underlying issue was fixed in Artemis 1.1.0.wildfly-009
> messaging-activemq: NPE when http-acceptor and https-acceptor configured
> ------------------------------------------------------------------------
>
> Key: WFLY-4866
> URL: https://issues.jboss.org/browse/WFLY-4866
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.1.0.Final, 10.0.0.CR2
> Environment: Windows 7 Pro, Java 7u55
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Labels: JMS, Messaging
> Fix For: 10.0.0.CR5
>
> Attachments: server-logs.zip
>
>
> With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log.
> I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped.
> Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException.
> I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method.
> The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal.
> The exception was:
> [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161)
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271)
> [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221)
> [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131)
> [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351)
> [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78)
> [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207)
> [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
> [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45)
> [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-102:
------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1299102|https://bugzilla.redhat.com/show_bug.cgi?id=1299102] from NEW to ASSIGNED
> Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-102
> URL: https://issues.jboss.org/browse/WFCORE-102
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha9
>
>
> The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so.
> To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-6420.
-------------------------------
Resolution: Rejected
Using wildfly jms client BOM to use the correct dependencies solve the issue.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-5796) Topic Subscriber does only get messages produced on node 2 after failover and failback of node 1
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5796?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-5796:
------------------------------
Summary: Topic Subscriber does only get messages produced on node 2 after failover and failback of node 1 (was: Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1)
> Topic Subscriber does only get messages produced on node 2 after failover and failback of node 1
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-5796
> URL: https://issues.jboss.org/browse/WFLY-5796
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Attachments: domain.xml, host.xml
>
>
> Client (Topic Subscriber) is connected to a 2 node symmetrical colocated life backup cluster receiving messages produced on any node (random).
> Observed behavior:
> When node 1 is shut down (failover to node 2). -> Client is automatically failing over to node 2 and is continuing to consume messages produced on node 2.
> Then node 1 is restarted (failback to node 1). From now on the client is only receiving messages produced on node 2, not messages produced on node 1.
> When node 2 is shut down (failover to node 1). -> Client is automatically failing over to node 1 and is continuing to consume messages produced on node 1.
> Then node 2 is restarted (failback to node 2). From now on the client is only receiving messages produced on node 1, not messages produced on node 2.
> Expected behavior:
> The client should at any time receive all messages regardless on which node the message is produced.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-5796) Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5796?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5796:
-----------------------------------
I wonder if this issue is caused by https://issues.apache.org/jira/browse/ARTEMIS-425 (like WFLY-5795).
Does the issue also occur if the notification address is commented out in the messaging-activemq subsystem configuration in domain.xml?
> Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-5796
> URL: https://issues.jboss.org/browse/WFLY-5796
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Attachments: domain.xml, host.xml
>
>
> Client (Topic Subscriber) is connected to a 2 node symmetrical colocated life backup cluster receiving messages produced on any node (random).
> Observed behavior:
> When node 1 is shut down (failover to node 2). -> Client is automatically failing over to node 2 and is continuing to consume messages produced on node 2.
> Then node 1 is restarted (failback to node 1). From now on the client is only receiving messages produced on node 2, not messages produced on node 1.
> When node 2 is shut down (failover to node 1). -> Client is automatically failing over to node 1 and is continuing to consume messages produced on node 1.
> Then node 2 is restarted (failback to node 2). From now on the client is only receiving messages produced on node 1, not messages produced on node 2.
> Expected behavior:
> The client should at any time receive all messages regardless on which node the message is produced.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month