Re: [VOTE] Apache ActiveMQ Artemis 2.35.0

[Gary Tully]

+1

On Wed, Jun 12, 2024, 17:37 Clebert Suconic 
wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.35.0 release.
>
> I would like to highlight the following changes:
>
> - https://issues.apache.org/jira/browse/ARTEMIS-4813 In a rare race,
> Large messages that were partially sent before the broker started to
> replicate could become damage and part of the body be missed.
>
> - The codebase now uses JUNIT5 for testing.
>
>
> There are as usual other bug fixes, and can see them in the full release
> notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12354784
>
>
> The git report can be found here:
>
> https://activemq.apache.org/components/artemis/download/commit-report-2.35.0
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.35.0
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1397
>
> If you would like to validate the release:
>
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases
>
>
> It is tagged in the git repo as 2.35.0:
>
> I would appreciate your VOTE and tryouts on this candidate release:
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: [VOTE] ActiveMQ Artemis 2.34.0 release

[Gary Tully]

+1

On Wed, May 29, 2024, 18:43 Clebert Suconic 
wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.34.0 release.
>
>
> I would like to highlight the following improvements as part of this
> release:
>
> * https://issues.apache.org/jira/browse/ARTEMIS-4758 - Extensive
> resiliency tests and hardening on Mirroring.
> * https://issues.apache.org/jira/browse/ARTEMIS-4773 - Paging
> performance improvements on sync.
> * https://issues.apache.org/jira/browse/ARTEMIS-4306 - Statics about
> security events
> * https://issues.apache.org/jira/browse/ARTEMIS-4675 - Replication
> status metrics
>
>
> For a full release notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12354426
>
> The commit report:
>
> https://activemq.apache.org/components/artemis/download/commit-report-2.34.0
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.34.0/
>
>
> The Maven staged repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1396
>
> If you would like to validate the release:
>
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases
>
>
> It is tagged in the git repo as 2.34.0
>
> If you could please vote as usually:
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: [VOTE] Release Apache ActiveMQ Artemis 2.31.2

[Gary Tully]

+1

On Fri, 27 Oct 2023 at 12:17, Robbie Gemmell 
wrote:

> Hi folks,
>
> I would like to propose an Apache ActiveMQ Artemis 2.31.2 release.
>
> This addresses a defect introduced in the recent 2.31.1 release.
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353776
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.2/
>
> The Maven staging repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1379
>
> If you would like to validate the release:
>
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases
>
> It is tagged in the git repo as 2.31.2.
>
> Robbie
>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Gary Tully]

makes sense, but please keep a clear distinction - activemq classic 6.0.0
activemq X may still evolve to combine the best of both.

On Mon, 11 Sept 2023 at 22:15, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> First, I realize that this thread is likely to cause a fight based on past
> history and probably not go anywhere, but with the work being done
> with Jakarta for AMQ 5.x I think it's time to at least bring up the
> ActiveMQ 6.0 discussion.
>
> With all the breaking changes currently targeted for version 5.19.x, such
> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
> upgrades and now potentially major OSGi changes, it makes zero sense to me
> to have this next AMQ version as version 5.19.0 as it's completely
> incompatible with the previous version 5.18.x. Users are likely going to be
> in for a rude awakening when trying to upgrade and will be quite confused
> as to why so much is different.
>
> The Jakarta changes should really be a major version upgrade so that it's
> much more clear to users that it's very different from the previous
> version. Another major benefit of going with version 6.0 is that it frees
> up the previous javax releases to continue on with 5.19 or 5.20 because we
> will likely need to support the older javax releases for quite a while.
>
> Also, from my point of view it seems pretty clear that the original goal
> for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
> its own branding and versioning for several years now and will likely
> continue that way and not change so I don't really see that as a reason to
> not bump AMQ 5.x to 6.x with all the major breaking changes.
>
> Anyways, I figure there won't be much agreement here but thought I should
> at least throw it out there before we go and release 5.19.x with such major
> breaking changes.
>

Re: [VOTE] Apache ActiveMQ Artemis 2.30.0

[Gary Tully]

+1

On Fri, Jul 21, 2023, 14:54 Justin Bertram  wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.30.0 release.
>
> This is mainly a bug-fix release with a few small improvements and a
> handful of dependency upgrades.
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353357
>
> Ths git commit report is here:
>
> https://activemq.apache.org/components/artemis/download/commit-report-2.30.0.html
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.30.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1367
>
> In case you want to give it a try with the maven repo on examples:
>
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
> The source tag:
> https://github.com/apache/activemq-artemis/tree/2.30.0
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1
>
>
> Justin
>

Re: [VOTE] Apache ActiveMQ Artemis 2.29.0

[Gary Tully]

+1

On Thu, Jun 15, 2023, 00:40 Clebert Suconic 
wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.29.0 release.
>
> This is a representative workload with 126 JIRAs and 200+ commits with
> a diverse number of committers. Thanks to all who contributed to this
> big release.
>
>
> The release notes can be found here:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352880=12315920
>
>
> Ths git commit report is here:
>
> https://activemq.apache.org/components/artemis/download/commit-report-2.29.0
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.29.0
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1279
>
> In case you want to give it a try with the maven repo on examples:
>
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The version has been tagged on git as '2.29.0'
>
> I will update the website after the vote has passed.
>
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1
>
>
> I will keep the Vote open until monday, US EST morning, on June 19th
>
>
> --
> Clebert Suconic
>

Re: [VOTE] Apache ActiveMQ Artemis 2.28.0

[Gary Tully]

+1

On Tue, 31 Jan 2023 at 15:19, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.28.0 release.
>
> I would like to highlight the following changes in this release:
>
> - Page counting improved. We no longer store counters in the journal
> simply relying on paging itself for that
> - We implemented a way to sync mirror from AMQP Broker Connections
>
> For a complete release notes:
> https://activemq.apache.org/components/artemis/download/release-notes-2.28.0
>
> The git commit 
> report:https://activemq.apache.org/components/artemis/download/commit-report-2.28.0
>
>
> Source and binary staged distributions:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.28.0
>
> The maven repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1268
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The current release candidate is tagged on the git repository as 2.28.0
>
> I will update the website after the vote has passed
>
> [ ] +1 approve this release
> [ ] -1 disapprove (and why)
> [ ] +0 no opinion (I would appreciate a reason why if this is your
> choice as well)

Re: [VOTE] Apache ActiveMQ Artemis 2.27.1 release

[Gary Tully]

+1

On Mon, Nov 28, 2022, 21:54 Clebert Suconic 
wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.27.1 release
>
>
> This is a bug fix release,
>
> I would like to highlight these 3 bug fixes:
>
> - AMQP Large Message over Bridges were broken
> - Rollback of massive transactions would take a long time to process
> - Improvements to auto-create and auto-delete queues.
>
> For a full release notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352610=12315920
>
>
> Ths git commit report is here:
>
> https://activemq.apache.org/components/artemis/download/commit-report-2.27.1
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.27.1/
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1266
>
> In case you want to give it a try with the maven repo on examples:
>
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
>
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.27.1
>
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1 (binding)
>
>
>
> --
> Clebert Suconic
>

Re: [VOTE] Apache ActiveMQ Artemis 2.26.0 release

[Gary Tully]

+1

On Wed, 21 Sept 2022 at 21:24, Clebert Suconic
 wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.26.0 release.
>
>
> We removed ActiveMQ Artemis Rest, (which was already non functional)
> as part of this release.
> And other improvements and bug fixes.
>
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352297=12315920
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.26.0
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.26.0
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1262
>
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
> The source tag is 2.26.0 on git, commit
> 2d7b1a3ef7613dab68aeeb667f5b5eca37743b94:
> https://github.com/apache/activemq-artemis/releases/tag/2.26.0
>
> The source tag:
>
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/
>
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here is my +1 Binding vote
>
>
>
>
> --
> Clebert Suconic

Re: HEADS-UP 2.25.1 Next week

[Gary Tully]

The removal of the REST feature is the only breaking change, feature
wise logging will be compatible and most won't care.
I would suggest reverting the commit that requires a 3.0 :
  ARTEMIS-3987Removing ActiveMQ Artemis Rest from the codebase - commit e654eba

and cutting the next release from main ensuring that anything that
needs to go/be removed in 3.0, is marked deprecated.

then we can plan for a 3.0 after a little gap/break

On Fri, 16 Sept 2022 at 14:35, Clebert Suconic
 wrote:
>
> hmmm... this is actually pointless.. (the 2.x branch so far).
>
>
> I had to cherry-pick *everything* except to 1 commit:
>
> ARTEMIS-3987Removing ActiveMQ Artemis Rest from the codebase - commit e654eba
>
>
>
> We could definitely release from main right now...
>
>
> and I'm wondering if we shouldn't make the logging change on a 2.x
> branch I don't see much else beyond logging to warrant a 3.x
> branch (we can certainly make a plan for a 3.x and we could / should
> start working on it).
>
>
> What do you think?
>
> On Thu, Sep 15, 2022 at 4:41 PM Clebert Suconic
>  wrote:
> >
> > @Gary Tully unless you don't consider removing activemq-rest and
> > changing the logging framework a change big enough to warrant a bump
> > to 3.0. if the consensus is to keep main as 2.x we can certainly
> > rename it back and do the release from main. I thought we should
> > rename it based on these two things.
> >
> > On Thu, Sep 15, 2022 at 11:22 AM Clebert Suconic
> >  wrote:
> > >
> > > maini is already 3.0... removed Rest, and soon the logging change will
> > > be put it in there... If I release from main now, it will be called
> > > 3.0, and we will have to do a 4.0 when we bring in the logging
> > > changes.
> > >
> > >
> > > So, I would rather cherry-pick stuff into 2.x
> > >
> > > (I will go ahead and remove 2.25.x now)
> > >
> > > On Thu, Sep 15, 2022 at 8:46 AM Gary Tully  wrote:
> > > >
> > > > would it make sense to just cut 2.26.0 from main?
> > > >
> > > > On Wed, 14 Sept 2022 at 02:11, Clebert Suconic
> > > >  wrote:
> > > > >
> > > > > I am renaming the branch as 2.x (instead of 2.25.x).
> > > > >
> > > > >
> > > > > Some of the candidates to cherry-pick categorize it as an enhancement,
> > > > > so it would make the release next week to be named 2.26.0 instead of
> > > > > 2.25.1) (same branch, just promoting it to 2.26 due to an enhancement
> > > > > being part of it).
> > > > >
> > > > > for that reason I am pushing a 2.x branch and I will remove the 2.25.x
> > > > > branch (after a few days).
> > > > >
> > > > > On Tue, Sep 13, 2022 at 11:40 AM Clebert Suconic
> > > > >  wrote:
> > > > > >
> > > > > > I would like to do a 2.25.1 next week (monday or tuesday).
> > > > > >
> > > > > >
> > > > > > Please add any commits into 2.25.x (just pushed a new branch)...
> > > > > >
> > > > > >
> > > > > > please use cherry-pick -x on commits from main only. (git 
> > > > > > cherry-pick
> > > > > > -x )
> > > > > >
> > > > > > --
> > > > > > Clebert Suconic
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic

Re: HEADS-UP 2.25.1 Next week

[Gary Tully]

would it make sense to just cut 2.26.0 from main?

On Wed, 14 Sept 2022 at 02:11, Clebert Suconic
 wrote:
>
> I am renaming the branch as 2.x (instead of 2.25.x).
>
>
> Some of the candidates to cherry-pick categorize it as an enhancement,
> so it would make the release next week to be named 2.26.0 instead of
> 2.25.1) (same branch, just promoting it to 2.26 due to an enhancement
> being part of it).
>
> for that reason I am pushing a 2.x branch and I will remove the 2.25.x
> branch (after a few days).
>
> On Tue, Sep 13, 2022 at 11:40 AM Clebert Suconic
>  wrote:
> >
> > I would like to do a 2.25.1 next week (monday or tuesday).
> >
> >
> > Please add any commits into 2.25.x (just pushed a new branch)...
> >
> >
> > please use cherry-pick -x on commits from main only. (git cherry-pick
> > -x )
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic

Re: [VOTE] ActiveMQ Artemis Native 2.0.0 release (RC2)

[Gary Tully]

+1

On Tue, 12 Jul 2022 at 20:52, Clebert Suconic  wrote:
>
> I would like to propose an ActiveMQ Artemis Native 2.0.0 release
>
>
> For those who are not familiar, this is the Native Layer in Artemis
> responsible for the integration on Linux and Libaio.
>
>
> I have been working on some logging changes with Robbie Gemmel, and
> Artemis Native 2.0.0 is now using SLF4J. This Module will be a
> requirement for ActiveMQ Artemis to move forward with SLF4J.
>
>
>
> The source distribution is here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/2.0.0/
>
>
> The Maven staged repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1257
>
>
> The git tag is here:
> https://github.com/apache/activemq-artemis-native/releases/tag/2.0.0
>
>
> the release notes is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348395
>
>
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1 binding
>
>
>
>
> --
> Clebert Suconic

Re: [VOTE] ActiveMQ Artemis 2.23.1

[Gary Tully]

+1

On Tue, 14 Jun 2022 at 21:59, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.23.1 release
>
> This is a small release following up where I added a fix for the following 
> bug:
>
> https://issues.apache.org/jira/browse/ARTEMIS-3856 - Failed to change
> channel state to ReadyForWriting :
> java.util.ConcurrentModificationException
>
>
>
> The release notes is here:
> https://activemq.apache.org/components/artemis/download/release-notes-2.23.1
>
> The commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.23.1
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.23.1
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1254
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.23.1
>
> I will update the website after the vote has passed.
>
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here is my +1 Binding vote.

Re: [VOTE] Apache ActiveMQ Artemis 2.23.0

[Gary Tully]

+1

On Tue, 7 Jun 2022 at 20:05, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.23.0 release.
>
> As part of this release I would like to highlight the addition of
> Jakarta 10 to the supported APIs.
>
>
>
> The release notes can be found here:
> https://activemq.apache.org/components/artemis/download/release-notes-2.23.0
>
> The git commit report:
> https://activemq.apache.org/components/artemis/download/commit-report-2.23.0
>
>
>
> Source and binary distributions can be found here:
>
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.23.0
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-
>
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.23.0
>
> or the equivalent tag on github:
> https://github.com/apache/activemq-artemis/releases/tag/2.23.0
>
>
> I will update the website after the vote has passed.
>
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here is my +1 Binding Vote

Re: [VOTE] Apache ActiveMQ Artemis 2.22.0

[Gary Tully]

+1

On Fri, 29 Apr 2022 at 12:26, Robbie Gemmell  wrote:
>
> On Thu, 28 Apr 2022 at 17:25, Clebert Suconic  
> wrote:
> >
> > I would like to propose an Apache ActiveMQ Artemis 2.22.0 release.
> >
> >
> > There are no new features on this release, however there are many
> > improvements and bug fixes.
> >
> > In particular there's a default change on cluster connections where we
> > now use 1MB bytes for flow control, avoiding Out Of Memory exception
> > on situations with high latency networking:
> >
> > * ARTEMIS-3083 Set a default producer-window-size on cluster connection
> >
> >
> > There are many other improvements and bug fixes and the full release
> > notes is available here for more information:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12351488
> >
> >
> > Ths git commit report is here:
> > https://activemq.apache.org/components/artemis/download/commit-report-2.22.0
> >
> >
> > Source and binary distributions can be found here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.22.0
> >
> > The Maven staged repository is here:
> > https://repository.apache.org/content/repositories/orgapacheactivemq-1251
> >
> >
> > In case you want to give it a try with the maven repo on examples:
> > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
> >
> >
> > The source tag:
> >
> > https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.22.0
> >
> >
> > [ ] +1 approve this release
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> >
> > Here's my +1 (Binding) vote
> >
> >
> >
> > I should keep this release open for 72 Hours, and I'm not going to
> > count the weekend as business hours. That means I will keep this
> > release open until at least May-3rd, Noon USA EST.
>
> +1
>
> I checked things out as follows:
> - Verified the signature + checksum files.
> - Checked for LICENCE and NOTICE files in the archives.
> - Checked licence headers in the source archive by running:
>   "mvn apache-rat:check"
> - Ran the Qpid JMS 2.0.0 HelloWorld against the broker from the binary 
> archive.
> - Ran the source build and the AMQP integration tests on JDK11 with:
>   "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
> -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
> test"
>
> Robbie

Re: [VOTE] Apache ActiveMQ Artemis 2.19.1

[Gary Tully]

+1

thank you!

verified source distro build and basic function

On Wed, 26 Jan 2022 at 20:08, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.19.1 release.
>
>
> This is a maintenance release on top of 2.19.0 that includes a few bug fixes.
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12351260
>
> The git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.19.1
>
>
> I have generated a XREF report here, where you can follow commits that
> were cherry-picked from master into 2.19.1.. Look for the column XREF
> on the report:
> https://activemq.apache.org/components/artemis/download/cherry-pick-report-2.19.1
>
>
> Source and binary distributions are found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.1/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1241
>
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.19.1
>
> I will update the website after the vote has passed.
>
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)

Re: [VOTE] Apache ActiveMQ Artemis 2.20.0

[Gary Tully]

+1

build from source, verified basic operation and console

On Wed, 15 Dec 2021 at 17:23, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.20.0 release...
>
>
> There is a few improvements and bug fixes on this release, there's one
> feature added:
>
> [ARTEMIS-2097] - Pause and Block Producers
>
> This is also the first release where we are requiring JDK 11+. JDK 1.8
> won't work on this release any longer.
>
>
> You can access the release notes and the git report here:
> https://activemq.apache.org/components/artemis/download/release-notes-2.20.0
>
>
> The source and binary distributions:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.20.0
>
> The maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1240
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.20.0
>
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> This also records my +1 (Binding) vote.
>
> I will keep this VOTE open until Monday Dec-20th 12:30 PM US EST time
> as the usual 72 hours for the release would take us to a Saturday.
>
> --
> Clebert Suconic

Re: Migrating plugins from ActiveMQ to Artemis

[Gary Tully]

there are plugin apis in artemis that map nicely - see
https://github.com/apache/activemq-artemis/tree/main/examples/features/standard/broker-plugin

however, for  your own authenticating/authorizing plugin the simplest
approach is to wrap your plugin in a custom security manager.
see an example:
https://github.com/apache/activemq-artemis/tree/main/examples/features/standard/security-manager

some doc pointers at
https://activemq.apache.org/components/artemis/documentation/latest/security.html#custom-security-manager

On Fri, 15 Oct 2021 at 08:58, Jędrzej Dudkiewicz
 wrote:
>
> Hi all,
> we have our own authenticating/authorizing plugin for ActiveMQ. We
> would like to migrate to Artemis, but for (probably) obvious reasons
> this plugin is a must. Are there any documents describing plugin
> migration from AMQ to Artemis? Are they drop-in compatible or do I
> have to develop one from scratch? I've been trying to figure it out
> from API and source code, unfortunately the code base is rather large
> and I was unable to make heads or tails of it.
> --
> Jędrzej Dudkiewicz
>
> I really hate this damn machine, I wish that they would sell it.
> It never does just what I want, but only what I tell it.

Re: [VOTE] Apache ActiveMQ Artemis 2.19.0

[Gary Tully]

+1

On Thu, 14 Oct 2021 at 17:29, Timothy Bish  wrote:
>
> On 10/11/21 10:13 PM, Justin Bertram wrote:
> > I would like to propose an Apache ActiveMQ Artemis 2.19.0 release.
> >
> > We added these new features as part of 2.19.0:
> >
> > - New ability to replay retained journal records via the management API.
> > - New environment/system property to set the "key" for masked passwords when
> >using the default codec.
> > - Ability to disable message-load-balancing and still allow redistribution
> > via the new OFF_WITH_REDISTRIBUTION type.
> > - MQTT session state can now be cleaned up automatically to avoid excessive
> >accumulation in situations where client's don't clean up their own
> > sessions.
> > - Distribute full Jakarta Messaging 3.0 client in the lib/client directory
> >along with a new example of how to use it in
> > examples/features/standard/queue-jakarta.
> >
> >
> > The release notes can be found here:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12350519
> >
> > Ths git commit report is here:
> > https://activemq.apache.org/components/artemis/download/commit-report-2.19.0.html
> >
> > Source and binary distributions can be found here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.0/
> >
> > The Maven repository is here:
> > https://repository.apache.org/content/repositories/orgapacheactivemq-1238
> >
> > In case you want to give it a try with the maven repo on examples:
> > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
> >
> > The source tag:
> > https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=tree;h=28749a383b3c60faed3ec28f96905cf11f9d1bf0;hb=refs/tags/2.19.0
> >
> > I will update the website after the vote has passed.
> >
> >
> > [ ] +1 approve this release
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my +1
> >
> +1
>
> * Validated signatures and checksums
> * Verified license and notice files
> * Check source for license headers
> * Built from source and ran the AMQP tests
>
>
> --
> Tim Bish
>

Re: JMS Mix "Classic" Clients with "Artemis" Servers

[Gary Tully]

yes. Artemis has openwire protocol support on the default Acceptor.
It peeks at the initial packets to see what protocol manager - AMQP,
OPENWIRE, MQTT, CORE etc it needs to hand off to.

