[JBoss JIRA] (WFLY-10002) Incorrect number of messages on queue after remove of scheduled message
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10002?page=com.atlassian.jira.plugin... ]
Jeff Mesnil reassigned WFLY-10002:
----------------------------------
Assignee: Jeff Mesnil (was: Martyn Taylor)
> Incorrect number of messages on queue after remove of scheduled message
> -----------------------------------------------------------------------
>
> Key: WFLY-10002
> URL: https://issues.jboss.org/browse/WFLY-10002
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Labels: feature-branch-blocker
>
> Removing scheduled message from queue cause incorrect number of messages reported by {{count-messages}} operation.
> It looks like the operation {{count-messages}} returns value equal to _actual number of messages_ minus _number of removed scheduled messages_
> *Scenario*
> # send 1 message with _AMQ_SCHED_DELIVERY property set to several minutes
> # remove scheduled emssage using CLI operation {{remove-message}}
> # find out number of messages on queue using CLI operation {{count-messages}} - it returns value -1
> This is broker related issue. It is regression against Artemis 1.5.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10045) [Artemis 2.x Upgrade] MDB doesn't find its source queue when useJndi property is set to false
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10045?page=com.atlassian.jira.plugin... ]
Martyn Taylor reassigned WFLY-10045:
------------------------------------
Assignee: Martyn Taylor (was: Jeff Mesnil)
> [Artemis 2.x Upgrade] MDB doesn't find its source queue when useJndi property is set to false
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10045
> URL: https://issues.jboss.org/browse/WFLY-10045
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Having a MDB configured as follows:
> {code}
> @MessageDriven(name = "mdb",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(propertyName = "destination", propertyValue ="InQueue"),
> @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"),
> })
> {code}
> MDB is not able to receive messages from InQueue.
> Server logs:
> {noformat}
> 09:53:29,128 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:29,188 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "Mdb.jar" (runtime-name : "Mdb.jar")
> 09:53:29,306 INFO [org.wildfly.naming] (default task-1) WildFly Naming version 1.0.7.Final
> 09:53:29,364 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151000: awaiting topic/queue creation jms/queue/InQueue
> 09:53:31,366 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151001: Attempting to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@2bd07716 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)
> 09:53:31,368 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:33,480 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:35,092 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout.
> {noformat}
> In {{ActiveMQActivation.setup()}}, call to {{setupDestination()}} is made. Destiantion InQueue is instantiated there. However, during the {{ActiveMQMessageHandler.setup()}} call. consumer can not be created for this destination and exception {{AMQ119017: Queue InQueue does not exist}} is being thrown.
> {code:title=ActiveMQActivation.setup()}
> protected synchronized void setup() throws Exception {
> logger.debug("Setting up " + spec);
> setupCF();
> setupDestination();
> Exception firstException = null;
> for (int i = 0; i < spec.getMaxSession(); i++) {
> ClientSessionFactory cf = null;
> ClientSession session = null;
> try {
> cf = factory.getServerLocator().createSessionFactory();
> session = setupSession(cf);
> ActiveMQMessageHandler handler = new ActiveMQMessageHandler(factory, this, ra.getTM(), (ClientSessionInternal) session, cf, i);
> handler.setup();
> handlers.add(handler);
> } catch (Exception e) {
> ...
> }
> }
> ...
> }
> {code}
> This is regression against Artemis 1.5.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstream master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10054) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10054?page=com.atlassian.jira.plugin... ]
Martyn Taylor commented on WFLY-10054:
--------------------------------------
[~jmesnil] [~mnovak] As discussed on the call, we need to verify whether the ActiveMQ classes are supported API.
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFLY-10054
> URL: https://issues.jboss.org/browse/WFLY-10054
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> 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)
8 years, 3 months
[JBoss JIRA] (WFLY-10043) [Artemis 2.x Upgrade] Last value queues do not work
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFLY-10043?page=com.atlassian.jira.plugin... ]
Clebert Suconic commented on WFLY-10043:
----------------------------------------
The issue is on the counter? or actually receiving messages?
> [Artemis 2.x Upgrade] Last value queues do not work
> ---------------------------------------------------
>
> Key: WFLY-10043
> URL: https://issues.jboss.org/browse/WFLY-10043
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Last value queues are not working as expected.
> # Set {{last-value-queue="true"}} for an address settings {{#}}
> # Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
> # Receiver receives 10 messages. (it is expected to receive the single message)
> This looks like broker related regression against Artemis 1.5.
> Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10054) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10054?page=com.atlassian.jira.plugin... ]
Martyn Taylor closed WFLY-10054.
--------------------------------
Resolution: Duplicate Issue
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFLY-10054
> URL: https://issues.jboss.org/browse/WFLY-10054
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> 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)
8 years, 3 months
[JBoss JIRA] (WFLY-10067) [Artemis 2.x Upgrade] Failover does not work with HTTP conncetors/acceptors
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10067?page=com.atlassian.jira.plugin... ]
Martyn Taylor reassigned WFLY-10067:
------------------------------------
Assignee: Jeff Mesnil (was: Martyn Taylor)
> [Artemis 2.x Upgrade] Failover does not work with HTTP conncetors/acceptors
> ---------------------------------------------------------------------------
>
> Key: WFLY-10067
> URL: https://issues.jboss.org/browse/WFLY-10067
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: clients.log, server1.log, server2.log, test.log
>
>
> Failover does not work with HTTP connectors/acceptors.
> *Scenario:*
> # There are two Wildfly servers configured as Live-Backup pair
> # There is one JMS producer and one JMS receiver which sends/receives messages
> # Live server is several times killed and restarted.
> *Expectation:* Always when the Live server is killed or restarted, clients do failover or failback.
> *Reality*: Sometimes happens that clients don't do failover.
> *Users impact:* One of basics feature of HA, failover, does not work properly.
> *Blocker* priority was set because this is regression against previous releases of Wildfly.
> *Detail description of issue*
> In the trace logs it can be seen that clients send HTTP handshake request to active backup, but the handshake fails. All checks (and logs) say that the backup is active in this time period. I tried to run the test with Netty connectors/acceptors and I didn't see this issue.
> {code:title=Backup log}
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=55, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=56, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485068, b=2147485067]
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485076, b=2147485075]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484450, b=2147484449]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485072, b=2147485071]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484454, b=2147484453]
> 07:52:47,866 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=0dee81c9-2d9d-11e8-ba3f-cc3d825f79a4
> 07:52:47,867 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221007: Server is now live
> {code}
> {code:title=Clients log}
> 07:52:49,274 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,274 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:447] Connector NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] using native epoll
> 07:52:49,275 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: QWV3bCfgh75NjWH3pZV5Ew==
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:601] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to localhost:9080
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,276 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: P9xBwRk1eZP5QjDWjqYuIg==
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,277 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10075) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFLY-10075?page=com.atlassian.jira.plugin... ]
Clebert Suconic commented on WFLY-10075:
----------------------------------------
This could been fixed after ARTEMIS-1776
There are two commits as part of the fix:
70bdfe760393a9d7d17ec175ea68ce83819fe83c
e5bce13316f7e81bb15a12592622df2ea2632a35
Perhaps you could check a snapshot from upstream?
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10075
> URL: https://issues.jboss.org/browse/WFLY-10075
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10068) [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10068?page=com.atlassian.jira.plugin... ]
Martyn Taylor commented on WFLY-10068:
--------------------------------------
Fixed upstream please restest.
> [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10068
> URL: https://issues.jboss.org/browse/WFLY-10068
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: standalone-full-ha.xml
>
>
> If Artemis is not configured to use HA then it should not create and use journal-node-manager-store-table table which is normally used by live/backup pair.
> Problem here is that especially if 2 servers are started and are using the database then administrator logically does not set journal-node-manager-store-table as HA is not used. However in the moment when both of the servers are started they use default values and both of them start to use the same table (default is NODE_MANAGER) then one of them fail with:
> {code}
> 09:20:03,246 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ221034: Waiting 60000 milliseconds to obtain live lock
> 09:21:03,517 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ224000: Failure in initialisation: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> 09:21:03,520 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 74) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: java.lang.Exception: timed out waiting for lock
> at org.wildfly.extension.messaging.activemq.jms.JMSService.lambda$doStart$0(JMSService.java:141) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivationFailureListeners(ActiveMQServerImpl.java:1908) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:82) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> Caused by: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10075) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10075?page=com.atlassian.jira.plugin... ]
Martyn Taylor commented on WFLY-10075:
--------------------------------------
[[~mnovak] We believe this is now fixed on Artemis master, commit to follow. Please retest.
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10075
> URL: https://issues.jboss.org/browse/WFLY-10075
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10075) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10075?page=com.atlassian.jira.plugin... ]
Martyn Taylor reassigned WFLY-10075:
------------------------------------
Assignee: Martyn Taylor (was: Jeff Mesnil)
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10075
> URL: https://issues.jboss.org/browse/WFLY-10075
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months