Re: [VOTE] Apache ActiveMQ Artemis 2.35.0

[Arthur Naseef]

+1

* built with `mvn clean install`
* created and started broker from the build output


On Wed, Jun 12, 2024 at 9:37 AM 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&version=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: PrefixAddressTransformer for unique event divert

[Arthur Naseef]

If I read it correctly, the transformer together with the divert provides a
means to duplicate messages from any number of inbound destinations to a
parallel set of destinations by adding a prefix.

For example:

test.events.a.1  -> TestQ.test.events.a.1

test.events.b.2 -> TestQ.test.events.b.2

Like a wiretap, using parallel queue structures.

Did I get that right?

Art


On Thu, Jun 6, 2024 at 8:55 AM Justin Bertram  wrote:

> Generally speaking, _every_ commit which fixes a bug or adds a feature or
> improvement should have a test. This ensures the bug is actually fixed or
> the feature actually works and also mitigates regressions later.
>
> Furthermore, if you want this to be something accessible to end-users then
> documentation should be part of the commit as well (e.g. here [1]).
>
> All that said, however, I'm not sure the use-case for this transformer is
> general enough to be shipped with the broker. I can't really tell what the
> use-case is based on your email.
>
> Of course, feel free to send a PR with tests and documentation and then it
> can be properly evaluated.
>
>
> Justin
>
> [1]
>
> https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/transformers.adoc
>
> On Thu, Jun 6, 2024 at 7:24 AM  wrote:
>
> > Hello,
> >
> > we are currently using a Transformer to redirect Event messages into a
> > queue to consume them as kind of Unique Processing by distributed
> > applications.
> > For this we use a transformer:
> >
> > public class PrefixAddressTransformer implements Transformer
> > {
> >@Override
> >public Message transform(Message message)
> >{
> >   SimpleString originalAddress =
> >
> (SimpleString)message.getBrokerProperty(Message.HDR_ORIGINAL_ADDRESS);
> >   message.setAddress(message.getAddress() + "."
> > +originalAddress.toString());
> >   return message;
> >}
> > }
> >
> > That we use with with a divert:
> >
> >   
> >  
> >   test.events.#
> >   TestQ
> >   true
> >
> >
> org.apache.activemq.artemis.core.server.transformer.PrefixAddressTransformer
> >  
> >  
> >
> > So that all messages on test.events.# are also sent to a queue
> > TestQ.test.events... and can be processed in a distributed manner.
> > Others might also profit from this, so we wanted to commit it to the
> > offical artemis repo.
> >
> > Should there be testing done on this transformer, like with the
> >
> org.apache.activemq.artemis.core.server.transformer.AddHeadersTransformer,
> > which is tested in
> >
> org.apache.activemq.artemis.tests.integration.management.DivertControlTest
> > ?
> >
> > best regards
> > Maximilian Rieder
> > --
> >
> > *Maximilian Rieder*
> > Software Engineer
> >
> > Phone: +49 941 / 7 83 92 84
> > maximilian.rie...@systema.com
> >
> > www.systema.com
> >
> > [image: LinkedIn]  >[image:
> > Facebook] [image: XING]
> > 
> >
> > SYSTEMA
> > Systementwicklung Dipl.-Inf. Manfred Austen GmbH
> >
> > Manfred-von-Ardenne-Ring 6 | 01099 Dresden
> > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786
> > Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO
> >
> > P Please check whether a printout of this e-mail is really necessary.
> >
>

Re: [VOTE] Include unsubscribe me on all ActiveMQ mail lists..

[Arthur Naseef]

+1

On Fri, May 17, 2024 at 9:22 AM Jean-Baptiste Onofré  wrote:
>
> +1
>
> Regards
> JB
>
> On Thu, May 16, 2024 at 8:19 PM Clebert Suconic
>  wrote:
> >
> > I want to propose having all of our user lists including an
> > Unsubscribe-me link at the end of the messages. Such unsubscribe-me
> > should include the link with enough information to remove such
> > subscriptions. Something like:
> >
> >
> > Click here To unsubscribe you from the  :
> >
> > - link to unsubscribe
> >
> >
> >
> > That way users will stop asking to be unsubscribed.. and any users not
> > knowing which alias was subscribed to the list wouldn't need to look
> > into the source of his email.
> >
> >
> > Apache Infra can do that but only after we got consensus from the
> > community, for that I'm starting a vote.
> >
> > Please indicate your vote with a +1 or -1. In case of a -1 please
> > indicate your reasoning for such.
> >
> >
> >
> > Here goes my +1 Binding Vote.
> >
> >
> >
> >
> > --
> > Clebert Suconic

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Arthur Naseef]

I read through Justin's document up to the section "Why Use GitHub
Issues?" and have questions.

When users want Jira access, do they use an Apache account, or can it
be any account?  Or are we just creating jira-specific accounts for
these users?  Do they have / need-to-have an ICLA signed and on-file?

It seems to me the real issue at heart here is avoiding spam, and
using authenticated users as a means to that end.  So, I'm trying to
understand whether that's feasible with Apache Jira.

Art

P.S. Nice write-up Justin - thank you!

On Wed, Apr 3, 2024 at 2:16 AM Jean-Baptiste Onofré  wrote:
>
> Hi Justin
>
> Fantastic work and great summary !
>
> I do a quick pass, I will do a more detailed read.
>
> Thanks !
> Regards
> JB
>
> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram  wrote:
> >
> > There's been a few threads about this general subject, but most have
> > concentrated on Classic in particular. I think it's worth discussing
> > migration of ActiveMQ as a whole and diving a bit deeper into the details
> > of why a migration makes (or doesn't make) sense and what the challenges
> > may be.
> >
> > To this end I've put together this document [1]. I hope it will be of
> > service to the community as we consider this option.
> >
> >
> > Justin
> >
> > [1]
> > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [PROPOSAL] OpenWire exception handling mismatch between Javax and Jakarta APIs

[Arthur Naseef]

Thanks Chris.  I looked at the PR - looks good.

I hope nobody relies on our specific sub-classes of JMSException...

Art


On Tue, Jan 16, 2024 at 5:21 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Art,
>
> For your first point, existing clients will run into this but they already
> properly handle the ClassNotFoundException fine so the client never sees
> the error. The marshaller just converts to a generic Throwable exception
> when it can't find the type given on the classpath and then the ActiveMQ
> client sees that and converts that to a JMSException. So it doesn't cause a
> client error but the exception type isn't quite right. (And no the broker
> doesn't create the type). My update fixes things so the client can
> translate easily back to the correct type so that the more specific JMS
> exception type and not a generic JMSException is thrown by the client.
>
> There is no breaking change so there is no need to opt in. This solution
> is fixing a bug when trying to convert exception types so there is no
> reason to allow turning it off. Without the change if a javax client talks
> to a jakarta broker (or vice versa) the exception type won't be mapped
> correctly and just be generic as I said. When we make things better in the
> future and use a new openwire version to handle things, this should be
> transparent and the client will still correctly use the right exception
> types by converting the newly returned error codes to the right exceptions
> so from the users stand point and client behavior there's no real change.
>
> I made all the changes and pushed up to the branches and tested things, you
> can see the commits linked to the Jira:
> https://issues.apache.org/jira/browse/AMQ-9418
>
> Chris
>
> On Tue, Jan 16, 2024 at 5:40 PM Arthur Naseef  wrote:
>
> > Looks like the key points here are:
> >
> >1. Existing clients will run into ClassNotFoundException when
> >unmarshalling an exception from a non-compatible broker. (Do broker's
> > ever
> >create an instance of the class specified by the client?)
> >2. The proposed change will update clients to convert between
> javax.jms
> >and jakarta.jms package names
> >3. In the future we can look to replace the existing approach with
> >something safer/simpler
> >
> > If so, I like that approach.  One thing I can see that could be a concern
> > for users - going to the intermediate solution means that they will hit
> > another breaking change in the not-too-distant future when we get to (3).
> > I wonder if we could perhaps make it opt-in so users are pushed to
> > understand what they are getting into.
> >
> > Art
> >
> >
> >
> > On Tue, Jan 16, 2024 at 1:04 PM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > I talked with Tim and Matt offline and will go with that approach, I
> have
> > > PRs open. If needed we can backport to some older clients too.
> > >
> > > On Tue, Jan 16, 2024 at 9:38 AM Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > >
> > > > As background, last week it was discovered (thanks Justin) that there
> > was
> > > > an oversight with the Exception handling over OpenWire with the
> upgrade
> > > to
> > > > Jakarta apis in the 6.0.x broker.
> > > > https://issues.apache.org/jira/browse/AMQ-9418
> > > >
> > > > The problem is that OpenWire has a response type to return an
> exception
> > > to
> > > > the client and this response type includes the actual throwable type
> > > > written as a string with the fully qualified package. This means that
> > if
> > > an
> > > > older 5.x client that is using the javax JMS apis receives back
> > something
> > > > like InvalidClientIDException from a 6.x broker the exception type
> > > received
> > > > is actually going to be "jakarta.jms.InvalidIDException" and then the
> > > > client can't unmarshall that since it's likely not on the classpath.
> > The
> > > > result is that if it converts it will get a ClassNotFoundException
> and
> > > just
> > > > convert to a generic exception type so this could be a breaking
> change
> > > for
> > > > clients that are trying to handle specific exceptions. Note that the
> > > > reverse is actually also true, if a new 6.x client connected to a 5.x
> > > > broker the same problem happens.
> > > >

Re: [PROPOSAL] OpenWire exception handling mismatch between Javax and Jakarta APIs

[Arthur Naseef]

Looks like the key points here are:

   1. Existing clients will run into ClassNotFoundException when
   unmarshalling an exception from a non-compatible broker. (Do broker's ever
   create an instance of the class specified by the client?)
   2. The proposed change will update clients to convert between javax.jms
   and jakarta.jms package names
   3. In the future we can look to replace the existing approach with
   something safer/simpler

If so, I like that approach.  One thing I can see that could be a concern
for users - going to the intermediate solution means that they will hit
another breaking change in the not-too-distant future when we get to (3).
I wonder if we could perhaps make it opt-in so users are pushed to
understand what they are getting into.

Art



On Tue, Jan 16, 2024 at 1:04 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I talked with Tim and Matt offline and will go with that approach, I have
> PRs open. If needed we can backport to some older clients too.
>
> On Tue, Jan 16, 2024 at 9:38 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > As background, last week it was discovered (thanks Justin) that there was
> > an oversight with the Exception handling over OpenWire with the upgrade
> to
> > Jakarta apis in the 6.0.x broker.
> > https://issues.apache.org/jira/browse/AMQ-9418
> >
> > The problem is that OpenWire has a response type to return an exception
> to
> > the client and this response type includes the actual throwable type
> > written as a string with the fully qualified package. This means that if
> an
> > older 5.x client that is using the javax JMS apis receives back something
> > like InvalidClientIDException from a 6.x broker the exception type
> received
> > is actually going to be "jakarta.jms.InvalidIDException" and then the
> > client can't unmarshall that since it's likely not on the classpath. The
> > result is that if it converts it will get a ClassNotFoundException and
> just
> > convert to a generic exception type so this could be a breaking change
> for
> > clients that are trying to handle specific exceptions. Note that the
> > reverse is actually also true, if a new 6.x client connected to a 5.x
> > broker the same problem happens.
> >
> > I've been looking at ways to fix this broker side and it's not great. We
> > would need to detect if the client wants jakarta or javax types (we can
> > kind of do this for newer clients because
> > https://issues.apache.org/jira/browse/AMQ-6379 has new clients set their
> > actual client version from the manifest file in the jar) and then we have
> > to pass that to the marshallers and signal in some way to convert.  The
> > main problem is having to pass it to the marshaller means probably having
> > to update the Openwire format to include the version discovered and
> having
> > complicated detection logic depending on if it is set or not as not
> > everything sets it. If we didn't want to do it at the marshaller level,
> > we'd have to include or repackage both versions of the Exceptions which
> is
> > also not ideal as having to include both javax and jakarta exception
> types
> > could cause mistakes elsewhere and maintaining isn't fun.
> >
> > I think a much simpler approach is to just let the receiver (usually
> > client) handle it. I think instead of trying to have the broker detect
> what
> > to send, it should be handled on the unmarshal side of things by the
> > receiver of the error command. The receiver (client or broker) knows if
> it
> > will need to convert so it makes things much simpler. Obviously this
> would
> > only work if we update the marshaller in the client code jar so my
> proposal
> > would be to just release a small update in the next version of 5.18.x
> > client and also 6.0.x clients to handle this. We can just document saying
> > that if you need to have specific exception type translation and are
> using
> > a broker and client that are not both javax or jakarta then you need to
> > upgrade to a new client version for the translation. Otherwise they can
> > just get the generic Throwable back and will work. The main use case I
> > think is if clients are stuck on older versions of Java and can't upgrade
> > yet when talking to a new broker or an older broker can't be upgraded yet
> > but the clients can.
> >
> > Here is an example of fixing the 5.18.x client:
> >
> https://github.com/cshannon/activemq/commit/b52bdd3f1cdac31e9aa6fed86e6737d376b8b5a4
> > It's pretty simple, if we get back jakarta then convert to javax and
> done.
> > We would do the reverse in 6.x branch.
> >
> > Going forward as a permanent fix, we should just fix this entirely in
> > OpenWire v13. Including the Java exception types already caused a major
> CVE
> > issue and now it's causing issues here. I think for the next OpenWire
> > version we should create a new Exception type that uses an Error code
> just
> > like Artemis and other projects do and then the client can jus

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

[Arthur Naseef]

+1

Ran the full build on my Ubuntu 20.04 system.

Note that I ran into a test failure on BrokerXmlConfigStartTest due to the
test reusing port 61616 quickly, and getting "port already in use" errors.
I know others have run this test without problem, so I'm not going to worry
about it for now.

All other tests passed.

Art


On Thu, Nov 16, 2023 at 2:11 AM Jamie G.  wrote:

> +1,
>
> Cheers,
> Jamie
>
> On Thu, Nov 16, 2023 at 3:01 AM Jean-Baptiste Onofré 
> wrote:
> >
> > +1 (binding)
> >
> > I did the same tests I did during release preparation :)
> > Some fixes/polish to do for 6.0.1 but nothing blocker :)
> >
> > Regards
> > JB
> >
> > On Tue, Nov 14, 2023 at 11:05 AM Jean-Baptiste Onofré 
> wrote:
> > >
> > > Hi guys,
> > >
> > > After several weeks of work, I'm glad to submit Apache ActiveMQ 6.0.0
> > > release to your vote.
> > >
> > > This release is a big milestone for ActiveMQ, starting the new 6.x
> series.
> > >
> > > It's the second RC where we fixed AMQ-9388 detected during the first
> vote.
> > >
> > > This release includes a bunch of changes, especially:
> > > - Jakarta Messaging 3.1, JMS 2.0, JMS 1.1 (still work to do to be
> > > fully complete)
> > > - Jakarta EE namespace support
> > > - JDK17/21 support
> > > - Spring 6.x
> > > - Jetty 11.x
> > > - Apache Camel 4.x
> > > - Jolokia 2.x
> > > - and much much more!
> > >
> > > Release Notes:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352570
> > >
> > > Maven Staging Repository:
> > >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1381/
> > >
> > > Dist Staging Repository:
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq/6.0.0/
> > >
> > > Git tag: activemq-6.0.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: HEADS-UP: ActiveMQ 6.0.0 - apache-activemq 6.0.0 artifact exists in Maven Central

[Arthur Naseef]

You're welcome.

On Thu, Oct 26, 2023 at 10:42 AM Jean-Baptiste Onofré 
wrote:

> Thanks Art :)
>
> Le jeu. 26 oct. 2023 à 19:25, Arthur Naseef  a
> écrit :
>
> > BTW, I just found this while doing something unrelated to our 6.0.0
> > release.
> >
> > Maven central already has an apache-activemq artifact released with
> version
> > 6.0.0:
> >
> > https://mvnrepository.com/artifact/org.apache.activemq/apache-activemq
> >
> >
> > Perhaps we can get that one removed?
> >
> > It looks like there are no files, just the metadata?
> >
> > Art
> >
>

HEADS-UP: ActiveMQ 6.0.0 - apache-activemq 6.0.0 artifact exists in Maven Central

[Arthur Naseef]

BTW, I just found this while doing something unrelated to our 6.0.0 release.

Maven central already has an apache-activemq artifact released with version
6.0.0:

https://mvnrepository.com/artifact/org.apache.activemq/apache-activemq


Perhaps we can get that one removed?

It looks like there are no files, just the metadata?

Art

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Arthur Naseef]

If we do update the website for naming - I recommend we just call refer to
"ActiveMQ Classic" as an alias.  For example (totally made up), "We have 2
brokers, ActiveMQ (aka ActiveMQ Classic) and ActiveMQ Artemis".

Art


On Thu, Sep 14, 2023 at 5:19 AM Jean-Baptiste Onofré 
wrote:

> I agree about naming. Let's use "Classic" on the index.html page, but
> not necessary on the "component"/subpage (here we can use ActiveMQ as
> shortcut).
>
> About the version, it seems we are heading to a consensus. Let's wait
> an additional 24 hours, then, if there are no objections, I will use
> 6.0.0-SNAPSHOT version on main branch, heading to the 6.0.0 release.
>
> Thanks !
> Regards
> JB
>
> On Thu, Sep 14, 2023 at 12:43 PM Christopher Shannon
>  wrote:
> >
> > I am ok with whatever makes sense to distinguish the brokers. If people
> are
> > starting to use "classic" that is fine. As I previously said I don't
> think
> > we necessarily need to make the naming discussion as part of the
> versioning
> > discussion.
> >
> > I am planning to leave this thread open for another day or so to see if
> > there is more feedback but if there's no big objections I will start a
> vote
> > thread for just bumping the AMQ version to 6.0.0 and we can leave open
> the
> > discussion for what to do about the "Classic" name as a separate topic.
> >
> > On Thu, Sep 14, 2023 at 5:14 AM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > > Same, when I have to mention both in the same discussion, I tend to add
> > > "classic" for ActiveMQ to make sure there is no confusion with Artemis.
> > > But that's basically it.
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Wed, Sep 13, 2023 at 5:43 AM Arthur Naseef 
> > > wrote:
> > >
> > > > As a general practice, I try to avoid unqualified + qualified names
> > > > together - it gets confusing.  However, in this case, we have a
> > > > long-established history.
> > > >
> > > > I believe that a formal rename of ActiveMQ would be fairly disruptive
> > > for a
> > > > small amount of value.
> > > >
> > > > For the record - I have heard, and started using, the term "ActiveMQ
> > > > Classic" when talking about ActiveMQ + Artemis in the same
> discussion.
> > > >
> > > > Art
> > > >
> > > >
> > > > On Tue, Sep 12, 2023 at 1:52 PM David Blevins <
> david.blev...@gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > > On Sep 12, 2023, at 7:15 AM, Jeff Genender  >
> > > > wrote:
> > > > > >
> > > > > > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> > > > > referred to as classic.  Most of our users just say "ActiveMQ" or
> > > > "Artemis".
> > > > >
> > > > > Same.  I've never heard anyone contact us and say "Classic".
> Always
> > > just
> > > > > "ActiveMQ" and "Artemis"
> > > > >
> > > > >
> > > > > -David
> > > > >
> > > > > > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> > > > > >> I don't really see a need for "Classic" and I think it should be
> > > > > dropped.
> > > > > >> No one uses it and just refers to it as "ActiveMQ 5.x".
> > > > > >>
> > > > > >> ActiveMQ Artemis has had its own versioning and brand since the
> > > > > beginning
> > > > > >> going back many years so I don't think getting rid of "Classic"
> is
> > > an
> > > > > issue
> > > > > >> or would lead to any confusion since as I said, no one uses it
> > > > anyways.
> > > > > >>
> > > > > >> So I think it makes sense to just go with what JB said for now:
> > > > > >>
> > > > > >> - ActiveMQ 5.18.x
> > > > > >> - ActiveMQ 6.x.x
> > > > > >> - ActiveMQ 7.x.x
> > > > > >> - ActiveMQ Artemis 2.x
> > > > > >>

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Arthur Naseef]

As a general practice, I try to avoid unqualified + qualified names
together - it gets confusing.  However, in this case, we have a
long-established history.

I believe that a formal rename of ActiveMQ would be fairly disruptive for a
small amount of value.

For the record - I have heard, and started using, the term "ActiveMQ
Classic" when talking about ActiveMQ + Artemis in the same discussion.

Art


On Tue, Sep 12, 2023 at 1:52 PM David Blevins 
wrote:

>
>
> > On Sep 12, 2023, at 7:15 AM, Jeff Genender  wrote:
> >
> > +1 to what Christopher said... I have rarely heard AMQ 5.x being
> referred to as classic.  Most of our users just say "ActiveMQ" or "Artemis".
>
> Same.  I've never heard anyone contact us and say "Classic".  Always just
> "ActiveMQ" and "Artemis"
>
>
> -David
>
> > On 2023/09/12 13:44:15 Christopher Shannon wrote:
> >> I don't really see a need for "Classic" and I think it should be
> dropped.
> >> No one uses it and just refers to it as "ActiveMQ 5.x".
> >>
> >> ActiveMQ Artemis has had its own versioning and brand since the
> beginning
> >> going back many years so I don't think getting rid of "Classic" is an
> issue
> >> or would lead to any confusion since as I said, no one uses it anyways.
> >>
> >> So I think it makes sense to just go with what JB said for now:
> >>
> >> - ActiveMQ 5.18.x
> >> - ActiveMQ 6.x.x
> >> - ActiveMQ 7.x.x
> >> - ActiveMQ Artemis 2.x
> >> - ActiveMQ Artemis 3.x
> >>
> >> That would be quite clear as to what each version is.
> >>
> >> On Tue, Sep 12, 2023 at 9:27 AM Jean-Baptiste Onofré 
> >> wrote:
> >>
> >>> That makes lot of sense to me ! We will have:
> >>>
> >>> - ActiveMQ 5.18.x
> >>> - ActiveMQ 6.x.x
> >>> - ActiveMQ 7.x.x
> >>> - ActiveMQ Artemis 2.x
> >>> - ActiveMQ Artemis 3.x
> >>>
> >>> So, I propose to have two "spaces" on website:
> >>> http://activemq.apache.org/activemq
> >>> http://activemq.apache.org/artemis
> >>>
> >>> The index.html will list the two spaces and users will go to one or
> >>> another.
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On Tue, Sep 12, 2023 at 3:08 PM Robbie Gemmell <
> robbie.gemm...@gmail.com>
> >>> wrote:
> 
>  ActiveMQ 5.x + 6.x, ActiveMQ Artemis 2.x yes...i.e no change.
> 
>  On Tue, 12 Sept 2023 at 13:34, Francois Papon
>   wrote:
> >
> > So next will be ActiveMQ 5.x, ActiveMQ 6.x and Artemis?
> >
> > On 12/09/2023 14:14, Robbie Gemmell wrote:
> >> That is how I refer to them, or more fully as ActiveMQ 5.x like
> >>> below,
> >> and ActiveMQ Artemis.
> >>
> >> Same as last time this was discussed, I dont consider "Classic" part
> >> of the actual name, just a reflective description label, quoted for
> a
> >> reason.
> >>
> >> On Tue, 12 Sept 2023 at 12:48, fpapon  wrote:
> >>> Why not simply ActiveMQ and Artemis?
> >>>
> >>> This is how people used to name the 2 projects, I never eared
> >>> someone
> >>> say "ActiveMQ Classic".
> >>>
> >>> regards,
> >>>
> >>> François
> >>>
> >>> On 12/09/2023 13:07, Robbie Gemmell wrote:
>  Same thoughts as last time you proposed it really. Adding Leto
> >>> would
>  not be an improvement for me, more actually the reverse. I think
> >>> it's
>  fine as it is, ActiveMQ 5.x / 6.x, adding Leto would be more
>  confusing. Describing something as 'classic' is a pretty normal /
>  well-known thing, I think a user even noted that on the original
>  thread.
> 
>  On Tue, 12 Sept 2023 at 10:25, Jean-Baptiste Onofré <
> >>> j...@nanthrax.net> wrote:
> > Is it a good time to talk about ActiveMQ "Something" instead of
> > "Classic" ? (I hate this "classic" naming (it sounds weird to me)
> >>> and
> > most of people uses simply Artemis and ActiveMQ as name)
> >
> > I proposed ActiveMQ Artemis and ActiveMQ Leto (Leto is the mother
> >>> of
> > Artemis in Greek mythology) to have a clear distinction between
> >>> the
> > two subprojects. Thoughts ? :)
> >
> > If it's too "sensible", please ignore :)
> >
> > Regards
> > JB
> >
> > On Tue, Sep 12, 2023 at 11:11 AM Gary Tully 
> >>> wrote:
> >> 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.1

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