On Wed, 13 Oct 2021 at 12:20, Christoph Läubrich  wrote:
>
> We currently plan to switch from Classic>Artemis but there is one point
> not completely clear (or I have missed something?), is it possible to
> connect with a "activemq classic" JMSConnectionFactory to an artemis
> server (given that they both enable the tcp transport of course, same
> host and port etc...)
>
> So we can switch the server to "Artemis" and then upgrade the (classic)
> clients step-by-step?

Re: [VOTE] Apache ActiveMQ Artemis 2.19.0

[Gary Tully]

the check sum seems wrong:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.0/apache-artemis-2.19.0-bin.tar.gz.sha512
can someone else verify?

I get: 
fbf14235851a3044d5c7732b1a21412c3b0fd5f312e814d2449c7e0533e9467718c48e577a80806a996593c626a8268aeee490beb93abef369ac9498130dc631

built from source, happy smoke-test of distro

On Wed, 13 Oct 2021 at 08:26, Jean-Baptiste Onofre  wrote:
>
> +1 (binding)
>
> Regards
> JB
>
> > Le 12 oct. 2021 à 04:13, Justin Bertram  a écrit :
> >
> > I would like to propose an Apache ActiveMQ Artemis 2.19.0 release.
> >
> > We added these new features as part of 2.19.0:
> >
> > - New ability to replay retained journal records via the management API.
> > - New environment/system property to set the "key" for masked passwords when
> >  using the default codec.
> > - Ability to disable message-load-balancing and still allow redistribution
> > via the new OFF_WITH_REDISTRIBUTION type.
> > - MQTT session state can now be cleaned up automatically to avoid excessive
> >  accumulation in situations where client's don't clean up their own
> > sessions.
> > - Distribute full Jakarta Messaging 3.0 client in the lib/client directory
> >  along with a new example of how to use it in
> > examples/features/standard/queue-jakarta.
> >
> >
> > The release notes can be found here:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12350519
> >
> > Ths git commit report is here:
> > https://activemq.apache.org/components/artemis/download/commit-report-2.19.0.html
> >
> > Source and binary distributions can be found here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.0/
> >
> > The Maven repository is here:
> > https://repository.apache.org/content/repositories/orgapacheactivemq-1238
> >
> > In case you want to give it a try with the maven repo on examples:
> > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
> >
> > The source tag:
> > https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=tree;h=28749a383b3c60faed3ec28f96905cf11f9d1bf0;hb=refs/tags/2.19.0
> >
> > I will update the website after the vote has passed.
> >
> >
> > [ ] +1 approve this release
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my +1
>

Re: [PROPOSAL] Change Apache ActiveMQ blog theme

[Gary Tully]

it may make sense to disable comment on the blog, it seems all are
spam. If conversations need to happen around a blog post, they can be
on the user list.

On Mon, 19 Apr 2021 at 10:12, Domenico Francesco Bruscino
 wrote:
>
> Hi guys,
>
> I have just applied the new theme, see https://blogs.apache.org/activemq/
> I can revert this change if someone objects.
>
> Thanks,
> Domenico
>
> On Fri, 16 Apr 2021 at 15:45, Matt Pavlovich  wrote:
>
> > +1
> >
> > Thanks,
> > Matt Pavlovich
> >
> > > On Apr 14, 2021, at 1:26 PM, Domenico Francesco Bruscino <
> > bruscin...@gmail.com> wrote:
> > >
> > > you can find a preview image of the gaurav theme at
> > https://blogs.apache.org/themes/gaurav/gaurav-preview.png <
> > https://blogs.apache.org/themes/gaurav/gaurav-preview.png>
> > >
> > >
> > > Thanks,
> > > Domenico
> > >
> > > On Wed, 14 Apr 2021 at 17:48, Matt Pavlovich  > > wrote:
> > > +1 in favor of modernizing the blog theme.
> > >
> > > Do you have a link to a preview site of the theme you are suggesting?
> > >
> > > Thanks,
> > > Matt Pavlovich
> > >
> > > > On Apr 14, 2021, at 10:42 AM, Domenico Francesco Bruscino <
> > bruscin...@gmail.com > wrote:
> > > >
> > > > Thanks Clebert, I'm going to change the theme next week unless someone
> > > > objects according to the lazy consensus[1].
> > > > I can revert this change any time in the future even if someone
> > > > will object after the next week.
> > > >
> > > > [1] https://community.apache.org/committers/lazyConsensus.html <
> > https://community.apache.org/committers/lazyConsensus.html>
> > > >
> > > > On Wed, 14 Apr 2021 at 17:25, Clebert Suconic <
> > clebert.suco...@gmail.com >
> > > > wrote:
> > > >
> > > >> I couldn't see the attachment through the email on the dev list, but
> > I know
> > > >> what you're talking about..
> > > >>
> > > >> to me it's a no brainer.. You have to.. the theme you're selecting is
> > a lot
> > > >> more modern.
> > > >>
> > > >> On Wed, Apr 14, 2021 at 10:50 AM Domenico Francesco Bruscino <
> > > >> bruscin...@gmail.com > wrote:
> > > >>
> > > >>> Hi guys,
> > > >>>
> > > >>> I would like to change the theme of Apache ActiveMQ blog[1]. The
> > current
> > > >>> theme is `ASF Projects Theme` while I would like to use the `Gaurav`
> > > >> theme
> > > >>> because it is a responsive Bootstrap-based theme using modern HTML5
> > and
> > > >>> CSS3.
> > > >>>
> > > >>> ASF Projects Theme
> > > >>> [image: image.png]
> > > >>>
> > > >>> Gaurav
> > > >>> [image: image.png]
> > > >>>
> > > >>> [1] https://blogs.apache.org/activemq/ <
> > https://blogs.apache.org/activemq/>
> > > >>>
> > > >>> Thoughts ?
> > > >>>
> > > >>> Regards,
> > > >>> Domenico
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Clebert Suconic
> > > >>
> > >
> >
> >

Re: ACK compaction with local transactions

[Gary Tully]

good catch, reading back on AMQ-7067 I see that both xa and local
commits were considered but only xa was completed!
see: 
https://issues.apache.org/jira/browse/AMQ-7067?focusedCommentId=16643245=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643245

this fix and test looks good.
it may be good to open a new jira to track this case, b/c AMQ-7067 has
been closed since 2018.

On Tue, 23 Mar 2021 at 19:49, Jonathan Gallimore
 wrote:
>
> Hi
>
> I've been looking at a problem I ran into here where messages are consumed,
> and acknowledged, but are then later redelivered to the consumer again
> after a broker restart.
>
> The consumer is running with transacted sessions, and looking in KahaDB, I
> can see a KAHA_REMOVE_MESSAGE_COMMAND, with the local transaction ID added
> to the journal, and then a KAHA_COMMIT_COMMAND after it. Some time later, I
> see the exact same KAHA_REMOVE_MESSAGE_COMMAND appended to the journal
> again, with the exact same transaction information, but no
> corresponding KAHA_COMMIT_COMMAND. This appears to follow a
> KAHA_REWRITTEN_DATA_FILE_COMMAND.
>
> It looks like the ack compaction method is forwarding the acknowledgement,
> but not the commit - it appears that the commit is only forwarded in the
> case of an XA transaction.
>
> I notice that there are some tests around this in AMQ-7067. I've managed to
> reproduce this with a further test case in AMQ8067Test.java, and I have
> created a PR for this here: https://github.com/apache/activemq/pull/636,
> and backported to 5.16.x https://github.com/apache/activemq/pull/637 and
> 5.15.x. https://github.com/apache/activemq/pull/638
>
> Are there other cases that should be tested around this?
>
> Thanks
>
> Jon

Re: [PROPOSAL] Rename Apache ActiveMQ from "Classic" to "Leto" | Website update/polish

[Gary Tully]

gt;> that
> >>>>>>>> AMQP
> >>>>>>>>>>> has
> >>>>>>>>>>>> its own separate governance that both brokers just adhere to?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Further to that then and if so where do OpenWire clients all
> >> (JMS
> >>>>>>>>>>>> OpenWire, NMS OpenWire, CMS OpenWire sit? In the OpenWire
> >> project?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Likewise where does bits like PooledConnectionFactory that can
> >> be
> >>>>>>>> shared
> >>>>>>>>>>>> and but sits in ActiveMQ code base atm then move to? I assume it
> >>>>>>>> might
> >>>>>>>>>>> move
> >>>>>>>>>>>> with the JMS OpenWire client.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ok great but then where does the CMS/NMS apis governance sit
> >> (not
> >>>>>>>>>>>> implementation)? Do we sit that still in ActiveMQ? Do we move it
> >>>> to
> >>>>>>>> its
> >>>>>>>>>>> own
> >>>>>>>>>>>> TLP? Do we move it to OpenWire?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Lastly, what about naming? I don’t like the idea of just Apache
> >>>>>>>> Artemis,
> >>>>>>>>>>>> nor ArtemisMQ , for me it was named Artemis simply because of
> >> the
> >>>>>>>>>>> previous
> >>>>>>>>>>>> dumped Apollo project, maybe a better named should be found? And
> >>>>>> then
> >>>>>>>>>>> what
> >>>>>>>>>>>> about existing users, the code base is littered with
> >>>>>>>>>>>> org.apache.activemq.artemis.* if TLP move occurred, there’d need
> >>>> to
> >>>>>>>> be
> >>>>>>>>>>> some
> >>>>>>>>>>>> package migration that would need to be done in a non breaking
> >>>>>>>> fashion
> >>>>>>>>>>>> where people have developed on and around the current code base
> >>>> apis
> >>>>>>>> and
> >>>>>>>>>>>> packaged.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> As such id like to see much more a proposed plan for everything
> >>>>>>>> before
> >>>>>>>>>>> any
> >>>>>>>>>>>> vote.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best
> >>>>>>>>>>>> Mike
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 19 Mar 2021, at 16:27, Jean-Baptiste Onofre <
> >> j...@nanthrax.net>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Fair enough, let’s wait more PMC/dev feedback.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards
> >>>>>>>>>>>>> JB
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Le 19 mars 2021 à 17:25, Christopher Shannon <
> >>>>>>>>>>>> christopher.l.shan...@gmail.com> a écrit :
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I'd like to see more PMC members chime in to get thoughts and
> 

Re: [PROPOSAL] Rename Apache ActiveMQ from "Classic" to "Leto" | Website update/polish

[Gary Tully]

> >>>> Over the past couple of years my opinion has swayed now to simply
> >> making
> >>>> Artemis its own TLP. Even after 6 years we have 2 separate communities
> >>>> entirely. We basically have 2 independent projects with almost no
> >> overlap
> >>>> between developers and users so why not just make Artemis its own TLP?
> >> I
> >>>> really see no benefit of operating under the same umbrella anymore (I
> >>> guess
> >>>> maybe if you want to keep the branding)
> >>>>
> >>>> On Fri, Mar 19, 2021 at 10:57 AM Jean-Baptiste Onofre  >>> <mailto:j...@nanthrax.net>>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I understand the point. My main concern was in term of versioning (I
> >>> don’t
> >>>>> want to "block" ActiveMQ to do a 6, 7, 8 or whatever release).
> >>>>>
> >>>>> Sorry, but classic is something I don’t fully understand (maybe my
> >>> French
> >>>>> culture ;)). I don’t see what’s "classic" (or maybe in term of
> >>> "previous"
> >>>>> or "older") is. Maybe "vintage" (like classical music compare to house
> >>>>> music) ;) ?
> >>>>>
> >>>>> And, anyway, nobody is using "classic": for the users I know, they use
> >>>>> ActiveMQ and Artemis (not ActiveMQ Classic or ActiveMQ Artemis).
> >>>>>
> >>>>> So, if you agree to have:
> >>>>>
> >>>>> http://activemq.apache.org/artemis <
> >> http://activemq.apache.org/artemis>
> >>> <http://activemq.apache.org/artemis <http://activemq.apache.org/artemis
> >>>>
> >>>>> http://activemq.apache.org/activemq <
> >>> http://activemq.apache.org/activemq> <
> >> http://activemq.apache.org/activemq
> >>> <http://activemq.apache.org/activemq>>
> >>>>>
> >>>>> I think it’s even better than introducing a new name, I agree.
> >>>>>
> >>>>> Then, I’m changing the proposal/question: agree to use activemq and
> >>>>> Artemis on website ?
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>>> Le 19 mars 2021 à 15:48, Bruce Snyder  >>  >>> bruce.sny...@gmail.com>> a écrit :
> >>>>>>
> >>>>>> Gary stated this well. I agree completely with all of his sentiments
> >>>>> here.
> >>>>>>
> >>>>>> I don't see the point to introducing yet another name as this will
> >>> muddy
> >>>>>> these waters even further, not clarify them. Artemis was meant to be
> >> a
> >>>>> code
> >>>>>> name until it matched ActiveMQ enough to be a drop-in replacement. I
> >>>>> don't
> >>>>>> believe that this goal has been achieved yet, has it? Is this still
> >> an
> >>>>>> active goal?
> >>>>>>
> >>>>>> Classic is an appropriate and deliberate name that was being
> >> discussed
> >>> as
> >>>>>> far back as just prior to the HornetQ donation. If we start
> >> officially
> >>>>>> referring to it as ActiveMQ Classic, then we need to explain the
> >> intent
> >>>>>> behind this name via the website.
> >>>>>>
> >>>>>> Agreed, the Classic stream needs a major version bump before those
> >>>>>> incompatible changes are introduced. Do this and move forward with
> >>> those
> >>>>>> incompatible changes.
> >>>>>>
> >>>>>> Bruce
> >>>>>>
> >>>>>> On Fri, Mar 19, 2021 at 8:29 AM Gary Tully  >>> <mailto:gary.tu...@gmail.com>> wrote:
> >>>>>>
> >>>>>>> Hi JB,
> >>>>>>> I think "classic" is a good name precisely because of its meaning,
> >> it
> >>>>>>> reflects its value and is a good way to differentiate on the
> >> website.
> >>>>>>>
> >>>>>>> But I don't

Re: [PROPOSAL] Rename Apache ActiveMQ from "Classic" to "Leto" | Website update/polish

[Gary Tully]

Hi JB,
I think "classic" is a good name precisely because of its meaning, it
reflects its value and is a good way to differentiate on the website.

But I don't think the classic stream should be limited in versioning.
If for good reason (a new incompatible openwire version/storage
incompatible change/large config update) it needs a major version
increment, then go for it.

Artemis was always intended as a code name, a generic title, a
temporary moniker, till it could take on the activemq mantle, but it
does not have to be 6, it can be 10 or 20, or it can be ActiveMQ
Artemis.

I don't see any point in introducing another "brand" name, the
versioning will be sufficient if we want to consolidate on the
activemq name in the future, and the Artemis sub brand will be
sufficient if we don't.

to speak to Lucas, the plan for Artemis is to be be a better ActiveMQ

kind regards,
gary.

On Fri, 19 Mar 2021 at 04:49, Jean-Baptiste Onofre  wrote:
>
> Hi,
>
> Like any Apache (and OpenSource) project, ActiveMQ "umbrella" project is 
> living and roadmap evolves.
>
> Justin is right with the project history, but I think the initial target to 
> "replace" ActiveMQ with Artemis evolves, due to the users.
>
> Personally, I’m saying still lot of ActiveMQ users, not planning to change to 
> Artemis, and even brand new installation starts with ActiveMQ (not Artemis).
> Furthermore, in term of features, there are some gaps between ActiveMQ and 
> Artemis IMHO.
>
> I think the mistake was to create a separated repo for Artemis: if Artemis 
> was ActiveMQ "master" branch at the time of the donation, then, the update 
> would be straight forward.
>
> So, clearly, IMHO, we have two completed separated projects between ActiveMQ 
> and Artemis, because the communities (both users and contributors) are not 
> the same.
>
> A possible path to that Artemis become Apache TLP (and so ActiveMQ Artemis 
> name), and ActiveMQ "classic" stays what he’s: Apache ActiveMQ.
>
> If the PMC don’t want to "move" as a TLP, then we should at least give space 
> for the two subprojects in the ActiveMQ umbrella and clearly identify who is 
> what.
>
> Regards
> JB
>
> > Le 19 mars 2021 à 05:13, Tetreault, Lucas  a 
> > écrit :
> >
> > Hey Justin,
> >
> > Thanks for the additional context. As a newcomer, it seems to me like both 
> > ActiveMQ "Classic" and Artemis are alive and well. 6 years and 2 major 
> > versions in to development, is the goal and focus for Artemis still on 
> > feature parity and becoming ActiveMQ 6?
> >
> > Thanks,
> > Lucas
> >
> >
> > On 2021-03-18, 8:38 PM, "Justin Bertram"  wrote:
> >
> >CAUTION: This email originated from outside of the organization. Do not 
> > click links or open attachments unless you can confirm the sender and know 
> > the content is safe.
> >
> >
> >
> >Lucas,
> >
> >I'm not sure you've been around the ActiveMQ community for very long or
> >maybe you have been and forgot some of the history. In any case, I'll
> >summarize briefly.
> >
> >Over a decade ago Hiram Chirino, one of the original ActiveMQ developers
> >and chair of the ActiveMQ PMC at the time, created a new broker under the
> >ActiveMQ banner named Apollo. It was designed on a non-blocking
> >architecture for much better performance than the existing ActiveMQ
> >architecture [1]. After ActiveMQ Apollo 1.0 was released the stated goal 
> > of
> >this project was for it to eventually be integrated with the mainline
> >ActiveMQ code-base and serve as its replacement [2]. This fact was
> >advertised on the ActiveMQ website although there are no longer any
> >references to that since the website was redesigned & updated a year or 
> > so
> >ago. For whatever reason Apollo never acquired the critical mass 
> > necessary
> >to replace mainline ActiveMQ.
> >
> >Then about 6 years ago the HornetQ code-base was donated to the ActiveMQ
> >community and that donation was accepted with the goal of creating the 
> > next
> >generation ActiveMQ broker that would eventually become version 6. Since
> >that time work has steadily progressed on the Artemis code-base to bring
> >sufficient feature parity with mainline ActiveMQ to allow users to
> >transition. Again, this has been communicated via the website and other
> >support channels for the last several years.
> >
> >For what it's worth, I hope that clarifies the current state of affairs.
> >
> >
> >Justin
> >
> >[1]
> >
> > https://hiramchirino.com/blog/2011/01/17/activemq-apollo-looking-impressive/
> >[2] https://hiramchirino.com/blog/2012/02/03/apache-apollo-1-0-released/
> >
> >On Thu, Mar 18, 2021 at 5:02 PM Tetreault, Lucas
> > wrote:
> >
> >> Hi all,
> >>
> >> It seems to me like the core problem here is that there are two distinct
> >> projects operating under one brand and it creates confusion. I agree with
> >> JB that the "ActiveMQ Classic" and "ActiveMQ 5" branding are not 

Re: [VOTE] Apache ActiveMQ Artemis 2.17.0 RC2

[Gary Tully]

+1

On Thu, 11 Feb 2021 at 20:25, Clebert Suconic  wrote:
>
>  would like to propose an Apache ActiveMQ Artemis 2.17.0 release. This
> is the second try, Release Candidate 2 (RC2). The previous identified
> issue with the NOTICE with the wrong year has been fixed.
>
>
>
> This is a summary of the improvements as part of 2.17.0:
>
> - Message-level authorization similar to ActiveMQ 5.x.
> - A count of addresses and queues is now available from the management API.
> - You can now reload the broker's configuration from disk via the
> management API rather than waiting for the periodic disk scan to pick
> it up
> - Performance improvements on libaio journal.
> - New command-line option to transfer messages.
> - Performance improvements for the wildcard address manager.
> - JDBC datasource property values can now be masked.
> - Lots of usability improvements to the Hawtio 2 based web console
> introduced in 2.16.0
> - New management method to create a core bridge using JSON-based
> configuration input.
>
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12349326
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.17.0
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.17.0
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1225
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.17.0
>
>
> I will update the website after the vote has passed.
>
> [ ] +1 approve the release as Apache Artemis 2.17.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> --
> Clebert Suconic

Re: [VOTE] Apache ActiveMQ Artemis 2.17.0

[Gary Tully]

+1

verified source distro, signature and sha
built with jdk8, message round trip via console
all good.

On Tue, 9 Feb 2021 at 22:35, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.17.0 release
>
>
> This is a summary of the improvements as part of 2.17.0:
>
> - Message-level authorization similar to ActiveMQ 5.x.
> - A count of addresses and queues is now available from the management API.
> - You can now reload the broker's configuration from disk via the
> management API rather than waiting for the periodic disk scan to pick
> it up
> - Performance improvements on libaio journal.
> - New command-line option to transfer messages.
> - Performance improvements for the wildcard address manager.
> - JDBC datasource property values can now be masked.
> - Lots of usability improvements to the Hawtio 2 based web console
> introduced in 2.16.0
> - New management method to create a core bridge using JSON-based
> configuration input.
>
>
> The release notes can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12349326
>
> Ths git commit report is here:
> https://activemq.apache.org/components/artemis/download/commit-report-2.17.0
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.17.0
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1224
>
> In case you want to give it a try with the maven repo on examples:
> https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.17.0
>
>
> I will update the website after the vote has passed.
>
> [ ] +1 approve the release as Apache Artemis 2.17.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)

Re: [VOTE] Apache ActiveMQ Artemis 2.16.0

[Gary Tully]

+1

verified source archive

