[jira] [Commented] (AMQ-6191) For HTTP Transport, make the embedded Jetty server Request Log configurable
[ https://issues.apache.org/jira/browse/AMQ-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423345#comment-15423345 ] Nate Klein commented on AMQ-6191: - Hi [~cshannon], I never had the opportunity to get back to this, and ended up finding the issue (performance degradation at HTTP proxy service in front of ActiveMQ, which we've since fixed). As such, I can close this unless you think it's still a valuable add. Regards, Nate > For HTTP Transport, make the embedded Jetty server Request Log configurable > --- > > Key: AMQ-6191 > URL: https://issues.apache.org/jira/browse/AMQ-6191 > Project: ActiveMQ > Issue Type: Improvement > Components: Transport >Affects Versions: 5.11.1 >Reporter: Nate Klein >Priority: Minor > Attachments: patchfile-5.13.1.txt, patchfile.txt > > > I recently had a need to troubleshoot some connectivity issues between client > application and broker, and wanted to look at the access logs of the embedded > Jetty server in the HTTP transport. This patch adds a way to configure this > file from the Connector URL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6397) Configure HTTP timeouts in HttpClientTransport for receive in addition to send
[
https://issues.apache.org/jira/browse/AMQ-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Klein updated AMQ-6397:
Attachment: patchfile.txt
> Configure HTTP timeouts in HttpClientTransport for receive in addition to send
> --
>
> Key: AMQ-6397
> URL: https://issues.apache.org/jira/browse/AMQ-6397
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Transport
>Affects Versions: 5.11.0, 5.14.0
>Reporter: Nate Klein
> Attachments: patchfile.txt
>
>
> We've experienced a situation where when creating a connection, the thread is
> stuck in a socket read during the HTTP HEAD call to the broker from
> HttpClientTransport:
> {code}
> httpClient.execute(httpMethod, new BasicResponseHandler());
> {code}
> After reading through the usage of HttpClient, it looks as though soTimeout
> is only set on the sent HttpClient instances, not the receive. This patch
> adds the timeout to both.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-6397) Configure HTTP timeouts in HttpClientTransport for receive in addition to send
Nate Klein created AMQ-6397:
---
Summary: Configure HTTP timeouts in HttpClientTransport for
receive in addition to send
Key: AMQ-6397
URL: https://issues.apache.org/jira/browse/AMQ-6397
Project: ActiveMQ
Issue Type: Improvement
Components: Transport
Affects Versions: 5.14.0, 5.11.0
Reporter: Nate Klein
We've experienced a situation where when creating a connection, the thread is
stuck in a socket read during the HTTP HEAD call to the broker from
HttpClientTransport:
{code}
httpClient.execute(httpMethod, new BasicResponseHandler());
{code}
After reading through the usage of HttpClient, it looks as though soTimeout is
only set on the sent HttpClient instances, not the receive. This patch adds
the timeout to both.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-601) Add support for automatic configuration reloading
[
https://issues.apache.org/jira/browse/ARTEMIS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic reopened ARTEMIS-601:
-
> Add support for automatic configuration reloading
> -
>
> Key: ARTEMIS-601
> URL: https://issues.apache.org/jira/browse/ARTEMIS-601
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> ActiveMQ 5.x does support automatic configuration reloading and this includes
> security related configuration (amongst other things), see
> http://activemq.apache.org/runtime-configuration.html.
> In our environment, it is very important to change the security settings
> without having to restart the broker.This works fine with ActiveMQ 5.x and
> the {{runtimeConfigurationPlugin}}.
> ARTEMIS-579 clarified the reload of the JAAS files. This is good but it is
> only one half of the security related configuration since the rest appears in
> {{}}.
> Could Artemis please also implement automatic configuration reloading, at
> least for the security configuration?
> Of course, the more settings can be changed without restarting the broker,
> the better...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ARTEMIS-601) Add support for automatic configuration reloading
[
https://issues.apache.org/jira/browse/ARTEMIS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-601.
---
Resolution: Fixed
> Add support for automatic configuration reloading
> -
>
> Key: ARTEMIS-601
> URL: https://issues.apache.org/jira/browse/ARTEMIS-601
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> ActiveMQ 5.x does support automatic configuration reloading and this includes
> security related configuration (amongst other things), see
> http://activemq.apache.org/runtime-configuration.html.
> In our environment, it is very important to change the security settings
> without having to restart the broker.This works fine with ActiveMQ 5.x and
> the {{runtimeConfigurationPlugin}}.
> ARTEMIS-579 clarified the reload of the JAAS files. This is good but it is
> only one half of the security related configuration since the rest appears in
> {{}}.
> Could Artemis please also implement automatic configuration reloading, at
> least for the security configuration?
> Of course, the more settings can be changed without restarting the broker,
> the better...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-601) Add support for automatic configuration reloading
[
https://issues.apache.org/jira/browse/ARTEMIS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-601:
Issue Type: New Feature (was: Improvement)
> Add support for automatic configuration reloading
> -
>
> Key: ARTEMIS-601
> URL: https://issues.apache.org/jira/browse/ARTEMIS-601
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> ActiveMQ 5.x does support automatic configuration reloading and this includes
> security related configuration (amongst other things), see
> http://activemq.apache.org/runtime-configuration.html.
> In our environment, it is very important to change the security settings
> without having to restart the broker.This works fine with ActiveMQ 5.x and
> the {{runtimeConfigurationPlugin}}.
> ARTEMIS-579 clarified the reload of the JAAS files. This is good but it is
> only one half of the security related configuration since the rest appears in
> {{}}.
> Could Artemis please also implement automatic configuration reloading, at
> least for the security configuration?
> Of course, the more settings can be changed without restarting the broker,
> the better...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ARTEMIS-601) Add support for automatic configuration reloading
[
https://issues.apache.org/jira/browse/ARTEMIS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-601.
---
> Add support for automatic configuration reloading
> -
>
> Key: ARTEMIS-601
> URL: https://issues.apache.org/jira/browse/ARTEMIS-601
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
> Fix For: 1.4.0
>
>
> ActiveMQ 5.x does support automatic configuration reloading and this includes
> security related configuration (amongst other things), see
> http://activemq.apache.org/runtime-configuration.html.
> In our environment, it is very important to change the security settings
> without having to restart the broker.This works fine with ActiveMQ 5.x and
> the {{runtimeConfigurationPlugin}}.
> ARTEMIS-579 clarified the reload of the JAAS files. This is good but it is
> only one half of the security related configuration since the rest appears in
> {{}}.
> Could Artemis please also implement automatic configuration reloading, at
> least for the security configuration?
> Of course, the more settings can be changed without restarting the broker,
> the better...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (ARTEMIS-607) Implement support for Interceptors with the MQTT protocol
[ https://issues.apache.org/jira/browse/ARTEMIS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic reopened ARTEMIS-607: - Assignee: John D. Ament (was: Justin Bertram) > Implement support for Interceptors with the MQTT protocol > - > > Key: ARTEMIS-607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-607 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.3.0 >Reporter: Jiri Danek >Assignee: John D. Ament > Fix For: 1.4.0 > > > Intercepting MQTT messages is not yet supported, only core protocol messages > can be intercepted. I would like to request a feature for MQTT interceptor > support. > This feature was recently requested on the users@ mailing list > http://activemq.2283324.n4.nabble.com/Interceptor-for-MQTT-td4713408.html > I encountered this issue when trying to answer > http://stackoverflow.com/questions/38101899/intercepting-mqtt-messages-in-artemis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARTEMIS-607) Implement support for Interceptors with the MQTT protocol
[ https://issues.apache.org/jira/browse/ARTEMIS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-607. --- Resolution: Fixed > Implement support for Interceptors with the MQTT protocol > - > > Key: ARTEMIS-607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-607 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.3.0 >Reporter: Jiri Danek >Assignee: John D. Ament > Fix For: 1.4.0 > > > Intercepting MQTT messages is not yet supported, only core protocol messages > can be intercepted. I would like to request a feature for MQTT interceptor > support. > This feature was recently requested on the users@ mailing list > http://activemq.2283324.n4.nabble.com/Interceptor-for-MQTT-td4713408.html > I encountered this issue when trying to answer > http://stackoverflow.com/questions/38101899/intercepting-mqtt-messages-in-artemis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-659) Remove dependencies on cdi/atinject
[ https://issues.apache.org/jira/browse/ARTEMIS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423077#comment-15423077 ] clebert suconic commented on ARTEMIS-659: - [~johndament] thanks > Remove dependencies on cdi/atinject > --- > > Key: ARTEMIS-659 > URL: https://issues.apache.org/jira/browse/ARTEMIS-659 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: John D. Ament >Assignee: clebert suconic > Fix For: 1.4.0 > > > The dependencies for cdi/atinject aren't actually needed in the client > library. Remove them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARTEMIS-659) Remove dependencies on cdi/atinject
[ https://issues.apache.org/jira/browse/ARTEMIS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-659. --- Resolution: Fixed > Remove dependencies on cdi/atinject > --- > > Key: ARTEMIS-659 > URL: https://issues.apache.org/jira/browse/ARTEMIS-659 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: John D. Ament >Assignee: clebert suconic > Fix For: 1.4.0 > > > The dependencies for cdi/atinject aren't actually needed in the client > library. Remove them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-659) Remove dependencies on cdi/atinject
[ https://issues.apache.org/jira/browse/ARTEMIS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-659: Fix Version/s: (was: 1.5.0) 1.4.0 > Remove dependencies on cdi/atinject > --- > > Key: ARTEMIS-659 > URL: https://issues.apache.org/jira/browse/ARTEMIS-659 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: John D. Ament >Assignee: clebert suconic > Fix For: 1.4.0 > > > The dependencies for cdi/atinject aren't actually needed in the client > library. Remove them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-659) Remove dependencies on cdi/atinject
[ https://issues.apache.org/jira/browse/ARTEMIS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament updated ARTEMIS-659: -- Assignee: clebert suconic > Remove dependencies on cdi/atinject > --- > > Key: ARTEMIS-659 > URL: https://issues.apache.org/jira/browse/ARTEMIS-659 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: John D. Ament >Assignee: clebert suconic > Fix For: 1.5.0 > > > The dependencies for cdi/atinject aren't actually needed in the client > library. Remove them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-659) Remove dependencies on cdi/atinject
[ https://issues.apache.org/jira/browse/ARTEMIS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423050#comment-15423050 ] John D. Ament commented on ARTEMIS-659: --- [~clebertsuconic] Didn't you already do this? > Remove dependencies on cdi/atinject > --- > > Key: ARTEMIS-659 > URL: https://issues.apache.org/jira/browse/ARTEMIS-659 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: John D. Ament > Fix For: 1.5.0 > > > The dependencies for cdi/atinject aren't actually needed in the client > library. Remove them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-392) Artemis NettyConnetor doesn't set Allocators after HTTP socket upgrade
[ https://issues.apache.org/jira/browse/ARTEMIS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-392: Fix Version/s: (was: 1.4.0) 1.5.0 > Artemis NettyConnetor doesn't set Allocators after HTTP socket upgrade > -- > > Key: ARTEMIS-392 > URL: https://issues.apache.org/jira/browse/ARTEMIS-392 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-81) Verify the activemq-rest is working and review messaging model
[ https://issues.apache.org/jira/browse/ARTEMIS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-81: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Verify the activemq-rest is working and review messaging model > -- > > Key: ARTEMIS-81 > URL: https://issues.apache.org/jira/browse/ARTEMIS-81 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-24) Lazy conversions on Protocols / Persistency
[ https://issues.apache.org/jira/browse/ARTEMIS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-24: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Lazy conversions on Protocols / Persistency > --- > > Key: ARTEMIS-24 > URL: https://issues.apache.org/jira/browse/ARTEMIS-24 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic > Fix For: 1.5.0 > > > We should do like apollo on converting between Protocols and persisting data. > We should keep the data native as much as we can to the protocol and only > convert when needed. > Right now we are always converting to an internal format independently of the > protocol. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-542) Change AMQ212006 log level
[
https://issues.apache.org/jira/browse/ARTEMIS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-542:
Fix Version/s: (was: 1.4.0)
1.5.0
> Change AMQ212006 log level
> --
>
> Key: ARTEMIS-542
> URL: https://issues.apache.org/jira/browse/ARTEMIS-542
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
>Priority: Trivial
> Fix For: 1.5.0
>
>
> When Artemis logger is configured to log traces, it also log the AMQ212006
> warning:
> {noformat}
> 12:55:47,789 WARN [org.apache.activemq.artemis.core.client] (Thread-10
> (ActiveMQ-client-global-threads-487873773)) AMQ212006: Waiting 2 000
> milliseconds before next retry. RetryInterval=2 000 and multiplier=1
> {noformat}
> The code in
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl#getConnectionWithRetry
> looks suspicious at the warning is logged only if TRACE is enabled.
> I think the log level should be decreased to TRACE (or INFO) as it is
> expected to happen during failover and does not indicate a problem with the
> client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-165) Karaf CLI integration
[ https://issues.apache.org/jira/browse/ARTEMIS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-165: Fix Version/s: (was: 1.4.0) 1.5.0 > Karaf CLI integration > - > > Key: ARTEMIS-165 > URL: https://issues.apache.org/jira/browse/ARTEMIS-165 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-181) Fix openwire tests under org.apache.activemq package
[ https://issues.apache.org/jira/browse/ARTEMIS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-181: Fix Version/s: (was: 1.4.0) 1.5.0 > Fix openwire tests under org.apache.activemq package > > > Key: ARTEMIS-181 > URL: https://issues.apache.org/jira/browse/ARTEMIS-181 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-175) CLI improvement with --docker
[ https://issues.apache.org/jira/browse/ARTEMIS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-175: Fix Version/s: (was: 1.4.0) 1.5.0 > CLI improvement with --docker > - > > Key: ARTEMIS-175 > URL: https://issues.apache.org/jira/browse/ARTEMIS-175 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: clebert suconic >Priority: Minor > Fix For: 1.5.0 > > > that would help to keep servers alive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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
]
clebert suconic updated ARTEMIS-160:
Fix Version/s: (was: 1.4.0)
1.5.0
> 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.5.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}
[jira] [Updated] (ARTEMIS-355) Duplex bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-355: Fix Version/s: (was: 1.4.0) 1.5.0 > Duplex bridges > -- > > Key: ARTEMIS-355 > URL: https://issues.apache.org/jira/browse/ARTEMIS-355 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.2.0 >Reporter: Mike Hearn >Assignee: Martyn Taylor > Fix For: 1.5.0 > > > I can't find any way to make an embedded artemis A connect to an embedded > artemis B such that B can send messages to A without connectivity at the TCP > level, e.g. due to firewall traversal. It'd be convenient if there was no > need for me to implement firewall punching myself. Apparently ActiveMQ can do > this using some sort of "duplex" attribute, but it's not in Artemis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-66) implement configuration persistence
[ https://issues.apache.org/jira/browse/ARTEMIS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-66: --- Fix Version/s: (was: 1.4.0) 1.5.0 > implement configuration persistence > --- > > Key: ARTEMIS-66 > URL: https://issues.apache.org/jira/browse/ARTEMIS-66 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Andy Taylor > Fix For: 1.5.0 > > > We should reflect changes thru management such as adding destinations in the > configuration file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-604) Message Serialization Improvement
[ https://issues.apache.org/jira/browse/ARTEMIS-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-604: Fix Version/s: (was: 1.4.0) 1.5.0 > Message Serialization Improvement > - > > Key: ARTEMIS-604 > URL: https://issues.apache.org/jira/browse/ARTEMIS-604 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 1.3.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-57) the 'to' field of AMQP messages gets cleared within the broker
[
https://issues.apache.org/jira/browse/ARTEMIS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-57:
---
Fix Version/s: (was: 1.4.0)
1.5.0
> the 'to' field of AMQP messages gets cleared within the broker
> --
>
> Key: ARTEMIS-57
> URL: https://issues.apache.org/jira/browse/ARTEMIS-57
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 1.5.0
>
>
> When sending and receiving AMQP messages, the 'to' field of the Properties
> section (which is meant to be immutable) is cleared as the message transits
> through the broker.
> The encoding on the wire of a message Properties section as it was sent to
> the broker:
> {noformat}
> # properties
> # properties
># message-id
> "localhost.localdomai"
> "n-54104-141838672362"
> "2-0:1:1:1-1"
>
># user-id
># to
> "myQueue"
>
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
> #2014/12/12 12:18:44.423 # creation-time
> # group-id
> # group-sequence
> # reply-to-group-id
>
> {noformat}
> The encoding on the wire on its way to a consumer:
> {noformat}
> # properties
> # properties
># message-id
># user-id
># to
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
> #2014/12/12 12:18:44.423 # creation-time
> # group-id
> # group-sequence
> # reply-to-group-id
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-474) replication fails with colocated topologies
[ https://issues.apache.org/jira/browse/ARTEMIS-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-474: Fix Version/s: (was: 1.4.0) 1.5.0 > replication fails with colocated topologies > --- > > Key: ARTEMIS-474 > URL: https://issues.apache.org/jira/browse/ARTEMIS-474 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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 ] clebert suconic updated ARTEMIS-161: Fix Version/s: (was: 1.4.0) 1.5.0 > 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.5.0 > > > 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] [Updated] (ARTEMIS-487) Support server side soWriteTimeout
[ https://issues.apache.org/jira/browse/ARTEMIS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-487: Fix Version/s: (was: 1.4.0) 1.5.0 > Support server side soWriteTimeout > -- > > Key: ARTEMIS-487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-487 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.2.0 >Reporter: Howard Gao > Fix For: 1.5.0 > > > Openwire broker supports a feature that can set soWriteTimeout (tcp) on > server side. It means when writing a message to a client, if the writing take > a time longer that a configured timeout (soWriteTimeout) it will disconnect > the connection (close the underlying socket). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-60) Transactionally consumed AMQP messages are settled without any disposition state.
[
https://issues.apache.org/jira/browse/ARTEMIS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-60:
---
Fix Version/s: (was: 1.4.0)
1.5.0
> Transactionally consumed AMQP messages are settled without any disposition
> state.
> -
>
> Key: ARTEMIS-60
> URL: https://issues.apache.org/jira/browse/ARTEMIS-60
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 1.5.0
>
>
> When the broker receives an unsettled disposition frame from a consumer
> accepting a message using TransactionalState to make it part of a
> transaction, it settles the message but does so with no state at all. This
> process causes a settled disposition frame to be sent to the client which
> contains no state. The message should retain TransactionalState linking it to
> the transaction and its outcome.
> Similar issue to AMQ-5456 for ActiveMQ 5.
> The issue can be seen in the protocol trace below:
> {noformat}
>
>
>
>
>
>
> # disposition
> # disposition
># role
># first
># last
># settled
># state TransactionalState
># state
> # txn-id
> 00 00 00 00 00 00 00 0d
>
> # outcome
> # accepted
>
> # batchable [false]
>
>
>
>
>
> {noformat}
> {noformat}
>
>
>
>
>
>
> # disposition
> # disposition
># role
>1 # first
>1 # last
># settled
> # state No state
> # batchable [false]
>
>
>
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-170) Improve AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-170: Fix Version/s: (was: 1.4.0) 1.5.0 > Improve AMQP > > > Key: ARTEMIS-170 > URL: https://issues.apache.org/jira/browse/ARTEMIS-170 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Critical > Fix For: 1.5.0 > > > The performance on our AMQP implementation is not bad, but it's not at the > same level as Core Protocol. > We should look at ways to improve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-189) Support Queue wildcard usecase
[ https://issues.apache.org/jira/browse/ARTEMIS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-189: Fix Version/s: (was: 1.4.0) 1.5.0 > Support Queue wildcard usecase > -- > > Key: ARTEMIS-189 > URL: https://issues.apache.org/jira/browse/ARTEMIS-189 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Minor > Fix For: 1.5.0 > > > Client should be able to create a Queue with wild card > Foo.> > Then create a consumer to it. > Then create a queue like FOO.BAR.HUMBUG > sends a few messages to it. > The consumer should be able to receive it. > Ref: JmsDurableQueueWildcardSendReceiveTest, JmsQueueWildcardSendReceiveTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-155) Incoming AMQP connection using "cut-through" ANONYMOUS SASL fails
[
https://issues.apache.org/jira/browse/ARTEMIS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-155:
Fix Version/s: (was: 1.4.0)
1.5.0
> Incoming AMQP connection using "cut-through" ANONYMOUS SASL fails
> -
>
> Key: ARTEMIS-155
> URL: https://issues.apache.org/jira/browse/ARTEMIS-155
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Andy Taylor
>Priority: Minor
> Fix For: 1.5.0
>
>
> When connecting an AMQP 1.0 connection to the broker using SASL ANONYMOUS,
> the following exchange occurs:
> {noformat}
> ClientBroker
> init(SASL) ->
> sasl.init (ANON) ->
> init(AMQP) ->
> open ->
> <- init(SASL)
> <- sasl.mechanisms
> <- sasl.outcome(OK)
> <- init(AMQP)
> socket closed by broker after timeout
> {noformat}
> It appears the the broker doesn't process the open frame.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-56) the message-id of AMQP messages gets cleared within the broker
[
https://issues.apache.org/jira/browse/ARTEMIS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-56:
---
Fix Version/s: (was: 1.4.0)
1.5.0
> the message-id of AMQP messages gets cleared within the broker
> --
>
> Key: ARTEMIS-56
> URL: https://issues.apache.org/jira/browse/ARTEMIS-56
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 1.5.0
>
>
> When sending and receiving AMQP messages, the message-id field of the
> Properties section (which is meant to be immutable) is cleared as the message
> transits through the broker.
> The encoding on the wire of a message Properties section as it was sent to
> the broker:
> {noformat}
> # properties
> # properties
># message-id
> "localhost.localdomai"
> "n-54104-141838672362"
> "2-0:1:1:1-1"
>
># user-id
># to
> "myQueue"
>
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
> #2014/12/12 12:18:44.423 # creation-time
> # group-id
> # group-sequence
> # reply-to-group-id
>
> {noformat}
> The encoding on the wire on its way to a consumer:
> {noformat}
> # properties
> # properties
># message-id
># user-id
># to
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
> #2014/12/12 12:18:44.423 # creation-time
> # group-id
> # group-sequence
> # reply-to-group-id
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-235) Map content-type to message type on Stomp
[ https://issues.apache.org/jira/browse/ARTEMIS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-235: Fix Version/s: (was: 1.4.0) 1.5.0 > Map content-type to message type on Stomp > - > > Key: ARTEMIS-235 > URL: https://issues.apache.org/jira/browse/ARTEMIS-235 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0 >Reporter: clebert suconic >Assignee: Justin Bertram > Fix For: 1.5.0 > > > As documented at > https://activemq.apache.org/artemis/docs/1.0.0/interoperability.html#sending-and-consuming-stomp-message-from-jms-or-apache-activemq-artemis-core-api > Will convert bytes message or text message when the size is available. > it would been better to use content-type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-31) Disaster recovery
[ https://issues.apache.org/jira/browse/ARTEMIS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-31: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Disaster recovery > - > > Key: ARTEMIS-31 > URL: https://issues.apache.org/jira/browse/ARTEMIS-31 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic > Fix For: 1.5.0 > > > allow some sort of disaster recovery -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-580) Add setting to control global memory usage
[
https://issues.apache.org/jira/browse/ARTEMIS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-580:
Fix Version/s: (was: 1.4.0)
1.5.0
> Add setting to control global memory usage
> --
>
> Key: ARTEMIS-580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-580
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: clebert suconic
>Priority: Blocker
> Fix For: 1.5.0
>
>
> AFAIK, the only way to prevent Artemis from consuming all the heap and dying
> with OOM errors is to set {{max-size-bytes}}.
> This per-address setting is not suitable for brokers with many addresses that
> have different usage patterns. For instance, on a broker used for testing,
> Artemis complained that:
> {code}
> 2016-06-20 13:20:03,107 [org.apache.activemq.artemis.core.server] WARN
> AMQ05: OutOfMemoryError possible! There are currently 400 addresses with
> a total max-size-bytes of 4,194,304,000 bytes, but the maximum memory
> available is 764,411,904 bytes.
> {code}
> These 400 addresses are not used anymore and will eventually be removed.
> In contrast, ActiveMQ 5.x has a much more useful global setting to control
> how much memory (in total) the broker will use. See {{memoryUsage}} in
> http://activemq.apache.org/producer-flow-control.html.
> Could Artemis also use a global memory setting to limit its memory usage?
> What to do when hitting this limit (DROP, BLOCK, PAGE...) could stay
> per-address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-440) Use Container ID on ProtonConnection
[ https://issues.apache.org/jira/browse/ARTEMIS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-440: Fix Version/s: (was: 1.4.0) 1.5.0 > Use Container ID on ProtonConnection > > > Key: ARTEMIS-440 > URL: https://issues.apache.org/jira/browse/ARTEMIS-440 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-537) Allow Artemis to use Karaf JAAS security
[ https://issues.apache.org/jira/browse/ARTEMIS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-537: Fix Version/s: (was: 1.4.0) 1.5.0 > Allow Artemis to use Karaf JAAS security > > > Key: ARTEMIS-537 > URL: https://issues.apache.org/jira/browse/ARTEMIS-537 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: osgi >Affects Versions: 1.2.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 1.5.0 > > > Right now Artemis can use only it's own role principal class when authorising > clients. When used inside other container and leveraging their JAAS security > implementation, we need to allow more flexibility in how we check client > roles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-190) Message Eviction and its Tests
[ https://issues.apache.org/jira/browse/ARTEMIS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-190: Fix Version/s: (was: 1.4.0) 1.5.0 > Message Eviction and its Tests > -- > > Key: ARTEMIS-190 > URL: https://issues.apache.org/jira/browse/ARTEMIS-190 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao > Fix For: 1.5.0 > > > Message Eviction means to keep a limited number of messages in broker memory > for consumers to a non-durable topic and drop the old messages as new > messages come in, in order to keep the limit. > ref: http://activemq.apache.org/slow-consumer-handling.html > The MessageEvictionTest needs to be refactored as it does the testing by > examining the internal status of activemq broker objects, which is not > applicable to the new artemis broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-332) Duplicate delivery over Bridges under OME scenarios, paging and other failures
[ https://issues.apache.org/jira/browse/ARTEMIS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-332: Fix Version/s: (was: 1.4.0) 1.5.0 > Duplicate delivery over Bridges under OME scenarios, paging and other failures > -- > > Key: ARTEMIS-332 > URL: https://issues.apache.org/jira/browse/ARTEMIS-332 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-171) Improve AMQP Performance
[ https://issues.apache.org/jira/browse/ARTEMIS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-171: Fix Version/s: (was: 1.4.0) 1.5.0 > Improve AMQP Performance > > > Key: ARTEMIS-171 > URL: https://issues.apache.org/jira/browse/ARTEMIS-171 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: clebert suconic >Priority: Critical > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-176) GC Durable Subscriptions
[ https://issues.apache.org/jira/browse/ARTEMIS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-176: Fix Version/s: (was: 1.4.0) 1.5.0 > GC Durable Subscriptions > > > Key: ARTEMIS-176 > URL: https://issues.apache.org/jira/browse/ARTEMIS-176 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: clebert suconic > Fix For: 1.5.0 > > > There should be a way to GC durable subscriptions when not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-196) Implementing Consumer Priority
[ https://issues.apache.org/jira/browse/ARTEMIS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-196: Fix Version/s: (was: 1.4.0) 1.5.0 > Implementing Consumer Priority > -- > > Key: ARTEMIS-196 > URL: https://issues.apache.org/jira/browse/ARTEMIS-196 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao > Fix For: 1.5.0 > > > ref: http://activemq.apache.org/consumer-priority.html > org.apache.activemq.QueueConsumerPriorityTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-85) Add support for HA cluster / failover discovery using DNS SRV records
[ https://issues.apache.org/jira/browse/ARTEMIS-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-85: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Add support for HA cluster / failover discovery using DNS SRV records > - > > Key: ARTEMIS-85 > URL: https://issues.apache.org/jira/browse/ARTEMIS-85 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Daniel Pocock > Fix For: 1.5.0 > > > Copied from HORNETQ-1270 > The DNS SRV record provides a convenient and well known mechanism to > configure active-active, load balanced clusters and to provide failover > information. > It is convenient for many people because they already have DNS servers and > support staff are usually familiar with the procedures for maintaining the > DNS entries. > DNS SRV also allows port numbers to be advertised. > The clustering support using UDP multicast doesn't work for all sites, > especially where the user is more concerned with failover than load-balancing. > A specific DNS SRV implementation may involve some or all of the following: > - clients discovering a HornetQ, JNDI or STOMP host and port > - servers dynamically deciding which IPs and ports to bind to by checking DNS > SRV records > - servers dynamically deciding which other servers to cluster with by > checking for DNS SRV records > DNS SRV records may look like this: > _stomp._tcp.test-mq.example.org. IN SRV 1 50 5566 testmqhost1.example.org. > _stomp._tcp.test-mq.example.org. IN SRV 2 50 5566 testmqbackup.example.org. > A STOMP client would then be configured with just the domain name > "test-mq.example.org" and it would dynamically discover the hosts and ports > from DNS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-172) Improve AMQP-JMS mapping on server
[ https://issues.apache.org/jira/browse/ARTEMIS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-172: Fix Version/s: (was: 1.4.0) 1.5.0 > Improve AMQP-JMS mapping on server > -- > > Key: ARTEMIS-172 > URL: https://issues.apache.org/jira/browse/ARTEMIS-172 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: clebert suconic >Priority: Critical > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-59) AMQP messages published transactionally should be accepted using a TransactionalState
[
https://issues.apache.org/jira/browse/ARTEMIS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-59:
---
Fix Version/s: (was: 1.4.0)
1.5.0
> AMQP messages published transactionally should be accepted using a
> TransactionalState
> -
>
> Key: ARTEMIS-59
> URL: https://issues.apache.org/jira/browse/ARTEMIS-59
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 1.5.0
>
>
> Currently, when an incoming AMQP message is part of a transaction, it is
> accepted using the regular Accepted terminal state on the disposition reply.
> According to the spec [1] the disposition should actually use a
> TransactionalState with Accepted outcome.
> Similar issue to AMQ-5352 for ActiveMQ 5.
> [1]
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp111808
> The issue can be seen in the following protocol traces.
> The transactional message transfer from the producer:
> {noformat}
>
>
>
>
>
>
> # transfer
> # transfer
>1 # handle
>1 # delivery-id
># delivery-tag
> "0"
>
># message-format
># settled
># more
># rcv-settle-mode
># state
> Transactional state
># state
> # txn-id
> 00 00 00 00 7f ff ff ff
>
> # outcome
>
> # resume [false]
> # aborted [false]
> # batchable [false]
>
>
> # header
> # header
># durable
> # priority
> # ttl
> # first-acquirer
> # delivery-count
>
>
> # message-annotations
> # message-annotations
>
> "x-opt-jms-msg-type"
>
>5
>
> "x-opt-to-type"
>
>0
>
>
> # properties
> # properties
># message-id
> "localhost.localdomai"
> "n-48953-141840504087"
> "8-0:1:1:1-1"
>
># user-id
># to
> "myQueue"
>
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
> #2014/12/12 17:24:01.614 # creation-time
> # group-id
> # group-sequence
> # reply-to-group-id
>
>
> # amqp-value
> # amqp-value
> "Hello world!"
>
>
>
>
>
> {noformat}
> The disposition for this message can then be seen being updated by the broker
> the Accepted state, rather than a TransactionalState identifying the
> transaction and containing the Accepted outcome:
> {noformat}
>
>
>
>
>
>
> # disposition
> # disposition
># role
>1 # first
>1 # last
># settled
># state
> Non-Transactional state
># accepted
> # batchable [false]
>
>
>
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-185) 100% transparent failover
[ https://issues.apache.org/jira/browse/ARTEMIS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-185: Fix Version/s: (was: 1.4.0) 1.5.0 > 100% transparent failover > - > > Key: ARTEMIS-185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-185 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Miroslav Novak > Fix For: 1.5.0 > > > The client should cache any transactional data, and verify if the information > had reached the server or not upon reconnection (through either failover or > reconnection). > Currently standalone JMS client throws exception (ArtemisException or > JMSException) to client application code during failover/failback and leaves > on application programmer to handle this exception and retry the last > operation. > This makes client code complex and developer must spent additional effort to > handle those edge cases. This is complicated to achieve especially for > consumer with transacted session of client acknowledge. > Goal of this RFE is to provide exception free behaviour for standalone JMS > clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-183) Fix openwire tests under org.apache.activemq.openwire package
[ https://issues.apache.org/jira/browse/ARTEMIS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-183: Fix Version/s: (was: 1.4.0) 1.5.0 > Fix openwire tests under org.apache.activemq.openwire package > - > > Key: ARTEMIS-183 > URL: https://issues.apache.org/jira/browse/ARTEMIS-183 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: Howard Gao > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-521) OSGi support broken after 1.2.0 release
[ https://issues.apache.org/jira/browse/ARTEMIS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-521: Fix Version/s: (was: 1.4.0) 1.5.0 > OSGi support broken after 1.2.0 release > --- > > Key: ARTEMIS-521 > URL: https://issues.apache.org/jira/browse/ARTEMIS-521 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 1.5.0 > > > Couple of changes since the last release broke OSGi bundles. Let's fix it for > 1.3.0 and create integration test that will catch those in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-215) OpenWireMessageConverter sets headers that need reviewed abd removed if not needed
[ https://issues.apache.org/jira/browse/ARTEMIS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-215: Fix Version/s: (was: 1.4.0) 1.5.0 > OpenWireMessageConverter sets headers that need reviewed abd removed if not > needed > -- > > Key: ARTEMIS-215 > URL: https://issues.apache.org/jira/browse/ARTEMIS-215 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: Andy Taylor >Assignee: Andy Taylor > Fix For: 1.5.0 > > > in the OpenWireMessageConverter there are a number of headers that are set > and unset on the ActiveMQMessage. These are either redundant or should be > mapped to internal Artemis constructs. > for instance AMQ_MSG_ORIG_DESTINATION is set in ActiveMQ when messages are > routed to the DLQ so this should be mapped to HDR_ORIGINAL_QUEUE on > MessageImpl. > The headers to check are: > public static final String AMQ_MSG_DLQ_DELIVERY_FAILURE_CAUSE_PROPERTY = > AMQ_PREFIX + "dlqDeliveryFailureCause"; >private static final String AMQ_MSG_ARRIVAL = AMQ_PREFIX + "ARRIVAL"; >private static final String AMQ_MSG_BROKER_IN_TIME = AMQ_PREFIX + > "BROKER_IN_TIME"; >private static final String AMQ_MSG_BROKER_PATH = AMQ_PREFIX + > "BROKER_PATH"; >private static final String AMQ_MSG_CLUSTER = AMQ_PREFIX + "CLUSTER"; >private static final String AMQ_MSG_COMMAND_ID = AMQ_PREFIX + "COMMAND_ID"; >private static final String AMQ_MSG_DATASTRUCTURE = AMQ_PREFIX + > "DATASTRUCTURE"; >private static final String AMQ_MSG_GROUP_ID = AMQ_PREFIX + "GROUP_ID"; >private static final String AMQ_MSG_GROUP_SEQUENCE = AMQ_PREFIX + > "GROUP_SEQUENCE"; >private static final String AMQ_MSG_MESSAGE_ID = AMQ_PREFIX + "MESSAGE_ID"; >private static final String AMQ_MSG_ORIG_DESTINATION = AMQ_PREFIX + > "ORIG_DESTINATION"; >private static final String AMQ_MSG_ORIG_TXID = AMQ_PREFIX + "ORIG_TXID"; >private static final String AMQ_MSG_PRODUCER_ID = AMQ_PREFIX + > "PRODUCER_ID"; >private static final String AMQ_MSG_MARSHALL_PROP = AMQ_PREFIX + > "MARSHALL_PROP"; >private static final String AMQ_MSG_REDELIVER_COUNTER = AMQ_PREFIX + > "REDELIVER_COUNTER"; >private static final String AMQ_MSG_REPLY_TO = AMQ_PREFIX + "REPLY_TO"; >private static final String AMQ_MSG_CONSUMER_ID = AMQ_PREFIX + > "CONSUMER_ID"; >private static final String AMQ_MSG_TX_ID = AMQ_PREFIX + "TX_ID"; >private static final String AMQ_MSG_USER_ID = AMQ_PREFIX + "USER_ID"; >private static final String AMQ_MSG_COMPRESSED = AMQ_PREFIX + "COMPRESSED"; >private static final String AMQ_MSG_DROPPABLE = AMQ_PREFIX + "DROPPABLE"; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-17) Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5
[ https://issues.apache.org/jira/browse/ARTEMIS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-17: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5 > -- > > Key: ARTEMIS-17 > URL: https://issues.apache.org/jira/browse/ARTEMIS-17 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Rob Davies >Assignee: Andy Taylor > Fix For: 1.5.0 > > > One of the main reasons ActiveMQ is popular is its flexibility. Allowing > Camel to intercept messages inside the broker (Camel Broker Component) - will > allow some of the current BrokerPlugins (like TimeStamp) - to be implemented > using Camel routes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-30) allow backup servers to service multiple live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-30: --- Fix Version/s: (was: 1.4.0) 1.5.0 > allow backup servers to service multiple live servers > - > > Key: ARTEMIS-30 > URL: https://issues.apache.org/jira/browse/ARTEMIS-30 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic > Fix For: 1.5.0 > > > On this you could have a number of backup Nodes (M) serving a number of live > Nodes (N) > On that scenario you would always have N+M nodes. you would only support M > lives failing on this scenario. > Right now a backup can only support one live. With this we would allow it to > serve multiple lives. > I'm not sure yet if this applies to replication as well. It's easy to be > implemented with shared storage. We will need to investigate if this makes > sense with replication or not. (To be discussed during design discussions > before the implementation) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-75) Recovery Manager should raise/log error when multiple ActiveMQRegistry service providers are registered.
[ https://issues.apache.org/jira/browse/ARTEMIS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-75: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Recovery Manager should raise/log error when multiple ActiveMQRegistry > service providers are registered. > > > Key: ARTEMIS-75 > URL: https://issues.apache.org/jira/browse/ARTEMIS-75 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Martyn Taylor >Assignee: Martyn Taylor > Fix For: 1.5.0 > > > Since we are now using the Service Loader to load instances of the > ActiveMQRegistry, it is now possible that more than one Service Provider for > the registry can be loaded. We should log an error if more than 1 service > provider is found. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-375) When use ./artemis data exp, the xml printed to stdout mixed with logging information
[ https://issues.apache.org/jira/browse/ARTEMIS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-375: Fix Version/s: (was: 1.4.0) 1.5.0 > When use ./artemis data exp, the xml printed to stdout mixed with logging > information > - > > Key: ARTEMIS-375 > URL: https://issues.apache.org/jira/browse/ARTEMIS-375 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Howard Nguyen > Fix For: 1.5.0 > > Attachments: XmlDataExport-improvement.patch > > > When use ./artemis data exp, the xml printed to stdout mixed with logging > information. > Attached patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-203) Investigate removal of namespaces for queues / topics
[ https://issues.apache.org/jira/browse/ARTEMIS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-203: Fix Version/s: (was: 1.4.0) 1.5.0 > Investigate removal of namespaces for queues / topics > - > > Key: ARTEMIS-203 > URL: https://issues.apache.org/jira/browse/ARTEMIS-203 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.0.0, 1.1.0, 1.2.0 >Reporter: Martyn Taylor > Fix For: 1.5.0 > > > We are currently using address name spacing on the broker to determine the > message producer client type, for example producing from a jms client results > in messages being posted to jms.queue.*** where *** is the address provided > by the client. The has caused some confusions for users who were expecting > to produce and consume to the same address using different clients. > This also has a couple of other consequences: > 1. Messages can not be produced to the same queue by AMQP and JMS. > 2. Consumers need to be aware of the producer client type so they can > subscribe to the appropriately namespaced address. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-173) Document migration path for all activemq5 features
[ https://issues.apache.org/jira/browse/ARTEMIS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-173: Fix Version/s: (was: 1.4.0) 1.5.0 > Document migration path for all activemq5 features > -- > > Key: ARTEMIS-173 > URL: https://issues.apache.org/jira/browse/ARTEMIS-173 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: clebert suconic >Priority: Critical > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-169) Fix imported open wire tests
[ https://issues.apache.org/jira/browse/ARTEMIS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-169: Fix Version/s: (was: 1.4.0) 1.5.0 > Fix imported open wire tests > > > Key: ARTEMIS-169 > URL: https://issues.apache.org/jira/browse/ARTEMIS-169 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: clebert suconic > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-581) Add setting to control global disk usage
[
https://issues.apache.org/jira/browse/ARTEMIS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-581:
Fix Version/s: (was: 1.4.0)
1.5.0
> Add setting to control global disk usage
> -
>
> Key: ARTEMIS-581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-581
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: clebert suconic
>Priority: Blocker
> Fix For: 1.5.0
>
>
> AFAIK, there is no way to prevent Artemis from using too much space on the
> disk (with paged messages).
> Disk space, just like memory space, is limited and Artemis should detect when
> it is about to use too much space and act accordingly (i.e. DROP, FAIL...).
> ActiveMQ 5.x does allow controlling disk usage via its {{storeUsage}} and
> {{tempUsage}} settings in {{systemUsage}}.
> Could Artemis also use a global disk setting to limit its disk usage?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-29) Reconnect to any live
[ https://issues.apache.org/jira/browse/ARTEMIS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-29: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Reconnect to any live > - > > Key: ARTEMIS-29 > URL: https://issues.apache.org/jira/browse/ARTEMIS-29 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic >Priority: Critical > Fix For: 1.5.0 > > > Right now clients will always connect to their backup or original lives. > We could in a configurable fashion have the client connecting anywhere after > a certain number of retries to their original nodes. > (This will only be applied to core clients since AMQP will always reconnect > to their original addresses). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-22) Review OpenWire Implementation
[ https://issues.apache.org/jira/browse/ARTEMIS-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-22: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Review OpenWire Implementation > -- > > Key: ARTEMIS-22 > URL: https://issues.apache.org/jira/browse/ARTEMIS-22 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Critical > Fix For: 1.5.0 > > > This is a review of the current open wire implementation on the activemq6 > branch > I would suggest someone with experience on activemq5 team to review the > implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-137) Replace JBoss Logging by SLF4J
[ https://issues.apache.org/jira/browse/ARTEMIS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-137: Fix Version/s: (was: 1.4.0) 1.5.0 > Replace JBoss Logging by SLF4J > -- > > Key: ARTEMIS-137 > URL: https://issues.apache.org/jira/browse/ARTEMIS-137 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: clebert suconic > Fix For: 1.5.0 > > > nice to support i18n -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-198) Streamlet message support
[ https://issues.apache.org/jira/browse/ARTEMIS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-198: Fix Version/s: (was: 1.4.0) 1.5.0 > Streamlet message support > - > > Key: ARTEMIS-198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-198 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao >Priority: Minor > Fix For: 1.5.0 > > > Client can create an inputStream and outputStream directly on connections to > write and receive data from a destination. > Minor because the API marked as deprecated. > See test: > LargeStreamletTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-566) Cannot remove JMS queue that has been removed from Core side
[ https://issues.apache.org/jira/browse/ARTEMIS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-566: Fix Version/s: (was: 1.4.0) 1.5.0 > Cannot remove JMS queue that has been removed from Core side > > > Key: ARTEMIS-566 > URL: https://issues.apache.org/jira/browse/ARTEMIS-566 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.2.0, 1.3.0 >Reporter: Ville Skyttä >Priority: Minor > Fix For: 1.5.0 > > > If a queue that has been created from the JMS side is removed from the Core > side in JMX, a phantom JMS queue is left behind which cannot be removed. > 1) Start jconsole, connect to artemis > 2) Navigate in mbeans to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> > JMS -> Server -> Operations > 3) Invoke createQueue TestQueue > 4) Navigate to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core, note > that jms.queue.TestQueue is in both Address and Queue > 5) Navigate to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core -> > Server -> Operations > 6) Invoke destroyQueue TestQueue > 7) Note that jms.queue.TestQueue disappears from Address and Queue from > org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core (as expected) > 8) Navigate to Navigate in mbeans to org.apache.activemq.artemis -> Broker -> > 0.0.0.0 -> JMS -> Queue > 9) Note that TestQueue is still listed > 10) Try to remove it with destroyQueue TestQueue from > org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> JMS -> Server -> > Operations > 11) Get ActiveMQNonExistentQueueException, and the queue is not removed > A workaround is to restart artemis, that results in the Core side queue > becoming visible again, and then step 10) succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-245) Change resource adapter to work with Tomee
[ https://issues.apache.org/jira/browse/ARTEMIS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-245: Fix Version/s: (was: 1.4.0) 1.5.0 > Change resource adapter to work with Tomee > -- > > Key: ARTEMIS-245 > URL: https://issues.apache.org/jira/browse/ARTEMIS-245 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.0.0, 1.1.0, 1.2.0 >Reporter: clebert suconic > Fix For: 1.5.0 > > Attachments: patch.txt > > > It seems that Tomee requires a JMS interface to be returned. We should try > changing the RA to be compatible with it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-33: --- Fix Version/s: (was: 1.4.0) 1.5.0 > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: clebert suconic >Priority: Critical > Fix For: 1.5.0 > > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-167) OSGI artemis extensions (e.g vertx integration)
[ https://issues.apache.org/jira/browse/ARTEMIS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-167: Fix Version/s: (was: 1.4.0) 1.5.0 > OSGI artemis extensions (e.g vertx integration) > --- > > Key: ARTEMIS-167 > URL: https://issues.apache.org/jira/browse/ARTEMIS-167 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic >Priority: Minor > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-70) Implement resource limits
[ https://issues.apache.org/jira/browse/ARTEMIS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-70: --- Fix Version/s: (was: 1.4.0) 1.5.0 > 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 >Priority: Critical > Fix For: 1.5.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] [Updated] (ARTEMIS-483) Review Thread Pool usage in Artemis server/client
[ https://issues.apache.org/jira/browse/ARTEMIS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-483: Fix Version/s: (was: 1.4.0) 1.5.0 > Review Thread Pool usage in Artemis server/client > - > > Key: ARTEMIS-483 > URL: https://issues.apache.org/jira/browse/ARTEMIS-483 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 1.2.0 >Reporter: Martyn Taylor >Priority: Critical > Fix For: 1.5.0 > > > We are using several thread pool executors across the code base. The usage > and separation of these is in need of review, to ensure we avoid resource > wastage and starvation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-192) Implement Exclusive Consumer feature
[ https://issues.apache.org/jira/browse/ARTEMIS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-192: Fix Version/s: (was: 1.4.0) 1.5.0 > Implement Exclusive Consumer feature > > > Key: ARTEMIS-192 > URL: https://issues.apache.org/jira/browse/ARTEMIS-192 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao > Fix For: 1.5.0 > > > The concept is pretty much similar to "message group", which pins messages on > a queue to one consumer, in order to get message order. > ref: http://activemq.apache.org/exclusive-consumer.html > Test: JMSExclusiveConsumerTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-184) Fix openwire tests under org.apache.activemq.transport.tcp package
[ https://issues.apache.org/jira/browse/ARTEMIS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-184: Fix Version/s: (was: 1.4.0) 1.5.0 > Fix openwire tests under org.apache.activemq.transport.tcp package > -- > > Key: ARTEMIS-184 > URL: https://issues.apache.org/jira/browse/ARTEMIS-184 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: Howard Gao > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-166) Karaf WARs integration
[ https://issues.apache.org/jira/browse/ARTEMIS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-166: Fix Version/s: (was: 1.4.0) 1.5.0 > Karaf WARs integration > -- > > Key: ARTEMIS-166 > URL: https://issues.apache.org/jira/browse/ARTEMIS-166 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: clebert suconic > Fix For: 1.5.0 > > > Karaf has the possibility of adding WARs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-540) Supporting openshift as source of service discovery
[ https://issues.apache.org/jira/browse/ARTEMIS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-540: Fix Version/s: (was: 1.4.0) 1.5.0 > Supporting openshift as source of service discovery > --- > > Key: ARTEMIS-540 > URL: https://issues.apache.org/jira/browse/ARTEMIS-540 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: Broker >Affects Versions: 1.2.0 >Reporter: Kaiming Yang > Fix For: 1.5.0 > > > Artemis Apache MQ currently only support broadcast for service discovery. > At our company that is not allowed, hence we are looking to provide a plugin > that can use a different service discovery mechanism. > At our company we are using OpenShift 3.x, which provides service > discovery/lookup itself. We are looking to provide a mechanism that leverages > OSE as the service to provide Artemis cluster information dynamically and are > looking to provide those contributions back to the community. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-182) Fix openwire tests under org.apache.activemq.command package
[ https://issues.apache.org/jira/browse/ARTEMIS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-182: Fix Version/s: (was: 1.4.0) 1.5.0 > Fix openwire tests under org.apache.activemq.command package > > > Key: ARTEMIS-182 > URL: https://issues.apache.org/jira/browse/ARTEMIS-182 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: Howard Gao > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-174) Separated Journal per Address
[ https://issues.apache.org/jira/browse/ARTEMIS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-174: Fix Version/s: (was: 1.4.0) 1.5.0 > Separated Journal per Address > - > > Key: ARTEMIS-174 > URL: https://issues.apache.org/jira/browse/ARTEMIS-174 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: clebert suconic >Priority: Minor > Fix For: 1.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-402) Retroactive Consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-402: Fix Version/s: (was: 1.4.0) 1.5.0 > Retroactive Consumer > > > Key: ARTEMIS-402 > URL: https://issues.apache.org/jira/browse/ARTEMIS-402 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.1.0 >Reporter: Howard Gao >Priority: Minor > Fix For: 1.5.0 > > > ActiveMQ5.x has a feature called "Retroactive" consumers. > http://activemq.apache.org/retroactive-consumer.html > A retroactive consumer is a kind of jms topic subscriber which can receive > messages sent to the topic before the consumer is created. Normally if a > message is sent to a topic without a subscription, it will be discarded. This > kind of consumer however changes this as if it can go "back in time". > Test ref: > org.apache.activemq.broker.BrokerTest#testTopicRetroactiveConsumerSeeMessagesBeforeCreation() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-682) Support encrypted passwords in JAAS properties files
Justin Bertram created ARTEMIS-682: -- Summary: Support encrypted passwords in JAAS properties files Key: ARTEMIS-682 URL: https://issues.apache.org/jira/browse/ARTEMIS-682 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-591) Wrong XAException return code when broker timeout is hit
[
https://issues.apache.org/jira/browse/ARTEMIS-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422780#comment-15422780
]
ASF GitHub Bot commented on ARTEMIS-591:
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/722
> Wrong XAException return code when broker timeout is hit
>
>
> Key: ARTEMIS-591
> URL: https://issues.apache.org/jira/browse/ARTEMIS-591
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Chen Maoqian
>
> By creating testcases for checking behavior of transaction timeout I've hit
> an issue of wrong error code being returned when broker transaction timeout
> is hit before TM transaction timeout expires.
> It uses {{XAER_PROTO}} instead of {{RBTIMEOUT}}.
> This issue does not cause data inconsistency.
> Scenario:
> * ejb sends a message to a queue
> * processing inside of the ejb takes long time
> ** TM transaction timeout is set big enough to not hit the timeout
> ** jms broker internal transaction timeout is smaller than time needed for
> processing ejb method
> * jms broker txn timeout occurs - broker local txn is rolled back
> ** txn is removed from list of broker's local in-process transactions
> * TM calls XAResource.end
> ** the call returns {{XAException.XAER_PROTO}}
> That's current implementation returns {{XAER_PROTO}} in this scenario but
> {{RBTIMEOUT}} would be more appropriate.
> From discussion with Narayana developers, RM should return the most specific
> error return code as possible. In this scenario it's {{RBTIMEOUT}}.
> Other notes from TM dev point of view:
> {code}
> "[XA_RBTIMEOUT]
> The work represented by this transaction branch took too long."
> {code}
> _per XA spec page 39._
> The more complex question is, at what point can the resource manager forget
> about that branch (and therefore return NOTA to subsequent calls)?
> The XA spec says "After the transaction manager calls xa_end(), it should no
> longer consider the calling thread associated with that resource manager
> (although it must consider the resource manager part of the transaction
> branch when it prepares the branch.)"
> which implies the branch is still considered live at that point, a view
> corroborated by:
> {code}
> "[XA_RB∗]
> The resource manager has dissociated the transaction branch from the thread
> of control and has marked rollback-only the work performed on behalf of ∗xid."
> {code}
> Exception being thrown
> {code}
> WARN [com.arjuna.ats.jta] (Thread-0
> (ActiveMQ-client-global-threads-1468293951)) ARJUNA016056:
> TransactionImple.delistResource - caught exception during delist :
> XAException.XAER_PROTO: javax.transaction.xa.XAException
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:346)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1115)
> at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
> at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:897)
> at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(TxConnectionListener.java:1063)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(TransactionSynchronizer.java:438)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(TransactionSynchronizer.java:376)
> at
> org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:130)
> at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Commented] (ARTEMIS-591) Wrong XAException return code when broker timeout is hit
[
https://issues.apache.org/jira/browse/ARTEMIS-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422779#comment-15422779
]
ASF subversion and git services commented on ARTEMIS-591:
-
Commit ad21b5b70b4bc34605291773ca424a31c57b41b5 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ad21b5b ]
ARTEMIS-591 Fixing typos
> Wrong XAException return code when broker timeout is hit
>
>
> Key: ARTEMIS-591
> URL: https://issues.apache.org/jira/browse/ARTEMIS-591
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Chen Maoqian
>
> By creating testcases for checking behavior of transaction timeout I've hit
> an issue of wrong error code being returned when broker transaction timeout
> is hit before TM transaction timeout expires.
> It uses {{XAER_PROTO}} instead of {{RBTIMEOUT}}.
> This issue does not cause data inconsistency.
> Scenario:
> * ejb sends a message to a queue
> * processing inside of the ejb takes long time
> ** TM transaction timeout is set big enough to not hit the timeout
> ** jms broker internal transaction timeout is smaller than time needed for
> processing ejb method
> * jms broker txn timeout occurs - broker local txn is rolled back
> ** txn is removed from list of broker's local in-process transactions
> * TM calls XAResource.end
> ** the call returns {{XAException.XAER_PROTO}}
> That's current implementation returns {{XAER_PROTO}} in this scenario but
> {{RBTIMEOUT}} would be more appropriate.
> From discussion with Narayana developers, RM should return the most specific
> error return code as possible. In this scenario it's {{RBTIMEOUT}}.
> Other notes from TM dev point of view:
> {code}
> "[XA_RBTIMEOUT]
> The work represented by this transaction branch took too long."
> {code}
> _per XA spec page 39._
> The more complex question is, at what point can the resource manager forget
> about that branch (and therefore return NOTA to subsequent calls)?
> The XA spec says "After the transaction manager calls xa_end(), it should no
> longer consider the calling thread associated with that resource manager
> (although it must consider the resource manager part of the transaction
> branch when it prepares the branch.)"
> which implies the branch is still considered live at that point, a view
> corroborated by:
> {code}
> "[XA_RB∗]
> The resource manager has dissociated the transaction branch from the thread
> of control and has marked rollback-only the work performed on behalf of ∗xid."
> {code}
> Exception being thrown
> {code}
> WARN [com.arjuna.ats.jta] (Thread-0
> (ActiveMQ-client-global-threads-1468293951)) ARJUNA016056:
> TransactionImple.delistResource - caught exception during delist :
> XAException.XAER_PROTO: javax.transaction.xa.XAException
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:346)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1115)
> at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
> at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:897)
> at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(TxConnectionListener.java:1063)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(TransactionSynchronizer.java:438)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(TransactionSynchronizer.java:376)
> at
> org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:130)
> at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at
>
[jira] [Commented] (ARTEMIS-681) Do not use just one "sf.my-cluster..." queue for message load-balancing and redistribution
[ https://issues.apache.org/jira/browse/ARTEMIS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422775#comment-15422775 ] Justin Bertram commented on ARTEMIS-681: Can you quantify the performance bottleneck? > Do not use just one "sf.my-cluster..." queue for message load-balancing and > redistribution > --- > > Key: ARTEMIS-681 > URL: https://issues.apache.org/jira/browse/ARTEMIS-681 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.3.0 >Reporter: Miroslav Novak >Priority: Critical > > For load balancing of messages in cluster is used just one "sf.my-cluster..." > queue which is used for routing messages to remote cluster node. This is > major performance bottleneck and scaling up blocker in case if there are 100s > queues/topics on server and there is just one queue to route messages to > another node in cluster. > Expected behavior: There should be special "routing" queue for every queue > and topic subscription per "remote" cluster node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Deleted] (AMQCPP-602) hacked by sec sh
[ https://issues.apache.org/jira/browse/AMQCPP-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish deleted AMQCPP-602: > hacked by sec sh > > > Key: AMQCPP-602 > URL: https://issues.apache.org/jira/browse/AMQCPP-602 > Project: ActiveMQ C++ Client > Issue Type: Bug > Environment: hacked by sec sh hacked by sec sh hacked by sec sh > hacked by sec sh hacked by sec sh hacked by sec sh hacked by sec sh hacked by > sec sh hacked by sec sh hacked by sec sh hacked by sec sh hacked by sec sh > hacked by sec sh >Reporter: smith smok >Assignee: Timothy Bish > Labels: newbie > > hacked by sec sh hacked by sec sh hacked by sec sh hacked by sec sh hacked by > sec sh hacked by sec sh hacked by sec sh -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-681) Do not use just one "sf.my-cluster..." queue for message load-balancing and redistribution
[ https://issues.apache.org/jira/browse/ARTEMIS-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miroslav Novak updated ARTEMIS-681: --- Priority: Critical (was: Major) > Do not use just one "sf.my-cluster..." queue for message load-balancing and > redistribution > --- > > Key: ARTEMIS-681 > URL: https://issues.apache.org/jira/browse/ARTEMIS-681 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.3.0 >Reporter: Miroslav Novak >Priority: Critical > > For load balancing of messages in cluster is used just one "sf.my-cluster..." > queue which is used for routing messages to remote cluster node. This is > major performance bottleneck and scaling up blocker in case if there are 100s > queues/topics on server and there is just one queue to route messages to > another node in cluster. > Expected behavior: There should be special "routing" queue for every queue > and topic subscription per "remote" cluster node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-681) Do not use just one "sf.my-cluster..." queue for message load-balancing and redistribution
Miroslav Novak created ARTEMIS-681: -- Summary: Do not use just one "sf.my-cluster..." queue for message load-balancing and redistribution Key: ARTEMIS-681 URL: https://issues.apache.org/jira/browse/ARTEMIS-681 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 1.3.0 Reporter: Miroslav Novak For load balancing of messages in cluster is used just one "sf.my-cluster..." queue which is used for routing messages to remote cluster node. This is major performance bottleneck and scaling up blocker in case if there are 100s queues/topics on server and there is just one queue to route messages to another node in cluster. Expected behavior: There should be special "routing" queue for every queue and topic subscription per "remote" cluster node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-592) Allow fine grain access control (durable subscriptions)
[
https://issues.apache.org/jira/browse/ARTEMIS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422542#comment-15422542
]
Martyn Taylor commented on ARTEMIS-592:
---
"Can we send messages directly to these queues? With Apollo and ActiveMQ 5.x,
we can."
In STOMP this is possible. But not just any client has access to the queue.
The STOMP implementation will prepend durable subscriptions with the client-id.
So subscribing to "foo" with client-id "123" allows you to consume from the
queue "123.foo". This is how the STOMP implementation behaves.
"Do we allow multiple connections to the same queue (see @clebertsuconic
question "Wouldn't be easier if we just failed more than one connection with
the same client-id?")? With Apollo and ActiveMQ 5.x, we can and messages will
be split between all consumers, like with regular queues."
We do. Similar to how we handle durable subscriptions (explained above). It's
possible to have more than 1 STOMP client with the same ID connect to the
broker. Thus, all clients with ID 123 are able to subscribe to "123.foo".
This has some limitations, a client with ID 123, is not able to "share a
durable subscription queue" with client ID 456. This behaviour of sharing
queues based on the client-id field isn't supported across all protocols. In
order to do this we may have to break the spec of some protocols (which may or
may not be acceptable) MQTT is an example of where this is explicitly outlined
in the spec as not supported.
TBH I'm not sure if the shared durable subscription ability (through client-id)
was intentional or was a side effect of the implementation.
"Can we define different security settings (this is the initial scope of this
Jira issue)? With Apollo and ActiveMQ 5.x, we can."
Yes this fix allows you to do that with STOMP.
"Since Artemis supports multiple protocols, the next question is how much of
this is (mostly) protocol independent and ends up in the Core and how much is
protocol specific."
Justin's point, which I think is a good one. Is that by securing queues, it's
possible to apply it across protocols. The slight concern I had was that
protocol implementations use queues to expose the desired protocol features.
Using security settings at the queue level, requires exposing the underlying
implementation details of each protocol. I'm now feeling OK with this if we
can somehow standardise the internal naming schemes across all protocols. I
believe STOMP durable subscriptions are ., MQTT is
similar ..
"From a user point of view, the more gets protocol independent, the better. I
would prefer to have the same security settings regarding which protocols the
clients end up using. Justin's proposal to concatenate the address and queue
names looks fine to me."
Yes, to make this non protocol specific we could perhaps support something
similar to virtual destinations or standardise on the naming scheme.
> Allow fine grain access control (durable subscriptions)
> ---
>
> Key: ARTEMIS-592
> URL: https://issues.apache.org/jira/browse/ARTEMIS-592
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> According to the documentation:
> {quote}
> Apache ActiveMQ Artemis allows sets of permissions to be defined against the
> queues based on their address.
> {quote}
> Two different subscriptions on the same topic will have the same address (the
> topic), only their name will change. So it seems they will get the same
> permissions.
> Could you please allow fine grain access control to be able to set different
> permissions to different durable subscriptions of the same topic?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-592) Allow fine grain access control (durable subscriptions)
[
https://issues.apache.org/jira/browse/ARTEMIS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422466#comment-15422466
]
Lionel Cons commented on ARTEMIS-592:
-
IMHO, it is very important to define precisely how Artemis handles durable
STOMP subscriptions.
Since they are durable, they are related to some kind of queues somewhere.
Can we send messages directly to these queues? With Apollo and ActiveMQ 5.x, we
can.
Do we allow multiple connections to the same queue (see @clebertsuconic
question "Wouldn't be easier if we just failed more than one connection with
the same client-id?")? With Apollo and ActiveMQ 5.x, we can and messages will
be split between all consumers, like with regular queues.
Can we define different security settings (this is the initial scope of this
Jira issue)? With Apollo and ActiveMQ 5.x, we can.
Since Artemis supports multiple protocols, the next question is how much of
this is (mostly) protocol independent and ends up in the Core and how much is
protocol specific.
>From a user point of view, the more gets protocol independent, the better. I
>would prefer to have the same security settings regarding which protocols the
>clients end up using. Justin's proposal to concatenate the address and queue
>names looks fine to me.
> Allow fine grain access control (durable subscriptions)
> ---
>
> Key: ARTEMIS-592
> URL: https://issues.apache.org/jira/browse/ARTEMIS-592
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>
> According to the documentation:
> {quote}
> Apache ActiveMQ Artemis allows sets of permissions to be defined against the
> queues based on their address.
> {quote}
> Two different subscriptions on the same topic will have the same address (the
> topic), only their name will change. So it seems they will get the same
> permissions.
> Could you please allow fine grain access control to be able to set different
> permissions to different durable subscriptions of the same topic?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-581) Add setting to control global disk usage
[
https://issues.apache.org/jira/browse/ARTEMIS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422444#comment-15422444
]
Lionel Cons commented on ARTEMIS-581:
-
FWIW, ActiveMQ 5.x has several parameters (such as {{sendFailIfNoSpace}} or
{{sendFailIfNoSpaceAfterTimeout}}) to control what happens when resources are
exhausted, see http://activemq.apache.org/producer-flow-control.html.
IMHO, configuring the response (block, fail...) should be independent from the
cause (disk full, single queue full...) and should very likely be protocol
specific since not all protocols support flow control.
If the response cannot be configured, I would prefer to first try to block (if
the protocol allows it) and then fail if blocking does not work.
> Add setting to control global disk usage
> -
>
> Key: ARTEMIS-581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-581
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Lionel Cons
>Assignee: clebert suconic
>Priority: Blocker
> Fix For: 1.4.0
>
>
> AFAIK, there is no way to prevent Artemis from using too much space on the
> disk (with paged messages).
> Disk space, just like memory space, is limited and Artemis should detect when
> it is about to use too much space and act accordingly (i.e. DROP, FAIL...).
> ActiveMQ 5.x does allow controlling disk usage via its {{storeUsage}} and
> {{tempUsage}} settings in {{systemUsage}}.
> Could Artemis also use a global disk setting to limit its disk usage?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6394) Activemq leveldb file issue
[ https://issues.apache.org/jira/browse/AMQ-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422292#comment-15422292 ] Julius commented on AMQ-6394: - I tested the ActiveMQ 5.14.0, but this issue is still exist. > Activemq leveldb file issue > --- > > Key: AMQ-6394 > URL: https://issues.apache.org/jira/browse/AMQ-6394 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.10.0 >Reporter: Julius >Priority: Minor > > Test case: > I created two queues test_1 and test_2. > From the same time send message to test_1 and test_2 queues,the message size > is 10k, but send to test_1 is fast, send to test_2 is slow, the aim is allow > each leveldb file contains a large number of test_1's messages and a small > amount of test_2's messages. > after stop send, test_1 stored 686 messages,test_1 stored 141888 messages, > generated following leveldb of files : > 101M.log > 101M0640077d.log > 101M0c800a63.log > 101M12c00eeb.log > 101M19001432.log > 7.1M1f4017fe.index > 30M 1f4017fe.log > After have consumed test_1 of all messages. But leveled of files are't > change, file capacity is not reduced.This will lead to store a small amount > of messages take up a lot of disk capacity. > The how to solve this problem? > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