[Arthur Naseef]

I agree.  We have had breaking changes in the 5.x series, and that's bad.
We may not be perfect in maintaining semantic versioning, but it is
important.

The Jakarta changes are definitely a major concern if we stick to 5.x.

Is there any reason to avoid using 6.x?  I looked around to see if we ever
had any artifacts released with that version number and didn't find any...

Art


On Mon, Sep 11, 2023 at 3:05 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Jeff,
>
> That's a good point about Artemis possibly being 7.0, that's fine too.
>
> This is nothing against Artemis, really it's just this release completely
> breaks everything and is not compatible at all so I really think it would
> be terrible to release it as 5.19.x as for the last 10+ years people have
> expected to mostly just upgrade from one 5.x version to the next without
> much issue.
>
> Chris
>
> On Mon, Sep 11, 2023 at 5:31 PM fpapon  wrote:
>
> > Hi,
> >
> > Make totally sense, especially about keeping the javax version
> > supported, so need to split in 2 major versions.
> >
> > Big +1
> >
> > regards,
> >
> > François
> >
> > On 11/09/2023 23:14, Christopher Shannon 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.
> > >
> > --
> > --
> > François
> >
> >
>

Re: Home for activemq-openwire

[Arthur Naseef]

That is very helpful, thank you Tim.  I heard that generator didn't work,
but haven't yet tried it myself.

Art

On Wed, Aug 23, 2023 at 11:59 AM Timothy Bish  wrote:

> On 8/23/23 13:11, Arthur Naseef wrote:
> > That sounds right.  My 2cents - it would be nice to figure out the
> closest
> > thing to a working flow that we can get, and then worry about cleanup.
> >
> > Art
>
> I spent a little time just to resurrect some knowledge on this, here's
> the basics
>
> To run the generator in the ActiveMQ source tree you need to enable the
> profile in the activemq-client module for the openwire generator and use
> the generate sources goal:
>
> mvn -P openwire-generate generate-sources
>
> This will at least try and generate the sources, the profile
> configuration tells it what the highest version is to generate in an ant
> task which needs to be moved to an ant target now as task is deprecated
> and will fall on its face until you do so.  Then it will actually try
> and do something, so if you added openwire v13 you'd change it or leave
> it at v12 and see if you can generate matching output and run the above
> command at which point it will fall on its face if you are on JDK 17 as
> the underlying javadoc types used by the generator are relocated to
> 'jdk.javadoc.doclet' and renamed or refactored into something close but
> not quite the same.  So then you run it on JDK 11 and it will fall on
> its face with an NPE that I didn't bother to look deeper into but at
> least you have a starting point.
>
> Likely the ancient annogen and gram stuff just won't work on a newer
> JDK, you could try running it on lower versions but the maven
> configuration will likely be unhappy as the compiler configuration is
> set to target 11 currently.
>
> Hopefully that at least gets you pointed in the right direction,
> frustrating as it may be.
>
>
> >
> > On Wed, Aug 23, 2023 at 4:30 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> So maybe the activemq-openwire project should just be deprecated and go
> >> away since it is not used or maintained.
> >>
> >> It has been several years now but I'm pretty sure I just used the
> >> activemq-openwire-generator 5.x module (as Tim mentioned) to generate
> the
> >> latest v12 Openwire version that is in use today.
> >>
> >>
> https://github.com/apache/activemq/commit/3953b9aaefaee914bdd0702f27aef47c021ceb27
> >>
> >> On Tue, Aug 22, 2023 at 5:49 PM Arthur Naseef  wrote:
> >>
> >>> Thank you Tim.  That helps.
> >>>
> >>> Art
> >>>
> >>>
> >>> On Tue, Aug 22, 2023 at 2:23 PM Timothy Bish 
> >> wrote:
> >>>> On 8/22/23 15:28, Arthur Naseef wrote:
> >>>>> I'd like to ask first to get some clarification.
> >>>>>
> >>>>> Using the activemq-openwire project, I was able to get it to generate
> >>>>> openwire Java code, but that code did not exactly match the code in
> >> the
> >>>>> activemq codebase.  It appeared to be mostly non-functional
> >>> differences,
> >>>>> such as packages being renamed, and import statements vs.
> >>> full-qualified
> >>>>> class names in the code.
> >>>>>
> >>>>> Here are my questions:
> >>>>>
> >>>>>  - What is the process for building and releasing a new version
> of
> >>> the
> >>>>>  openwire protocol?
> >>>> There is no process other than running the generator in the ActiveMQ
> >>>> tree if you can get it to run, I don't recall if there's anything
> >>>> written down now that explains it as it has been years since I touched
> >>>> it and my memory is foggy.  I vaguely recall there being an antrun
> >>>> target in the pom file to run the generator so something like 'mvn
> >>>> antrun:run'.
> >>>>
> >>>> possibly some insights here:
> >>>>
> >>>>
> >>
> https://github.com/apache/activemq-nms-openwire-generator/blob/d16ff371fecade87f97942cdf0174ab790bc999c/pom.xml#L172
> >>>>
> >>>>>  - Where are the NMS and C++ parts generated?  Are there others
> >>>> generated
> >>>>>  as well?
> >>>> I already answered this, please read my previous response.
> >>>>
> >>>>

Re: Home for activemq-openwire

[Arthur Naseef]

That sounds right.  My 2cents - it would be nice to figure out the closest
thing to a working flow that we can get, and then worry about cleanup.

Art


On Wed, Aug 23, 2023 at 4:30 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> So maybe the activemq-openwire project should just be deprecated and go
> away since it is not used or maintained.
>
> It has been several years now but I'm pretty sure I just used the
> activemq-openwire-generator 5.x module (as Tim mentioned) to generate the
> latest v12 Openwire version that is in use today.
>
> https://github.com/apache/activemq/commit/3953b9aaefaee914bdd0702f27aef47c021ceb27
>
> On Tue, Aug 22, 2023 at 5:49 PM Arthur Naseef  wrote:
>
> > Thank you Tim.  That helps.
> >
> > Art
> >
> >
> > On Tue, Aug 22, 2023 at 2:23 PM Timothy Bish 
> wrote:
> >
> > > On 8/22/23 15:28, Arthur Naseef wrote:
> > > > I'd like to ask first to get some clarification.
> > > >
> > > > Using the activemq-openwire project, I was able to get it to generate
> > > > openwire Java code, but that code did not exactly match the code in
> the
> > > > activemq codebase.  It appeared to be mostly non-functional
> > differences,
> > > > such as packages being renamed, and import statements vs.
> > full-qualified
> > > > class names in the code.
> > > >
> > > > Here are my questions:
> > > >
> > > > - What is the process for building and releasing a new version of
> > the
> > > > openwire protocol?
> > >
> > > There is no process other than running the generator in the ActiveMQ
> > > tree if you can get it to run, I don't recall if there's anything
> > > written down now that explains it as it has been years since I touched
> > > it and my memory is foggy.  I vaguely recall there being an antrun
> > > target in the pom file to run the generator so something like 'mvn
> > > antrun:run'.
> > >
> > > possibly some insights here:
> > >
> > >
> >
> https://github.com/apache/activemq-nms-openwire-generator/blob/d16ff371fecade87f97942cdf0174ab790bc999c/pom.xml#L172
> > >
> > >
> > > > - Where are the NMS and C++ parts generated?  Are there others
> > > generated
> > > > as well?
> > >
> > > I already answered this, please read my previous response.
> > >
> > >
> > > > - How much manual intervention is needed in that process (e.g.
> are
> > > the
> > > > java files generated, then copied and editted before being
> > committed
> > > in the
> > > > main project)?
> > >
> > > I don't recall anymore if there is much intervention needed other than
> > > generating the new marshallers but I do recall that KahaDB has some
> > > settings that indicate which version it uses as a baseline.  I'd look
> at
> > > git commits in the 5.x code around the marshaller version code and see
> > > what was touched in the commit.
> > >
> > >
> > > >
> > > > Art
> > > >
> > > >
> > > > On Tue, Aug 22, 2023 at 12:22 PM Matt Pavlovich 
> > > wrote:
> > > >
> > > >> Hi-
> > > >>
> > > >> The activmeq-openwire project is currently hosted in a separate git
> > > >> repository. The project is used to generate marshaller classes for
> > > multiple
> > > >> languages and would be suitable for supporting multi-broker openwire
> > > >> support as well (5.x and Artemis). However, it does not appear to be
> > > active
> > > >> in any build lifecycle or toolchain for any of the ActiveMQ
> projects.
> > > >>
> > > >> I propose that we host the activemq-openwire project in the main 5.x
> > > tree
> > > >> for a couple reasons:
> > > >>
> > > >> 1. JDK changes and overall maintenance is easier from a single repo.
> > We
> > > >> can add notes able compatibility or a README-VERSIONS.md to note
> what
> > > >> product releases go to which protocol versions, and when those
> > protocol
> > > >> versions changed.
> > > >>
> > > >> 2. ActiveMQ 5.x uses openwire as its internal native protocol. It
> > makes
> > > >> sense to host it there, especially of things like enhancements to
> > > network
> > > >> connector commands, which other client libraries and brokers usually
> > do
> > > not
> > > >> adopt fully.
> > > >>
> > > >> 3. There are planned enhancements coming that most likely require
> > > openwire
> > > >> version bumps:
> > > >>  - JMS 2.0 support features
> > > >>  - Replication support (using Network Connectors)
> > > >>
> > > >> Discuss.
> > > >>
> > > >> Thank you,
> > > >> Matt Pavlovich
> > > >>
> > > >>
> > >
> > > --
> > > Tim Bish
> > >
> > >
> >
>

Re: Home for activemq-openwire

[Arthur Naseef]

Thank you Tim.  That helps.

Art


On Tue, Aug 22, 2023 at 2:23 PM Timothy Bish  wrote:

> On 8/22/23 15:28, Arthur Naseef wrote:
> > I'd like to ask first to get some clarification.
> >
> > Using the activemq-openwire project, I was able to get it to generate
> > openwire Java code, but that code did not exactly match the code in the
> > activemq codebase.  It appeared to be mostly non-functional differences,
> > such as packages being renamed, and import statements vs. full-qualified
> > class names in the code.
> >
> > Here are my questions:
> >
> > - What is the process for building and releasing a new version of the
> > openwire protocol?
>
> There is no process other than running the generator in the ActiveMQ
> tree if you can get it to run, I don't recall if there's anything
> written down now that explains it as it has been years since I touched
> it and my memory is foggy.  I vaguely recall there being an antrun
> target in the pom file to run the generator so something like 'mvn
> antrun:run'.
>
> possibly some insights here:
>
> https://github.com/apache/activemq-nms-openwire-generator/blob/d16ff371fecade87f97942cdf0174ab790bc999c/pom.xml#L172
>
>
> > - Where are the NMS and C++ parts generated?  Are there others
> generated
> > as well?
>
> I already answered this, please read my previous response.
>
>
> > - How much manual intervention is needed in that process (e.g. are
> the
> > java files generated, then copied and editted before being committed
> in the
> > main project)?
>
> I don't recall anymore if there is much intervention needed other than
> generating the new marshallers but I do recall that KahaDB has some
> settings that indicate which version it uses as a baseline.  I'd look at
> git commits in the 5.x code around the marshaller version code and see
> what was touched in the commit.
>
>
> >
> > Art
> >
> >
> > On Tue, Aug 22, 2023 at 12:22 PM Matt Pavlovich 
> wrote:
> >
> >> Hi-
> >>
> >> The activmeq-openwire project is currently hosted in a separate git
> >> repository. The project is used to generate marshaller classes for
> multiple
> >> languages and would be suitable for supporting multi-broker openwire
> >> support as well (5.x and Artemis). However, it does not appear to be
> active
> >> in any build lifecycle or toolchain for any of the ActiveMQ projects.
> >>
> >> I propose that we host the activemq-openwire project in the main 5.x
> tree
> >> for a couple reasons:
> >>
> >> 1. JDK changes and overall maintenance is easier from a single repo. We
> >> can add notes able compatibility or a README-VERSIONS.md to note what
> >> product releases go to which protocol versions, and when those protocol
> >> versions changed.
> >>
> >> 2. ActiveMQ 5.x uses openwire as its internal native protocol. It makes
> >> sense to host it there, especially of things like enhancements to
> network
> >> connector commands, which other client libraries and brokers usually do
> not
> >> adopt fully.
> >>
> >> 3. There are planned enhancements coming that most likely require
> openwire
> >> version bumps:
> >>  - JMS 2.0 support features
> >>  - Replication support (using Network Connectors)
> >>
> >> Discuss.
> >>
> >> Thank you,
> >> Matt Pavlovich
> >>
> >>
>
> --
> Tim Bish
>
>

Re: Home for activemq-openwire

[Arthur Naseef]

Tim - can you help answer the questions from my email above?  Are there
notes/documents anywhere that help?

Art

On Tue, Aug 22, 2023 at 12:28 PM Arthur Naseef  wrote:

> I'd like to ask first to get some clarification.
>
> Using the activemq-openwire project, I was able to get it to generate
> openwire Java code, but that code did not exactly match the code in the
> activemq codebase.  It appeared to be mostly non-functional differences,
> such as packages being renamed, and import statements vs. full-qualified
> class names in the code.
>
> Here are my questions:
>
>- What is the process for building and releasing a new version of the
>openwire protocol?
>- Where are the NMS and C++ parts generated?  Are there others
>generated as well?
>- How much manual intervention is needed in that process (e.g. are the
>java files generated, then copied and editted before being committed in the
>main project)?
>
> Art
>
>
> On Tue, Aug 22, 2023 at 12:22 PM Matt Pavlovich 
> wrote:
>
>> Hi-
>>
>> The activmeq-openwire project is currently hosted in a separate git
>> repository. The project is used to generate marshaller classes for multiple
>> languages and would be suitable for supporting multi-broker openwire
>> support as well (5.x and Artemis). However, it does not appear to be active
>> in any build lifecycle or toolchain for any of the ActiveMQ projects.
>>
>> I propose that we host the activemq-openwire project in the main 5.x tree
>> for a couple reasons:
>>
>> 1. JDK changes and overall maintenance is easier from a single repo. We
>> can add notes able compatibility or a README-VERSIONS.md to note what
>> product releases go to which protocol versions, and when those protocol
>> versions changed.
>>
>> 2. ActiveMQ 5.x uses openwire as its internal native protocol. It makes
>> sense to host it there, especially of things like enhancements to network
>> connector commands, which other client libraries and brokers usually do not
>> adopt fully.
>>
>> 3. There are planned enhancements coming that most likely require
>> openwire version bumps:
>> - JMS 2.0 support features
>> - Replication support (using Network Connectors)
>>
>> Discuss.
>>
>> Thank you,
>> Matt Pavlovich
>>
>>

Re: Home for activemq-openwire

[Arthur Naseef]

I'd like to ask first to get some clarification.

Using the activemq-openwire project, I was able to get it to generate
openwire Java code, but that code did not exactly match the code in the
activemq codebase.  It appeared to be mostly non-functional differences,
such as packages being renamed, and import statements vs. full-qualified
class names in the code.

Here are my questions:

   - What is the process for building and releasing a new version of the
   openwire protocol?
   - Where are the NMS and C++ parts generated?  Are there others generated
   as well?
   - How much manual intervention is needed in that process (e.g. are the
   java files generated, then copied and editted before being committed in the
   main project)?

Art


On Tue, Aug 22, 2023 at 12:22 PM Matt Pavlovich  wrote:

> Hi-
>
> The activmeq-openwire project is currently hosted in a separate git
> repository. The project is used to generate marshaller classes for multiple
> languages and would be suitable for supporting multi-broker openwire
> support as well (5.x and Artemis). However, it does not appear to be active
> in any build lifecycle or toolchain for any of the ActiveMQ projects.
>
> I propose that we host the activemq-openwire project in the main 5.x tree
> for a couple reasons:
>
> 1. JDK changes and overall maintenance is easier from a single repo. We
> can add notes able compatibility or a README-VERSIONS.md to note what
> product releases go to which protocol versions, and when those protocol
> versions changed.
>
> 2. ActiveMQ 5.x uses openwire as its internal native protocol. It makes
> sense to host it there, especially of things like enhancements to network
> connector commands, which other client libraries and brokers usually do not
> adopt fully.
>
> 3. There are planned enhancements coming that most likely require openwire
> version bumps:
> - JMS 2.0 support features
> - Replication support (using Network Connectors)
>
> Discuss.
>
> Thank you,
> Matt Pavlovich
>
>

Re: Artemis client can't connect to Artemis server

[Arthur Naseef]

David:

Please re-post this message on the user mailing list.

The DEV mailing list is for development of ActiveMQ itself, and not
applications using ActiveMQ.

Art


On Thu, Jun 29, 2023 at 9:54 AM David Hoffer  wrote:

> Hi,
>
> We have a Quarkus app where we embed an Artemis server, we were using
> 2.27.1.  We were connecting to it via quarkus-artemis-jms 1.0.3 which I see
> now is very old.  This stopped working and strangely it stopped working
> when it tried to create the activemq working directories.
>
> I have tried upgrading to quarkus-artemis-jms 2.1.1 but strangely that
> version can't read our quarkus properties correctly.  It reads the wrong
> value for build time is devervices enabled and wrong value for url
> setting.  Can't figure that one out.  So we get this error:
>
> new IllegalStateException(String.format(
> "Configuration %s: url is not set and devservices is
> activated. This is a bug. Please report it.", name));
>
> So taking a step back here I'm thinking we don't have the correct
> dependencies in our build.  Can you point me to the correct way to include
> both the artemis server and the artemis client jars?  E.g. is there a BOM
> for these?
>
> We are using Quarkus 2.16.7
> JDK 11
> We would prefer to use the latest known stable versions of Artemis server
> and client components, but most important is that they work together
> properly.
>
> Thanks,
> -David
>
> P.S. Here is the error log when it fails to generate the working
> folders/files.  Note the broker.xml file does exist, no idea why that shows
> as a warning.
>
> 14:07:17,414 dhoffe-bstaq-pc ./target/udl-runner.jar[10576] WARN
>  [org.apa.act.art.cor.server] (main) AMQ19: File
> file:\C:\projects\udl\target\udl-runner.jar!\broker.xml does not exist
> 2023-06-26 14:07:17,426 dhoffe-bstaq-pc ./target/udl-runner.jar[10576] INFO
>  [org.apa.act.art.cor.server] (main) AMQ221034: Waiting indefinitely to
> obtain live lock
> 2023-06-26 14:07:17,426 dhoffe-bstaq-pc ./target/app-runner.jar[10576] INFO
>  [org.apa.act.art.cor.server] (main) AMQ221035: Live Server Obtained live
> lock
> 2023-06-26 14:07:17,434 dhoffe-bstaq-pc ./target/udl-runner.jar[10576] WARN
>  [org.apa.act.art.journal] (main) AMQ142018: Temporary files were left
> unattended after a crash on journal directory, deleting invalid files now
> 2023-06-26 14:07:17,434 dhoffe-bstaq-pc ./target/app-runner.jar[10576] WARN
>  [org.apa.act.art.journal] (main) AMQ142019: Deleting orphaned file
> activemq-bindings-4.bindings.tmp
> 2023-06-26 14:07:17,492 dhoffe-bstaq-pc ./target/udl-runner.jar[10576]
> ERROR [org.apa.act.art.cor.server] (main) AMQ224000: Failure in
> initialisation: java.lang.IndexOutOfBoundsException
> at java.base/java.nio.Buffer.checkIndex(Buffer.java:687)
> at java.base/java.nio.DirectByteBuffer.put(DirectByteBuffer.java:344)
> at
>
> org.apache.activemq.artemis.utils.ByteUtil.uncheckedZeros(ByteUtil.java:512)
> at org.apache.activemq.artemis.utils.ByteUtil.zeros(ByteUtil.java:494)
> at
>
> org.apache.activemq.artemis.core.io.util.ThreadLocalByteBufferPool.borrow(ThreadLocalByteBufferPool.java:47)
> at
>
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.newBuffer(NIOSequentialFileFactory.java:150)
> at
>
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.newBuffer(NIOSequentialFileFactory.java:142)
> at
>
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.fill(NIOSequentialFile.java:170)
> at
>
> org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile0(JournalFilesRepository.java:655)
> at
>
> org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile(JournalFilesRepository.java:611)
> at
>
> org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.ensureMinFiles(JournalFilesRepository.java:220)
> at
>
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.setUpCurrentFile(JournalImpl.java:3454)
> at
>
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:2288)
> at
>
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:2340)
> at
>
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1669)
> at org.apache.activemq.artemis.core.journal.Journal.load(Journal.java:278)
> at
>
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadBindingJournal(AbstractJournalStorageManager.java:1515)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3643)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3324)
> at
>
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:684)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQSer

Re: [VOTE] Release activemq-nms-amqp 2.2.0-rc1

[Arthur Naseef]

+1

Art


On Sun, May 7, 2023 at 7:32 AM  wrote:

> +1
>
> Jeff
>
>
> > On May 7, 2023, at 2:09 AM, Havret  wrote:
> >
> > FYI
> >
> > -- Forwarded message -
> > From: Jean-Baptiste Onofré mailto:j...@nanthrax.net>>
> > Date: Sun, May 7, 2023 at 7:02 AM
> > Subject: Re: [VOTE] Release activemq-nms-amqp 2.2.0-rc1
> > To: mailto:dev@activemq.apache.org>>
> >
> >
> > +1 (binding)
> >
> > Regards
> > JB
> >
> > On Sat, May 6, 2023 at 8:58 PM Havret  hav...@apache.org>> wrote:
> > >
> > > Hi all,
> > >
> > > I have put together another release of activemq-nms-amqp. Please
> review it
> > > and vote accordingly.
> > >
> > > This update enhances the message acknowledgement functionality by
> > > supporting multiple AckType's, This improvement enables clients to
> utilize
> > > broker redelivery configurations automatically and aligns the client
> > > library more closely with the qpid-jms counterpart.
> > >
> > > This release contains the following change:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&version=12353210
> > >
> > > The files can be grabbed from:
> > > *
> https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/2.2.0-rc1/
> > > <
> https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/2.2.0-rc1/
> >*
> > >
> > > Regards,
> > > Krzysztof
> > >
> > > Here's mine +1 (binding)
>
>

Re: wildfly 26.1.2 support

[Arthur Naseef]

Please ask this question on the user mailing list.  The dev mailing list is
for discussion of development/maintainenance of the ActiveMQ / Artemis code
bases themselves.

Art


On Fri, Mar 17, 2023 at 2:47 PM Walter Krix (Nokia) 
wrote:

> Dear ActiveMQ Artemis Developers,
>
>
> I am writing to inquire about the setup of the ActiveMQ Artemis subsystem
> in Wildfly 26.1.2. Specifically, I am interested in configuring Artemis to
> work without serialization/deserialization.
>
>
> I would greatly appreciate it if you could provide me with information on
> how to achieve this configuration, if it is possible at all. Any guidance,
> documentation or resources you can offer to assist me in this matter would
> be most helpful.
>
>
> Thank you for your time and attention to this matter. I look forward to
> hearing back from you soon.
>
>
> Sincerely,
>
> Walter Krix
>