On Tue, 3 Nov 2020 at 01:45, Clebert Suconic 
wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.16.0 release.
>
> This release is including these new features as part of 2.16.0:
>
> [ARTEMIS-2901] - Support namespace for temporary queues
> [ARTEMIS-2937] - AMQP Server Connectivity
> [ARTEMIS-2947] - Implement SecurityManager that supports replication
>
>
> [ARTEMIS-2937] AMQP Server Connectivity is actually a new module,
> where you can use it to "bridge" messages, expand the broker
> networking using AMQP and other products such as Qpid Dispatch,  and
> also includes an option to mirror the broker asynchronously into
> another broker and maybe another site. I would recommend reading the
> documentation for more information:
>
>
> https://github.com/apache/activemq-artemis/blob/master/docs/user-manual/en/amqp-broker-connections.md
>
>
> The release notes is included here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348718
>
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.16.0
>
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1219
>
> In case you want to give it a try with the maven repo on examples:
>
> http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html
>
> The source tag:
>
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.16.0
>
> I will update the website after the vote has passed.
>
>
> [ ] + 1 approve the release as Apache ActiveMQ Artemis 2.16.0
> [ ] + 0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> This vote will stay open for at least 72 hours. (End of day of
> Thursday, Nov 5th 2020)
>

Re: [DISCUSS] AMQP connectivity new features

[Gary Tully]

yep, that is better. naming is very hard

On Fri, 9 Oct 2020 at 15:49, Clebert Suconic 
wrote:

> I can definitely rename the interface.
>
> I did not want the interface exposed to users outside of the context
> of the mirroring I'm doing here. for other usages users can get what
> they want from broker plugins.
>
>
> I will rename this as Mirror
>
>
> and then I can have a MirrorSource and MirrorTarget
>
>
> WDYT?
>
> On Thu, Oct 8, 2020 at 8:21 AM Gary Tully  wrote:
> >
> > Hi Clebert, this is a great piece of work.
> >
> > One thing popped out for me from the PR, the remoteControl interface.
> >
> > I know naming is hard :-). That name to me means something is controlling
> > from afar. But I think it is really a set of change events that a broker
> > can emit. If I understand correctly, a ``mirror`` AMQP outbound
> connection
> > is turning those events/commands into amqp messages on an address that a
> > receiver is using to replicate a selective state.
> > Another listener could use it for generating notifications or audits?
> >
> > Should it be called ChangeEvents? or ChangeActions - because there are
> > operations for each event.
> >
> > further on that, if a mirror is making a broker replica, I could imagine
> a
> > change event for a new security role or for a role deletion event. Does
> > this sort of thing fit in with your idea of a RemoteControl?
> >
> > I guess I am getting ahead a little, as in all events that change a
> broker
> > are potentially relevant to a mirror, and if some extra plugins are in
> > play, maybe some extra events need to get replicated.
> >
> > In other words, this is a concrete specific implementation of a more
> > general concept, change data capture.  To make it extensible would
> require
> > being able to publish events and on the receiver end, find a handler or
> > ignore events that are unrecognised. It would need some conventions etc.
> >
> > In any event, something like that is now possible :-)
> >
> > /gary
> >
> > On Wed, 7 Oct 2020 at 23:14, Clebert Suconic 
> > wrote:
> >
> > > sorry for the SPAM: I meant to add the link:
> > >
> > > https://github.com/apache/activemq-artemis/pull/3294
> > >
> > > On Wed, Oct 7, 2020 at 4:17 PM Clebert Suconic
> > >  wrote:
> > > >
> > > > I have posted a Pull Request.. .(for review only at this time)
> > > >
> > > > I would appreciate reviews.
> > > >
> > > > I'm fixing some issues, adding docs.. but the overall is ready for
> > > > code review already.
> > > >
> > > > Thank you
> > > >
> > > > On Thu, Oct 1, 2020 at 9:55 AM Clebert Suconic
> > > >  wrote:
> > > > >
> > > > > I am working on new features in the AMQP Protocol Handler, and I
> would
> > > > > like to explain here what I am doing:
> > > > >
> > > > >
> > > > > I needed to go beyond what we do now with AMQP, and use it connect
> > > > > brokers, and eventually with qpid-dispatch for more elaborate
> > > > > networking on datacenters.
> > > > >
> > > > > First part:
> > > > >
> > > > > The first issue I had while implementing something protocol
> specific
> > > > > (other than Core) was to use the classes within the protocol
> package.
> > > > > As the broker is agnostic to the protocols (exception is core
> ATM), I
> > > > > needed the whole initialization to take place within
> > > > > artemis-amqp-protocol.
> > > > >
> > > > > To get around that I added what I called ProtocolServices. So when
> you
> > > > > implement a protocol service the interface will be called within
> > > > > broker start.
> > > > >
> > > > >
> > > > > Second part:
> > > > >
> > > > > As the broker is now taking action on connecting to other brokers
> (or
> > > > > other AMQP servers), I needed to change out Netty bootstrapping to
> > > > > allow outgoing connections with a given protocol. With that I'm
> > > > > inverting everything we had for server, and I am abusing the power
> of
> > > > > AMQP here. Since AMQP is totally symmetrical I can now connect
> brokers
> > > > > directly. So, a Consumer on the broker and be connected directly
> to a
> >

Re: [DISCUSS] AMQP connectivity new features

[Gary Tully]

Hi Clebert, this is a great piece of work.

One thing popped out for me from the PR, the remoteControl interface.

I know naming is hard :-). That name to me means something is controlling
from afar. But I think it is really a set of change events that a broker
can emit. If I understand correctly, a ``mirror`` AMQP outbound connection
is turning those events/commands into amqp messages on an address that a
receiver is using to replicate a selective state.
Another listener could use it for generating notifications or audits?

Should it be called ChangeEvents? or ChangeActions - because there are
operations for each event.

further on that, if a mirror is making a broker replica, I could imagine a
change event for a new security role or for a role deletion event. Does
this sort of thing fit in with your idea of a RemoteControl?

I guess I am getting ahead a little, as in all events that change a broker
are potentially relevant to a mirror, and if some extra plugins are in
play, maybe some extra events need to get replicated.

In other words, this is a concrete specific implementation of a more
general concept, change data capture.  To make it extensible would require
being able to publish events and on the receiver end, find a handler or
ignore events that are unrecognised. It would need some conventions etc.

In any event, something like that is now possible :-)

/gary

On Wed, 7 Oct 2020 at 23:14, Clebert Suconic 
wrote:

> sorry for the SPAM: I meant to add the link:
>
> https://github.com/apache/activemq-artemis/pull/3294
>
> On Wed, Oct 7, 2020 at 4:17 PM Clebert Suconic
>  wrote:
> >
> > I have posted a Pull Request.. .(for review only at this time)
> >
> > I would appreciate reviews.
> >
> > I'm fixing some issues, adding docs.. but the overall is ready for
> > code review already.
> >
> > Thank you
> >
> > On Thu, Oct 1, 2020 at 9:55 AM Clebert Suconic
> >  wrote:
> > >
> > > I am working on new features in the AMQP Protocol Handler, and I would
> > > like to explain here what I am doing:
> > >
> > >
> > > I needed to go beyond what we do now with AMQP, and use it connect
> > > brokers, and eventually with qpid-dispatch for more elaborate
> > > networking on datacenters.
> > >
> > > First part:
> > >
> > > The first issue I had while implementing something protocol specific
> > > (other than Core) was to use the classes within the protocol package.
> > > As the broker is agnostic to the protocols (exception is core ATM), I
> > > needed the whole initialization to take place within
> > > artemis-amqp-protocol.
> > >
> > > To get around that I added what I called ProtocolServices. So when you
> > > implement a protocol service the interface will be called within
> > > broker start.
> > >
> > >
> > > Second part:
> > >
> > > As the broker is now taking action on connecting to other brokers (or
> > > other AMQP servers), I needed to change out Netty bootstrapping to
> > > allow outgoing connections with a given protocol. With that I'm
> > > inverting everything we had for server, and I am abusing the power of
> > > AMQP here. Since AMQP is totally symmetrical I can now connect brokers
> > > directly. So, a Consumer on the broker and be connected directly to a
> > > producer on another broker. Acting like a bridge, but way more
> > > lightweight.
> > >
> > >
> > > Third part:
> > >
> > > I am using that for replicas. At the moment these replicas will not
> > > sync the client, but they are working quite nicely. and allowing
> > > multiple replicas.
> > >
> > >
> > >
> > > The configuration will take part as the following.
> > >
> > > You define amqp connections with their URL and their reconnecting
> > > information, for each connection you can define:
> > >
> > > sender : All addresses matching will have a
> > > transfer sender. This will act like a push bridge
> > > receiver < matching addresses>: All matching addresses on this broker
> > > will create a consumer pulling messages. This will act like a pull
> > > bridge
> > > peer : This will create both ways, but you can
> > > only use this towards a special server that knows how to handle this.
> > > (e.g. qpid-dispatch). otherwise you get ping pongs on transfers
> > > copy  : This will create a replica, without
> > > sending the acks, (You will be responsible to consume the messages
> > > yourself at the target broker)
> > > replica : Just like copy, but acks are sent and
> > > messages removed upong ack (or accept)
> > >
> > >
> > > This is an example of the configuration:
> > >
> > > 
> > >   
> > > > > retry-interval="333" reconnect-attempts="33">
> > >   
> > >   
> > >   
> > >   
> > >   
> > >
> > > 
> > >
> > >
> > > so far these are being worked on a my github fork/ but it's not really
> > > meant for a review at this point as I have some cleanup to do (some
> > > logging messages and stuff I have to remove).
> > >
> > > I am getting ready to send a Pull Request early next week. but you
> > > have the concepts 

Re: [VOTE] Apache ActiveMQ Artemis 2.15.0 release

[Gary Tully]

+1

- built from dist source with 1.8 jdk and verified distro operation

On Tue, 25 Aug 2020 at 19:48, Domenico Francesco Bruscino <
bruscin...@gmail.com> wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.15.0 release.
>
> We added these new features as part of 2.15.0:
>
> [ARTEMIS-2847] - socks5h support
> [ARTEMIS-2855] - Define a new broker plugin to track XA transactions
> [ARTEMIS-2857] - Expose ActivemqServer::isActivated through
> ActiveMQServerControl
>
> We had quite a few improvements on this release:
>
> [ARTEMIS-2844] - Improve MQTT subscribe/unsubscribe topic performance
> [ARTEMIS-2845] - ConcurrentAppendOnlyChunkedList cannot be queried while
> resizing
> [ARTEMIS-2863] - Support pausing dispatch during group rebalance
> [ARTEMIS-2872] - Support FQQN syntax for security-settings
> [ARTEMIS-2880] - Support FQQN syntax for JNDI lookup
> [ARTEMIS-2882] - Better support for JMS topics + FQQN
>
> And we also had some important fixes:
>
> [ARTEMIS-2862] - Activation failure can result in zombie broker
> [ARTEMIS-2868] - Split Brain on Replication could "damage" the Topology,
> isolating the server
> [ARTEMIS-2877] - Fix journal replication scalability
>
> The release notes can be found here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348568
>
> Ths git commit report is here:
>
> https://activemq.apache.org/components/artemis/download/commit-report-2.15.0
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.15.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1217
>
> In case you want to give it a try with the maven repo on examples:
>
> http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html
>
> The source tag:
>
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.15.0
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve the release as Apache Artemis 2.15.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1
>

[RESULT][VOTE] Apache ActiveMQ CLI Tools 0.2.0

[Gary Tully]

There were 3 binding +1 votes and no other votes were received.
The vote has passed.

Thanks to all who took the time to verify the release.

/gary.

Re: [DISCUSS] ActiveMQ KahaDB Export Tool 0.1.0

[Gary Tully]

Hi Samuel,
the release(s) can be found at:
https://www.apache.org/dyn/closer.cgi?filename=apache/activemq
activemq-cli-tools

The project is at: https://github.com/apache/activemq-cli-tools

On Thu, 21 May 2020 at 15:10, skao  wrote:

> Hi Tim,
>
> I would like to convert the kahadb data to xml format too.
>
> How did you that ?
> Where did you get the kahadb export tool ?
>
> Please kindly advise.
>
> Thanks,
> Samuel
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>

Re: [VOTE] Apache ActiveMQ CLI Tools 0.2.0

[Gary Tully]

Hi Chris,
yes, the fingerprint is correct as far as I can see, I think the problem is
that page re-creation.

lastCreateTimestamp: 20200721184646Z is two days old:
at the bottom of: https://people.apache.org/keys/committer/



On Thu, 23 Jul 2020 at 15:38, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Gary,
>
> Did you upload your key fingerprint to https://id.apache.org ? It still
> isn't showing up yet and the link that Robbie pointed out says it should
> update once a day if you upload the fingerprint to your account.
>
> Chris
>
> On Wed, Jul 22, 2020 at 4:03 PM Gary Tully  wrote:
>
> > Thanks Robbie,
> > it is published[1] and the nexus 'close' process verified the sigs so it
> > may be that the apache keys page needs more time to refresh.
> > I will keep an eye on it.
> >
> > [1]
> > https://pgp.surfnet.nl/pks/lookup?search=gtully=on=index
> >
> > On Wed, 22 Jul 2020 at 14:21, Robbie Gemmell 
> > wrote:
> >
> > > Did you upload your new PGP public key to a keyserver? It isnt being
> > > listed at https://people.apache.org/keys/ because it hasnt been found.
> > > That may mean you cant release the staging repo.
> > >
> > > On Wed, 22 Jul 2020 at 11:06, Gary Tully  wrote:
> > > >
> > > > Thanks Tim,
> > > > makes perfect sense and is item 11 on the release guide, sorted now.
> > > >
> > > > The staged artifacts are at:
> > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/activemq/activemq-cli-tools/0.2.0/
> > > >
> > > > kind regards,
> > > > gary
> > > >
> > > > On Tue, 21 Jul 2020 at 21:18, Timothy Bish 
> > wrote:
> > > >
> > > > > On 7/21/20 1:03 PM, Gary Tully wrote:
> > > > > > Hi Everyone,
> > > > > > I have a candidate for vote.
> > > > > > This has support for migrating virtual topic consumer queues to
> > > durable
> > > > > > subscription queues as part of kahadb export.
> > > > > >
> > > > > > doc:  https://github.com/apache/activemq-cli-tools
> > > > > >
> > > > > > The list of resolved issues is here:
> > > > > >
> > > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821
> > > > > > <
> > > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821=Create_token=A5KQ-2QAV-T4JA-FDED_2141d238181a14d05d38a6fcfc5a3e12f5f15824_lout
> > > > > >
> > > > > >
> > > > > > You can get binary distributions here:
> > > > > >
> > > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
> > > > > > activemq/activemq-cli-tools/0.2.0/
> > > > > >
> > > > > > Source archives are here:
> > > > > >
> > > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
> > > > > > activemq/activemq-cli-tools-parent/0.2.0/
> > > > > >
> > > > > > Maven repository is at:
> > > > > >
> > > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215
> > > > > >
> > > > > >
> > > > > > Source tag:
> > > > > >
> > > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-cli-tools.git;a=tag;h=refs/tags/0.2.0
> > > > > >
> > > > > > Please vote to approve this release.  The vote will remain open
> for
> > > 72
> > > > > > hours.
> > > > > >
> > > > > > [ ] +1 Release the binary as Apache ActiveMQ CLI Tools 0.2.0
> > > > > > [ ] -1 (provide specific comments)
> > > > > >
> > > > > > Here's my +1
> > > > > >
> > > > > I don't see any artifacts uploaded to the staging site for this
> > > release so
> > > > > I cannot review them since
> > > > > I don't know what the artifacts are that are actually going to get
> > > moved
> > > > > to dist release in the end.
> > > > >
> > > > > https://dist.apache.org/repos/dist/dev/
> > > > >
> > > > > --
> > > > > Tim Bish
> > > > >
> > > > >
> > >
> >
>

Re: [VOTE] Apache ActiveMQ CLI Tools 0.2.0

[Gary Tully]

Thanks Robbie,
it is published[1] and the nexus 'close' process verified the sigs so it
may be that the apache keys page needs more time to refresh.
I will keep an eye on it.

[1] https://pgp.surfnet.nl/pks/lookup?search=gtully=on=index

On Wed, 22 Jul 2020 at 14:21, Robbie Gemmell 
wrote:

> Did you upload your new PGP public key to a keyserver? It isnt being
> listed at https://people.apache.org/keys/ because it hasnt been found.
> That may mean you cant release the staging repo.
>
> On Wed, 22 Jul 2020 at 11:06, Gary Tully  wrote:
> >
> > Thanks Tim,
> > makes perfect sense and is item 11 on the release guide, sorted now.
> >
> > The staged artifacts are at:
> >
> >
> https://dist.apache.org/repos/dist/dev/activemq/activemq-cli-tools/0.2.0/
> >
> > kind regards,
> > gary
> >
> > On Tue, 21 Jul 2020 at 21:18, Timothy Bish  wrote:
> >
> > > On 7/21/20 1:03 PM, Gary Tully wrote:
> > > > Hi Everyone,
> > > > I have a candidate for vote.
> > > > This has support for migrating virtual topic consumer queues to
> durable
> > > > subscription queues as part of kahadb export.
> > > >
> > > > doc:  https://github.com/apache/activemq-cli-tools
> > > >
> > > > The list of resolved issues is here:
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821
> > > > <
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821=Create_token=A5KQ-2QAV-T4JA-FDED_2141d238181a14d05d38a6fcfc5a3e12f5f15824_lout
> > > >
> > > >
> > > > You can get binary distributions here:
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
> > > > activemq/activemq-cli-tools/0.2.0/
> > > >
> > > > Source archives are here:
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
> > > > activemq/activemq-cli-tools-parent/0.2.0/
> > > >
> > > > Maven repository is at:
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215
> > > >
> > > >
> > > > Source tag:
> > > >
> > >
> https://git-wip-us.apache.org/repos/asf?p=activemq-cli-tools.git;a=tag;h=refs/tags/0.2.0
> > > >
> > > > Please vote to approve this release.  The vote will remain open for
> 72
> > > > hours.
> > > >
> > > > [ ] +1 Release the binary as Apache ActiveMQ CLI Tools 0.2.0
> > > > [ ] -1 (provide specific comments)
> > > >
> > > > Here's my +1
> > > >
> > > I don't see any artifacts uploaded to the staging site for this
> release so
> > > I cannot review them since
> > > I don't know what the artifacts are that are actually going to get
> moved
> > > to dist release in the end.
> > >
> > > https://dist.apache.org/repos/dist/dev/
> > >
> > > --
> > > Tim Bish
> > >
> > >
>

Re: [VOTE] Apache ActiveMQ CLI Tools 0.2.0

[Gary Tully]

Thanks Tim,
makes perfect sense and is item 11 on the release guide, sorted now.

The staged artifacts are at:

https://dist.apache.org/repos/dist/dev/activemq/activemq-cli-tools/0.2.0/

kind regards,
gary

On Tue, 21 Jul 2020 at 21:18, Timothy Bish  wrote:

> On 7/21/20 1:03 PM, Gary Tully wrote:
> > Hi Everyone,
> > I have a candidate for vote.
> > This has support for migrating virtual topic consumer queues to durable
> > subscription queues as part of kahadb export.
> >
> > doc:  https://github.com/apache/activemq-cli-tools
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821
> > <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821=Create_token=A5KQ-2QAV-T4JA-FDED_2141d238181a14d05d38a6fcfc5a3e12f5f15824_lout
> >
> >
> > You can get binary distributions here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
> > activemq/activemq-cli-tools/0.2.0/
> >
> > Source archives are here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
> > activemq/activemq-cli-tools-parent/0.2.0/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1215
> >
> >
> > Source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-cli-tools.git;a=tag;h=refs/tags/0.2.0
> >
> > Please vote to approve this release.  The vote will remain open for 72
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ CLI Tools 0.2.0
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
> I don't see any artifacts uploaded to the staging site for this release so
> I cannot review them since
> I don't know what the artifacts are that are actually going to get moved
> to dist release in the end.
>
> https://dist.apache.org/repos/dist/dev/
>
> --
> Tim Bish
>
>

[VOTE] Apache ActiveMQ CLI Tools 0.2.0

[Gary Tully]

Hi Everyone,
I have a candidate for vote.
This has support for migrating virtual topic consumer queues to durable
subscription queues as part of kahadb export.

doc:  https://github.com/apache/activemq-cli-tools

The list of resolved issues is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821


You can get binary distributions here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
activemq/activemq-cli-tools/0.2.0/

Source archives are here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
activemq/activemq-cli-tools-parent/0.2.0/

Maven repository is at:
https://repository.apache.org/content/repositories/orgapacheactivemq-1215


Source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq-cli-tools.git;a=tag;h=refs/tags/0.2.0

Please vote to approve this release.  The vote will remain open for 72
hours.

[ ] +1 Release the binary as Apache ActiveMQ CLI Tools 0.2.0
[ ] -1 (provide specific comments)

Here's my +1

[ANNOUNCE] CVE-2020-13932 Apache ActiveMQ Artemis - Remote XSS in Web console Diagram Plugin

[Gary Tully]

Apache ActiveMQ Artemis - Remote XSS in Web console Diagram Plugin

Severity: Medium

Vendor: The Apache Software Foundation

Affected Version: Apache ActiveMQ Artemis 2.5.0 to 2.13.0

Vulnerability details:
A specifically crafted MQTT packet which has an XSS payload as
client-id or topic name can exploit this vulnerability. The XSS
payload is being injected into the admin console's browser. The XSS
payload is triggered in the diagram plugin; queue node and the info
section.

