[jira] [Resolved] (ACTIVEMQ6-111) Journal directory created even if persistence is disabled
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ACTIVEMQ6-111. -- Resolution: Fixed Fix Version/s: 1.0.0 Resolved via 4b833cf5e79324453b7fa51a4158e890b23048b5 Journal directory created even if persistence is disabled - Key: ACTIVEMQ6-111 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-111 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.0.0 The directory for the journal is still created even if the configuration uses persistence-enabledfalse/persistence-enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-19) Disable Server Side Load Balancing on message routing
[ https://issues.apache.org/jira/browse/ARTEMIS-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-19. --- Resolution: Fixed Disable Server Side Load Balancing on message routing - Key: ARTEMIS-19 URL: https://issues.apache.org/jira/browse/ARTEMIS-19 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: clebert suconic Assignee: Justin Bertram Fix For: 1.0.1 It should be possible to disable server side load balancing on message producers with a configuration option. Once we introduce this configuration the default should be off (meaning server side load balancing = no) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-134) Include jgroups.jar in distribution
[ https://issues.apache.org/jira/browse/ARTEMIS-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-134. Resolution: Fixed Include jgroups.jar in distribution --- Key: ARTEMIS-134 URL: https://issues.apache.org/jira/browse/ARTEMIS-134 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.0.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 ] Justin Bertram resolved ARTEMIS-79. --- Resolution: Fixed I believe this was fixed via 00837c120d131cd6db706aed5f549db06cd7b1e7. Resolving as fixed. 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 Assignee: Justin Bertram 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] [Assigned] (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 ] Justin Bertram reassigned ARTEMIS-79: - Assignee: Justin Bertram 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 Assignee: Justin Bertram 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] [Closed] (ARTEMIS-123) Import ActiveMQ OpenWire test framework
[ https://issues.apache.org/jira/browse/ARTEMIS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-123. -- Resolution: Duplicate 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] [Closed] (ARTEMIS-122) Import ActiveMQ OpenWire test framework
[ https://issues.apache.org/jira/browse/ARTEMIS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-122. -- Resolution: Duplicate Import ActiveMQ OpenWire test framework --- Key: ARTEMIS-122 URL: https://issues.apache.org/jira/browse/ARTEMIS-122 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] [Commented] (ARTEMIS-142) Fix test failures
[ https://issues.apache.org/jira/browse/ARTEMIS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593942#comment-14593942 ] Justin Bertram commented on ARTEMIS-142: Something from 438892352777a6870a329b186e13d0547c2bf405 broke XmlImportExportTest, but I haven't determined what yet exactly. Fix test failures - Key: ARTEMIS-142 URL: https://issues.apache.org/jira/browse/ARTEMIS-142 Project: ActiveMQ Artemis Issue Type: Bug Reporter: clebert suconic Fix For: 1.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-142) Fix test failures
[ https://issues.apache.org/jira/browse/ARTEMIS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593942#comment-14593942 ] Justin Bertram edited comment on ARTEMIS-142 at 6/19/15 9:03 PM: - Something from 438892352777a6870a329b186e13d0547c2bf405 broke XmlImportExportTest, but I haven't determined what yet exactly. It looks like that same commit may have broken SimpleStartStopTest. was (Author: jbertram): Something from 438892352777a6870a329b186e13d0547c2bf405 broke XmlImportExportTest, but I haven't determined what yet exactly. Fix test failures - Key: ARTEMIS-142 URL: https://issues.apache.org/jira/browse/ARTEMIS-142 Project: ActiveMQ Artemis Issue Type: Bug Reporter: clebert suconic Fix For: 1.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-70) Implement resource limits
[ https://issues.apache.org/jira/browse/ARTEMIS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601340#comment-14601340 ] Justin Bertram commented on ARTEMIS-70: --- I implemented: * overall number of connections * connections per user * queues per user I have not implemented: * connections per IP address * max queue size a user can create * names a user may call a queue that he creates Implement resource limits - Key: ARTEMIS-70 URL: https://issues.apache.org/jira/browse/ARTEMIS-70 Project: ActiveMQ Artemis Issue Type: New Feature Affects Versions: 1.0.0 Reporter: Michael Cressman Assignee: Justin Bertram Fix For: 1.1.0 Implement various resource limits within the system: - overall number of connections - connections per user - connections per IP address - queues per user - (possibly: number of sessions, number of subscriptions per user) The per user limits can be a default maximum for everyone plus specific limits for particular users. Other things: - limit the max queue size a user can create - limit the names a user may call a queue that he creates -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-141) Refactor classloading into ServiceRegistry
Justin Bertram created ARTEMIS-141: -- Summary: Refactor classloading into ServiceRegistry Key: ARTEMIS-141 URL: https://issues.apache.org/jira/browse/ARTEMIS-141 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 1.0.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.0.1 Move classloading duties for services related to the ServiceRegistry inside the ServiceRegistry itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-142) Fix test failures
[ https://issues.apache.org/jira/browse/ARTEMIS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593553#comment-14593553 ] Justin Bertram commented on ARTEMIS-142: [~clebertsuconic], I believe your commit cd205f6b9dd444a4abeab2f8627720932726e6c2 broke a few of the CoreClientOverOneWaySSLTest cases. Fix test failures - Key: ARTEMIS-142 URL: https://issues.apache.org/jira/browse/ARTEMIS-142 Project: ActiveMQ Artemis Issue Type: Bug Reporter: clebert suconic Fix For: 1.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-105) ActiveMQServerControl#forceFailover() always throw an exception
[
https://issues.apache.org/jira/browse/ARTEMIS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-105.
Resolution: Fixed
ActiveMQServerControl#forceFailover() always throw an exception
---
Key: ARTEMIS-105
URL: https://issues.apache.org/jira/browse/ARTEMIS-105
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Jeff Mesnil
Assignee: Justin Bertram
Fix For: 1.0.1
{noformat}
14:31:36,734 ERROR [org.jboss.as.controller.management-operation]
(management-handler-thread - 3) WFLYCTL0013: Operation (force-failover)
failed - address: ([
(subsystem = messaging-activemq),
(server = default)
]): java.lang.RuntimeException: Server is stopped
at
org.apache.activemq.artemis.core.management.impl.AbstractControl.blockOnIO(AbstractControl.java:72)
at
org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl.forceFailover(ActiveMQServerControlImpl.java:1937)
at
org.wildfly.extension.messaging.activemq.ActiveMQServerControlHandler.executeRuntimeStep(ActiveMQServerControlHandler.java:221)
{noformat}
The call to blockOnIO in the finally block always fail because the server has
been stopped beforehands.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-109) Divert routing name is no longer optional
[
https://issues.apache.org/jira/browse/ARTEMIS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582550#comment-14582550
]
Justin Bertram commented on ARTEMIS-109:
Looks like this functionality was inadvertently removed when the
DivertConfiguration was changed to a fluent class. I'll restore the previous
semantics.
Divert routing name is no longer optional
-
Key: ARTEMIS-109
URL: https://issues.apache.org/jira/browse/ARTEMIS-109
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Jeff Mesnil
Assignee: Justin Bertram
Fix For: 1.0.1
It used to be possible to create a divert configuration without a null
routing name. The server was then generating a unique routing name instead.
But now, it throws a NPE:
{noformat}
java.lang.NullPointerException
at
org.apache.activemq.api.core.SimpleString.init(SimpleString.java:75)
at
org.apache.activemq.core.server.impl.ActiveMQServerImpl.deployDivert(ActiveMQServerImpl.java:1402)
at
org.apache.activemq.core.management.impl.ActiveMQServerControlImpl.createDivert(ActiveMQServerControlImpl.java:1805)
{noformat}
I have no idea what I should use as the routing name for my divert... (use
its name, or the address or something different...)
Either the API (and documentation) must be updated to reflect that the
routing name is mandatory or the code to generate an unique one must be put
back.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (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 closed ARTEMIS-90.
-
Resolution: Fixed
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] [Resolved] (ARTEMIS-109) Divert routing name is no longer optional
[
https://issues.apache.org/jira/browse/ARTEMIS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-109.
Resolution: Fixed
Divert routing name is no longer optional
-
Key: ARTEMIS-109
URL: https://issues.apache.org/jira/browse/ARTEMIS-109
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Jeff Mesnil
Assignee: Justin Bertram
Fix For: 1.0.1
It used to be possible to create a divert configuration without a null
routing name. The server was then generating a unique routing name instead.
But now, it throws a NPE:
{noformat}
java.lang.NullPointerException
at
org.apache.activemq.api.core.SimpleString.init(SimpleString.java:75)
at
org.apache.activemq.core.server.impl.ActiveMQServerImpl.deployDivert(ActiveMQServerImpl.java:1402)
at
org.apache.activemq.core.management.impl.ActiveMQServerControlImpl.createDivert(ActiveMQServerControlImpl.java:1805)
{noformat}
I have no idea what I should use as the routing name for my divert... (use
its name, or the address or something different...)
Either the API (and documentation) must be updated to reflect that the
routing name is mandatory or the code to generate an unique one must be put
back.
--
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] [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] [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] [Created] (ARTEMIS-180) Remove example profile
Justin Bertram created ARTEMIS-180: -- Summary: Remove example profile Key: ARTEMIS-180 URL: https://issues.apache.org/jira/browse/ARTEMIS-180 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 1.0.0 Reporter: Justin Bertram Fix For: 1.1.0 Now that the examples no longer depend on a central common dependency (courtesy of https://github.com/apache/activemq-artemis/pull/97) we no longer need the example profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-162) Can't create colocated HA topology with JGroups discovery
[
https://issues.apache.org/jira/browse/ARTEMIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-162:
--
Assignee: Justin Bertram
Can't create colocated HA topology with JGroups discovery
-
Key: ARTEMIS-162
URL: https://issues.apache.org/jira/browse/ARTEMIS-162
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
Priority: Critical
Fix For: 1.0.1
Hi, I tried to start two Artemis nodes from our application server in
colocated topology with JGroups as discovery method, but i'm not able to do
it. After both nodes are up, this exception starts spamming in logs:
{noformat}
java.io.NotSerializableException: org.jgroups.JChannel
10:56:50,187 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.util.ArrayList.writeObject(ArrayList.java:747)
10:56:50,189 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.lang.reflect.Method.invoke(Method.java:483)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,192 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy(ConfigurationImpl.java:1528)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateReplicatedBackup(ColocatedHAManager.java:190)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateBackup(ColocatedHAManager.java:104)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.impl.ColocatedActivation$1.handlePacket(ColocatedActivation.java:141)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ClusterController$ClusterControllerChannelHandler.handlePacket(ClusterController.java:424)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:652)
10:56:50,193 ERROR [stderr] (default I/O-5) at
[jira] [Commented] (ARTEMIS-162) Can't create colocated HA topology with JGroups discovery
[
https://issues.apache.org/jira/browse/ARTEMIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649741#comment-14649741
]
Justin Bertram commented on ARTEMIS-162:
[~jmesnil], can you attach your configuration files, please?
Can't create colocated HA topology with JGroups discovery
-
Key: ARTEMIS-162
URL: https://issues.apache.org/jira/browse/ARTEMIS-162
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Priority: Critical
Fix For: 1.0.1
Hi, I tried to start two Artemis nodes from our application server in
colocated topology with JGroups as discovery method, but i'm not able to do
it. After both nodes are up, this exception starts spamming in logs:
{noformat}
java.io.NotSerializableException: org.jgroups.JChannel
10:56:50,187 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.util.ArrayList.writeObject(ArrayList.java:747)
10:56:50,189 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.lang.reflect.Method.invoke(Method.java:483)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,192 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy(ConfigurationImpl.java:1528)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateReplicatedBackup(ColocatedHAManager.java:190)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateBackup(ColocatedHAManager.java:104)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.impl.ColocatedActivation$1.handlePacket(ColocatedActivation.java:141)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ClusterController$ClusterControllerChannelHandler.handlePacket(ClusterController.java:424)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:652)
10:56:50,193 ERROR [stderr] (default I/O-5) at
[jira] [Assigned] (ARTEMIS-179) Artemis is logging warnings during reconnecting cluster connection on server shut down
[
https://issues.apache.org/jira/browse/ARTEMIS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-179:
--
Assignee: Justin Bertram
Artemis is logging warnings during reconnecting cluster connection on server
shut down
---
Key: ARTEMIS-179
URL: https://issues.apache.org/jira/browse/ARTEMIS-179
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.0.0
Reporter: Miroslav Novak
Assignee: Justin Bertram
Fix For: 1.0.1
Artemis is trying reconnect cluster connection if node in cluster is cleanly
shut downed. Problem is that server.log is filled by:
{code}
13:07:09,855 WARN [org.apache.activemq.artemis.core.server] (Thread-0
(ActiveMQ-server-ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f-753751730))
AMQ222109: NodeID=5638e157-35e1-11e5-82f6-752f620dec6f is not available on
the topology. Retrying the connection to that node now
{code}
which makes the logs completely unreadable.
Run two instances with:
./artemis create --clustered /server1
./artemis create --clustered /server2 --port-offset 100
start botsh servers and stop one of them:
server.log:
{code}
13:06:37,059 INFO [org.apache.activemq.artemis.core.server] (Thread-17
(ActiveMQ-server-ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f-753751730))
AMQ221027: Bridge ClusterConnectionBridge@7eb486c7
[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
queue=QueueImpl[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f]]@7f77c8d9
targetConnector=ServerLocatorImpl
(identity=(Cluster-connection-bridge::ClusterConnectionBridge@7eb486c7
[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
queue=QueueImpl[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f]]@7f77c8d9
targetConnector=ServerLocatorImpl
[initialConnectors=[TransportConfiguration(name=http-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?httpUpgradeEnabled=trueport=9080host=localhosthttp-upgrade-endpoint=http-acceptor],
discoveryGroupConfiguration=null]]::ClusterConnectionImpl@841790227[nodeUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f,
connector=TransportConfiguration(name=http-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?host=localhosthttp-upgrade-endpoint=http-acceptorhttpUpgradeEnabled=trueport=8080,
address=jms,
server=ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f]))
[initialConnectors=[TransportConfiguration(name=http-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?httpUpgradeEnabled=trueport=9080host=localhosthttp-upgrade-endpoint=http-acceptor],
discoveryGroupConfiguration=null]] is connected
13:07:09,305 WARN [org.apache.activemq.artemis.core.client] (Thread-0
(ActiveMQ-client-global-threads-166185675)) AMQ212037: Connection failure has
been detected: AMQ119015: The connection was disconnected because of server
shutdown [code=DISCONNECTED]
13:07:09,311 WARN [org.apache.activemq.artemis.core.client] (Thread-2
(ActiveMQ-client-global-threads-166185675)) AMQ212037: Connection failure has
been detected: AMQ119015: The connection was disconnected because of server
shutdown [code=DISCONNECTED]
13:07:09,310 WARN [org.apache.activemq.artemis.core.client] (Thread-1
(ActiveMQ-client-global-threads-166185675)) AMQ212037: Connection failure has
been detected: AMQ119015: The connection was disconnected because of server
shutdown [code=DISCONNECTED]
13:07:09,325 WARN [org.apache.activemq.artemis.core.server] (Thread-2
(ActiveMQ-client-global-threads-166185675)) AMQ222095: Connection failed with
failedOver=false: ActiveMQDisconnectedException[errorType=DISCONNECTED
message=AMQ119015: The connection was disconnected because of server shutdown]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:1183)
at
org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
13:07:09,354 WARN [org.apache.activemq.artemis.core.server] (Thread-2
(ActiveMQ-client-global-threads-166185675)) AMQ222095:
[jira] [Resolved] (ARTEMIS-179) Artemis is logging warnings during reconnecting cluster connection on server shut down
[
https://issues.apache.org/jira/browse/ARTEMIS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-179.
Resolution: Fixed
Artemis is logging warnings during reconnecting cluster connection on server
shut down
---
Key: ARTEMIS-179
URL: https://issues.apache.org/jira/browse/ARTEMIS-179
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.0.0
Reporter: Miroslav Novak
Assignee: Justin Bertram
Fix For: 1.0.1
Artemis is trying reconnect cluster connection if node in cluster is cleanly
shut downed. Problem is that server.log is filled by:
{code}
13:07:09,855 WARN [org.apache.activemq.artemis.core.server] (Thread-0
(ActiveMQ-server-ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f-753751730))
AMQ222109: NodeID=5638e157-35e1-11e5-82f6-752f620dec6f is not available on
the topology. Retrying the connection to that node now
{code}
which makes the logs completely unreadable.
Run two instances with:
./artemis create --clustered /server1
./artemis create --clustered /server2 --port-offset 100
start botsh servers and stop one of them:
server.log:
{code}
13:06:37,059 INFO [org.apache.activemq.artemis.core.server] (Thread-17
(ActiveMQ-server-ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f-753751730))
AMQ221027: Bridge ClusterConnectionBridge@7eb486c7
[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
queue=QueueImpl[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f]]@7f77c8d9
targetConnector=ServerLocatorImpl
(identity=(Cluster-connection-bridge::ClusterConnectionBridge@7eb486c7
[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
queue=QueueImpl[name=sf.my-cluster.5638e157-35e1-11e5-82f6-752f620dec6f,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f]]@7f77c8d9
targetConnector=ServerLocatorImpl
[initialConnectors=[TransportConfiguration(name=http-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?httpUpgradeEnabled=trueport=9080host=localhosthttp-upgrade-endpoint=http-acceptor],
discoveryGroupConfiguration=null]]::ClusterConnectionImpl@841790227[nodeUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f,
connector=TransportConfiguration(name=http-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?host=localhosthttp-upgrade-endpoint=http-acceptorhttpUpgradeEnabled=trueport=8080,
address=jms,
server=ActiveMQServerImpl::serverUUID=60b3fc86-35e1-11e5-aa4b-0324779e0c1f]))
[initialConnectors=[TransportConfiguration(name=http-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?httpUpgradeEnabled=trueport=9080host=localhosthttp-upgrade-endpoint=http-acceptor],
discoveryGroupConfiguration=null]] is connected
13:07:09,305 WARN [org.apache.activemq.artemis.core.client] (Thread-0
(ActiveMQ-client-global-threads-166185675)) AMQ212037: Connection failure has
been detected: AMQ119015: The connection was disconnected because of server
shutdown [code=DISCONNECTED]
13:07:09,311 WARN [org.apache.activemq.artemis.core.client] (Thread-2
(ActiveMQ-client-global-threads-166185675)) AMQ212037: Connection failure has
been detected: AMQ119015: The connection was disconnected because of server
shutdown [code=DISCONNECTED]
13:07:09,310 WARN [org.apache.activemq.artemis.core.client] (Thread-1
(ActiveMQ-client-global-threads-166185675)) AMQ212037: Connection failure has
been detected: AMQ119015: The connection was disconnected because of server
shutdown [code=DISCONNECTED]
13:07:09,325 WARN [org.apache.activemq.artemis.core.server] (Thread-2
(ActiveMQ-client-global-threads-166185675)) AMQ222095: Connection failed with
failedOver=false: ActiveMQDisconnectedException[errorType=DISCONNECTED
message=AMQ119015: The connection was disconnected because of server shutdown]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:1183)
at
org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
13:07:09,354 WARN [org.apache.activemq.artemis.core.server] (Thread-2
(ActiveMQ-client-global-threads-166185675)) AMQ222095: Connection
[jira] [Assigned] (ARTEMIS-205) Keepalive not working on OpenWire
[ https://issues.apache.org/jira/browse/ARTEMIS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-205: -- Assignee: Justin Bertram Keepalive not working on OpenWire - Key: ARTEMIS-205 URL: https://issues.apache.org/jira/browse/ARTEMIS-205 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.0.0 Reporter: clebert suconic Assignee: Justin Bertram Priority: Blocker Fix For: 1.1.0 Just run the chat example from ./examples/protocol/openwire/chat and you will see that the application won't survive no matter what you do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-161) Graceful shutdown: add a timeout to stop Artemis
[ https://issues.apache.org/jira/browse/ARTEMIS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-161: -- Assignee: Justin Bertram Graceful shutdown: add a timeout to stop Artemis Key: ARTEMIS-161 URL: https://issues.apache.org/jira/browse/ARTEMIS-161 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 1.0.0 Reporter: Jeff Mesnil Assignee: Justin Bertram Fix For: 1.0.1 We want to provide a graceful shutdown for Artemis to leave some time for JMS clients to finish their work before stopping the server. This is also covered by ARTEMIS-72 which deals with refusing new remote connections once the shutdown process is started (while keeping in-vm connections opened). This issue is about specifying a timeout when stopping the ActiveMQServer. It is possible to provide a general shutdown timeout in the server configuration but this is not suitable. A shutdown process is contextual: it may be a quick shutdown in case of emergency (with a timeout of some seconds) or a long timeout (several hours) in case of planned upgrade for example. This parameter should be specified when the admin starts the shutdown process and be passed to the ActiveMQServer (and its wrapping JMSServerManger) stop() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-210) Outbound connections aren't load-balanced as expected
Justin Bertram created ARTEMIS-210: -- Summary: Outbound connections aren't load-balanced as expected Key: ARTEMIS-210 URL: https://issues.apache.org/jira/browse/ARTEMIS-210 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-289) Potential ConcurrentModificationException when closing connections
[ https://issues.apache.org/jira/browse/ARTEMIS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-289: --- Description: org.apache.activemq.artemis.core.server.impl.QueueImpl#getConsumers returns the actual Set of consumers, but if another thread modifies this collection while the caller loops through the Set then a ConcurrentModificationException will be thrown. This is possible particularly in management operations that work on the Set of consumers like org.apache.activemq.artemis.api.core.management.ActiveMQServerControl#closeConsumerConnectionsForAddress. (was: org.apache.activemq.artemis.core.server.impl.QueueImpl#getConsumers returns the actual Set of consumers, but if another thread modifies this collection while the caller loops through the Set then a ConcurrentModificationException will be thrown.) > Potential ConcurrentModificationException when closing connections > -- > > Key: ARTEMIS-289 > URL: https://issues.apache.org/jira/browse/ARTEMIS-289 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > > org.apache.activemq.artemis.core.server.impl.QueueImpl#getConsumers returns > the actual Set of consumers, but if another thread modifies this collection > while the caller loops through the Set then a ConcurrentModificationException > will be thrown. This is possible particularly in management operations that > work on the Set of consumers like > org.apache.activemq.artemis.api.core.management.ActiveMQServerControl#closeConsumerConnectionsForAddress. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-289) Potential ConcurrentModificationException when closing connections
[ https://issues.apache.org/jira/browse/ARTEMIS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-289: --- Affects Version/s: 1.1.0 > Potential ConcurrentModificationException when closing connections > -- > > Key: ARTEMIS-289 > URL: https://issues.apache.org/jira/browse/ARTEMIS-289 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > > org.apache.activemq.artemis.core.server.impl.QueueImpl#getConsumers returns > the actual Set of consumers, but if another thread modifies this collection > while the caller loops through the Set then a ConcurrentModificationException > will be thrown. This is possible particularly in management operations that > work on the Set of consumers like > org.apache.activemq.artemis.api.core.management.ActiveMQServerControl#closeConsumerConnectionsForAddress. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-168) Pluggable ACL Hierarchies
[ https://issues.apache.org/jira/browse/ARTEMIS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-168: --- Fix Version/s: (was: 1.3.0) 1.1.1 > Pluggable ACL Hierarchies > - > > Key: ARTEMIS-168 > URL: https://issues.apache.org/jira/browse/ARTEMIS-168 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: Justin Bertram >Priority: Critical > Fix For: 1.1.1 > > > ActiveMQ5 has a way to plug the security-settings into LDAP | Files, or a > Pluggable ACL implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-255) Make failover timeout for non-blocking sends configurable
[ https://issues.apache.org/jira/browse/ARTEMIS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-255. Resolution: Fixed > Make failover timeout for non-blocking sends configurable > - > > Key: ARTEMIS-255 > URL: https://issues.apache.org/jira/browse/ARTEMIS-255 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-289) Potential ConcurrentModificationException when closing connections
[ https://issues.apache.org/jira/browse/ARTEMIS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-289. Resolution: Fixed > Potential ConcurrentModificationException when closing connections > -- > > Key: ARTEMIS-289 > URL: https://issues.apache.org/jira/browse/ARTEMIS-289 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > > org.apache.activemq.artemis.core.server.impl.QueueImpl#getConsumers returns > the actual Set of consumers, but if another thread modifies this collection > while the caller loops through the Set then a ConcurrentModificationException > will be thrown. This is possible particularly in management operations that > work on the Set of consumers like > org.apache.activemq.artemis.api.core.management.ActiveMQServerControl#closeConsumerConnectionsForAddress. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-168) Pluggable ACL Hierarchies
[ https://issues.apache.org/jira/browse/ARTEMIS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-168. Resolution: Fixed > Pluggable ACL Hierarchies > - > > Key: ARTEMIS-168 > URL: https://issues.apache.org/jira/browse/ARTEMIS-168 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: Justin Bertram >Priority: Critical > Fix For: 1.3.0 > > > ActiveMQ5 has a way to plug the security-settings into LDAP | Files, or a > Pluggable ACL implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-283) Protocol independent JMSMessageID from management interface
[
https://issues.apache.org/jira/browse/ARTEMIS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976491#comment-14976491
]
Justin Bertram commented on ARTEMIS-283:
Couple of questions:
# I don't quite understand why listing JMS messages would not make sense if
there is not a JMSMessageID to correlate with. There are all kinds of different
use-cases for listing messages. Can you clarify your specific use-case a bit
more?
# I'm not sure it makes sense for a message produced with a non-JMS API to have
a JMSMessageID. The JMSMessageID is after all JMS-specific.
> Protocol independent JMSMessageID from management interface
> ---
>
> Key: ARTEMIS-283
> URL: https://issues.apache.org/jira/browse/ARTEMIS-283
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.1.0
>Reporter: Petter Nordlander
>Priority: Minor
>
> The Management interface (JMX) has a listMessagesAsJSON operation on JMS
> queues.
> Listing JMS messages would not make sense if there is not a JMSMessageID to
> correlate with. This works only for messages produced with Artemis "Core JMS"
> protocol (i.e. HornetQ wire protocol). Messages produced with AMQP (proton)
> and OpenWire JMS clients does not contain the JMSMessageID property.
> This property is vital to make GUIs, management scripts and whatnot.
> Example:
> Three messages in the following order: Artemis JMS, OpenWire, AMQP
> {code:javascript}
> [
> {
> "JMSPriority":4,
> "JMSMessageID":"ID:11d61bfc-7c8f-11e5-b67d-fbf95a4499b8",
> "address":"jms.queue.a1",
> "JMSExpiration":0,
> "__AMQ_CID":"11d1d638-7c8f-11e5-b67d-fbf95a4499b8",
> "JMSTimestamp":1445938962608,
> "messageID":134336,
> "JMSDeliveryMode":"PERSISTENT"
> },
> {
> "address":"jms.queue.a1",
> "JMSExpiration":0,
> "JMSTimestamp":1445938969309,
>
> "__HDR_MARSHALL_PROP":[0,0,0,1,0,6,118,101,110,100,111,114,9,0,3,97,109,113],
> "messageID":134354,
> "__HDR_GROUP_SEQUENCE":0,
>
> "__HDR_PRODUCER_ID":[0,0,0,61,123,1,43,0,52,73,68,58,80,101,116,116,101,114,115,45,77,97,99,66,111,111,107,45,80,114,111,46,108,111,99,97,108,45,54,52,53,55,52,45,49,52,52,53,57,51,56,57,54,57,49,53,54,45,49,58,49,0,1,0,1],
> "JMSDeliveryMode":"PERSISTENT",
> "JMSPriority":4,
> "__HDR_COMMAND_ID":6,
> "__HDR_ARRIVAL":0,
> "__HDR_REDELIVER_COUNTER":0,
>
> "__HDR_MESSAGE_ID":[0,0,0,65,110,2,-82,2,123,0,52,73,68,58,80,101,116,116,101,114,115,45,77,97,99,66,111,111,107,45,80,114,111,46,108,111,99,97,108,45,54,52,53,55,52,45,49,52,52,53,57,51,56,57,54,57,49,53,54,45,49,58,49,0,1,0,1,0,1],
> "__HDR_DROPPABLE":false,
> "__HDR_BROKER_IN_TIME":1445938969310
> },
> {
> "JMS_AMQP_NATIVE":false,
> "JMSPriority":4,
> "address":"jms.queue.a1",
> "JMSExpiration":0,
> "JMS_AMQP_MESSAGE_FORMAT":0,
> "JMSTimestamp":1445939704838,
> "messageID":134376,
> "JMSDeliveryMode":"PERSISTENT"
> }
> ]
> {code}
> Corresponding Message Ids would be (read from JMS interface).
> Core: JMSMessageID: 783cf118-7c91-11e5-9a09-b3c5f39ba469:0:0:-1
> OpenWire: JMSMessageID:
> ID:Petters-MacBook-Pro.local-64574-1445938969156-1:1:1:1:1
> AMQP: JMSMessageID: 783d1829-7c91-11e5-9a09-b3c5f39ba469:0:0:-1
> Problem is in QueueCtrlImpl which uses core-jms-client to convert messages
> from core to Jms Map. It consider all messages as core messages. Logic from
> each protocol/client should be used on respective message.
> Map jmsMessage =
> ActiveMQMessage.coreMaptoJMSMap(coreMessage);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-93) OSGI support
[ https://issues.apache.org/jira/browse/ARTEMIS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976699#comment-14976699 ] Justin Bertram commented on ARTEMIS-93: --- [~ch...@die-schneider.net], I think that would be great. > OSGI support > > > Key: ARTEMIS-93 > URL: https://issues.apache.org/jira/browse/ARTEMIS-93 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.3.0 >Reporter: clebert suconic >Priority: Critical > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-261) Allow certificate based JAAS security
[ https://issues.apache.org/jira/browse/ARTEMIS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-261: -- Assignee: Justin Bertram > Allow certificate based JAAS security > - > > Key: ARTEMIS-261 > URL: https://issues.apache.org/jira/browse/ARTEMIS-261 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 1.1.1 >Reporter: Stephen Lewis >Assignee: Justin Bertram > > ARTEMIS-74 imported ActiveMQ 5 JAAS. However, this doesn't allow certificate > based authentication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-168) Pluggable ACL Hierarchies
[ https://issues.apache.org/jira/browse/ARTEMIS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-168: -- Assignee: Justin Bertram > Pluggable ACL Hierarchies > - > > Key: ARTEMIS-168 > URL: https://issues.apache.org/jira/browse/ARTEMIS-168 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: Justin Bertram >Priority: Critical > Fix For: 1.3.0 > > > ActiveMQ5 has a way to plug the security-settings into LDAP | Files, or a > Pluggable ACL implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-299) Improve performance of TextFileCertificateLoginModule when many entries in user file
[ https://issues.apache.org/jira/browse/ARTEMIS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-299. Resolution: Fixed > Improve performance of TextFileCertificateLoginModule when many entries in > user file > > > Key: ARTEMIS-299 > URL: https://issues.apache.org/jira/browse/ARTEMIS-299 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-298) IPv6 escape doesn't always work
[ https://issues.apache.org/jira/browse/ARTEMIS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-298. Resolution: Fixed > IPv6 escape doesn't always work > --- > > Key: ARTEMIS-298 > URL: https://issues.apache.org/jira/browse/ARTEMIS-298 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > > Currently a valid IPv6 address like "2620:db8:1:2::1%em1" will not be > properly escaped with surrounding square brackets (i.e. "[" and "]") which > causes URI parsing to fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-286) Upgrade Netty to version 4.0.32.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-286. Resolution: Fixed > Upgrade Netty to version 4.0.32.Final > - > > Key: ARTEMIS-286 > URL: https://issues.apache.org/jira/browse/ARTEMIS-286 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Andrea Cosentino >Priority: Minor > Fix For: 1.2.0 > > > Latest release is 4.0.32.Final, Artemis actually is using 4.0.30.Final -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-304) Prompt for role when creating instance
Justin Bertram created ARTEMIS-304: -- Summary: Prompt for role when creating instance Key: ARTEMIS-304 URL: https://issues.apache.org/jira/browse/ARTEMIS-304 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 1.1.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.1.1 It's not ideal to use a default value for the "role" when creating an instance of Artemis. Prompt the user for input here instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-263) etc folder not included at runtime
[ https://issues.apache.org/jira/browse/ARTEMIS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-263. Resolution: Fixed This looks resolved to me so I'm marking it as such. Feel free to change it back to "unresolved" if necessary. > etc folder not included at runtime > -- > > Key: ARTEMIS-263 > URL: https://issues.apache.org/jira/browse/ARTEMIS-263 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Andy Taylor >Assignee: Andy Taylor > Fix For: 1.1.1 > > > also it should be at the head of the classpath so that users can replace > resources in jars -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-276) JMSBridge should be TCCL aware
[ https://issues.apache.org/jira/browse/ARTEMIS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-276. Resolution: Fixed This looks resolved to me so I'm marking it as such. Feel free to change it back to "unresolved" if necessary. > JMSBridge should be TCCL aware > -- > > Key: ARTEMIS-276 > URL: https://issues.apache.org/jira/browse/ARTEMIS-276 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 1.1.1 > > > JMSBridge should pass TCCL (if any) to its threads. This is useful when the > bridge is deployed in a container that rely on TCCL to find classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-299) Improve performance of TextFileCertificateLoginModule when many entries in user file
Justin Bertram created ARTEMIS-299: -- Summary: Improve performance of TextFileCertificateLoginModule when many entries in user file Key: ARTEMIS-299 URL: https://issues.apache.org/jira/browse/ARTEMIS-299 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.1.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-298) IPv6 escape doesn't always work
Justin Bertram created ARTEMIS-298: -- Summary: IPv6 escape doesn't always work Key: ARTEMIS-298 URL: https://issues.apache.org/jira/browse/ARTEMIS-298 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.1.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.1.1 Currently a valid IPv6 address like "2620:db8:1:2::1%em1" will not be properly escaped with surrounding square brackets (i.e. "[" and "]") which causes URI parsing to fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-293) Rebalance JCA RA inflow connections when cluster topology changes
[ https://issues.apache.org/jira/browse/ARTEMIS-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-293. Resolution: Fixed > Rebalance JCA RA inflow connections when cluster topology changes > - > > Key: ARTEMIS-293 > URL: https://issues.apache.org/jira/browse/ARTEMIS-293 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > > The inflow connections for an MDB (or other JCA inflow component) are > typically long-lived. This is normally a good thing. However, when MDBs are > consuming messages from a remote cluster and the topology of that cluster > changes (i.e. a node is added to increase capacity or removed for > maintenance) the inflow connections don't react in an efficient way. The RA > should detect topology changes and re-balance the inflow connections across > the new topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-300) Make JAAS properties login module default and deprecate "basic"
Justin Bertram created ARTEMIS-300: -- Summary: Make JAAS properties login module default and deprecate "basic" Key: ARTEMIS-300 URL: https://issues.apache.org/jira/browse/ARTEMIS-300 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.1.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-293) Rebalance JCA RA inflow connections when cluster topology changes
Justin Bertram created ARTEMIS-293: -- Summary: Rebalance JCA RA inflow connections when cluster topology changes Key: ARTEMIS-293 URL: https://issues.apache.org/jira/browse/ARTEMIS-293 Project: ActiveMQ Artemis Issue Type: New Feature Affects Versions: 1.1.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.1.1 The inflow connections for an MDB (or other JCA inflow component) are typically long-lived. This is normally a good thing. However, when MDBs are consuming messages from a remote cluster and the topology of that cluster changes (i.e. a node is added to increase capacity or removed for maintenance) the inflow connections don't react in an efficient way. The RA should detect topology changes and re-balance the inflow connections across the new topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-256) Orchestrate fail-back deterministically
[ https://issues.apache.org/jira/browse/ARTEMIS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-256. Resolution: Fixed > Orchestrate fail-back deterministically > --- > > Key: ARTEMIS-256 > URL: https://issues.apache.org/jira/browse/ARTEMIS-256 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > > Currently fail-back using replication relies on a simple delay (i.e. > failback-delay) to determine when the live broker has synchronized all its > data to the backup broker (which will become the new live broker once > fail-back completes). However, if failback-delay is too short then > synchronization won't complete and both the live and backup brokers will be > nonfunctional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARTEMIS-242) IllegalStateException thrown during producer.send()
[
https://issues.apache.org/jira/browse/ARTEMIS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram closed ARTEMIS-242.
--
Resolution: Duplicate
> IllegalStateException thrown during producer.send()
> ---
>
> Key: ARTEMIS-242
> URL: https://issues.apache.org/jira/browse/ARTEMIS-242
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
>Priority: Minor
>
> Sometimes happens that during failback JMS producer can get
> java.lang.IllegalStateException during producer.send(message):
> {code}
> java.lang.IllegalStateException: Cannot send a packet while channel is doing
> failover
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:242)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:201)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendInitialChunkOnLargeMessage(ActiveMQSessionContext.java:358)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendInitialLargeMessageHeader(ClientProducerImpl.java:339)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendStreamed(ClientProducerImpl.java:518)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendBuffered(ClientProducerImpl.java:414)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSend(ClientProducerImpl.java:333)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:263)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:124)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:476)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:172)
> at
> org.jboss.qa.hornetq.apps.clients.ProducerClientAck.sendMessage(ProducerClientAck.java:174)
> at
> org.jboss.qa.hornetq.apps.clients.ProducerClientAck.run(ProducerClientAck.java:116)
> {code}
> This happened if failback-delay was set to 10s. There were 2 servers
> configured configured in dedicated HA topology with shared store.
> IllegalStateException should be never thrown from producer.send().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-254) Don't throw IllegalStateException from JMS producer implementation
[
https://issues.apache.org/jira/browse/ARTEMIS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-254:
---
Description:
Sometimes during failback a JMS producer can get
java.lang.IllegalStateException during producer.send(message):
{noformat}
java.lang.IllegalStateException: Cannot send a packet while channel is doing
failover
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:242)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:201)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendInitialChunkOnLargeMessage(ActiveMQSessionContext.java:358)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendInitialLargeMessageHeader(ClientProducerImpl.java:339)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendStreamed(ClientProducerImpl.java:518)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendBuffered(ClientProducerImpl.java:414)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSend(ClientProducerImpl.java:333)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:263)
at
org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:124)
at
org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:476)
at
org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:172)
...
{noformat}
IllegalStateException should be never thrown from producer.send().
> Don't throw IllegalStateException from JMS producer implementation
> --
>
> Key: ARTEMIS-254
> URL: https://issues.apache.org/jira/browse/ARTEMIS-254
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Sometimes during failback a JMS producer can get
> java.lang.IllegalStateException during producer.send(message):
> {noformat}
> java.lang.IllegalStateException: Cannot send a packet while channel is doing
> failover
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:242)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:201)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendInitialChunkOnLargeMessage(ActiveMQSessionContext.java:358)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendInitialLargeMessageHeader(ClientProducerImpl.java:339)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendStreamed(ClientProducerImpl.java:518)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendBuffered(ClientProducerImpl.java:414)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSend(ClientProducerImpl.java:333)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:263)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:124)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:476)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:172)
> ...
> {noformat}
> IllegalStateException should be never thrown from producer.send().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-254) Don't throw IllegalStateException from JMS producer implementation
[
https://issues.apache.org/jira/browse/ARTEMIS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-254:
---
Fix Version/s: 1.1.1
> Don't throw IllegalStateException from JMS producer implementation
> --
>
> Key: ARTEMIS-254
> URL: https://issues.apache.org/jira/browse/ARTEMIS-254
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Sometimes during failback a JMS producer can get
> java.lang.IllegalStateException during producer.send(message):
> {noformat}
> java.lang.IllegalStateException: Cannot send a packet while channel is doing
> failover
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:242)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:201)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendInitialChunkOnLargeMessage(ActiveMQSessionContext.java:358)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendInitialLargeMessageHeader(ClientProducerImpl.java:339)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendStreamed(ClientProducerImpl.java:518)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendBuffered(ClientProducerImpl.java:414)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSend(ClientProducerImpl.java:333)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:263)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:124)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:476)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:172)
> ...
> {noformat}
> IllegalStateException should be never thrown from producer.send().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ARTEMIS-254) Don't throw IllegalStateException from JMS producer implementation
[
https://issues.apache.org/jira/browse/ARTEMIS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram closed ARTEMIS-254.
--
Resolution: Duplicate
> Don't throw IllegalStateException from JMS producer implementation
> --
>
> Key: ARTEMIS-254
> URL: https://issues.apache.org/jira/browse/ARTEMIS-254
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Sometimes during failback a JMS producer can get
> java.lang.IllegalStateException during producer.send(message):
> {noformat}
> java.lang.IllegalStateException: Cannot send a packet while channel is doing
> failover
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:242)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:201)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendInitialChunkOnLargeMessage(ActiveMQSessionContext.java:358)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendInitialLargeMessageHeader(ClientProducerImpl.java:339)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendStreamed(ClientProducerImpl.java:518)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendBuffered(ClientProducerImpl.java:414)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSend(ClientProducerImpl.java:333)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:263)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:124)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:476)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:172)
> ...
> {noformat}
> IllegalStateException should be never thrown from producer.send().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-242) IllegalStateException thrown during producer.send()
[
https://issues.apache.org/jira/browse/ARTEMIS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reopened ARTEMIS-242:
Assignee: Justin Bertram
> IllegalStateException thrown during producer.send()
> ---
>
> Key: ARTEMIS-242
> URL: https://issues.apache.org/jira/browse/ARTEMIS-242
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
>Priority: Minor
>
> Sometimes happens that during failback JMS producer can get
> java.lang.IllegalStateException during producer.send(message):
> {code}
> java.lang.IllegalStateException: Cannot send a packet while channel is doing
> failover
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:242)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:201)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendInitialChunkOnLargeMessage(ActiveMQSessionContext.java:358)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendInitialLargeMessageHeader(ClientProducerImpl.java:339)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendStreamed(ClientProducerImpl.java:518)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendBuffered(ClientProducerImpl.java:414)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSend(ClientProducerImpl.java:333)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:263)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:124)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:476)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:172)
> at
> org.jboss.qa.hornetq.apps.clients.ProducerClientAck.sendMessage(ProducerClientAck.java:174)
> at
> org.jboss.qa.hornetq.apps.clients.ProducerClientAck.run(ProducerClientAck.java:116)
> {code}
> This happened if failback-delay was set to 10s. There were 2 servers
> configured configured in dedicated HA topology with shared store.
> IllegalStateException should be never thrown from producer.send().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-242) IllegalStateException thrown during producer.send()
[
https://issues.apache.org/jira/browse/ARTEMIS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-242.
Resolution: Fixed
> IllegalStateException thrown during producer.send()
> ---
>
> Key: ARTEMIS-242
> URL: https://issues.apache.org/jira/browse/ARTEMIS-242
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
>Priority: Minor
>
> Sometimes happens that during failback JMS producer can get
> java.lang.IllegalStateException during producer.send(message):
> {code}
> java.lang.IllegalStateException: Cannot send a packet while channel is doing
> failover
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:242)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:201)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendInitialChunkOnLargeMessage(ActiveMQSessionContext.java:358)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendInitialLargeMessageHeader(ClientProducerImpl.java:339)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendStreamed(ClientProducerImpl.java:518)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSendBuffered(ClientProducerImpl.java:414)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.largeMessageSend(ClientProducerImpl.java:333)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:263)
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:124)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:476)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:172)
> at
> org.jboss.qa.hornetq.apps.clients.ProducerClientAck.sendMessage(ProducerClientAck.java:174)
> at
> org.jboss.qa.hornetq.apps.clients.ProducerClientAck.run(ProducerClientAck.java:116)
> {code}
> This happened if failback-delay was set to 10s. There were 2 servers
> configured configured in dedicated HA topology with shared store.
> IllegalStateException should be never thrown from producer.send().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-255) Make failover timeout for non-blocking sends configurable
Justin Bertram created ARTEMIS-255: -- Summary: Make failover timeout for non-blocking sends configurable Key: ARTEMIS-255 URL: https://issues.apache.org/jira/browse/ARTEMIS-255 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.1.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 1.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-160) After failback backup prints warnings to log
[
https://issues.apache.org/jira/browse/ARTEMIS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009497#comment-15009497
]
Justin Bertram commented on ARTEMIS-160:
Log debug instead of throwing the IllegalStateException from
org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl#checkInitialised?
There may be methods that rely on the exception.
> After failback backup prints warnings to log
>
>
> Key: ARTEMIS-160
> URL: https://issues.apache.org/jira/browse/ARTEMIS-160
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.2.0
>
>
> We integrate Artemis in our app server.
> When the artemis server is stopped, we want to unregister any JNDI bindings
> for the JMS resources.
> For failback, the only way to detect that the artemis server is stopped is to
> use the ActivateCallback callback on Artemis *core* server. There is no way
> to be notified when the JMS server (wrapping the core server) is stopped.
> This leads to a window where we remove JNDI bindings from the JMS server
> before it is deactivated but the actual operations is performed after it was
> deactivated and the server prints WARNING logs:
> {noformat}
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 4) WFLYMSGAMQ0004: Failed to destroy queue: ExpiryQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 68) WFLYMSGAMQ0004: Failed to destroy queue: AsyncQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 9) WFLYMSGAMQ0004: Failed to destroy queue: DLQ:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
[jira] [Comment Edited] (ARTEMIS-160) After failback backup prints warnings to log
[
https://issues.apache.org/jira/browse/ARTEMIS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009444#comment-15009444
]
Justin Bertram edited comment on ARTEMIS-160 at 11/17/15 8:34 PM:
--
The runAfterActive was implemented here because of HORNETQ-911. At the time
that
org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl#runAfterActive
actually runs it looks like the server is active. However, by the time that the
WrappedRunnable executes the server is no longer active which is why the
IllegalStateException is thrown.
I'm a bit confused about the use-case here because I was under the impression
that the org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl
itself would removed the bindings via
org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl#deActivate.
Are you providing an custom implementation of
org.apache.activemq.artemis.spi.core.naming.BindingRegistry? If so, could you
put hooks in there to do your specific JNDI clean-up when the JMSServerManager
unbinds the JMS admin objects?
was (Author: jbertram):
The runAfterActive was implemented here because of HORNETQ-911. At the time
that
org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl#runAfterActive
actually runs it looks like the server is active. However, by the time that the
WrappedRunnable executes the server is no longer active which is why the
IllegalStateException is thrown.
I'm a bit confused about the use-case here because I was under the impression
that the org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl
itself would removed the JNDI bindings via
org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl#deActivate.
Are you providing an custom implementation of
org.apache.activemq.artemis.spi.core.naming.BindingRegistry? If so, could you
put hooks in there to do your specific JNDI clean-up when the JMSServerManager
unbinds the JMS admin objects?
> After failback backup prints warnings to log
>
>
> Key: ARTEMIS-160
> URL: https://issues.apache.org/jira/browse/ARTEMIS-160
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.2.0
>
>
> We integrate Artemis in our app server.
> When the artemis server is stopped, we want to unregister any JNDI bindings
> for the JMS resources.
> For failback, the only way to detect that the artemis server is stopped is to
> use the ActivateCallback callback on Artemis *core* server. There is no way
> to be notified when the JMS server (wrapping the core server) is stopped.
> This leads to a window where we remove JNDI bindings from the JMS server
> before it is deactivated but the actual operations is performed after it was
> deactivated and the server prints WARNING logs:
> {noformat}
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 4) WFLYMSGAMQ0004: Failed to destroy queue: ExpiryQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 68) WFLYMSGAMQ0004: Failed to destroy queue: AsyncQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
>
[jira] [Assigned] (ARTEMIS-160) After failback backup prints warnings to log
[
https://issues.apache.org/jira/browse/ARTEMIS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-160:
--
Assignee: Justin Bertram
> After failback backup prints warnings to log
>
>
> Key: ARTEMIS-160
> URL: https://issues.apache.org/jira/browse/ARTEMIS-160
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.2.0
>
>
> We integrate Artemis in our app server.
> When the artemis server is stopped, we want to unregister any JNDI bindings
> for the JMS resources.
> For failback, the only way to detect that the artemis server is stopped is to
> use the ActivateCallback callback on Artemis *core* server. There is no way
> to be notified when the JMS server (wrapping the core server) is stopped.
> This leads to a window where we remove JNDI bindings from the JMS server
> before it is deactivated but the actual operations is performed after it was
> deactivated and the server prints WARNING logs:
> {noformat}
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 4) WFLYMSGAMQ0004: Failed to destroy queue: ExpiryQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 68) WFLYMSGAMQ0004: Failed to destroy queue: AsyncQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 9) WFLYMSGAMQ0004: Failed to destroy queue: DLQ:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent
[jira] [Commented] (ARTEMIS-160) After failback backup prints warnings to log
[
https://issues.apache.org/jira/browse/ARTEMIS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009444#comment-15009444
]
Justin Bertram commented on ARTEMIS-160:
The runAfterActive was implemented here because of HORNETQ-911. At the time
that
org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl#runAfterActive
actually runs it looks like the server is active. However, by the time that the
WrappedRunnable executes the server is no longer active which is why the
IllegalStateException is thrown.
I'm a bit confused about the use-case here because I was under the impression
that the org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl
itself would removed the JNDI bindings via
org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl#deActivate.
Are you providing an custom implementation of
org.apache.activemq.artemis.spi.core.naming.BindingRegistry? If so, could you
put hooks in there to do your specific JNDI clean-up when the JMSServerManager
unbinds the JMS admin objects?
> After failback backup prints warnings to log
>
>
> Key: ARTEMIS-160
> URL: https://issues.apache.org/jira/browse/ARTEMIS-160
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jeff Mesnil
> Fix For: 1.2.0
>
>
> We integrate Artemis in our app server.
> When the artemis server is stopped, we want to unregister any JNDI bindings
> for the JMS resources.
> For failback, the only way to detect that the artemis server is stopped is to
> use the ActivateCallback callback on Artemis *core* server. There is no way
> to be notified when the JMS server (wrapping the core server) is stopped.
> This leads to a window where we remove JNDI bindings from the JMS server
> before it is deactivated but the actual operations is performed after it was
> deactivated and the server prints WARNING logs:
> {noformat}
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 4) WFLYMSGAMQ0004: Failed to destroy queue: ExpiryQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 68) WFLYMSGAMQ0004: Failed to destroy queue: AsyncQueue:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService
> Thread Pool – 9) WFLYMSGAMQ0004: Failed to destroy queue: DLQ:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> yet active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at
>
[jira] [Assigned] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-212:
--
Assignee: Justin Bertram
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-212.
Resolution: Fixed
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715571#comment-14715571
]
Justin Bertram edited comment on ARTEMIS-212 at 8/26/15 9:40 PM:
-
Maybe I'm thick, but I can't reproduce this. Here's the quick unit test I
wrote:
{code}
ConnectionFactoryParser parser = new ConnectionFactoryParser();
ActiveMQConnectionFactory factory = parser.newObject(new
URI(tcp://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah), null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream outStream = new ObjectOutputStream(baos);
outStream.writeObject(factory);
outStream.close();
baos.close();
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream in = new ObjectInputStream(bais);
factory = (ActiveMQConnectionFactory) in.readObject();
in.close();
bais.close();
{code}
If I try to use http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah; as
the URI string then I get {{java.lang.NullPointerException: Schema http not
found}}.
Any thoughts on how I can reproduce this in a unit test?
was (Author: jbertram):
Maybe I'm thick, but I can't reproduce this. Here's the quick unit test I
wrote:
{code}
ActiveMQConnectionFactory factory = parser.newObject(new
URI(tcp://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah), null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream outStream = new ObjectOutputStream(baos);
outStream.writeObject(factory);
outStream.close();
baos.close();
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream in = new ObjectInputStream(bais);
factory = (ActiveMQConnectionFactory) in.readObject();
in.close();
bais.close();
{code}
If I try to use http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah; as
the URI string then I get {{java.lang.NullPointerException: Schema http not
found}}.
Any thoughts on how I can reproduce this in a unit test?
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715571#comment-14715571
]
Justin Bertram commented on ARTEMIS-212:
Maybe I'm thick, but I can't reproduce this. Here's the quick unit test I
wrote:
{code}
ActiveMQConnectionFactory factory = parser.newObject(new
URI(tcp://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah), null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream outStream = new ObjectOutputStream(baos);
outStream.writeObject(factory);
outStream.close();
baos.close();
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream in = new ObjectInputStream(bais);
factory = (ActiveMQConnectionFactory) in.readObject();
in.close();
bais.close();
{code}
If I try to use http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah; as
the URI string then I get {{java.lang.NullPointerException: Schema http not
found}}.
Any thoughts on how I can reproduce this in a unit test?
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-206: -- Assignee: Justin Bertram HTTP Upgrade does not work over HTTPS - Key: ARTEMIS-206 URL: https://issues.apache.org/jira/browse/ARTEMIS-206 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 1.0.0 Reporter: Jeff Mesnil Assignee: Justin Bertram For security reasons, we need to support creating Artemis connections over HTTPS Upgrade. Currently, the Upgrade code works only over HTTP. We need to also support it over HTTPS for increased security. This means that the NettyConnector code that deals with httpUpgradeEnabled must also check if sslEnabled is set. If that's the case, the GET request to upgrade the connection must be done over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14718586#comment-14718586 ] Justin Bertram commented on ARTEMIS-206: I'm trying to get a test-case set up for this, but I'm having trouble getting the little web server started in org.apache.activemq.artemis.tests.integration.transports.netty.NettyConnectorWithHTTPUpgradeTest.startWebServer() to handle the SSL handshake from the client. You got any ideas on how to implement that? HTTP Upgrade does not work over HTTPS - Key: ARTEMIS-206 URL: https://issues.apache.org/jira/browse/ARTEMIS-206 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 1.0.0 Reporter: Jeff Mesnil For security reasons, we need to support creating Artemis connections over HTTPS Upgrade. Currently, the Upgrade code works only over HTTP. We need to also support it over HTTPS for increased security. This means that the NettyConnector code that deals with httpUpgradeEnabled must also check if sslEnabled is set. If that's the case, the GET request to upgrade the connection must be done over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14719969#comment-14719969 ] Justin Bertram commented on ARTEMIS-206: Nevermind. I got past the SSL handshake issue. Continuing to investigate... HTTP Upgrade does not work over HTTPS - Key: ARTEMIS-206 URL: https://issues.apache.org/jira/browse/ARTEMIS-206 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 1.0.0 Reporter: Jeff Mesnil Assignee: Justin Bertram For security reasons, we need to support creating Artemis connections over HTTPS Upgrade. Currently, the Upgrade code works only over HTTP. We need to also support it over HTTPS for increased security. This means that the NettyConnector code that deals with httpUpgradeEnabled must also check if sslEnabled is set. If that's the case, the GET request to upgrade the connection must be done over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14723496#comment-14723496 ] Justin Bertram commented on ARTEMIS-206: I made a small change to the NettyConnector to use "https" when SSL is enabled. Do you believe this is sufficient to resolve the issue? > HTTP Upgrade does not work over HTTPS > - > > Key: ARTEMIS-206 > URL: https://issues.apache.org/jira/browse/ARTEMIS-206 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > For security reasons, we need to support creating Artemis connections over > HTTPS Upgrade. > Currently, the Upgrade code works only over HTTP. > We need to also support it over HTTPS for increased security. > This means that the NettyConnector code that deals with httpUpgradeEnabled > must also check if sslEnabled is set. > If that's the case, the GET request to upgrade the connection must be done > over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL > handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14723496#comment-14723496 ] Justin Bertram edited comment on ARTEMIS-206 at 8/31/15 2:48 PM: - I just made a small change to the NettyConnector to use "https" when SSL is enabled. Do you believe this is sufficient to resolve the issue? was (Author: jbertram): I made a small change to the NettyConnector to use "https" when SSL is enabled. Do you believe this is sufficient to resolve the issue? > HTTP Upgrade does not work over HTTPS > - > > Key: ARTEMIS-206 > URL: https://issues.apache.org/jira/browse/ARTEMIS-206 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > For security reasons, we need to support creating Artemis connections over > HTTPS Upgrade. > Currently, the Upgrade code works only over HTTP. > We need to also support it over HTTPS for increased security. > This means that the NettyConnector code that deals with httpUpgradeEnabled > must also check if sslEnabled is set. > If that's the case, the GET request to upgrade the connection must be done > over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL > handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-211) Memory leak using wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-211: --- Fix Version/s: 1.1.0 > Memory leak using wildcard topic > > > Key: ARTEMIS-211 > URL: https://issues.apache.org/jira/browse/ARTEMIS-211 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 > Environment: FreeBSD 10.2+ARTEMIS >Reporter: Huang Wen Hui >Assignee: Justin Bertram > Fix For: 1.1.0 > > Attachments: BindingsImpl.java.patch, Receiver1.java, Receiver2.java, > Sender.java, artemis.log.gz, broker.xml > > > 1. I set up broker.xml use PAGE: > > > > jms.queue.DLQ > jms.queue.ExpiryQueue > 0 > 2097152 > 10485760 > > 10 > PAGE > > > and add 2 topics: > > > 2. before run broker, open DEBUG: > logger.org.apache.activemq.artemis.core.server.level=DEBUG > 3. run Sender.java > 4. run Receiver1.java with rts.* first, and then run Receiver2.java with > rts.pick. > 5. kill Receiver1 and Receiver2. > 6. after about 20 mins, OutOfMemory: > 15:18:28,462 WARN [org.apache.activemq.artemis.core.client] AMQ212037: > Connection failure has been detected: AMQ119014: Did not receive data from > /127.0.0.1:36351. It is likely the client has exited or crashed without > closing its connection, or the network between the server and client has > failed. You also might have configured connection-ttl and > client-failure-check-period incorrectly. Please check user manual for more > information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] > 15:18:41,090 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:18:57,554 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:18:53,474 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:19:03,751 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:11,228 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:29,926 WARN [org.apache.activemq.artemis.core.client] AMQ212041: Timed > out waiting for netty channel to close > 15:19:34,166 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:20:10,078 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > Exception in thread "qtp1326393666-134" Exception in thread "ActiveMQ > Artemis Server Shutdown Timer" Exception in thread "qtp1326393666-130" > Exception in thread "Thread-9 > (ActiveMQ-server-ActiveMQServerImpl::serverUUID=9e8aecec-4a4d-11e5-b7c8-a3ebfe3193a3-589835301)" > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "qtp1326393666-134" > java.lang.OutOfMemoryError: Java heap space > 15:20:28,493 WARNING [io.netty.channel.nio.NioEventLoop] Unexpected exception > in the selector loop.: java.lang.OutOfMemoryError: Java heap space > 15:20:37,701 WARN [org.apache.activemq.artemis.core.server] AMQ222082: error > on connection failure check: java.lang.OutOfMemoryError: Java heap space > at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300) > at java.lang.StringCoding.encode(StringCoding.java:344) > at java.lang.String.getBytes(String.java:906) > at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) > at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) > at java.io.File.exists(File.java:819) > at org.apache.activemq.artemis.cli.commands.Run$1.run(Run.java:134) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > java.lang.OutOfMemoryError: Java heap space > java.lang.OutOfMemoryError: Java heap space > Exception in thread "Thread-3 (activemq-netty-threads-2123444693)" Exception > in thread "activemq-expiry-reaper-thread" java.lang.OutOfMemoryError: Java > heap space > java.lang.OutOfMemoryError: Java heap space > 15:21:04,952 WARNING [io.netty.channel.DefaultChannelPipeline] An > exceptionCaught() event was fired, and it reached at the tail of the > pipeline. It usually means the last handler in the pipeline did not handle > the exception.: io.netty.channel.ChannelPipelineException: >
[jira] [Resolved] (ARTEMIS-211) Memory leak using wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-211. Resolution: Fixed > Memory leak using wildcard topic > > > Key: ARTEMIS-211 > URL: https://issues.apache.org/jira/browse/ARTEMIS-211 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 > Environment: FreeBSD 10.2+ARTEMIS >Reporter: Huang Wen Hui >Assignee: Justin Bertram > Fix For: 1.1.0 > > Attachments: BindingsImpl.java.patch, Receiver1.java, Receiver2.java, > Sender.java, artemis.log.gz, broker.xml > > > 1. I set up broker.xml use PAGE: > > > > jms.queue.DLQ > jms.queue.ExpiryQueue > 0 > 2097152 > 10485760 > > 10 > PAGE > > > and add 2 topics: > > > 2. before run broker, open DEBUG: > logger.org.apache.activemq.artemis.core.server.level=DEBUG > 3. run Sender.java > 4. run Receiver1.java with rts.* first, and then run Receiver2.java with > rts.pick. > 5. kill Receiver1 and Receiver2. > 6. after about 20 mins, OutOfMemory: > 15:18:28,462 WARN [org.apache.activemq.artemis.core.client] AMQ212037: > Connection failure has been detected: AMQ119014: Did not receive data from > /127.0.0.1:36351. It is likely the client has exited or crashed without > closing its connection, or the network between the server and client has > failed. You also might have configured connection-ttl and > client-failure-check-period incorrectly. Please check user manual for more > information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] > 15:18:41,090 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:18:57,554 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:18:53,474 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:19:03,751 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:11,228 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:29,926 WARN [org.apache.activemq.artemis.core.client] AMQ212041: Timed > out waiting for netty channel to close > 15:19:34,166 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:20:10,078 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > Exception in thread "qtp1326393666-134" Exception in thread "ActiveMQ > Artemis Server Shutdown Timer" Exception in thread "qtp1326393666-130" > Exception in thread "Thread-9 > (ActiveMQ-server-ActiveMQServerImpl::serverUUID=9e8aecec-4a4d-11e5-b7c8-a3ebfe3193a3-589835301)" > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "qtp1326393666-134" > java.lang.OutOfMemoryError: Java heap space > 15:20:28,493 WARNING [io.netty.channel.nio.NioEventLoop] Unexpected exception > in the selector loop.: java.lang.OutOfMemoryError: Java heap space > 15:20:37,701 WARN [org.apache.activemq.artemis.core.server] AMQ222082: error > on connection failure check: java.lang.OutOfMemoryError: Java heap space > at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300) > at java.lang.StringCoding.encode(StringCoding.java:344) > at java.lang.String.getBytes(String.java:906) > at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) > at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) > at java.io.File.exists(File.java:819) > at org.apache.activemq.artemis.cli.commands.Run$1.run(Run.java:134) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > java.lang.OutOfMemoryError: Java heap space > java.lang.OutOfMemoryError: Java heap space > Exception in thread "Thread-3 (activemq-netty-threads-2123444693)" Exception > in thread "activemq-expiry-reaper-thread" java.lang.OutOfMemoryError: Java > heap space > java.lang.OutOfMemoryError: Java heap space > 15:21:04,952 WARNING [io.netty.channel.DefaultChannelPipeline] An > exceptionCaught() event was fired, and it reached at the tail of the > pipeline. It usually means the last handler in the pipeline did not handle > the exception.: io.netty.channel.ChannelPipelineException: >
[jira] [Commented] (ARTEMIS-211) Memory leak using wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14711944#comment-14711944 ] Justin Bertram commented on ARTEMIS-211: I've reproduced this and I'm investigating further. Memory leak using wildcard topic Key: ARTEMIS-211 URL: https://issues.apache.org/jira/browse/ARTEMIS-211 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 1.0.0 Environment: FreeBSD 10.2+ARTEMIS Reporter: Huang Wen Hui Assignee: Justin Bertram Attachments: Receiver1.java, Receiver2.java, Sender.java, artemis.log.gz, broker.xml 1. I set up broker.xml use PAGE: address-settings !--default for catch all-- address-setting match=# dead-letter-addressjms.queue.DLQ/dead-letter-address expiry-addressjms.queue.ExpiryQueue/expiry-address redelivery-delay0/redelivery-delay page-size-bytes2097152/page-size-bytes max-size-bytes10485760/max-size-bytes message-counter-history-day-limit10/message-counter-history-day-limit address-full-policyPAGE/address-full-policy /address-setting /address-settings and add 2 topics: topic name=rts.pick/ topic name=rts.nop/ 2. before run broker, open DEBUG: logger.org.apache.activemq.artemis.core.server.level=DEBUG 3. run Sender.java 4. run Receiver1.java with rts.* first, and then run Receiver2.java with rts.pick. 5. kill Receiver1 and Receiver2. 6. after about 20 mins, OutOfMemory: 15:18:28,462 WARN [org.apache.activemq.artemis.core.client] AMQ212037: Connection failure has been detected: AMQ119014: Did not receive data from /127.0.0.1:36351. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] 15:18:41,090 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session a3fafb41-4af7-11e5-8680-adb2aefa8c20 15:18:57,554 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue 15:18:53,474 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session a3fafb41-4af7-11e5-8680-adb2aefa8c20 15:19:03,751 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session a3fc81e2-4af7-11e5-8680-adb2aefa8c20 15:19:11,228 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session a3fc81e2-4af7-11e5-8680-adb2aefa8c20 15:19:29,926 WARN [org.apache.activemq.artemis.core.client] AMQ212041: Timed out waiting for netty channel to close 15:19:34,166 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue 15:20:10,078 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue Exception in thread qtp1326393666-134 Exception in thread ActiveMQ Artemis Server Shutdown Timer Exception in thread qtp1326393666-130 Exception in thread Thread-9 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=9e8aecec-4a4d-11e5-b7c8-a3ebfe3193a3-589835301) Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread qtp1326393666-134 java.lang.OutOfMemoryError: Java heap space 15:20:28,493 WARNING [io.netty.channel.nio.NioEventLoop] Unexpected exception in the selector loop.: java.lang.OutOfMemoryError: Java heap space 15:20:37,701 WARN [org.apache.activemq.artemis.core.server] AMQ222082: error on connection failure check: java.lang.OutOfMemoryError: Java heap space at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300) at java.lang.StringCoding.encode(StringCoding.java:344) at java.lang.String.getBytes(String.java:906) at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) at java.io.File.exists(File.java:819) at org.apache.activemq.artemis.cli.commands.Run$1.run(Run.java:134) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space Exception in thread Thread-3 (activemq-netty-threads-2123444693) Exception in thread activemq-expiry-reaper-thread java.lang.OutOfMemoryError: Java heap space
[jira] [Assigned] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-225: -- Assignee: Justin Bertram > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-224) java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
[
https://issues.apache.org/jira/browse/ARTEMIS-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-224:
--
Assignee: Justin Bertram
> java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
> -
>
> Key: ARTEMIS-224
> URL: https://issues.apache.org/jira/browse/ARTEMIS-224
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Howard Nguyen
>Assignee: Justin Bertram
>
> When configure artemis.profile under bin of the broker installation with
> {code}
> -Dcom.sun.management.jmxremote.port=8686
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dcom.sun.management.jmxremote.ssl=false
> {code}
> Log does not work and console output show the following
> {code}
> Could not load Logmanager "org.jboss.logmanager.LogManager"
> java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.util.logging.LogManager$1.run(LogManager.java:195)
> at java.util.logging.LogManager$1.run(LogManager.java:181)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.(LogManager.java:181)
> at java.util.logging.Logger.demandLogger(Logger.java:448)
> at java.util.logging.Logger.getLogger(Logger.java:502)
> at com.sun.jmx.remote.util.ClassLogger.(ClassLogger.java:55)
> at
> sun.management.jmxremote.ConnectorBootstrap.(ConnectorBootstrap.java:814)
> at sun.management.Agent.startAgent(Agent.java:257)
> at sun.management.Agent.startAgent(Agent.java:447)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14902861#comment-14902861 ] Justin Bertram commented on ARTEMIS-225: [~jmesnil], I don't believe my fix is valid per Clebert's comment above so I'd like to address the NPE at a different level. Can you provide a stack-trace or any further details on the specific API call from the RA which caused the NPE? > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > Fix For: 1.2.0, 1.1.1 > > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-225) Incomplete Activation Validation
[ https://issues.apache.org/jira/browse/ARTEMIS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14902763#comment-14902763 ] Justin Bertram commented on ARTEMIS-225: The "fix" I sent to validate the activation spec breaks the TCK so I'm going to revert that and focus on resolving the NPE itself. [~jmesnil], can you provide a stack-trace for the NPE you're seeing? > Incomplete Activation Validation > > > Key: ARTEMIS-225 > URL: https://issues.apache.org/jira/browse/ARTEMIS-225 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > Fix For: 1.2.0, 1.1.1 > > > When a MDB is deployed with the activation config property > subscriptionDurability set to Durable but without a required clientId > property, it generates NPE in our app server since the RA tries to create a > queue which name is an non-null empty string. > When the Activation validate its spec, it should verify the presence of the > clientId property if the subscriptionDurability is Durable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-314) Support JCA inflow connection rebalancing when reconnectAttempts == -1
[ https://issues.apache.org/jira/browse/ARTEMIS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-314: --- Affects Version/s: 1.1.0 > Support JCA inflow connection rebalancing when reconnectAttempts == -1 > -- > > Key: ARTEMIS-314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-314 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > > Currently the re-balancing implementation will only rebalance when the > underlying connection stops trying to reconnect. If reconnectAttempts == -1 > then rebalancing will never occur. This should be changed so that > rebalancing occurs even if reconnectAttempts == -1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-314) Support JCA inflow connection rebalancing when reconnectAttempts == -1
Justin Bertram created ARTEMIS-314: -- Summary: Support JCA inflow connection rebalancing when reconnectAttempts == -1 Key: ARTEMIS-314 URL: https://issues.apache.org/jira/browse/ARTEMIS-314 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Justin Bertram Assignee: Justin Bertram Currently the re-balancing implementation will only rebalance when the underlying connection stops trying to reconnect. If reconnectAttempts == -1 then rebalancing will never occur. This should be changed so that rebalancing occurs even if reconnectAttempts == -1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic
[
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15047032#comment-15047032
]
Justin Bertram commented on ARTEMIS-303:
Thanks. I've reproduced the exception, and I'm investigating further.
> listDurableSubscriptionsAsJson fails if there is a durable subscription on a
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException:
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> java.security.AccessController.doPrivileged(Native Method)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> javax.security.auth.Subject.doAs(Subject.java:422)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
>
[jira] [Updated] (ARTEMIS-309) Upgrade commons-collections
[ https://issues.apache.org/jira/browse/ARTEMIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-309: --- Fix Version/s: (was: 1.2.0) > Upgrade commons-collections > --- > > Key: ARTEMIS-309 > URL: https://issues.apache.org/jira/browse/ARTEMIS-309 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Claus Ibsen >Assignee: Justin Bertram >Priority: Blocker > Fix For: 1.1.1 > > > Noticed that we use 3.2.1 version of commons collection > https://github.com/apache/activemq-artemis/blob/master/artemis-features/src/main/resources/features.xml#L38 > It should be upgraded to 3.2.2 due the security issue that is fixed in the > 3.2.2 release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-310) Upgrade jolokia to 1.3.2
[ https://issues.apache.org/jira/browse/ARTEMIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-310: --- Affects Version/s: 1.1.0 > Upgrade jolokia to 1.3.2 > > > Key: ARTEMIS-310 > URL: https://issues.apache.org/jira/browse/ARTEMIS-310 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Claus Ibsen >Assignee: Justin Bertram >Priority: Minor > Fix For: 1.1.1 > > > We should upgrade to jolokia 1.3.2 > https://github.com/apache/activemq-artemis/blob/master/pom.xml#L467 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-309) Upgrade commons-collections
[ https://issues.apache.org/jira/browse/ARTEMIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-309: -- Assignee: Justin Bertram > Upgrade commons-collections > --- > > Key: ARTEMIS-309 > URL: https://issues.apache.org/jira/browse/ARTEMIS-309 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Claus Ibsen >Assignee: Justin Bertram >Priority: Blocker > Fix For: 1.2.0, 1.1.1 > > > Noticed that we use 3.2.1 version of commons collection > https://github.com/apache/activemq-artemis/blob/master/artemis-features/src/main/resources/features.xml#L38 > It should be upgraded to 3.2.2 due the security issue that is fixed in the > 3.2.2 release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-310) Upgrade jolokia to 1.3.2
[ https://issues.apache.org/jira/browse/ARTEMIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-310: --- Fix Version/s: (was: 1.2.0) 1.1.1 > Upgrade jolokia to 1.3.2 > > > Key: ARTEMIS-310 > URL: https://issues.apache.org/jira/browse/ARTEMIS-310 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Claus Ibsen >Assignee: Justin Bertram >Priority: Minor > Fix For: 1.1.1 > > > We should upgrade to jolokia 1.3.2 > https://github.com/apache/activemq-artemis/blob/master/pom.xml#L467 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-310) Upgrade jolokia to 1.3.2
[ https://issues.apache.org/jira/browse/ARTEMIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-310. Resolution: Fixed > Upgrade jolokia to 1.3.2 > > > Key: ARTEMIS-310 > URL: https://issues.apache.org/jira/browse/ARTEMIS-310 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Claus Ibsen >Assignee: Justin Bertram >Priority: Minor > Fix For: 1.1.1 > > > We should upgrade to jolokia 1.3.2 > https://github.com/apache/activemq-artemis/blob/master/pom.xml#L467 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-317) Large Message Failure in calling interceptor java.lang.ClassCastException
[ https://issues.apache.org/jira/browse/ARTEMIS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-317: -- Assignee: Justin Bertram > Large Message Failure in calling interceptor java.lang.ClassCastException > - > > Key: ARTEMIS-317 > URL: https://issues.apache.org/jira/browse/ARTEMIS-317 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 > Environment: Artemis 1.1.0, HornetQ 2.4.7 client and Java JDK 1.8.0_65 >Reporter: Raj >Assignee: Justin Bertram > > We download Artemis 1.1.0 and using HornetQ 2.4.7 client publish to > "LargeMSGTest" topic using 5445 port. MSG size is 2032KB XML. > We get following error (ClassCastException) for each Large MSG publication in > the log file. > We are current user of HornetQ and looking for broker because HornetQ support > was close this year. We are happy to see Artemis which support hornetQ. > Please provide workaround or anyfix. Thank you in advance. > AMQ212038: Failure in calling interceptor: > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor@443b9ce4: > java.lang.ClassCastException: > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage > cannot be cast to > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.MessagePacket. > Here is log file content. > 09:21:12,002 INFO [org.apache.activemq.artemis.integration.bootstrap] > AMQ101000: Starting ActiveMQ Artemis Server > 09:21:12,034 INFO [org.apache.activemq.artemis.core.server] AMQ221000: live > Message Broker is starting with configuration Broker Configuration > (clustered=false,journalDirectory=./data/journal,bindingsDirectory=./data/bindings,largeMessagesDirectory=./data/large-messages,pagingDirectory=./data/paging) > 09:21:12,112 INFO [org.apache.activemq.artemis.core.server] AMQ221013: Using > NIO Journal > 09:21:12,268 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-server]. Adding protocol support for: CORE > 09:21:12,299 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: > AMQP > 09:21:12,346 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-hornetq-protocol]. Adding protocol support > for: HORNETQ > 09:21:12,362 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: > MQTT > 09:21:12,409 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-openwire-protocol]. Adding protocol support > for: OPENWIRE > 09:21:12,627 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: > STOMP > 09:21:29,671 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > trying to deploy queue jms.queue.DLQ > 09:21:29,687 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > trying to deploy queue jms.queue.ExpiryQueue > 09:21:29,703 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > trying to deploy queue jms.topic.LargeMSGTest > 09:21:30,374 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:5445 for protocols [HORNETQ,STOMP] > 09:21:30,515 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:61613 for protocols [STOMP] > 09:21:30,546 INFO [org.apache.activemq.artemis.core.server] AMQ221007: > Server is now live > 09:21:30,546 INFO [org.apache.activemq.artemis.core.server] AMQ221001: > Apache ActiveMQ Artemis Message Broker version 1.1.0 > [nodeID=62fcb50e-99ef-11e5-b584-372f138c390d] > 09:22:53,634 WARN [org.apache.activemq.artemis.core.client] AMQ212038: > Failure in calling interceptor: > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor@443b9ce4: > java.lang.ClassCastException: > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage > cannot be cast to > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.MessagePacket > at > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor.intercept(HQPropertiesConversionInterceptor.java:71) > [artemis-hornetq-protocol-1.1.0.jar:1.1.0] > at > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor.intercept(HQPropertiesConversionInterceptor.java:34) > [artemis-hornetq-protocol-1.1.0.jar:1.1.0] > at >
[jira] [Assigned] (ARTEMIS-310) Upgrade jolokia to 1.3.2
[ https://issues.apache.org/jira/browse/ARTEMIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-310: -- Assignee: Justin Bertram > Upgrade jolokia to 1.3.2 > > > Key: ARTEMIS-310 > URL: https://issues.apache.org/jira/browse/ARTEMIS-310 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Claus Ibsen >Assignee: Justin Bertram >Priority: Minor > Fix For: 1.2.0 > > > We should upgrade to jolokia 1.3.2 > https://github.com/apache/activemq-artemis/blob/master/pom.xml#L467 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-317) Large Message Failure in calling interceptor java.lang.ClassCastException
[ https://issues.apache.org/jira/browse/ARTEMIS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15048957#comment-15048957 ] Justin Bertram commented on ARTEMIS-317: Can you try this on the "master" branch from our Git repo? HornetQ client support has been refactored a bit since 1.1.0 was released. > Large Message Failure in calling interceptor java.lang.ClassCastException > - > > Key: ARTEMIS-317 > URL: https://issues.apache.org/jira/browse/ARTEMIS-317 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 > Environment: Artemis 1.1.0, HornetQ 2.4.7 client and Java JDK 1.8.0_65 >Reporter: Raj >Assignee: Justin Bertram > > We download Artemis 1.1.0 and using HornetQ 2.4.7 client publish to > "LargeMSGTest" topic using 5445 port. MSG size is 2032KB XML. > We get following error (ClassCastException) for each Large MSG publication in > the log file. > We are current user of HornetQ and looking for broker because HornetQ support > was close this year. We are happy to see Artemis which support hornetQ. > Please provide workaround or anyfix. Thank you in advance. > AMQ212038: Failure in calling interceptor: > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor@443b9ce4: > java.lang.ClassCastException: > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage > cannot be cast to > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.MessagePacket. > Here is log file content. > 09:21:12,002 INFO [org.apache.activemq.artemis.integration.bootstrap] > AMQ101000: Starting ActiveMQ Artemis Server > 09:21:12,034 INFO [org.apache.activemq.artemis.core.server] AMQ221000: live > Message Broker is starting with configuration Broker Configuration > (clustered=false,journalDirectory=./data/journal,bindingsDirectory=./data/bindings,largeMessagesDirectory=./data/large-messages,pagingDirectory=./data/paging) > 09:21:12,112 INFO [org.apache.activemq.artemis.core.server] AMQ221013: Using > NIO Journal > 09:21:12,268 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-server]. Adding protocol support for: CORE > 09:21:12,299 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: > AMQP > 09:21:12,346 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-hornetq-protocol]. Adding protocol support > for: HORNETQ > 09:21:12,362 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: > MQTT > 09:21:12,409 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-openwire-protocol]. Adding protocol support > for: OPENWIRE > 09:21:12,627 INFO [org.apache.activemq.artemis.core.server] AMQ221043: > Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: > STOMP > 09:21:29,671 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > trying to deploy queue jms.queue.DLQ > 09:21:29,687 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > trying to deploy queue jms.queue.ExpiryQueue > 09:21:29,703 INFO [org.apache.activemq.artemis.core.server] AMQ221003: > trying to deploy queue jms.topic.LargeMSGTest > 09:21:30,374 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:5445 for protocols [HORNETQ,STOMP] > 09:21:30,515 INFO [org.apache.activemq.artemis.core.server] AMQ221020: > Started Acceptor at 0.0.0.0:61613 for protocols [STOMP] > 09:21:30,546 INFO [org.apache.activemq.artemis.core.server] AMQ221007: > Server is now live > 09:21:30,546 INFO [org.apache.activemq.artemis.core.server] AMQ221001: > Apache ActiveMQ Artemis Message Broker version 1.1.0 > [nodeID=62fcb50e-99ef-11e5-b584-372f138c390d] > 09:22:53,634 WARN [org.apache.activemq.artemis.core.client] AMQ212038: > Failure in calling interceptor: > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor@443b9ce4: > java.lang.ClassCastException: > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionSendLargeMessage > cannot be cast to > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.MessagePacket > at > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor.intercept(HQPropertiesConversionInterceptor.java:71) > [artemis-hornetq-protocol-1.1.0.jar:1.1.0] > at > org.apache.activemq.artemis.core.protocol.hornetq.HQPropertiesConversionInterceptor.intercept(HQPropertiesConversionInterceptor.java:34) >
[jira] [Resolved] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic
[
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-303.
Resolution: Fixed
> listDurableSubscriptionsAsJson fails if there is a durable subscription on a
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException:
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> java.security.AccessController.doPrivileged(Native Method)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> javax.security.auth.Subject.doAs(Subject.java:422)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4)
[jira] [Updated] (ARTEMIS-315) NullPointerException when trying to list prepared transactions as JSON
[ https://issues.apache.org/jira/browse/ARTEMIS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-315: --- Fix Version/s: 1.1.1 > NullPointerException when trying to list prepared transactions as JSON > -- > > Key: ARTEMIS-315 > URL: https://issues.apache.org/jira/browse/ARTEMIS-315 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 > Environment: Artemis >Reporter: Tom Ross > Fix For: 1.1.1 > > > There is possibility of getting NullPointerException when trying to JMX > operation listPreperedTransactionDetailsAsJSON on the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-315) NullPointerException when trying to list prepared transactions as JSON
[ https://issues.apache.org/jira/browse/ARTEMIS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-315. Resolution: Fixed Assignee: Justin Bertram This looks fixed so I'm resolving it. Feel free to comment otherwise. > NullPointerException when trying to list prepared transactions as JSON > -- > > Key: ARTEMIS-315 > URL: https://issues.apache.org/jira/browse/ARTEMIS-315 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 > Environment: Artemis >Reporter: Tom Ross >Assignee: Justin Bertram > Fix For: 1.1.1 > > > There is possibility of getting NullPointerException when trying to JMX > operation listPreperedTransactionDetailsAsJSON on the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-312: -- Assignee: Justin Bertram > Artemis clients use by default an unbounded global thread pool > -- > > Key: ARTEMIS-312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-312 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > While investigating some performance issues, we noticed that Artemis clients > (including MDBs) use by default a "global" pool by creating a cached thread > pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive. > This default global pool looks misconfigured. If a Artemis clients has a lot > of activity it is actually possible that threads are deleted from the pool > and added back. > Related to this, Artemis defines a threadPoolMaxSize attribute if the client > is not using a global pool. But the property does not seem to be well name. > If the Artemis client is using a "non-global" pool, this property is used to > create a newFixedThreadPool. So this property defines the actual size of the > pool, not a max size. > As a comparison, the "global" scheduled thread is instantiating with a 5 core > pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[
https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15049330#comment-15049330
]
Justin Bertram commented on ARTEMIS-312:
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
Can you elaborate on this possible use-case? Are you talking about, for
example, a client with short, heavy bursts of activity where a lot of threads
may be created in the cached thread pool and then would time-out after 60
seconds and be removed only to have threads be created again during the next
burst of activity?
Would you prefer the ability to define the "core" size of this thread pool so
that a certain number of threads would always be retained in the pool?
> If the Artemis client is using a "non-global" pool, {{threadPoolMaxSize}} is
> used to create a newFixedThreadPool. So this property defines the actual size
> of the pool, not a max size.
The value for threadPoolMaxSize is passed as the first parameter to
java.util.concurrent.Executors#newFixedThreadPool(int,
java.util.concurrent.ThreadFactory) which ultimately defines _both_ the "core"
size and the "max" size of the thread pool.
> Artemis clients use by default an unbounded global thread pool
> --
>
> Key: ARTEMIS-312
> URL: https://issues.apache.org/jira/browse/ARTEMIS-312
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
>
> While investigating some performance issues, we noticed that Artemis clients
> (including MDBs) use by default a "global" pool by creating a cached thread
> pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive.
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
> Related to this, Artemis defines a threadPoolMaxSize attribute if the client
> is not using a global pool. But the property does not seem to be well name.
> If the Artemis client is using a "non-global" pool, this property is used to
> create a newFixedThreadPool. So this property defines the actual size of the
> pool, not a max size.
> As a comparison, the "global" scheduled thread is instantiating with a 5 core
> pool size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[
https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15049330#comment-15049330
]
Justin Bertram edited comment on ARTEMIS-312 at 12/9/15 8:22 PM:
-
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
Can you elaborate on this possible use-case? Are you talking about, for
example, a client with short, heavy bursts of activity where a lot of threads
may be created in the cached thread pool and then would time-out after 60
seconds and be removed only to have threads be created again during the next
burst of activity?
Would you prefer the ability to define the "core" size of this thread pool so
that a certain number of threads would always be retained in the pool?
> If the Artemis client is using a "non-global" pool, {{threadPoolMaxSize}} is
> used to create a newFixedThreadPool. So this property defines the actual size
> of the pool, not a max size.
The value for threadPoolMaxSize is passed as the first parameter to
java.util.concurrent.Executors#newFixedThreadPool(int,
java.util.concurrent.ThreadFactory) which ultimately defines _both_ the "core"
size and the "max" size of the thread pool.
Is your concern here that it's not clear based on the name of
{{threadPoolMaxSize}} that it applies only to the "non-global"?
BTW, much of this is discussed in the documentation (e.g.
[http://activemq.apache.org/artemis/docs/1.1.0/thread-pooling.html])
was (Author: jbertram):
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
Can you elaborate on this possible use-case? Are you talking about, for
example, a client with short, heavy bursts of activity where a lot of threads
may be created in the cached thread pool and then would time-out after 60
seconds and be removed only to have threads be created again during the next
burst of activity?
Would you prefer the ability to define the "core" size of this thread pool so
that a certain number of threads would always be retained in the pool?
> If the Artemis client is using a "non-global" pool, {{threadPoolMaxSize}} is
> used to create a newFixedThreadPool. So this property defines the actual size
> of the pool, not a max size.
The value for threadPoolMaxSize is passed as the first parameter to
java.util.concurrent.Executors#newFixedThreadPool(int,
java.util.concurrent.ThreadFactory) which ultimately defines _both_ the "core"
size and the "max" size of the thread pool.
> Artemis clients use by default an unbounded global thread pool
> --
>
> Key: ARTEMIS-312
> URL: https://issues.apache.org/jira/browse/ARTEMIS-312
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
>
> While investigating some performance issues, we noticed that Artemis clients
> (including MDBs) use by default a "global" pool by creating a cached thread
> pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive.
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
> Related to this, Artemis defines a threadPoolMaxSize attribute if the client
> is not using a global pool. But the property does not seem to be well name.
> If the Artemis client is using a "non-global" pool, this property is used to
> create a newFixedThreadPool. So this property defines the actual size of the
> pool, not a max size.
> As a comparison, the "global" scheduled thread is instantiating with a 5 core
> pool size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-318) Allow extra settings on command line for JVM (remote JMX & binding port already in use when stopping broker)
[ https://issues.apache.org/jira/browse/ARTEMIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051688#comment-15051688 ] Justin Bertram commented on ARTEMIS-318: I was able to reproduce this. As far as I can tell the problem occurs because the artemis.profile is used for both the "run" and "stop" commands and the presence of the "com.sun.management.jmxremote.port" system property causes the JVM to automatically start listening on that port in both cases. This behavior makes sense for the "run" command, but it doesn't make sense for the "stop" command. I'm still investigating potential solutions. > Allow extra settings on command line for JVM (remote JMX & binding port > already in use when stopping broker) > - > > Key: ARTEMIS-318 > URL: https://issues.apache.org/jira/browse/ARTEMIS-318 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 > Environment: all >Reporter: Michal Toth >Assignee: Justin Bertram > Labels: features > > I have been using remote JMX with Artemis for few weeks so far, > but lately, I have noticed, that I am not able to shutdown the Artemis > gracefully via 'artemis stop' nor 'artemis-service stop' when JMX is set up. > Here is my scenario: > 1) Add system properties to java (/etc/artemis.profile): > JAVA_ARGS+="-Dcom.sun.management.jmxremote=true > -Dcom.sun.management.jmxremote.port=1099 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false " > 2) Start the broker > 3) Do JMX "queries", send messages, everything works fine > 4) bin/artemis stop > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 1099; nested exception is: > java.net.BindException: Address already in use > It does not matter what port number I use. > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 3099; nested exception is: > java.net.BindException: Address already in use > 5) I have kill the artemis process (SIGTERM is sufficient) to stop it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051654#comment-15051654 ] Justin Bertram commented on ARTEMIS-312: As I'm sure you understand, a message broker is a complex piece of software and the default configuration will not be optimal for every particular use-case. The bottom line here is that certain choices must be made. Here's a simple example. In earlier versions of HornetQ using Netty 3.x we had to choose between using blocking IO by default or non-blocking IO by default for remote clients. Blocking IO would provide the lowest latency for a small number of connections, but wouldn't scale well (and would be "dangerous" under heavy load due to all the threads required to service remote connections). Non-blocking IO would scale well but with a small latency penalty. We chose to go with blocking IO by default and documented both configuration options clearly. The same basic scenario plays out hundreds of different ways across the broker's configuration. I've been working with HornetQ for a number of years now, and I don't often hear users complain about the default thread pool configuration. That leads me to believe that the default thread pool configuration is likely suitable for most use-cases. We've tried to make the defaults _sensible_, but of course even that is up for debate depending on your perspective. You're certainly free to think that the default configuration is "wide-opened-unrealistic," but I hope you'd also grant there are other reasonable opinions on that. The definition of "production ready" is as varied as the number of production environments. > Artemis clients use by default an unbounded global thread pool > -- > > Key: ARTEMIS-312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-312 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > While investigating some performance issues, we noticed that Artemis clients > (including MDBs) use by default a "global" pool by creating a cached thread > pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive. > This default global pool looks misconfigured. If a Artemis clients has a lot > of activity it is actually possible that threads are deleted from the pool > and added back. > Related to this, Artemis defines a threadPoolMaxSize attribute if the client > is not using a global pool. But the property does not seem to be well name. > If the Artemis client is using a "non-global" pool, this property is used to > create a newFixedThreadPool. So this property defines the actual size of the > pool, not a max size. > As a comparison, the "global" scheduled thread is instantiating with a 5 core > pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-318) Allow extra settings on command line for JVM (remote JMX & binding port already in use when stopping broker)
[ https://issues.apache.org/jira/browse/ARTEMIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-318: -- Assignee: Justin Bertram > Allow extra settings on command line for JVM (remote JMX & binding port > already in use when stopping broker) > - > > Key: ARTEMIS-318 > URL: https://issues.apache.org/jira/browse/ARTEMIS-318 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 > Environment: all >Reporter: Michal Toth >Assignee: Justin Bertram > Labels: features > > I have been using remote JMX with Artemis for few weeks so far, > but lately, I have noticed, that I am not able to shutdown the Artemis > gracefully via 'artemis stop' nor 'artemis-service stop' when JMX is set up. > Here is my scenario: > 1) Add system properties to java (/etc/artemis.profile): > JAVA_ARGS+="-Dcom.sun.management.jmxremote=true > -Dcom.sun.management.jmxremote.port=1099 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false " > 2) Start the broker > 3) Do JMX "queries", send messages, everything works fine > 4) bin/artemis stop > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 1099; nested exception is: > java.net.BindException: Address already in use > It does not matter what port number I use. > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 3099; nested exception is: > java.net.BindException: Address already in use > 5) I have kill the artemis process (SIGTERM is sufficient) to stop it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051748#comment-15051748 ] Justin Bertram commented on ARTEMIS-312: To Clebert's point, we can certainly add more configuration options for the client thread pools and even change the defaults (which I was trying to clarify in my first response to [~jmesnil]). Do you have any specific suggestions about what you would like to see changed here, [~Glaucio Melo]? > Artemis clients use by default an unbounded global thread pool > -- > > Key: ARTEMIS-312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-312 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > While investigating some performance issues, we noticed that Artemis clients > (including MDBs) use by default a "global" pool by creating a cached thread > pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive. > This default global pool looks misconfigured. If a Artemis clients has a lot > of activity it is actually possible that threads are deleted from the pool > and added back. > Related to this, Artemis defines a threadPoolMaxSize attribute if the client > is not using a global pool. But the property does not seem to be well name. > If the Artemis client is using a "non-global" pool, this property is used to > create a newFixedThreadPool. So this property defines the actual size of the > pool, not a max size. > As a comparison, the "global" scheduled thread is instantiating with a 5 core > pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051748#comment-15051748 ] Justin Bertram edited comment on ARTEMIS-312 at 12/10/15 10:17 PM: --- To [~clebertsuconic]'s point, we can certainly add more configuration options for the client thread pools and even change the defaults (which I was trying to clarify in my first response to [~jmesnil]). Do you have any specific suggestions about what you would like to see changed here, [~Glaucio Melo]? was (Author: jbertram): To Clebert's point, we can certainly add more configuration options for the client thread pools and even change the defaults (which I was trying to clarify in my first response to [~jmesnil]). Do you have any specific suggestions about what you would like to see changed here, [~Glaucio Melo]? > Artemis clients use by default an unbounded global thread pool > -- > > Key: ARTEMIS-312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-312 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > While investigating some performance issues, we noticed that Artemis clients > (including MDBs) use by default a "global" pool by creating a cached thread > pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive. > This default global pool looks misconfigured. If a Artemis clients has a lot > of activity it is actually possible that threads are deleted from the pool > and added back. > Related to this, Artemis defines a threadPoolMaxSize attribute if the client > is not using a global pool. But the property does not seem to be well name. > If the Artemis client is using a "non-global" pool, this property is used to > create a newFixedThreadPool. So this property defines the actual size of the > pool, not a max size. > As a comparison, the "global" scheduled thread is instantiating with a 5 core > pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053027#comment-15053027 ] Justin Bertram edited comment on ARTEMIS-312 at 12/11/15 5:06 PM: -- [~clebertsuconic], JNDI would be appealing for anybody who doesn't want to put implementation classes in their code. I'm not sure what you mean by, "...things get messed up as you would have only the last one affecting the setting." Can you clarify this point? was (Author: jbertram): JNDI would be appealing for anybody who doesn't want to put implementation classes in their code. I'm not sure what you mean by, "...things get messed up as you would have only the last one affecting the setting." Can you clarify this point? > Artemis clients use by default an unbounded global thread pool > -- > > Key: ARTEMIS-312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-312 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > While investigating some performance issues, we noticed that Artemis clients > (including MDBs) use by default a "global" pool by creating a cached thread > pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive. > This default global pool looks misconfigured. If a Artemis clients has a lot > of activity it is actually possible that threads are deleted from the pool > and added back. > Related to this, Artemis defines a threadPoolMaxSize attribute if the client > is not using a global pool. But the property does not seem to be well name. > If the Artemis client is using a "non-global" pool, this property is used to > create a newFixedThreadPool. So this property defines the actual size of the > pool, not a max size. > As a comparison, the "global" scheduled thread is instantiating with a 5 core > pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053027#comment-15053027 ] Justin Bertram commented on ARTEMIS-312: JNDI would be appealing for anybody who doesn't want to put implementation classes in their code. I'm not sure what you mean by, "...things get messed up as you would have only the last one affecting the setting." Can you clarify this point? > Artemis clients use by default an unbounded global thread pool > -- > > Key: ARTEMIS-312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-312 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.1.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > While investigating some performance issues, we noticed that Artemis clients > (including MDBs) use by default a "global" pool by creating a cached thread > pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive. > This default global pool looks misconfigured. If a Artemis clients has a lot > of activity it is actually possible that threads are deleted from the pool > and added back. > Related to this, Artemis defines a threadPoolMaxSize attribute if the client > is not using a global pool. But the property does not seem to be well name. > If the Artemis client is using a "non-global" pool, this property is used to > create a newFixedThreadPool. So this property defines the actual size of the > pool, not a max size. > As a comparison, the "global" scheduled thread is instantiating with a 5 core > pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