Re: [VOTE] Release activemq-nms-amqp 2.1.0-rc1

[Arthur Naseef]

+1 (binding)

Built and did a quick comparison of the file sizes in the published zip.

Art


On Wed, Mar 15, 2023 at 9:21 AM Clebert Suconic 
wrote:

> (hmm.. I had already sent the previous +1, sorry, I thought this was
> another spin or something).
>
> please make sure you only consider one vote from me.. my bad
>
> On Wed, Mar 15, 2023 at 12:19 PM Clebert Suconic
>  wrote:
> >
> > +1
> >
> > On Wed, Mar 15, 2023 at 9:42 AM Michael André Pearce
> >  wrote:
> > >
> > > +1  (Binding0
> > >
> > > Best
> > > Mike
> > >
> > > On 2023/03/12 21:21:41 Clebert Suconic wrote:
> > > > +1
> > > >
> > > > On Sun, Mar 12, 2023 at 6:27 AM Havret  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I have put together another release of activemq-nms-amqp. Please
> review it
> > > > > and vote accordingly.
> > > > >
> > > > > This release includes an important new feature that allows users
> to specify
> > > > > an allow/deny list of types for binary serialization. This can
> help prevent
> > > > > potential security vulnerabilities.
> > > > >
> > > > > The feature is implemented in the same way as in qpid-jms, using a
> > > > > deserialization policy that controls which types can be trusted for
> > > > > deserialization from an incoming NMS IObjectMessage containing
> serialized
> > > > > .NET Object content. By default, all types are trusted during
> > > > > deserialization. However, the default Deserialization Policy object
> > > > > provides URI options for specifying an allow list and a deny list
> of .NET
> > > > > classes or namespaces.
> > > > >
> > > > > The following options are available:
> > > > >
> > > > > - nms.deserializationPolicy.allowList: A comma-separated list of
> > > > > classes/namespaces that are allowed during deserialization, unless
> they are
> > > > > overridden by the deny list. Names in this list are not pattern
> values; the
> > > > > exact class or namespace name must be configured (e.g.
> > > > > "System.Collections.Queue" or "System.Collections"). Namespace
> matches
> > > > > include sub-namespaces. The default is to allow all.
> > > > > - nms.deserializationPolicy.denyList: A comma-separated list of
> > > > > classes/namespaces that are rejected during deserialization. Names
> in this
> > > > > list are not pattern values; the exact class or namespace name
> must be
> > > > > configured (e.g. "System.Collections.Queue" or
> "System.Collections").
> > > > > Namespace matches include sub-namespaces. The default is to reject
> none.
> > > > >
> > > > > This release contains the following change:
> > > > >
> > > > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201&version=12353001
> > > > >
> > > > > The files can be grabbed from:
> > > > >
> > > > >
> https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/2.1.0-rc1/
> > > > >
> > > > > Regards,
> > > > > Chris
> > > > >
> > > > > Here's mine +1 (binding)
> > > > >
> > > > --
> > > > Clebert Suconic
> > > >
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>

Re: [Discuss] automated github messages on a separate list

[Arthur Naseef]

Hey Justin - looks like I'm living in the past on this topic.  OK, I
figured out what's going on.

I had a filter for the gitbox messages going into a separate gmail
folder/label.  Now that I'm looking at it carefully, all of the content in
there is ancient.  SO, it appears when the gitbox notifications got moved
to another list, this just went stale and I never paid any real attention
to it.

Now I've revived it.  Apologies for the confusion, and thanks for helping
to clear it up.

I'm going to remove all filters for the DEV list and if anything odd comes
up, I'll look into it.

Art




On Tue, Mar 7, 2023 at 10:18 AM Justin Bertram  wrote:

> Art, can you clarify the "hint, hint"? Perhaps I missed some context
> somewhere. The GitBox emails stopped hitting the dev list over 4 years ago
> now. Are you saying that you haven't looked over the dev list in 4 years?
> :-)
>
>
> Justin
>
> On Tue, Mar 7, 2023 at 11:01 AM Arthur Naseef  wrote:
>
> > Just saw this from a rare look over DEV list messages (hint hint) ;-).
> >
> > So glad to see this action.  Easy-to-Use is top priority, and a dev list
> > that requires filtering to use - why?  Just why?
> >
> > Art
> >
> >
> > On Thu, Mar 14, 2019 at 11:40 AM jgenender  wrote:
> >
> > > +1 to github notifications on another list.  It does indeed drown out
> the
> > > communication here and not everyone can use a filter.  I use Nabble, so
> > its
> > > not as easy.
> > >
> > > Jeff
> > >
> > >
> > >
> > > --
> > > Sent from:
> > > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
> > >
> >
>

Re: [Discuss] automated github messages on a separate list

[Arthur Naseef]

Just saw this from a rare look over DEV list messages (hint hint) ;-).

So glad to see this action.  Easy-to-Use is top priority, and a dev list
that requires filtering to use - why?  Just why?

Art


On Thu, Mar 14, 2019 at 11:40 AM jgenender  wrote:

> +1 to github notifications on another list.  It does indeed drown out the
> communication here and not everyone can use a filter.  I use Nabble, so its
> not as easy.
>
> Jeff
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>

Re: Versions no longer supported (EOL) of ActiveMq Artemis

[Arthur Naseef]

Please send this message to the user list.  The dev list is reserved for
discussions related to the development (e.g. code changes) of the broker
itself.

Thank you.

Art


On Thu, Mar 2, 2023 at 8:26 AM Rhea MOUBARAK  wrote:

> Hello,
>
>
>
> I am trying to look everywhere for the versions of ActiveMq Artemis that
> are no longer supported, and I can't find any.
>
>
>
> Does any of you know which versions are not supported anymore?
>
>
>
> Thank you for your help.
>
>
>
> Best,
>
> Rhea MOUBARAK
>
>
>

Re: DISCUSS: Memory Leak Test...

[Arthur Naseef]

Yeah, Sontatype OSSRH is a little involved to get going, but not too bad.
I use it (for example
https://mvnrepository.com/artifact/com.artnaseef/correlation-id-utils).

On Mon, Nov 7, 2022 at 4:20 AM Robbie Gemmell 
wrote:

> You can release stuff to Maven Central via Sonatype OSSRH,
> https://central.sonatype.org/publish/publish-guide/
>
> For example by using your GitHub Pages details for the groupid
> coordinates i.e. io.github.your-id, among other options:
>
> https://central.sonatype.org/publish/requirements/coordinates/#supported-code-hosting-services-for-personal-groupid
>
> On Sun, 6 Nov 2022 at 10:10, Domenico Francesco Bruscino
>  wrote:
> >
> > JitPack is free for open-source projects and it doesn't require
> > authentication to download artifacts, see https://jitpack.io/
> >
> > Another free alternative for open-source projects is GitHub Packages but
> it
> > requires authentication, see
> >
> https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry
> >
> >
> > On Sat, 5 Nov 2022 at 17:15, Clebert Suconic 
> > wrote:
> >
> > > getAllReachableObjects is somewhat easy to implement in C.
> > >
> > > I will try to pursue my own implementation.. and if we fail we have a
> > > failback on the jetbrains route.
> > >
> > >
> > > there are some reporting things I'm doing to show where are eventual
> leaks.
> > >
> > >
> > >
> > > I worked on a test with Justin, and we asserted noObjects in the heap
> > > and it worked like a charm.
> > >
> > >
> > > I just need to find a way to deploy a maven repo somewhere.
> > >
> > > On Sat, Nov 5, 2022 at 11:13 AM Jiri Daněk  wrote:
> > > >
> > > > On Sat, Nov 5, 2022 at 4:00 PM Clebert Suconic <
> > > clebert.suco...@gmail.com>
> > > > wrote:
> > > >
> > > > > There are of course tools that would been written before. I have
> not
> > > > > seen anything that would be as simple as I'm proposing (with the
> > > > > exception of the .NET where you can get a list of objects).
> > > > >
> > > >
> > > > Yes! It is weird that C#, Python, JavaScript, all have a simple way
> to
> > > list
> > > > heap objects, only in Java it seems soo hard to do.
> > > >
> > > >
> > > > > What I'm doing is based on the JBoss Profiler that I wrote many
> years
> > > > > ago (and I left it rotten and dead)... so this would revive the
> simple
> > > > > parts just for the JUnit Tests.
> > > > >
> > > >
> > > > Yeah, I linked it in my previous mail. I was thinking that the code
> looks
> > > > somewhat similar, except it's in C and not C++...
> > > >
> > > >
> > > > > You just get a simple list of Objects before and later.
> > > > >
> > > > >
> > > > > Regarding the criticism to JMVTI.. I have it already written,
> besides
> > > > > any tooling around Java and Debugging will require C dev...
> > > > >
> > > > >
> > > > > the project itself already exists.. and I think it's viable. I am
> > > > > looking for options to host it, while you seem to be looking for
> > > > > counter arguments for having it done?
> > > > >
> > > >
> > > > I'm just writing up the results of my explorations. Initially I
> hoped to
> > > > learn what is possible. Best case would be I found something that's
> > > already
> > > > written and hosted, and that does not include native code (think all
> > > those
> > > > possible build/compatibility issues) that did not really
> happen...
> > > >
> > > > Some tests can be written using the weakref approach, but that has
> > > limited
> > > > use for only specific scenarios. The dumping and reading of hprof
> file
> > > > might work, but I did not find a good Java implementation (Shark is
> in
> > > > Kotlin). The jetbrains JVMTI library looks reasonable, on a first
> sight,
> > > > though.
> > > >
> > > >
> > > > > if you give me an alternative in Java where i can do
> > > > > jvmti.getallObject(clazz); and eventually list the references for
> it..
> > > > > perhaps I could just use that option instead. Such thing will be
> > > > > written in C anyways.
> > > > >
> > > >
> > > > https://github.com/JetBrains/debugger-memory-agent
> > > >
> > > > MemoryAgent ma = MemoryAgent.get();
> > > > if (ma == null) { /* handle failure to load */ }
> > > > ma.getAllReachableObjects(null, clazz);
> > > > --
> > > > Mit freundlichen Grüßen / Kind regards
> > > > Jiri Daněk
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
>

Re: [DISCUSS] Remove shaded client JARS

[Arthur Naseef]

Making use simple for users is a good thing.  On the other hand, there are
a lot of target environments that could use different tweaks.  Our
dependency-management tool is maven.

If folks want to work outside of maven, that's their choice, but then
dependency management becomes a problem for that case.

Is it worth the effort, and added complexity, to maintain the uber jar?

Art

On Wed, Jul 27, 2022 at 7:57 AM Michael André Pearce
 wrote:

> So as the person who added the shaded jars, this was a requirement to make
> it far easier for those who DO NOT use tools like maven to be able to build
> an application without having to copy a large dependency tree of libs,
> which yes for maven or gradle is fine as they handle the dependency tree,
> as those tools do this. But unfortunately we don't live in a perfect world,
> and providing the shaded allows those users to use the client.
>
> Im happy to look at why moving logging to slf4j brings an issue, im unsure
> why it does tbh, its just another lib, and as long as you shade correctly
> it should be fine, ive seen it shaded in many other projects.
>
> With this i am going on leave for a bit, so unlikely i will get to have a
> look at it for a week or two.
>
> Best
> Mike
>
> On 26 Jul 2022, at 21:44, Justin Bertram  wrote:
>
>
> To be clear, the documentation already exists [1]. It just needs to be
> updated with the aforementioned details when the uber jars are removed.
>
>
> Justin
>
> [1]
>
> https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html
>
> On Tue, Jul 26, 2022 at 3:39 PM Clebert Suconic  >
> wrote:
>
> sure, of course we need to update the docs in relation to anything
> these removed jars. What I meant was we need to document the jars that
> are required independently of removing the jars.. if someone wants to
> use the client jars the client dependency should be documented anyway.
> that's what I meant
>
> On Tue, Jul 26, 2022 at 3:25 PM Justin Bertram 
> wrote:
> >
> > I'm not sure what you mean by "independent issue." If we remove the uber
> > jars then the docs have to be updated. The two things are directly
> related,
> > right?
> >
> >
> > Justin
> >
> > On Tue, Jul 26, 2022 at 2:13 PM Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> > > I think that’s an independent issue. The doc would need to be updated
> > > anyways.
> > >
> > > On Tue, Jul 26, 2022 at 2:40 PM Justin Bertram 
> > > wrote:
> > >
> > > > Yes, the documentation needs to be clear. This is a usability issue.
> > > >
> > > > Even if you did a "mvn dependency:list" you'd get a list including
> > > optional
> > > > and test dependencies. Also, there would be potentially unnecessary
> > > > dependencies (e.g. netty-transport-native-kqueue even if you aren't
> on a
> > > > Mac).
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Tue, Jul 26, 2022 at 1:30 PM Clebert Suconic <
> > > clebert.suco...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > the pom on artemis-core-client, artemis-jms-client, and
> > > > > artemis-jakarta-client... They will include all the needed
> > > > > dependencies, right?
> > > > >
> > > > >
> > > > > what is the issue? to have a clear text on the docs?
> > > > >
> > > > > On Tue, Jul 26, 2022 at 2:01 PM Justin Bertram <
> jbert...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > The original impetus for the uber jar was ARTEMIS-1129. The issue
> > > there
> > > > > was
> > > > > > that it wasn't clear what jars were needed on the client. If we
> > > remove
> > > > > the
> > > > > > uber jars then we need to update the documentation to make
> crystal
> > > > clear
> > > > > > what jars are needed on the client, including details about what
> jars
> > > > may
> > > > > > be optional depending on which functionality the client uses.
> > > > > >
> > > > > > I'm not necessarily against it, but removing the uber jar is
> probably
> > > > > going
> > > > > > to sting for a handful of users. Anything we can do to alleviate
> that
> > > > > will
> > > > > > help. Maybe we could generate a text file in lib/client instead
> of
> > > the
> > > > > uber
> > > > > > jars to help users who expect them to be there. The text could
> list
> > > the
> > > > > > jars required for the client's classpath.
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-1129
> > > > > >
> > > > > > On Tue, Jul 26, 2022 at 8:40 AM Clebert Suconic <
> > > > > clebert.suco...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > We currently deploy these following shaded uber jars with
> ActiveMQ
> > > > > Artemis.
> > > > > > >
> > > > > > > artemis-jms-client-all
> > > > > > > artemis-core-client-all
> > > > > > > artemis-jakarta-client-all
> > > > > > >
> > > > > > > We are in the process of removing jboss-logging, and replacing
> it
> > > by
> > > > > > > SLF4j /LOG4J on a separate branch, and we will probably make a
> > > switch
> > > > > > > on the branch as 3.0.

Re: [DISCUSS] Remove shaded client JARS

[Arthur Naseef]

+1 for eliminating shaded jars/bundles where possible

On Tue, Jul 26, 2022 at 10:16 AM Timothy Bish  wrote:

> +1
>
> Removing them seems valid given the issues noted.
>
> On 7/26/22 12:18, Robbie Gemmell wrote:
> > I think removing them would be good for various reasons inc all you
> noted below.
> >
> > On Tue, 26 Jul 2022 at 14:34, Clebert Suconic 
> wrote:
> >> We currently deploy these following shaded uber jars with ActiveMQ
> Artemis.
> >>
> >> artemis-jms-client-all
> >> artemis-core-client-all
> >> artemis-jakarta-client-all
> >>
> >> We are in the process of removing jboss-logging, and replacing it by
> >> SLF4j /LOG4J on a separate branch, and we will probably make a switch
> >> on the branch as 3.0.
> >>
> >> I never really liked these shaded jars as part of the distribution. I
> >> would be inclined to remove them on a switch for 3.0 anyways, and now
> >> we are having a build issue,
> >> as they will fail (on a second build) shading apache-commons-logging:
> >>
> >> ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-shade-plugin:3.3.0:shade (default) on
> >> project artemis-core-client-all: Error creating shaded jar: duplicate
> >> entry: META-INF/services/org.apache.activemq.artemis.shaded.org
> .apache.commons.logging.LogFactory
> >> -> [Help 1] [ERROR]  [ERROR] To see the full stack trace of the
> >> errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using
> >> the -X switch to enable full debug logging. [ERROR]  [ERROR] For more
> >> information about the errors and possible solutions, please read the
> >> following articles: [ERROR] [Help 1]
> >> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> >> [ERROR]  [ERROR] After correcting the problems, you can resume the
> >> build with the command [ERROR]   mvn  -rf
> >> :artemis-core-client-all
> >>
> >>
> >>
> >>
> >> Also, they add about 20MB to our distribution, and more 10MB for the
> >> core-client-all that's not on the distro but it is on maven repo.
> >>
> >> This is a common trend with other projects. Netty stopped producing a
> >> netty-all and is offering a pom. Jetty did the same thing.. and There
> >> are a lot of issues introduced by an "all client".
> >>
> >>
> >> So, even though we could fix the build, these JARs are never tested as
> >> part of the testsuite or anything It's like playing with the
> >> odds...  and they are huge on the distribution as they will all
> >> include copies of Netty.
> >>
> >>
> >> I would really like to remove these JARs and I think it would be a
> >> great improvement to do so.
> >>
> >> These POMS are already defining all the dependencies anyway. Any user
> >> who wants to have a shaded jar would just be able to shade it
> >> themselves as part of their project.
> >>
> >>
> >> If anyone  have a strong feeling about keeping them we would need:
> >>
> >> - your opinion (why we keep them on 3.0)
> >> - Help fixing the build on new-logging
> >> - Help with adding smoke tests for these jars.
> >>
> >>
> >> anyone?
>
>
> --
> Tim Bish
>
>

Re: https://issues.apache.org/jira/browse/AMQ-8971 - Karaf activemq-client feature in 5.16.3+

[Arthur Naseef]

Sounds good - thank you JB.

On Sun, Jul 24, 2022 at 12:07 AM Jean-Baptiste Onofré 
wrote:

> Thanks for the test app. I will test with my PR.
>
> I will keep you posted.
>
> Regards
> JB
>
> Le sam. 23 juil. 2022 à 21:46, Arthur Naseef  a écrit :
>
> > Got the test application working, a PR with a fix that provides
> > simultaneous support for JMS 1.1 and JMS 2.0 via the same Karaf feature
> > (activemq-client).
> >
> > Please take a look at the comment on the ticket:
> > https://issues.apache.org/jira/browse/AMQ-8971
> >
> > The good news about this fix is that it fixes backward compatibility for
> > JMS 1.1 applications while retaining JMS 2.0 compatibility (i.e. does not
> > further break backward compatibility).
> >
> > Art
> >
> > On Wed, Jun 22, 2022 at 9:15 AM Arthur Naseef  wrote:
> >
> > > Still working on a test project - almost got it working.
> > >
> > > Art
> > >
> > >
> > > On Tue, Jun 21, 2022 at 8:27 AM Arthur Naseef  wrote:
> > >
> > >> Agreed on fixing it going forward and not simply reverting - that
> would
> > >> really just create another non-backward-compatible change and increase
> > the
> > >> size of the problem.  The 5.16.3 - 5.17.1 releases are already in this
> > >> state, and we can't fix that - hopefully anyone updating goes right
> for
> > the
> > >> latest (once we release a "fix"), and anyone else searching on the
> > problem
> > >> can find the jira ticket, this discussion, or similar resources which
> > can
> > >> point them at a work-around.
> > >>
> > >> I started writing a small test to reproduce the problem and try
> > solutions.
> > >>
> > >> For the idea of providing both spec bundles, that could be a decent
> > >> solution.  My only concern is that it could get messy for resolution
> > >> because there would be 2 sets of classes, from different bundles, that
> > >> could end up in the dependency chain.  In other words, some users
> could
> > >> have some bundles wire to the 1.1 spec bundle, others wire to the 2.0
> > spec
> > >> bundle, and any wiring amongst those would fail because their JMS
> > classes
> > >> aren't the same ones.  You know, the dreaded, because it is exposed to
> > >> package '...' from resources ... via two dependency chains.
> > >>
> > >> One solution I'm thinking here - use the feature file's "capability"
> to
> > >> advertise the existing JMS 2 spec as providing the JMS 1.1 packages.
> If
> > >> the JMS 2 classes are truly backward-compatible, I believe that could
> > "just
> > >> work" for both cases (JMS 1.1 and JMS 2.0 applications).
> > >>
> > >> Thoughts?
> > >>
> > >> Art
> > >>
> > >>
> > >> On Tue, Jun 21, 2022 at 7:50 AM Robbie Gemmell <
> > robbie.gemm...@gmail.com>
> > >> wrote:
> > >>
> > >>> I would fix it on 5.17.x as well unless theres some reason not to
> that
> > >>> im missing, it really seems no different than it is for 5.16.x.
> People
> > >>> can upgrade to 5.17.x from <=5.16.2 as well, and reasonably wouldnt
> > >>> expect to hit a breakage for this any more than they should on
> 5.16.x,
> > >>> since it also does not implement JMS 2 either.
> > >>>
> > >>> On Tue, 21 Jun 2022 at 15:36, Jean-Baptiste Onofré 
> > >>> wrote:
> > >>> >
> > >>> > Agree: I should not have changed on 5.16.x, keep it for 5.17.x.
> > >>> >
> > >>> > Now that it has been released, I think the best approach is to
> > provide
> > >>> both
> > >>> > spec bundles.
> > >>> >
> > >>> > Let me test and create PR.
> > >>> >
> > >>> > Regards
> > >>> > JB
> > >>> >
> > >>> > Le mar. 21 juin 2022 à 16:07, Robbie Gemmell <
> > robbie.gemm...@gmail.com>
> > >>> a
> > >>> > écrit :
> > >>> >
> > >>> > > The obvious "why not" answer would be however easy it is, its
> > perhaps
> > >>> > > not so obvious to people, and it certainly doesnt seem like it
> > should
> > >>

Re: https://issues.apache.org/jira/browse/AMQ-8971 - Karaf activemq-client feature in 5.16.3+

[Arthur Naseef]

Got the test application working, a PR with a fix that provides
simultaneous support for JMS 1.1 and JMS 2.0 via the same Karaf feature
(activemq-client).

Please take a look at the comment on the ticket:
https://issues.apache.org/jira/browse/AMQ-8971

The good news about this fix is that it fixes backward compatibility for
JMS 1.1 applications while retaining JMS 2.0 compatibility (i.e. does not
further break backward compatibility).

Art

On Wed, Jun 22, 2022 at 9:15 AM Arthur Naseef  wrote:

> Still working on a test project - almost got it working.
>
> Art
>
>
> On Tue, Jun 21, 2022 at 8:27 AM Arthur Naseef  wrote:
>
>> Agreed on fixing it going forward and not simply reverting - that would
>> really just create another non-backward-compatible change and increase the
>> size of the problem.  The 5.16.3 - 5.17.1 releases are already in this
>> state, and we can't fix that - hopefully anyone updating goes right for the
>> latest (once we release a "fix"), and anyone else searching on the problem
>> can find the jira ticket, this discussion, or similar resources which can
>> point them at a work-around.
>>
>> I started writing a small test to reproduce the problem and try solutions.
>>
>> For the idea of providing both spec bundles, that could be a decent
>> solution.  My only concern is that it could get messy for resolution
>> because there would be 2 sets of classes, from different bundles, that
>> could end up in the dependency chain.  In other words, some users could
>> have some bundles wire to the 1.1 spec bundle, others wire to the 2.0 spec
>> bundle, and any wiring amongst those would fail because their JMS classes
>> aren't the same ones.  You know, the dreaded, because it is exposed to
>> package '...' from resources ... via two dependency chains.
>>
>> One solution I'm thinking here - use the feature file's "capability" to
>> advertise the existing JMS 2 spec as providing the JMS 1.1 packages.  If
>> the JMS 2 classes are truly backward-compatible, I believe that could "just
>> work" for both cases (JMS 1.1 and JMS 2.0 applications).
>>
>> Thoughts?
>>
>> Art
>>
>>
>> On Tue, Jun 21, 2022 at 7:50 AM Robbie Gemmell 
>> wrote:
>>
>>> I would fix it on 5.17.x as well unless theres some reason not to that
>>> im missing, it really seems no different than it is for 5.16.x. People
>>> can upgrade to 5.17.x from <=5.16.2 as well, and reasonably wouldnt
>>> expect to hit a breakage for this any more than they should on 5.16.x,
>>> since it also does not implement JMS 2 either.
>>>
>>> On Tue, 21 Jun 2022 at 15:36, Jean-Baptiste Onofré 
>>> wrote:
>>> >
>>> > Agree: I should not have changed on 5.16.x, keep it for 5.17.x.
>>> >
>>> > Now that it has been released, I think the best approach is to provide
>>> both
>>> > spec bundles.
>>> >
>>> > Let me test and create PR.
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > Le mar. 21 juin 2022 à 16:07, Robbie Gemmell 
>>> a
>>> > écrit :
>>> >
>>> > > The obvious "why not" answer would be however easy it is, its perhaps
>>> > > not so obvious to people, and it certainly doesnt seem like it should
>>> > > be necessary. Those with things which only use JMS 1.1 and previously
>>> > > worked with <=5.16.2 (its not just 5.15.x upgraders affected) would
>>> > > not typically expect to be broken by a simple update to using
>>> 5.16.3+,
>>> > > or to necessarily understand they can work around the feature problem
>>> > > by using the JMS 2 spec when their stuff isnt using that and they are
>>> > > still clearly using a client implementing 1.1.
>>> > >
>>> > > If having both versions provided is possible, fixes simple upgrades
>>> > > for all the existing JMS 1.1 users on <= 5.16.2, and still allows
>>> > > those already working with JMS 2 to use it as now, then that would
>>> > > seem a reasonable middle ground. The spec jar isnt exactly a
>>> monstrous
>>> > > overhead after all, especially not compared to the client feature
>>> > > already supplying [most of] the broker etc.
>>> > >
>>> > > Or, you suggested earlier what would happen currently is it would
>>> only
>>> > > use/supply 2.0 unless something provided 1.1 first. Can it do th

Re: Need help

[Arthur Naseef]

That error can happen under normal (non-errant) conditions - are there
other symptoms that raise concerns related to it?

One cause of such an error is an unstable network that is dropping
connections.  Another could be a simple race between the connection being
closed on the other end and the publisher.

Another consideration - if the application is failing on this exception,
consider using the failover transport - *especially* if their is any type
of intermittent network instability.  In such a case, the failover
transport will block until it can successfully connect and the application
won't receive the exception.  Just make sure to have adequate logging in
place so you can tell when the application is disconnected.

Art


On Sat, Jul 2, 2022 at 2:32 AM Rupali Lalwani <
rupali.lalw...@eclinicalworks.com> wrote:

>
> Hi All,
>
>
>
> Hope this email find you in good health. I need help, we are using
> activemq 5.13. Recently we started encountering intermittent issue.
>
> Not able to find the solution though, can you please suggest looking at
> the logs?
>
>
>
> javax.jms.JMSException: Cannot send, channel has already failed:
> tcp://XX.XXX.XX.XX:8001
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1421)
> at
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1486)
> at
> org.apache.activemq.ActiveMQConnection.start(ActiveMQConnection.java:527)
> at
> com.ecw.components.ActiveMQPublishService.publishNAV(ActiveMQPublishService.java:73)
> at
> com.ecw.components.RequestProcesssor.insertPHRMessage(RequestProcesssor.java:325)
> at
> org.apache.jsp.jsp.jspnew.requestPHR_jsp._jspService(requestPHR_jsp.java:195)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:476)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>
>
>
>
>
>
>
> Regards,
>
> Rupali Lalwani
>
> 2 Technology Drive | Westborough, MA 01581
>
> T: 508-475-0450 x17002
>
> rupali.lalw...@eclinicalworks.com >
>
>
>
> 
> From: Clebert Suconic 
> Sent: Friday, July 1, 2022 12:34 PM
> To: dev@activemq.apache.org 
> Subject: [HEADS-UP] ActiveMQ Artemis Native some time between 5th and 11th
>
> [You don't often get email from clebert.suco...@gmail.com. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Attention! - This email has originated from an External Source outside of
> eClinicalWorks. Always use caution when opening attachments, clicking
> links, or when responding to this email. If you feel this is a phishing
> scam, please use the Phish Alert Report button in Outlook.
>
>
> We should release activemq artemis native within the next 2 weeks.
>
>
> I am in vacation mode next week but I may try to do a release
> anyways... it will be unlikely though as I need some hardware to
> compile the native bits (I need that even if I use the Docker).
>
>
> so, it will be most likely on the week of the 11th.. unless Robbie
> Gemmel or anyone else would like to go ahead before me.
>
>
> --
> Clebert Suconic
>
> CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains
> confidential information belonging to the sender that is legally privileged
> and proprietary and may be subject to protection under the law, including
> the Health Insurance Portability and Accountability Act (HIPAA). If you are
> not the intended recipient of this e-mail, you are prohibited from sharing,
> copying, or otherwise using or disclosing its contents. If you have
> received this e-mail in error, please notify the sender immediately by
> reply e-mail and permanently delete this e-mail and any attachments without
> reading, forwarding or saving them. Thank you.
>
> CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains
> confidential information belonging to the sender that is legally privileged
> and proprietary and may be subject to protection under the law, including
> the Health Insurance Portability and Accountability Act (HIPAA). If you are
> not the intended recipient of this e-mail, you are prohibited from sharing,
> copying, or otherwise using or disclosing its contents. If you have
> received this e-mail in error, please notify the sender immediately by
> reply e-mail and permanently delete this e-mail and any attachments without
> reading, forwarding or saving them. Thank you.
>

Re: https://issues.apache.org/jira/browse/AMQ-8971 - Karaf activemq-client feature in 5.16.3+

[Arthur Naseef]

Still working on a test project - almost got it working.

Art


On Tue, Jun 21, 2022 at 8:27 AM Arthur Naseef  wrote:

> Agreed on fixing it going forward and not simply reverting - that would
> really just create another non-backward-compatible change and increase the
> size of the problem.  The 5.16.3 - 5.17.1 releases are already in this
> state, and we can't fix that - hopefully anyone updating goes right for the
> latest (once we release a "fix"), and anyone else searching on the problem
> can find the jira ticket, this discussion, or similar resources which can
> point them at a work-around.
>
> I started writing a small test to reproduce the problem and try solutions.
>
> For the idea of providing both spec bundles, that could be a decent
> solution.  My only concern is that it could get messy for resolution
> because there would be 2 sets of classes, from different bundles, that
> could end up in the dependency chain.  In other words, some users could
> have some bundles wire to the 1.1 spec bundle, others wire to the 2.0 spec
> bundle, and any wiring amongst those would fail because their JMS classes
> aren't the same ones.  You know, the dreaded, because it is exposed to
> package '...' from resources ... via two dependency chains.
>
> One solution I'm thinking here - use the feature file's "capability" to
> advertise the existing JMS 2 spec as providing the JMS 1.1 packages.  If
> the JMS 2 classes are truly backward-compatible, I believe that could "just
> work" for both cases (JMS 1.1 and JMS 2.0 applications).
>
> Thoughts?
>
> Art
>
>
> On Tue, Jun 21, 2022 at 7:50 AM Robbie Gemmell 
> wrote:
>
>> I would fix it on 5.17.x as well unless theres some reason not to that
>> im missing, it really seems no different than it is for 5.16.x. People
>> can upgrade to 5.17.x from <=5.16.2 as well, and reasonably wouldnt
>> expect to hit a breakage for this any more than they should on 5.16.x,
>> since it also does not implement JMS 2 either.
>>
>> On Tue, 21 Jun 2022 at 15:36, Jean-Baptiste Onofré 
>> wrote:
>> >
>> > Agree: I should not have changed on 5.16.x, keep it for 5.17.x.
>> >
>> > Now that it has been released, I think the best approach is to provide
>> both
>> > spec bundles.
>> >
>> > Let me test and create PR.
>> >
>> > Regards
>> > JB
>> >
>> > Le mar. 21 juin 2022 à 16:07, Robbie Gemmell 
>> a
>> > écrit :
>> >
>> > > The obvious "why not" answer would be however easy it is, its perhaps
>> > > not so obvious to people, and it certainly doesnt seem like it should
>> > > be necessary. Those with things which only use JMS 1.1 and previously
>> > > worked with <=5.16.2 (its not just 5.15.x upgraders affected) would
>> > > not typically expect to be broken by a simple update to using 5.16.3+,
>> > > or to necessarily understand they can work around the feature problem
>> > > by using the JMS 2 spec when their stuff isnt using that and they are
>> > > still clearly using a client implementing 1.1.
>> > >
>> > > If having both versions provided is possible, fixes simple upgrades
>> > > for all the existing JMS 1.1 users on <= 5.16.2, and still allows
>> > > those already working with JMS 2 to use it as now, then that would
>> > > seem a reasonable middle ground. The spec jar isnt exactly a monstrous
>> > > overhead after all, especially not compared to the client feature
>> > > already supplying [most of] the broker etc.
>> > >
>> > > Or, you suggested earlier what would happen currently is it would only
>> > > use/supply 2.0 unless something provided 1.1 first. Can it do the
>> > > reverse, i.e can it provide 1.1 as it did before but still allow for
>> > > using 2 if already supplied, falling back to using its provided 1.1 if
>> > > they dont?
>> > >
>> > >
>> > > On Tue, 21 Jun 2022 at 14:01, Jean-Baptiste Onofré 
>> > > wrote:
>> > > >
>> > > > OK, now I understand the confusion:
>> > > >
>> > > > Karaf activemq-client feature uses activemq-osgi bundle, not
>> > > > activemq-client bundle. The activemq-client bundle is not used at
>> all
>> > > > in the Karaf features: we use the activemq-osgi uber bundle.
>> > > >
>> > > > So, if a user uses activemq-client bundle (without the feature), it
>> > > > w

Re: https://issues.apache.org/jira/browse/AMQ-8971 - Karaf activemq-client feature in 5.16.3+

[Arthur Naseef]

; > feature provides JMS 2.0 by default, but Art's bundle still import
> > > > [1.1,2) (not [1.1,3)).
> > > >
> > > > I see three options here:
> > > > 1. Art can fix his bundles header to use the extended range [1.1,3).
> > > > 2. The user who wants to still use JMS 1.1, they can stay with
> ActiveMQ
> > > 5.15.x
> > > > 3. The user who wants to still use JMS 1.1, we can add geronimo-spec
> > > > jms 1.1 in activemq-client karaf feature, meaning that we will have
> > > > both JMS 1.1 and 2.0 packages at runtime.
> > > >
> > > > Honestly, why not extending the range, easy to do and it works fine
> > > > (it's what Karaf and Camel are using) ?
> > > >
> > > > Regards
> > > > JB
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Jun 21, 2022 at 1:53 PM Jean-Baptiste Onofré <
> j...@nanthrax.net>
> > > wrote:
> > > > >
> > > > > I tested at runtime on activemq-osgi bundle used by
> activemq-client.
> > > > >
> > > > > The feature verify would not work with this range.
> > > > >
> > > > > Let me take a look but I doubt it's the case.
> > > > >
> > > > > On Tue, Jun 21, 2022 at 11:53 AM Robbie Gemmell
> > > > >  wrote:
> > > > > >
> > > > > > The javax.jms; version="[1.1,2)" value I quoted was directly
> from the
> > > > > > Import-Package manifest entry of the 5.16.3 and 5.16.5
> > > activemq-client
> > > > > > jars on maven central. On checking 5.17.1 it lists the same.
> > > > > >
> > > > > > On Tue, 21 Jun 2022 at 09:56, Jean-Baptiste Onofré <
> j...@nanthrax.net>
> > > wrote:
> > > > > > >
> > > > > > > activemq-client 5.16.3 does use the right range:
> > > > > > >
> > > > > > >javax.jms;version="[1.1,3)",
> > > > > > >
> > > > > > > Else it won't work.
> > > > > > >
> > > > > > > And by the way, before the change, I sent a couple of messages
> on
> > > the
> > > > > > > mailing list as a discussion thread.
> > > > > > >
> > > > > > > Regards
> > > > > > > JB
> > > > > > >
> > > > > > > On Tue, Jun 21, 2022 at 10:37 AM Robbie Gemmell
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > I believe the 5.16.x client doesnt have the below, instead
> > > saying:
> > > > > > > > javax.jms; version="[1.1,2)"
> > > > > > > > despite the Feature only supplying the 2.0 version which
> appears
> > > > > > > > incompatible with this. Maybe thats whats tripping Art's
> usage up
> > > > > > > > since he was clearly using <= 5.16.2 before?
> > > > > > > >
> > > > > > > > On Tue, 21 Jun 2022 at 09:24, Jean-Baptiste Onofré <
> > > j...@nanthrax.net> wrote:
> > > > > > > > >
> > > > > > > > > By the way, you can see in activemq-client:
> > > > > > > > >
> > > > > > > > > javax.jms;version="[1.1,3)",
> > > > > > > > >
> > > > > > > > > So:
> > > > > > > > > 1. if your application uses the same range, it works
> > > > > > > > > 2. if your application use [1.1,2), than, simple add
> javax.jms
> > > > > > > > > (geronimo) 1.1 bundle
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > > JB
> > > > > > > > >
> > > > > > > > > On Mon, Jun 20, 2022 at 7:45 PM Arthur Naseef <
> a...@amlinv.com>
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > I created the following ticket to address applications
> > > failing to load into
> > > > > > > > > > Karaf with AMQ 5.16.3 - 5.17.1 due to an incompatible
> change
> > > in the
> > > > > > > > > > activemq-client feature.
> > > > > > > > > >
> > > > > > > > > > https://issues.apache.org/jira/browse/AMQ-8971
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Looks to me like the right fix here is to revert the
> change
> > > to the JMS 1.1
> > > > > > > > > > spec in the feature because all of the AMQ internals are
> > > still 100% on the
> > > > > > > > > > JMS 1.1 spec.  The maven-bundle-plugin for client
> > > applications is doing the
> > > > > > > > > > right thing by generating "Package-Import" lines with
> > > version range
> > > > > > > > > > "1.1,2.0)", but the feature doesn't match it.
> > > > > > > > > >
> > > > > > > > > > It seems we have sacrificed the core case to solve an
> edge
> > > case.
> > > > > > > > > >
> > > > > > > > > > Thoughts?
> > > > > > > > > >
> > > > > > > > > > Art
> > >
>

https://issues.apache.org/jira/browse/AMQ-8971 - Karaf activemq-client feature in 5.16.3+

[Arthur Naseef]

I created the following ticket to address applications failing to load into
Karaf with AMQ 5.16.3 - 5.17.1 due to an incompatible change in the
activemq-client feature.

https://issues.apache.org/jira/browse/AMQ-8971


Looks to me like the right fix here is to revert the change to the JMS 1.1
spec in the feature because all of the AMQ internals are still 100% on the
JMS 1.1 spec.  The maven-bundle-plugin for client applications is doing the
right thing by generating "Package-Import" lines with version range
"1.1,2.0)", but the feature doesn't match it.

It seems we have sacrificed the core case to solve an edge case.

Thoughts?

Art

Re: [VOTE] Terminology to replace master/slave in ActiveMQ

[Arthur Naseef]

My 2 cents...

For AMQ 5: Active / Passive or Active / Standby makes sense for H/A.  NOB
it does not apply - each "node" (H/A pair in case every broker is running
in H/A) has active/passive pairs.  So yes, a NOB could have a bunch of
brokers all in Active state if none of the nodes is running H/A.  NOB is
never H/A.

For Artemis, since there is a designated Primary broker (the Secondary
broker cannot become active until after the Primary starts and is Active),
then it seems two sets of terms apply.  Active/Passive for the actual
runtime state, and Primary/Secondary for the assigned role.  Live/Backup
feels like it mixes the two - Live feels like runtime state.  Backup feels
like assigned role.

Art


On Fri, May 6, 2022 at 8:33 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Justin,
>
> Looks like you sent your response right when I sent mine where I mentioned
> I was leaning towards having different terms between brokers.
>
> You more accurately described the situation than I did. It's not so much a
> difference between 5.x and Artemis but two different scenarios of runtime
> vs configuration and I like your idea of having a set of nouns and
> adjectives and do think it would help solve the issue.  I also think
> the terms you picked work well so I would be in favor of going with both
> sets and having Primary/Backup and also Active/Passive depending on the
> situation described.
>
> Chris
>
> On Fri, May 6, 2022 at 11:23 AM Justin Bertram 
> wrote:
>
> > > When a user pulls up a web page or dashboard with a field next to the
> > broker name what should they see?
> >
> > It depends on which ActiveMQ broker they're using.
> >
> > In ActiveMQ "Classic" there is no configured state, as you note. There is
> > only runtime state, and it makes sense for that to be something like
> > "Active" or "Passive."
> >
> > However, in ActiveMQ Artemis there is both configured state and runtime
> > state so it would make sense to see something like "Active Primary,"
> > "Active Backup," "Passive Backup," etc.
> >
> > This gets back to a suggestion I made on AMQ-7514 [1] almost a year ago
> now
> > - we need 2 nouns to denote configured state and 2 adjectives to denote
> > runtime state and we need to use those consistently across code &
> > documentation for both brokers.
> >
> > It may turn out that ActiveMQ "Classic" ultimately only uses the
> adjectives
> > and that's 100% fine. However, there is currently both documentation and
> > URL configuration which refers to "master" and "slave" in some capacity.
> >
> > In short, it's not sufficient to have just nouns or just adjectives. We
> > need *both* for the project as a whole. I think this disconnect is one of
> > the main reasons why we haven't resolved this matter already.
> >
> > My vote is for...
> >
> > Nouns:
> > [+1] Primary/Backup
> >
> > Adjectives:
> > [+1] Active/Passive
> >
> >
> > Justin
> >
> > [1]
> >
> >
> https://issues.apache.org/jira/browse/AMQ-7514?focusedCommentId=17377740&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17377740
> >
> > On Fri, May 6, 2022 at 9:36 AM Matt Pavlovich 
> wrote:
> >
> > > When a user pulls up a web page or dashboard with a field next to the
> > > broker name what should they see?
> > >
> > > Use Case 1: Why would it makes sense to a user that has a 5-broker NOB
> > > cluster see the term ‘primary’ 5 times?
> > >
> > > Use Case 2: Why would a user that has a single broker see a status of
> > > ‘primary’?
> > >
> > > Use Case 3: With two ‘master’ and two 'slave’ brokers in a cluster the
> > > user would see ‘primary’, ‘backup’, ‘primary’, ‘backup’.  What does
> that
> > > mean? How can I have two ‘primary’ brokers? What are the ‘backup’
> > instances
> > > backing up?
> > >
> > > See how these terms makes no sense in the context of how ActiveMQ
> brokers
> > > work and how users use them?
> > >
> > > All these use cases make more sense with:
> > >
> > > +1 Active / Standby
> > >
> > > I think the terminology is really important here, since there is
> already
> > > interest (redis) for adding add’l data store backends and enhancements
> to
> > > kahadb (replication)— and to have a goal to align with Artemis.
> > >
> > > -1 Leader/Follower — this should be reserved for a state or status flag
> > at
> > > the persistence layer
> > > -1 Backup — this is a bad term for using with a systems that store
> data.
> > > IMO in incorrectly insinuates that there is data being ‘backed-up’,
> which
> > > is not the case with ActiveMQ 5.x.
> > > -1 Primary — this is not a great term, since there is no secondary or
> > > tertiary concept. This also insinuates that there are always multiple
> > > instances.
> > >
> > > ActiveMQ 5.x only has a state — active or polling to become active.
> > > Transport connectors, network connectors, etc all go offline. These
> > > primary/leader/follower concepts should be pushed down to the
> persistence
> > > layer.
> > >
> > > Thanks,
> > > Matt Pavlov

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Arthur Naseef]

In case the testing part is not entirely clear, after making the logger
injectable, then use a Mock in the test; like this:

Logger mockLogger = Mockito.mock(Logger.class);
target.setLog(mockLogger);

...

Mockito.verify(mockLogger).info("Started");

Art

On Wed, May 4, 2022 at 10:27 AM Arthur Naseef  wrote:

> +1 on SLF4J - that's what it does: eliminate the tight coupling of code
> generating log output from the logging implementation.
>
> For testing, I would just make the logger injectable, but configure a
> default.  Here's a "Live Template" for intellij that does this (minus the
> getter and setter):
>
> private static final org.slf4j.Logger DEFAULT_LOGGER =
> org.slf4j.LoggerFactory.getLogger($CLASS$.class);
>
>
> private org.slf4j.Logger log = DEFAULT_LOGGER;
>
>
> Cheers!
>
> Art
>
>
> On Wed, May 4, 2022 at 8:15 AM Matt Pavlovich  wrote:
>
>> Hey Clebert-
>>
>> We just did this as part of log4j2 conversion.  Here is a sample test
>> class w/ in-line appender:
>>
>>
>> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java
>> <
>> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java
>> >
>>
>> Matt Pavlovich
>>
>> > On May 4, 2022, at 7:37 AM, Clebert Suconic 
>> wrote:
>> >
>> > A few questions I have:
>> >
>> > - One of things we do in the testsuite is to capture loggers with an
>> > interceptor and assert the loggers were called. How would we do such a
>> > thing? an appender? Can someone point me to a test in ActiveMQ5 doing
>> > that?
>> >
>> > - how would you configure Log4J? (assuming we are using log4j with
>> SLF4j)
>> >
>> > - also we have separate loggers for Auditing... I think that will be
>> > just an entry on the log4j configuration.
>> >
>> > On Wed, May 4, 2022 at 8:16 AM Clebert Suconic
>> >  wrote:
>> >>
>> >> MDC seems nice, but I don't think it's relevant here.. we need the
>> >> Codes as part of the messages where they appear. Some users will
>> >> create alerts for them on their log frameworks.
>> >>
>> >> On Wed, May 4, 2022 at 1:16 AM Christoph Läubrich 
>> wrote:
>> >>>
>> >>> SLF4J support the "Mapped Diagnostic Context"
>> >>>
>> >>> maybe this would be a good replacement here? you could even add more
>> >>> context infos then and people are free to format them as they like:
>> >>>
>> >>> https://logback.qos.ch/manual/mdc.html
>> >>>
>> >>> Am 03.05.22 um 22:30 schrieb Justin Bertram:
>> >>>> The point here is that the current logging implementation provides a
>> simple
>> >>>> way to associate codes with each user-facing log message and
>> exception.
>> >>>> This is helpful to those who may want to monitor logs for certain
>> codes
>> >>>> (e.g. for alerting purposes), filter some codes out, etc. In this
>> way the
>> >>>> logging is part of a contract with the users much like an API is a
>> contract
>> >>>> with developers. The codes stay consistent across versions but the
>> content
>> >>>> of the message may change (e.g. to provide more information, correct
>> >>>> spelling errors, typos, etc.). This kind of facade also opens the
>> door for
>> >>>> fairly simple internationalization.
>> >>>>
>> >>>> The goals here as I see them:
>> >>>>  - Maintain the aforementioned functionality.
>> >>>>  - Ditch the dependence on JBoss Log Manager and JBoss Logging.
>> >>>>
>> >>>> Having a simple implementation of our own is an easy way to do this.
>> If we
>> >>>> decide to go this route then (and only then) we will need to decide
>> on the
>> >>>> underlying logging facade and implementation.
>> >>>>
>> >>>>
>> >>>> Justin
>> >>>>
>> >>>>
>> >>>> On Tue, May 3, 2022 at 3:17 PM Christopher Shannon <
>> >>>> christopher.l.shan...@gmail.com> wrote:
>> >>>>
>> >>>>> Using SL4J make

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Arthur Naseef]

+1 on SLF4J - that's what it does: eliminate the tight coupling of code
generating log output from the logging implementation.

For testing, I would just make the logger injectable, but configure a
default.  Here's a "Live Template" for intellij that does this (minus the
getter and setter):