Mitigation:
Upgrade to Apache ActiveMQ Artemis 2.14.0

Credit: This issue was discovered by Arun Magesh from Payatu Software Labs

see:
https://activemq.apache.org/security-advisories.data/CVE-2020-13932-announcement.txt

Re: Replace racially charged terms throughout source code, comments and documentation

[Gary Tully]

I think for openwire, rename and a change in openwire version is the way to go.
keeping the old terms around for backward compatibility is both
sensible and necessary.

On Tue, 14 Jul 2020 at 11:42, Christopher Shannon
 wrote:
>
> I agree that it is time to make the change. Justin made a good point in
> that we should make sure to pick the best and most descriptive names
> possible for the use case. Whether that is follower/leader,
> primary/secondary, primary/replica, live/backup, etc. I think live/backup
> certainly makes a lot of sense for Artemis. For 5.x I think it also makes
> sense but primary/secondary is fine too.
>
> My main concern here is how do we handle the technical issues with
> compatibility? For example, do we just deprecate the old configuration and
> terminology to not break users or do we rip it out entirely initially which
> would be a breaking change for users that needs to be well communicated?
> For Artemis, maybe we deprecated in 2.x and in 3.x.
>
> Another thing is some things will be easy to change and others not so
> much.  For something like the LevelDB store that uses the terminology this
> is easy as we can just remove it entirely as we plan to remove it in 5.17
> anyways. However, one thing that does seem like a challenge to fix is
> OpenWire. For example the BrokerInfo command actually uses the terms
> slaveBroker and masterBroker. Renaming these would now break compatibility
> with brokers running older versions of 5.x.  I think the only way it would
> work is to keep the terms around for the older versions of OpenWire and
> then generate a new version that has them renamed which I'm not sure if
> that is or isn't acceptable as the software would still be distributed with
> those older terms laying around.
>
> On Mon, Jul 13, 2020 at 11:57 PM Xeno Amess  wrote:
>
> > They did?
> > OK, then I have no more doubts.
> >
> > Justin Bertram  于2020年7月14日周二 上午11:42写道：
> >
> > > For what it's worth, GitHub is changing the default branch name so
> > there's
> > > no argument to be had with them as you suggest. See here [1] for example.
> > >
> > >
> > > Justin
> > >
> > > [1] https://www.bbc.com/news/technology-53050955
> > >
> > > On Mon, Jul 13, 2020, 10:24 PM Xeno Amess  wrote:
> > >
> > > > Hi.
> > > > If you really think "master" is something you cannot accept, then you
> > > might
> > > > argue with github first.
> > > > after all their default git branch name is "master", and github have
> > far
> > > > more user than ActiveMQ.
> > > >
> > > > Bruce Snyder  于2020年7月14日周二 上午11:03写道：
> > > >
> > > > > Someone mentioned use of the terms 'primary' and 'backup' in the
> > > private
> > > > > list and I liked that suggestion. I'm not wed to any terms
> > necessarily,
> > > > so
> > > > > if Artemis is already using the terms 'live' and 'backup', I'm ok
> > with
> > > > that
> > > > > in ActiveMQ.
> > > > >
> > > > > Bruce
> > > > >
> > > > > On Mon, Jul 13, 2020 at 8:42 PM Justin Bertram 
> > > > > wrote:
> > > > >
> > > > > > Thanks for kicking this off, Bruce.
> > > > > >
> > > > > > Among other things the Jira [1] says:
> > > > > >
> > > > > > > 'master' and 'slave' should be replaced with the terms 'primary,'
> > > > > > 'secondary,' 'tertiary,' etc.
> > > > > >
> > > > > > I would offer "live" and "backup" as suitable replacements for
> > > "master"
> > > > > and
> > > > > > "slave" respectively. The Artemis code and documentation already
> > use
> > > > > "live"
> > > > > > and "backup" in many places although some instances of "master" and
> > > > > "slave"
> > > > > > do exist. Aside from the fact that they're already in use I like
> > the
> > > > fact
> > > > > > that they're relatively short and they clearly capture the
> > underlying
> > > > > > functional semantic. In my opinion the terms "primary,"
> > "secondary,"
> > > > etc.
> > > > > > are actually a bit vague and they're certainly quite a bit longer
> > > which
> > > > > > isn't a huge deal but it adds up when writing tests, documentation,
> > > > etc.
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/AMQ-7514
> > > > > >
> > > > > > On Mon, Jul 13, 2020 at 3:04 PM Bruce Snyder <
> > bruce.sny...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Given the racial charged nature of certain terms in today's
> > world,
> > > I
> > > > > feel
> > > > > > > that action should be taken to change any such terms in all the
> > > > > ActiveMQ
> > > > > > > projects. Examples include 'master,' 'slave,' 'whitelist' and
> > > > > > 'blacklist'.
> > > > > > >
> > > > > > > It doesn't matter where these terms originated or how long they
> > > have
> > > > > been
> > > > > > > used in computer science. I have friends who feel that these
> > terms
> > > > are
> > > > > > > offensive and present a barrier to entry to some. So, I would
> > > prefer
> > > > > that
> > > > > > > they no longer be used anywhere in the ActiveMQ project. The
> > simple
> > > > > 

Re: [VOTE] Apache ActiveMQ Artemis 2.14.0

[Gary Tully]

+1

thank you.

On Fri, 10 Jul 2020 at 14:26, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.14.0 release.
>
> We only added one feature as part of this release:
>
> [ARTEMIS-2770] - Update diverts using the management API
>
> And we have quite a few improvements on this release:
>
> [ARTEMIS-2109] - enable building Artemis with JDK 11+
> [ARTEMIS-2771] - Support JVM GC & thread metrics
> [ARTEMIS-2776] - Dockerfile improvements to startup arguments
> [ARTEMIS-2786] - Timestamp in console is incorrect
> [ARTEMIS-2787] - Allow a queue to be disabled, so that messages are not
> routed to it.
> [ARTEMIS-2797] - Reset queue properties by unsetting them in broker.xml
> [ARTEMIS-2807] - Avoid notifications on critical IO error
> [ARTEMIS-2820] - Undeploy diverts by removing them from broker.xml
> [ARTEMIS-2827] - Add addressMemoryUsagePercentage as metric
> [ARTEMIS-2828] - Add addressSize as metric
>
>
>
> The whole release notes is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348290==12315920=Create_token=A5KQ-2QAV-T4JA-FDED_4d142d7a703c84c576af5fabc058fb51bb1473f2_lin
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.14.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1214
>
> In case you want to give it a try with the maven repo on examples:
> http://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve the release as Apache Artemis 2.4.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> --
> Clebert Suconic

Re: [VOTE] Apache ActiveMQ 5.16.0 release (take #2)

[Gary Tully]

+0

doing: mvn install on the source bundle, after about 6 attempts it
gets through all but one test:

activemq-karaf-itest

ActiveMQBrokerFeatureTest.testSendReceiveWeb:122->produceMessageWebConsole:106
post succeeded, POST
http://localhost:8181/activemqweb/sendMessage.action?secret=042c4710-37f5-4fd5-94b8-8979a97c2224=1593422784780=1593422784780=queue
HTTP/1.1 expected:<302> but was:<500>

not a biggie but needs fixing at some point. Mabe someone else can
verify in their environment.

Thanks for taking care of this release JB

On Thu, 25 Jun 2020 at 15:23, Jean-Baptiste Onofré  wrote:
>
> Hi everyone,
>
> Now that we fixed the ASF header issue, I'm submitting ActiveMQ 5.16.0
> release to your vote (take #2).
>
> This release is an important milestone as the runtime supports JDK 11.
> The full build with JDK 11 is planned for 5.17.0.
>
> It also includes bunch of fixes, improvements and much more.
>
> For your information, once this vote will pass, I will create
> activemq-5.16.x branch and I will move master branch to version 5.17.0.
>
> Please take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12341032
>
> The Maven staging repository is:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1213/
>
> The dist staging repository is:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.0/
>
> Git tag:
> activemq-5.16.0
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

Re: [VOTE] ActiveMQ Artemis Native 1.0.2

[Gary Tully]

+1

verified sha512 on dist source bundle, license and readme

On Wed, 17 Jun 2020 at 16:00, Clebert Suconic  wrote:
>
> Right, sorry for the miss... it's uploaded now
>
>
> This VOTE thread remains open
>
>
> Just for reference,
>
> here is the staged source release:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/
>
> Here is the maven staged repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1211/
>
>
>
>
> This release is purely source and maven, there won't be any binaries
> released apart from the ones in maven central.
>
> On Wed, Jun 17, 2020 at 10:39 AM Robbie Gemmell
>  wrote:
> >
> > The source archive should be in the dist repo yes, as 'the source is
> > the release' so to speak, thus ensuring it actually gets archived etc
> > (mirroring obviously not as useful in this specific case).
> >
> > Putting it in the dist dev area for voting helps ensure folks are
> > actually testing the release as it will be distributed, precisely what
> > will be remotely moved/copied into the release area afterwards, when
> > verifying it has the relevant signatures + checksums etc etc that go
> > along with doing a release and satisfying the foundations
> > requirements.
> >
> > On Wed, 17 Jun 2020 at 14:59, Clebert Suconic  
> > wrote:
> > >
> > > The release is staged on nexus:
> > >
> > > https://repository.apache.org/content/repositories/orgapacheactivemq-1211
> > >
> > >
> > > This release binary is only maven.. The only source we would
> > > distribute is the source.. and nothing else.
> > >
> > > If you want to, I can create the source distribution under there.. but
> > > it's not going to be any different than what is staged in nexus right
> > > now.
> > >
> > >
> > > On Tue, Jun 16, 2020 at 3:30 PM Timothy Bish  wrote:
> > > >
> > > > On 6/15/20 11:19 AM, Clebert Suconic wrote:
> > > > > I would like to propose an Apache ActiveMQ Artemis Native 1.0.2 
> > > > > release.
> > > > >
> > > > >
> > > > > Artemis native is a dependency for Artemis responsible for the journal
> > > > > type libaio. It's basically a JNI wrapper submitting writes to the
> > > > > kernel on Linux.
> > > > >
> > > > >
> > > > > I have already tested the testsuite with this release and it worked 
> > > > > fine.
> > > > >
> > > > >
> > > > > As part of this release, I'm addressing:
> > > > >
> > > > > https://issues.apache.org/jira/browse/ARTEMIS-2800 Work around kernel 
> > > > > issue
> > > > >
> > > > >
> > > > > I'm trapping the issue before it happened on the kernel. So in case
> > > > > you are running artemis-native on a kernel with the offending bug, it
> > > > > would work around the issue and the broker would not crash.
> > > > >
> > > > > So far this has only been seen on RHEL 7.8 as further releases on
> > > > > kernel upstream already contain a fix. But I want to prevent it from
> > > > > ever happening again.
> > > > >
> > > > >
> > > > > The release notes is here:
> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346447
> > > > >
> > > > > The repository is here:
> > > > > https://repository.apache.org/content/repositories/orgapacheactivemq-1211/
> > > > >
> > > > > The tag is here:
> > > > > https://gitbox.apache.org/repos/asf/activemq-artemis-native.git;a=tag;h=refs/tags/1.0.2
> > > > >
> > > > > Steps to use the staged maven repo:
> > > > > http://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
> > > > >
> > > > > I update the website after the vote has passed.
> > > > >
> > > > > Notice that we will only provide sources for this release, and the
> > > > > maven repository as the source for binaries.
> > > > >
> > > > > [ ] +1 approve the release as Apache Artemis 2.4.0
> > > > > [ ] +0 no opinion
> > > > > [ ] -1 disapprove (and reason why)
> > > > >
> > > > >
> > > > > Here's my +1
> > > >
> > > >
> > > > I don't see any artifacts uploaded to the staging site for this release
> > > > so I cannot review them
> > > >
> > > > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/
> > > >
> > > >
> > > >
> > > > --
> > > > Tim Bish
> > > >
> > >
> > >
> > > --
> > > Clebert Suconic
>
>
>
> --
> Clebert Suconic

Re: [VOTE] Apache ActiveMQ 5.15.13 release

[Gary Tully]

+1

On Mon, 25 May 2020 at 12:41, Jean-Baptiste Onofre  wrote:
>
> Hi everyone,
>
> I'm submitting ActiveMQ 5.15.13 release to your vote.
>
> This release includes several bug fixes and improvements.
>
> Please take a look on the Release Notes for details:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12347002
>  
> 
>
> The Maven staging repository is:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1210/ 
> 
>
> The dist staging repository is:
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.13/ 
> 
>
> Git tag:
> activemq-5.15.13
>
> Website PR:
> https://github.com/apache/activemq-website/pull/31 
> 
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks !
> Regards
> JB

Re: [VOTE] Apache ActiveMQ Artemis 2.13.0

[Gary Tully]

+1

On Mon, 18 May 2020 at 17:26, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.13.0 release.
>
>
> This release will include these features:
>
> [ARTEMIS-2666] - Add management for duplicate ID cache
> [ARTEMIS-2726] - Implement min/max expiry-delay
> [ARTEMIS-2738] - Implement per-acceptor security domains
> [ARTEMIS-2739] - Artemis health check tool
> [ARTEMIS-2758] - Support disabling metrics per address
> [ARTEMIS-2761] - Supporting QUOTED-IDS on expressions to align with qpid-jms
>
> There was a significant improvement in AMQP. With a recent fix in Flow
> control combined with previous changes in scheduling, Performance in
> AMQP is significant fast to any previous version. I personally spent
> time on profiling AMQP and the server does not show much fat to cut on
> processing, which means.. that's really fast.
>
> AMQP is a serious contender to even Artemis Core protocol.
>
> The release notes is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348088
>
> The git commit report is here:
> http://activemq.apache.org/components/artemis/download/commit-report-2.13.0
>
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.13.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1209
>
> In case you want to give it a try with the maven repo on examples:
> http://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.13.0
>
>
> I will update the website after the vote has passed.
>
>
>
> [ ] +1 approve the release as Apache Artemis 2.4.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1

Re: [DISCUSS] Artemis health check tool (ARTEMIS-2739)

[Gary Tully]

I imagine the equivalent of the oracle db query : "select * from
DUAL", ie: something that exercise the server.

A combination of queue produce and consume, on some existing queue or
on a temp queue for that purpose.
I guess an existing queue may be better b/c on production systems
queue creation may be locked down.

This covers any potential unexpected blocking, the caveat though, is
that blocking can be a reasonable response for a queuing system that
has reached some limits.

A system that cannot produce may be healthy if it can browse.

To that end, maybe we need to have a pre configured queue that has one
message on it.
We verify we can browse it, then *if* after some small timeout we can
produce to it, we consume it. Essentially replacing the single entry
on the queue.

Periodic monitoring would cycle the head of the queue, blocking and
browsing would indicate healthy but blocked since the message-in-time
of the head of the queue.

It is some sort of multi value return: for example,  -1 cannot browse,
0 all good (replaced the head), > 0 the time of the head of the queue
I guess it could be red, green, amber also, but that is more vague. It
could be turned into that!

what is good health is very context specific, but a framework like
this could be generally useful I think and provide an example of how
some more context specific health checks could be achieved.
maybe some food for thought.

/gary

On Tue, 28 Apr 2020 at 10:52, Domenico Francesco Bruscino
 wrote:
>
> I'm implementing a tool to determine whether the broker is in a healthy
> state. There is a series of health checks that can be performed, starting
> with the most basic and very rarely producing false positives, to
> increasingly more comprehensive, intrusive, and opinionated that have a
> higher probability of false positives.
>
> In the following list there are some health checks grouped by target:
> - node
>   - up - check if a client can connect to the the node
>   - disk - check if the disk hits the `max-disk-usage` limit
>   - memory - check if the memory available to the JVM
>   - backup - check if the backup node is announced
>   - queues - check if all queues with a positive rate have a consumer
> - queue
>   - up - check if the queue exists
>   - browser - check if the queue is browsable
>   - consumer - check if a consumer can connect to the queue and/or receive
> messages
>   - producer - check if a producer can connect to the queue and/or send
> messages
>
> I would start with some of the previous checks, exposing them through the
> MBeans interfaces and/or the Command Line utility.
>
> What are your thoughts?
>
> Domenico

Re: [VOTE] Apache ActiveMQ Artemis 2.12.0 RC2

[Gary Tully]

+1

On Tue, 21 Apr 2020, 22:59 Clebert Suconic, 
wrote:

> I would like to propose an Apache ActiveMQ Artemis 2.12.0 release.
>
> This is a second try after I cancelled the release after a possible
> blocker.
>
> We added the following features as part of 2.12.0:
>
> [ARTEMIS-1194] - SOCKS proxy support
> [ARTEMIS-1975] - Real LargeMessage support for AMQP
> [ARTEMIS-2587] - ActiveMQ5-like dead letter strategy
> [ARTEMIS-2613] - Support DivertBindings for Federated Addresses
> [ARTEMIS-2624] - Auto-create expiry resources
> [ARTEMIS-2692] - Provide Improved API for Queue Creation
>
> and it also include the fix for the previous blocker I identified:
>
> [ARTEMIS-2728] Fixing Deadlock with LargeServerMessage
>
>
>
> Also, I want to highlight the Large Message support for AMQP, which is
> a major enhancement that required some refactoring on the broker to
> implement this feature.
>
> We also added a new API for queue creation, simplifying operations on
> embedded broker or Core Client.
>
> This is also among many bug fixes. The complete release report can be
> found here:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346675
>
> A detailed commit report:
> http://activemq.apache.org/artemis/commit-report-2.12.0.html
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.12.0
>
> The staged Maven Repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1208
>
> Instructions to how to validate the maven repository if you want to
> give it a try:
>
> http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html
>
> The source tag:
>
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.12.0
>
> I will update the website after the vote has passed
>
> [ ] +1 approve the release as Apache Artemis 2.12.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>

Re: NIST CVEs for ActiveMQ

[Gary Tully]

I don't think there is any need for code change, just a lack of
documentation or a reference to refer to the jolokia docs on how to
lock down jolokia.
https://jolokia.org/reference/html/security.html#security-policy-location

I have not looked into that in detail but my guess is it should be
possible to add that config.


On Fri, 18 Oct 2019 at 12:13, Colm O hEigeartaigh  wrote:
>
> Thanks Gary. OK so for 2 + 3, the issue is in Hawtio and not AMQ, so I will
> alert NIST about changing the CPE score for these issues so that we don't
> see CVEs appearing when scanning AMQ artifacts.
>
> Just to get a bit more clarity on your comment for point (1) - grepping the
> AMQ source for "jolokia.policyLocation" doesn't throw anything up. There is
> a reference in the Hawt IO source though for it (
> https://github.com/hawtio/hawtio/search?q=jolokia.policyLocation_q=jolokia.policyLocation).
> Does this mean the issue was not fixed in AMQ?
>
> Colm.
>
> On Thu, Oct 17, 2019 at 2:32 PM Gary Tully  wrote:
>
> > for 2 and 3, the fix is in the http endpoint configuration for hawtio
> > for 1, configuring jolokia.policyLocation is all that is required.
> > that was not possible in earlier versions of A-MQ.
> >
> > I don't think any of the above are relevant to activemq 5.
> >
> >
> > On Thu, 17 Oct 2019 at 12:53, j...@nanthrax.net  wrote:
> > >
> > >
> > > Hi Colm
> > >
> > > I will do a review as I'm preparing 5.16.0 and 5.15.11 releases.
> > >
> > > Thanks for the reminder.
> > >
> > > Regards
> > > JB
> > >
> > > On Thursday, October 17, 2019 13:52 CEST, Colm O hEigeartaigh <
> > cohei...@apache.org> wrote:
> > >  Hi,
> > >
> > > I previously posted this to the private list (last year), but I didn't
> > get
> > > any reply - so maybe I'll have more luck here :-)
> > >
> > > I'd like to clear up 3 ActiveMQ CVEs that are reported at NIST, which
> > have
> > > no "fix" version associated with them. Please give me some feedback on
> > the
> > > following:
> > >
> > > 1) https://nvd.nist.gov/vuln/detail/CVE-2015-5182 (
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1248809). The redhat bug is
> > > marked as "WONTFIX", so I'm not sure if this was accepted as a valid
> > issue
> > > or not?
> > >
> > > 2) https://nvd.nist.gov/vuln/detail/CVE-2015-5183. This is reported
> > against
> > > the HawtIO console for AMQ. If the fix was in HawtIO, and not AMQ, and we
> > > don't bundle Hawt IO, then the CPE is invalid, as the issue has nothing
> > to
> > > do with AMQ. Could someone confirm this? Was there any fix made to the
> > AMQ
> > > codebase for this issue?
> > >
> > > 3) https://nvd.nist.gov/vuln/detail/CVE-2015-5184. This is reported
> > against
> > > the HawtIO console for AMQ. If the fix was in HawtIO, and not AMQ, and we
> > > don't bundle Hawt IO, then the CPE is invalid, as the issue has nothing
> > to
> > > do with AMQ. Could someone confirm this? Was there any fix made to the
> > AMQ
> > > codebase for this issue?
> > >
> > > I can communicate the findings with NIST to update the CVEs if I get some
> > > feedback.
> > >
> > > Colm.
> > >
> > >
> > >
> >

Re: [DISCUSS] Artemis Federation improvements

[Gary Tully]

