[jira] [Created] (AMQ-6126) The corePoolSize value of the TaskRunnerFactory created Executor should be configurable
Timothy Bish created AMQ-6126: - Summary: The corePoolSize value of the TaskRunnerFactory created Executor should be configurable Key: AMQ-6126 URL: https://issues.apache.org/jira/browse/AMQ-6126 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.13.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 5.13.1, 5.14.0 It is currently not possible to alter the corePoolSize value of the Executor created in the TaskRunnerFactory in order to keep some Threads always active and avoid some Thread churn that might otherwise happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6124) failover backup transports do not update the brokerInfo leaving stale org.apache.activemq.ActiveMQConnection#getBrokerName
[
https://issues.apache.org/jira/browse/AMQ-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098297#comment-15098297
]
ASF subversion and git services commented on AMQ-6124:
--
Commit 741ee01e11f2805d84d45996f70996687026993c in activemq's branch
refs/heads/activemq-5.13.x from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=741ee01 ]
https://issues.apache.org/jira/browse/AMQ-6124 - fix and test - propagate
broker info from prestarted backup transport
(cherry picked from commit db1506a5921f70134c3b647cec51204f0e1c1416)
> failover backup transports do not update the brokerInfo leaving stale
> org.apache.activemq.ActiveMQConnection#getBrokerName
> --
>
> Key: AMQ-6124
> URL: https://issues.apache.org/jira/browse/AMQ-6124
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.13.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Minor
> Labels: backup, failover, priorityBackup
> Fix For: 5.14.0
>
>
> with broker url {code}failover:(tcp://a:,tcp://b:
> ")?randomize=false=true{code} The brokerName as reported by
> org.apache.activemq.ActiveMQConnection#getBrokerName stays at A even after
> failover to B.
> The backup transport are started up front and the brokerInfo is not cached so
> it never gets replayed to the jms connection.
> The same is true for the backup attribute
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6126) The corePoolSize value of the TaskRunnerFactory created Executor should be configurable
[ https://issues.apache.org/jira/browse/AMQ-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098269#comment-15098269 ] ASF subversion and git services commented on AMQ-6126: -- Commit 543851ba54fe624fac1245c5ef2859dc6db0af19 in activemq's branch refs/heads/activemq-5.13.x from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=543851b ] https://issues.apache.org/jira/browse/AMQ-6126 Add more configuration options to TaskRunnerFactory (cherry picked from commit ebcc1b4eae194553e2e9764d9e0c337e0efc320f) > The corePoolSize value of the TaskRunnerFactory created Executor should be > configurable > --- > > Key: AMQ-6126 > URL: https://issues.apache.org/jira/browse/AMQ-6126 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.13.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.13.1, 5.14.0 > > > It is currently not possible to alter the corePoolSize value of the Executor > created in the TaskRunnerFactory in order to keep some Threads always active > and avoid some Thread churn that might otherwise happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-347) support URI on cluster connections
clebert suconic created ARTEMIS-347: --- Summary: support URI on cluster connections Key: ARTEMIS-347 URL: https://issues.apache.org/jira/browse/ARTEMIS-347 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: clebert suconic Fix For: 1.3.0 Using an URI to specify the cluster connection would simplify how the configuration is done. This is specially used on simplifying the migration of a lot of openwire tests, but in the end it will also simplify how users can configure the cluster connection being a lot less verbose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-334) Add Management browse functionality similar to ActiveMQ
[ https://issues.apache.org/jira/browse/ARTEMIS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Taylor resolved ARTEMIS-334. - Resolution: Fixed > Add Management browse functionality similar to ActiveMQ > --- > > Key: ARTEMIS-334 > URL: https://issues.apache.org/jira/browse/ARTEMIS-334 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.1.0 >Reporter: Andy Taylor >Assignee: Andy Taylor > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6117) QueueView method output is not in sync with actual queue
[ https://issues.apache.org/jira/browse/AMQ-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15099117#comment-15099117 ] ASF subversion and git services commented on AMQ-6117: -- Commit 5b73ffad6bd000fdad93bc473900b2374d36181a in activemq's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=5b73ffa ] https://issues.apache.org/jira/browse/AMQ-6117 Test to try and reproduce the issue. > QueueView method output is not in sync with actual queue > > > Key: AMQ-6117 > URL: https://issues.apache.org/jira/browse/AMQ-6117 > Project: ActiveMQ > Issue Type: Bug > Components: JMX >Affects Versions: 5.13.0 >Reporter: Jo Vandermeeren > > After upgrading from 5.10.2 to 5.13.0, it seems that the data provided by the > QueueView methods is not in sync with the actual queue. > When removing messages from the DLQ via QueueView.removeMessage(String), the > message is actually removed from the queue but QueueView.browse() still lists > the message. > When new messages arrive on the DLQ via JMS, the output of QueueView.browse() > still lists the stale message. > Only when an action is performed via the ActiveMQ admin console (e.g. refresh > browse.jsp for that queue) the JMX output is refreshed. > The QueueSize attribute of the queue however, is always accurate when > accessed via JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-6117) QueueView method output is not in sync with actual queue
[ https://issues.apache.org/jira/browse/AMQ-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-6117. - Resolution: Cannot Reproduce Created a unit test for this and I can't reproduce it, reopen if you can reproduce in a JUnit test case. I added AMQ6117Test.java to activemq-unit-tests if you want to try and work with that test > QueueView method output is not in sync with actual queue > > > Key: AMQ-6117 > URL: https://issues.apache.org/jira/browse/AMQ-6117 > Project: ActiveMQ > Issue Type: Bug > Components: JMX >Affects Versions: 5.13.0 >Reporter: Jo Vandermeeren > > After upgrading from 5.10.2 to 5.13.0, it seems that the data provided by the > QueueView methods is not in sync with the actual queue. > When removing messages from the DLQ via QueueView.removeMessage(String), the > message is actually removed from the queue but QueueView.browse() still lists > the message. > When new messages arrive on the DLQ via JMS, the output of QueueView.browse() > still lists the stale message. > Only when an action is performed via the ActiveMQ admin console (e.g. refresh > browse.jsp for that queue) the JMX output is refreshed. > The QueueSize attribute of the queue however, is always accurate when > accessed via JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6127) Broker to not log "Could not accept connection" as error during shutdown
Martin Lichtin created AMQ-6127: --- Summary: Broker to not log "Could not accept connection" as error during shutdown Key: AMQ-6127 URL: https://issues.apache.org/jira/browse/AMQ-6127 Project: ActiveMQ Issue Type: Wish Components: Broker Affects Versions: 5.12.2 Reporter: Martin Lichtin Priority: Trivial Broker emits 2016-01-14 22:50:21,972 | ERROR | t.maxFrameSize=104857600 | TransportConnector | vemq.broker.TransportConnector$1 242 | 163 - org.apache.activemq.activemq-osgi - 5.12.2 | Could not accept connection : java.lang.InterruptedException during shutdown. Can the log level be reduced to WARN? I don't see this as an error situation. Also, the thread name is no longer recognizable, not sure it needs to include the options? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6108) SelectorManager Executor is not shutdown when transport os stopped.
[ https://issues.apache.org/jira/browse/AMQ-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098910#comment-15098910 ] Timothy Bish commented on AMQ-6108: --- Since the SelectorManager instance is shared amongst every Transport instance created when using the NIOTransport types it doesn't make any sense to shutdown the executor when any one instance is stopped, or when any one TransportConnector instance is stopped as that defeats the purpose of the NIO bits sharing resources. The Threads in the executor should be set deamon though in order to prevent them keeping a JVM running. > SelectorManager Executor is not shutdown when transport os stopped. > --- > > Key: AMQ-6108 > URL: https://issues.apache.org/jira/browse/AMQ-6108 > Project: ActiveMQ > Issue Type: Bug >Reporter: Andy Gumbrecht > Fix For: 5.13.1 > > Attachments: SelectorManager.Shutdown.patch > > > SelectorManager creates an Executor that is not shut down on termination of > the Transport. > The Executor currently uses non-daemon threads and is is not guaranteed the > the SelectorWorker thread exit condition is ever met. > This causes the shutdown to hang when using transports that utilise the > SelectorManager, such as nio+ssl for example. > The proposed patch shuts down the ExecutorService on/after Transport > shutdown. The SelectorWorkers also check for this as an exit condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-6126) The corePoolSize value of the TaskRunnerFactory created Executor should be configurable
[
https://issues.apache.org/jira/browse/AMQ-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098271#comment-15098271
]
Timothy Bish edited comment on AMQ-6126 at 1/14/16 3:46 PM:
Add additional system properties that can be used to configure core pool size
and maximum pool size.
{noformat}
org.apache.activemq.thread.TaskRunnerFactory.corePoolSize default = 0
org.apache.activemq.thread.TaskRunnerFactory.maximumPoolSize default =
Integer.MAX_VALUE
org.apache.activemq.thread.TaskRunnerFactory.keepAliveTime default = 30
{noformat}
was (Author: tabish121):
{noformat}
org.apache.activemq.thread.TaskRunnerFactory.corePoolSize default = 0
org.apache.activemq.thread.TaskRunnerFactory.maximumPoolSize default =
Integer.MAX_VALUE
org.apache.activemq.thread.TaskRunnerFactory.keepAliveTime default = 30
{noformat}
> The corePoolSize value of the TaskRunnerFactory created Executor should be
> configurable
> ---
>
> Key: AMQ-6126
> URL: https://issues.apache.org/jira/browse/AMQ-6126
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.13.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.13.1, 5.14.0
>
>
> It is currently not possible to alter the corePoolSize value of the Executor
> created in the TaskRunnerFactory in order to keep some Threads always active
> and avoid some Thread churn that might otherwise happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-6126) The corePoolSize value of the TaskRunnerFactory created Executor should be configurable
[ https://issues.apache.org/jira/browse/AMQ-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-6126. --- Resolution: Fixed > The corePoolSize value of the TaskRunnerFactory created Executor should be > configurable > --- > > Key: AMQ-6126 > URL: https://issues.apache.org/jira/browse/AMQ-6126 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.13.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.13.1, 5.14.0 > > > It is currently not possible to alter the corePoolSize value of the Executor > created in the TaskRunnerFactory in order to keep some Threads always active > and avoid some Thread churn that might otherwise happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6126) The corePoolSize value of the TaskRunnerFactory created Executor should be configurable
[
https://issues.apache.org/jira/browse/AMQ-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098271#comment-15098271
]
Timothy Bish commented on AMQ-6126:
---
{noformat}
org.apache.activemq.thread.TaskRunnerFactory.corePoolSize default = 0
org.apache.activemq.thread.TaskRunnerFactory.maximumPoolSize default =
Integer.MAX_VALUE
org.apache.activemq.thread.TaskRunnerFactory.keepAliveTime default = 30
{noformat}
> The corePoolSize value of the TaskRunnerFactory created Executor should be
> configurable
> ---
>
> Key: AMQ-6126
> URL: https://issues.apache.org/jira/browse/AMQ-6126
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.13.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.13.1, 5.14.0
>
>
> It is currently not possible to alter the corePoolSize value of the Executor
> created in the TaskRunnerFactory in order to keep some Threads always active
> and avoid some Thread churn that might otherwise happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6126) The corePoolSize value of the TaskRunnerFactory created Executor should be configurable
[ https://issues.apache.org/jira/browse/AMQ-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098266#comment-15098266 ] ASF subversion and git services commented on AMQ-6126: -- Commit ebcc1b4eae194553e2e9764d9e0c337e0efc320f in activemq's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ebcc1b4 ] https://issues.apache.org/jira/browse/AMQ-6126 Add more configuration options to TaskRunnerFactory > The corePoolSize value of the TaskRunnerFactory created Executor should be > configurable > --- > > Key: AMQ-6126 > URL: https://issues.apache.org/jira/browse/AMQ-6126 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.13.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.13.1, 5.14.0 > > > It is currently not possible to alter the corePoolSize value of the Executor > created in the TaskRunnerFactory in order to keep some Threads always active > and avoid some Thread churn that might otherwise happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-346) Add Management send text message functionality similar to ActiveMQ
Andy Taylor created ARTEMIS-346: --- Summary: Add Management send text message functionality similar to ActiveMQ Key: ARTEMIS-346 URL: https://issues.apache.org/jira/browse/ARTEMIS-346 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: Andy Taylor Assignee: Andy Taylor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6108) SelectorManager Executor is not shutdown when transport os stopped.
[ https://issues.apache.org/jira/browse/AMQ-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098940#comment-15098940 ] ASF subversion and git services commented on AMQ-6108: -- Commit 5adbafef3b9ec05de7186caa9112f3639c7a6253 in activemq's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=5adbafe ] https://issues.apache.org/jira/browse/AMQ-6108 Ensure that executor threads are created as daemon threads, fix a try/finaly block, clean up some warnings. > SelectorManager Executor is not shutdown when transport os stopped. > --- > > Key: AMQ-6108 > URL: https://issues.apache.org/jira/browse/AMQ-6108 > Project: ActiveMQ > Issue Type: Bug >Reporter: Andy Gumbrecht > Fix For: 5.13.1 > > Attachments: SelectorManager.Shutdown.patch > > > SelectorManager creates an Executor that is not shut down on termination of > the Transport. > The Executor currently uses non-daemon threads and is is not guaranteed the > the SelectorWorker thread exit condition is ever met. > This causes the shutdown to hang when using transports that utilise the > SelectorManager, such as nio+ssl for example. > The proposed patch shuts down the ExecutorService on/after Transport > shutdown. The SelectorWorkers also check for this as an exit condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6108) SelectorManager Executor is not shutdown when transport os stopped.
[ https://issues.apache.org/jira/browse/AMQ-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098943#comment-15098943 ] ASF subversion and git services commented on AMQ-6108: -- Commit 1d9fdbcbeaacf2d5673bb5435b1caae0b1cfc7a7 in activemq's branch refs/heads/activemq-5.13.x from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=1d9fdbc ] https://issues.apache.org/jira/browse/AMQ-6108 Ensure that executor threads are created as daemon threads, fix a try/finaly block, clean up some warnings. (cherry picked from commit 5adbafef3b9ec05de7186caa9112f3639c7a6253) > SelectorManager Executor is not shutdown when transport os stopped. > --- > > Key: AMQ-6108 > URL: https://issues.apache.org/jira/browse/AMQ-6108 > Project: ActiveMQ > Issue Type: Bug >Reporter: Andy Gumbrecht > Fix For: 5.13.1 > > Attachments: SelectorManager.Shutdown.patch > > > SelectorManager creates an Executor that is not shut down on termination of > the Transport. > The Executor currently uses non-daemon threads and is is not guaranteed the > the SelectorWorker thread exit condition is ever met. > This causes the shutdown to hang when using transports that utilise the > SelectorManager, such as nio+ssl for example. > The proposed patch shuts down the ExecutorService on/after Transport > shutdown. The SelectorWorkers also check for this as an exit condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-6108) SelectorManager Executor is not shutdown when transport os stopped.
[ https://issues.apache.org/jira/browse/AMQ-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-6108. --- Resolution: Fixed Assignee: Timothy Bish Fix Version/s: 5.14.0 Updated thread creation to be daemon threads and fixed some warnings in the code. Shutdown of the SelectorManager doesn't make sense on Transport stop given that all other active NIO Transport based instances still need to use the SelectorManager > SelectorManager Executor is not shutdown when transport os stopped. > --- > > Key: AMQ-6108 > URL: https://issues.apache.org/jira/browse/AMQ-6108 > Project: ActiveMQ > Issue Type: Bug >Reporter: Andy Gumbrecht >Assignee: Timothy Bish > Fix For: 5.13.1, 5.14.0 > > Attachments: SelectorManager.Shutdown.patch > > > SelectorManager creates an Executor that is not shut down on termination of > the Transport. > The Executor currently uses non-daemon threads and is is not guaranteed the > the SelectorWorker thread exit condition is ever met. > This causes the shutdown to hang when using transports that utilise the > SelectorManager, such as nio+ssl for example. > The proposed patch shuts down the ExecutorService on/after Transport > shutdown. The SelectorWorkers also check for this as an exit condition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