private static final org.slf4j.Logger DEFAULT_LOGGER =
org.slf4j.LoggerFactory.getLogger($CLASS$.class);


private org.slf4j.Logger log = DEFAULT_LOGGER;


Cheers!

Art


On Wed, May 4, 2022 at 8:15 AM Matt Pavlovich  wrote:

> Hey Clebert-
>
> We just did this as part of log4j2 conversion.  Here is a sample test
> class w/ in-line appender:
>
>
> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java
> <
> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java
> >
>
> Matt Pavlovich
>
> > On May 4, 2022, at 7:37 AM, Clebert Suconic 
> wrote:
> >
> > A few questions I have:
> >
> > - One of things we do in the testsuite is to capture loggers with an
> > interceptor and assert the loggers were called. How would we do such a
> > thing? an appender? Can someone point me to a test in ActiveMQ5 doing
> > that?
> >
> > - how would you configure Log4J? (assuming we are using log4j with SLF4j)
> >
> > - also we have separate loggers for Auditing... I think that will be
> > just an entry on the log4j configuration.
> >
> > On Wed, May 4, 2022 at 8:16 AM Clebert Suconic
> >  wrote:
> >>
> >> MDC seems nice, but I don't think it's relevant here.. we need the
> >> Codes as part of the messages where they appear. Some users will
> >> create alerts for them on their log frameworks.
> >>
> >> On Wed, May 4, 2022 at 1:16 AM Christoph Läubrich 
> wrote:
> >>>
> >>> SLF4J support the "Mapped Diagnostic Context"
> >>>
> >>> maybe this would be a good replacement here? you could even add more
> >>> context infos then and people are free to format them as they like:
> >>>
> >>> https://logback.qos.ch/manual/mdc.html
> >>>
> >>> Am 03.05.22 um 22:30 schrieb Justin Bertram:
>  The point here is that the current logging implementation provides a
> simple
>  way to associate codes with each user-facing log message and
> exception.
>  This is helpful to those who may want to monitor logs for certain
> codes
>  (e.g. for alerting purposes), filter some codes out, etc. In this way
> the
>  logging is part of a contract with the users much like an API is a
> contract
>  with developers. The codes stay consistent across versions but the
> content
>  of the message may change (e.g. to provide more information, correct
>  spelling errors, typos, etc.). This kind of facade also opens the
> door for
>  fairly simple internationalization.
> 
>  The goals here as I see them:
>   - Maintain the aforementioned functionality.
>   - Ditch the dependence on JBoss Log Manager and JBoss Logging.
> 
>  Having a simple implementation of our own is an easy way to do this.
> If we
>  decide to go this route then (and only then) we will need to decide
> on the
>  underlying logging facade and implementation.
> 
> 
>  Justin
> 
> 
>  On Tue, May 3, 2022 at 3:17 PM Christopher Shannon <
>  christopher.l.shan...@gmail.com> wrote:
> 
> > Using SL4J makes sense to me as that is what almost everyone else
> uses so
> > it's pretty standard and easy to swap implementations
> >
> > On Mon, May 2, 2022 at 1:26 PM Justin Bertram 
> wrote:
> >
> >> I think this looks great, Clebert. The code is straightforward, and
> I
> > like
> >> the idea of reducing our dependencies.
> >>
> >> This is a +1 from me.
> >>
> >>
> >> Justin
> >>
> >> On Fri, Apr 29, 2022 at 3:43 PM Clebert Suconic <
> > clebert.suco...@gmail.com
> >>>
> >> wrote:
> >>
> >>> For a while, I thought it would be nice to remove jboss-logging
> from
> >>> artemis and use a generic logger. (SLF4J, Log4j, commons..
> whatever..
> >>> it's all orthogonal and transparent to this discussion, we can
> decide
> >>> that at a later point).
> >>>
> >>>
> >>> One of the issues we had while making the move would be the
> generated
> >>> error codes out of the Log Processor.
> >>>
> >>>
> >>> So, I put together a prototype here that would generate code based
> on
> >>> an interface and that could use whatever logger we choose. I will
> try
> >>> to never remove the branch for future reference:
> >>>
> >>>
> >>>
> >>>
> >>
> >
> https://github.com/clebertsuconic/activemq-artemis/tree/prototype-log-processor
> >>>
> >>>
> >>>
> >>> the Log processor would read the annotations and generate the code:
> >>>
> >>>
> >>>
> >>
> >
> h

Re: [PROPOSAL] Change kahadb stats to be microseconds in 5.17.x

[Arthur Naseef]

Clarifying on (4) units problem - that refers to the software industry in
whole, not just AMQ.

Art


On Wed, Dec 22, 2021 at 12:24 PM Arthur Naseef  wrote:

> Thoughts that come to mind (not advocating anything, just putting down
> thoughts);
>
>1. Semver + breaking-changes = new major number
>2. Exposing a new metric while leaving the original unchanged can
>eliminate the backward-compatibility problem at the expense of additional
>complexity/tech-debt going forward
>3. A configuration setting to switch the metric between original and
>new units could do the job, but - again - at the cost of additional
>complexity/tech-debt
>4. The units problem hasn't really been solved well; the best I've
>seen is to standardize on one unit (such as milliseconds)
>5. Is there a need here being addressed, or is the intent for cleanup?
>6. At the very least, a breaking change here warrants very clear
>communication (the changes, once-upon-a-time, to the MBean naming
>unexpectedly hit me for a few hours of work - and that was just 1 person
>who actually wasn't that heavily invested in it)
>
> Art
>
>
> On Wed, Dec 22, 2021 at 12:06 PM Matt Pavlovich 
> wrote:
>
>> Hi Art-
>>
>> The metric is arguably broken right now, so my thought is that “fixing”
>> it in  5.17.0 should be the default moving forward.
>>
>> What else would you suggest?
>>
>> -Matt Pavlovich
>>
>> > On Dec 22, 2021, at 11:25 AM, Arthur Naseef  wrote:
>> >
>> > Hmm, what about the impact to all the consumers of that metric today?
>> >
>> > That's potentially a huge amount of change.
>> >
>> > Any thoughts on mitigating the problems for users?
>> >
>> > Art
>> >
>> >
>> > On Wed, Dec 22, 2021 at 7:32 AM Matt Pavlovich 
>> wrote:
>> >
>> >> Using nanos would eliminate the math division. Might be worth it to cut
>> >> out a math operations on longs
>> >>
>> >> Checking for overflow risk.. Java Long.MAX_VALUE in nanoseconds is 292
>> >> years.
>> >>
>> >> We should be good with nanos as default vs microseconds.
>> >>
>> >> -Matt
>> >>
>> >>> On Dec 22, 2021, at 6:52 AM, Christopher Shannon <
>> >> christopher.l.shan...@gmail.com> wrote:
>> >>>
>> >>> +1, I'm not sure if it makes sense to keep the default as millis or
>> make
>> >>> the new default as nanoseconds.
>> >>>
>> >>> On Wed, Dec 22, 2021 at 2:09 AM Jean-Baptiste Onofre > >
>> >>> wrote:
>> >>>
>> >>>> +1
>> >>>>
>> >>>> It makes sense.
>> >>>>
>> >>>> Regards
>> >>>> JB
>> >>>>
>> >>>>> Le 20 déc. 2021 à 16:44, Matt Pavlovich  a
>> écrit :
>> >>>>>
>> >>>>> Currently, KahaDB stats are in ms and we get invalid rollup values
>> for
>> >>>> minTime, averageTime, and totalTime, since a large number of
>> operations
>> >>>> take < 1ms on modern hardware. I propose we convert the units to be
>> >>>> microseconds to provide better granularity and correctness. I have
>> >> created
>> >>>> a JIRA to track this change:
>> >>>> https://issues.apache.org/jira/browse/AMQ-8414 <
>> >>>> https://issues.apache.org/jira/browse/AMQ-8414>
>> >>>>>
>> >>>>> For comparison, Apache CXF also uses microseconds for metrics for
>> >>>> service operations.
>> >>>>>
>> >>>>> Sample:
>> >>>>> Broker uptimeMillis: 835951271 <-- 9 days
>> >>>>> KahaDB  "totalTime": 62568920797,  <-- 724.177324039352 days
>> >>>>>
>> >>>>>
>> >>>>> {
>> >>>>> "writeTime": {
>> >>>>>  "maxTime": 5812,
>> >>>>>  "averageTime": 16.418624299081607,
>> >>>>>  "minTime": 0,
>> >>>>>  "totalTime": 62568920797,
>> >>>>>  "count": 3810850389,
>> >>>>>  "averagePerSecond": 60.906442694832606,
>> >>>>>  "averagePerSecondExMinMax": 60.9064483204415,
>> >>>>>  "averageTimeExMinMax": 16.418622782579472
>> >>>>> },
>> >>>>> "readTime": {
>> >>>>>  "maxTime": 517,
>> >>>>>  "averageTime": 0.27722760803497465,
>> >>>>>  "minTime": 0,
>> >>>>>  "totalTime": 264011084,
>> >>>>>  "count": 952326090,
>> >>>>>  "averagePerSecond": 3607.144350045546,
>> >>>>>  "averagePerSecondExMinMax": 3607.1514061783746,
>> >>>>>  "averageTimeExMinMax": 0.2772270657359121
>> >>>>> }
>> >>>>> }
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Matt Pavlovich
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>

Re: [PROPOSAL] Change kahadb stats to be microseconds in 5.17.x

[Arthur Naseef]

Thoughts that come to mind (not advocating anything, just putting down
thoughts);

   1. Semver + breaking-changes = new major number
   2. Exposing a new metric while leaving the original unchanged can
   eliminate the backward-compatibility problem at the expense of additional
   complexity/tech-debt going forward
   3. A configuration setting to switch the metric between original and new
   units could do the job, but - again - at the cost of additional
   complexity/tech-debt
   4. The units problem hasn't really been solved well; the best I've seen
   is to standardize on one unit (such as milliseconds)
   5. Is there a need here being addressed, or is the intent for cleanup?
   6. At the very least, a breaking change here warrants very clear
   communication (the changes, once-upon-a-time, to the MBean naming
   unexpectedly hit me for a few hours of work - and that was just 1 person
   who actually wasn't that heavily invested in it)

Art


On Wed, Dec 22, 2021 at 12:06 PM Matt Pavlovich  wrote:

> Hi Art-
>
> The metric is arguably broken right now, so my thought is that “fixing” it
> in  5.17.0 should be the default moving forward.
>
> What else would you suggest?
>
> -Matt Pavlovich
>
> > On Dec 22, 2021, at 11:25 AM, Arthur Naseef  wrote:
> >
> > Hmm, what about the impact to all the consumers of that metric today?
> >
> > That's potentially a huge amount of change.
> >
> > Any thoughts on mitigating the problems for users?
> >
> > Art
> >
> >
> > On Wed, Dec 22, 2021 at 7:32 AM Matt Pavlovich 
> wrote:
> >
> >> Using nanos would eliminate the math division. Might be worth it to cut
> >> out a math operations on longs
> >>
> >> Checking for overflow risk.. Java Long.MAX_VALUE in nanoseconds is 292
> >> years.
> >>
> >> We should be good with nanos as default vs microseconds.
> >>
> >> -Matt
> >>
> >>> On Dec 22, 2021, at 6:52 AM, Christopher Shannon <
> >> christopher.l.shan...@gmail.com> wrote:
> >>>
> >>> +1, I'm not sure if it makes sense to keep the default as millis or
> make
> >>> the new default as nanoseconds.
> >>>
> >>> On Wed, Dec 22, 2021 at 2:09 AM Jean-Baptiste Onofre 
> >>> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> It makes sense.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>>> Le 20 déc. 2021 à 16:44, Matt Pavlovich  a
> écrit :
> >>>>>
> >>>>> Currently, KahaDB stats are in ms and we get invalid rollup values
> for
> >>>> minTime, averageTime, and totalTime, since a large number of
> operations
> >>>> take < 1ms on modern hardware. I propose we convert the units to be
> >>>> microseconds to provide better granularity and correctness. I have
> >> created
> >>>> a JIRA to track this change:
> >>>> https://issues.apache.org/jira/browse/AMQ-8414 <
> >>>> https://issues.apache.org/jira/browse/AMQ-8414>
> >>>>>
> >>>>> For comparison, Apache CXF also uses microseconds for metrics for
> >>>> service operations.
> >>>>>
> >>>>> Sample:
> >>>>> Broker uptimeMillis: 835951271 <-- 9 days
> >>>>> KahaDB  "totalTime": 62568920797,  <-- 724.177324039352 days
> >>>>>
> >>>>>
> >>>>> {
> >>>>> "writeTime": {
> >>>>>  "maxTime": 5812,
> >>>>>  "averageTime": 16.418624299081607,
> >>>>>  "minTime": 0,
> >>>>>  "totalTime": 62568920797,
> >>>>>  "count": 3810850389,
> >>>>>  "averagePerSecond": 60.906442694832606,
> >>>>>  "averagePerSecondExMinMax": 60.9064483204415,
> >>>>>  "averageTimeExMinMax": 16.418622782579472
> >>>>> },
> >>>>> "readTime": {
> >>>>>  "maxTime": 517,
> >>>>>  "averageTime": 0.27722760803497465,
> >>>>>  "minTime": 0,
> >>>>>  "totalTime": 264011084,
> >>>>>  "count": 952326090,
> >>>>>  "averagePerSecond": 3607.144350045546,
> >>>>>  "averagePerSecondExMinMax": 3607.1514061783746,
> >>>>>  "averageTimeExMinMax": 0.2772270657359121
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> Thanks,
> >>>>> Matt Pavlovich
> >>>>
> >>>>
> >>
> >>
>
>

Re: [PROPOSAL] Change kahadb stats to be microseconds in 5.17.x

[Arthur Naseef]

Hmm, what about the impact to all the consumers of that metric today?

That's potentially a huge amount of change.

Any thoughts on mitigating the problems for users?

Art


On Wed, Dec 22, 2021 at 7:32 AM Matt Pavlovich  wrote:

> Using nanos would eliminate the math division. Might be worth it to cut
> out a math operations on longs
>
> Checking for overflow risk.. Java Long.MAX_VALUE in nanoseconds is 292
> years.
>
> We should be good with nanos as default vs microseconds.
>
> -Matt
>
> > On Dec 22, 2021, at 6:52 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
> >
> > +1, I'm not sure if it makes sense to keep the default as millis or make
> > the new default as nanoseconds.
> >
> > On Wed, Dec 22, 2021 at 2:09 AM Jean-Baptiste Onofre 
> > wrote:
> >
> >> +1
> >>
> >> It makes sense.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 20 déc. 2021 à 16:44, Matt Pavlovich  a écrit :
> >>>
> >>> Currently, KahaDB stats are in ms and we get invalid rollup values for
> >> minTime, averageTime, and totalTime, since a large number of operations
> >> take < 1ms on modern hardware. I propose we convert the units to be
> >> microseconds to provide better granularity and correctness. I have
> created
> >> a JIRA to track this change:
> >> https://issues.apache.org/jira/browse/AMQ-8414 <
> >> https://issues.apache.org/jira/browse/AMQ-8414>
> >>>
> >>> For comparison, Apache CXF also uses microseconds for metrics for
> >> service operations.
> >>>
> >>> Sample:
> >>> Broker uptimeMillis: 835951271 <-- 9 days
> >>> KahaDB  "totalTime": 62568920797,  <-- 724.177324039352 days
> >>>
> >>>
> >>> {
> >>> "writeTime": {
> >>>   "maxTime": 5812,
> >>>   "averageTime": 16.418624299081607,
> >>>   "minTime": 0,
> >>>   "totalTime": 62568920797,
> >>>   "count": 3810850389,
> >>>   "averagePerSecond": 60.906442694832606,
> >>>   "averagePerSecondExMinMax": 60.9064483204415,
> >>>   "averageTimeExMinMax": 16.418622782579472
> >>> },
> >>> "readTime": {
> >>>   "maxTime": 517,
> >>>   "averageTime": 0.27722760803497465,
> >>>   "minTime": 0,
> >>>   "totalTime": 264011084,
> >>>   "count": 952326090,
> >>>   "averagePerSecond": 3607.144350045546,
> >>>   "averagePerSecondExMinMax": 3607.1514061783746,
> >>>   "averageTimeExMinMax": 0.2772270657359121
> >>> }
> >>> }
> >>>
> >>> Thanks,
> >>> Matt Pavlovich
> >>
> >>
>
>

Re: Truncated messages in 5.16.1 when using Postman

[Arthur Naseef]

I didn't read the full thread, but I have a question based on the initial
description.

There is an XML payload with random bytes inline?  If so, what keeps that
from being invalid XML?  '<', '>', '&', and characters that are invalid for
the character set would all cause havok.

Art


On Wed, Jun 16, 2021 at 2:27 PM Doug Whitfield 
wrote:

> Hi JB,
>
> Thanks for taking a look at this.
>
> Here are the steps to reproduce:
> 1. Download ActiveMQ 5.15.14 or later OR 5.16.1 or later.
> 2. Untar the package
> 3. Start ActiveMQ
> 4*. Send payload (as size-described in the initial email) to
> http://localhost:8161/api/message/orders.input?type=queue (I assume this
> is the REST API given the URL. Also, doesn’t need to be localhost)*
> 5. Look at the message in the ActiveMQ UI.
> 6. Note that the message is truncated
>
> To clarify, there is no need to involve a consumer to see the issue. We
> haven’t tested using a producer, just the API.
>
> Since you are asking about the consumer, I assume you are concerned about
> the ultimate use case. In the customer use case, once MDB processes, it
> puts that to dlq since the queue doesn’t has complete(required) XML
> messages.
>
> *We’ve played around with part 4 a bit. We can get curl to truncate if we
> set a different Content-Type. We can get postman to work in some cases. One
> thing we noticed is that the payload from postman is much larger than that
> of curl.  Whatever curl does with x-www-form-urlencoded works but we can’t
> get postman to replicate that exactly. Currently, we are thinking it might
> be related to https://issues.apache.org/jira/browse/AMQ-8029 -- with the
> urlencoding, it could be larger, and in some cases things could get
> compressed. It seems like it should be throwing an error, but those fix
> versions line up with where the issue exists and when it doesn’t. We
> haven’t tested the 5.17.0 builds yet. That’s probably on the horizon though
> if we can’t get this resolved in the next couple of days. Maybe it’s a
> bystander bug that’s gotten fixed.
>
> The fact that the payload piece of the XML is random might play into this
> if there is compression. Also, the fact that this is XML, might play into
> the exact numbers.
>
> Another piece I want to be clear about is that this is not a postman
> issue. The customer is seeing this with their production workloads. Postman
> was just an easy way to replicate and at the beginning we didn’t understand
> that Content-Type played some role here. We still don’t know what role
> exactly it plays, but we do know it plays some role.
>
> Best Regards,
> Doug Whitfield
>
>
> From: Jean-Baptiste Onofre 
> Date: Wednesday, June 16, 2021 at 10:55 AM
> To: dev@activemq.apache.org 
> Subject: Re: Truncated messages in 5.16.1 when using Postman
> Hi Doug,
>
> Sorry, but I don’t fully understand what you are doing ;)
>
> My understanding (correct me if I’m wrong) is:
>
> 1. You have a http related transport connector in activemq.xml
> (https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2F0.0.0.0%3A%2F&data=04%7C01%7Cdwhitfield%40perforce.com%7C814742a1ad4e4243324108d930df1b40%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637594557080096516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QPOrYsE7c0c9fzxD9Bj2ofjl97jottiAnPo9TSUu2p4%3D&reserved=0
> <
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2F0.0.0.0%3A%2F&data=04%7C01%7Cdwhitfield%40perforce.com%7C814742a1ad4e4243324108d930df1b40%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637594557080096516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QPOrYsE7c0c9fzxD9Bj2ofjl97jottiAnPo9TSUu2p4%3D&reserved=0
> >"/<
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2F0.0.0.0%3A%2F&data=04%7C01%7Cdwhitfield%40perforce.com%7C814742a1ad4e4243324108d930df1b40%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637594557080096516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QPOrYsE7c0c9fzxD9Bj2ofjl97jottiAnPo9TSUu2p4%3D&reserved=0%3e%22/
> >>)
> 2. You push a message via a connection factory ? Or you go through the
> REST API ?
> 3. The message you consume is incomplete (don’t consider the log message,
> but the consumed message)
>
> Is that correct ?
>
> Regards
> JB
>
> > Le 16 juin 2021 à 17:31, Doug Whitfield  a
> écrit :
> >
> > Hi JB,
> >
> > We took the jetty jar from 5.16.0 (which does not have the issue) and
> replaced the jetty jar in 5.16.1. Tcpdump confirms that we were testing
> jetty 9.4.28. This does not resolve the issue. That said, we didn’t change
> any of the other related jetty files, so there could still be something in
> jetty.
> >
> > We believe this has something to do with the Content-Type flag (but
> still unclear why the difference in ActiveMQ versions). By default, these
> are different in Postman and curl. The ultimate customer issue i

Re: What does "passed by reference" mean in ActiveMQ's context?

[Arthur Naseef]

May I ask where this is going?  The vm-transport's handling of
copying/not-copying messages isn't intended to be a feature.  Changing a
message that's in-flow within the broker is a bad idea for a lot of reasons.

Art


On Thu, Apr 1, 2021 at 1:01 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I haven't spent a ton of time using the VM transport personally (I
> exclusively use SSL/TCP) but at this point it is pretty clear to me that
> this is just a case of the documentation is old and doesn't apply to
> ActiveMQ 5.x and it's safe to assume the messages are copied.
>
> ActiveMQ has been around for something like 15 years so it is likely that
> the behavior used to be one way and then changed and that specific piece of
> documentation was never updated or removed. ActiveMQ version 5.x has been
> around since 2008 so I don't know that too many people remember older
> versions like version 4.x and how things used to be (I know I wasn't around
> that long ago). Ideally all the documentation should be up to date but
> sometimes things get missed.
>
> Besides what I already sent to show the message is being copied on send, I
> also just did a quick search and it looks like it also gets copied on
> dispatch to a consumer therefore you are never going to get "pass by
> reference" behavior which is what you have verified in your own testing.
> See:
>
> https://github.com/apache/activemq/blob/activemq-5.16.1/activemq-client/src/main/java/org/apache/activemq/ActiveMQConnection.java#L1840
> .
>
> There are certainly lots of unit tests that use the VMTransport but I don't
> know that there are any specific tests to demonstrate pass by value or
> reference, I'm guessing there is nothing else than what you already found
> and testing it yourself is probably the best thing which you have done.
>
> The main action point here is that documentation is quite confusing and
> needs to be fixed up (probably just deleted honestly) as it doesn't appear
> to be relevant anymore.
>
> On Thu, Apr 1, 2021 at 2:48 PM Cunningham  wrote:
>
> > > "...that was just referring to the fact that when the message is sent
> by
> > VM transport the same reference is used..."
> >
> > That answers my question #1. Thanks.
> >
> >
> > > "...changes to the original message after sending would also affect the
> > message that was already sent since they are the same object still..."
> >
> > Thanks. My experiments show that is true only if
> > ActiveMQObjectMessage.setObject(new Object()) is done in the producer
> after
> > the original send. The same change when done in consumers has no effect.
> In
> > both cases I set ActiveMQObjectMessage.setReadOnlyBody(false) beforehand,
> > by the way.
> >
> > If you have running code that implements what you're describing, I'd be
> > grateful if you could share it. Please? TIA.
> >
> >
> > > "...See: .../org/apache/activemq/ActiveMQSession.java#L1955..."
> >
> > Forgive me if I sound ungrateful. But I had already seen that. Thanks
> just
> > the same though.
> >
> > I've also seen the unit test for it [1]. And I've seen where it's used
> with
> > objectMessageSerializationDefered [2]. ActiveMQObjectMessage.setObject()
> > also uses objectMessageSerializationDefered [3].
> >
> > Another test I've seen is one that verifies that an ObjectMessage's body
> is
> > serialized over TCP transport but not serialized over VM transport when
> > objectMessageSerializationDefered is true [4].
> >
> >
> > > "...a copy of the message is still sent even with the VM transport by
> > default..."
> >
> > That might explain why I haven't had any luck producing pass-by-reference
> > behavior (as I understand it [5]) in my experiments.
> >
> > Starting with this ActiveMQ-supplied example code [6] as a base, I tried
> > every combination of values for objectMessageSerializationDefered and
> > copyMessageOnSend I could think of.
> >
> > That documentation I linked to in my first post claims "Messages are
> passed
> > by reference when objectMessageSerializationDefered is false" and
> "Messages
> > are  passed by value when objectMessageSerializationDefered is true". I
> > would love to find a test that either verifies either of those claims or
> > disproves either of them.
> >
> > Until I do though, I will still have these unanswered questions...
> >
> > 1. ...
> > 2. Where can I find existing unit tests that exercise and verify
> ActiveMQ's
> > expected pass-by-reference/pass-by-value behavior?
> > 3. Is that ActiveMQ documentation even relevant for ActiveMQ 5+? Or only
> > for 3x and 4x?
> >
> > 
> >
> > [1] https://bit.ly/testAMQcopy
> > [2] https://bit.ly/AMQcopy
> > [3] https://bit.ly/setObject
> > [4] https://bit.ly/MsgNotSerTest
> > [5] https://bit.ly/JavaDudePbV
> > [6] https://bit.ly/HelloAMQApp
> >
> >
> > 
> >
> > On Thu, Apr 1, 2021 at 2:39 PM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > I forgot to add that your experiment probably didn't show changes
> > because I

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

[Arthur Naseef]

JB - I appreciate that you are ready to take on effort here.  Some parts of
renaming are open questions in my mind.  For example, do we rename the
Maven Artifacts?  If so, how can we help users to avoid confusion when
searching for artifacts, and when upgrading from existing ones.

I know that's not a unique problem to AMQ; for example, I still have to
pause and think, "is it group-id commons-io, or org.apache.commons"?

One idea of a small change to the website landing page that could help (as
an additional consideration, not a replacement for renaming) - have a link
with a title such as, "WHICH ACTIVEMQ BROKER?" or "ACTIVEMQ or ARTEMIS?" -
and have that link open a page with a brief clarification, and perhaps a
little history.

Cheers!

Art


On Sat, Mar 20, 2021 at 10:51 PM Jean-Baptiste Onofre 
wrote:

> Hi Art,
>
> I share your point and it’s the intention of the thread: some users (all
> ?) are lost between ActiveMQ and Artemis.
>
> Some don’t understand that Artemis is a ActiveMQ project, some others are
> lot between ActiveMQ and Artemis.
> I think most of the confusion is that "Classic" or version is not super
> clean for users (for us, it’s a not a problem because we are involved in
> the project, but think about "external" users).
>
> If we go with naming change for "Classic" (or whatever name), I’m really
> to tackle the effort (it can be done in two steps, website/documentation
> first and code base after).
> I’m ready to tackle this (even it’s a big effort ;)).
>
> Regards
> JB
>
> > Le 20 mars 2021 à 19:19, Arthur Naseef  a écrit :
> >
> > When it comes to naming, and overloaded names, having two things with the
> > same base name, then one with a distinguisher and one without, creates an
> > imbalance that always leads to confusion.  In other words, having
> > "ActiveMQ" and "ActiveMQ Artemis" is confusing.  If it had been (too late
> > now) "ActiveMQ" and "Artemis", then there would be no confusion on the
> > naming (just then the confusion for some of whether Artemis was related
> to
> > ActiveMQ in any way).
> >
> > BTW, for those who are too new to remember, we started out using version
> > numbers to distinguish, which quickly got even more confusing when
> Artemis
> > rolled around because Apollo was already informally branded "AMQ 6".
> There
> > is also, as many know, now a company calling Artemis "AMQ 7".  This is
> the
> > point in the thought process where I usually just walk away.
> >
> > The best way, in my experience, to eliminate that confusion is to create
> a
> > new distinguishing name and use it.  Using "Classic" here achieves that
> > goal, but it also has a feeling of calling it "the old thing".
> >
> > On the other hand, we are very deep in here (i.e. ActiveMQ has a LOT of
> > code and assets behind it), so renaming could lead to a lot of changes -
> > for example, renaming the artifacts could be desirable.
> >
> > Changing the designation on the website landing page seems like a good
> idea
> > to me - it's a "shallow" operation (shallow meaning only 1 layer of thing
> > to change).  Hence my recommendation to change it to somehitng like
> > "ActiveMQ (the Classic broker)" from "ActiveMQ Classic" since the former
> > seems, in my mind, to clarify that Classic is not part of the name.
> >
> > If we really want to solve the naming imbalance, I'll support it, but
> then
> > I think we need a good name, and we'll need to be mindful of just how
> deep
> > we take the name.  And good name = not something like "Classic" - a name
> > worthy of a project, something akin to "Artemis" and "Apollo".  (More god
> > names?)
> >
> > Art
> >
> > P.S. It would be awesome to remove the 5.x major-number limitation.
> >
> >
> > On Sat, Mar 20, 2021 at 8:17 AM Jean-Baptiste Onofre 
> > wrote:
> >
> >> Hi Chris,
> >>
> >> I agree that we have kind of consensus about stay under ActiveMQ
> umbrella.
> >>
> >> As Artemis and Classic are in two different repos, and we have some
> gaps,
> >> I think it could be "confusing" for our users.
> >>
> >> That was exactly my point when I started the thread: I see users lot in
> >> naming, versioning.
> >> I think that maybe the mistake was to keep ActiveMQ "branding" for 5.x,
> >> and have Artemis at same time.
> >>
> >> Anyway, it’s mostly a communication

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