Hi Christopher,
this is timely, I started peeking at federation this week also, to see
if I can make it a "better bridge" from the perspective of only moving
messages that are needed.
The idea is to use AMQP as the protocol and flow messages across the
bridge based on aggregate AMQP credit, ie: rather than have all
messages move between brokers when local consumers are slow, only move
to satisfy remote/upstream credit and react to it dynamically, which
is a fundamental part of AMQP flow control.

i need to pull together a POC of this to verify how easy/hard it will
be to aggregate credit demand etc and have outbound AMQP calls, but I
think it can be really good and fix an age old problem with the 5.x
bridge.

it would also help with the duplex part because of the symmetric nature of AMQP.

on the duplex and configuration command, authentication was one
problem in 5.x, in that the same users needed to exist on all brokers
b/c the user/pass etc was part of the bridge config, I think the
"reuse of the same connection" may be important to avoid that need. It
will typically need to be TLS and maybe cert based authentication so
maybe SASL would also come into play.

The duplex case in my mind was always about hub/spoke where the hub
did not need to be aware of the spokes configuration. Each spoke could
initiate a duplex/two way bridge to the hub and not require any
additional fire wall ports. To my mind, propagation of config and
reuse of the connection was always related.
But for sure small steps. And maybe AMQP can help!

On Thu, 17 Oct 2019 at 16:34, Christopher Shannon
 wrote:
>
> Duplex is still up in the air as I was going to do the downstream portion
> first.  A true duplex bridge would share the same connection which is what
> happens In 5.x.  It establishes the bridge and then the remote broker gets
> a command to also send messages back over the same connection.
>
> So we could do something similar, or we could make it easier and just
> automatically create two connections.  So for example we could define a
> duplex connection as part of the federation config and under the covers the
> federation will just create 1 upstream and 1 downstream connection
> automatically.  Having 2 connections could be better performance anyways
> and prevent traffic from each direction from getting in the way of the
> other.  We could also support both options, etc.
>
> On Thu, Oct 17, 2019 at 11:26 AM Justin Bertram  wrote:
>
> > I think your implementation idea makes sense and it is actually quite
> > similar to what is done for clustering (i.e. each broker tells all the
> > other brokers how they can connect back to it). This makes sense to me as a
> > way to configure downstream brokers, but I'm still fuzzy on the "duplex"
> > part. Does this idea fulfill both the configuration aspect and the "duplex"
> > aspect? Could you clarify what you mean by "duplex"? I always conceived
> > that implementing "duplex" would require modifying the bridge to be able to
> > "pull" messages rather than only "push" them.
> >
> >
> > Justin
> >
> > On Thu, Oct 17, 2019 at 8:13 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > I recently started to dive into the federation support as I try and
> > migrate
> > > 5.x brokers to Artemis as I need something similar to how 5.x does
> > bridging
> > > and federated queues/addresses seem like more in line to what I need than
> > > clustering.
> > >
> > > However, I've noticed several shortcomings and enhancements that will be
> > > necessary to make it useful.  The first thing is right now you can only
> > > configure an upstream broker which is backwards from how 5.x configures a
> > > bridge (it configures a one way downstream).  So I wanted to go ahead and
> > > enhance Federation support to allow configuring both downstream brokers
> > and
> > > hopefully duplex as well.
> > >
> > > For the approach I was thinking that maybe if we could add a
> > configuration
> > > option for downstream brokers.  Then, when the connection is made to the
> > > remote broker we could send a new CORE packet command with the info for
> > the
> > > Federation config.  Then the remote broker could receive this config,
> > parse
> > > it, and then establish an upstream link based on that information back to
> > > the broker that made the connection...essentially creating a downstream
> > > link but re-using the existing upstream way of creating the bridge to
> > > simplify things.
> > >
> > > I can work on the PR and difference enhancements but wanted to get some
> > > agreement on the approach before spending a bunch of time on it.
> > >
> > > Thoughts? Or other ideas on how to accomplish configuring a downstream
> > > broker?
> > >
> >

Re: NIST CVEs for ActiveMQ

[Gary Tully]

for 2 and 3, the fix is in the http endpoint configuration for hawtio
for 1, configuring jolokia.policyLocation is all that is required.
that was not possible in earlier versions of A-MQ.

I don't think any of the above are relevant to activemq 5.


On Thu, 17 Oct 2019 at 12:53, j...@nanthrax.net  wrote:
>
>
> Hi Colm
>
> I will do a review as I'm preparing 5.16.0 and 5.15.11 releases.
>
> Thanks for the reminder.
>
> Regards
> JB
>
> On Thursday, October 17, 2019 13:52 CEST, Colm O hEigeartaigh 
>  wrote:
>  Hi,
>
> I previously posted this to the private list (last year), but I didn't get
> any reply - so maybe I'll have more luck here :-)
>
> I'd like to clear up 3 ActiveMQ CVEs that are reported at NIST, which have
> no "fix" version associated with them. Please give me some feedback on the
> following:
>
> 1) https://nvd.nist.gov/vuln/detail/CVE-2015-5182 (
> https://bugzilla.redhat.com/show_bug.cgi?id=1248809). The redhat bug is
> marked as "WONTFIX", so I'm not sure if this was accepted as a valid issue
> or not?
>
> 2) https://nvd.nist.gov/vuln/detail/CVE-2015-5183. This is reported against
> the HawtIO console for AMQ. If the fix was in HawtIO, and not AMQ, and we
> don't bundle Hawt IO, then the CPE is invalid, as the issue has nothing to
> do with AMQ. Could someone confirm this? Was there any fix made to the AMQ
> codebase for this issue?
>
> 3) https://nvd.nist.gov/vuln/detail/CVE-2015-5184. This is reported against
> the HawtIO console for AMQ. If the fix was in HawtIO, and not AMQ, and we
> don't bundle Hawt IO, then the CPE is invalid, as the issue has nothing to
> do with AMQ. Could someone confirm this? Was there any fix made to the AMQ
> codebase for this issue?
>
> I can communicate the findings with NIST to update the CVEs if I get some
> feedback.
>
> Colm.
>
>
>

Re: [VOTE] Apache ActiveMQ Artemis 2.10.1

[Gary Tully]

+1

build from source, verified basic function and console

On Mon, 23 Sep 2019 at 21:26, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.10.1 Release.
>
> The release contains bug fixes and improvements as you can see on the
> release report:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346078
>
> The commit report:
> https://activemq.apache.org/components/artemis/download/commit-report-2.10.1
>
> Source and binary distribution:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.10.1/
>
> The maven repository:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1198
>
> In case you want to give it a try with the maven repo on examples:
> http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.10.1
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve the release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1
>
>
> --
> Clebert Suconic

Re: [QUESTION] PUSH -f on master

[Gary Tully]

I would not do a push -f, just commit a fix on top. With mirrors in
play it may cause problems.

On Thu, 22 Aug 2019 at 12:34, Clebert Suconic  wrote:
>
> I did a mistake yesterday, and I pushed a commit I wasn't supposed to.
>
> It was a commit only intended to my box, it says "fix"
>
> nothing too wrong with it, but it has some checkstyle errors. which I
> can fix with a later commit.
>
>
> but if I could push -f and remove it it would be better.
>
>
> So, we don't have a way to push -f?
>
>
> Any ideas?
>
>
>
>
> --
> Clebert Suconic

Re: Artemis past releases page breakages

[Gary Tully]

is that step in:
https://github.com/apache/activemq-artemis/blob/master/RELEASING.md


On Thu, 30 May 2019 at 12:29, Robbie Gemmell  wrote:
>
> I've found that the docs/downloads/etc links for recent releases on
> the past releases page are broken nearly every time I have used the
> page over the last couple of years. I've fixed it a bunch of times,
> reported it several times to try and stop it from actually happening,
> and fixed it some more times as it keeps doing so.
>
> It is difficult to understand how the same issue keeps happening
> repeatedly given how trivial the page is to update and how quick/easy
> it is to verify the links while doing so, e.g by hovering over them,
> or actually clicking them like a user might and see them 404 or go the
> wrong place if the files havent been cleared from the mirroring area
> just yet.
>
> As the page is proving so troublesome to maintain in working order, I
> think the per-release content might be better jsut removed and only
> the direct link to the archive parent dir left. Thats where I will be
> going directly in future to save myself the hassle (of noticing the
> page is broken and feeling I should report it or fix it yet again).
>
> Robbie

Re: [VOTE] Apache ActiveMQ Artemis 2.8.0 [rc2]

[Gary Tully]

+1

verified distro built from source artefact

On Thu, 2 May 2019 at 23:47, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.8.0 release.
>
> This is basically a bug fix release, with the addition of the following 
> feature
>
> [ARTEMIS-2306] - Support ActiveMQ5 feature JMSXGroupFirstForConsumer
>
> This also includes this bug fix, which is the reason I decided to
> cancel RC1 and respin 2.8.0:
>
> ARTEMIS-2328 Routing after empty addresses could lead to invalid messages
>
>
> The commit report with a full change list is here:
> http://activemq.apache.org/components/artemis/download/commit-report-2.8.0.html
>
>
> And a release notes from jira:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12345169
>
> Source and binary distributions can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.8.0
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1188
>
> In case you want to give it a try with the maven repo:
> http://activemq.apache.org/components/artemis/documentation/latest/hacking-guide/validating-releases.html
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.8.0
>
>
> I will update the website after the vote has passed.
>
>
>
> [ ] +1 approve the release as Apache Artemis 2.8.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1

Re: [VOTE] Apache ActiveMQ Artemis 2.8.0

[Gary Tully]

respin as nothing has been published yet.

On Wed, 1 May 2019, 06:01 Clebert Suconic, 
wrote:

> I have a question. I have found a critical issue:
>
>
> https://github.com/apache/activemq-artemis/pull/2656/commits/46d550bda25eae609ee874f5f88b28221a141083
>
> It's not a regression on 2.8.0, but a blocker bug on 2.7.0.
>
> Would I be better on cancel 2.8.0 and respin it.. or do a 2.8.1 asap?
>
> On Mon, Apr 29, 2019 at 7:11 AM michael.andre.pearce
>  wrote:
> >
> > +1 have built locally, and run a number of basic flow tests using core
> and amqp.Sent from my Samsung Galaxy smartphone.
> >  Original message From: Francesco Nigro <
> nigro@gmail.com> Date: 27/04/2019  15:50  (GMT+00:00) To:
> dev@activemq.apache.org Subject: Re: [VOTE] Apache ActiveMQ Artemis 2.8.0
> +1Il sab 27 apr 2019, 16:09 Christopher Shannon <
> christopher.l.shan...@gmail.com> ha scritto:> +1>> On Fri, Apr 26, 2019
> at 12:18 PM Timothy Bish  wrote:>> > On 4/25/19 9:48
> PM, Clebert Suconic wrote:> > > I would like to propose an Apache ActiveMQ
> Artemis 2.8.0 release.> > >> > > This is basically a bug fix release, with
> the addition of the following> > feature:> > >> > > [ARTEMIS-2306] -
> Support ActiveMQ5 feature JMSXGroupFirstForConsumer> > >> > > The commit
> report with a full change list is here:> > >> >>
> http://activemq.apache.org/components/artemis/download/commit-report-2.8.0.html>
> > >> > >> > > And a release notes from jira:> > >> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12345169>
> > >> > > Source and binary distributions can be found here:> > >
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.8.0> >
> >> > > The Maven repository is here:> > >> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1186>
> > >> > > In case you want to give it a try with the maven repo:> > >> >>
> http://activemq.apache.org/components/artemis/documentation/latest/hacking-guide/validating-releases.html>
> > >> > >> > > The source tag:> > >> >>
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.8.0>
> > >> > >> > > I will update the website after the vote has passed.> > >> >
> >> > >> > > [ ] +1 approve the release as Apache Artemis 2.8.0> > > [ ] +0
> no opinion> > > [ ] -1 disapprove (and reason why)> > >> > >> > > Here's my
> +1> > >> > +1> >> >> > * Validated signatures and checksums> > * Checked
> for license and notice files> > * Validated source licenses with 'mvn
> apache-rat:check -Prelease'> > * Ran binary broker and tested using Qpid
> JMS example (secured and> > anonymous)> > * Built from source and ran some
> of the tests and all AMQP integration> > tests> >> > --> > Tim Bish> >> >>
>
>
>
> --
> Clebert Suconic
>

Re: [VOTE] Website Update

[Gary Tully]

+1

great work. It looks really fresh and the style is crisp.

On Wed, 27 Mar 2019 at 20:07, Justin Bertram  wrote:
>
> As most of you probably know there's been work underway to update the
> ActiveMQ website for the better part of a year. That work has reached a
> point where it makes sense to vote on whether or not it should replace the
> existing website. The new website is available at:
>
>   http://activemq.apache.org/activemq-website/
>
> All existing links for *ActiveMQ 5.x* content should continue to work as-is.
>
> The source files for the new site are hosted here:
>
>   https://github.com/apache/activemq-website/
>
> This repo includes instructions on how to modify, test, & update the site.
>
>
> [ ] +1 approve the promotion of the new website to be the official ActiveMQ
> website
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1
>
>
> Justin

Re: Failover Transport - send timeout not working

[Gary Tully]

note the last comment on AMQ-.
Check the logs, your failover connection is probably trying to
reconnect forever. use maxReconnectAttempts=x to limit that.

On Mon, 25 Mar 2019 at 12:43, tal.cohen2  wrote:
>
> Hi .
> we are using activemq v.5.15.8 broker and client. (jdk 1.8)
> when configuring broker jms url in the client side  , this way :
> 
> 
> 
> 
>  value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
>  value=failover://(tcp://${ACTIVEMQ_HOSTNAME}:61616?daemon=true)?b>timeout=6"/*>
>
>
> after the service is running and connected to the activemq , we shut down
> activemq broker and try to send message. on v.5.8 the operation timeout
> after the defined time . on this version it never timeout even with this
> paramter .
> someone can give us a soultion ?
>
>
>
> Best Regards,
> Tal
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

Re: [VOTE] Apache ActiveMQ Artemis 2.7.0

[Gary Tully]

+1

On Thu, 14 Mar 2019 at 19:28, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis 2.7.0 release.
>
> This is a big release, with 526 Commits, over 291 JIRAs overall. I'm
> really proud being part of this project involving many companies and
> distinct great developers. The commit list alone shows what I mean:
>
> http://activemq.apache.org/artemis/commit-report-2.7.0.html
>
> And this is the JIRA release report:
> http://activemq.apache.org/artemis/release-notes-2.7.0.html
>
> Source and binary staged repository is here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.7.0/
>
> The Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1182
>
> In case you want to give it a try with the maven repo on examples:
> http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html
>
> The source tag:
> https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.7.0
>
>
> I will update the website after the vote has passed.
>
>
> [ ] +1 approve the release as Apache ActiveMQ Artemis 2.7.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1

Re: [VOTE] ActiveMQ Artemis Native 1.0.0 (RC2)

[Gary Tully]

+1

On Mon, 4 Mar 2019 at 01:25, Clebert Suconic  wrote:
>
> I would like to propose an Apache ActiveMQ Artemis Native 1.0.0
> release. This is a second re-spin.
>
> This is a sub component of ActiveMQ Artemis Native,
>
> Source distribution can be found here:
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/1.0.0/
>
> Maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1179
>
>
> The source tag:
> https://gitbox.apache.org/repos/asf?p=activemq-artemis-native.git;a=tag;h=refs/tags/1.0.0
>
>
>
> Notice this is a sub component of ActiveMQ Artemis, and the release
> notes will be part of the main component. And also, the binary here is
> distributed through maven.
>
>
> [ ] +1 approve the release as Apache Artemis 2.4.0
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here's my +1
>
>
> --
> Clebert Suconic

Re: [Discuss] Refactoring KahaDBStore class

[Gary Tully]

Hey Arthur,
I am not asserting that they need to be small.
I am pointing out that they currently are small changes; there has
been no significant refactor to date; it is all very conservative.
Release 5.16.0 as a line in the sand, then move code around to make it
better etc.. go for it.

I know too well it is not perfect and I think it is great that there
is interest in making it better.

On Wed, 28 Nov 2018 at 16:22, Arthur Naseef  wrote:
>
> Hey Gary - I agree that these changes belong on a minor version increase.
>
> What I don't understand is the assertion that the changes between 5.15.x
> and 5.16.0 need to be small.  Given that the minor version bump can mean
> significant changes, as long as they are backward compatible, I see no
> reason to adhere to a small set of changes between 5.15.x and 5.16.0.  Add
> to that fact that ActiveMQ's minor releases are sometimes really major
> changes (i.e. include breaking changes), and that makes even less sense.
>
> Is there something more to this that perhaps I'm missing?
>
> Making the code more maintainable by the community, as ActiveMQ is an
> Apache *community* project, is the goal.  As for it being maintained for 7
> years, that's great.  However, I'm sure you'll agree it's not perfect, and
> community improvements are welcome.
>
> Art
>
>
> On Wed, Nov 28, 2018 at 3:30 AM Gary Tully  wrote:
>
> > Jamie,
> > you are missing my point. it is a tradeoff plain and simple. easier to
> > maintain for who? It has been carefully maintained for more than 7
> > years.
> > Do refactoring at the beginning of a release cycle, not at the end.
> > diffs between 5.15.x and 5.16 will be meaningless otherwise.
> > push out 5.16.0, which has loads of incremental (non refactored) small
> > changes. Then refactor away on master for 5.17.0 and make it better in
> > any way that works for the future and for you.
> > On Tue, 27 Nov 2018 at 15:34, Jamie G.  wrote:
> > >
> > > Hi Gary,
> > >
> > > To address your concerns:
> > >
> > > 1. The code is being cleaned up, not completely rewritten.  This is
> > > making it easier to maintain over the monolithic classes.  It's also
> > > why it was brought to the community… to review it and be sure the
> > > changes are just cleaning it up.  There was no intent to change the
> > > logic for the reason that you suggested.
> > >
> > > 2. I answered above, its easy on the back port as we can just make it
> > > a part of 5.15.9 (too my understanding the community supports master
> > > and the last release branch).  There are little differences between 16
> > > and 15.9 in the KahaDB realm.  So placing it in 15.9 does not change
> > > any way it operates or works.  It only cleans up the readability of
> > > the code.
> > >
> > >
> > > "A dream you dream alone is only a dream. A dream you dream together
> > > is reality."
> > >
> > > ― John Lennon
> > >
> > >
> > > Cheers,
> > > Jamie
> > > On Tue, Nov 27, 2018 at 8:29 AM Gary Tully  wrote:
> > > >
> > > > Hi Jamie G,
> > > > There are a few trade offs to consider:
> > > >  1) those familiar with the code will have to reacquaint themselves
> > > > with anything that is refactored
> > > >  2) backporting fixes will be more difficult when the code structure
> > changes
> > > >
> > > > Of the two, I think #2 is more critical.
> > > >
> > > > On #1:
> > > > context builds up over time and code structure is an integral part of
> > > > that, for better or for worse.
> > > > Switching context is not something us humans like doing, most
> > > > especially when stability is a key concern.
> > > >
> > > > Refactoring with purpose (for a new feature) can be great, doing it at
> > > > this stage for readability may be less great.
> > > >
> > > > Mr. W. B. Yeats put it nicely: "tread softly because you tread on my
> > dreams"
> > > >
> > > > s/dreams/mental model/
> > > > On Mon, 26 Nov 2018 at 19:44, Christopher Shannon
> > > >  wrote:
> > > > >
> > > > > I didn't say I definitely wouldn't support it but I just want to
> > make sure
> > > > > we are careful and the benefits of the refactor (in this case
> > improved
> > > > > maintainability) are really going to be worth the risk specifically
> > because
> > > > > of the comp

Re: [Discuss] Refactoring KahaDBStore class

[Gary Tully]

