[jira] [Resolved] (AMQ-5841) activemq script returns a non zero exit code for successful operations
[ https://issues.apache.org/jira/browse/AMQ-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac resolved AMQ-5841. Resolution: Fixed Fixed with http://git-wip-us.apache.org/repos/asf/activemq/commit/e2221e31 activemq script returns a non zero exit code for successful operations -- Key: AMQ-5841 URL: https://issues.apache.org/jira/browse/AMQ-5841 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.11.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.12.0 By default operations return 1 when broker is not running. That's not necessary for many script operations like create, encrypt, etc. We should always rely on what the actual task returns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5840) activemq-osgi should include activemq-blueprint
[ https://issues.apache.org/jira/browse/AMQ-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Heide updated AMQ-5840: -- Attachment: activemq-osgi-should-include-activemq-blueprint.patch activemq-osgi should include activemq-blueprint --- Key: AMQ-5840 URL: https://issues.apache.org/jira/browse/AMQ-5840 Project: ActiveMQ Issue Type: Bug Components: OSGi/Karaf Affects Versions: 5.11.1 Environment: Equinox Container 3.10.1 with Apache Aries 1.0.0 Reporter: Tobias Heide Attachments: activemq-osgi-should-include-activemq-blueprint.patch The bundle activemq-osgi does not include the contents of activemq-blueprint because this dependency is not declared in the pom.xml. This causes the namespace handlers to be missing in the blueprint container. Adding the activemq-blueprint bundle separately fails because the schema files are not present in this bundle. Suggested solution: add a dependency to the pom.xml of activemq-osgi that refers to activemq-blueprint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5840) activemq-osgi should include activemq-blueprint
Tobias Heide created AMQ-5840: - Summary: activemq-osgi should include activemq-blueprint Key: AMQ-5840 URL: https://issues.apache.org/jira/browse/AMQ-5840 Project: ActiveMQ Issue Type: Bug Components: OSGi/Karaf Affects Versions: 5.11.1 Environment: Equinox Container 3.10.1 with Apache Aries 1.0.0 Reporter: Tobias Heide The bundle activemq-osgi does not include the contents of activemq-blueprint because this dependency is not declared in the pom.xml. This causes the namespace handlers to be missing in the blueprint container. Adding the activemq-blueprint bundle separately fails because the schema files are not present in this bundle. Suggested solution: add a dependency to the pom.xml of activemq-osgi that refers to activemq-blueprint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQCPP-571) Unacknowledged messages dissappear from broker if session/consumer is closed and then re-created
Mark Williams created AMQCPP-571: Summary: Unacknowledged messages dissappear from broker if session/consumer is closed and then re-created Key: AMQCPP-571 URL: https://issues.apache.org/jira/browse/AMQCPP-571 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 3.8.4 Environment: Linux, 64 bit Reporter: Mark Williams Assignee: Timothy Bish Unacknowledged messages dissappear from broker if session is stopped and restarted and/or if the consumer object is deleted and re-created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQCPP-571) Unacknowledged messages dissappear from broker if session/consumer is closed and then re-created
[ https://issues.apache.org/jira/browse/AMQCPP-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Williams updated AMQCPP-571: - Attachment: (was: LostMessages.cpp) Unacknowledged messages dissappear from broker if session/consumer is closed and then re-created Key: AMQCPP-571 URL: https://issues.apache.org/jira/browse/AMQCPP-571 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 3.8.4 Environment: Linux, 64 bit Reporter: Mark Williams Assignee: Timothy Bish Attachments: LostMessages.cpp, LostMessages.h Unacknowledged messages dissappear from broker if session is stopped and restarted and/or if the consumer object is deleted and re-created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQCPP-571) Unacknowledged messages dissappear from broker if session/consumer is closed and then re-created
[ https://issues.apache.org/jira/browse/AMQCPP-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Williams updated AMQCPP-571: - Attachment: LostMessages.h Unacknowledged messages dissappear from broker if session/consumer is closed and then re-created Key: AMQCPP-571 URL: https://issues.apache.org/jira/browse/AMQCPP-571 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 3.8.4 Environment: Linux, 64 bit Reporter: Mark Williams Assignee: Timothy Bish Attachments: LostMessages.cpp, LostMessages.h Unacknowledged messages dissappear from broker if session is stopped and restarted and/or if the consumer object is deleted and re-created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5842) activemq script doesn't work on solaris because of su command
Thomas RICOU created AMQ-5842: - Summary: activemq script doesn't work on solaris because of su command Key: AMQ-5842 URL: https://issues.apache.org/jira/browse/AMQ-5842 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.1 Environment: Solaris 11.1 (SPARC) Activemq 5.11.1 installed from tar.gz Reporter: Thomas RICOU Priority: Trivial I installed activemq from archive and wished to run the broker using a specific user but I was having a problem with the su command lines 134 : su -c mkdir $ACTIVEMQ_DATA - $ACTIVEMQ_USER; and 294/295 : su -s /bin/sh -c ... - $ACTIVEMQ_USER Actually, the su command is used to Switch User whereas the intended task here is to execute a commad as another user. In my opinion, the need and the command goal don't match. Moreover, the sudo command matches better : Switch User DO. And on my platform, the su command doesn't support the -c parameter and only permits to change the current user before typing other commands. So I would use the sudo command like that : - line 134 : sudo -u $ACTIVEMQ_USER mkdir $ACTIVEMQ_DATA - line 294 : DOIT_PREFIX=sudo -u $ACTIVEMQ_USER /bin/sh -c And I would also remove the DOIT_POSTFIX variable : - to leave the 295th line empty - to adjust lines 310, 323 and 333 without $DOIT_POSTFIX -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMQ-5842) activemq script doesn't work on solaris because of su command
[ https://issues.apache.org/jira/browse/AMQ-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned AMQ-5842: - Assignee: Jean-Baptiste Onofré activemq script doesn't work on solaris because of su command --- Key: AMQ-5842 URL: https://issues.apache.org/jira/browse/AMQ-5842 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.1 Environment: Solaris 11.1 (SPARC) Activemq 5.11.1 installed from tar.gz Reporter: Thomas RICOU Assignee: Jean-Baptiste Onofré Priority: Trivial Labels: easyfix, script, solaris Original Estimate: 1h Remaining Estimate: 1h I installed activemq from archive and wished to run the broker using a specific user but I was having a problem with the su command lines 134 : su -c mkdir $ACTIVEMQ_DATA - $ACTIVEMQ_USER; and 294/295 : su -s /bin/sh -c ... - $ACTIVEMQ_USER Actually, the su command is used to Switch User whereas the intended task here is to execute a commad as another user. In my opinion, the need and the command goal don't match. Moreover, the sudo command matches better : Switch User DO. And on my platform, the su command doesn't support the -c parameter and only permits to change the current user before typing other commands. So I would use the sudo command like that : - line 134 : sudo -u $ACTIVEMQ_USER mkdir $ACTIVEMQ_DATA - line 294 : DOIT_PREFIX=sudo -u $ACTIVEMQ_USER /bin/sh -c And I would also remove the DOIT_POSTFIX variable : - to leave the 295th line empty - to adjust lines 310, 323 and 333 without $DOIT_POSTFIX -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5770) activemq-web-console feature doesn't install in Karaf 4 SNAPSHOT
[
https://issues.apache.org/jira/browse/AMQ-5770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-5770:
--
Fix Version/s: 5.12.0
5.11.2
activemq-web-console feature doesn't install in Karaf 4 SNAPSHOT
Key: AMQ-5770
URL: https://issues.apache.org/jira/browse/AMQ-5770
Project: ActiveMQ
Issue Type: Bug
Components: webconsole
Affects Versions: 5.11.1, 5.12.0
Reporter: Bernhard Schuhmann
Assignee: Jean-Baptiste Onofré
Priority: Minor
Fix For: 5.11.2, 5.12.0
Attachments: AMQ-5770.patch
{{feature:install activemq-web-console}} fails with
{noformat}
Error executing command: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=activemq-web-console; type=ka
raf.feature; version=[5.12.0.SNAPSHOT,5.12.0.SNAPSHOT];
filter:=((osgi.identity=activemq-web-console)(type=karaf.feature)(version
=5.12.0.SNAPSHOT)(version=5.12.0.SNAPSHOT)) [caused by: Unable to resolve
activemq-web-console/5.12.0.SNAPSHOT: missing requirement
[activemq-web-console/5.12.0.SNAPSHOT] osgi.identity;
osgi.identity=org.apache.activemq.activemq-web-console; type=osgi.bundle;
versio
n=[5.12.0.SNAPSHOT,5.12.0.SNAPSHOT]; resolution:=mandatory [caused by:
Unable to resolve org.apache.activemq.activemq-web-console/5.
12.0.SNAPSHOT: missing requirement
[org.apache.activemq.activemq-web-console/5.12.0.SNAPSHOT]
osgi.wiring.package; filter:=((osgi.wi
ring.package=javax.servlet.resources)(version=2.5.0)(!(version=4.0.0)))]]
{noformat}
As this package seems not to be used in the web console, an it not be
removed? I've tested locally with this change
{noformat}
diff --git a/activemq-web-console/pom.xml b/activemq-web-console/pom.xml
index 1f1e641..4bdbe51 100755
--- a/activemq-web-console/pom.xml
+++ b/activemq-web-console/pom.xml
@@ -142,7 +142,6 @@
org.w3c.dom,
javax.servlet;version=[2.5,4),
javax.servlet.http;version=[2.5,4),
- javax.servlet.resources;version=[2.5,4),
javax.servlet.jsp,
javax.servlet.jsp.tagext,
javax.servlet.jsp.el,
{noformat}
And web console works if ActiveMQ is started standalone and deployed into
Karaf 4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5770) activemq-web-console feature doesn't install in Karaf 4 SNAPSHOT
[
https://issues.apache.org/jira/browse/AMQ-5770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-5770:
--
Affects Version/s: 5.11.1
activemq-web-console feature doesn't install in Karaf 4 SNAPSHOT
Key: AMQ-5770
URL: https://issues.apache.org/jira/browse/AMQ-5770
Project: ActiveMQ
Issue Type: Bug
Components: webconsole
Affects Versions: 5.11.1, 5.12.0
Reporter: Bernhard Schuhmann
Assignee: Jean-Baptiste Onofré
Priority: Minor
Fix For: 5.11.2, 5.12.0
Attachments: AMQ-5770.patch
{{feature:install activemq-web-console}} fails with
{noformat}
Error executing command: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=activemq-web-console; type=ka
raf.feature; version=[5.12.0.SNAPSHOT,5.12.0.SNAPSHOT];
filter:=((osgi.identity=activemq-web-console)(type=karaf.feature)(version
=5.12.0.SNAPSHOT)(version=5.12.0.SNAPSHOT)) [caused by: Unable to resolve
activemq-web-console/5.12.0.SNAPSHOT: missing requirement
[activemq-web-console/5.12.0.SNAPSHOT] osgi.identity;
osgi.identity=org.apache.activemq.activemq-web-console; type=osgi.bundle;
versio
n=[5.12.0.SNAPSHOT,5.12.0.SNAPSHOT]; resolution:=mandatory [caused by:
Unable to resolve org.apache.activemq.activemq-web-console/5.
12.0.SNAPSHOT: missing requirement
[org.apache.activemq.activemq-web-console/5.12.0.SNAPSHOT]
osgi.wiring.package; filter:=((osgi.wi
ring.package=javax.servlet.resources)(version=2.5.0)(!(version=4.0.0)))]]
{noformat}
As this package seems not to be used in the web console, an it not be
removed? I've tested locally with this change
{noformat}
diff --git a/activemq-web-console/pom.xml b/activemq-web-console/pom.xml
index 1f1e641..4bdbe51 100755
--- a/activemq-web-console/pom.xml
+++ b/activemq-web-console/pom.xml
@@ -142,7 +142,6 @@
org.w3c.dom,
javax.servlet;version=[2.5,4),
javax.servlet.http;version=[2.5,4),
- javax.servlet.resources;version=[2.5,4),
javax.servlet.jsp,
javax.servlet.jsp.tagext,
javax.servlet.jsp.el,
{noformat}
And web console works if ActiveMQ is started standalone and deployed into
Karaf 4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (AMQ-5736) JMS 2.0 Support
[ https://issues.apache.org/jira/browse/AMQ-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich closed AMQ-5736. --- Resolution: Duplicate I'm good, looks like the dup issue has this covered. Thanks! JMS 2.0 Support --- Key: AMQ-5736 URL: https://issues.apache.org/jira/browse/AMQ-5736 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.11.1 Reporter: Matt Pavlovich Expand broker support to include JMS 2.0. The biggest impacts are going to be the client side changes to support the simplified API (It looks like AMQ-5383 covers that), and the ability to share subscriptions across multiple clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5846) High cpu usage if using masterslave discovery in network brokers
duff qiu created AMQ-5846: - Summary: High cpu usage if using masterslave discovery in network brokers Key: AMQ-5846 URL: https://issues.apache.org/jira/browse/AMQ-5846 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.1 Reporter: duff qiu I setup a network brokers with 2 nodes (A, and B) In the config, the A and B use masterslave discovery. If I start A first, and then start B, I found that the cpu usaging in the machine running A is very high (~100). But The B doens't like that because B can connect to A at the first time. I try to use the static:failover way, then the problem is the same (static:failover:()?randomize=falsemaxReconnectAttempts=0) But I try to remove the maxReconnectAttempts=0' or set the value more than 10 , the issue disapeared. I think there are some issues on the network transfer impl how to handle the maxReconnectAttempts -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-123) Import ActiveMQ OpenWire test framework
[ https://issues.apache.org/jira/browse/ARTEMIS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586320#comment-14586320 ] Justin Bertram commented on ARTEMIS-123: This looks like a duplicate of ARTEMIS-122. If so, please close. If not, please clarify the differentiation. Import ActiveMQ OpenWire test framework --- Key: ARTEMIS-123 URL: https://issues.apache.org/jira/browse/ARTEMIS-123 Project: ActiveMQ Artemis Issue Type: Task Components: OpenWire Reporter: Andy Taylor Assignee: Howard Gao Fix For: 1.0.1 We should any ActiveMQ tests so we can test what is currently missing from the OpenWire support. From this we should raise Jiras and prioritize what we need to fix. I think it makes sense to make any new Jiras sub tasks of this Jira so we can keep track easily -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5843) Add an option to include original message body for advisory messages
[ https://issues.apache.org/jira/browse/AMQ-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-5843: Summary: Add an option to include original message body for advisory messages (was: Add option to include original message body for Advisory messages) Add an option to include original message body for advisory messages Key: AMQ-5843 URL: https://issues.apache.org/jira/browse/AMQ-5843 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.11.1 Reporter: Christopher L. Shannon Currently some advisory messages such as messageConsumed or messageDelivered advisories contain a copy of the original message set as the dataStructure, but the message body is missing because it has been cleared out. This is fine most of the time but it would be nice to be have the ability to optionally include the original message body of messages. This should be off by default because of the performance hit, but sometimes I want to have the option to receive the message body content (ie the entire message) on the advisory topic for auditing purposes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5843) Add option to include original message body for Advisory messages
[ https://issues.apache.org/jira/browse/AMQ-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586384#comment-14586384 ] ASF GitHub Bot commented on AMQ-5843: - GitHub user cshannon opened a pull request: https://github.com/apache/activemq/pull/115 https://issues.apache.org/jira/browse/AMQ-5843 Adding a new property on PolicyEntry called includeBodyForAdvisory which will include the original message body when sending advisory messages that include the original message, instead of clearing it out. This is turned off by default. You can merge this pull request into a Git repository by running: $ git pull https://github.com/cshannon/activemq AMQ-5843 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/115.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #115 commit 267b8e6ce438ee119f7aee5294dee669db867362 Author: Christopher L. Shannon (cshannon) christopher.l.shan...@gmail.com Date: 2015-06-15T17:38:49Z https://issues.apache.org/jira/browse/AMQ-5843 Adding a new property on PolicyEntry called includeBodyForAdvisory which will include the original message body when sending advisory messages that include the original message, instead of clearing it out. This is turned off by default. Add option to include original message body for Advisory messages - Key: AMQ-5843 URL: https://issues.apache.org/jira/browse/AMQ-5843 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.11.1 Reporter: Christopher L. Shannon Currently some advisory messages such as messageConsumed or messageDelivered advisories contain a copy of the original message set as the dataStructure, but the message body is missing because it has been cleared out. This is fine most of the time but it would be nice to be have the ability to optionally include the original message body of messages. This should be off by default because of the performance hit, but sometimes I want to have the option to receive the message body content (ie the entire message) on the advisory topic for auditing purposes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-136) XA should send FAIL instead of ERR in case of any communication issues
[ https://issues.apache.org/jira/browse/ARTEMIS-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-136: Affects Version/s: 1.0.0 This also affects all versions of HornetQ. And from some inspection I had on the codebase it also affects ActiveMQ5. XA should send FAIL instead of ERR in case of any communication issues -- Key: ARTEMIS-136 URL: https://issues.apache.org/jira/browse/ARTEMIS-136 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.0.0 Reporter: clebert suconic Assignee: clebert suconic Fix For: 1.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-136) XA should send FAIL instead of ERR in case of any communication issues
[ https://issues.apache.org/jira/browse/ARTEMIS-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586644#comment-14586644 ] ASF GitHub Bot commented on ARTEMIS-136: GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/28 ARTEMIS-136 - XA Error fix with proper exception error https://issues.apache.org/jira/browse/ARTEMIS-136 From what I researched from implementers of XA TM if you throw ERR over communication errors the transaction manager will create an heuristic transaction to be manually dealt with. Other XA Implementations (such as Oracle JDBC) are return FAIL over communication failures during any XA operation. You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/28.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #28 commit f883ce925df31508d0a698aa1662cbde5820d885 Author: Clebert Suconic clebertsuco...@apache.org Date: 2015-06-15T20:27:54Z ARTEMIS-136 - XA Error fix with proper exception error https://issues.apache.org/jira/browse/ARTEMIS-136 From what I researched from implementers of XA TM if you throw ERR over communication errors the transaction manager will create an heuristic transaction to be manually dealt with. Other XA Implementations (such as Oracle JDBC) are return FAIL over communication failures during any XA operation. XA should send FAIL instead of ERR in case of any communication issues -- Key: ARTEMIS-136 URL: https://issues.apache.org/jira/browse/ARTEMIS-136 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.0.0 Reporter: clebert suconic Assignee: clebert suconic Fix For: 1.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-90) ClassNotFoundException when a backup server fails over after having failed back
[
https://issues.apache.org/jira/browse/ARTEMIS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586622#comment-14586622
]
Justin Bertram edited comment on ARTEMIS-90 at 6/15/15 8:31 PM:
[~jmesnil], what if I added a new getter/setting on
org.apache.activemq.artemis.core.server.ServiceRegistry for the appropriate
java.lang.ClassLoader instance to be used when creating this thread? I looked
at using the injected ExecutorService, but it isn't initialized at the point
this thread is created and moving the pool initialization from
ActiveMQServerImpl.initialisePart1() led to other problems so it looks like it
will be simpler (although not as elegant) to manually set the TCCL. What are
your thoughts?
was (Author: jbertram):
[~jmesnil], what if I added a new getter/setting on
org.apache.activemq.artemis.core.server.ServiceRegistry for the appropriate
java.lang.ClassLoader instance to be used when creating this thread? I looked
at using the injected ExecutorService, but it isn't initialized at the point
this thread is creating and moving the pool initialization from
ActiveMQServerImpl.initialisePart1() led to other problems so it looks like it
will be simpler (although not as elegant) to manually set the TCCL. What are
your thoughts?
ClassNotFoundException when a backup server fails over after having failed
back
---
Key: ARTEMIS-90
URL: https://issues.apache.org/jira/browse/ARTEMIS-90
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
Fix For: 1.0.1
I'm integrating ActiveMQ 6 in WildFly and testing out its failover features.
My use case is:
2 servers:
* server #1 with replicated master HA (check-for-live-serve=true)
* server #2 with replicated slave HA (restart-backup=true)
* both servers are started
= #1 is master
= #2 announces it is a backup
* server #1 is stopped
= #2 fails over and becomes live
* server #1 is restarted
= #2 detects the live is up again and fails back
* server #1 is stopped again
= I was expecting server #2 to becomes live again but instead, I got the
following exception:
{noformat}
16:27:07,528 WARN [org.apache.activemq.core.server] (AMQ119000: Activation
for server ActiveMQServerImpl::serverUUID=null) AMQ222080: Error
instantiating remoting acceptor
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory:
java.lang.ClassNotFoundException:
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory from
[Module org.wildfly.extension.io:main from local module loader @6e32bb55
(finder: local module finder @44a901f8 (roots:
/Users/jmesnil/Developer/wildfly/dist/target/slave/modules,/Users/jmesnil/Developer/wildfly/dist/target/slave/modules/system/layers/base))]
at
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:216)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
at
org.apache.activemq.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:235)
at
org.apache.activemq.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1778)
at
org.apache.activemq.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:280)
at java.lang.Thread.run(Thread.java:744)
{noformat}
The CFNE occurs because WildFly uses a modular class loader.
The SharedNothingBackupActivation runnable is run by creating a new
backupActivationThread (ActiveMQServerImpl.java:425).
In a modular environment this thread's module has not knowledge of the
NettyAcceptorFactory class.
To prevent this CFNE, this thread should use the TCCL before loading the
acceptor factory from its class names.
Additionally, I'm not sure it's a good idea to create new Thread like this.
ActiveMQ has a threadPool executorService that could be used to run such
code. Since ActiveMQ supports injection of this threadPool (through the
serviceRegistry), WildFly could ensure that any code run by this thread pool
will be using the correct module class loader.
Is there a good reason to use a separate thread for the backup activation?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5844) Introduce logic into the failover transport not to recreate aborted slow consumers.
Ganesh created AMQ-5844: --- Summary: Introduce logic into the failover transport not to recreate aborted slow consumers. Key: AMQ-5844 URL: https://issues.apache.org/jira/browse/AMQ-5844 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.11.1 Reporter: Ganesh Priority: Minor AbortSlowConsumerStrategy can forcefully abort a slow consumer on the broker side if the consumer (client side) is not responding to the request to gracefully shutdown. If the connection between broker and consumer is subsequently lost, the failover transport recreates the connection and transparently re-registers all consumers on the broker side including those slow consumers that were previously forcefully aborted. It would be good to introduce some logic into the failover transport to avoid recreating slow consumers that have already been forcefully aborted on broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5844) Introduce logic into the failover transport not to recreate aborted slow consumers.
[ https://issues.apache.org/jira/browse/AMQ-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586580#comment-14586580 ] Ganesh commented on AMQ-5844: - The FailoverTransport must remove slow consumer from its state so that the slow consumer is not re-registered if the connection falters. Please see attached patch and unit test Introduce logic into the failover transport not to recreate aborted slow consumers. - Key: AMQ-5844 URL: https://issues.apache.org/jira/browse/AMQ-5844 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.11.1 Reporter: Ganesh Priority: Minor AbortSlowConsumerStrategy can forcefully abort a slow consumer on the broker side if the consumer (client side) is not responding to the request to gracefully shutdown. If the connection between broker and consumer is subsequently lost, the failover transport recreates the connection and transparently re-registers all consumers on the broker side including those slow consumers that were previously forcefully aborted. It would be good to introduce some logic into the failover transport to avoid recreating slow consumers that have already been forcefully aborted on broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-90) ClassNotFoundException when a backup server fails over after having failed back
[
https://issues.apache.org/jira/browse/ARTEMIS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-90:
-
Assignee: Justin Bertram
ClassNotFoundException when a backup server fails over after having failed
back
---
Key: ARTEMIS-90
URL: https://issues.apache.org/jira/browse/ARTEMIS-90
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
Fix For: 1.0.1
I'm integrating ActiveMQ 6 in WildFly and testing out its failover features.
My use case is:
2 servers:
* server #1 with replicated master HA (check-for-live-serve=true)
* server #2 with replicated slave HA (restart-backup=true)
* both servers are started
= #1 is master
= #2 announces it is a backup
* server #1 is stopped
= #2 fails over and becomes live
* server #1 is restarted
= #2 detects the live is up again and fails back
* server #1 is stopped again
= I was expecting server #2 to becomes live again but instead, I got the
following exception:
{noformat}
16:27:07,528 WARN [org.apache.activemq.core.server] (AMQ119000: Activation
for server ActiveMQServerImpl::serverUUID=null) AMQ222080: Error
instantiating remoting acceptor
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory:
java.lang.ClassNotFoundException:
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory from
[Module org.wildfly.extension.io:main from local module loader @6e32bb55
(finder: local module finder @44a901f8 (roots:
/Users/jmesnil/Developer/wildfly/dist/target/slave/modules,/Users/jmesnil/Developer/wildfly/dist/target/slave/modules/system/layers/base))]
at
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:216)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
at
org.apache.activemq.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:235)
at
org.apache.activemq.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1778)
at
org.apache.activemq.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:280)
at java.lang.Thread.run(Thread.java:744)
{noformat}
The CFNE occurs because WildFly uses a modular class loader.
The SharedNothingBackupActivation runnable is run by creating a new
backupActivationThread (ActiveMQServerImpl.java:425).
In a modular environment this thread's module has not knowledge of the
NettyAcceptorFactory class.
To prevent this CFNE, this thread should use the TCCL before loading the
acceptor factory from its class names.
Additionally, I'm not sure it's a good idea to create new Thread like this.
ActiveMQ has a threadPool executorService that could be used to run such
code. Since ActiveMQ supports injection of this threadPool (through the
serviceRegistry), WildFly could ensure that any code run by this thread pool
will be using the correct module class loader.
Is there a good reason to use a separate thread for the backup activation?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5844) Introduce logic into the failover transport not to recreate aborted slow consumers.
[ https://issues.apache.org/jira/browse/AMQ-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh updated AMQ-5844: Attachment: FailoverTransportDeleteSlowConsumerTest.java AMQ-5844-GMURTHY-PATCH.TXT Introduce logic into the failover transport not to recreate aborted slow consumers. - Key: AMQ-5844 URL: https://issues.apache.org/jira/browse/AMQ-5844 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.11.1 Reporter: Ganesh Priority: Minor Attachments: AMQ-5844-GMURTHY-PATCH.TXT, FailoverTransportDeleteSlowConsumerTest.java AbortSlowConsumerStrategy can forcefully abort a slow consumer on the broker side if the consumer (client side) is not responding to the request to gracefully shutdown. If the connection between broker and consumer is subsequently lost, the failover transport recreates the connection and transparently re-registers all consumers on the broker side including those slow consumers that were previously forcefully aborted. It would be good to introduce some logic into the failover transport to avoid recreating slow consumers that have already been forcefully aborted on broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-79) JMX: getFirstMessageAsJSON not suitable for large messages
[ https://issues.apache.org/jira/browse/ARTEMIS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-79: --- Fix Version/s: 1.0.1 JMX: getFirstMessageAsJSON not suitable for large messages -- Key: ARTEMIS-79 URL: https://issues.apache.org/jira/browse/ARTEMIS-79 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: Daniel Pocock Fix For: 1.0.1 When calling getFirstmessageAsJSON it has to return the whole message body. If only interested in one of the headers (e.g. the timestamp) and if the message body is large then this method can be inefficient. It would be useful to have methods that just return the headers or just the timestamp or age of the message. https://github.com/apache/activemq-6/pull/97 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-137) Review Logging implementation with i18n support
clebert suconic created ARTEMIS-137: --- Summary: Review Logging implementation with i18n support Key: ARTEMIS-137 URL: https://issues.apache.org/jira/browse/ARTEMIS-137 Project: ActiveMQ Artemis Issue Type: Bug Reporter: clebert suconic Fix For: 1.1.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