[Arthur Naseef]

When it comes to naming, and overloaded names, having two things with the
same base name, then one with a distinguisher and one without, creates an
imbalance that always leads to confusion.  In other words, having
"ActiveMQ" and "ActiveMQ Artemis" is confusing.  If it had been (too late
now) "ActiveMQ" and "Artemis", then there would be no confusion on the
naming (just then the confusion for some of whether Artemis was related to
ActiveMQ in any way).

BTW, for those who are too new to remember, we started out using version
numbers to distinguish, which quickly got even more confusing when Artemis
rolled around because Apollo was already informally branded "AMQ 6".  There
is also, as many know, now a company calling Artemis "AMQ 7".  This is the
point in the thought process where I usually just walk away.

The best way, in my experience, to eliminate that confusion is to create a
new distinguishing name and use it.  Using "Classic" here achieves that
goal, but it also has a feeling of calling it "the old thing".

On the other hand, we are very deep in here (i.e. ActiveMQ has a LOT of
code and assets behind it), so renaming could lead to a lot of changes -
for example, renaming the artifacts could be desirable.

Changing the designation on the website landing page seems like a good idea
to me - it's a "shallow" operation (shallow meaning only 1 layer of thing
to change).  Hence my recommendation to change it to somehitng like
"ActiveMQ (the Classic broker)" from "ActiveMQ Classic" since the former
seems, in my mind, to clarify that Classic is not part of the name.

If we really want to solve the naming imbalance, I'll support it, but then
I think we need a good name, and we'll need to be mindful of just how deep
we take the name.  And good name = not something like "Classic" - a name
worthy of a project, something akin to "Artemis" and "Apollo".  (More god
names?)

Art

P.S. It would be awesome to remove the 5.x major-number limitation.


On Sat, Mar 20, 2021 at 8:17 AM Jean-Baptiste Onofre 
wrote:

> Hi Chris,
>
> I agree that we have kind of consensus about stay under ActiveMQ umbrella.
>
> As Artemis and Classic are in two different repos, and we have some gaps,
> I think it could be "confusing" for our users.
>
> That was exactly my point when I started the thread: I see users lot in
> naming, versioning.
> I think that maybe the mistake was to keep ActiveMQ "branding" for 5.x,
> and have Artemis at same time.
>
> Anyway, it’s mostly a communication and website point.
>
> I think (even if I don’t like "Classic" name ;)) we can keep Artemis and
> Classic, but clearly separate resources (it’s already the case, but let’s
> do this even more obvious) on website, and inform users that both
> "subprojects" are active and moving forward.
>
> Regards
> JB
>
> > Le 20 mars 2021 à 16:10, Christopher Shannon <
> christopher.l.shan...@gmail.com> a écrit :
> >
> > After reading everyone's feedback I am seeing a lot of good reasons to
> stay
> > under one umbrella. The main thing is probably just clarifying to user's
> > that both brokers are alive and being supported at this point to reduce
> > confusion and the plans for each broker.
> >
> > How about versioning going forward (since that was part of this initial
> > thread)? The initial intent was Artemis was a code name and eventually
> > would be retired and become ActiveMQ 6.0 when deemed ready. Is this still
> > the goal? Or are we just going to keep going forward with Artemis as the
> > name under its own versioning indefinitely and that would allow ActiveMQ
> > 5.x to become 6 if desired? I think either way is fine as long as it is
> > defined as the plan. The Artemis name has been around a while now and I'm
> > fine with just keeping that name long term.
> >
> >
> > On Sat, Mar 20, 2021 at 1:29 AM Jean-Baptiste Onofre 
> > wrote:
> >
> >> Hi guys,
> >>
> >> It seems we lost the initial intend of this thread.
> >>
> >> The two initial questions on this thread were:
> >>
> >> 1. Can we give a more clear "tag name" than "classic", and also being
> able
> >> to use different versioning than just 5.
> >> 2. Refactoring just the activemq "classic" part of the website (working
> on
> >> cleaning the wiki resources, etc).
> >>
> >> We don’t have a consensus about other actions and we have different
> >> standpoints about the current situation and communities "segmentation".
> >>
> >> That’s OK for me: it’s the base of OpenSource and Apache to discuss and
> >> have a consensus.
> >>
> >> So, to summarize:
> >>
> >> 1. We continue to have "classic" and "Artemis" under the ActiveMQ
> >> "umbrella"
> >> 2. We will move forward on cleaning and updates of the ActiveMQ
> "classic"
> >> part on the website (it’s a must have IMHO)
> >> 3. We will move forward on "Classic" roadmap and new features
> >> 4. We will move forward on "Artemis" roadmap and new features
> >>
> >> Regards
> >> JB
> >>
> >>> Le 20 mars 2021 à 01:53, Bruce Snyder  a
> écrit :
> >>>
> >>> I remember the

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

[Arthur Naseef]

If we're just talking about the landing page saying

ActiveMQ 5 "Classic"

then perhaps we change that so it's clear Classic isn't part of the
official project name?  Maybe like this (note I'm not loving this, but it's
an idea):

ActiveMQ 5 (The classic broker)

Art


On Fri, Mar 19, 2021 at 3:28 PM Arthur Naseef  wrote:

> TLDR; my take here - we discussed making Artemis a TLP long ago, and we
> chose this path.
>
> I see the naming can be confusing.  And of course, there's the fact that
> AMQ 5 is kinda stuck on major version number 5, but we have lived with that
> up until now without significant problems.
>
> Was there some other important consideration going on?
>
> I'm going to go look at the web site now and see where the word "Classic"
> is being used.
>
> Art
>
>
> On Fri, Mar 19, 2021 at 2:31 PM Jean-Baptiste Onofre 
> wrote:
>
>> I disagree about the work/effort to go to a TLP. When we moved Karaf as
>> TLP from Felix, it was pretty fast and straight forward.
>> That’s true it’s a PMC decision, I would completely understand that some
>> PMC members would prefer on the ActiveMQ "umbrella".
>>
>> Anyway, I give up on this thread, agree with Gary: let’s keep colocation
>> on the ActiveMQ "umbrella". We will see what our users will do.
>>
>> I will still maintain and work on ActiveMQ, heading to new features and
>> releases. I will request some helps for website refactoring/cleanup.
>>
>> Regards
>> JB
>>
>> > Le 19 mars 2021 à 21:21, Gary Tully  a écrit :
>> >
>> > there is a huge amount of work being a TLP, duplicate work, it seems a
>> > completely preposterous suggestion to me.
>> >
>> > I don't see problems if we can have clarity and appreciation for each
>> > others work.
>> >
>> > We have come along way,  today users have choice under the activemq
>> > umbrella, there are now two openwire implementations; migration is an
>> > option, a viable choice.
>> > Let me give you all a concrete example:
>> > - Selector aware virtual topics on artemis can work better than on
>> > 5.x, that is what I was working on today. there is no need for the
>> > selector cache plugin!
>> > it is quite positive. alternatives are good and healthy. new
>> > architectures present different possibilities.
>> >
>> > My personal feeling is that there is lots more in common that in
>> > difference between the brokers, and our users will be one and the same
>> > over time, or they will go elsewhere.
>> >
>> > I am delighted to see some activity on 5.x and look forward to seeing
>> > how it evolves and being part of it.
>> >
>> > Let's not make extra work unless it is for very good reason.
>> > Let's continue to co exist and let users decide what stream they want
>> > to adopt or when.
>> >
>> > /gary
>> >
>> > On Fri, 19 Mar 2021 at 16:10, Jean-Baptiste Onofre 
>> wrote:
>> >>
>> >> I agree.
>> >>
>> >> If no objection, I would start a vote to propose Artemis as TLP.
>> >>
>> >> Thoughts ?
>> >>
>> >> Regards
>> >> JB
>> >>
>> >>> Le 19 mars 2021 à 17:00, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> a écrit :
>> >>>
>> >>> I personally feel that renaming Classic to Leto has the potential to
>> >>> further confuse people. I'd be +1 on Artemis becoming its own TLP.
>> >>>
>> >>> Jon
>> >>>
>> >>> On Fri, Mar 19, 2021 at 3:37 PM Christopher Shannon <
>> >>> christopher.l.shan...@gmail.com> wrote:
>> >>>
>> >>>> JB,
>> >>>>
>> >>>> Right, I am a user of both products also. I am still a heavy
>> 5.x/Classic
>> >>>> user but I also am still trying to get my project/team onto Artemis
>> as well
>> >>>> but migration is always slow. I'm also working quite heavily with
>> Kafka now
>> >>>> as well which has taken up a lot of my time and prevented me from
>> having as
>> >>>> much interaction with AMQ recently. Having a separate TLP does not
>> stop
>> >>>> anyone from contributing and using both projects but it does make
>> things a
>> >>>> lot easier I think in terms of naming, versioning, etc.  I think it
>>

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

[Arthur Naseef]

TLDR; my take here - we discussed making Artemis a TLP long ago, and we
chose this path.

I see the naming can be confusing.  And of course, there's the fact that
AMQ 5 is kinda stuck on major version number 5, but we have lived with that
up until now without significant problems.

Was there some other important consideration going on?

I'm going to go look at the web site now and see where the word "Classic"
is being used.

Art


On Fri, Mar 19, 2021 at 2:31 PM Jean-Baptiste Onofre 
wrote:

> I disagree about the work/effort to go to a TLP. When we moved Karaf as
> TLP from Felix, it was pretty fast and straight forward.
> That’s true it’s a PMC decision, I would completely understand that some
> PMC members would prefer on the ActiveMQ "umbrella".
>
> Anyway, I give up on this thread, agree with Gary: let’s keep colocation
> on the ActiveMQ "umbrella". We will see what our users will do.
>
> I will still maintain and work on ActiveMQ, heading to new features and
> releases. I will request some helps for website refactoring/cleanup.
>
> Regards
> JB
>
> > Le 19 mars 2021 à 21:21, Gary Tully  a écrit :
> >
> > there is a huge amount of work being a TLP, duplicate work, it seems a
> > completely preposterous suggestion to me.
> >
> > I don't see problems if we can have clarity and appreciation for each
> > others work.
> >
> > We have come along way,  today users have choice under the activemq
> > umbrella, there are now two openwire implementations; migration is an
> > option, a viable choice.
> > Let me give you all a concrete example:
> > - Selector aware virtual topics on artemis can work better than on
> > 5.x, that is what I was working on today. there is no need for the
> > selector cache plugin!
> > it is quite positive. alternatives are good and healthy. new
> > architectures present different possibilities.
> >
> > My personal feeling is that there is lots more in common that in
> > difference between the brokers, and our users will be one and the same
> > over time, or they will go elsewhere.
> >
> > I am delighted to see some activity on 5.x and look forward to seeing
> > how it evolves and being part of it.
> >
> > Let's not make extra work unless it is for very good reason.
> > Let's continue to co exist and let users decide what stream they want
> > to adopt or when.
> >
> > /gary
> >
> > On Fri, 19 Mar 2021 at 16:10, Jean-Baptiste Onofre 
> wrote:
> >>
> >> I agree.
> >>
> >> If no objection, I would start a vote to propose Artemis as TLP.
> >>
> >> Thoughts ?
> >>
> >> Regards
> >> JB
> >>
> >>> Le 19 mars 2021 à 17:00, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
> >>>
> >>> I personally feel that renaming Classic to Leto has the potential to
> >>> further confuse people. I'd be +1 on Artemis becoming its own TLP.
> >>>
> >>> Jon
> >>>
> >>> On Fri, Mar 19, 2021 at 3:37 PM Christopher Shannon <
> >>> christopher.l.shan...@gmail.com> wrote:
> >>>
>  JB,
> 
>  Right, I am a user of both products also. I am still a heavy
> 5.x/Classic
>  user but I also am still trying to get my project/team onto Artemis
> as well
>  but migration is always slow. I'm also working quite heavily with
> Kafka now
>  as well which has taken up a lot of my time and prevented me from
> having as
>  much interaction with AMQ recently. Having a separate TLP does not
> stop
>  anyone from contributing and using both projects but it does make
> things a
>  lot easier I think in terms of naming, versioning, etc.  I think it
> also
>  just adds a lot more clarity for the users. Also, even as its own TLP,
>  there is no reason why Artemis can't still have a goal to be feature
>  compliant with ActiveMQ 5.x.
> 
>  A pretty good example about how things are confusing right now is
> Artemis
>  has been advertised as the next generation but there has been a lot of
>  discussion recently about 5.x release cycles, upgrading the
> datastore, JMS
>  2.0 upgrades, etc. Basically it looks like it is still being actively
>  development (which it is) so a user might be pretty confused about
> which
>  broker to pick and what is going on long term.
> 
>  Anyways, I can only speak for myself so maybe most people still think
> the
>  two projects should stay together under 1 umbrella. If I am in the
> minority
>  and most people want to keep everything together that is fine.
> 
>  On Fri, Mar 19, 2021 at 11:15 AM Jean-Baptiste Onofre <
> j...@nanthrax.net>
>  wrote:
> 
> > Hi Chris,
> >
> > I’m sharing the same feeling and analyze.
> >
> > Even if I plan to work more on Artemis (first PR will happen soon
> ;)),
>  the
> > current situation is what you describe: we have two communities.
> >
> > It’s not a bad thing IMHO, it happens in all projects, with time and
> > resulting of some decisions taken.
> >
> > Regards
> > JB
> >
> >> Le 19 mars 2021 à 16:02

Re: Official Docker Image for ActiveMQ

[Arthur Naseef]

I keep seeing mention of having multiple variations of docker images using
different base images and some thoughts come to mind.

Here are my thoughts:

   - Docker staged builds make it easy to copy specific contents from one
   base image into a new one, leaving behind unwanted content (e.g. O/S or JDK
   specifics)
   - If the ActiveMQ-specific parts are placed in dedicated directories,
   copying them out to new images would be straight forward
   - Of couse, the number of combinations folks will want can grow to
   unmaintainable levels quickly
   - Having official image(s) that are functional, and provide a
   "quick-start" to meet the following use-cases would be great value across
   the board:
  - New user spinning up a broker to learn/experiment
  - Build/Test pipeline ephemeral broker for application testing
  purposes
   - Docker containers have many means to gain access to additional tooling
   not built-into an image
  - Because of this, having a minimal container is not overly-limiting
  - Of course, getting tools working with a process in a docker
  container can be challenging (e.g. not everyone will be
comfortable to use
  nsenter), so some basic tools may be good to have
   - Providing a basic, well-structured image enables more complex
   use-cases without having to clean-up / undo more advanced

Hope this helps.

Art



On Wed, Mar 17, 2021 at 1:38 AM Jean-Baptiste Onofre 
wrote:

> Hi,
>
> As I’m preparing ActiveMQ 5.17.0 with lot of changes, I plan to include
> docker image there.
>
> Regards
> JB
>
> > Le 17 mars 2021 à 09:26, Havret  a écrit :
> >
> > Any update on this?
> >
> > On Fri, Feb 26, 2021, 00:30 Clebert Suconic 
> > wrote:
> >
> >> I feel like we are stuck again on Infra.
> >>
> >> On the clone for artemis someone suggested asking for help in
> >> build.Apache.org which I then answered we just need help and
> authorization
> >> to upload stuff
> >>
> >>
> >> Anyone have any insight!?
> >>
> >> On Wed, Feb 24, 2021 at 1:33 PM Matt Pavlovich 
> wrote:
> >>
> >>> Not yet. INFRA has assigned that task, but not taken any action on the
> >>> request. I’ll nudge for an update.
> >>>
>  On Feb 24, 2021, at 12:21 PM, Clebert Suconic <
> >> clebert.suco...@gmail.com>
> >>> wrote:
> 
>  Do you have a Jenkins job already aligned to build it ?
> 
> 
>  On Wed, Feb 24, 2021 at 12:19 PM Matt Pavlovich 
> >>> wrote:
> 
> > I’m prepping the PR for 5.17.0.  Please provide feedback on the JIRA.
> >
> > Thanks!
> >
> >> On Feb 24, 2021, at 11:16 AM, Havret  wrote:
> >>
> >> Any update on this? I've just seen that Victor Romero archived his
> >> unofficial docker image. :(
> >>
> >> On Fri, Feb 19, 2021 at 4:57 PM Clebert Suconic <
> > clebert.suco...@gmail.com>
> >> wrote:
> >>
> >>> I'm following up on that JIRA ticket.
> >>>
> >>> On Fri, Feb 19, 2021 at 10:57 AM Clebert Suconic
> >>>  wrote:
> 
>  Thanks Matt, I thought you already had some information about
> >> changes
>  on Infra. I had misunderstood you.
> 
>  On Fri, Feb 19, 2021 at 10:33 AM Matt Pavlovich <
> >> mattr...@gmail.com>
> >>> wrote:
> >
> > Hi Clebert-
> >
> > I do not have all the info yet, INFRA has assigned the ticket but
> >>> not
> >>> started working on it =)
> >
> > -Matt
> >
> >> On Feb 19, 2021, at 9:25 AM, Clebert Suconic <
> >>> clebert.suco...@gmail.com> wrote:
> >>
> >> I tried to follow the JIRA on Infra and I did not see much
> >>> information about it.
> >>
> >> What's the procedure to upload images?
> >>
> >>
> >> The only thing I saw was this JIRA: But it seemed you would be
> >> uploading images manually?
> >>
> >> https://issues.apache.org/jira/browse/INFRA-21430
> >>
> >>
> >>
> >> Isn't there an official way to provide the images?
> >>
> >>
> >> In artemis we have a docker module where you would build the
> >>> binaries
> >> and create the image. We would just need to add that to a
> Jenkins
> >> build and produce an image whenever a tag is created.
> >> I suppose ActiveMQ branch would do the same...
> >>
> >>
> >> How this is supposed to work?
> >>
> >>
> >> thank you
> >>
> >> On Wed, Feb 17, 2021 at 4:13 PM Matt Pavlovich <
> >> mattr...@gmail.com
> 
> >>> wrote:
> >>>
> >>> +1
> >>>
> >>> The initial features list and notes in the JIRA reflect this
> >>> approach. I’ll start on the module and push a PR this weekend.
> >>>
> >>> Thanks,
> >>> Matt
> >>>
>  On Feb 17, 2021, at 2:08 PM, Jean-Baptiste Onofre <
> >>> j...@nanthrax.net
> >>
> >>> 

Re: [PROPOSAL] Rebirth of replicatedKahaDB