Jamie,
you are missing my point. it is a tradeoff plain and simple. easier to
maintain for who? It has been carefully maintained for more than 7
years.
Do refactoring at the beginning of a release cycle, not at the end.
diffs between 5.15.x and 5.16 will be meaningless otherwise.
push out 5.16.0, which has loads of incremental (non refactored) small
changes. Then refactor away on master for 5.17.0 and make it better in
any way that works for the future and for you.
On Tue, 27 Nov 2018 at 15:34, Jamie G.  wrote:
>
> Hi Gary,
>
> To address your concerns:
>
> 1. The code is being cleaned up, not completely rewritten.  This is
> making it easier to maintain over the monolithic classes.  It's also
> why it was brought to the community… to review it and be sure the
> changes are just cleaning it up.  There was no intent to change the
> logic for the reason that you suggested.
>
> 2. I answered above, its easy on the back port as we can just make it
> a part of 5.15.9 (too my understanding the community supports master
> and the last release branch).  There are little differences between 16
> and 15.9 in the KahaDB realm.  So placing it in 15.9 does not change
> any way it operates or works.  It only cleans up the readability of
> the code.
>
>
> "A dream you dream alone is only a dream. A dream you dream together
> is reality."
>
> ― John Lennon
>
>
> Cheers,
> Jamie
> On Tue, Nov 27, 2018 at 8:29 AM Gary Tully  wrote:
> >
> > Hi Jamie G,
> > There are a few trade offs to consider:
> >  1) those familiar with the code will have to reacquaint themselves
> > with anything that is refactored
> >  2) backporting fixes will be more difficult when the code structure changes
> >
> > Of the two, I think #2 is more critical.
> >
> > On #1:
> > context builds up over time and code structure is an integral part of
> > that, for better or for worse.
> > Switching context is not something us humans like doing, most
> > especially when stability is a key concern.
> >
> > Refactoring with purpose (for a new feature) can be great, doing it at
> > this stage for readability may be less great.
> >
> > Mr. W. B. Yeats put it nicely: "tread softly because you tread on my dreams"
> >
> > s/dreams/mental model/
> > On Mon, 26 Nov 2018 at 19:44, Christopher Shannon
> >  wrote:
> > >
> > > I didn't say I definitely wouldn't support it but I just want to make sure
> > > we are careful and the benefits of the refactor (in this case improved
> > > maintainability) are really going to be worth the risk specifically 
> > > because
> > > of the component being touched.  Too often things get committed and then
> > > issues are uncovered with the patch later that were missed.
> > >
> > > Some parts of the broker are critical and this is one of them because a 
> > > bug
> > > that corrupts a store could lead to losing lots of production data which 
> > > is
> > > a very different type of bug than a random web console bug or transport
> > > error that just causes an error with a single client or with a single
> > > message. Granted the risk of a critical bug being introduced with a
> > > refactor like this is not very high but if there is one it could have
> > > pretty bad consequences.
> > >
> > > Now all that being said ... as long as we are careful to make sure all
> > > tests pass and have a few people thoroughly review it (such as Gary who 
> > > has
> > > the most experience out of anyone in KahaDB) then I would +1 the change 
> > > for
> > > a 5.16.0 release.
> > >
> > > On Mon, Nov 26, 2018 at 2:07 PM Arthur Naseef  wrote:
> > >
> > > > Improving the existing code is a great goal.
> > > >
> > > > While cleaning up code is nice KahaDB has gotten pretty stable over the
> > > > > years and doing a bunch of refactoring just opens it up to new bugs 
> > > > > that
> > > > > have to be fixed.  Fixing bugs is not a problem however I tend to be 
> > > > > more
> > > > > sensitive to store related changes because of the possible data loss 
> > > > > or
> > > > > corruption issues to production data that can occur from store bugs vs
> > > > some
> > > > > other random bug in the broker.
> > > > >
> > > >
> > > > I understand the desire to avoid the risk of introducing bugs.  
> > > > However, as
> > > > long as the project is active

Re: [Discuss] Refactoring KahaDBStore class

[Gary Tully]

Hi Jamie G,
There are a few trade offs to consider:
 1) those familiar with the code will have to reacquaint themselves
with anything that is refactored
 2) backporting fixes will be more difficult when the code structure changes

Of the two, I think #2 is more critical.

On #1:
context builds up over time and code structure is an integral part of
that, for better or for worse.
Switching context is not something us humans like doing, most
especially when stability is a key concern.

Refactoring with purpose (for a new feature) can be great, doing it at
this stage for readability may be less great.

Mr. W. B. Yeats put it nicely: "tread softly because you tread on my dreams"

s/dreams/mental model/
On Mon, 26 Nov 2018 at 19:44, Christopher Shannon
 wrote:
>
> I didn't say I definitely wouldn't support it but I just want to make sure
> we are careful and the benefits of the refactor (in this case improved
> maintainability) are really going to be worth the risk specifically because
> of the component being touched.  Too often things get committed and then
> issues are uncovered with the patch later that were missed.
>
> Some parts of the broker are critical and this is one of them because a bug
> that corrupts a store could lead to losing lots of production data which is
> a very different type of bug than a random web console bug or transport
> error that just causes an error with a single client or with a single
> message. Granted the risk of a critical bug being introduced with a
> refactor like this is not very high but if there is one it could have
> pretty bad consequences.
>
> Now all that being said ... as long as we are careful to make sure all
> tests pass and have a few people thoroughly review it (such as Gary who has
> the most experience out of anyone in KahaDB) then I would +1 the change for
> a 5.16.0 release.
>
> On Mon, Nov 26, 2018 at 2:07 PM Arthur Naseef  wrote:
>
> > Improving the existing code is a great goal.
> >
> > While cleaning up code is nice KahaDB has gotten pretty stable over the
> > > years and doing a bunch of refactoring just opens it up to new bugs that
> > > have to be fixed.  Fixing bugs is not a problem however I tend to be more
> > > sensitive to store related changes because of the possible data loss or
> > > corruption issues to production data that can occur from store bugs vs
> > some
> > > other random bug in the broker.
> > >
> >
> > I understand the desire to avoid the risk of introducing bugs.  However, as
> > long as the project is active and maintained, that really isn't a valid
> > approach to its maintenance overall.
> >
> > So that leads us to the question of risk mitigation.  Build-time tests are
> > an industry standard, and ActiveMQ certainly has a large number of such
> > tests.  Code reviews are another best-practice, and there are multiple
> > individuals looking at these code changes now.  More are always welcome,
> > and access is certainly not a problem!
> >
> > If there are specific concerns within the code changes, let's discuss
> > them.  It'll be great to have actual technical discussions!
> >
> > As for the concern that this is the broker's storage, similar arguments
> > could be made for just about any part of the code.  Reliable handling of
> > messages is ActiveMQ's core benefit to its users.
> >
> >
> >
> > > FWIW, the current community goal is for ActiveMQ Artemis to become
> > ActiveMQ
> >
> > 6.x when acceptable feature parity is reached (which is actively being
> > > worked on).
> > >
> >
> > Whether Artemis will eventually become ActiveMQ 6.x is not pertitent to
> > this discussion.  Let's not open that discussion as part of this technical
> > code conversation.
> >
> > Making the existing code base, which has heavy usage in the industry, more
> > maintainable is always a good goal to achieve.  And having more folks in
> > the community engaging in working on the project can only benefit the
> > entire community regardless of the long-term destination.
> >
> > Art
> >
> >
> >
> >
> > On Mon, Nov 26, 2018 at 10:22 AM Justin Bertram 
> > wrote:
> >
> > > FWIW, the current community goal is for ActiveMQ Artemis to become
> > ActiveMQ
> > > 6.x when acceptable feature parity is reached (which is actively being
> > > worked on).
> > >
> > >
> > > Justin
> > >
> > >
> > > On Mon, Nov 26, 2018 at 11:01 AM Jamie G. 
> > > wrote:
> > >
> > > > The idea here is to ensure that it’s development and maintenance
> > > > moving forward is easier as we work to make it better in the future.
> > > >
> > > > KahaDB currently has massive classes (KahaDBStore, MessageDatabase)
> > > > and code base and is extremely hard to follow.  My desire to do this
> > > > was to make this so we could make the continued maintenance easier and
> > > > also make it more inviting to improvements.  The unit tests all pass,
> > > > so as long as we have a good solid testing coverage, the risks are not
> > > > huge.  If a bug appears to be introduced, than we may have 

Re: [discussion] About blocking producers

[Gary Tully]

There may be two different use cases here;
1) the pause/resume use case, where it makes some sense to leave producers
active stop reading/deny credit/buffer etc; the corollary to the pause
consumers
2) the take down for maintenance case, where it would be nice to drain the
broker.
 In the past, users have tackled the "maintenance" use case with
separate acceptors, one for producers and one for consumers. with the
ability to disable an acceptor via a management operation. That is not
ideal b/c it requires cooperation with the applications to use the correct
acceptors etc.
   However it is a coarse grained option that is a step to shutdown, a one
way step that won't be undone via resume. That can more easily be
implemented with a management op that kills off producers and blocks all
send operations with some deny interceptor (along the lines of the
authorisation interceptors). something like shutdownSenders

If the use case is more like shutdownSenders keeping it coarse (on or off
for the entire server) will be best.

For the pause/resume case it gets tricky;
 - for example if the same connection is used for producing and consuming,
any exception can be fatal for the connection, causing retries etc and
looping.
 - blocking will only work for sync send operations and async operations
may accumulate. It may require protocol specific smarts.
 - same for of credit, only where flow control is respected by the client.

I guess my point is that pause/resume may not be the way to go if the use
case is actually shut down for maintenance.


On Tue, 16 Oct 2018 at 04:19 Howard Gao  wrote:

> Hi guys,
>
> I'm working on this story and I'd like to hear your thoughts.
>
> The Jira: https://issues.apache.org/jira/browse/ARTEMIS-2097
>
> This is to provide a functionality of the broker to block on producers so
> that user can consume all the existing messages (for maintaining their
> servers for example), regardless of how the address setting's address full
> policy is configured. The unblock
> functionality should also be provided to complete this feature.
>
> Here is my current implementation:
> https://github.com/apache/activemq-artemis/pull/2371
>
> The idea is to keep a list of blocked/unblock addresses set by the user.
> Any incoming messages will be checked against the list and if its address
> is blocked, it will be rejected and an exception will be thrown to the
> clients.  It works for all types of clients (core, openwire, jms, mqtt
> etc).
>
> Any comments are welcome.
>
> Thanks
> Howard
>

Re: AMQ-7006

[Gary Tully]

doing many thousand iterations of the problematic code path using external
api and verifying the vm memory usage after a few gc cycles usually
identifies a memory leak.
see an example here:
https://github.com/apache/activemq/blob/57795bafcea290c6879bb288822435c480a9212d/activemq-unit-tests/src/test/java/org/apache/activemq/bugs/AMQ4930Test.java#L120

it is not very elegant, you have to leave some wiggle room, but it is
effective.

On Tue, 10 Jul 2018 at 06:37 Avikash Mishra  wrote:

> Hi Gary,
>
> The issue I’m trying to fix is a memory leak in ProtocolConverter.java
> I can’t seem to find any tests that use this file or the
> StompSubscription.java file.
>
> The problem is the pedingAcks array in ProtocolConverter.java is not
> getting cleaned up when we ACK in client mode. The garbage collector does’t
> clean this up ether.
>
> All the tests are only checking the responses and not the internal
> workings.
>
> Do you know how I could go about writing a test for this case?
>
> Thanks
> Avikash
> > On 4/07/2018, at 10:07 PM, Gary Tully  wrote:
> >
> > see: org.apache.activemq.transport.stomp.Stomp12Test
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=blob_plain;f=activemq-stomp/src/test/java/org/apache/activemq/transport/stomp/Stomp12Test.java;hb=HEAD
> >
> > On Tue, 3 Jul 2018 at 23:47 Avikash Mishra  wrote:
> >
> >> Hi Gary,
> >>
> >> Thanks for your reply.
> >> Is there any tests I can leverage off? I need to test the
> >> onStompMessageAck method in StompSubsrcription.java class.
> >> Or if you can point me in the right direction.
> >>
> >> Thanks
> >> Avikash
> >>> On 3/07/2018, at 9:14 PM, Gary Tully  wrote:
> >>>
> >>> please add a unit test that will demonstrate the problem and fix and
> also
> >>> protect it.
> >>>
> >>> On Tue, 3 Jul 2018, 06:04 Avikash Mishra,  wrote:
> >>>
> >>>> Hi there,
> >>>>
> >>>> We have been having the issue mentioned here
> >>>> https://issues.apache.org/jira/browse/AMQ-7006
> >>>>
> >>>> I have attached a patch. Please review and get back to me asap. We
> have
> >>>> tested this on our test environment and all seems to work fine and
> fixes
> >>>> the issue we are having. Would like to create my own fork and commit
> >> please.
> >>>>
> >>>> Thanks
> >>>> Avikash
> >>
> >>
>
>

Re: AMQ-7006

[Gary Tully]

see: org.apache.activemq.transport.stomp.Stomp12Test
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=blob_plain;f=activemq-stomp/src/test/java/org/apache/activemq/transport/stomp/Stomp12Test.java;hb=HEAD

On Tue, 3 Jul 2018 at 23:47 Avikash Mishra  wrote:

> Hi Gary,
>
> Thanks for your reply.
> Is there any tests I can leverage off? I need to test the
> onStompMessageAck method in StompSubsrcription.java class.
> Or if you can point me in the right direction.
>
> Thanks
> Avikash
> > On 3/07/2018, at 9:14 PM, Gary Tully  wrote:
> >
> > please add a unit test that will demonstrate the problem and fix and also
> > protect it.
> >
> > On Tue, 3 Jul 2018, 06:04 Avikash Mishra,  wrote:
> >
> >> Hi there,
> >>
> >> We have been having the issue mentioned here
> >> https://issues.apache.org/jira/browse/AMQ-7006
> >>
> >> I have attached a patch. Please review and get back to me asap. We have
> >> tested this on our test environment and all seems to work fine and fixes
> >> the issue we are having. Would like to create my own fork and commit
> please.
> >>
> >> Thanks
> >> Avikash
>
>

Re: AMQ-7006

[Gary Tully]

please add a unit test that will demonstrate the problem and fix and also
protect it.

On Tue, 3 Jul 2018, 06:04 Avikash Mishra,  wrote:

> Hi there,
>
> We have been having the issue mentioned here
> https://issues.apache.org/jira/browse/AMQ-7006
>
> I have attached a patch. Please review and get back to me asap. We have
> tested this on our test environment and all seems to work fine and fixes
> the issue we are having. Would like to create my own fork and commit please.
>
> Thanks
> Avikash

Re: [VOTE] Apache ActiveMQ 5.15.3

[Gary Tully]

+1

On Mon, 29 Jan 2018 at 21:58 Timothy Bish  wrote:

> On 01/29/2018 08:59 AM, Christopher Shannon wrote:
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.15.3 release and it's ready for a vote.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12341947
> >
> > You can get the release artifacts here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.3/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1154/
> >
> > Source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=bd4285d3aae04cb3f2dae8d0689b59598a844192
> >
> > Please vote to approve this release.  The vote will remain open for 72
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.15.3
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
> +1
>
> * Validated signatures and checksums
> * Checked for License and Notice files
> * Ran mvn apache-rat:check and no missing headers found.
> * Ran broker from the binary archive and exercised the webconsole
> * Built from source and ran the sanity tests, plus AMQP, STOMP and
> Karaf-itests.
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [DISCUSS] Graduate Artemis as TLP

[Gary Tully]

I don't agree with the premise of this discussion at all. It seems to be
born out of a your replies to your self in an echo chamber.

What are the adverse consequences in providing a robust migration path for
5.x users to activemq 6 *within* the ActiveMQ project?

The preceding vote did not have an implicit "now" in the title, it was
future focused.
In hind sight the title could have been:

 "When it's ready, Artemis becomes ActiveMQ 6"

I think there is consensus forming around that.

On Thu, 7 Dec 2017 at 02:05 Hadrian Zbarcea  wrote:

> Since Artemis has a kernel of developers had a few releases, and
> hard-core Artemis believers want to be in control of their own destiny
> and they believe the project can be sustained on its own merits and have
> it's own awesome site, I propose that Artemis form its own PMC and start
> a vote to graduate as TLP.
>
> Thoughts?
> Hadrian
>
>
>

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Gary Tully]

Hadrian,
inline

On Wed, 6 Dec 2017 at 15:56 Hadrian Zbarcea <hzbar...@gmail.com> wrote:

> Gary,
>
> That is precisely what folks vote -1 against.

That is what I wish to clarify but I presume you speak for your self here.


> I hope you are not
> implying that the -1s should not be counted because you believe the -1s
> where for a different reason.
>
your hope has come true, there is no such implication.


> Surely you must remember the same issue being raised and a vote called
> some 2 years ago if my memory serves me well (I can look it up if
> necessary). Exactly same vote, exactly same statement of intent. You
> know how that went.

What changed to start it all over again?
>
> Artemis has got OpenWire support, a plugin framework and a console.
Features that mirror 5.x.
There is a bunch of artemis activity on the user list and the the dev list.
Apollo work has stoped. The activemq website still needs love and the
activemq project clearly needs a future direction beyond 5.x


Can we agree that this vote is a PR/marketing play, not technology?

I agree marketing has a part in this, marketing the ActiveMQ brand as a
live project and reflecting the good work that the artemis devs are doing.
And sorting out or website has a huge part to play in that.
But I cannot agree that this is not about technology. As some one who has
intimate knowledge of 5.x I can categorically say that it is not the basis
for future development. It does what it does really well but making change
to that code base and not breaking existing users is very difficult. In a
way it is a victim of its own success, but a victim none the less.


> This
> is not a vote for a controversial feature people can't agree on, nor on
> accepting an external contribution, nor a release vote. What is it?
>
> It is about getting some consensus on a future. Nearly 3years have passed
since we accepted the hornetq donation in good faith. Contributions to 5.x
have dwindled and contributions to artemis have grown.


> Some see Artemis as the future of ActiveMQ. Other gray beards see it as
> a project that needs to get more adoption an prove itself before it's
> clear that it can be the evolution of the current 5.x version that
> serves the market very well (proven yet again by AWS). No consensus yet.
>
> We cannot predict the future, we can only make it happen and I see the
energy around artemis provides a future path. The alternative is more
stagnation.

/gary.


> On 12/06/2017 10:45 AM, Gary Tully wrote:
> > On Wed, 6 Dec 2017 at 14:34 Bruce Snyder <bruce.sny...@gmail.com> wrote:
> >
> >> My understanding of this vote is that it is a decision to officially
> state
> >> the intent of the ActiveMQ project to eventually release Artemis as
> >> ActiveMQ 6.x and get moving in that direction to identify and address
> >> concerns.
> >
> >
> > This was also my understanding and what I voted for.
> > Maybe the intent of the vote needs to be clarified.
> >
> > is this what folks voted against?
> >
> > gary.
> >
>

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Gary Tully]

On Wed, 6 Dec 2017 at 14:34 Bruce Snyder  wrote:

> My understanding of this vote is that it is a decision to officially state
> the intent of the ActiveMQ project to eventually release Artemis as
> ActiveMQ 6.x and get moving in that direction to identify and address
> concerns.


This was also my understanding and what I voted for.
Maybe the intent of the vote needs to be clarified.

is this what folks voted against?

gary.

Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6

[Gary Tully]

+1

On 5 Dec 2017 7:59 am, "Francesco Nigro"  wrote:

> +1 (non-binding)
>
>
> Il giorno mar 5 dic 2017 alle ore 04:17 Francois Papon <
> francois.pa...@openobject.fr> ha scritto:
>
> > +1 (non-binding)
> >
> > Francois
> >
> >
> > Le 05/12/2017 à 00:32, Clebert Suconic a écrit :
> > > Following on from the discussion, "[DISCUSS] Confusion surrounding the
> > > ActiveMQ project roadmap"
> > >
> > > linked here for convenience :
> > > -
> > http://activemq.2283324.n4.nabble.com/DISCUSS-Confusion-
> surrounding-the-ActiveMQ-project-roadmap-td4732935.html
> > > -
> > http://activemq.2283324.n4.nabble.com/Re-DISCUSS-
> Confusion-surrounding-the-ActiveMQ-project-roadmap-td4733148.html
> > >
> > >
> > > I would like to propose a vote on ActiveMQ Artemis mainline becoming
> > ActiveMQ 6.
> > >
> > > [+1] -  agree
> > > [-1] . - disagree and provide some reason
> > > [0] - neutral but go ahead
> > >
> > > This vote will be open until Thursday, Dec 07 by the end of the day.
> > >
> > > Here is my +1 (PMC) vote.
> >
> >
>

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Gary Tully]

I think ActiveMQ needs a roadmap for sure and I think Artemis is the future
for a bunch of technical reasons.

Without a clear direction going forward we will loose adoption because I
don't know anyone who likes making a choice.

If you are an existing ActiveMQ user there should be a clear path forward.
If you are peeking at ActiveMQ for the first time you should find a vibrant
project.

To avoid confusion, moving forward with ActiveMQ6 looks like the simplest
solution.

That implies migration but also a step migration because there is a new
architecture.

I would propose that the Artemis mainline becomes ActiveMQ 6.x.
Continuing the frequent release cadence of Artemis, any outstanding
migration issues can be promptly catalogued and addressed.

Gary.

On Thu, 23 Nov 2017 at 05:41 Clebert Suconic 
wrote:

