[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335388#comment-16335388 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 @clebertsuconic can you take a look at the additional commit ? > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1628. - Resolution: Fixed > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335334#comment-16335334 ] ASF subversion and git services commented on ARTEMIS-1628: -- Commit 35222485e84069394546f6220dd514964b3951ce in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=3522248 ] ARTEMIS-1628 Limit pool size on artemis journal > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335335#comment-16335335 ] ASF GitHub Bot commented on ARTEMIS-1628: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1803 > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335319#comment-16335319 ] ASF GitHub Bot commented on ARTEMIS-1626: - GitHub user gaohoward reopened a pull request: https://github.com/apache/activemq-artemis/pull/1800 ARTEMIS-1626 Disable thread leak check for failing tests The ThreadLeakCheckRule is used to check thread leaks after each test is finished. However when a test fails, it is not necessary to check leaking threads because the test failure should be fixed anyway. And leaking threads in a failed test may well be a result of the failure (once the test is fixed the thread leak may be gone). If a failed test also leaks threads, it takes a long time before the thread leak check finishes (60 seconds checking time), thus it takes a long time to finish, especially when tests are run in batches with failures. So to improve this, it should be reasonable to just enable the thread leaking check for each test passes, and disable the check when a test fails. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gaohoward/activemq-artemis fthread_rule Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1800.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1800 commit c8e25c72b9885bb08ec9dd5d8502c273b349d46a Author: Howard Gao Date: 2018-01-22T14:39:23Z ARTEMIS-1626 Disable thread leak check for failing tests The ThreadLeakCheckRule is used to check thread leaks after each test is finished. However when a test fails, it is not necessary to check leaking threads because the test failure should be fixed anyway. And leaking threads in a failed test may well be a result of the failure (once the test is fixed the thread leak may be gone). If a failed test also leaks threads, it takes a long time before the thread leak check finishes (60 seconds checking time), thus it takes a long time to finish, especially when tests are run in batches with failures. So to improve this, it should be reasonable to just enable the thread leaking check for each test passes, and disable the check when a test fails. > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335318#comment-16335318 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 reopen for further discussion. > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335311#comment-16335311 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 @clebertsuconic regarding the thread leak logging, I don't think I got it right. Do you mean if test failed, we give the thread logging, what about test that pases? (just keep in mind if test failed we sure will check and log without this PR) > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335306#comment-16335306 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 Right now it fails the test. If you changed it to log only if the test failed. You got what you wanted. And what we wanted. It’s a good compromise. > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335302#comment-16335302 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 Please don’t close those. Just change it to log. > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335303#comment-16335303 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 I think logging would eventually turn on the thread checking, that's the original behavior, no need to change anything, right? > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335301#comment-16335301 ] ASF GitHub Bot commented on ARTEMIS-1628: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1803 I can merge this. > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335288#comment-16335288 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 All we asked was logging instead. > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335287#comment-16335287 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 Why close it instead of logging it ? > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335284#comment-16335284 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 ok, I think it's better to take cautions as people worries about it. Thanks you guys for the opinions ! > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335285#comment-16335285 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user gaohoward closed the pull request at: https://github.com/apache/activemq-artemis/pull/1800 > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-608) Document how to add user-provided classes to Broker class path
[
https://issues.apache.org/jira/browse/ARTEMIS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-608.
Resolution: Fixed
Fix Version/s: 2.5.0
> Document how to add user-provided classes to Broker class path
> --
>
> Key: ARTEMIS-608
> URL: https://issues.apache.org/jira/browse/ARTEMIS-608
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
> Fix For: 2.5.0
>
>
> Broker reads the {{lib}} directory in the broker home directory and a {{lib}}
> directory **in the broker instance directory** and jar files in these
> directories are put on the class path. To provide my own Interceptor or
> something, it should be built into a jar and (together with all depending
> jars) dropped into the instance's lib directory, so it can be found by the
> broker.
> This deserves to be written up in the documentation. I believe that the only
> place this is described (the part about the instance's lib at least) is
> http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.
> Appropriate place for this explanation might be be
> {{docs/user-manual/en/using-server.md}}
> There are few references to it, I managed to find
> {{docs/user-manual/en/intercepting-operations.md}} and
> {{docs/user-manual/en/persistence.md}} which say
> {quote}The interceptors classes (and their dependencies) must be added to the
> server classpath to be properly instantiated and called.{quote}
> {quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You
> can do this by dropping the relevant jars in the lib folder of the ActiveMQ
> Artemis distribution.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-609) Documentation for Interceptors is wrong regarding broker.xml file structure
[
https://issues.apache.org/jira/browse/ARTEMIS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-609.
Resolution: Fixed
Fix Version/s: 2.5.0
> Documentation for Interceptors is wrong regarding broker.xml file structure
> ---
>
> Key: ARTEMIS-609
> URL: https://issues.apache.org/jira/browse/ARTEMIS-609
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
> Fix For: 2.5.0
>
>
> Documentation suggests that the {{}} element
> is a direct children of the {{}} element. In fact, it must be
> children of the {{}} element, the way it is done in
> {{examples/features/standard/interceptor/src/main/resources/activemq/server0/broker.xml}}.
> This issue is present in the following files
> * {{docs/user-manual/en/intercepting-operations.md}}
> * {{examples/features/standard/interceptor/readme.html}}
> * {{examples/features/standard/interceptor-client/readme.html}}
> I worry that these obsolete configuration fragments are remnants of some past
> change in the {{broker.xml}} file structure and that there could be more to
> be found.
> One more thing. The last two files in my list have completely the same
> content. Is that really intentional?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-764) Migrate generic jms connection pool from ActiveMQ5 to Artemis
[ https://issues.apache.org/jira/browse/ARTEMIS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-764. Resolution: Duplicate > Migrate generic jms connection pool from ActiveMQ5 to Artemis > - > > Key: ARTEMIS-764 > URL: https://issues.apache.org/jira/browse/ARTEMIS-764 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Benjamin Graf >Priority: Major > > Add pooling capability to Artemis -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-469) Artemis needs PoolingConnectionFactory for standalone clients
[ https://issues.apache.org/jira/browse/ARTEMIS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-469. Resolution: Information Provided > Artemis needs PoolingConnectionFactory for standalone clients > - > > Key: ARTEMIS-469 > URL: https://issues.apache.org/jira/browse/ARTEMIS-469 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker > Environment: Solaris >Reporter: Abhijith Prabhakar >Priority: Major > > Artemis does not have PoolingConnectionFactory which can be used outside of > container in standalone applications. More on conversation here: > http://activemq.2283324.n4.nabble.com/Apache-Artemis-pooling-td4707663.html#a4707675 > Similar to ActiveMQ, Artemis needs a standalone PoolingConnectionFactory > which is built on JMS 2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1607) OpenWire is sending responses too early with durable messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335169#comment-16335169 ] ASF GitHub Bot commented on ARTEMIS-1607: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1801 @clebertsuconic Np I've understood what you mean :) I've pushed another commit with another solution less "reactive" but more simlar to the original code: let me know if it seems better and I will squash the commits into this last one :+1: > OpenWire is sending responses too early with durable messages > - > > Key: ARTEMIS-1607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1607 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1625) Moving messages is broken
[ https://issues.apache.org/jira/browse/ARTEMIS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335115#comment-16335115 ] ASF GitHub Bot commented on ARTEMIS-1625: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1799 > Moving messages is broken > - > > Key: ARTEMIS-1625 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1625 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Stanislav Knot >Priority: Major > > Create address X > attach anycast queues A and B under address X > send message from A > move message from A to B ( incorrect green notification appears ) > check queues A and B, the message is not moved ... it is moved, but back to > queue A, itself. > try again to move message from A to B ( green notification ) > message is moved -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1625) Moving messages is broken
[ https://issues.apache.org/jira/browse/ARTEMIS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335114#comment-16335114 ] ASF subversion and git services commented on ARTEMIS-1625: -- Commit 156372ab40bbf2ccb1367059c44b2f4f69130e7c in activemq-artemis's branch refs/heads/master from [~sknot] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=156372a ] ARTEMIS-1625 fix moving messages > Moving messages is broken > - > > Key: ARTEMIS-1625 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1625 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Stanislav Knot >Priority: Major > > Create address X > attach anycast queues A and B under address X > send message from A > move message from A to B ( incorrect green notification appears ) > check queues A and B, the message is not moved ... it is moved, but back to > queue A, itself. > try again to move message from A to B ( green notification ) > message is moved -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335111#comment-16335111 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit c6b6dd95d1665230d667557df240d8a62a2118af in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=c6b6dd9 ] ARTEMIS-1616 OpenWire improvements Refactored OpenWireMessageConverter::toAMQMessage into smaller methods > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335108#comment-16335108 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit 64724c3520586c6cd1bc0aec9942ae5bb5562459 in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=64724c3 ] ARTEMIS-1616 OpenWire improvements Used SimpleString on OpenWireMessageConverter to avoid translations on CoreMessage > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335109#comment-16335109 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit 9650c80ba701acbf727f379bd11cdd663b47 in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9650c80 ] ARTEMIS-1616 OpenWire improvements Cached Notification Destination check on AMQConsumer to avoid expensive ActiveMQDestination::toString > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335110#comment-16335110 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit e7a1dca7b54bc47002b5d743115c1c790ead9579 in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=e7a1dca ] ARTEMIS-1616 OpenWire improvements Used SimpleString on AMQSession with HDR_DUPLICATE_DETECTION_ID and CONNECTION_ID_PROPERTY_NAME > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335107#comment-16335107 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit 17c0a331aceda16460cc4d87f376c8730e479fe5 in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=17c0a33 ] ARTEMIS-1616 OpenWire improvements Added existing queues cache to avoid multiple expensive AMQSession::checkAutoCreateQueue calls > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335113#comment-16335113 ] ASF GitHub Bot commented on ARTEMIS-1616: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1786 > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335112#comment-16335112 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit 0387b1a8427673f42166df5651bc504d38f365ce in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=0387b1a ] ARTEMIS-1616 OpenWire improvements Refactored OpenWireMessageConverter::inbound into a private static method > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335104#comment-16335104 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit 2db4eafc4d81cd18f9394e356ee11b202f5f2301 in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2db4eaf ] ARTEMIS-1616 OpenWire improvements Avoided copy of CoreMessage when not needed and cached lambda on hot path > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335106#comment-16335106 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit 051a3cae49c488314b9a5ccaa36056a358e4b9df in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=051a3ca ] ARTEMIS-1616 OpenWire improvements Optimized SimpleString::split because heavily used into AddressImpl::new > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335105#comment-16335105 ] ASF subversion and git services commented on ARTEMIS-1616: -- Commit 54d0161850bc4543839d4f36b46f3bd84f5cd8e1 in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=54d0161 ] ARTEMIS-1616 OpenWire improvements Refactored OpenWireMessageConverter::inbound into smaller methods > OpenWire improvements > - > > Key: ARTEMIS-1616 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1616 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1607) OpenWire is sending responses too early with durable messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335101#comment-16335101 ] ASF GitHub Bot commented on ARTEMIS-1607: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1801 @franz1981 typo on my last message.. I actually meant the autoRead stuff. > OpenWire is sending responses too early with durable messages > - > > Key: ARTEMIS-1607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1607 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1498) [interop] Openwire internal headers should not be part of message properties
[
https://issues.apache.org/jira/browse/ARTEMIS-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335099#comment-16335099
]
ASF GitHub Bot commented on ARTEMIS-1498:
-
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1793
I ran the whole testsuite and it didn't complete.
it's a very nice start though.
> [interop] Openwire internal headers should not be part of message properties
>
>
> Key: ARTEMIS-1498
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1498
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
> Environment: interoperability between Openwire -> AMQP/Core
>Reporter: Michal Toth
>Priority: Minor
>
> Sending an empty message from Openwire JMS client to AMQP or Core receiver
> client shows extra "internal" headers (__HDR_*) in message properties.
> They should not be there, as these are internal for broker in my opinion.
> Openwire sender
> {noformat}
> $ java -jar /var/dtests/node_data/clients/aoc7.jar sender --timeout 5
> --log-msgs interop --broker tcp://localhost:61616 --address queue_name_\$
> --count 1 --conn-username admin --conn-password admin
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False,
> 'delivery-count': 0, 'id':
> 'dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1:1:1:1',
> 'user-id':None, 'address': 'queue_name_$', 'subject': None, 'reply-to': None,
> 'correlation-id': None, 'content-type': None, 'content-encoding': None,
> 'absolute-expiry-time': 0, 'creation-time': 1509702974798, 'group-id': None,
> 'group-sequence': 0, 'reply-to-group-id': None, 'properties': {}, 'content':
> None, 'type': None}
> {noformat}
> AMQP/Core receiver
> {noformat}
> $ java -jar /var/dtests/node_data/clients/aac1.jar receiver --timeout 5
> --log-msgs interop --broker localhost:5672 --address queue_name_\$ --count 1
> --conn-username admin --conn-password admin
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x00Jn\x02\xae\x02{\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01\x00\x01
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x00F{\x01+\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False,
> 'delivery-count': 0, 'id': None, 'user-id': None, 'address': 'queue_name_$',
> 'subject': None, 'reply-to': None, 'correlation-id': None, 'content-type':
> None, 'content-encoding': None, 'absolute-expiry-time': 0, 'creation-time':
> 1509702974798, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id':
> None, 'properties': {'__HDR_COMMAND_ID': 5, 'JMSXDeliveryCount': 1,
> '__HDR_ARRIVAL': 0, '__HDR_MESSAGE_ID':
> \x00\x00\x00Jn\x02\xae\x02{\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01\x00\x01,
> '__HDR_GROUP_SEQUENCE': 0, '__HDR_PRODUCER_ID':
> \x00\x00\x00F{\x01+\x00=ID:dhcp-145-96.lab.eng.brq.redhat.com-33646-1509702974536-1:1\x00\x01\x00\x01,
> '__HDR_DROPPABLE': False, '__HDR_BROKER_IN_TIME': 1509702974800}, 'content':
> None}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1607) OpenWire is sending responses too early with durable messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335080#comment-16335080 ] ASF GitHub Bot commented on ARTEMIS-1607: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1801 @franz1981 I told you it was ok to do it this way.. but I'm a bit concerned by the use of setResponse(true) and false through this. is there a way to return the packet like it used to be done before? can you check the setRespond(true) and false usages? I'm concerned of a possible race making the server unavailable eventually. > OpenWire is sending responses too early with durable messages > - > > Key: ARTEMIS-1607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1607 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-609) Documentation for Interceptors is wrong regarding broker.xml file structure
[
https://issues.apache.org/jira/browse/ARTEMIS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335078#comment-16335078
]
ASF GitHub Bot commented on ARTEMIS-609:
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1805
> Documentation for Interceptors is wrong regarding broker.xml file structure
> ---
>
> Key: ARTEMIS-609
> URL: https://issues.apache.org/jira/browse/ARTEMIS-609
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
>
> Documentation suggests that the {{}} element
> is a direct children of the {{}} element. In fact, it must be
> children of the {{}} element, the way it is done in
> {{examples/features/standard/interceptor/src/main/resources/activemq/server0/broker.xml}}.
> This issue is present in the following files
> * {{docs/user-manual/en/intercepting-operations.md}}
> * {{examples/features/standard/interceptor/readme.html}}
> * {{examples/features/standard/interceptor-client/readme.html}}
> I worry that these obsolete configuration fragments are remnants of some past
> change in the {{broker.xml}} file structure and that there could be more to
> be found.
> One more thing. The last two files in my list have completely the same
> content. Is that really intentional?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-609) Documentation for Interceptors is wrong regarding broker.xml file structure
[
https://issues.apache.org/jira/browse/ARTEMIS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335077#comment-16335077
]
ASF subversion and git services commented on ARTEMIS-609:
-
Commit 04298136b785f6ac76ab777dd1fc05da159b7d06 in activemq-artemis's branch
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=0429813 ]
ARTEMIS-609 fix interceptor XML docs
> Documentation for Interceptors is wrong regarding broker.xml file structure
> ---
>
> Key: ARTEMIS-609
> URL: https://issues.apache.org/jira/browse/ARTEMIS-609
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
>
> Documentation suggests that the {{}} element
> is a direct children of the {{}} element. In fact, it must be
> children of the {{}} element, the way it is done in
> {{examples/features/standard/interceptor/src/main/resources/activemq/server0/broker.xml}}.
> This issue is present in the following files
> * {{docs/user-manual/en/intercepting-operations.md}}
> * {{examples/features/standard/interceptor/readme.html}}
> * {{examples/features/standard/interceptor-client/readme.html}}
> I worry that these obsolete configuration fragments are remnants of some past
> change in the {{broker.xml}} file structure and that there could be more to
> be found.
> One more thing. The last two files in my list have completely the same
> content. Is that really intentional?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1504) AMQP: Update Qpid JMS to latest 0.29.0 release and Proton-j to 0.25.0 to match
[ https://issues.apache.org/jira/browse/ARTEMIS-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335075#comment-16335075 ] ASF subversion and git services commented on ARTEMIS-1504: -- Commit 5e6967c809b9b0dbefb6e0fa25161d6ae5e7ece6 in activemq-artemis's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5e6967c ] ARTEMIS-1504 Update Qpid JMS to 0.29.0 and proton-j to 0.25.0 Updates to latest Qpid JMS and the latest Proton-J release > AMQP: Update Qpid JMS to latest 0.29.0 release and Proton-j to 0.25.0 to match > -- > > Key: ARTEMIS-1504 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1504 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 2.5.0 > > > Update to latest Qpid-JMS release and match its Proton-J dependency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1504) AMQP: Update Qpid JMS to latest 0.29.0 release and Proton-j to 0.25.0 to match
[ https://issues.apache.org/jira/browse/ARTEMIS-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335076#comment-16335076 ] ASF GitHub Bot commented on ARTEMIS-1504: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1802 > AMQP: Update Qpid JMS to latest 0.29.0 release and Proton-j to 0.25.0 to match > -- > > Key: ARTEMIS-1504 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1504 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 2.5.0 > > > Update to latest Qpid-JMS release and match its Proton-J dependency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQCPP-623) Can't build on some newer OpenSSL versions
[ https://issues.apache.org/jira/browse/AMQCPP-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-623. - Resolution: Fixed > Can't build on some newer OpenSSL versions > -- > > Key: AMQCPP-623 > URL: https://issues.apache.org/jira/browse/AMQCPP-623 > Project: ActiveMQ C++ Client > Issue Type: Bug >Affects Versions: 3.9.4 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 3.9.5 > > > Some newer revisions of OpenSSL such as those on latest Fedora releases cause > an error in compilation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQCPP-622) Memory leaks in the handshake of a OpenSSL connection
[
https://issues.apache.org/jira/browse/AMQCPP-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQCPP-622.
-
Resolution: Fixed
Fix Version/s: 3.9.5
> Memory leaks in the handshake of a OpenSSL connection
> -
>
> Key: AMQCPP-622
> URL: https://issues.apache.org/jira/browse/AMQCPP-622
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: Decaf
>Affects Versions: 3.9.4
>Reporter: Daniel Laügt
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 3.9.5
>
> Attachments: OpenSSLSocket.cpp.patch
>
>
> ActiveMQ transport has two memory leaks in the handshake of a OpenSSL
> connection.
> {noformat}
> ==15167== Memcheck, a memory error detector
> ==15167== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==15167== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==15167==
> ==15167==
> ==15167== HEAP SUMMARY:
> ==15167== in use at exit: 4,682,917 bytes in 8,351 blocks
> ==15167== total heap usage: 108,257 allocs, 99,907 frees, 64,602,948 bytes
> allocated
> ==15167==
> ==15167== 207 (32 direct, 175 indirect) bytes in 1 blocks are definitely lost
> in loss record 2,149 of 2,859
> ==15167==at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15167==by 0x6D8DA67: CRYPTO_malloc (mem.c:346)
> ==15167==by 0x6E3FEBE: sk_new (stack.c:162)
> ==15167==by 0x6E93024: X509V3_add_value (v3_utl.c:93)
> ==15167==by 0x6E94BD8: i2v_GENERAL_NAME (v3_alt.c:142)
> ==15167==by 0x6E94D2A: i2v_GENERAL_NAMES (v3_alt.c:106)
> ==15167==by 0x19B5FF6E:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::verifyServerCert(std::string
> const&) (OpenSSLSocket.cpp:671)
> ==15167==by 0x19B61481:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::startHandshake()
> (OpenSSLSocket.cpp:379)
> ==15167==by 0x19B5FA95:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::write(unsigned char
> const*, int, int, int) (OpenSSLSocket.cpp:566)
> ==15167==by 0x19B63520:
> decaf::internal::net::ssl::openssl::OpenSSLSocketOutputStream::doWriteArrayBounded(unsigned
> char const*, int, int, int) (OpenSSLSocketOutputStream.cpp:91)
> ==15167==by 0x19BB14D1: decaf::io::OutputStream::doWriteArray(unsigned
> char const*, int) (OutputStream.cpp:89)
> ==15167==by 0x19BB1255: decaf::io::OutputStream::write(unsigned char
> const*, int) (OutputStream.cpp:65)
> ==15167==
> ==15167== 228 (32 direct, 196 indirect) bytes in 1 blocks are definitely lost
> in loss record 2,153 of 2,859
> ==15167==at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15167==by 0x6D8DA67: CRYPTO_malloc (mem.c:346)
> ==15167==by 0x6E3FEBE: sk_new (stack.c:162)
> ==15167==by 0x6E6ED08: asn1_template_noexp_d2i (tasn_dec.c:634)
> ==15167==by 0x6E6EE34: asn1_template_ex_d2i (tasn_dec.c:584)
> ==15167==by 0x6E6E4A5: ASN1_item_ex_d2i (tasn_dec.c:206)
> ==15167==by 0x6E6E983: ASN1_item_d2i (tasn_dec.c:146)
> ==15167==by 0x19B5FF4C:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::verifyServerCert(std::string
> const&) (OpenSSLSocket.cpp:671)
> ==15167==by 0x19B61481:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::startHandshake()
> (OpenSSLSocket.cpp:379)
> ==15167==by 0x19B5FA95:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::write(unsigned char
> const*, int, int, int) (OpenSSLSocket.cpp:566)
> ==15167==by 0x19B63520:
> decaf::internal::net::ssl::openssl::OpenSSLSocketOutputStream::doWriteArrayBounded(unsigned
> char const*, int, int, int) (OpenSSLSocketOutputStream.cpp:91)
> ==15167==by 0x19BB14D1: decaf::io::OutputStream::doWriteArray(unsigned
> char const*, int) (OutputStream.cpp:89)
> ==15167==
> ==15167== LEAK SUMMARY:
> ==15167==definitely lost: 64 bytes in 2 blocks
> ==15167==indirectly lost: 371 bytes in 20 blocks
> ==15167== possibly lost: 176,608 bytes in 28 blocks
> ==15167==still reachable: 2,705,672 bytes in 6,620 blocks
> ==15167== suppressed: 1,800,202 bytes in 1,681 blocks
> ==15167== Reachable blocks (those to which a pointer was found) are not shown.
> ==15167== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQCPP-623) Can't build on some newer OpenSSL versions
[ https://issues.apache.org/jira/browse/AMQCPP-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335003#comment-16335003 ] ASF subversion and git services commented on AMQCPP-623: Commit 0eb4320503f34d90f2668211486e97974f926918 in activemq-cpp's branch refs/heads/3.9.x from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq-cpp.git;h=0eb4320 ] AMQCPP-623 AMQCPP-622 Fix OpenSSL issues Fix possible memory leak and address issues with build on newer releases. > Can't build on some newer OpenSSL versions > -- > > Key: AMQCPP-623 > URL: https://issues.apache.org/jira/browse/AMQCPP-623 > Project: ActiveMQ C++ Client > Issue Type: Bug >Affects Versions: 3.9.4 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 3.9.5 > > > Some newer revisions of OpenSSL such as those on latest Fedora releases cause > an error in compilation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQCPP-622) Memory leaks in the handshake of a OpenSSL connection
[
https://issues.apache.org/jira/browse/AMQCPP-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335008#comment-16335008
]
ASF subversion and git services commented on AMQCPP-622:
Commit 46db7293dc0dbebc7efdb39a20c1ea26da48bc53 in activemq-cpp's branch
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-cpp.git;h=46db729 ]
AMQCPP-623 AMQCPP-622 Fix OpenSSL issues
Fix possible memory leak and address issues with build on newer
releases.
(cherry picked from commit 0eb4320503f34d90f2668211486e97974f926918)
> Memory leaks in the handshake of a OpenSSL connection
> -
>
> Key: AMQCPP-622
> URL: https://issues.apache.org/jira/browse/AMQCPP-622
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: Decaf
>Affects Versions: 3.9.4
>Reporter: Daniel Laügt
>Assignee: Timothy Bish
>Priority: Minor
> Attachments: OpenSSLSocket.cpp.patch
>
>
> ActiveMQ transport has two memory leaks in the handshake of a OpenSSL
> connection.
> {noformat}
> ==15167== Memcheck, a memory error detector
> ==15167== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==15167== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==15167==
> ==15167==
> ==15167== HEAP SUMMARY:
> ==15167== in use at exit: 4,682,917 bytes in 8,351 blocks
> ==15167== total heap usage: 108,257 allocs, 99,907 frees, 64,602,948 bytes
> allocated
> ==15167==
> ==15167== 207 (32 direct, 175 indirect) bytes in 1 blocks are definitely lost
> in loss record 2,149 of 2,859
> ==15167==at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15167==by 0x6D8DA67: CRYPTO_malloc (mem.c:346)
> ==15167==by 0x6E3FEBE: sk_new (stack.c:162)
> ==15167==by 0x6E93024: X509V3_add_value (v3_utl.c:93)
> ==15167==by 0x6E94BD8: i2v_GENERAL_NAME (v3_alt.c:142)
> ==15167==by 0x6E94D2A: i2v_GENERAL_NAMES (v3_alt.c:106)
> ==15167==by 0x19B5FF6E:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::verifyServerCert(std::string
> const&) (OpenSSLSocket.cpp:671)
> ==15167==by 0x19B61481:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::startHandshake()
> (OpenSSLSocket.cpp:379)
> ==15167==by 0x19B5FA95:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::write(unsigned char
> const*, int, int, int) (OpenSSLSocket.cpp:566)
> ==15167==by 0x19B63520:
> decaf::internal::net::ssl::openssl::OpenSSLSocketOutputStream::doWriteArrayBounded(unsigned
> char const*, int, int, int) (OpenSSLSocketOutputStream.cpp:91)
> ==15167==by 0x19BB14D1: decaf::io::OutputStream::doWriteArray(unsigned
> char const*, int) (OutputStream.cpp:89)
> ==15167==by 0x19BB1255: decaf::io::OutputStream::write(unsigned char
> const*, int) (OutputStream.cpp:65)
> ==15167==
> ==15167== 228 (32 direct, 196 indirect) bytes in 1 blocks are definitely lost
> in loss record 2,153 of 2,859
> ==15167==at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15167==by 0x6D8DA67: CRYPTO_malloc (mem.c:346)
> ==15167==by 0x6E3FEBE: sk_new (stack.c:162)
> ==15167==by 0x6E6ED08: asn1_template_noexp_d2i (tasn_dec.c:634)
> ==15167==by 0x6E6EE34: asn1_template_ex_d2i (tasn_dec.c:584)
> ==15167==by 0x6E6E4A5: ASN1_item_ex_d2i (tasn_dec.c:206)
> ==15167==by 0x6E6E983: ASN1_item_d2i (tasn_dec.c:146)
> ==15167==by 0x19B5FF4C:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::verifyServerCert(std::string
> const&) (OpenSSLSocket.cpp:671)
> ==15167==by 0x19B61481:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::startHandshake()
> (OpenSSLSocket.cpp:379)
> ==15167==by 0x19B5FA95:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::write(unsigned char
> const*, int, int, int) (OpenSSLSocket.cpp:566)
> ==15167==by 0x19B63520:
> decaf::internal::net::ssl::openssl::OpenSSLSocketOutputStream::doWriteArrayBounded(unsigned
> char const*, int, int, int) (OpenSSLSocketOutputStream.cpp:91)
> ==15167==by 0x19BB14D1: decaf::io::OutputStream::doWriteArray(unsigned
> char const*, int) (OutputStream.cpp:89)
> ==15167==
> ==15167== LEAK SUMMARY:
> ==15167==definitely lost: 64 bytes in 2 blocks
> ==15167==indirectly lost: 371 bytes in 20 blocks
> ==15167== possibly lost: 176,608 bytes in 28 blocks
> ==15167==still reachable: 2,705,672 bytes in 6,620 blocks
> ==15167== suppressed: 1,800,202 bytes in 1,681 blocks
> ==15167== Reachable blocks (those to which a pointer was found) are not shown.
> ==15167== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQCPP-623) Can't build on some newer OpenSSL versions
[ https://issues.apache.org/jira/browse/AMQCPP-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335007#comment-16335007 ] ASF subversion and git services commented on AMQCPP-623: Commit 46db7293dc0dbebc7efdb39a20c1ea26da48bc53 in activemq-cpp's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq-cpp.git;h=46db729 ] AMQCPP-623 AMQCPP-622 Fix OpenSSL issues Fix possible memory leak and address issues with build on newer releases. (cherry picked from commit 0eb4320503f34d90f2668211486e97974f926918) > Can't build on some newer OpenSSL versions > -- > > Key: AMQCPP-623 > URL: https://issues.apache.org/jira/browse/AMQCPP-623 > Project: ActiveMQ C++ Client > Issue Type: Bug >Affects Versions: 3.9.4 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 3.9.5 > > > Some newer revisions of OpenSSL such as those on latest Fedora releases cause > an error in compilation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQCPP-622) Memory leaks in the handshake of a OpenSSL connection
[
https://issues.apache.org/jira/browse/AMQCPP-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335004#comment-16335004
]
ASF subversion and git services commented on AMQCPP-622:
Commit 0eb4320503f34d90f2668211486e97974f926918 in activemq-cpp's branch
refs/heads/3.9.x from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-cpp.git;h=0eb4320 ]
AMQCPP-623 AMQCPP-622 Fix OpenSSL issues
Fix possible memory leak and address issues with build on newer
releases.
> Memory leaks in the handshake of a OpenSSL connection
> -
>
> Key: AMQCPP-622
> URL: https://issues.apache.org/jira/browse/AMQCPP-622
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: Decaf
>Affects Versions: 3.9.4
>Reporter: Daniel Laügt
>Assignee: Timothy Bish
>Priority: Minor
> Attachments: OpenSSLSocket.cpp.patch
>
>
> ActiveMQ transport has two memory leaks in the handshake of a OpenSSL
> connection.
> {noformat}
> ==15167== Memcheck, a memory error detector
> ==15167== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==15167== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==15167==
> ==15167==
> ==15167== HEAP SUMMARY:
> ==15167== in use at exit: 4,682,917 bytes in 8,351 blocks
> ==15167== total heap usage: 108,257 allocs, 99,907 frees, 64,602,948 bytes
> allocated
> ==15167==
> ==15167== 207 (32 direct, 175 indirect) bytes in 1 blocks are definitely lost
> in loss record 2,149 of 2,859
> ==15167==at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15167==by 0x6D8DA67: CRYPTO_malloc (mem.c:346)
> ==15167==by 0x6E3FEBE: sk_new (stack.c:162)
> ==15167==by 0x6E93024: X509V3_add_value (v3_utl.c:93)
> ==15167==by 0x6E94BD8: i2v_GENERAL_NAME (v3_alt.c:142)
> ==15167==by 0x6E94D2A: i2v_GENERAL_NAMES (v3_alt.c:106)
> ==15167==by 0x19B5FF6E:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::verifyServerCert(std::string
> const&) (OpenSSLSocket.cpp:671)
> ==15167==by 0x19B61481:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::startHandshake()
> (OpenSSLSocket.cpp:379)
> ==15167==by 0x19B5FA95:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::write(unsigned char
> const*, int, int, int) (OpenSSLSocket.cpp:566)
> ==15167==by 0x19B63520:
> decaf::internal::net::ssl::openssl::OpenSSLSocketOutputStream::doWriteArrayBounded(unsigned
> char const*, int, int, int) (OpenSSLSocketOutputStream.cpp:91)
> ==15167==by 0x19BB14D1: decaf::io::OutputStream::doWriteArray(unsigned
> char const*, int) (OutputStream.cpp:89)
> ==15167==by 0x19BB1255: decaf::io::OutputStream::write(unsigned char
> const*, int) (OutputStream.cpp:65)
> ==15167==
> ==15167== 228 (32 direct, 196 indirect) bytes in 1 blocks are definitely lost
> in loss record 2,153 of 2,859
> ==15167==at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15167==by 0x6D8DA67: CRYPTO_malloc (mem.c:346)
> ==15167==by 0x6E3FEBE: sk_new (stack.c:162)
> ==15167==by 0x6E6ED08: asn1_template_noexp_d2i (tasn_dec.c:634)
> ==15167==by 0x6E6EE34: asn1_template_ex_d2i (tasn_dec.c:584)
> ==15167==by 0x6E6E4A5: ASN1_item_ex_d2i (tasn_dec.c:206)
> ==15167==by 0x6E6E983: ASN1_item_d2i (tasn_dec.c:146)
> ==15167==by 0x19B5FF4C:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::verifyServerCert(std::string
> const&) (OpenSSLSocket.cpp:671)
> ==15167==by 0x19B61481:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::startHandshake()
> (OpenSSLSocket.cpp:379)
> ==15167==by 0x19B5FA95:
> decaf::internal::net::ssl::openssl::OpenSSLSocket::write(unsigned char
> const*, int, int, int) (OpenSSLSocket.cpp:566)
> ==15167==by 0x19B63520:
> decaf::internal::net::ssl::openssl::OpenSSLSocketOutputStream::doWriteArrayBounded(unsigned
> char const*, int, int, int) (OpenSSLSocketOutputStream.cpp:91)
> ==15167==by 0x19BB14D1: decaf::io::OutputStream::doWriteArray(unsigned
> char const*, int) (OutputStream.cpp:89)
> ==15167==
> ==15167== LEAK SUMMARY:
> ==15167==definitely lost: 64 bytes in 2 blocks
> ==15167==indirectly lost: 371 bytes in 20 blocks
> ==15167== possibly lost: 176,608 bytes in 28 blocks
> ==15167==still reachable: 2,705,672 bytes in 6,620 blocks
> ==15167== suppressed: 1,800,202 bytes in 1,681 blocks
> ==15167== Reachable blocks (those to which a pointer was found) are not shown.
> ==15167== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMQCPP-623) Can't build on some newer OpenSSL versions
Timothy Bish created AMQCPP-623: --- Summary: Can't build on some newer OpenSSL versions Key: AMQCPP-623 URL: https://issues.apache.org/jira/browse/AMQCPP-623 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 3.9.4 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 3.9.5 Some newer revisions of OpenSSL such as those on latest Fedora releases cause an error in compilation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-469) Artemis needs PoolingConnectionFactory for standalone clients
[ https://issues.apache.org/jira/browse/ARTEMIS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334955#comment-16334955 ] Timothy Bish commented on ARTEMIS-469: -- There is a JMS 2.0 generic JMS Pool here: https://github.com/messaginghub/pooled-jms > Artemis needs PoolingConnectionFactory for standalone clients > - > > Key: ARTEMIS-469 > URL: https://issues.apache.org/jira/browse/ARTEMIS-469 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker > Environment: Solaris >Reporter: Abhijith Prabhakar >Priority: Major > > Artemis does not have PoolingConnectionFactory which can be used outside of > container in standalone applications. More on conversation here: > http://activemq.2283324.n4.nabble.com/Apache-Artemis-pooling-td4707663.html#a4707675 > Similar to ActiveMQ, Artemis needs a standalone PoolingConnectionFactory > which is built on JMS 2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-393) Server logs message with queue deploy even when topic is being deployed.
[ https://issues.apache.org/jira/browse/ARTEMIS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-393. Resolution: Fixed Fix Version/s: 1.3.0 > Server logs message with queue deploy even when topic is being deployed. > > > Key: ARTEMIS-393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-393 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-608) Document how to add user-provided classes to Broker class path
[
https://issues.apache.org/jira/browse/ARTEMIS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334915#comment-16334915
]
ASF GitHub Bot commented on ARTEMIS-608:
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1804
> Document how to add user-provided classes to Broker class path
> --
>
> Key: ARTEMIS-608
> URL: https://issues.apache.org/jira/browse/ARTEMIS-608
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
>
> Broker reads the {{lib}} directory in the broker home directory and a {{lib}}
> directory **in the broker instance directory** and jar files in these
> directories are put on the class path. To provide my own Interceptor or
> something, it should be built into a jar and (together with all depending
> jars) dropped into the instance's lib directory, so it can be found by the
> broker.
> This deserves to be written up in the documentation. I believe that the only
> place this is described (the part about the instance's lib at least) is
> http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.
> Appropriate place for this explanation might be be
> {{docs/user-manual/en/using-server.md}}
> There are few references to it, I managed to find
> {{docs/user-manual/en/intercepting-operations.md}} and
> {{docs/user-manual/en/persistence.md}} which say
> {quote}The interceptors classes (and their dependencies) must be added to the
> server classpath to be properly instantiated and called.{quote}
> {quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You
> can do this by dropping the relevant jars in the lib folder of the ActiveMQ
> Artemis distribution.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-833) maxHops defaults to 0 when creating artemis cluster configuration through cli
[
https://issues.apache.org/jira/browse/ARTEMIS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-833.
Resolution: Won't Fix
> maxHops defaults to 0 when creating artemis cluster configuration through cli
> --
>
> Key: ARTEMIS-833
> URL: https://issues.apache.org/jira/browse/ARTEMIS-833
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
>Reporter: Tom Ross
>Priority: Minor
> Labels: easyfix
>
> When running artemis CLI to create cluster configuration using simple CLI
> command like:
> {noformat}
> ./artemis create --clustered --name node-one --host localhost
> --message-load-balancing ON_DEMAND ../node-one
> {noformat}
> The generated broker.xml configuration file has the element set
> to 0. This is very confusing since it effectively disables message load
> balancing and stop cluster from forwarding messages to other nodes in hte
> cluster. This should be set to at least 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-608) Document how to add user-provided classes to Broker class path
[
https://issues.apache.org/jira/browse/ARTEMIS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334914#comment-16334914
]
ASF subversion and git services commented on ARTEMIS-608:
-
Commit 557224795b3e1f7634e018f1741788201a1ba833 in activemq-artemis's branch
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5572247 ]
ARTEMIS-608 document adding runtime deps
> Document how to add user-provided classes to Broker class path
> --
>
> Key: ARTEMIS-608
> URL: https://issues.apache.org/jira/browse/ARTEMIS-608
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
>
> Broker reads the {{lib}} directory in the broker home directory and a {{lib}}
> directory **in the broker instance directory** and jar files in these
> directories are put on the class path. To provide my own Interceptor or
> something, it should be built into a jar and (together with all depending
> jars) dropped into the instance's lib directory, so it can be found by the
> broker.
> This deserves to be written up in the documentation. I believe that the only
> place this is described (the part about the instance's lib at least) is
> http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.
> Appropriate place for this explanation might be be
> {{docs/user-manual/en/using-server.md}}
> There are few references to it, I managed to find
> {{docs/user-manual/en/intercepting-operations.md}} and
> {{docs/user-manual/en/persistence.md}} which say
> {quote}The interceptors classes (and their dependencies) must be added to the
> server classpath to be properly instantiated and called.{quote}
> {quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You
> can do this by dropping the relevant jars in the lib folder of the ActiveMQ
> Artemis distribution.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334906#comment-16334906 ] ASF GitHub Bot commented on ARTEMIS-1628: - GitHub user clebertsuconic reopened a pull request: https://github.com/apache/activemq-artemis/pull/1803 ARTEMIS-1628 Limit pool size on artemis journal You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis journal Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1803.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1803 commit 12746dfd4e6752fd3fef02b0f2c18b17bdffe8d5 Author: Clebert Suconic Date: 2018-01-22T17:33:14Z ARTEMIS-1628 Limit pool size on artemis journal > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-806) Publishing a MQTT message on one node of the cluster is not distributed to the subscriber on a different node when using topic pattern expression.
[ https://issues.apache.org/jira/browse/ARTEMIS-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-806. Resolution: Duplicate > Publishing a MQTT message on one node of the cluster is not distributed to > the subscriber on a different node when using topic pattern expression. > -- > > Key: ARTEMIS-806 > URL: https://issues.apache.org/jira/browse/ARTEMIS-806 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Antoine Toulme >Assignee: Martyn Taylor >Priority: Major > > We are trying out ActiveMQ Artemis with MQTT. We are interested in using > pattern subscription such as foo/# to listen to a set of topics. > We created a cluster in which one client publishes to a node, while an other > one subscribes to another. > When using pattern subscriptions, we see that the subscriber does not receive > the message. > When using an exact subscription (foo/bar), the subscriber receives the > message. > I have managed to reproduce the issue by adjusting the symmetric cluster > example. > Here is the code: > https://github.com/atoulme/activemq-artemis/tree/mqtt_cluster_test2 > With this code, I see that messages are sent, but none are received. > If you change the subscription to “mqtt/bar” line 71 and 103, messages are > passed OK. > More context here: > http://mail-archives.apache.org/mod_mbox/activemq-dev/201610.mbox/%3CC5A6C1AC-C985-4F30-AF4D-0E5F27E69D2B%40gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-469) Artemis needs PoolingConnectionFactory for standalone clients
[ https://issues.apache.org/jira/browse/ARTEMIS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334905#comment-16334905 ] Justin Bertram commented on ARTEMIS-469: [~tabish121], weren't you looking at creating a generic pool implementation? If so, it would likely fit the need here, no? > Artemis needs PoolingConnectionFactory for standalone clients > - > > Key: ARTEMIS-469 > URL: https://issues.apache.org/jira/browse/ARTEMIS-469 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker > Environment: Solaris >Reporter: Abhijith Prabhakar >Priority: Major > > Artemis does not have PoolingConnectionFactory which can be used outside of > container in standalone applications. More on conversation here: > http://activemq.2283324.n4.nabble.com/Apache-Artemis-pooling-td4707663.html#a4707675 > Similar to ActiveMQ, Artemis needs a standalone PoolingConnectionFactory > which is built on JMS 2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1126) Artemis 1.5.3 doc missing "JDBC Persistence" under "Persistence" section
[ https://issues.apache.org/jira/browse/ARTEMIS-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-1126. --- Resolution: Won't Fix > Artemis 1.5.3 doc missing "JDBC Persistence" under "Persistence" section > > > Key: ARTEMIS-1126 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1126 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.3 >Reporter: Varsha >Priority: Minor > Labels: documentation > > Artemis 1.5.3 doc missing "JDBC Persistence" under "Persistence" section > which is present in 1.5.2's as well as 1.5.4's doc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-557) Client connection are not balanced across cluster with RandomConnectionLoadBalancingPolicy
[
https://issues.apache.org/jira/browse/ARTEMIS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram closed ARTEMIS-557.
--
Resolution: Not A Bug
Questions like this should be directed to the [ActiveMQ User
list|http://activemq.apache.org/mailing-lists.html]. JIRA is typically
reserved for confirmed issues. Thanks!
> Client connection are not balanced across cluster with
> RandomConnectionLoadBalancingPolicy
> --
>
> Key: ARTEMIS-557
> URL: https://issues.apache.org/jira/browse/ARTEMIS-557
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Martin Styk
>Priority: Major
>
> *Scenario*
> There two nodes in cluster. Nodes in cluster are connected and both nodes
> have same jms destinations and connection factory defined like the following
> one
> {noformat}
> connectors="http-connector"
> entries="java:jboss/exported/jms/RemoteConnectionFactory" ha="true"
> connection-ttl="12" call-timeout="6" block-on-acknowledge="true"
> retry-interval="1000" reconnect-attempts="-1"
> connection-load-balancing-policy-class-name="org.apache.activemq.artemis.api.core.client.loadbalance.RandomConnectionLoadBalancingPolicy"/>
> {noformat}
> There are clients connecting to cluster. With
> _RandomConnectionLoadBalancingPolicy_, I would expect that connections are
> randomly distributed among the nodes in cluster. However, when I list
> connections on both nodes
> (/subsystem=messaging-activemq/server=default:list-connection-ids), all
> connections are on one server.
> Method {{private TransportConfiguration selectConnector()}} in class
> {{ServerLocatorImpl}} checks whether the {{topologyArray}} is null and makes
> decision between choosing connector to other node in topology or initial
> connector of connection factory. In method {{private TransportConfiguration
> selectConnector()}} {{topologyArray}} is still null, so clients make
> connection using initial connector. It seems like {{topologyArray}} is only
> updated during {{notifyNodeUp/Down}} methods.
> Could you please explain how is this client connection balancing supposed to
> work?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-609) Documentation for Interceptors is wrong regarding broker.xml file structure
[
https://issues.apache.org/jira/browse/ARTEMIS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334893#comment-16334893
]
ASF GitHub Bot commented on ARTEMIS-609:
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/1805
ARTEMIS-609 fix interceptor XML docs
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-609
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/1805.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1805
commit e3561fde13d0cb05fb5c58fe7cca7843defa11de
Author: Justin Bertram
Date: 2018-01-22T21:01:04Z
ARTEMIS-609 fix interceptor XML docs
> Documentation for Interceptors is wrong regarding broker.xml file structure
> ---
>
> Key: ARTEMIS-609
> URL: https://issues.apache.org/jira/browse/ARTEMIS-609
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
>
> Documentation suggests that the {{}} element
> is a direct children of the {{}} element. In fact, it must be
> children of the {{}} element, the way it is done in
> {{examples/features/standard/interceptor/src/main/resources/activemq/server0/broker.xml}}.
> This issue is present in the following files
> * {{docs/user-manual/en/intercepting-operations.md}}
> * {{examples/features/standard/interceptor/readme.html}}
> * {{examples/features/standard/interceptor-client/readme.html}}
> I worry that these obsolete configuration fragments are remnants of some past
> change in the {{broker.xml}} file structure and that there could be more to
> be found.
> One more thing. The last two files in my list have completely the same
> content. Is that really intentional?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ARTEMIS-608) Document how to add user-provided classes to Broker class path
[
https://issues.apache.org/jira/browse/ARTEMIS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-608:
--
Assignee: Justin Bertram
> Document how to add user-provided classes to Broker class path
> --
>
> Key: ARTEMIS-608
> URL: https://issues.apache.org/jira/browse/ARTEMIS-608
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
>
> Broker reads the {{lib}} directory in the broker home directory and a {{lib}}
> directory **in the broker instance directory** and jar files in these
> directories are put on the class path. To provide my own Interceptor or
> something, it should be built into a jar and (together with all depending
> jars) dropped into the instance's lib directory, so it can be found by the
> broker.
> This deserves to be written up in the documentation. I believe that the only
> place this is described (the part about the instance's lib at least) is
> http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.
> Appropriate place for this explanation might be be
> {{docs/user-manual/en/using-server.md}}
> There are few references to it, I managed to find
> {{docs/user-manual/en/intercepting-operations.md}} and
> {{docs/user-manual/en/persistence.md}} which say
> {quote}The interceptors classes (and their dependencies) must be added to the
> server classpath to be properly instantiated and called.{quote}
> {quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You
> can do this by dropping the relevant jars in the lib folder of the ActiveMQ
> Artemis distribution.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ARTEMIS-609) Documentation for Interceptors is wrong regarding broker.xml file structure
[
https://issues.apache.org/jira/browse/ARTEMIS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-609:
--
Assignee: Justin Bertram
> Documentation for Interceptors is wrong regarding broker.xml file structure
> ---
>
> Key: ARTEMIS-609
> URL: https://issues.apache.org/jira/browse/ARTEMIS-609
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Labels: documentation
>
> Documentation suggests that the {{}} element
> is a direct children of the {{}} element. In fact, it must be
> children of the {{}} element, the way it is done in
> {{examples/features/standard/interceptor/src/main/resources/activemq/server0/broker.xml}}.
> This issue is present in the following files
> * {{docs/user-manual/en/intercepting-operations.md}}
> * {{examples/features/standard/interceptor/readme.html}}
> * {{examples/features/standard/interceptor-client/readme.html}}
> I worry that these obsolete configuration fragments are remnants of some past
> change in the {{broker.xml}} file structure and that there could be more to
> be found.
> One more thing. The last two files in my list have completely the same
> content. Is that really intentional?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1607) OpenWire is sending responses too early with durable messages
[
https://issues.apache.org/jira/browse/ARTEMIS-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334882#comment-16334882
]
ASF GitHub Bot commented on ARTEMIS-1607:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1801#discussion_r163065589
--- Diff:
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQSession.java
---
@@ -393,26 +395,47 @@ public void send(final ProducerInfo producerInfo,
this.connection.getContext().setDontSendReponse(false);
connection.sendException(exceptionToSend);
} else {
- if (sendProducerAck) {
-try {
- ProducerAck ack = new
ProducerAck(producerInfo.getProducerId(), messageSend.getSize());
- connection.dispatchAsync(ack);
-} catch (Exception e) {
-
this.connection.getContext().setDontSendReponse(false);
-
ActiveMQServerLogger.LOGGER.warn(e.getMessage(), e);
- connection.sendException(e);
+
server.getStorageManager().afterCompleteOperations(new IOCallback() {
+@Override
+public void done() {
+ if (sendProducerAck) {
+ try {
+ ProducerAck ack = new
ProducerAck(producerInfo.getProducerId(), messageSend.getSize());
+ connection.dispatchAsync(ack);
+ } catch (Exception e) {
+
connection.getContext().setDontSendReponse(false);
+
ActiveMQServerLogger.LOGGER.warn(e.getMessage(), e);
+ connection.sendException(e);
+ }
+ } else {
+
connection.getContext().setDontSendReponse(false);
+ try {
+ Response response = new Response();
+
response.setCorrelationId(messageSend.getCommandId());
+ connection.dispatchAsync(response);
+ } catch (Exception e) {
+
ActiveMQServerLogger.LOGGER.warn(e.getMessage(), e);
+ connection.sendException(e);
+ }
+ }
}
- } else {
-connection.getContext().setDontSendReponse(false);
-try {
- Response response = new Response();
-
response.setCorrelationId(messageSend.getCommandId());
- connection.dispatchAsync(response);
-} catch (Exception e) {
-
ActiveMQServerLogger.LOGGER.warn(e.getMessage(), e);
- connection.sendException(e);
+
+@Override
+public void onError(int errorCode, String
errorMessage) {
+ //failing here is severe and IO related
+ final Throwable criticalError = new
IOException(errorMessage);
+ try {
+ //it is handled async and hopefully will be
sent before the critical error shutdown the broker:
+ //it helps to fail fast the clients on
critical errors
+ connection.serviceException(criticalError);
+ } catch (Exception e) {
+ ActiveMQServerLogger.LOGGER.debug(e);
+ } finally {
+ //it needs to be called ASAP: the broker
isn't in a safe state
+
server.getStorageManager().criticalError(criticalError);
--- End diff --
this is probably also called earlier by the IO layer.. but it doesn't hurt
here.
> OpenWire is sending responses too early with durable messages
> -
>
> Key: ARTEMIS-1607
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1607
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Francesco Nigro
>Assignee: Fran
[jira] [Commented] (ARTEMIS-1627) Unable to remove address from broker when linked with a wildcard address
[ https://issues.apache.org/jira/browse/ARTEMIS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334876#comment-16334876 ] Christopher L. Shannon commented on ARTEMIS-1627: - I think I have a PR for this that I will submit in the morning for review to see if others agree with it. > Unable to remove address from broker when linked with a wildcard address > > > Key: ARTEMIS-1627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1627 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Priority: Major > Attachments: JmsConsumerBindingTest.java > > > I was doing some testing with wildcard addresses and I noticed that the > broker does not allow an address to be removed when linked with a binding for > another address (such as with wildcard addresses). For example, if there are > two addresses created called durable.# and durable.test and a durable > subscription is created on durable.# then later on the durable.test address > is unable to be removed even though there is no direct consumer on that > address. > It seems like this should be allowed and I'm not sure if this would be > considered a bug or an improvement. I will attach a very simple unit test > that demonstrates the issue I am having. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-608) Document how to add user-provided classes to Broker class path
[
https://issues.apache.org/jira/browse/ARTEMIS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334875#comment-16334875
]
ASF GitHub Bot commented on ARTEMIS-608:
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/1804
ARTEMIS-608 document adding runtime deps
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-608
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/1804.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1804
commit b8239d4401e7a614067debd4b6c4d3d6b38abbe2
Author: Justin Bertram
Date: 2018-01-22T20:47:53Z
ARTEMIS-608 document adding runtime deps
> Document how to add user-provided classes to Broker class path
> --
>
> Key: ARTEMIS-608
> URL: https://issues.apache.org/jira/browse/ARTEMIS-608
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Daněk
>Priority: Major
> Labels: documentation
>
> Broker reads the {{lib}} directory in the broker home directory and a {{lib}}
> directory **in the broker instance directory** and jar files in these
> directories are put on the class path. To provide my own Interceptor or
> something, it should be built into a jar and (together with all depending
> jars) dropped into the instance's lib directory, so it can be found by the
> broker.
> This deserves to be written up in the documentation. I believe that the only
> place this is described (the part about the instance's lib at least) is
> http://activemq.2283324.n4.nabble.com/Adding-custom-decoder-into-Artemis-classpath-td4707493.html.
> Appropriate place for this explanation might be be
> {{docs/user-manual/en/using-server.md}}
> There are few references to it, I managed to find
> {{docs/user-manual/en/intercepting-operations.md}} and
> {{docs/user-manual/en/persistence.md}} which say
> {quote}The interceptors classes (and their dependencies) must be added to the
> server classpath to be properly instantiated and called.{quote}
> {quote}Add the appropriate JDBC driver libraries to the Artemis runtime. You
> can do this by dropping the relevant jars in the lib folder of the ActiveMQ
> Artemis distribution.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-546) Allow to disable client-side load-balancing
[
https://issues.apache.org/jira/browse/ARTEMIS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-546.
Resolution: Duplicate
> Allow to disable client-side load-balancing
> ---
>
> Key: ARTEMIS-546
> URL: https://issues.apache.org/jira/browse/ARTEMIS-546
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Affects Versions: 1.3.0
>Reporter: Miroslav Novak
>Priority: Major
>
> In case when user wants to define client side load-balancing on its own and
> for each client specify connector to node in cluster to which it must connect
> then there is no way do it by current load-balancing policies.
> Interface {{ConnectionLoadBalancingPolicy}} does not allow to say to which
> node to connect based on connector information which was used in
> configuration connection factory.
> Idea is to allow to disable load-balancing policy. When load-balancing policy
> is disabled then it will iterate through initial connectors (in sequence as
> they were configured) to create connection to remote broker.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16334781#comment-16334781 ] Justin Bertram commented on ARTEMIS-375: This patch it out of date. Please submit a PR via the [Artemis GitHub repo|https://github.com/apache/activemq-artemis]. > 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 >Priority: Major > Fix For: unscheduled > > 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 (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1392) NPE thrown if FQQN used on multicast address when queue does not exist
[ https://issues.apache.org/jira/browse/ARTEMIS-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-1392. --- Resolution: Fixed Fix Version/s: 2.4.0 > NPE thrown if FQQN used on multicast address when queue does not exist > -- > > Key: ARTEMIS-1392 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1392 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Martyn Taylor >Priority: Major > Fix For: 2.4.0 > > > Consuming from a FQQN with multicast routing type in AMQP will cause the > broker to throw an NPE should the queue not exist. Instead this should be > checked and an appropriate (Amqp:NotFound) error returned to the client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1611) Artemis transformer interface is not backwards compatible
[ https://issues.apache.org/jira/browse/ARTEMIS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334754#comment-16334754 ] ASF GitHub Bot commented on ARTEMIS-1611: - Github user mtaylor commented on a diff in the pull request: https://github.com/apache/activemq-artemis/pull/1783#discussion_r163036074 --- Diff: artemis-server/src/main/java/org/apache/activemq/artemis/core/server/transformer/ServerMessageImpl.java --- @@ -0,0 +1,190 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.activemq.artemis.core.server.transformer; + +import org.apache.activemq.artemis.api.core.ICoreMessage; +import org.apache.activemq.artemis.api.core.Message; +import org.apache.activemq.artemis.api.core.SimpleString; +import org.apache.activemq.artemis.core.message.impl.CoreMessage; +import org.apache.activemq.artemis.core.message.impl.MessageInternalImpl; +import org.apache.activemq.artemis.core.paging.PagingStore; +import org.apache.activemq.artemis.core.server.MessageReference; +import org.apache.activemq.artemis.core.server.Queue; +import org.apache.activemq.artemis.core.server.ServerMessage; + +@Deprecated --- End diff -- Can do. > Artemis transformer interface is not backwards compatible > - > > Key: ARTEMIS-1611 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1611 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 > Environment: > >Reporter: Jeff Mesnil >Priority: Major > > We have users of Artemis 1.x that uses the transformer interface defined in > org.apache.activemq.artemis.core.server.cluster.Transformer. > > This class was moved in Artemis 2.x in an incompatible way: > [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/Transformer.java] > that redirects to > [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/transformer/Transformer.java] > We are updating Artemis 2.x but it breaks the client configuration that was > using the old interface. > We have strong requirement for backwards compatibility and we'd like to come > up with a solution so that the new interface could be made backwards > compatible with the existing one. > Would it be possible sense to reintroduce the old interface in the > server.cluster package so that old code would still be able to run with > Artemis 2.x? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1611) Artemis transformer interface is not backwards compatible
[
https://issues.apache.org/jira/browse/ARTEMIS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334752#comment-16334752
]
ASF GitHub Bot commented on ARTEMIS-1611:
-
Github user mtaylor commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1783#discussion_r163035962
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/TypedProperties.java
---
@@ -23,4 +23,7 @@
@Deprecated
public class TypedProperties extends
org.apache.activemq.artemis.utils.collections.TypedProperties {
+ public TypedProperties(final
org.apache.activemq.artemis.utils.collections.TypedProperties other) {
--- End diff --
Good shout @michaelandrepearce. I missed that. Will update accordingly.
> Artemis transformer interface is not backwards compatible
> -
>
> Key: ARTEMIS-1611
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1611
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.4.0
> Environment:
>
>Reporter: Jeff Mesnil
>Priority: Major
>
> We have users of Artemis 1.x that uses the transformer interface defined in
> org.apache.activemq.artemis.core.server.cluster.Transformer.
>
> This class was moved in Artemis 2.x in an incompatible way:
> [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/Transformer.java]
> that redirects to
> [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/transformer/Transformer.java]
> We are updating Artemis 2.x but it breaks the client configuration that was
> using the old interface.
> We have strong requirement for backwards compatibility and we'd like to come
> up with a solution so that the new interface could be made backwards
> compatible with the existing one.
> Would it be possible sense to reintroduce the old interface in the
> server.cluster package so that old code would still be able to run with
> Artemis 2.x?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1402) Broker should return a not found if the address does not match queue in FQQN
[ https://issues.apache.org/jira/browse/ARTEMIS-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-1402. --- Resolution: Fixed Fix Version/s: 2.4.0 > Broker should return a not found if the address does not match queue in FQQN > > > Key: ARTEMIS-1402 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1402 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Martyn Taylor >Priority: Major > Fix For: 2.4.0 > > > If a client specifies a FQQN with address::queue the broker returns an > internal-error message back to the client. This case should be handled and a > not found error returned. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1493) DatabaseStorageConfiguration API is not consistent
[ https://issues.apache.org/jira/browse/ARTEMIS-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1493. - Resolution: Won't Fix > DatabaseStorageConfiguration API is not consistent > -- > > Key: ARTEMIS-1493 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1493 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Jeff Mesnil >Priority: Trivial > > The setJdbcNetworkTimeout(int jdbcNetworkTimeout) method is not correct. It > expects a value in milliseconds but accepts only an int instead of a long. > The name is also not consistent with the new methods > setJdbcLockRenewPeriodMillis(), setJdbcLockExpirationMillis(), > setJdbcLockAcquisitionTimeoutMillis() that appends Millis to specify the time > unit and accepts long parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1493) DatabaseStorageConfiguration API is not consistent
[
https://issues.apache.org/jira/browse/ARTEMIS-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334744#comment-16334744
]
Justin Bertram commented on ARTEMIS-1493:
-
The [underlying JDBC
java.sql.Connection#setNetworkTimeout|https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setNetworkTimeout(java.util.concurrent.Executor,%20int)]
method which eventually uses this value takes an {{int}}.
> DatabaseStorageConfiguration API is not consistent
> --
>
> Key: ARTEMIS-1493
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1493
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.4.0
>Reporter: Jeff Mesnil
>Priority: Trivial
>
> The setJdbcNetworkTimeout(int jdbcNetworkTimeout) method is not correct. It
> expects a value in milliseconds but accepts only an int instead of a long.
> The name is also not consistent with the new methods
> setJdbcLockRenewPeriodMillis(), setJdbcLockExpirationMillis(),
> setJdbcLockAcquisitionTimeoutMillis() that appends Millis to specify the time
> unit and accepts long parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1486) Core client should be notified if consumer is closed on broker side
[ https://issues.apache.org/jira/browse/ARTEMIS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1486. - Resolution: Fixed Fix Version/s: 2.5.0 > Core client should be notified if consumer is closed on broker side > --- > > Key: ARTEMIS-1486 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1486 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Stanislav Knot >Priority: Major > Fix For: 2.5.0 > > > If consumer is closed on broker using e.g. Hawtio console, client connected > as that consumer (representation of broker resource) should be notified about > that fact and react to that. It doesn't seem to react. If consumer is closed, > as a result of not being notified, client hangs in the air and cannot receive > messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1607) OpenWire is sending responses too early with durable messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334709#comment-16334709 ] ASF GitHub Bot commented on ARTEMIS-1607: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1801 The errors on the completion are critical. They are IOerrors. I think the critical exception will be called anyways. > OpenWire is sending responses too early with durable messages > - > > Key: ARTEMIS-1607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1607 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (ARTEMIS-1560) Destroy message instead of sending it to DLQ
[ https://issues.apache.org/jira/browse/ARTEMIS-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-1560: Comment: was deleted (was: [~raggz], which is the other JIRA?) > Destroy message instead of sending it to DLQ > > > Key: ARTEMIS-1560 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1560 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.3.0 > Environment: Artemis broker >Reporter: Tom Ross >Priority: Major > > There is a requirement to add an enhancement to the way messages are sent to > DLQ. > It should be possible to set a property on a message that when rejected by > client the broker would rollback an existing transaction, ACK the message and > destroy it instead of sending it to DLQ. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (ARTEMIS-1560) Destroy message instead of sending it to DLQ
[ https://issues.apache.org/jira/browse/ARTEMIS-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reopened ARTEMIS-1560: - > Destroy message instead of sending it to DLQ > > > Key: ARTEMIS-1560 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1560 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.3.0 > Environment: Artemis broker >Reporter: Tom Ross >Priority: Major > > There is a requirement to add an enhancement to the way messages are sent to > DLQ. > It should be possible to set a property on a message that when rejected by > client the broker would rollback an existing transaction, ACK the message and > destroy it instead of sending it to DLQ. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1560) Destroy message instead of sending it to DLQ
[ https://issues.apache.org/jira/browse/ARTEMIS-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-1560. --- Resolution: Duplicate > Destroy message instead of sending it to DLQ > > > Key: ARTEMIS-1560 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1560 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.3.0 > Environment: Artemis broker >Reporter: Tom Ross >Priority: Major > > There is a requirement to add an enhancement to the way messages are sent to > DLQ. > It should be possible to set a property on a message that when rejected by > client the broker would rollback an existing transaction, ACK the message and > destroy it instead of sending it to DLQ. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1560) Destroy message instead of sending it to DLQ
[ https://issues.apache.org/jira/browse/ARTEMIS-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-1560. --- Resolution: Duplicate > Destroy message instead of sending it to DLQ > > > Key: ARTEMIS-1560 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1560 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.3.0 > Environment: Artemis broker >Reporter: Tom Ross >Priority: Major > > There is a requirement to add an enhancement to the way messages are sent to > DLQ. > It should be possible to set a property on a message that when rejected by > client the broker would rollback an existing transaction, ACK the message and > destroy it instead of sending it to DLQ. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1511) Add WebSocket coverage to STOMP tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1511. - Resolution: Fixed Fix Version/s: 2.5.0 > Add WebSocket coverage to STOMP tests > - > > Key: ARTEMIS-1511 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1511 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Martyn Taylor >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1512) Race Condition with STOMP Subscribe Receipt
[ https://issues.apache.org/jira/browse/ARTEMIS-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1512. - Resolution: Fixed Fix Version/s: 2.5.0 > Race Condition with STOMP Subscribe Receipt > --- > > Key: ARTEMIS-1512 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1512 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Martyn Taylor >Priority: Major > Fix For: 2.5.0 > > > If a STOMP client sends a subscribe packet with receipt true, it can occur > that messages based on that subscription can arrive before the receipt. This > can cause issues with STOMP clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Deleted] (ARTEMIS-1515) Negative Message Count and Delivering Count
[ https://issues.apache.org/jira/browse/ARTEMIS-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram deleted ARTEMIS-1515: > Negative Message Count and Delivering Count > --- > > Key: ARTEMIS-1515 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1515 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Mary Cochran >Priority: Major > > This is for amq-broker-7.0.3 for RH release, not for sure what version that > is for Artemis. > May be related to : https://issues.jboss.org/browse/HORNETQ-1296 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1627) Unable to remove address from broker when linked with a wildcard address
[ https://issues.apache.org/jira/browse/ARTEMIS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334690#comment-16334690 ] Christopher L. Shannon commented on ARTEMIS-1627: - Perhaps we should be using the getMatchingBindings() method call instead of getBindingsForAddress() method call when checking for bindings here: https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java#L535 > Unable to remove address from broker when linked with a wildcard address > > > Key: ARTEMIS-1627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1627 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Priority: Major > Attachments: JmsConsumerBindingTest.java > > > I was doing some testing with wildcard addresses and I noticed that the > broker does not allow an address to be removed when linked with a binding for > another address (such as with wildcard addresses). For example, if there are > two addresses created called durable.# and durable.test and a durable > subscription is created on durable.# then later on the durable.test address > is unable to be removed even though there is no direct consumer on that > address. > It seems like this should be allowed and I'm not sure if this would be > considered a bug or an improvement. I will attach a very simple unit test > that demonstrates the issue I am having. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1520) Add connectionID to trace logging that deals with packet reading/writing
[ https://issues.apache.org/jira/browse/ARTEMIS-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1520. - Resolution: Fixed Fix Version/s: 2.5.0 > Add connectionID to trace logging that deals with packet reading/writing > - > > Key: ARTEMIS-1520 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1520 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Pat Fox >Priority: Minor > Fix For: 2.5.0 > > > There is some very good logging for tracking packet read/write operations in > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl > and org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl .However > it is difficult to distinguish which TCP connection a packet arrived on or > was written to. > It would be good to add a connection ID to that logging so it is easier to > track the packet flow on an individual connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1560) Destroy message instead of sending it to DLQ
[ https://issues.apache.org/jira/browse/ARTEMIS-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334684#comment-16334684 ] Justin Bertram commented on ARTEMIS-1560: - [~raggz], which is the other JIRA? > Destroy message instead of sending it to DLQ > > > Key: ARTEMIS-1560 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1560 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.3.0 > Environment: Artemis broker >Reporter: Tom Ross >Priority: Major > > There is a requirement to add an enhancement to the way messages are sent to > DLQ. > It should be possible to set a property on a message that when rejected by > client the broker would rollback an existing transaction, ACK the message and > destroy it instead of sending it to DLQ. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1508) AMQPMesage.reencode is broken
[ https://issues.apache.org/jira/browse/ARTEMIS-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1508. - Resolution: Fixed Fix Version/s: 2.5.0 > AMQPMesage.reencode is broken > - > > Key: ARTEMIS-1508 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1508 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Stanislav Knot >Priority: Major > Fix For: 2.5.0 > > > When a is used to route messages from a topic to a queue, and when a > consumer attaches to the target queue using a selector expression, then no > messages are consumed, even though the message headers match the selector. > In some (but not all) circumstances, an error message is seen in the broker > log: > ~~~ > 08:57:44,807 ERROR [org.apache.activemq.artemis.core.server] AMQ224006: > Invalid filter: filename='XXX' > ~~~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1612) Redistribution of messages does not work if prefixing is used
[ https://issues.apache.org/jira/browse/ARTEMIS-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1612. - Resolution: Fixed Fix Version/s: 2.5.0 > Redistribution of messages does not work if prefixing is used > -- > > Key: ARTEMIS-1612 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1612 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Martyn Taylor >Priority: Major > Fix For: 2.5.0 > > > The problem lies in the redistribution logic, it uses the message address to > locate the bindings. However, once the message has been routed, the original > "prefixless routing address" is not available. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1607) OpenWire is sending responses too early with durable messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334624#comment-16334624 ] ASF GitHub Bot commented on ARTEMIS-1607: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1801 @gtully Good point! I've added an async send of error that finally will end with the critical error as before: I hope (@clebertsuconic could help confirm that) that it is safe enough. There could be the chance that the exception won't be never send back to the clients because the critical error handling will shutdown the server before the send will happen! > OpenWire is sending responses too early with durable messages > - > > Key: ARTEMIS-1607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1607 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334617#comment-16334617 ] ASF GitHub Bot commented on ARTEMIS-1628: - Github user clebertsuconic closed the pull request at: https://github.com/apache/activemq-artemis/pull/1803 > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334615#comment-16334615 ] ASF GitHub Bot commented on ARTEMIS-1628: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1803 Please do not merge this.. i will add a log.warn if -1 > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1341) Core JMS does not permit calling Message#getBytes(arbitrary type) when message has empty body
[
https://issues.apache.org/jira/browse/ARTEMIS-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1341.
-
Resolution: Fixed
Fix Version/s: 2.5.0
> Core JMS does not permit calling Message#getBytes(arbitrary type) when
> message has empty body
> -
>
> Key: ARTEMIS-1341
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1341
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Priority: Trivial
> Fix For: 2.5.0
>
>
> Consider the ActiveMQ Artemis test
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
> adapted to run through multiple JMS ConnectionFactories in turn. This test
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
> BytesMessage bytesMessage = sess.createBytesMessage();
> producer.send(bytesMessage);
> Message msg = cons.receiveNoWait();
> assertNotNull(msg);
> try {
> msg.getBody(String.class);
> fail("Exception expected");
> } catch (MessageFormatException e) {
> }
> {noformat}
> The test is wrong, see discussion with [~tabish121] at QPIDJMS-313 for
> details and references as to why.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1626) Disable thread leak check for failing tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334610#comment-16334610 ] ASF GitHub Bot commented on ARTEMIS-1626: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1800 @gaohoward I undestand your points you've showed on my questions, but as @clebertsuconic has pointed > the ideal world is far from reality.. there are tests that will be failing forever on the testsuite and people will ignore them I agree with that and I think we should try to keep more isolated than possible (if possible) tests (failing or not) just for this reason: just logging the leaks would be enough for me. While dealing with very long running tests who will read the test reports need to rely that 2 different runs are comparable somehow and hiding this information won't help doing it. I understand the need to make the process more agile and to aim "0 tests failures" and I think that just logging would be great. I hope to have explained better what I'm worried about > Disable thread leak check for failing tests > --- > > Key: ARTEMIS-1626 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1626 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.5.0 > > > The ThreadLeakCheckRule is used to check thread leaks > after each test is finished. However when a test fails, it is > not necessary to check leaking threads because the test > failure should be fixed anyway. And leaking threads in a > failed test may well be a result of the failure (once the test > is fixed the thread leak may be gone). > If a failed test also leaks threads, it takes a long time before > the thread leak check finishes (60 seconds checking time), > thus it takes a long time to finish, especially when tests are > run in batches with failures. > So to improve this, it should be reasonable to just enable > the thread leaking check for each test passes, and disable > the check when a test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1516) Ensure JNDI using Tomcat Resources works as like ActiveMQ 5
[ https://issues.apache.org/jira/browse/ARTEMIS-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1516. - Resolution: Fixed Fix Version/s: 2.5.0 > Ensure JNDI using Tomcat Resources works as like ActiveMQ 5 > --- > > Key: ARTEMIS-1516 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1516 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > Fix For: 2.5.0 > > > Ensure JNDI using Tomcat Resources works as like ActiveMQ 5. JNDI > serialisation needs to use StringRefAddr to support this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1406) FindBugs: impossible instanceof in exception handler in MappedSequentialFile.java
[
https://issues.apache.org/jira/browse/ARTEMIS-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1406.
-
Resolution: Fixed
Fix Version/s: 2.5.0
> FindBugs: impossible instanceof in exception handler in
> MappedSequentialFile.java
> -
>
> Key: ARTEMIS-1406
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1406
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.4.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> {noformat}
> 360 @Override
> 361 public void renameTo(String newFileName) throws Exception {
> 362 try {
> 363 close();
> 364 } catch (Exception e) {
>
> CID 1418586 (#1 of 1): BC: Bad casts of object references
> (FB.BC_IMPOSSIBLE_INSTANCEOF)
> 1. defect: instanceof will always return false, since a RuntimeException
> can't be a java.io.IOException.
> 365 if (e instanceof IOException) {
> 366factory.onIOError(new ActiveMQIOErrorException(e.getMessage(),
> e), e.getMessage(), this);
> 367 }
> 368 throw e;
> 369 }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1616) OpenWire improvements
[
https://issues.apache.org/jira/browse/ARTEMIS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334608#comment-16334608
]
ASF GitHub Bot commented on ARTEMIS-1616:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1786#discussion_r163012542
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/SimpleString.java
---
@@ -361,13 +371,68 @@ public int hashCode() {
}
}
+ private static SimpleString[] splitWithCachedString(final SimpleString
simpleString, final int delim) {
+ final String str = simpleString.str;
+ final byte[] data = simpleString.data;
+ final int length = str.length();
+ List all = null;
+ int index = 0;
+ while (index < length) {
+ final int delimIndex = str.indexOf(delim, index);
+ if (delimIndex == -1) {
+//just need to add the last one
+break;
+ } else {
+all = addSimpleStringPart(all, data, index, delimIndex);
+ }
+ index = delimIndex + 1;
+ }
+ if (all == null) {
+ return new SimpleString[]{simpleString};
+ } else {
+ // Adding the last one
+ all = addSimpleStringPart(all, data, index, length);
+ // Converting it to arrays
+ final SimpleString[] parts = new SimpleString[all.size()];
+ return all.toArray(parts);
+ }
+ }
+
+ private static List
addSimpleStringPart(List all,
+ final byte[] data,
+ final int
startIndex,
+ final int
endIndex) {
+ final int expectedLength = endIndex - startIndex;
+ final SimpleString ss;
+ if (expectedLength == 0) {
+ ss = EMPTY;
+ } else {
+ //extract a byte[] copy from this
+ final int ssIndex = startIndex << 1;
+ final int delIndex = endIndex << 1;
+ final byte[] bytes = Arrays.copyOfRange(data, ssIndex, delIndex);
+ ss = new SimpleString(bytes);
+ }
+ // We will create the ArrayList lazily
+ if (all == null) {
+ // There will be at least 3 strings on this case (which is the
actual common usecase)
--- End diff --
@franz1981 just thinking on this is it worth making the other array list
also 3? Just so both is consistent, maybe make it a constant, so if in future
it changes again, single change would affect both.
> OpenWire improvements
> -
>
> Key: ARTEMIS-1616
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1616
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ARTEMIS-1406) FindBugs: impossible instanceof in exception handler in MappedSequentialFile.java
[
https://issues.apache.org/jira/browse/ARTEMIS-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-1406:
---
Assignee: Justin Bertram
> FindBugs: impossible instanceof in exception handler in
> MappedSequentialFile.java
> -
>
> Key: ARTEMIS-1406
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1406
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.4.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Major
>
> {noformat}
> 360 @Override
> 361 public void renameTo(String newFileName) throws Exception {
> 362 try {
> 363 close();
> 364 } catch (Exception e) {
>
> CID 1418586 (#1 of 1): BC: Bad casts of object references
> (FB.BC_IMPOSSIBLE_INSTANCEOF)
> 1. defect: instanceof will always return false, since a RuntimeException
> can't be a java.io.IOException.
> 365 if (e instanceof IOException) {
> 366factory.onIOError(new ActiveMQIOErrorException(e.getMessage(),
> e), e.getMessage(), this);
> 367 }
> 368 throw e;
> 369 }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1591) Exporter won't preserve message ordering
[ https://issues.apache.org/jira/browse/ARTEMIS-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1591. - Resolution: Fixed > Exporter won't preserve message ordering > > > Key: ARTEMIS-1591 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1591 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1585) Log connector details on start
[ https://issues.apache.org/jira/browse/ARTEMIS-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1585. - Resolution: Fixed Fix Version/s: 2.5.0 > Log connector details on start > -- > > Key: ARTEMIS-1585 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1585 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Michael Andre Pearce >Priority: Major > Fix For: 2.5.0 > > > As like acceptors do, ensure details of connectors are logged out when they > start. This helps diagnose any issue with the clients later. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1628) Limit pool size of files on the journal by default
[ https://issues.apache.org/jira/browse/ARTEMIS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334600#comment-16334600 ] ASF GitHub Bot commented on ARTEMIS-1628: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/1803 ARTEMIS-1628 Limit pool size on artemis journal You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis journal Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1803.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1803 commit 12746dfd4e6752fd3fef02b0f2c18b17bdffe8d5 Author: Clebert Suconic Date: 2018-01-22T17:33:14Z ARTEMIS-1628 Limit pool size on artemis journal > Limit pool size of files on the journal by default > -- > > Key: ARTEMIS-1628 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1628 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1595) Serialization issues between 1.x and 2.x JNDI objects
[ https://issues.apache.org/jira/browse/ARTEMIS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1595. - Resolution: Fixed > Serialization issues between 1.x and 2.x JNDI objects > - > > Key: ARTEMIS-1595 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1595 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1611) Artemis transformer interface is not backwards compatible
[
https://issues.apache.org/jira/browse/ARTEMIS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334597#comment-16334597
]
ASF GitHub Bot commented on ARTEMIS-1611:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1783#discussion_r163011302
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/TypedProperties.java
---
@@ -23,4 +23,7 @@
@Deprecated
public class TypedProperties extends
org.apache.activemq.artemis.utils.collections.TypedProperties {
+ public TypedProperties(final
org.apache.activemq.artemis.utils.collections.TypedProperties other) {
--- End diff --
Should add the default empty constructor. By adding this without explicit
defining the empty it is being removed.
> Artemis transformer interface is not backwards compatible
> -
>
> Key: ARTEMIS-1611
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1611
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.4.0
> Environment:
>
>Reporter: Jeff Mesnil
>Priority: Major
>
> We have users of Artemis 1.x that uses the transformer interface defined in
> org.apache.activemq.artemis.core.server.cluster.Transformer.
>
> This class was moved in Artemis 2.x in an incompatible way:
> [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/Transformer.java]
> that redirects to
> [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/transformer/Transformer.java]
> We are updating Artemis 2.x but it breaks the client configuration that was
> using the old interface.
> We have strong requirement for backwards compatibility and we'd like to come
> up with a solution so that the new interface could be made backwards
> compatible with the existing one.
> Would it be possible sense to reintroduce the old interface in the
> server.cluster package so that old code would still be able to run with
> Artemis 2.x?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1599) Data exported with 1.x won't be loaded with 2.x
[ https://issues.apache.org/jira/browse/ARTEMIS-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1599. - Resolution: Fixed > Data exported with 1.x won't be loaded with 2.x > --- > > Key: ARTEMIS-1599 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1599 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1590) Use properties to configure JDBC store SQLProvider
[ https://issues.apache.org/jira/browse/ARTEMIS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1590. - Resolution: Fixed Fix Version/s: 2.5.0 > Use properties to configure JDBC store SQLProvider > -- > > Key: ARTEMIS-1590 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1590 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Jeff Mesnil >Priority: Major > Fix For: 2.5.0 > > > This follow up the conversation started on activemq-dev mailing list[1] to > use a properties-based implementation for Artemis SQLProvider to ease > maintenance and support of different databases and their dialects. > [1] > http://mail-archives.apache.org/mod_mbox/activemq-dev/201711.mbox/%3ccaaeh2wf_ajyvzfaglczfwpdmcwlpydsrnio_4+k+mthdzph...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v7.6.3#76005)