[Arthur Naseef]

Hey JB, I am interested here.

I know many approaches to replication have been tried - with AMQ 5 as well
as Artemis.  For example, "LevelDB replicated storage" and "Pure Master
Slave" (where the active broker copied updates to the passive brokers) in
AMQ 5.  So I'm curious how the problem is getting solved in an effective
manner.

I've had people ask about GlusterFS, but haven't heard of anyone
successfully using it.

The reason shared filesystem works so well is that a synchronous write to
the shared filesystem is guaranteed "on disk" (and hence, accessible by all
clients of that filesystem).  Even though the overhead of the sync write
can be significant, high speed networking and advanced hardware help
minimize the latency introduced.  If we use replication, would it be doing
effectively the same thing for all the replicated copies?  If not, then how
can message loss and duplication be prevented on change of the active
broker?

Of course, one big downside for the shared filesystem solution is that it
requires the server to be redundant and highly-available (like a Filter, or
EFS), so a distributed solution like this is appealing.

Cheers!

Art


On Wed, Feb 17, 2021 at 1:52 PM JB Onofré  wrote:

> Hi everyone
>
> On a cloud environment, our current ActiveMQ5 topologies have limitations:
>
> - master slave works fine but requires either a shared file system (for
> instance AWS EFS) or database. And it also means that we only have one
> broker active at a time.
> - network of broker can be used to have kind of partitioning of messages
> across several brokers. However if we have pending messages on a broker and
> we lost this broker, the messages on this one are not available until we
> restart the broker (with the same file system).
>
> The idea of replicatedKahaDB is to replicate messages from one kahadb to
> another one. If we lost the broker, a broker with the replica is able to
> load the messages to be available.
>
> I started to work on this implementation:
> - adding a new configuration element as persistence adapter
> - adding zookeeper client m, zookeeper is used as topology storage,
> heartbeat and leader élection
> - I’m evaluating the use of bookkeeper as well (directly as storage)
>
> I will share a branch on my local repo with you soon.
>
> Any comment is welcome.
>
> Thanks
> Regards
> JB
>

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

[Arthur Naseef]

I have started to run the build after updating the tag.

Thank you JB.

Art


On Fri, Dec 4, 2020 at 1:20 PM Jamie G.  wrote:

> +1
>
> Cheers,
> Jamie
>
> On Fri, Dec 4, 2020 at 9:11 AM Jean-Baptiste Onofre 
> wrote:
> >
> > +1 (binding)
> >
> > Regards
> > JB
> >
> > > Le 3 déc. 2020 à 06:03, Jean-Baptiste Onofre  a
> écrit :
> > >
> > > Hi everyone,
> > >
> > > I submit Apache ActiveMQ 5.15.14 to your vote. This second take
> includes fixes on jetty-realm file protocol and new updates.
> > > This release includes CVE related updates and bug fixes.
> > >
> > > Please take a look on the Release Notes for details:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
> >
> > >
> > > The Maven staging repository is:
> > >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1221/
> <
> https://repository.apache.org/content/repositories/orgapacheactivemq-1221/
> >
> > >
> > > The dist staging repository is:
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/ <
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/>
> > >
> > > Git tag:
> > > activemq-5.15.14
> > >
> > > 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: [CANCEL][VOTE] Apache ActiveMQ 5.15.14 release

[Arthur Naseef]

Oh nice.  I missed this earlier.  Thanks!

Art


On Wed, Dec 2, 2020 at 2:09 AM Jean-Baptiste Onofre  wrote:

> FYI, I fixed the issues (very quick fix) the InMemory test.
>
> Regards
> JB
>
> > Le 2 déc. 2020 à 05:54, Jean-Baptiste Onofre  a écrit :
> >
> > Hi Art,
> >
> > Thanks for the update !
> >
> > Yeah, those tests are some of I would like to fix (they fail for quite
> long now, since at least 5.15.9).
> >
> > I think some tests should be removed because they don’t make sense
> anymore.
> >
> > I will take a look (I’m also improving the Karaf tests which are flaky).
> >
> > By the way, all is executed on Jenkins with the pipeline I created.
> However:
> > - a full ActiveMQ test is very long (~6h)
> > - the build often fails on Jenkins due to flaky tests
> >
> > So, I started to improve the situation, but it takes sometime and I
> don’t think we should hold releases for non accurate/flaky tests.
> >
> > Thanks again for your feedback, I’m moving forward on release (5.15.14
> take #2) and improving the build/tests.
> >
> > Regards
> > JB
> >
> >> Le 1 déc. 2020 à 22:46, Arthur Naseef  a écrit :
> >>
> >> So the ClassCastException happens in 5.15.13 and 5.15.10 when I run that
> >> test specifically.
> >> I suspect we have a case where the test class inheritance is causing
> >> confusion.  If so, then the fix here is to bypass the base-class test
> >> method.
> >>
> >> Can someone look at the test method
> >> testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded
> >> in JmsSchedulerTest.java and answer the question, "does this test method
> >> make sense for the in-memory scheduler?"  I suspect the in-memory
> scheduler
> >> just doesn't have a journal, so the test doesn't apply.
> >>
> >> Still no update on (2).
> >>
> >> Art
> >>
> >>
> >> On Tue, Dec 1, 2020 at 1:48 PM Arthur Naseef  wrote:
> >>
> >>> Looks like I'm finding 2 problems with the InMemeoryJmsSchedulerTest:
> >>>
> >>>
> >>>  1. The ClassCastException in one test, and
> >>>  2. "Didn't receive the message" problem in the other.
> >>>
> >>>
> >>> Digging into the ClassCastException, all the code appears to be
> unchanged
> >>> for at least 6 months.  Could this have been broken all this time?
> >>>
> >>> Haven't dug into the second problem yet.
> >>>
> >>> Art
> >>>
> >>>
> >>> On Tue, Dec 1, 2020 at 1:03 PM Arthur Naseef  wrote:
> >>>
> >>>> So it looks like my build only had 2 test failures.  The first we
> >>>> discussed already.  The second is as follows:
> >>>>
> >>>> [INFO] Running
> >>>> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
> >>>> [ERROR] Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time
> elapsed:
> >>>> 41.993 s <<< FAILURE! - in
> >>>> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
> >>>> [ERROR]
> >>>>
> testScheduleFullRecoveryRestart(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
> >>>> Time elapsed: 5.514 s  <<< FAILURE!
> >>>> java.lang.AssertionError: Didn't receive the message
> >>>>
> >>>> [ERROR]
> >>>>
> testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
> >>>> Time elapsed: 0.005 s  <<< ERROR!
> >>>> java.lang.ClassCastException:
> >>>> org.apache.activemq.broker.scheduler.memory.InMemoryJobSchedulerStore
> >>>> cannot be cast to
> >>>> org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl'
> >>>>
> >>>>
> >>>> I'm looking into it - please let me know if this is also a known
> issue.
> >>>>
> >>>> Art
> >>>>
> >>>>
> >>>> On Mon, Nov 30, 2020 at 10:22 PM Jean-Baptiste Onofre <
> j...@nanthrax.net>
> >>>> wrote:
> >>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> Due to an issue with the fix for AMQ-8045, I cancel this vote to
> prepare
> >>>>> a new one.
> >>>>

Re: [CANCEL][VOTE] Apache ActiveMQ 5.15.14 release

[Arthur Naseef]

Makes sense.  Glad to hear the tests are run even if we have a few that
fail consistently.

When I did a few official AMQ builds, I learned to use "mvn -fn" to run
through the entire build, then go back and re-run the tests that failed.
At that time, running the tests more than once usually got them to pass,
and I accepted that result.

The more I looked at the ClassCastException in the
InMemeoryJmsSchedulerTest, the more I think that test just doesn't apply.
If that's the case, we could use a simple means to disable the specific
test method when inherited - either by overriding the test method to do
nothing, or by adding a simple "instanceof" check in the base class.

Art


On Wed, Dec 2, 2020 at 2:09 AM Jean-Baptiste Onofre  wrote:

> FYI, I fixed the issues (very quick fix) the InMemory test.
>
> Regards
> JB
>
> > Le 2 déc. 2020 à 05:54, Jean-Baptiste Onofre  a écrit :
> >
> > Hi Art,
> >
> > Thanks for the update !
> >
> > Yeah, those tests are some of I would like to fix (they fail for quite
> long now, since at least 5.15.9).
> >
> > I think some tests should be removed because they don’t make sense
> anymore.
> >
> > I will take a look (I’m also improving the Karaf tests which are flaky).
> >
> > By the way, all is executed on Jenkins with the pipeline I created.
> However:
> > - a full ActiveMQ test is very long (~6h)
> > - the build often fails on Jenkins due to flaky tests
> >
> > So, I started to improve the situation, but it takes sometime and I
> don’t think we should hold releases for non accurate/flaky tests.
> >
> > Thanks again for your feedback, I’m moving forward on release (5.15.14
> take #2) and improving the build/tests.
> >
> > Regards
> > JB
> >
> >> Le 1 déc. 2020 à 22:46, Arthur Naseef  a écrit :
> >>
> >> So the ClassCastException happens in 5.15.13 and 5.15.10 when I run that
> >> test specifically.
> >> I suspect we have a case where the test class inheritance is causing
> >> confusion.  If so, then the fix here is to bypass the base-class test
> >> method.
> >>
> >> Can someone look at the test method
> >> testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded
> >> in JmsSchedulerTest.java and answer the question, "does this test method
> >> make sense for the in-memory scheduler?"  I suspect the in-memory
> scheduler
> >> just doesn't have a journal, so the test doesn't apply.
> >>
> >> Still no update on (2).
> >>
> >> Art
> >>
> >>
> >> On Tue, Dec 1, 2020 at 1:48 PM Arthur Naseef  wrote:
> >>
> >>> Looks like I'm finding 2 problems with the InMemeoryJmsSchedulerTest:
> >>>
> >>>
> >>>  1. The ClassCastException in one test, and
> >>>  2. "Didn't receive the message" problem in the other.
> >>>
> >>>
> >>> Digging into the ClassCastException, all the code appears to be
> unchanged
> >>> for at least 6 months.  Could this have been broken all this time?
> >>>
> >>> Haven't dug into the second problem yet.
> >>>
> >>> Art
> >>>
> >>>
> >>> On Tue, Dec 1, 2020 at 1:03 PM Arthur Naseef  wrote:
> >>>
> >>>> So it looks like my build only had 2 test failures.  The first we
> >>>> discussed already.  The second is as follows:
> >>>>
> >>>> [INFO] Running
> >>>> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
> >>>> [ERROR] Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time
> elapsed:
> >>>> 41.993 s <<< FAILURE! - in
> >>>> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
> >>>> [ERROR]
> >>>>
> testScheduleFullRecoveryRestart(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
> >>>> Time elapsed: 5.514 s  <<< FAILURE!
> >>>> java.lang.AssertionError: Didn't receive the message
> >>>>
> >>>> [ERROR]
> >>>>
> testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
> >>>> Time elapsed: 0.005 s  <<< ERROR!
> >>>> java.lang.ClassCastException:
> >>>> org.apache.activemq.broker.scheduler.memory.InMemoryJobSchedulerStore
> >>>> cannot be cast to
> >>>> org.apache.ac

Re: [CANCEL][VOTE] Apache ActiveMQ 5.15.14 release

[Arthur Naseef]

So the ClassCastException happens in 5.15.13 and 5.15.10 when I run that
test specifically.
I suspect we have a case where the test class inheritance is causing
confusion.  If so, then the fix here is to bypass the base-class test
method.

Can someone look at the test method
testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded
in JmsSchedulerTest.java and answer the question, "does this test method
make sense for the in-memory scheduler?"  I suspect the in-memory scheduler
just doesn't have a journal, so the test doesn't apply.

Still no update on (2).

Art


On Tue, Dec 1, 2020 at 1:48 PM Arthur Naseef  wrote:

> Looks like I'm finding 2 problems with the InMemeoryJmsSchedulerTest:
>
>
>1. The ClassCastException in one test, and
>2. "Didn't receive the message" problem in the other.
>
>
> Digging into the ClassCastException, all the code appears to be unchanged
> for at least 6 months.  Could this have been broken all this time?
>
> Haven't dug into the second problem yet.
>
> Art
>
>
> On Tue, Dec 1, 2020 at 1:03 PM Arthur Naseef  wrote:
>
>> So it looks like my build only had 2 test failures.  The first we
>> discussed already.  The second is as follows:
>>
>> [INFO] Running
>> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
>> [ERROR] Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time elapsed:
>> 41.993 s <<< FAILURE! - in
>> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
>> [ERROR]
>> testScheduleFullRecoveryRestart(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
>>  Time elapsed: 5.514 s  <<< FAILURE!
>> java.lang.AssertionError: Didn't receive the message
>>
>> [ERROR]
>> testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
>>  Time elapsed: 0.005 s  <<< ERROR!
>> java.lang.ClassCastException:
>> org.apache.activemq.broker.scheduler.memory.InMemoryJobSchedulerStore
>> cannot be cast to
>> org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl'
>>
>>
>> I'm looking into it - please let me know if this is also a known issue.
>>
>> Art
>>
>>
>> On Mon, Nov 30, 2020 at 10:22 PM Jean-Baptiste Onofre 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> Due to an issue with the fix for AMQ-8045, I cancel this vote to prepare
>>> a new one.
>>>
>>> Sorry about that. And thanks Art to find this.
>>>
>>> A new vote will start today.
>>>
>>> Regards
>>> JB
>>>
>>> > Le 24 nov. 2020 à 08:00, Jean-Baptiste Onofre  a
>>> écrit :
>>> >
>>> > Hi everyone,
>>> >
>>> > I submit Apache ActiveMQ 5.15.14 to your vote.
>>> > This release includes CVE related updates and bug fixes.
>>> >
>>> > Please take a look on the Release Notes for details:
>>> >
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
>>> <
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
>>> >
>>> >
>>> > The Maven staging repository is:
>>> >
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1220/
>>> <
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1220/
>>> >
>>> >
>>> > The dist staging repository is:
>>> > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/ <
>>> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/>
>>> >
>>> > Git tag:
>>> > activemq-5.15.14
>>> >
>>> > 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: [CANCEL][VOTE] Apache ActiveMQ 5.15.14 release

[Arthur Naseef]

Looks like I'm finding 2 problems with the InMemeoryJmsSchedulerTest:


   1. The ClassCastException in one test, and
   2. "Didn't receive the message" problem in the other.


Digging into the ClassCastException, all the code appears to be unchanged
for at least 6 months.  Could this have been broken all this time?

Haven't dug into the second problem yet.

Art


On Tue, Dec 1, 2020 at 1:03 PM Arthur Naseef  wrote:

> So it looks like my build only had 2 test failures.  The first we
> discussed already.  The second is as follows:
>
> [INFO] Running
> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
> [ERROR] Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time elapsed:
> 41.993 s <<< FAILURE! - in
> org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
> [ERROR]
> testScheduleFullRecoveryRestart(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
>  Time elapsed: 5.514 s  <<< FAILURE!
> java.lang.AssertionError: Didn't receive the message
>
> [ERROR]
> testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
>  Time elapsed: 0.005 s  <<< ERROR!
> java.lang.ClassCastException:
> org.apache.activemq.broker.scheduler.memory.InMemoryJobSchedulerStore
> cannot be cast to
> org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl'
>
>
> I'm looking into it - please let me know if this is also a known issue.
>
> Art
>
>
> On Mon, Nov 30, 2020 at 10:22 PM Jean-Baptiste Onofre 
> wrote:
>
>> Hi everyone,
>>
>> Due to an issue with the fix for AMQ-8045, I cancel this vote to prepare
>> a new one.
>>
>> Sorry about that. And thanks Art to find this.
>>
>> A new vote will start today.
>>
>> Regards
>> JB
>>
>> > Le 24 nov. 2020 à 08:00, Jean-Baptiste Onofre  a
>> écrit :
>> >
>> > Hi everyone,
>> >
>> > I submit Apache ActiveMQ 5.15.14 to your vote.
>> > This release includes CVE related updates and bug fixes.
>> >
>> > Please take a look on the Release Notes for details:
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
>> <
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
>> >
>> >
>> > The Maven staging repository is:
>> >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1220/
>> <
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1220/
>> >
>> >
>> > The dist staging repository is:
>> > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/ <
>> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/>
>> >
>> > Git tag:
>> > activemq-5.15.14
>> >
>> > 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: [CANCEL][VOTE] Apache ActiveMQ 5.15.14 release

[Arthur Naseef]

So it looks like my build only had 2 test failures.  The first we discussed
already.  The second is as follows:

[INFO] Running
org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
[ERROR] Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time elapsed:
41.993 s <<< FAILURE! - in
org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
[ERROR]
testScheduleFullRecoveryRestart(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
 Time elapsed: 5.514 s  <<< FAILURE!
java.lang.AssertionError: Didn't receive the message

[ERROR]
testUpdatesAppliedToIndexBeforeJournalShouldBeDiscarded(org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest)
 Time elapsed: 0.005 s  <<< ERROR!
java.lang.ClassCastException:
org.apache.activemq.broker.scheduler.memory.InMemoryJobSchedulerStore
cannot be cast to
org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl'


I'm looking into it - please let me know if this is also a known issue.

Art


On Mon, Nov 30, 2020 at 10:22 PM Jean-Baptiste Onofre 
wrote:

> Hi everyone,
>
> Due to an issue with the fix for AMQ-8045, I cancel this vote to prepare a
> new one.
>
> Sorry about that. And thanks Art to find this.
>
> A new vote will start today.
>
> Regards
> JB
>
> > Le 24 nov. 2020 à 08:00, Jean-Baptiste Onofre  a écrit
> :
> >
> > Hi everyone,
> >
> > I submit Apache ActiveMQ 5.15.14 to your vote.
> > This release includes CVE related updates and bug fixes.
> >
> > Please take a look on the Release Notes for details:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294
> >
> >
> > The Maven staging repository is:
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1220/
> <
> https://repository.apache.org/content/repositories/orgapacheactivemq-1220/
> >
> >
> > The dist staging repository is:
> > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/ <
> https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/>
> >
> > Git tag:
> > activemq-5.15.14
> >
> > 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 5.15.14 release

[Arthur Naseef]

Ahh, thanks for letting me know.  I'll wait for the fix on that one and
look at the other tests.

Art


On Mon, Nov 30, 2020 at 10:11 PM Jean-Baptiste Onofre 
wrote:

> Hi Arthur,
>
> That’s a real issue due a change introduce in the default jetty.xml to
> load the jetty-realm.
>
> My bad, I will fix that.
>
> Thanks !
> Regards
> JB
>
> > Le 1 déc. 2020 à 05:00, Arthur Naseef  a écrit :
> >
> > I'm running the build on an Ubuntu system and getting 4 test failures.  I
> > retried 1 and it repeated.
> >
> > I'll look at the failures more tomorrow.  Here are the errors from the
> test
> > I retried:
> >
> > [ERROR]
> >
> testStartBrokerUsingXmlConfig1[activemq-leveldb-replicating.xml](org.apache.activemq.config.BrokerXmlConfigStartTest)
> > Time elapsed: 1.222 s  <<< ERROR!
> > org.springframework.beans.factory.BeanCreationException: Error creating
> > bean with name 'invokeStart' defined in file
> > [/home/art/work/activemq/src/activemq/assembly/target/conf/jetty.xml]:
> > Invocation of init method failed; nested exception is
> > java.lang.IllegalStateException: java.lang.IllegalArgumentException:
> > file:target/conf/jetty-realm.properties
> > at
> >
> org.apache.activemq.config.BrokerXmlConfigStartTest.testStartBrokerUsingXmlConfig1(BrokerXmlConfigStartTest.java:95)
> > Caused by: java.lang.IllegalStateException:
> > java.lang.IllegalArgumentException:
> file:target/conf/jetty-realm.properties
> > at
> >
> org.apache.activemq.config.BrokerXmlConfigStartTest.testStartBrokerUsingXmlConfig1(BrokerXmlConfigStartTest.java:95)
> > Caused by: java.lang.IllegalArgumentException:
> > file:target/conf/jetty-realm.properties
> > at
> >
> org.apache.activemq.config.BrokerXmlConfigStartTest.testStartBrokerUsingXmlConfig1(BrokerXmlConfigStartTest.java:95)
> >
> > Art
> >
> >
> > On Mon, Nov 30, 2020 at 5:37 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> +1,
> >>
> >> -verified checksum and gpg signature
> >> -ran a build and ran through smoke tests
> >> -ran broker from release to verify it starts
> >>
> >> On Fri, Nov 27, 2020 at 8:43 PM Robbie Gemmell <
> robbie.gemm...@gmail.com>
> >> wrote:
> >>
> >>> The issues I was noting were with the staged dist repo contents rather
> >>> than the maven repo. There is a helper script for prepping the dist
> >>> area contents inc verifying the gpg sig at
> >>> https://dist.apache.org/repos/dist/dev/activemq/activemq/
> >>>
> >>> On Fri, 27 Nov 2020 at 17:43, Matt Pavlovich 
> wrote:
> >>>>
> >>>> Robbie-
> >>>>
> >>>> Here is a release validation script:
> >>>>
> >>>> https://github.com/apache/activemq/pull/587 <
> >>> https://github.com/apache/activemq/pull/587>
> >>>>
> >>>> You can pass an arg to change the Maven repo.
> >>>>
> >>>> Currently it validates:
> >>>>
> >>>> 1. Download tar.gz and zip files
> >>>> 2. Validates SHA1 and MD5
> >>>> 3. Extracts the zip and tar.gz
> >>>> 4. Cleans up after itself
> >>>>
> >>>> Next step would be to add the gpg signature validation
> >>>>
> >>>> Thanks,
> >>>> Matt Pavlovich
> >>>>
> >>>>> On Nov 27, 2020, at 9:56 AM, Robbie Gemmell <
> >> robbie.gemm...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>> The issues I noted (.md5 present, -bin files missing) dont appear to
> >>>>> be fixed for 5.15.14 yet? Still showing via the dist area HTTP view
> >>>>> and svn directly for me at least.
> >>>>>
> >>>>> On Fri, 27 Nov 2020 at 15:21, Jean-Baptiste Onofre 
> >>> wrote:
> >>>>>>
> >>>>>> It’s already fixed for the 5.15.14 release and I will push the fix
> >> on
> >>> the script.
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>>> Le 27 nov. 2020 à 16:10, Robbie Gemmell 
> >>> a écrit :
> >>>>>>>
> >>>>>>> I would fix the dist problems before starting another release
> >>>>>>> personally, so that any new voters can prope

Re: [VOTE] Apache ActiveMQ 5.15.14 release

[Arthur Naseef]

I'm running the build on an Ubuntu system and getting 4 test failures.  I
retried 1 and it repeated.

I'll look at the failures more tomorrow.  Here are the errors from the test
I retried:

[ERROR]
testStartBrokerUsingXmlConfig1[activemq-leveldb-replicating.xml](org.apache.activemq.config.BrokerXmlConfigStartTest)
 Time elapsed: 1.222 s  <<< ERROR!
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'invokeStart' defined in file
[/home/art/work/activemq/src/activemq/assembly/target/conf/jetty.xml]:
Invocation of init method failed; nested exception is
java.lang.IllegalStateException: java.lang.IllegalArgumentException:
file:target/conf/jetty-realm.properties
at
org.apache.activemq.config.BrokerXmlConfigStartTest.testStartBrokerUsingXmlConfig1(BrokerXmlConfigStartTest.java:95)
Caused by: java.lang.IllegalStateException:
java.lang.IllegalArgumentException: file:target/conf/jetty-realm.properties
at
org.apache.activemq.config.BrokerXmlConfigStartTest.testStartBrokerUsingXmlConfig1(BrokerXmlConfigStartTest.java:95)
Caused by: java.lang.IllegalArgumentException:
file:target/conf/jetty-realm.properties
at
org.apache.activemq.config.BrokerXmlConfigStartTest.testStartBrokerUsingXmlConfig1(BrokerXmlConfigStartTest.java:95)

Art


On Mon, Nov 30, 2020 at 5:37 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1,
>
> -verified checksum and gpg signature
> -ran a build and ran through smoke tests
> -ran broker from release to verify it starts
>
> On Fri, Nov 27, 2020 at 8:43 PM Robbie Gemmell 
> wrote:
>
> > The issues I was noting were with the staged dist repo contents rather
> > than the maven repo. There is a helper script for prepping the dist
> > area contents inc verifying the gpg sig at
> > https://dist.apache.org/repos/dist/dev/activemq/activemq/
> >
> > On Fri, 27 Nov 2020 at 17:43, Matt Pavlovich  wrote:
> > >
> > > Robbie-
> > >
> > > Here is a release validation script:
> > >
> > > https://github.com/apache/activemq/pull/587 <
> > https://github.com/apache/activemq/pull/587>
> > >
> > > You can pass an arg to change the Maven repo.
> > >
> > > Currently it validates:
> > >
> > > 1. Download tar.gz and zip files
> > > 2. Validates SHA1 and MD5
> > > 3. Extracts the zip and tar.gz
> > > 4. Cleans up after itself
> > >
> > > Next step would be to add the gpg signature validation
> > >
> > > Thanks,
> > > Matt Pavlovich
> > >
> > > > On Nov 27, 2020, at 9:56 AM, Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > wrote:
> > > >
> > > > The issues I noted (.md5 present, -bin files missing) dont appear to
> > > > be fixed for 5.15.14 yet? Still showing via the dist area HTTP view
> > > > and svn directly for me at least.
> > > >
> > > > On Fri, 27 Nov 2020 at 15:21, Jean-Baptiste Onofre 
> > wrote:
> > > >>
> > > >> It’s already fixed for the 5.15.14 release and I will push the fix
> on
> > the script.
> > > >>
> > > >> Regards
> > > >> JB
> > > >>
> > > >>> Le 27 nov. 2020 à 16:10, Robbie Gemmell 
> > a écrit :
> > > >>>
> > > >>> I would fix the dist problems before starting another release
> > > >>> personally, so that any new voters can properly inspect things.
> > > >>>
> > > >>> Aside, I since saw that you only added the .md5 this morning along
> > > >>> with the .sha512 contents. I'm not sure how so many people managed
> to
> > > >>> vote for it without verifying the checksum, except perhaps everyone
> > > >>> just assumed someone else would do it. That's one reason it's good
> to
> > > >>> say what testing you actually did when voting, to help spot such
> > gaps.
> > > >>>
> > > >>> Robbie
> > > >>>
> > > >>> On Fri, 27 Nov 2020 at 12:39, Jean-Baptiste Onofre <
> j...@nanthrax.net>
> > wrote:
> > > 
> > >  Yeah I know ;) Not a problem. We can wait ! I will move forward on
> > 5.16.1 in the meantime.
> > > 
> > >  Thanks !
> > >  Regards
> > >  JB
> > > 
> > > > Le 27 nov. 2020 à 12:48, Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > a écrit :
> > > >
> > > > Many of the people you are looking to remind are likely not
> around
> > to
> > > > see it, being on vacation either for or just around the US
> > > > Thanksgiving. It's probably the second worst point of the year to
> > have
> > > > a release vote open unfortunately.
> > > >
> > > > I'd note that the binary archives are missing from the dist
> staging
> > > > area, and there is an MD5 checksum present for the source release
> > > > which should be removed given they aren't meant to be
> distributed.
> > > >
> > > > On Fri, 27 Nov 2020 at 04:58, Jean-Baptiste Onofre <
> > j...@nanthrax.net> wrote:
> > > >>
> > > >> Gently reminder about this vote.
> > > >>
> > > >> Thanks !
> > > >> Regards
> > > >> JB
> > > >>
> > > >>> Le 24 nov. 2020 à 08:00, Jean-Baptiste Onofre  >
> > a écrit :
> > > >>>
> > > >>> Hi everyone,
> > > >>>
> > > >>> I submit Apache ActiveMQ 5.15.14 to your vo

Re: [DISCUSS]: move to Jakarta Messaging API

[Arthur Naseef]

To clarify, the subject says "move to" which sounds at first like "remove
and replace" - but that's not the intent, right?  Just talking about adding
the JakartaEE API and keeping JMS 2.0, correct?

If it's just adding a new API, I have no strong feelings either way.

Art


On Tue, Sep 22, 2020 at 10:02 AM Emmanuel Hugonnet 
wrote:

> Hello,
> Currently Artemis is exposing a JMS 2.0 API but Java EE has moved toward
> JakartaEE.
> For JakartaEE 9 there is only a namespace switch( with more coming on with
> JakartaEE 10).
> Shouldn't we propose new artefacts that expose Jakarta Messaging API too ?
> Do yo have any idea on how to create and provide those artefacts ?
>
> Cheers,
> Emmanuel
>
>

Re: [DISCUSS] JMS 2.0 support in 5.x going forward

[Arthur Naseef]

I'm just catching up on this thread and didn't read it all thoroughly, so
forgive me if I missed anything.

The idea of using Virtual Topics to meet the JMS 2.0 "named subscriptions"
feature sounds like a good approach.

One question that raises - removal of the queue so ensure it doesn't end up
abandoned while collecting messages.  Perhaps it is feasible to
automatically remove the queue when the named-subscription goes away?

In a network-of-brokers, there will be race conditions that will make this
complicated.  Virtual Topics already have the same race conditions, so it's
nothing new, but something to consider - especially when the use of the
feature is simplified in a way that makes it easier for developers to "just
use it".  An example race condition: removal of the queue on one broker
while adding messages to the topic, and hence the queue, on another broker.

With all that said, adding support for some of the simpler JMS 2.0 features
is welcome (like the simplified session creation).  Good communication will
be important.  We all know there will be developers who see the JMS 2.0
methods and immediately assume all of JMS 2.0 is implemented.

Hope this helps.

Art



On Thu, Jun 25, 2020 at 9:19 AM Matt Pavlovich  wrote:

> I think the approach is sound. I don’t see a lot of
> JMS-v2.0-as-a-minumum-version
> dependency in many 3rd party systems that integrate with JMS. They tend to
> use the v1.1 API
> method signatures anyway. IMHO throwing an UnsupportedException is a
> reasonable for the
> client-side JMS 2.0-specific methods for Chris’ point 1.
>
> As for claiming ActiveMQ 5.x as “Supports JMS 2.0"— I think using Virtual
> Topics in approach #3 sounds reasonable to
> consider ActiveMQ 5.x as “Supports JMS 2.0" on the server-side. Other JMS
> v2.0 brokers use queues to back durable topic
> subscriptions, and make the same claim (ie IBM MQ). Also, ActiveMQ 5.x
> optionally uses a similar pattern with
> MQTT to be backed by Virtual Topics so it would not be setting a new
> precedent within ActiveMQ or the industry
> in general to call it “Supports JMS 2.0” by using a queue to back the
> shared topic subscription.
>
> -Matt Pavlovich
>
> > On Jun 25, 2020, at 9:06 AM, Jean-Baptiste Onofré 
> wrote:
> >
> > Hi,
> >
> > Thanks Chris for bringing this up.
> >
> > First, a quick update about JMS 2.0: client API compatibility is almost
> > done. I tested in Karaf, Camel and standalone Java and so far so good.
> >
> > My first intention when I proposed the JMS 2.0 support is first on
> > client side, as least to allow client to use JMS 2.0 API.
> >
> > About the specific features from JMS 2.0, the first step I did is to
> > return OperationNotSupportedException for now. So it's mostly Chris'
> > point 1.
> >
> > In term of roadmap, I tried to follow recommendation and feedback from
> > everyone. So roughly, that's my intention/understanding:
> >
> > - 5.16.0: JDK 11 support at runtime
> > - 5.16.x: first JMS 2.0 client side support (before 5.17.0).
> > - 5.17.0: JDK 11 support at both build and runtime and improved JMS 2.0
> > support (even if not complete on broker side ;)).
> >
> > I'm ready to move forward on (3), but I think it's worth to create PR
> > and merge what I started already.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> >
> > On 25/06/2020 15:10, Christopher Shannon wrote:
> >> There seems to be some confusion on what the plan is for JMS 2.0
> support in
> >> 5.x so I figured it was worth starting a discussion on it.
> >>
> >> First, targeting a complete implementation of "full" JMS 2.0 support for
> >> 5.17.0 is not very realistic in my opinion. I think 5.17.0 needs to go
> out
> >> faster than 5.16.0 did as for one thing it is starting to get annoying
> to
> >> have to use JDK 8 to build it. If JMS 2.0 support is going to happen
> that's
> >> probably going to take a few releases along the way with increasing
> >> functionality for each one and there is still a discussion that needs to
> >> happen on what will actually be done and the effort level. The main
> level
> >> of effort is dealing with the new shared subscription semantics.
> >>
> >> For example, in order of increasing effort:
> >> *1)* We could just add basic API compatibility with the JMS 2.0 jar but
> >> don't really implement many features at all (maybe have unsupported
> >> exceptions thrown if a new method is called) which i think was the goal
> of
> >> 5.16.1. Note that this isn't really buying much as a user can simply use
> >> the JMS 2.0 jar now with 5.x and just not call the new methods (which is
> >> what I personally do)
> >> *2)* We could have the Java client fake it by using Virtual topics to
> >> create shared subscriptions. So if a user calls off to the shared sub
> api
> >> call it would just subscribe to the matching queue it needed. The
> downside
> >> to this is it's done all client side so would only work for the Java
> client
> >> and not any other open wire clients and is pretty hacky. Seems better to
> 

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

[Arthur Naseef]

+1

JB: very good - thanks for the feedback.

Build is successful with no problems beyond the warning mentioned earlier -
first time in a very long time that I've had a fully successful build in
one shot - very nice.

License notifications appear to be on most files.  Several readme.txt files
don't include the license, but I don't think that's a concern.

The broker starts up and passes messages.  Web console works.

Cheers.

Art


On Tue, Jun 30, 2020 at 12:24 AM Jean-Baptiste Onofre 
wrote:

> Hi
>
> That’s a warning present for a very long time. I already prepared the
> update to maven-bundle-plugin 4.2.1 allowing us to build using JDK 11
> (targeted for ActiveMQ 5.17.0).
>
> This warning also exists on activemq-5.15.x branch for very very long time.
>
> So, no blocker, and I already fix that.
>
> Regards
> JB
>
> > Le 30 juin 2020 à 06:51, Arthur Naseef  a écrit :
> >
> > I'm building now.  Don't know how quickly it'll get done, so I won't be
> > surprised if the vote is closed before then.
> >
> > There is an error in making the activemq-client bundle - any thoughts on
> > this?
> >
> >
> > [INFO] --- maven-bundle-plugin:2.3.7:bundle (default-bundle) @
> > activemq-client ---
> > java.lang.ArrayIndexOutOfBoundsException: 18
> >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:1595)
> >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.BundlePlugin.buildOSGiBundle(BundlePlugin.java:547)
> >at
> > org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:347)
> >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:137)
> >at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> >at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> >at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> >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:56)
> >at
> >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> >at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
> >at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> >at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> >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:282)
> >at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> >at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> >at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> > [WARNING] Bundle org.apache.activemq:activem

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