> The documentation does talk about those things.  Migration guide is just a
> quick guide on how to migrate but it does not replace the documentation.
>
> There was some good suggestions you made here as to tools to move
> configuration automatically.   But that’s not a requirement to make any
> progress. We won’t ever get anuwhere if we aim for perfection as there will
> always be space for more.  Nothing in life is perfect.
>
> Tools and features I think it’s orthogonal to the discussion about the
> direction.
>
> On Wed, Nov 22, 2017 at 10:49 PM Tim Bain  wrote:
>
> > On Nov 21, 2017 3:00 PM, "Clebert Suconic" 
> > wrote:
> >
> > > Another thought - having both brokers long term seems redundant as
> there
> > is
> > > a huge amount of overlap, and I believe the intent (please correct me
> if
> > > this is wrong) is eventually to have Artemis superset all of the *key*
> > > functionality from AMQ 5.x.
> >
> > I think all the features are covered at this point. The one exception
> > is Retroactive Consumers.. however this could be done with browsers
> > and paging.
> > It still on my personal list of improvements I want to make. I could
> > make it happen sooner with some demand.. So I don't think it blocks
> > anything going forward.
> >
> > The other feature that has been brought a lot of times.. is virtual
> > topics.. however with the address model in Artemis.. it's not needed..
> > as virtual topic was a way to emulate a queue within a topic, which is
> > pretty much what we have on the address model.
> >
> > >
> > > In order to facilitate a move, users of AMQ 5.x are going to need a
> > smooth
> > > transition.  Note that I don't mean to say it has to be seamless, just
> > that
> > > it has to be smooth - easy enough to understand and execute.
> >
> > >
> > > Let me pose some questions here that may help move this forward:
> > >
> > >   - Do we know what it takes to migrates customers from AMQ 5.x to
> > Artemis?
> >
> >
> > https://activemq.apache.org/artemis/migration.html
> >
> > ^^ It's in good shape IMO already.
> >
> >
> > That guide has lots of good information, but it explicitly punts on the
> > question of how to migrate a cluster that has existing unconsumed
> messages.
> > Does a migration guide for that subject already exist? If so, let's link
> to
> > it; if not, I don't think we're ready yet.
> >
> > There are two possible ways to migrate when messages are pre-existing:
> > either you take an outage and convert the messages store somehow, or you
> > network the old and new brokers but have clients use only the new broker,
> > and you configure the brokers so that all of the messages flow from the
> old
> > broker to the new one without downtime. Note that the second approach
> won't
> > migrate scheduled messages, so it might be necessary to use a hybrid
> > approach depending on the use case. Are Artemis and ActiveMQ capable of
> > being networked together to allow the second approach? I've always
> assumed
> > that it could be done since Artemis supports OpenWire, but I've never
> heard
> > anyone say it was possible. I think we'd want the migration guide to
> talk a
> > bit about options for how to perform the actual operational migration,
> not
> > just how to configure Artemis to make it behave similarly to ActiveMQ or
> > HornetQ (though that's important too, and the guide does that well).
> Also,
> > the guide should talk about what happens if a user wants to migrate when
> > their broker contains more messages than will fit into Artemis's memory,
> > since it's possible that some users might be in that situation.
> (Hopefully
> > not many people, though!)
> >
> > Also, I don't see any discussion in the guide of SSL transports even
> though
> > a number of other protocols (both network and application) are mentioned,
> > so that looks like something else that should be added.
> >
> > >   - Do we have a comprehensive list of features that will remain
> > supported?
> > >   - Do we have a list of features that will not be retained?
> >
> > We had a few discussions in the past... there could be minor 

Re: Dead Letter Queue Expiry

[Gary Tully]

That could maybe filter into a bounded queue feature. If the dlq is bounded
by time, if head of the queue is X milliseconds old drop it.
A bounded queue, bounded by size, memory usage, disk usage or time is a
very useful concept.

On Tue, 14 Nov 2017 at 19:37 Clebert Suconic 
wrote:

> Feel free to add a JIRA though.
> It’s probably an easy fix.
>
> On Tue, Nov 14, 2017 at 1:20 PM Justin Bertram 
> wrote:
>
> > The functionality you're looking for isn't directly supported in Artemis,
> > although you could probably solve the issue with a broker plugin [1].
> Feel
> > free to open a "New Feature" JIRA [2] if you like.
> >
> >
> > Justin
> >
> > [1] http://activemq.apache.org/artemis/docs/latest/broker-plugins.html
> > [2] https://issues.apache.org/jira/projects/ARTEMIS
> >
> > On Tue, Nov 14, 2017 at 12:12 PM, cnadukula  wrote:
> >
> > > Hi
> > >
> > > We are using apache artemis version : 2.3.0 and wanted to see if there
> is
> > > any setting that we can provide so after a certain period the dead
> Letter
> > > queue is purged automatically? I noticed Apache ActiveMQ has a setting
> > > called   where we can discard DLQ messages after a
> > > certain period of time or set an expiry date for those messages. Is
> > there a
> > > way we can do that for Artemis, perhaps a setting in broker.xml?
> > >
> > > thanks,
> > > Chandra
> > >
> > >
> > >
> > > --
> > > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
> > > f2368404.html
> > >
> >
> --
> Clebert Suconic
>

Re: [VOTE] Apache ActiveMQ 5.15.2

[Gary Tully]

+1

On Tue, 17 Oct 2017 at 21:49 Timothy Bish  wrote:

> +1
>
> * Checked each archive to License and Notice files
> * Validated signatures and checksums
> * Ran the binary broker build on linux, checked web console and sent
> some messages using Qpid JMS example
> * Built from source and ran the sanity test profile tests
> * Built Qpid JMS using the staged bits and ran it's tests against ActiveMQ
> * Checked using the maven apache-rat:check goal for files missing any
> license headers.
>
> On 10/17/2017 10:37 AM, Christopher Shannon wrote:
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.15.2 release and it's ready for a vote.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12341669
> >
> > You can get the release artifacts here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.2/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1151/
> >
> > Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=9e595d8674456810ee3bd2d4a9920ed8b680937b
> >
> > Please vote to approve this release.  The vote will remain open for 72
> hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.15.2
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [VOTE] Apache ActiveMQ 5.15.1

[Gary Tully]

the activemq-amqp-client karaf feature was broken upstream and in the
release due to a new netty dependency.
see: https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=33b52b5

maybe that fix should be pulled in - the ActiveMQAMQPBrokerFeatureTest
regressed.


On Mon, 25 Sep 2017 at 16:47 Timothy Bish  wrote:

> On 09/25/2017 10:00 AM, Christopher Shannon wrote:
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.15.1 release and it's ready for a vote.
> > This release uses the new process based on the discussion from last
> > week.
> >
> > The list of resolved issues is here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12341031
> >
> > You can get the release artifacts here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.1/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1149/
> >
> > Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=37227fbf8bf2308d45dddb169483864007ef5560
> >
> > Please vote to approve this release.  The vote will remain open for 72
> hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.15.1
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
> +1
>
> * Checked validated signatures and checksums
> * Checked for license and notice files in the archives
> * Extracted binary broker archive and ran the broker, tested against
> Qpid JMS example and exercised the Web Console.
> * Built from source and ran the sanity test profile as well as the full
> AMQP test suite.
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: Oracle - delivered Messages remain in ACTIVEMQ_MSGS

[Gary Tully]

That DELETE statement is for durable topic subscribers. For queues, a
delete is done when the message is acked, does you application acknowledge
receipt of the message after onDelivery or is the session auto ack?

On Thu, 10 Aug 2017 at 23:02 Heike Potter  wrote:

> We are running an application on centos with tomcat 8.0.28, java 1.8 and
> activemq 5.13.4
> For persistency we are using Oracle 11.2
>
> We have 3 queues with several producers and consumers.
>
> From time to time we have the effect that messages remain in the
> ACTIVEMQ_MSGS table in the oracle database though these messages are
> consumed correctly (we get correct results).
> These messages never get removed from the ACTIVEQ_MSG table. Our problem
> occurs, when we restart activemq,
> because these messages are redelivered.
>
> We checked the activemq-Logfile, the enqueue/dequeue counters for the
> queues
> are identical.
> What is astonishing us is the following logged DELETE command:
> ---
> 2017-06-09 10:24:58,281 [ Adaptor Task-2] DEBUG JournalPersistenceAdapter
> - Checkpoint started.
> 2017-06-09 10:24:58,291 [ Adaptor Task-2] DEBUG JDBCPersistenceAdapter
> - Cleaning up old messages.
> 2017-06-09 10:24:58,291 [ Adaptor Task-2] DEBUG DefaultJDBCAdapter
> - Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE (PRIORITY=? AND ID <=
> ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID)   FROM ACTIVEMQ_ACKS WHERE
> ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINERAND
> ACTIVEMQ_ACKS.PRIORITY=?)   )
> 2017-06-09 10:24:58,300 [ Adaptor Task-2] DEBUG DefaultJDBCAdapter
> - Deleted 0 old message(s) at priority: 0
> 2017-06-09 10:24:58,300 [ Adaptor Task-2] DEBUG JDBCPersistenceAdapter
> - Cleanup done.
> 2017-06-09 10:24:58,300 [ Adaptor Task-2] DEBUG JournalPersistenceAdapter
> - Checkpoint done.
> ---
> Though we have entries in ACTIVEMQ_MSGS we do not have entries in the
> ACTIVEMQ_ACKS table, so if I understand it correctly the statement above
> can
> never remove any records.
>
> Here is our configuration file:
> ---
>xmlns="http://activemq.apache.org/schema/core;>
>
> 
>  dataDirectory="${activemq.data}/activemq-data" dataSource="#oracle-ds"/>
> 
>
>
> 
> 
> uri=tcp://ourhost>:8016?transport.trace=falsetransport.soTimeout=6keepAlive=true"/>
> 
>
>   
>
>  destroy-method="close">
>  
>   value=jdbc:oracle:thin:@ourhost2>:1521/"/>
>  
>  
>  
>
>
> ---
>
> And a code snippet:
> 
> public void onMessage(final Message message, final Session session) {
> try {
> _log.debug("OmqListener.On Message Beginn");
> ObjectMessage om = (ObjectMessage) message;
> Object obj = om.getObject();
> if (obj instanceof OutMessage) {
> OutMessage ome = (OutMessage) obj;
> String messtype = ome.getTyp().toString();
> String oid = message.getStringProperty(Constants.OID);
> String erstellungsdatum =
> message.getStringProperty(Constants.EINSTELLUNGSDATUM);
> _log.debug(new StringBuffer("Message erhalten
> Typus=").append(messtype)
> .append("; OID=").append(oid)
> .append(";
> Erstellungsdatum=").append(erstellungsdatum)
>
> .append(";Logging=").append(ome.isLogging()).toString());
> _ausgangsService.performOutmessage(ome,
> _propholder.isAntwortLoeschenAusDb());
> _log.info("onMessage: Anzahl Versuche = " +
> ome.getAnzahlVersuche());
>
> }
> _log.debug("OmqListener.On Message Ende");
> } catch (Throwable e) {
> //auf erneute Zustellversuche(Timer!) warten
> _log.error("Fehler!", e);
> }
> }
> ---
>
> When we restart activemq, what possibilities do I have to filter out in my
> programme those messages that have already been delivered ?
> I could delete messages from ACTIVEMQ_MSGS before we restart activemq but
> how can I decide between old messages (already delivered) and those that
> still need to be delivered ?
>
> Thanks !
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Oracle-delivered-Messages-remain-in-ACTIVEMQ-MSGS-tp4729613.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Critical Analysis feature on broker

[Gary Tully]

nice, I think there is value in just logging this information and not
halting of stopping.
In this way the feature can be used to determine usage patterns and spikes
etc and it would be possible to determine what the critical levels are.
This would allow a separation between getting information and doing
something about it.

On Sun, 6 Aug 2017 at 05:58 Michael André Pearce <
michael.andre.pea...@me.com> wrote:

> Thanks Clebert have left my feedback directly on the PR.
>
> Cheers
> Mike
>
> Sent from my iPhone
>
> > On 5 Aug 2017, at 06:03, Clebert Suconic 
> wrote:
> >
> > PR Sent.. i would appreciate reviews.
> >
> > thanks
> >
> > On Fri, Aug 4, 2017 at 1:02 PM, Clebert Suconic
> >  wrote:
> >> I'm adding some logic to detect cases where the broker may become
> irresponsive.
> >>
> >> I'm adding a component called CriticalAnalyzer, which will inspect
> >> response times of certain operations and decide to take the broker
> >> down when bad things are happening.
> >>
> >>
> >> Along several critical operations on the broker, I'm adding this
> pattern:
> >>
> >>
> >> enterCritical(pathID);
> >> try {
> >>   synchronized (lock) {
> >>   }
> >> } finally {
> >>   leaveCritical(pathID);
> >> }
> >>
> >> The CriticalAnalyzer will look at the times between enter and leave,
> >> and with a configured timeout, it will take the broker down.
> >>
> >>
> >>
> >> Now, when it's coming to the configuration, I'm not finding a good
> >> nomenclature for this.. and I'm asking for help:
> >>
> >> So, far I came up with these names:
> >>
> >> - analyze-critical : default true
> >>  is the critical analyzer on?
> >>
> >> - analyze-critical-timeout: default 12 (milliseconds, 2 minutes)
> >>  The timeout used to
> >>
> >> - analyze-critical-check-period default 1/2 of analyze-critical-timeout
> >>
> >> - analyze-critical-halt-on-failure: default false
> >>  In case of an issue, the a Runtime.halt() would be issued if true,
> >>  otherwise a shutdown.
> >>
> >> During deadlocks or IO issues, the most effective way would be
> >> actually the halt. We could even change the start scripts to restart
> >> the server in case of a returned value.
> >>
> >>
> >>
> >>
> >> Any input?
> >>
> >>
> >> I will send a Pull Request soon.
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>

Re: HEADS UP 1.5.6 and 2.2.0 release in 1 or 2 Weeks

[Gary Tully]

and there is a follow up:
https://github.com/apache/activemq-artemis/pull/1388

that better sorts the role mapping.
glad of the extra eyes :-)

On 6 Jul 2017 2:28 pm, "Clebert Suconic" <clebert.suco...@gmail.com> wrote:

> Martyn started a full build on a box we both share.. if it's ok I will
> merge it. It should be ok from what I saw.
>
> On Thu, Jul 6, 2017 at 3:59 AM, Gary Tully <gary.tu...@gmail.com> wrote:
> > i would like to get the kerberos bits into 2.2.0
> > https://github.com/apache/activemq-artemis/pull/1379
> >
> >
> > On 1 Jul 2017 01:28, "Clebert Suconic" <clebert.suco...@gmail.com>
> wrote:
> >
> >> I just fixed what i was going after...
> >> https://issues.apache.org/jira/browse/ARTEMIS-1269
> >>
> >> Anyone else has anything important to send? I want to cut a release
> >> Monday July 10th. instead of Friday, since cutting a release on Friday
> >> has been a bad omen for me :)
> >>
> >> On Wed, Jun 28, 2017 at 10:43 AM, Clebert Suconic
> >> <clebert.suco...@gmail.com> wrote:
> >> > I would like to do a 1.5.6 and a 2.2.0 between 1 and 2 weeks.
> >> >
> >> > (Most likely 1.. so if you have anything planned it would be nice to
> >> > have it 1 week... depending on a task I'm working on I may delay an
> >> > extra week, for a fix I'm doing for replication).
> >> >
> >> >
> >> > There are a few fixes on both branches, including a MQTT memory leak
> fix.
> >> >
> >> >
> >> >
> >> > --
> >> > Clebert Suconic
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >>
>
>
>
> --
> Clebert Suconic
>

Re: HEADS UP 1.5.6 and 2.2.0 release in 1 or 2 Weeks

[Gary Tully]

i would like to get the kerberos bits into 2.2.0
https://github.com/apache/activemq-artemis/pull/1379


On 1 Jul 2017 01:28, "Clebert Suconic"  wrote:

> I just fixed what i was going after...
> https://issues.apache.org/jira/browse/ARTEMIS-1269
>
> Anyone else has anything important to send? I want to cut a release
> Monday July 10th. instead of Friday, since cutting a release on Friday
> has been a bad omen for me :)
>
> On Wed, Jun 28, 2017 at 10:43 AM, Clebert Suconic
>  wrote:
> > I would like to do a 1.5.6 and a 2.2.0 between 1 and 2 weeks.
> >
> > (Most likely 1.. so if you have anything planned it would be nice to
> > have it 1 week... depending on a task I'm working on I may delay an
> > extra week, for a fix I'm doing for replication).
> >
> >
> > There are a few fixes on both branches, including a MQTT memory leak fix.
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>

Re: [VOTE] Apache ActiveMQ 5.15.0

[Gary Tully]

+1

There are some odd stack traces in the source build from bnd tools - looks
like we may need to add some additional excludes or it may be java8 bits
that bnd cannot parse. It is a little ugly need not be a blocker.

eg:

[*INFO*] *--- *maven-bundle-plugin:2.3.7:manifest *(bundle-manifest)* @
activemq-web-demo* ---*

java.lang.ArrayIndexOutOfBoundsException: 15

at aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:448)

at aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:369)

at aQute.lib.osgi.Clazz.parseClassFileWithCollector(Clazz.java:359)

at aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:349)

at aQute.lib.osgi.Analyzer.analyzeJar(Analyzer.java:1725)

at aQute.lib.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:1618)

at aQute.lib.osgi.Analyzer.analyze(Analyzer.java:124)

at aQute.lib.osgi.Builder.analyze(Builder.java:306)

at aQute.lib.osgi.Analyzer.calcManifest(Analyzer.java:301)

at aQute.lib.osgi.Builder.build(Builder.java:73)

at
org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:201)

at
org.apache.felix.bundleplugin.ManifestPlugin.getManifest(ManifestPlugin.java:114)

at
org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:69)

at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:264)

at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:255)

at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)

at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)

at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)

at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)

at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)

at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)

at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

On Wed, 28 Jun 2017 at 17:01 Timothy Bish  wrote:

> +1
>
> * Built from source and ran the smoke tests
> * Verified with Apache RAT that the license is present in the source files
> * Checked the SRC and BIN archives for License and NOTICE files
> * Ran the binary broker and tested the webconsole and ran some sample
> clients against it
> * Validated the signatures and checksums
>
>
> On Tue, Jun 27, 2017 at 1:59 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Hi Everyone,
> >
> > I have created the ActiveMQ 5.15.0 release and it's ready for a vote.
> Note
> > that this release bumps the required Java version to Java 8.
> >
> > The list of resolved issues is here:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> > ctId=12311210=12338054
> >
> > You can get binary distributions here:
> > https://repository.apache.org/content/repositories/orgapache
> > activemq-1137/org/apache/activemq/apache-activemq/5.15.0/
> >
> > Source archives are here:
> > https://repository.apache.org/content/repositories/orgapache
> > activemq-1137/org/apache/activemq/activemq-parent/5.15.0/
> >
> > Maven repository is at:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1137/
> >
> > Source tag:
> > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=com
> > mit;h=5f0d6943cb97b0570bf8d58e8eaf9f0003a5cb6c
> >
> > Please vote to approve this release.  The vote will remain open for 72
> > hours.
> >
> > [ ] +1 Release the binary as Apache ActiveMQ 5.15.0
> > [ ] -1 (provide specific comments)
> >
> > Here's my +1
> >
>
>
>
> --
> --
> Tim Bish
>

Re: Artemis commands in OSGi

[Gary Tully]

one thought - in 5.x there was some overlap between producer/consumer tools
provided by activemq and the jms send/receive tools in karaf[1].  It may
make sense to integrate with the karaf platform in this regard for the
plain jms stuff and have artemis specifics around destination and broker
stats b/c there is no standard way to do those bits.

[1]
https://svn.apache.org/repos/asf/karaf/site/production/manual/latest/jms.html -
not sure how old or relevant this is.

On Fri, 12 May 2017 at 07:22 Guillaume Nodet  wrote:

> Hey guys,
>
> I can't see the artemis commands when deploying in Karaf.
> Is that missing or did I miss something ?
> If they're actually missing, would you like me to work on it ?
> If so, anything I should now around artemis commands would be welcomed !
>
> Cheers,
> Guillaume Nodet
>

Re: Change Resource Adapter Defaults

[Gary Tully]

this may be out of date but there is an example at:
https://github.com/gtully/activemq-arquillian/blob/master/javaee/jca-config/server/standalone/configuration/standalone-example.xml#L341

On Fri, 28 Apr 2017 at 18:35 myung  wrote:

> Hello, I am working with the ActiveMQ Resource Adapter, hooking it into
> Wildfly 10. I am trying to configure it properly, but I do not know how to
> change the default ServerURL. The link here:
> http://activemq.apache.org/resource-adapter-properties.html, states that
> it
> defaults to localhost, but I want to default to a different value. Is this
> possible?
>
> Further, is it possible to change this property to have no default and to
> be
> required? Ideally, Wildfly would fail to start if this value is not
> provided, but right now it is forcing me to attempt to connect to
> localhost,
> which I do not want.
>
> I have tried using the  tag instead of the
>  within the ra.xml, but this causes the module to fail to
> load.
>
> Thanks for your time!
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Change-Resource-Adapter-Defaults-tp4725348.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: ActiveMQ + lgtm?

[Gary Tully]

this looks like a very nice tool and useful. the ui is great :-)

re:
   - The remaining alerts (present in today's code) can be found here
   . Many of them seem
   worthwhile to fix - what is the best way to collaborate with the ActiveMQ
   team on that? Would you like us to file JIRA issues, or even submit
   patches?

For sure, if you can provide patches, either via pr's or jiras that is
ideal.
Having a test that shows the real implication of an alert/flaw would be
even better so we can shore up our test coverage.


On Mon, 10 Apr 2017 at 19:33 Oege de Moor  wrote:

> lgtm.com is an analytics engine for source code, free for open source.
>
> It's currently in beta, continuously analysing commits of 160,000+
> developers, working on 30,000+ open source projects. ActiveMQ is one of
> these projects, and I am writing to ask for your feedback:
>
>- The overview  shows how
>ActiveMQ is steadily improving in quality - the number of "alerts"
> (issues
>identified by our out-of-the-box analyses, in red) drops steadily while
> the
>code grows (in blue). Does that tally with your own view of how
> ActiveMQ's
>quality is trending? From the contributors tab
> you can
>see Chris Shannon is responsible for most of the clean-up.
>- The remaining alerts (present in today's code) can be found here
>. Many of them
> seem
>worthwhile to fix - what is the best way to collaborate with the
> ActiveMQ
>team on that? Would you like us to file JIRA issues, or even submit
>patches?
>- Would you consider enabling PR integration
> (where alerts are
>posted as review comments), so new alerts are caught at code-review
> time in
>future?
>- The most important feature of lgtm is its powerful query engine
> to create new
> analyses. Whenever you see a mistake that *could* have been caught with
>code analysis, it's easy to create a new query that does so. So the
> notion
>of "quality" is not set by lgtm.com - you can set it yourself by
>creating new queries, or modifying existing ones. Do you have
>ideas/challenges for queries? Perhaps checking adherence to API
> contracts
>that are particular to ActiveMQ? If you supply the ideas, we'll create
> the
>queries.
>
> Any feedback you may have would be tremendously useful - please let us know
> what you think!
>
> Many thanks,
>
> -Oege
>

Re: Do we need DynamicImport-Package in actrivemq OSGi?

[Gary Tully]

my understanding is that it is related to embedding a broker and using
something like the jdbc store that uses a third party driver. The required
package import cannot be known in-advance.
Another scenario would be a custom broker plugin.
In essence, because there are extension points exposed by the broker that
are not osgi services or do not play by the osgi rules.

It is a tradeoff between limiting what is possible with activemq in osgi or
leaving it open to this sort of problem but allowing existing extensions to
work.
With dynamic-import * removed, the embedded broker becomes constrained.


On Mon, 13 Feb 2017 at 10:57 Christian Schneider 
wrote:

> I have a problem with the acticemq camel component.
> See https://issues.apache.org/jira/browse/AMQ-6597
>
> I think it is related to the use of DynamicImport-Package: * in activemq
> osgi.
>
> We had a similar issue before. In the former case activemq or artemis
> was searching for extensions and was trying to find them by loading some
> interface class using the bundles classloader. The problem is when doing
> this in a bundle that has Dynamic Import it will bind to that package at
> runtime. So it will be linked to the bundle offering the package which
> casues problems when refreshing bundles.
>
> In any case I found at that time that DynamicImport-Package causes big
> problems. So do we really need this? What is it used for?
>
> Christian
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: [DISCUSS] LevelDB deprecation

[Gary Tully]

makes sense to me.  keep the focus on the current default store.

On Thu, 17 Nov 2016 at 11:14 Richard Kettelerij 
wrote:

> +1 (non-binding).
>
> On Wed, Nov 16, 2016 at 3:48 PM, Jim Gomes  wrote:
>
> > No objections. I was never clear on what advantages LevelDB was supposed
> to
> > offer anyway.
> >
> > On Wed, Nov 16, 2016, 3:45 AM Robbie Gemmell 
> > wrote:
> >
> > > Seems like a good idea to me.
> > >
> > > On 15 November 2016 at 11:45, Christopher Shannon
> > >  wrote:
> > > > Hi Everyone,
> > > >
> > > > I just wanted to ask what people think about officially deprecating
> > > LevelDB
> > > > in our 5.x broker and update our documentation to say that it is no
> > > longer
> > > > recommended.  We can leave it in the code base for people who are
> still
> > > > using it but discourage its use.
> > > >
> > > > The main reason is that KahaDB continues to be the main focus where
> > bugs
> > > > are fixed and not much attention is paid to LevelDB. There seems to
> be
> > > > several issues with corruption (especially with replication) so I
> don't
> > > > think it should be a recommended store unless the stability is sorted
> > > out.
> > > > Unfortunately nearly every Jira reported against LevelDB goes
> ignored.
> > > >
> > > > Now that Artemis exists and supports replication I think the focus
> > should
> > > > be primarily on making Artemis the focus for users who need a
> > replicated
> > > > store or to encourage the use of something like a shared file system
> > > > master/slave setup.
> > >
> >
>

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.7.2

[Gary Tully]

+1

On Mon 4 Apr 2016 4:22 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1
>
> On Mon, Apr 4, 2016 at 10:45 AM, Jim Gomes  wrote:
>
> > +1
> >
> > On Mon, Apr 4, 2016, 6:36 AM Timothy Bish  wrote:
> >
> > > Hello
> > >
> > > This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.7.2
> > >
> > > This is new bugfix release of the Apache.NMS.ActiveMQ v1.7.x line.
> This
> > > release incorporates a few important fixes and improvements over the
> > > 1.7.1 release.
> > >
> > > The binaries and source bundles for the Release Candidate can be found
> > > here:
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq-dotnet/1.7.x/
> > >
> > > The Wiki Page for this release is here:
> > > http://activemq.apache.org/nms/apachenmsactivemq-v172.html
> > >
> > > The list of issues resolved is here:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201=12332993
> > >
> > > [ ] +1 Release the source as Apache NMS.ActiveMQ v1.7.2
> > > [ ] -1 (provide specific comments)
> > >
> > > Here's my +1
> > >
> > > --
> > > Tim Bish
> > > twitter: @tabish121
> > > blog: http://timbish.blogspot.com/
> > >
> > >
> >
>

Re: [VOTE] Release ActiveMQ-CPP v3.9.3

[Gary Tully]

+1

On Mon, 28 Mar 2016 at 20:47 Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1
>
> On Mon, Mar 28, 2016 at 10:58 AM, Timothy Bish 
> wrote:
>
> > New vote open for ActiveMQ-CPP v3.9.3
> >
> > This is a new patch release of the ActiveMQ-CPP client with a fix for the
> > message producer creation handling that allowed the client to miss
> > exceptions sent back from the broker on producer create failure.
> >
> > The source bundles for this release can be found here:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq-cpp/3.9.3/
> >
> > The Wiki page for the release is here:
> > http://activemq.apache.org/cms/activemq-cpp-393-release.html
> >
> > The list of issues fixed in this release is available here:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207=Html=12334243
> >
> > Please cast your votes:
> >
> > [ ] +1 Release the source as Apache ActiveMQ-CPP 3.9.3
> > [ ] -1 (provide specific comments)
> >
> > Here is my +1
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog:http://timbish.blogspot.com/
> >
> >
>

Re: [VOTE] Release ActiveMQ-CPP v3.9.1

[Gary Tully]

+1

On Tue, 1 Dec 2015 at 12:35 Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1 (non-binding)
>
> On Tue, Dec 1, 2015 at 1:43 AM, Claus Ibsen  wrote:
>
> > +1
> >
> > On Tue, Dec 1, 2015 at 1:47 AM, Timothy Bish 
> wrote:
> > > New vote open for ActiveMQ-CPP v3.9.1
> > >
> > > This is a new bug fix release of the ActiveMQ-CPP client with a fix for
> > a potential segfault when testing against the latest ActiveMQ Artemis
> > release.  A couple other minor fixes are included as well.
> > >
> > > The source bundles for this release can be found here:
> > > http://people.apache.org/~tabish/cms-3.9.x
> > >
> > > The Wiki page for the release is here:
> > > http://activemq.apache.org/cms/activemq-cpp-391-release.html
> > >
> > > The list of issues fixed in this release is available here:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311207=Html=12333244
> > >
> > > Please cast your votes:
> > >
> > > [ ] +1 Release the source as Apache ActiveMQ-CPP 3.9.1
> > > [ ] -1 (provide specific comments)
> > >
> > > Here is my +1
> > >
> > > --
> > > Tim Bish
> > > Sr Software Engineer | RedHat Inc.
> > > tim.b...@redhat.com | www.redhat.com
> > > twitter: @tabish121
> > > blog: http://timbish.blogspot.com/
> > >
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>

Re: [VOTE] Apache ActiveMQ 5.13.0

[Gary Tully]

source builds ok, license check ok, locally built binaries pass sanity check
+1

On Tue, 1 Dec 2015 at 01:05 Jamie G.  wrote:

> +1 (non-binding)
>
> On Mon, Nov 30, 2015 at 3:19 PM, Jim Gomes  wrote:
> > +1
> >
> > On Mon, Nov 30, 2015, 6:23 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> Hello everyone,
> >>
> >> I have cut the ActiveMQ 5.13.0 release and it's ready for a vote. This
> >> release has over 80 bug fixes and new features.
> >>
> >> The list of resolved issues is here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12329848
> >>
> >> You can get binary distributions here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1071/org/apache/activemq/apache-activemq/5.13.0/
> >>
> >> Source archives are here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1071/org/apache/activemq/activemq-parent/5.13.0/
> >>
> >> Maven2 repository is at:
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1071/
> >>
> >> Source tag:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=abfe038ddfd6d6c4f7c41e106dabc815041b04c5
> >>
> >> Please vote to approve this release.  The vote will remain open for 72
> >> hours.
> >>
> >> [ ] +1 Release the binary as Apache ActiveMQ 5.13.0
> >> [ ] -1 (provide specific comments)
> >>
> >> Here's my +1 (non-binding)
> >>
>

Re: [VOTE] Apache ActiveMQ 5.12.1

[Gary Tully]

+1

On Mon 12 Oct 2015 7:34 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Hello everyone,
>
> I have cut the ActiveMQ 5.12.1 release and it's ready for a vote. This
> release has 22 bug fixes and
> improvements.
>
> The list of resolved issues is here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12333269
>
> You can get binary distributions here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1069/org/apache/activemq/apache-activemq/5.12.1/
>
> Source archives are here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1069/org/apache/activemq/activemq-parent/5.12.1/
>
> Maven2 repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1069/
>
> Source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=21c8b4695f771065192ed7a24c92367ed9f6e564
>
> Please vote to approve this release.  The vote will remain open for 72
> hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.12.1
> [ ] -1 (provide specific comments)
>
> Here's my +1 (non-binding)
>

Re: {VOTE] Release Apache.NMS.ActiveMQ 1.7.1

[Gary Tully]

+1

On Sat, 3 Oct 2015 at 16:46 Timothy Bish  wrote:

> On 09/30/2015 07:04 PM, Jim Gomes wrote:
> > +1
> >
> > On Wed, Sep 30, 2015, 2:44 PM Timothy Bish  wrote:
> >
> >> Hello
> >>
> >> This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.7.1
> >>
> >> This is first bugfix release of the Apache.NMS.ActiveMQ v1.7.x line.
> >> This release incorporates many fixes and improvements over the 1.7.0
> >> release.  Several fixes made to the Java OpenWire client were ported
> >> over as well as some fixes for issues in the .NET Distributed
> >> Transaction layer.
> >>
> >> The binaries and source bundles for the Release Candidate can be found
> >> here:
> >> http://people.apache.org/~tabish/nms-1.7.x
> >> 
> >>
> >> The Wiki Page for this release is here:
> >> http://activemq.apache.org/nms/apachenmsactivemq-v171.html
> >>
> >> The list of issues resolved is here:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201=12329541
> >>
> >> Please cast your votes (the vote will be open for 72 hrs):
> >>
> >> [ ] +1 Release the source as Apache NMS.ActiveMQ v1.7.1
> >> [ ] -1 (provide specific comments)
> >>
> >> Here's my +1
> >>
> >> --
> >> Tim Bish
> >> Sr Software Engineer | RedHat Inc.
> >> tim.b...@redhat.com | www.redhat.com
> >> twitter: @tabish121
> >> blog: http://timbish.blogspot.com/
> >>
> >>
> I'll leave this open for a few more days, hopefully another PMC can take
> a look and cast a vote.
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Re: [DISCUSS] Refactor job scheduler

[Gary Tully]

that makes good sense. There is an open issue on this -
https://issues.apache.org/jira/browse/AMQ-5238

On Sat, 26 Sep 2015 at 13:30 Erik Wramner  wrote:

> I'm considering implementing a JDBC job scheduler store. The current
> state of affairs where there is only a memory and KahaDB job scheduler
> store means that it is impossible to use JDBC as a highly available
> backend with scheduled messages, including messages scheduled by the
> redelivery plugin. However, in my view the job scheduler store interface
> is deeply flawed.
>
> The problem is that the store does nothing. It can get or set a
> directory (useless with JDBC), it can return the number of jobs
> scheduled (OK) and it can return or remove job schedulers. The job
> schedulers do all the heavy lifting.
>
> This works, but it means that every time a new persistence mechanism is
> added we must implement the scheduler again. I really don't want to
> implement a job scheduler just to save jobs to a database instead of to
> the file system (with KahaDB). I think it would be much better if we
> could refactor the JobSchedulerStore interface to provide the
> persistence operations that are used by the two existing schedulers.
> That way it would be much easier to write a JDBC scheduler store and a
> LevelDB scheduler store and a new-exciting-storage-not-yet-available
> scheduler store without reinventing the wheel (the basic scheduling)
> every time.
>
> What do you think?
>
> -Erik
>

Re: [VOTE] Apache Artemis (RC4)

[Gary Tully]

+1

On Mon, 21 Sep 2015 at 18:33 Timothy Bish  wrote:

> +1 (binding)
>
> On 09/18/2015 10:55 AM, Martyn Taylor wrote:
> > Hello all.
> >
> > I've cut a 4th release candidate of Apache Artemis 1.1.0 addressing.
> > This latest RC fixes the MDB regressions as discussed on the RC3
> > feedback.
> >
> > Since 1.0.0 a number of significant improvements have been made,
> > mainly around OpenWire protocol support, where a number of bugs have
> > been fixed and significant enhancements to performance have been
> > made.  The examples have also been restructured to make them more user
> > friendly, and lastly, MQTT protocol support has been added.
> >
> > The release notes can be found here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12332642
> >
> >
> > The binary distributions can be found here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1068/org/apache/activemq/apache-artemis/1.1.0/
> >
> >
> > The source archives can be found here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1068/org/apache/activemq/apache-artemis/1.1.0/
> >
> >
> > The Maven repository is here:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1068/
> >
> >
> > The source tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.1.0
> >
> >
> > The project website for that version has been staged to:
> > http://people.apache.org/~martyntaylor/
> >
> > The vote will remain open for 72 hours.
> >
> > [ ] +1 approve the release as Apache Artemis 1.1.0
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here's my (non-binding) +1
> >
> > Regards
> >
> > Martyn
> > .
> >
>
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.b...@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

maven-bundle-plugin warning on the web-console

[Gary Tully]

the console output on a build of the activemq-web-console has been bugging
me for ages.
Stuff like:

[WARNING] Manifest
org.apache.activemq:activemq-web-console:war:5.12-SNAPSHOT : Split package
org/apache/activemq/web

and:

[ERROR] Manifest org.apache.activemq:activemq-web-console:war:5.12-SNAPSHOT
: Unresolved references to [bsh, 


I had a peek to see if I could suppress the warnings or configure the
correct bits such that they were no longer relevant.
I did not have any success :-)

If anyone has some relevant experience with the bundle plugin and can help
out it would be great.

In essence I want to have a clean maven build with minimal console noise.

thanks in advance ;-)

Re: [question] parallel tests in java

[Gary Tully]

maven surefire can fire off a few parallel jvms on a junit class or
method or I think even modules in parallel - it is at a higher level
but it think it is a sensible approach.
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#parallel

On 25 June 2015 at 14:53, Clebert Suconic clebert.suco...@gmail.com wrote:
 I have failed on google for this one...

 Well, I could find plenty of stuff but failed to find a good one.


 I'm hoping to get a few tests on Artemis and make them run in Parallel
 to gain some time on the overall testsuite.


 I was hoping to be able to steal some code from apollo, but the
 little I saw it's using a Scala trait for that, you add something like
 with with ParallelTestExecution (through super classes on the
 testsuite).

 I was looking into something similar on junit and I couldn't find
 anything like it. I found some user extends through Stack Over Flow,
 through something called ParallelComputer in Junit but I couldn't find
 anything standard enough and ready to use.

 Does anyone have any experience to share here?

Re: [question] parallel tests in java

[Gary Tully]

peek at @NotThreadSafe in
http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html

the inverse of what you want but not a bad place to start.


On 25 June 2015 at 15:20, Clebert Suconic clebert.suco...@gmail.com wrote:
 I can't run the whole thing in Parallel, I need to be able to tell
 which tests are safe to run in parallel.

 On Thu, Jun 25, 2015 at 10:13 AM, Gary Tully gary.tu...@gmail.com wrote:
 maven surefire can fire off a few parallel jvms on a junit class or
 method or I think even modules in parallel - it is at a higher level
 but it think it is a sensible approach.
 http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#parallel

 On 25 June 2015 at 14:53, Clebert Suconic clebert.suco...@gmail.com wrote:
 I have failed on google for this one...

 Well, I could find plenty of stuff but failed to find a good one.


 I'm hoping to get a few tests on Artemis and make them run in Parallel
 to gain some time on the overall testsuite.


 I was hoping to be able to steal some code from apollo, but the
 little I saw it's using a Scala trait for that, you add something like
 with with ParallelTestExecution (through super classes on the
 testsuite).

 I was looking into something similar on junit and I couldn't find
 anything like it. I found some user extends through Stack Over Flow,
 through something called ParallelComputer in Junit but I couldn't find
 anything standard enough and ready to use.

 Does anyone have any experience to share here?



 --
 Clebert Suconic
 http://community.jboss.org/people/clebert.suco...@jboss.com
 http://clebertsuconic.blogspot.com

Re: Completing the IP clearance for Artemis

[Gary Tully]

looks good to me too.

On 27 May 2015 at 18:04, Hiram Chirino hi...@hiramchirino.com wrote:
 Ok I think the IP clearance form is now complete:
 http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/hornetq.xml

 Could some more PMC members please review and let me know if it looks
 good to them?

 On Wed, May 27, 2015 at 12:51 PM, Hiram Chirino hi...@hiramchirino.com 
 wrote:
 Now that the release looks good.  I think the ip clearance docs need
 to be completed.
 Current status is up at:
 http://incubator.apache.org/ip-clearance/hornetq.html

 The remaining items are Copyright and 3rd party license stuff which we
 have validated is correct in the this release so I'm going to fill
 them out as completed today.

 --
 Hiram Chirino
 Engineering | Red Hat, Inc.
 hchir...@redhat.com | fusesource.com | redhat.com
 skype: hiramchirino | twitter: @hiramchirino



 --
 Hiram Chirino
 Engineering | Red Hat, Inc.
 hchir...@redhat.com | fusesource.com | redhat.com
 skype: hiramchirino | twitter: @hiramchirino

Re: [VOTE] Apache Artemis 1.0.0 (RC3)

[Gary Tully]

+1

On 21 May 2015 at 17:38, Martyn Taylor mtay...@redhat.com wrote:
 Hello all.

 I've cut a third release candidate of Apache Artemis 1.0.0, addressing the
 RC2 feedback from community members.

 This is a first release of the Artemis project with protocol support for
 AMQP, STOMP, CORE, HORNETQ and OPENWIRE (alpha).

 N.B. The OpenWire implementation is at alpha with support for ActiveMQ JMS
 clients and basic transport.  More advanced features will be added
 progressively over the next series of releases.


 The release notes can be found here:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920version=12328953

 The binary distributions can be found here:
 https://repository.apache.org/content/repositories/orgapacheactivemq-1060/org/apache/activemq/apache-artemis/1.0.0/

 The source archives can be found here:
 https://repository.apache.org/content/repositories/orgapacheactivemq-1060/org/apache/activemq/apache-artemis/1.0.0/

 The Maven repository is here:
 https://repository.apache.org/content/repositories/orgapacheactivemq-1060/

 The source tag:
 https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0

 The project website for that version has been staged to:
 http://people.apache.org/~martyntaylor/

 The vote will remain open for 72 hours.

 [ ] +1 approve the release as Apache Artemis 1.0.0
 [ ] +0 no opinion
 [ ] -1 disapprove (and reason why)

 Here's my (non-binding) +1

 Regards
 Martyn

Re: What does it take to become a committer on ActiveMQ?

[Gary Tully]

added willingness to document to the list in the wiki.
discussion on issues or the lists could maybe be pulled into separate points.

I think if you hit any or all of the points you could be a committer.

On 20 May 2015 at 16:32, Bruce Snyder bruce.sny...@gmail.com wrote:
 What do you feel it takes to become a committer on ActiveMQ?

 In an effort to identify what is required to become a committer on
 ActiveMQ, I have created a wiki page so that we can all collaborate to
 create some guidelines:

 https://cwiki.apache.org/confluence/display/ACTIVEMQ/How+to+Become+a+Committer+on+the+ActiveMQ+Project

 Please contribute your thoughts on this page and let's discuss the matter
 on this thread.

 Bruce

 --
 perl -e 'print
 unpack(u30,D0G)U8V4\@4VYY95R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );'

 ActiveMQ in Action: http://bit.ly/2je6cQ
 Blog: http://bruceblog.org/
 Twitter: http://twitter.com/brucesnyder

[jira] [Commented] (AMQ-5734) Support MQTT 3.1 silent subscription fail

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519143#comment-14519143
 ] 

Gary Tully commented on AMQ-5734:
-

Dejan - can u peek at 
https://fisheye6.atlassian.com/changelog/activemq-git?cs=f5283a904589eb4a9344fe42885cdacf92de68dd
 
i found that the retained message (body size ==0) was not being accounted for 
in the test. Can you verify that that message should be dispatched?

 Support MQTT 3.1 silent subscription fail
 -

 Key: AMQ-5734
 URL: https://issues.apache.org/jira/browse/AMQ-5734
 Project: ActiveMQ
  Issue Type: Improvement
  Components: MQTT
Affects Versions: 5.11.0
Reporter: Dejan Bosanac
Assignee: Dejan Bosanac
 Fix For: 5.12.0


 There's a difference in what 3.1 and 3.1.1 specs say should happen when an 
 unauthorised subscribe happens. In 3.1, the broker don't informs the client 
 so it just silently ignores the problem. In 3.1.1 it sends special QoS back. 
 We currently only implement the later. We need to implement also 3.1 
 behaviour for older clients.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)