[Arthur Naseef]

I'm building now.  Don't know how quickly it'll get done, so I won't be
surprised if the vote is closed before then.

There is an error in making the activemq-client bundle - any thoughts on
this?


[INFO] --- maven-bundle-plugin:2.3.7:bundle (default-bundle) @
activemq-client ---
java.lang.ArrayIndexOutOfBoundsException: 18
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:1595)
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.BundlePlugin.buildOSGiBundle(BundlePlugin.java:547)
at
org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:347)
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:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
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:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
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:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
[WARNING] Bundle org.apache.activemq:activemq-client:bundle:5.16.0 :
Instructions in Private-Package, or -testpackages that are never used:
com\.google\.errorprone\.annotations\.concurrent
com\.google\.errorprone\.annotations
Classpath:
Jar:.,Jar:slf4j-api,Jar:geronimo-jms_1.1_spec,Jar:hawtbuf,Jar:geronimo-j2ee-management_1.1_spec,Jar:commons-net,Jar:jmdns,Jar:log4j

[WARNING] Bundle org.apache.activemq:activemq-client:bundle:5.16.0 : Did
not find matching referal for !com.google.errorprone.annotations
[WARNING] Bundle org.apache.activemq:activemq-client:bundle:5.16.0 : Did
not find matching referal for !com.google.errorprone.annotations.concurrent
[ERROR] Bundle org.apache.activemq:activemq-client:bundle:5.16.0 :
Exception: 18
[ERROR] Bundle org.apache.activemq:activemq-client:bundle:5.16.0 : Invalid
class file: org/apache/activemq/filter/DestinationMap.class

I believe this is not causing the build to fail, but I can't rule that out
because I used "mvn -fn ..." to ensure a complete build.

So far, all of the tests are passing (up to LevelDBStoreBrokerTest).

Art


On Mon, Jun 29, 2020 at 9:53 AM Daniel Kulp  wrote:

> +1, simple building and running basic tests looks OK
>
> --
> Daniel Kulp
> dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend - http://talend.com 
>
>
>
> > On Jun 25, 2020, at 10:23 AM, 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.
> >
> > I

Re: Building Errors

[Arthur Naseef]

You should not see any problems with mixing versions.  With that said,
please test before rolling out to production.  In our history, we have had
a couple of unintentional version-mismatch issues arise, so they are very
rare, but not impossible.

Art


On Thu, Apr 30, 2020 at 4:04 AM goutamknit  wrote:

> HI,
>
> We are going to upgrade activemq 5.14.5 to 5.15.5 . To understand
> compatibillity matrix between client and broker i search on documentation
> but do not found any thing.
> So can we have broker on 5.14.5 and client on 5.15.5 vice-versa, do we have
> issue with that?
>
> Any reference of documentation will be helpfull.
>
> Thanks
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>

Re: Porting JAVA examples to C#

[Arthur Naseef]

I would be comfortable to use a maven profile that is disabled by default
together with the plugin to do the C# build.

Any concerns with that approach?

Art

P.S. Apologies if I missed something from your messages Michael - the
spacing on my screen is a mess (looks like lost newlines).


On Tue, Apr 7, 2020 at 2:21 PM michael.andre.pearce
 wrote:

> Plugin that we use internally at work where a project is java and dotnet
> and use maven to perform the build and release.
> https://github.com/kaspersorensen/dotnet-maven-pluginIts apache licensed
> so no issues there.Sent from my Samsung Galaxy smartphone.
>  Original message From: "michael.andre.pearce" <
> michael.andre.pea...@me.com> Date: 07/04/2020  22:15  (GMT+00:00) To:
> dev@activemq.apache.org Subject: Re: Porting JAVA examples to C# A few
> things here.You can actually bind the build with maven and dotnet, theres a
> maven plugin that will actually download bits needed for dotnet core and
> compile and even run. This way you could actually tie it into the maven
> release.Re core 3. Before anything in examples can be updated theres
> outstanding work on nms openwire to make it compatible with netstd this
> really needs to complete first.Lastly as a community the efforts to slowly
> drive Artemis forwards i would want to see examples added to
> Artemis. BestMikeSent from my Samsung Galaxy smartphone.

Re: Porting JAVA examples to C#

[Arthur Naseef]

Did you get any feedback on this?

Here are thoughts that come to mind...

The src/main/java/... structure is used by (and "encouraged" by) Maven.
Would the C# sources be built as part of the maven build process?  If so,
how do we ensure folks can build the Java sources even when they don't have
the tooling to build the C# sources?

Art


On Mon, Mar 23, 2020 at 4:15 AM Ruslan.Shupoval 
wrote:

> Hello to everyone.
>
> I'd like to port java examples located at " ActiveMQ OpenWire
> <
> https://github.com/apache/activemq/tree/master/assembly/src/release/examples/openwire>
>
> " to C#.
> Prior to start doing this I'd like to clarify a few things:
> Does the  ActiveMQ OpenWire
> <
> https://github.com/apache/activemq/tree/master/assembly/src/release/examples/openwire>
>
> location is the place in repo where examples are stored (those examples
> that
> are included into e.g.  apache-activemq-5.15.12-bin.zip
> <
> http://www.apache.org/dyn/closer.cgi?filename=/activemq/5.15.12/apache-activemq-5.15.12-bin.zip&action=download>
>
> ?
> Would it be acceptable to create charp directory (sibling to corresponding
> java directory) for c# examples (e.g.
>
> "/activemq/assembly/src/release/examples/openwire/advanced-scenarios/jms-example-wildcard-consumer/src/main/*java*/"
> directory currently contains java samples and to create new
>
> "/activemq/assembly/src/release/examples/openwire/advanced-scenarios/jms-example-wildcard-consumer/src/main/*charp*/"
> for the same example but in c#
> I'l like to use .net core 3.1 (latest at this moment)
> Shall I create a separate Jira ticker for this?
>
> Please let me know in case of any other questions or suggestions.
>
> Kind regards,
> Ruslan
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

Re: Artemis Consumers

[Arthur Naseef]

col
> > potentially has multiple client implementations.
> > I believe I am using the CORE protocol and API. Please see my GitHub repo
> >
> > Also, please elaborate on:
> >  - how you made your observations and drew your conclusions
> > I log the throughput on the producer side by calculating the number of
> > messages sent every second, the same is done on the consumer side.
> >  - the message volume your working with
> > When I set to the queue to persistent the throughput on the producer side
> > is 50k msg per second, non persistent its 250k msg per second. The
> consumer
> > side throughput is much slower 10k and 50k respectively.
> >
> >
> >  - the number of producers and consumers
> > I have 4 producers and 4 consumers each running on different machines.
> The
> > single broker is on its own machine.
> >
> > Justin
> >
> >
> >
> >
> >
> >
> >
> > > On Sep 17, 2019, at 1:30 AM, Arthur Naseef  wrote:
> > >
> > > While it is possible to improve throughput with batching acks in
> > > transactions, I would recommend to check some other things first.  Also
> > > note that transactions can introduce other issues, as I have
> experienced.
> > >
> > > Here are things I recommend to try (forgive me if these have already
> been
> > > tried):
> > >
> > >   - First, reproduce the problem outside of production if not already
> > done
> > >   - Increase the number of consumers on the queue
> > >   - Attach consumers that do no processing on the messages -- only
> > >   consume, ack, and discard - this will give a baseline for just how
> > fast the
> > >   consumers can go between the lowest level of the application and the
> > broker
> > >   - Consume and produce from the same machine to isolate away potential
> > >   differences in system, I/O, and network across multiple systems
> > >   - Measure network and system I/O on the systems (especially the
> > consumer
> > >   systems)
> > >
> > > The following information on the messaging use-case would help further:
> > >
> > >   - What QoS is used for the messages (persistent vs non-persistent,
> > etc)?
> > >   - Are message groups, selectors, or other messaging features used?
> > >   - Are transactions in-use?  If so, are they XA?
> > >   - How large are the messages?
> > >
> > > Hope this helps.
> > >
> > > Art
> > >
> > >
> > > On Fri, Sep 13, 2019 at 4:20 PM Clebert Suconic <
> > clebert.suco...@gmail.com>
> > > wrote:
> > >
> > >> You can batch acks in transactions.
> > >>
> > >> On Thu, Sep 12, 2019 at 7:14 PM Brian Ramprasad <
> bri...@cs.utoronto.ca>
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I am trying to improve the throughput of queue Consumers. At present
> > the
> > >>> Consumers are much slower than the Producers resulting in messages
> > >> building
> > >>> up inside a queue. From what I can see(maybe I’m wrong) it looks like
> > >>> messages are sent to consumers of a queue one at a time in a round
> > robin
> > >>> fashion which is not very efficient. Do you know if there is a way to
> > >> batch
> > >>> messages together when sending to a consumer? For example if I have 2
> > >>> consumers, I want to send them batches of 500 msgs each.
> > >>> If I need to implement this feature myself, does anyone know which
> java
> > >>> class I need to modify?
> > >>>
> > >>> Thanks!
> > >>> Brian R
> > >>>
> > >>>
> > >>> --
> > >> Clebert Suconic
> > >>
> >
> >
>

Re: Artemis Consumers

[Arthur Naseef]

While it is possible to improve throughput with batching acks in
transactions, I would recommend to check some other things first.  Also
note that transactions can introduce other issues, as I have experienced.

Here are things I recommend to try (forgive me if these have already been
tried):

   - First, reproduce the problem outside of production if not already done
   - Increase the number of consumers on the queue
   - Attach consumers that do no processing on the messages -- only
   consume, ack, and discard - this will give a baseline for just how fast the
   consumers can go between the lowest level of the application and the broker
   - Consume and produce from the same machine to isolate away potential
   differences in system, I/O, and network across multiple systems
   - Measure network and system I/O on the systems (especially the consumer
   systems)

The following information on the messaging use-case would help further:

   - What QoS is used for the messages (persistent vs non-persistent, etc)?
   - Are message groups, selectors, or other messaging features used?
   - Are transactions in-use?  If so, are they XA?
   - How large are the messages?

Hope this helps.

Art


On Fri, Sep 13, 2019 at 4:20 PM Clebert Suconic 
wrote:

> You can batch acks in transactions.
>
> On Thu, Sep 12, 2019 at 7:14 PM Brian Ramprasad 
> wrote:
>
> > Hi,
> >
> > I am trying to improve the throughput of queue Consumers. At present the
> > Consumers are much slower than the Producers resulting in messages
> building
> > up inside a queue. From what I can see(maybe I’m wrong) it looks like
> > messages are sent to consumers of a queue one at a time in a round robin
> > fashion which is not very efficient. Do you know if there is a way to
> batch
> > messages together when sending to a consumer? For example if I have 2
> > consumers, I want to send them batches of 500 msgs each.
> > If I need to implement this feature myself, does anyone know which java
> > class I need to modify?
> >
> > Thanks!
> > Brian R
> >
> >
> > --
> Clebert Suconic
>

Re: Unable to connect to remote host IP:port using Apache Active MQ Message Broker

[Arthur Naseef]

Try 'netstat -an'

It appears something else is already using that port.


On Sat, Jul 27, 2019 at 8:02 AM balan.karuppasamy <
balan.karuppas...@cognizant.com> wrote:

> Hello,
>
> In *conf/activemq.xml* , we have below configuration to connect with remote
> host and port.
>
>  
>   
> uri="tcp://:*?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
>
>   
>
> In *bin/env* , we have below configuration to connect with remote host and
> port.
>
> if [ -z "$ACTIVEMQ_QUEUEMANAGERURL" ]; then
>  ACTIVEMQ_QUEUEMANAGERURL="--amqurl *tcp://:*"
> fi
>
> When we run active MQ console from bin directory as below
>
> *./activemq console*
>
> We are getting below error
>
> WARN | Exception encountered during context initialization - cancelling
> refresh attempt: org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in class path
> resource [activemq.xml]: Invocation of init method failed; nested exception
> is java.io.IOException: Transport Connector could not be registered in JMX:
> java.io.IOException: *Failed to bind to server socket:
>
> tcp://:*?maximumConnections=1000&wireFormat.maxFrameSize=104857600
> due to: java.net.BindException: *Cannot assign requested address (Bind
> failed)*
> ERROR: java.lang.RuntimeException: Failed to execute start task. Reason:
> java.lang.IllegalStateException: BeanFactory not initialized or already
> closed - call 'refresh' before accessing beans via the ApplicationContext
> java.lang.RuntimeException: Failed to execute start task. Reason:
> java.lang.IllegalStateException: BeanFactory not initialized or already
> closed - call 'refresh' before accessing beans via the ApplicationContext
>
> Can you please let us know for any pointers that we need to consider.
>
> In network connection setup, from our server we are connecting to vendor
> server, from which , we are connecting to remote host and port.
>
> Also, in order to receive from the remote host, let us know where the
> Apache
> Active MQ message broker should run.
>
> 1. In our local server.
> 2. In Vendor server.
> 3. In Remote server.
>
> Thanks,
> Balan
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>