Re: Test message api looks to be broken in ActiveMQ 5.18.4

[Christopher Shannon]

This issue was also fixed in 5.18.5, see
https://issues.apache.org/jira/browse/AMQ-9330

On Mon, Jul 15, 2024 at 5:35 PM Mau, I-Min 
wrote:

> And it did work.  Thanks all!
>
> From: Mau, I-Min 
> Sent: Monday, July 15, 2024 4:11 PM
> To: Matt Pavlovich ; users@activemq.apache.org
> Cc: Bhattacharjee, Tapas ; Mau, I-Min <
> i-min@fisglobal.com>
> Subject: RE: Test message api looks to be broken in ActiveMQ 5.18.4
>
> But just as FYI, it does look like Matt’s response is what we needed, I am
> going to deploy and verify in a bit.
> So thanks Matt.
>
> Regards,
>
> From: Mau, I-Min
> Sent: Monday, July 15, 2024 2:54 PM
> To: 'Matt Pavlovich' mailto:mattr...@gmail.com>>;
> users@activemq.apache.org
> Cc: Bhattacharjee, Tapas  tapas.bhattachar...@fisglobal.com>>; Mau, I-Min  >
> Subject: RE: Test message api looks to be broken in ActiveMQ 5.18.4
>
> Ok but what do you think about Tapas finding that this worked again in a
> higher version?  So 5.16.7 and 6.1.2 did not have this issue, but 5.18.4
> did.
>
> Thanks,
>
> From: Matt Pavlovich mailto:mattr...@gmail.com>>
> Sent: Monday, July 15, 2024 2:50 PM
> To: users@activemq.apache.org
> Cc: Bhattacharjee, Tapas  tapas.bhattachar...@fisglobal.com>>; Mau, I-Min  >
> Subject: Re: Test message api looks to be broken in ActiveMQ 5.18.4
>
> Hi I-Min-
>
> The default for the messages API is to set the destination as a topic. If
> you want to read from a queue, add the &type=queue parameter to your query
> string.
>
>
>  curl --user admin:admin "
> http://localhost:8161/api/message/TEST?readTimeout=1&type=queue";
>
> ref: https://activemq.apache.org/components/classic/documentation/rest
>
> Thanks,
> Matt Pavlovich
>
> On Jul 15, 2024, at 1:12 PM, Mau, I-Min  .INVALID> wrote:
>
> Hi, we recently tried out ActiveMQ 5.18.4 (we were at 5.16.7) and one
> thing we encountered is that the test message api seems to be broken in
> this newer version.
> That is, when we tried curl --user admin:admin
> http://localhost:8161/api/message/TEST?readTimeout=1
>
> We got below.   Just wondering if others have encountered same.   Thanks,
>
> Error 500 AsyncContext timeout
> 
> HTTP ERROR 500 AsyncContext timeout
> 
> URI:/api/message/TEST
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> 
>
>
>
> 
> 
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you. Message
> Encrypted via TLS connection
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you. Message
> Encrypted via TLS connection
>

Re: CVE notices

[Christopher Shannon]

This mailing list is correct, CVEs are sent to the users list and also
should be sent to the dev list.

On Wed, Feb 8, 2023 at 11:12 AM Jonathan Card <
jonathan.c...@intersystems.com> wrote:

> Is there a mailing list to subscribe to potential CVE notices? It looks
> like I can’t/shouldn’t subscribe to security@…, because that’s for
> reporting vulnerabilities, and it’s not clear if there is a mailing list
> that would be exclusively for security updates, and where they would be
> announced.
>
> Thank you.
>
> Jonathan Card
> Software Engineer, Intersystems
> jc...@intersystems.com
>
>
>
>
>

Re: [DISCUSS] discontinue PDF, EPUB, & MOBI docs for Artemis

[Christopher Shannon]

I would think the HTML pages for Artemis/5.x are really the only versions
used but I am curious to see if any users here chime in and say otherwise.
HTML is pretty nice as you can just link to the latest docs and is standard
for most projects. I don't know of too many other Open source projects that
distribute docs other than through HTML on the web page or through Github
and markdown, etc.

On Mon, Feb 6, 2023 at 2:31 PM Clebert Suconic 
wrote:

> I wonder if anyone is using those formats?
>
>
>
> On Mon, Feb 6, 2023 at 12:58 PM Justin Bertram 
> wrote:
> >
> > Currently as part of the release process for Artemis we build docs in
> these
> > formats:
> >  - HTML
> >  - PDF
> >  - EPUB
> >  - MOBI
> >
> > I think we should only build docs in HTML and stop building them in PDF,
> > EPUB, & MOBI. Building the extra formats adds a surprising overhead to
> the
> > release process, and I don't think they are useful enough to warrant the
> > effort.
> >
> > Thoughts?
> >
> >
> > Justin
> >
> > P.S. This started out on the dev list, but I moved it to the users list
> to
> > get a feel for what users think about these docs.
>
>
>
> --
> Clebert Suconic
>

Re: JMS 2.0 support

[Christopher Shannon]

No, JMS 2 is a work in progress and is going to take a while. It will be
done in stages with client side updates first over a couple releases
probably. There won't be any server side support for a while as that is
much more difficult and more work so there won't be shared subscription
support, etc

On Tue, Mar 15, 2022 at 7:01 AM COURTAULT Francois
 wrote:

> Hello,
>
> According to this URL https://activemq.apache.org/jms2, JMS 2.0
> implementation will be finalized in Active MQ 5.18, right ?
>
> Best Regards.
>
>
>
>

Re: need details of parallel processing

[Christopher Shannon]

If you don't want want to use Artemis you can also just look into virtual
topics or composite queues. https://activemq.apache.org/virtual-destinations

On Fri, Jul 2, 2021 at 11:17 AM Justin Bertram  wrote:

> The ability to share a JMS subscription like you want was added in JMS 2.0.
> However, ActiveMQ 5.x doesn't support JMS 2.0. You'd need to use ActiveMQ
> Artemis instead.
>
>
> Justin
>
> On Fri, Jul 2, 2021 at 10:06 AM NawazAli Shaik <
> nawazali.sh...@sainsburys.co.uk> wrote:
>
> > Hi Robbie,
> >
> > Thanks for the response. We are trying to connect from multiple nodes to
> > the durable subscriber to balance the load but it seems active mqueue is
> > not allowing connection with same client ID.
> >
> > If we use different client id from second node it is providing duplicate
> > message to us. We need to build a architecture to pick messages from
> > multiple nodes and process multiple messages from each node at the same
> > time.
> >
> > Please let me know if you have any suggestion to match the above
> > requirement.
> >
> > Thanks & Regards,
> > Nawaz Ali Shaik
> > Integration Support | Digital & Technology Service Operations
> > Sainsbury's Supermarkets Ltd | Walsgrave,Coventry
> > nawazali.sh...@sainsburys.co.uk | Mobile: +44-7405734657
> >
> >  www.sainsburys.co.uk
> >
> >
> > -Original Message-
> > From: Robbie Gemmell 
> > Sent: 02 July 2021 16:01
> > To: users@activemq.apache.org
> > Subject: Re: need details of parallel processing
> >
> > 
> >
> > CAUTION: This message was sent to you from outside of the organisation.
> Do
> > not click links or open attachments unless you are expecting the email
> and
> > know the content is safe.
> >
> > 
> >
> > It would seem you aren't failing to subscribe, but rather failing to
> > create a Connection upon which attempt could even be made to subscribe.
> The
> > exception looks to give the reason fairly clearly, it seems you are
> trying
> > to create a connection using a ClientID that is already in use for
> another
> > connection. You can only create a single Connection with a given
> ClientID.
> >
> > Either define additional connection factories with different ClientID
> > values configured and use them to create 1 connection each, or stop
> > configuring an explicit ClientID for the factory and set it on each
> > connection immediately after creation, or dont do either and accept the
> > client-generated value (not an option if you want to use durable
> > subscriptions, which require a ClientID be set).
> >
> >
> > On Fri, 2 Jul 2021 at 13:23, NawazAli Shaik <
> > nawazali.sh...@sainsburys.co.uk> wrote:
> > >
> > > Hi Tim,
> > >
> > > Yes you are correct we are failing to subscribe the messages from
> topic.
> > Below is the error which we are getting:
> > >
> > > com.wm.app.b2b.server.jms.JMSSubsystemException: [ISS.0134.9064] Error
> > > creating connection: javax.jms.InvalidClientIDException: Broker:
> > > app-intg-platform-sit-retail-corp-broker-3 - Client: testingcluster
> > > already connected from tcp://
> > >
> > >
> > > Thanks & Regards,
> > > Nawaz Ali Shaik
> > > Integration Support | Digital & Technology Service Operations
> > > Sainsbury's Supermarkets Ltd | Walsgrave,Coventry
> > > nawazali.sh...@sainsburys.co.uk | Mobile: +44-7405734657
> > >
> > >  www.sainsburys.co.uk
> > >
> > >
> > > -Original Message-
> > > From: Tim Bain 
> > > Sent: 02 July 2021 13:19
> > > To: ActiveMQ Users 
> > > Cc: michael.andre.pearce 
> > > Subject: Re: need details of parallel processing
> > >
> > > 
> > >
> > > CAUTION: This message was sent to you from outside of the organisation.
> > Do not click links or open attachments unless you are expecting the email
> > and know the content is safe.
> > >
> > > 
> > >
> > > Nawaz,
> > >
> > > Are your threads failing to subscribe to the destination, or failing to
> > receive messages as expected after subscribing? You said that enabling
> the
> > trigger in the client is failing, so am I right to understand that this
> is
> > a failure to subscribe to the topic, not a failure to process messages as
> > expected once successfully subscribed?
> > >
> > > Are there any relevant error messages?
> > >
> > > Thanks,
> > > Tim
> > >
> > > On Fri, Jul 2, 2021, 5:54 AM NawazAli Shaik
> > > 
> > > wrote:
> > >
> > > > Hi Tim,
> > > >
> > > > The active mq version is recently updated to Apache ActiveMQ 5.16.2.
> > > > We are trying to subscribe the messages from active mqueue topic
> > parllely .
> > > >
> > > > In webmethods we have triggers to subscribe the messages from
> > > > topics/queues, we are not able to enable the triggers itself from
> > > > the client side.
> > > >
> > > > Thanks & Regards,
> > > > Nawaz Ali Shaik
> > > > Integration Support | Digital & Technology Service Operations
> > > > Sainsbury's Supermarkets Ltd | Walsgrave,Coventry
> > > > nawazali.sh...@

Re: ActiveMQ5.15.9/zookeeper 3.5.9 After the cluster is created successfully, an exception occurs when the ActiveMQ component is restarted

[Christopher Shannon]

LevelDB has been long deprecated and is being removed from 5.17.0

https://activemq.apache.org/leveldb-store

On Mon, Jun 28, 2021 at 2:40 AM ヤ艾枫o.-- <1169114...@qq.com.invalid> wrote:

> Hi 
> activemq.log is 
> " Too many cluster members are connected. Expected at most 3 members but
> there arr 4 connected".
> I use three hosts, each with an ActiveMQ and zookeeper deployed。

Re: Which activeMQ (not Artemis) version will be JMS 2.0 or 3.0 ?

[Christopher Shannon]

The veto is for proposing to make new JMS 2.0 methods delegate to 1.1
methods in the client as that behavior is just wrong and makes no sense.

On Wed, May 19, 2021 at 9:55 AM Justin Bertram  wrote:

> Pardon my ignorance, but why not help TomEE move to ActiveMQ Artemis which
> already supports JMS 2.0? If I recall correctly one of the reasons that the
> HornetQ donation was originally accepted was because it provided JMS 2.0
> support. This would save work on changes to the 5.x code-base and speed
> TomEE's transition to Artemis which should happen eventually anyway.
>
>
> Justin
>
> On Tue, May 18, 2021 at 11:05 PM Jean-Baptiste Onofre 
> wrote:
>
> > Hi,
> >
> > The first step is at least the client support, similar to what have been
> > done on OpenEJB:
> >
> >
> >
> https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2
> > <
> >
> https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2
> > >
> >
> > This allow TomEE to work with ActiveMQ using JMS 2.0.
> >
> > So, the proposal is to have a two steps work:
> >
> > 1. Support JMS 2.0 client side, it will help in tomee, karaf, etc
> > 2. Step by step implement server side support
> >
> > IMHO, 1 would be good step forward already and it works fine for a while
> > in tomee. It will already allow us to update the spec.
> >
> > Regards
> > JB
> >
> > > Le 18 mai 2021 à 21:09, Christopher Shannon <
> > christopher.l.shan...@gmail.com> a écrit :
> > >
> > > What exactly are you proposing? Full support would be a tremendous
> amount
> > > of work. I started a thread on this already a while back here:
> > >
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-JMS-2-0-support-in-5-x-going-forward-td4757779.html
> > >
> > > My issue here is the lack of clarity. I have no clue what you are
> > proposing
> > > but it needs to be defined so we don't mislead users by claiming there
> is
> > > JMS 2.0 support when there isn't. I listed out possible paths forward
> in
> > > that other thread.
> > >
> > > On Tue, May 18, 2021 at 12:04 PM Jean-Baptiste Onofre  >
> > > wrote:
> > >
> > >> It’s something that we already discussed and I moved forward on the
> PR.
> > >>
> > >> I propose to move forward on JMS 2.0 support.
> > >>
> > >> If the community agree, and tests are fine, I don’t see any issue to
> > >> support it in 5.17.0 as best effort.
> > >>
> > >> Anyway, I will propose the PR, and see when to include it.
> > >>
> > >> Regards
> > >> JB
> > >>
> > >>> Le 18 mai 2021 à 17:36, Christopher Shannon <
> > >> christopher.l.shan...@gmail.com> a écrit :
> > >>>
> > >>> Since when is JMS 2.0 supposed to be supported by 5.17.0?
> > >>>
> > >>> None of the features are implemented on the server side for the new
> API
> > >>> calls. This was brought up in a dev discussion that there won't be
> JMS
> > >> 2.0
> > >>> support on the server side in this release.
> > >>>
> > >>> On Tue, May 18, 2021 at 11:29 AM Jean-Baptiste Onofre <
> j...@nanthrax.net
> > >
> > >>> wrote:
> > >>>
> > >>>> He’s not PMC but committer, so he can help anyway ;)
> > >>>>
> > >>>> Regards
> > >>>> JB
> > >>>>
> > >>>>> Le 18 mai 2021 à 17:23, COURTAULT Francois <
> > >>>> francois.courta...@thalesgroup.com> a écrit :
> > >>>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> I don't think Romain is still the PMC for TomEE.
> > >>>>>
> > >>>>> Best Regards.
> > >>>>>
> > >>>>> -Original Message-
> > >>>>> From: Jean-Baptiste Onofre 
> > >>>>> Sent: mardi 18 mai 2021 17:19
> > >>>>> To: users@activemq.apache.org
> > >>>>> Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0
> or
> > >> 3.0
> > >>>> ?
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>&

Re: Which activeMQ (not Artemis) version will be JMS 2.0 or 3.0 ?

[Christopher Shannon]

What exactly are you proposing? Full support would be a tremendous amount
of work. I started a thread on this already a while back here:
http://activemq.2283324.n4.nabble.com/DISCUSS-JMS-2-0-support-in-5-x-going-forward-td4757779.html

My issue here is the lack of clarity. I have no clue what you are proposing
but it needs to be defined so we don't mislead users by claiming there is
JMS 2.0 support when there isn't. I listed out possible paths forward in
that other thread.

On Tue, May 18, 2021 at 12:04 PM Jean-Baptiste Onofre 
wrote:

> It’s something that we already discussed and I moved forward on the PR.
>
> I propose to move forward on JMS 2.0 support.
>
> If the community agree, and tests are fine, I don’t see any issue to
> support it in 5.17.0 as best effort.
>
> Anyway, I will propose the PR, and see when to include it.
>
> Regards
> JB
>
> > Le 18 mai 2021 à 17:36, Christopher Shannon <
> christopher.l.shan...@gmail.com> a écrit :
> >
> > Since when is JMS 2.0 supposed to be supported by 5.17.0?
> >
> > None of the features are implemented on the server side for the new API
> > calls. This was brought up in a dev discussion that there won't be JMS
> 2.0
> > support on the server side in this release.
> >
> > On Tue, May 18, 2021 at 11:29 AM Jean-Baptiste Onofre 
> > wrote:
> >
> >> He’s not PMC but committer, so he can help anyway ;)
> >>
> >> Regards
> >> JB
> >>
> >>> Le 18 mai 2021 à 17:23, COURTAULT Francois <
> >> francois.courta...@thalesgroup.com> a écrit :
> >>>
> >>> Hello,
> >>>
> >>> I don't think Romain is still the PMC for TomEE.
> >>>
> >>> Best Regards.
> >>>
> >>> -Original Message-
> >>> From: Jean-Baptiste Onofre 
> >>> Sent: mardi 18 mai 2021 17:19
> >>> To: users@activemq.apache.org
> >>> Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0 or
> 3.0
> >> ?
> >>>
> >>> Hi,
> >>>
> >>> I’m sure I can ask help from Romain about TomEE releases ;)
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>> Le 18 mai 2021 à 17:09, COURTAULT Francois <
> >> francois.courta...@thalesgroup.com> a écrit :
> >>>>
> >>>> Hello Jean-Baptiste,
> >>>>
> >>>> We are using ActiveMQ in TomEE context.
> >>>> So I am just curious about when this version could be included in
> TomEE
> >> releases. I will push for that.
> >>>>
> >>>> Best Regards.
> >>>>
> >>>> -Original Message-
> >>>> From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
> >>>> Sent: mardi 18 mai 2021 17:05
> >>>> To: users@activemq.apache.org <mailto:users@activemq.apache.org>
> >>>> Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0 or
> >> 3.0 ?
> >>>>
> >>>> Hi,
> >>>>
> >>>> The purpose of the RC is to cut an early release (kind of "cut
> >> SNAPSHOT") to allow users to test it before the first "official"
> release.
> >>>>
> >>>> What I can propose to you is:
> >>>>
> >>>> 1. I need couple of weeks to open the PRs and merge it (I’m on JDK11
> >> now, identifying/fixing/disabling some tests) 2. When done, I will
> inform
> >> you on the mailing list allowing you to test using the SNAPSHOTs
> >> (5.17.0-SNAPSHOT) 3. If I don’t see any blocker on SNAPSHOT, then I will
> >> move forward on 5.17.0 release
> >>>>
> >>>> Does it sound good to you ?
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>>> Le 18 mai 2021 à 16:59, Simon Billingsley
> >>  a écrit :
> >>>>>
> >>>>> Thanks for the details information.
> >>>>> I am interested in the Log4J 2 upgrade.
> >>>>> How long does the release take after the RC process normally?
> >>>>>
> >>>>> Best regards,
> >>>>> Simon.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 18 May 2021, at 15:53, Jean-Baptiste Onofre  >> <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net  j...@nanthrax.net
> >>>> <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net> j...@nanthrax.net
> >> <mailto:j...@nanthrax.net>>>> wrote:
> >>>>>
> >>>>> Hi François,
> >>>>>
> >>>>> ActiveMQ 5.17.0 will support JMS 2.0.
> >>>>>
> >>>>> Basically, what I’m planning for ActiveMQ 5.17.0:
> >>>>> - JDK11 build
> >>>>> - Spring 5
> >>>>> - Log4j2
> >>>>> - JMS 2.0
> >>>>>
> >>>>> About date target, I’m working on JDK11 build now and the other PRs
> >> will follow. I would like to submit a first 5.17 RC end of June.
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> Le 18 mai 2021 à 16:48, COURTAULT Francois <
> >> francois.courta...@thalesgroup.com  >> francois.courta...@thalesgroup.com>  >> francois.courta...@thalesgroup.com  >> francois.courta...@thalesgroup.com>> >> francois.courta...@thalesgroup.com  >> francois.courta...@thalesgroup.com>  >> francois.courta...@thalesgroup.com  >> francois.courta...@thalesgroup.com>>>> a écrit :
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> The question to be answered is in the Subject.
> >>>>>
> >>>>> Best Regards.
> >>>
> >>
> >>
>
>

Re: Which activeMQ (not Artemis) version will be JMS 2.0 or 3.0 ?

[Christopher Shannon]

Since when is JMS 2.0 supposed to be supported by 5.17.0?

None of the features are implemented on the server side for the new API
calls. This was brought up in a dev discussion that there won't be JMS 2.0
support on the server side in this release.

On Tue, May 18, 2021 at 11:29 AM Jean-Baptiste Onofre 
wrote:

> He’s not PMC but committer, so he can help anyway ;)
>
> Regards
> JB
>
> > Le 18 mai 2021 à 17:23, COURTAULT Francois <
> francois.courta...@thalesgroup.com> a écrit :
> >
> > Hello,
> >
> > I don't think Romain is still the PMC for TomEE.
> >
> > Best Regards.
> >
> > -Original Message-
> > From: Jean-Baptiste Onofre 
> > Sent: mardi 18 mai 2021 17:19
> > To: users@activemq.apache.org
> > Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0 or 3.0
> ?
> >
> > Hi,
> >
> > I’m sure I can ask help from Romain about TomEE releases ;)
> >
> > Regards
> > JB
> >
> >> Le 18 mai 2021 à 17:09, COURTAULT Francois <
> francois.courta...@thalesgroup.com> a écrit :
> >>
> >> Hello Jean-Baptiste,
> >>
> >> We are using ActiveMQ in TomEE context.
> >> So I am just curious about when this version could be included in TomEE
> releases. I will push for that.
> >>
> >> Best Regards.
> >>
> >> -Original Message-
> >> From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
> >> Sent: mardi 18 mai 2021 17:05
> >> To: users@activemq.apache.org 
> >> Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0 or
> 3.0 ?
> >>
> >> Hi,
> >>
> >> The purpose of the RC is to cut an early release (kind of "cut
> SNAPSHOT") to allow users to test it before the first "official" release.
> >>
> >> What I can propose to you is:
> >>
> >> 1. I need couple of weeks to open the PRs and merge it (I’m on JDK11
> now, identifying/fixing/disabling some tests) 2. When done, I will inform
> you on the mailing list allowing you to test using the SNAPSHOTs
> (5.17.0-SNAPSHOT) 3. If I don’t see any blocker on SNAPSHOT, then I will
> move forward on 5.17.0 release
> >>
> >> Does it sound good to you ?
> >>
> >> Regards
> >> JB
> >>
> >>> Le 18 mai 2021 à 16:59, Simon Billingsley
>  a écrit :
> >>>
> >>> Thanks for the details information.
> >>> I am interested in the Log4J 2 upgrade.
> >>> How long does the release take after the RC process normally?
> >>>
> >>> Best regards,
> >>> Simon.
> >>>
> >>>
> >>>
> >>>
> >>> On 18 May 2021, at 15:53, Jean-Baptiste Onofre    >> >>  >>>
> >>> Hi François,
> >>>
> >>> ActiveMQ 5.17.0 will support JMS 2.0.
> >>>
> >>> Basically, what I’m planning for ActiveMQ 5.17.0:
> >>> - JDK11 build
> >>> - Spring 5
> >>> - Log4j2
> >>> - JMS 2.0
> >>>
> >>> About date target, I’m working on JDK11 build now and the other PRs
> will follow. I would like to submit a first 5.17 RC end of June.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> Le 18 mai 2021 à 16:48, COURTAULT Francois <
> francois.courta...@thalesgroup.com  francois.courta...@thalesgroup.com>  francois.courta...@thalesgroup.com  francois.courta...@thalesgroup.com>> francois.courta...@thalesgroup.com  francois.courta...@thalesgroup.com>  francois.courta...@thalesgroup.com  francois.courta...@thalesgroup.com a écrit :
> >>>
> >>> Hello,
> >>>
> >>> The question to be answered is in the Subject.
> >>>
> >>> Best Regards.
> >
>
>

Re: Activemq 5.15 startup error

[Christopher Shannon]

In terms of exporting I am not sure.  I personally have never looked at
LevelDB. In terms of the error itself it seems like some of the files got
corrupt so not sure if it's possible to recover. If you want to export the
data you would probably need to write your own export tool to parse the
LevelDB structure. Or if you manage to get the broker running again and
want to migrate you could write a client to move data to a new broker.

Tim is right on the reasoning for deprecation and upcoming removal.
LevelDB has been deprecated for 4 years now and as far as I'm aware no one
still around really knows anything about it and no one is going to answer
any questions on it. There was no community support or knowledge (it was
written in Scala which was one major issue) and the people who wrote it
have long stopped contributing to the project so it didn't make sense to
continue supporting it if no one was around to do so.


On Fri, Aug 7, 2020 at 11:20 AM Tim Bain  wrote:

> LevelDB support was removed in large part due to the absence of developers
> willing to maintain the code and volunteers willing to provide support for
> it on this mailing list. In the 5+ years I've been involved in this mailing
> list, I don't recall ever seeing a LevelDB question answered (and I've
> definitely seen them asked).
>
> When Chris says that LevelDB is unsupported, he means that it's
> UNSUPPORTED. If you're not prepared to provide your own support for
> whatever problems you encounter (leveraging the open-source codebase), you
> shouldn't be using it, and should switch to KahaDB (or Artemis, as you
> said, but KahaDB gives you a short-term solution for minimal effort). I'm
> sorry to be the bearer of bad news, especially since you might not have
> been aware of LevelDB's status until now, but you're on your own for
> LevelDB issues.
>
> Good luck.
>
> Tim
>
> On Fri, Aug 7, 2020, 8:24 AM Ramesh Venkitaswaran  >
> wrote:
>
> > Any ideas? Or, is there a way to export these messages so that I can
> > recreate the broker data directory and import them?
> >
> > On Fri, Aug 7, 2020 at 6:39 AM Ramesh Venkitaswaran <
> > venkitaswa...@gmail.com>
> > wrote:
> >
> > > Understood, that LevelDB is deprecated, and we are trying to get this
> > team
> > > to move to Artemis. However we still need this broker to run while the
> > > migration is going on.
> > >
> > > On Fri, Aug 7, 2020 at 5:48 AM Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > >
> > >> LevelDB support has been deprecated for many years now and is going to
> > be
> > >> removed in the next version of ActiveMQ (5.17.0) so I would suggest
> > trying
> > >> to migrate over to KahaDB.
> > >>
> > >> On Fri, Aug 7, 2020 at 4:08 AM Ramesh Venkitaswaran <
> > >> venkitaswa...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hello
> > >> > We have a 3 node activemq 5.15 cluster with zookeeper using Level
> DB.
> > >> It's
> > >> > a very old system. However last night we started to get these errors
> > and
> > >> > the broker did not come up. Any ideas on how to fix this would be
> > >> > appreciated. I can provide further log messages as needed, if
> > sufficient
> > >> > direction is provided. Thank you!
> > >> >
> > >> > Here are the logs
> > >> > 2020-08-07 02:44:54,502 | INFO  | Apache ActiveMQ 5.15.0 (BROKER01P,
> > >> >
> > >> >
> > >>
> >
> ID:mkt-lpf-prod-usc1a-activemq-broker01p-1.c.x-mkt-prd.internal-35573-1596786294369-0:1)
> > >> > is starting |
> > >> >  org.apache.activemq.broker.BrokerService | main
> > >> > 2020-08-07 02:44:54,732 | INFO  | Listening for connections at:
> > >> >
> > >> >
> > >>
> >
> tcp://mkt-lpf-prod-usc1a-activemq-broker01p-1.c.x-mkt-prd.internal:61616?maximumConnections=1000&wireFormat
> > >> > .maxFrameSize=104857600 |
> > >> > org.apache.activemq.transport.TransportServerThreadSupport | main
> > >> > 2020-08-07 02:44:54,733 | INFO  | Connector openwire started |
> > >> > org.apache.activemq.broker.TransportConnector | main
> > >> > 2020-08-07 02:44:54,823 | INFO  | Listening for connections at:
> > >> >
> > >> >
> > >>
> >
> ssl://mkt-lpf-prod-usc1a-activem

Re: Activemq 5.15 startup error

[Christopher Shannon]

LevelDB support has been deprecated for many years now and is going to be
removed in the next version of ActiveMQ (5.17.0) so I would suggest trying
to migrate over to KahaDB.

On Fri, Aug 7, 2020 at 4:08 AM Ramesh Venkitaswaran 
wrote:

> Hello
> We have a 3 node activemq 5.15 cluster with zookeeper using Level DB. It's
> a very old system. However last night we started to get these errors and
> the broker did not come up. Any ideas on how to fix this would be
> appreciated. I can provide further log messages as needed, if sufficient
> direction is provided. Thank you!
>
> Here are the logs
> 2020-08-07 02:44:54,502 | INFO  | Apache ActiveMQ 5.15.0 (BROKER01P,
>
> ID:mkt-lpf-prod-usc1a-activemq-broker01p-1.c.x-mkt-prd.internal-35573-1596786294369-0:1)
> is starting |
>  org.apache.activemq.broker.BrokerService | main
> 2020-08-07 02:44:54,732 | INFO  | Listening for connections at:
>
> tcp://mkt-lpf-prod-usc1a-activemq-broker01p-1.c.x-mkt-prd.internal:61616?maximumConnections=1000&wireFormat
> .maxFrameSize=104857600 |
> org.apache.activemq.transport.TransportServerThreadSupport | main
> 2020-08-07 02:44:54,733 | INFO  | Connector openwire started |
> org.apache.activemq.broker.TransportConnector | main
> 2020-08-07 02:44:54,823 | INFO  | Listening for connections at:
>
> ssl://mkt-lpf-prod-usc1a-activemq-broker01p-1.c.x-mkt-prd.internal:61617?maximumConnections=1000&wireFormat
> at
>
> org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:184)[activemq-client-5.15.0.jar:5.15.0]
> at
>
> org.apache.activemq.console.command.store.amq.CommandLineSupport.setOptions(CommandLineSupport.java:81)[activemq-console-5.15.0.jar:5.15.0]
> at
>
> org.apache.activemq.console.command.StoreExportCommand.execute(StoreExportCommand.java:51)[activemq-console-5.15.0.jar:5.15.0]
> at
>
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:154)[activemq-console-5.15.0.jar:5.15.0]
> at
>
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:63)[activemq-console-5.15.0.jar:5.15.0]
> at
>
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)[activemq-console-5.15.0.jar:5.15.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)[:1.8.0_232]
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_232]
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_232]
> at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_232]
> at
>
> org.apache.activemq.console.Main.runTaskClass(Main.java:262)[activemq.jar:5.15.0]
> at
> org.apache.activemq.console.Main.main(Main.java:115)[activemq.jar:5.15.0]
> 2020-08-07 02:44:46,669 | INFO  | Refreshing
> org.apache.activemq.xbean.XBeanBrokerFactory$1@3159c4b8: startup date [Fri
> Aug 07 02:44:46 CDT 2020]; root of context hierarchy |
> org.apache.activemq.xbean.XBeanBrokerFactory$1 | main
> 2020-08-07 02:44:49,462 | INFO  | Using Persistence Adapter: Replicated
> LevelDB[/var/lib/activemq/data/leveldb, 10.184.11.8:2181,10.184.11.9:2181,
> 10.184.11.7:2181//activemq/ap
> ps/mkt/lpf/prod-usc1a/BROKER01P] | org.apache.activemq.broker.BrokerService
> | main
> 2020-08-07 02:44:51,492 | INFO  | Client
> environment:zookeeper.version=3.4.6-1569965, built on 02/20/2014 09:09 GMT
> | org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,494 | INFO  | Client
> environment:host.name
> =mkt-lpf-prod-usc1a-activemq-broker01p-1.c.x-mkt-prd.internal
> | org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,496 | INFO  | Client environment:java.version=1.8.0_232
> | org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,499 | INFO  | Client environment:java.vendor=Oracle
> Corporation | org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,500 | INFO  | Client
>
> environment:java.home=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232.b09-0.el7_7.x86_64/jre
> | org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,504 | INFO  | Client
>
> environment:java.class.path=/opt/activemq/apache-activemq-5.15.0//bin/activemq.jar:/srv/prop/cavisson/netdiagnostics/lib/ndmain.jar
> |
> org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,505 | INFO  | Client
>
> environment:java.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> | org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,506 | INFO  | Client
> environment:java.io.tmpdir=/opt/activemq/apache-activemq-5.15.0//tmp |
> org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,507 | INFO  | Client environment:java.compiler= |
> org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,507 | INFO  | Client environment:os.name=Linux |
> org.apache.zookeeper.ZooKeeper | main
> 2020-08-07 02:44:51,508 | INFO  | Client environment:os.arch=amd64 |
> org.apache.zookeeper.ZooKeeper | main
> 2020-0

Re: Federation using Bi-Directional/Duplex between Artemis brokers

[Christopher Shannon]

I am coming from a 5.x background as well with heavy usage of duplex
network connectors for the same reason as you (such as firewall
configurations) so I definitely understand it being a deal breaker.  I'm
not sure when I will get time to work on it more but I'm hoping to soon as
it will make Federation much more useful in a lot of cases.

On Thu, Feb 27, 2020 at 11:17 AM sateesh kumar kapu 
wrote:

> Thanks Chris,
> Currently we are using ActiveMQ5.x and planning to switch to Artemis  to
> leverage its benefits but it appears Duplex feature is a deal breaker for
> now to make this switch.
>
> Even it is required two connections to federate, if they initiated by one
> broker then it would have solved our problem.
>
> Anyways we stay tune to get updates on this.
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Federation using Bi-Directional/Duplex between Artemis brokers

[Christopher Shannon]

There is currently no duplex option but it is on the list of things in the
future. Originally there was only upstream connections but I recently added
downstream configuration but it still requires creating a connection in
each direction.

The main issue is there is no current support for duplex connections in
Artemis to make it easy to implement (ServerLocator, etc create a new
connection and can't use existing).  So it will take a little work to get
there but ultimately having real duplex connection is nice so the remote
broker doesn't have to know how to create a new connection.

On Wed, Feb 26, 2020 at 5:00 PM satees kumar kapu 
wrote:

> We are trying to implement a hub and spoke topology using the Federation
> feature by configuring both upstream and downstream connections.  In our
> case, we wanted to configure everything that is needed for the federation
> on
> the broker which is acting as spoke.  This is mainly done this way as our
> main requirement was hub should not be aware of any spoke as spokes can be
> behind the firewall and are added or removed dynamically.
>
>  In order to achieve this, In the downstream configuration, we set a
> share-connection flag that is supposed to use the same upstream connection
> to use for downstream communication. However, it seems we also required to
> configure the upstream-connector-ref which will be used by the hub to
> create
> a new connection to communicate. This is making Hub to aware of spoke which
> is violating our intend. Ideally, we want to avoid spoke's hostname the
> connector that is given in the upstream-connector-ref configuration.
>
> Is there any way to make the same connection Bi-directional/Duplex?
>
> In addition to that as spokes can be behind the firewall where only
> HTTP
> connections are allowed, can federation done via HTTP?
>
>
> Broker.xml on Hub
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:xi="http://www.w3.org/2001/XInclude";
>xsi:schemaLocation="urn:activemq
> /schema/artemis-configuration.xsd">
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="urn:activemq:core ">
>   0.0.0.0
>…
>
> name="netty-connector">tcp://0.0.0.0:61618
>   
>
> name="netty-acceptor">tcp://0.0.0.0:61618
>
>
>
>
>name="exampleSubscription"/>
>
>
>   
>   
> 
>
>
> Broker.xml on Spoke.
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:xi="http://www.w3.org/2001/XInclude";
>xsi:schemaLocation="urn:activemq
> /schema/artemis-configuration.xsd">
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="urn:activemq:core ">
>   0.0.0.0
>…
>
> name="netty-connector">tcp://spokeHostName:61618
>name="us-central-1-connector">tcp://hubHostName:61618
>   
>  
> name="netty-acceptor">tcp://0.0.0.0:61618
>
>
>
>
>
> 1000
>
> true
>   
>
> us-central-1-connector
>   
>   
>
>
>
> 1000
>
> true
>   
>
> us-central-1-connector
>   
>   
>
> netty-connector
>
>
>ref="address-federation" />
>
>
>address-match="exampleTopic" />
>
>
>   
>
>
>
>name="exampleSubscription"/>
>
>
>   
>   
> 
>
> Thanks in advance.
>
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: ActiveMQ v5 plugin migration to Artemis

[Christopher Shannon]

Take a look at the plugin API for Artemis:
https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html

Specifically you can implement your own ActiveMQServerPlugin (which extends
many other plugin interfaces) and has a ton of hooks into the broker to do
what you need.  ActiveMQServerConsumerPlugin probably has the methods you
need.

https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/plugin/ActiveMQServerConsumerPlugin.java

On Thu, Feb 13, 2020 at 9:59 AM David Martin  wrote:

> Hi everyone,
>
> Decided to switch to Artemis which is not going to be difficult in the main
> but not sure of my best option to migrate a broker plugin which overrides
> *addConsumer()* to set a new destination and a message selector using
> broker-side business logic based on the user credentials. It looks like I
> might be able to do this as a plugin or as an interceptor and not sure what
> to override on either of these interfaces?
>
> Any help/pointers appreciated.
>
> Thanks,
>
> Dave
>

Re: Issue with ActiveMQ/JMS 2.0

[Christopher Shannon]

ActiveMQ 5.x does not support any part of JMS 2.0.  There has been talk of
it but it would require a lot of work to get there and isn't close.

For JMS 2.0 support I would recommend looking at Artemis which is the next
generation broker and already supports it.

On Mon, Feb 10, 2020 at 3:11 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:

> Hello,
>
> I know that ActiveMQ doesn't cover all JMS 2.0 specification.
> Could you tell me, please, how far ActiveMQ is close to JMS 2.0 ?
>
> I am asking this question because I am using TomEE 8.0.0 or 8.0.1 with
> ActiveMQ 5.15.10 embedded.
> In an stateless EJB, I inject JMSContext (working) and in a method, I have
> the following code:
>  jmsContext.createProducer().send(messageQueue,
> jmsContext.createTextMessage("Test"));
>
> The issue I have is that each time I send a text message a DynamicProducer
> is created which could be the root cause of a memory leak.
>
> But looking at the docs:
> https://javaee.github.io/javaee-spec/javadocs/javax/jms/JMSContext.html
> (new way JMS 2.0)
> https://javaee.github.io/javaee-spec/javadocs/javax/jms/Session.html (old
> way JMS 1.1)
>
> I find something not coherent. Indeed:
>
> · Using Session (JMS 1.1), we are able to create a Producer
> targeting a destination : createProducer<
> https://javaee.github.io/javaee-spec/javadocs/javax/jms/Session.html#createProducer-javax.jms.Destination-
> >(Destination<
> https://javaee.github.io/javaee-spec/javadocs/javax/jms/Destination.html>
> destination). So no, dynamic producer is created.
>
> · Using JMSContext (JMS 2.0) , we are able to create a Producer
> but with no destination (createProducer<
> https://javaee.github.io/javaee-spec/javadocs/javax/jms/JMSContext.html#createProducer-->())
> => dynamic production creation.
> Why don't we have on JMSContext the same method createProducer<
> https://javaee.github.io/javaee-spec/javadocs/javax/jms/Session.html#createProducer-javax.jms.Destination-
> >(Destination<
> https://javaee.github.io/javaee-spec/javadocs/javax/jms/Destination.html>
> destination) ?
>
> But I also don't get that, according to the JMS 2.0 specification, the
> JMSContext injected has a Transaction scope => this mean that after the end
> of the method, the JMSContext should be closed so that the dynamic producer.
> Do you agree with the behavior described above. If so, Is it an ActiveMQ
> issue or a TomEE issue ?
>
> Looking at
> https://www.oracle.com/technical-resources/articles/java/jms20.html
> A sample is provided in § Injecting a JMSContext into a Java EE
> Application:
>   context.send(dataQueue, body);   => but the JMSContext java
> doc I didn't find any send method. So I guess it's a mistake, right ?
>
> Best Regards.
>
>

Re: OutOfMemoryError in activeMQ and applcation gets stopped

[Christopher Shannon]

Have you configured limits on memory usage in the broker settings? You need
to look at a heap dump and see exactly where the memory is being used (if
it's messages on a destination, in prefetch etc).

Some general info about OOM and how to prevent it:
https://activemq.apache.org/javalangoutofmemory.html

On Mon, Nov 25, 2019 at 10:38 AM sainath 
wrote:

> We have LiveTransfer application that use ActiveMQ to transfer data from
> Production database to operational Database
>
> Application is getting issue for every 50+ days i.e. OutOfMemoryError in
> activeMQ and LT gets stopped. After restarting the AMQ services, it will
> resume the transfer.
>
> 
> INFO  | jvm 1| 2019/09/06 00:56:34 | java.lang.OutOfMemoryError: Java
> heap space
> INFO  | jvm 1| 2019/09/06 00:56:34 | Dumping heap to
> D:\RockwellSoftware\heap_log\java_pid5216.hprof ...
> INFO  | jvm 1| 2019/09/06 00:56:58 | Heap dump file created [4259842078
> bytes in 23.626 secs]
> 
>
> Due to this issue we found data missing between Production database to
> operational Database.
>
> Currently activemq memory set to 4 GB. We continuously monitor AMQ memory
> using JConsole and found memory is consuming more than i.e. 2.8 GB
>
> This system is only dedicated for AMQ and Live transfer
>
> AactiveMQ version-5.14.1
>
> JDK version : 1.8 Update 60
>
> Could you please help to provide the root cause and fix on the issue.
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: compositeTopic and lost messages - broker restart

[Christopher Shannon]

I put a lot of work into the network bridging in 5.x and it looks like I
didn't add documentation for some of it including the forceDurable flag and
also the ability to synchronize durable subscriptions on bridge reconnect
with a flag.  I did document the Virtual destinations demand feature which
seems relevant here. I will go back and update the network of brokers page
with the new flags/features.

For some tests that show the features see:

https://github.com/apache/activemq/blob/activemq-5.15.10/activemq-unit-tests/src/test/java/org/apache/activemq/network/DurableSyncNetworkBridgeTest.java
https://github.com/apache/activemq/blob/activemq-5.15.10/activemq-unit-tests/src/test/java/org/apache/activemq/network/ForceDurableNetworkBridgeTest.java
https://github.com/apache/activemq/blob/activemq-5.15.10/activemq-unit-tests/src/test/java/org/apache/activemq/network/VirtualConsumerDemandTest.java

On Mon, Nov 11, 2019 at 1:17 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> You can force durable subscriptions by setting a flag.  Looks like this
> may not have made it into the documentation.
>
>  
>
>   useVirtualDestSubs="true"
> duplex="true"
>
> uri="static:(tcp://
> 127.0.0.1:61616)" userName="omitted" password="omitted" >
>
>
>
>
>
>
>
>
> 
>
> 
>
> On Mon, Nov 11, 2019 at 8:33 AM Tim Bain  wrote:
>
>> OK, thanks for sharing what you did.
>>
>> Tim
>>
>> On Mon, Nov 11, 2019, 2:05 AM Cannock, Richard <
>> richard.cann...@edfenergy.com> wrote:
>>
>> > HI Tim
>> >
>> > Thanks for the advice. In the end, I got the network connector
>> 'promoted'
>> > to a durable topic subscriber by adding a temporary Topic to the forward
>> > declaration like this:
>> >
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> >
>> > Before attaching a durable scubscriber to this topic. Once restarted the
>> > broker made the network connector durable.
>> >
>> > I then removed theand
>> > restarted the broker again. The network connector remained durable and
>> > messages remained to be sent to the queue even when the broker was
>> offline.
>> >
>> > This is clearly a workaround, so a bit nervous of it's reliability, so
>> > clearly an enhancement request to make this a duranble subscription
>> might
>> > be best.
>> >
>> > Thanks
>> >
>> > Richard
>> >
>> > -Original Message-
>> > From: Tim Bain 
>> > Sent: 08 November 2019 07:00
>> > To: ActiveMQ Users 
>> > Subject: Re: compositeTopic and lost messages - broker restart
>> >
>> > Durable topic subscriptions are dangerous things, because if the
>> consumer
>> > disappears without removing the subscription, the broker will keep the
>> > messages for it forever, eventually running the broker out of memory. A
>> > durable topic subscription between brokers (for implementing a composite
>> > destination) is doubly so, since the subscription isn't held by a
>> > traditional consumer who might give assurances of cleaning things up
>> before
>> > tearing itself down. So it's no surprise to me that a non-durable
>> > subscription is the default behavior, since that's the safer behavior.
>> >
>> > However, I think maybe your real question isn't why this isn't the
>> > default, but why there isn't an option to specify the use of a durable
>> > subscription if you so choose. Your use case seems like a valid one for
>> > that particular feature, so if you submit an enhancement request,
>> perhaps
>> > it could be added in a future version.
>> >
>> > In the meantime, could you make the composite topic in your broker use a
>> > different name than the remote topic (call it *myCompositeTopic*), and
>> then
>> > have an embedded Camel route that uses a durable subscription to consume
>> > from *myCompositeTopic* and publishes the message to *sourceTopic*? Then
>> > the network of brokers can ensure that there's a durable subscription on
>> > the remote broker, an

Re: compositeTopic and lost messages - broker restart

[Christopher Shannon]

You can force durable subscriptions by setting a flag.  Looks like this may
not have made it into the documentation.

 

 

   

   

   






On Mon, Nov 11, 2019 at 8:33 AM Tim Bain  wrote:

> OK, thanks for sharing what you did.
>
> Tim
>
> On Mon, Nov 11, 2019, 2:05 AM Cannock, Richard <
> richard.cann...@edfenergy.com> wrote:
>
> > HI Tim
> >
> > Thanks for the advice. In the end, I got the network connector 'promoted'
> > to a durable topic subscriber by adding a temporary Topic to the forward
> > declaration like this:
> >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > Before attaching a durable scubscriber to this topic. Once restarted the
> > broker made the network connector durable.
> >
> > I then removed theand
> > restarted the broker again. The network connector remained durable and
> > messages remained to be sent to the queue even when the broker was
> offline.
> >
> > This is clearly a workaround, so a bit nervous of it's reliability, so
> > clearly an enhancement request to make this a duranble subscription might
> > be best.
> >
> > Thanks
> >
> > Richard
> >
> > -Original Message-
> > From: Tim Bain 
> > Sent: 08 November 2019 07:00
> > To: ActiveMQ Users 
> > Subject: Re: compositeTopic and lost messages - broker restart
> >
> > Durable topic subscriptions are dangerous things, because if the consumer
> > disappears without removing the subscription, the broker will keep the
> > messages for it forever, eventually running the broker out of memory. A
> > durable topic subscription between brokers (for implementing a composite
> > destination) is doubly so, since the subscription isn't held by a
> > traditional consumer who might give assurances of cleaning things up
> before
> > tearing itself down. So it's no surprise to me that a non-durable
> > subscription is the default behavior, since that's the safer behavior.
> >
> > However, I think maybe your real question isn't why this isn't the
> > default, but why there isn't an option to specify the use of a durable
> > subscription if you so choose. Your use case seems like a valid one for
> > that particular feature, so if you submit an enhancement request, perhaps
> > it could be added in a future version.
> >
> > In the meantime, could you make the composite topic in your broker use a
> > different name than the remote topic (call it *myCompositeTopic*), and
> then
> > have an embedded Camel route that uses a durable subscription to consume
> > from *myCompositeTopic* and publishes the message to *sourceTopic*? Then
> > the network of brokers can ensure that there's a durable subscription on
> > the remote broker, and you'll still get the composite destination on your
> > local broker. This has the additional benefit of not having *sourceTopic*
> > be a composite destination on your local broker while being a
> non-composite
> > destination on the remote broker, which is a pretty wonky configuration
> > anyway.
> >
> > Tim
> >
> > On Fri, Oct 18, 2019 at 2:05 AM Cannock, Richard <
> > richard.cann...@edfenergy.com> wrote:
> >
> > > HI,
> > >
> > > Further investigations indicate that the resulting network connector
> > > establishes only a non durable topic subscription to the sourceTopic
> > > via the CompositeTopic, which is why we do not get any messages queued
> > > up at source and subsequently delivered received post the networked
> > > broker restart.
> > >
> > > However, this does not explain why this is only a non durable topic
> > > subscription, as I believe this should be a durable topic subscription
> > > by default.
> > >
> > > I have tried this with various ActiveMQ versions upto 5.15.9 and the
> > > behaviour is consistent.
> > >
> > > Any advice?
> > >
> > > Thanks
> > >
> > > Richard
> > >
> > > -Original Message-
> > > From: Cannock, Richard 
> > > Sent: 16 October 2019 19:36
> > > To: users@activemq.apache.org
> > > Subject: RE: compositeTopic and lost messages - broker restart
> > >
> > > Apologies, mail server issue meant I wasn't sure that the original
> > > message had gotten through. Obviously it had!
> > >
> > > These are the same issue so only looking for advice on one of them,
> > > thanks.
> > >
> > > ___
> > > From: Justin Bertram [jbert...@apache.org]
> > > Sent: 16 October 2019 17:09
> > > To: users@activemq.apache.org
> > > Subject: Re: compositeTopic and lost messages - broker restart
> > >
> > > Richard, didn't you just send this same email to the ActiveMQ user
> > > list (although with a slightly different subject)? Just want to
> > > clarify if they are the same or different issues.
> > >
> > >
> > > Justin
> > >
> > > On Wed, Oct 16, 2019 at 10:40 AM Cannock, Richard <
> > > richard.cann...@edfenergy.com> wrote:
> > >
> > > > Hi,
> > > >
> 

Re: Antwort: Re: mqtt adapter roadmap

[Christopher Shannon]

There is no way that MQTT 5 is going to make it into 5.16.0.  5.16.0 is
already way passed due in my opinion and adding support for a new protocol
version is a ton of work.  The only reason I haven't started a release for
5.16.0 is because of some issues with JDK 11 (specifically with OSGI/Karaf)
but otherwise there shouldn't be any blockers on it.

On Mon, Oct 7, 2019 at 3:27 AM Jean-Baptiste Onofré  wrote:

> Hi Herbert,
>
> I guess we don't have a Jira about this update yet, right ?
>
> If not, I will create one and I will take a look for 5.16.0 (depending
> of the impact/effort).
>
> Regards
> JB
>
> On 07/10/2019 08:51, herbert.helmstr...@systema.com wrote:
> > Hello Tim,
> >
> > I'm working  with ActiveMQ 5. Artemis was out of scope for me up to now.
> > If Artemis is supporting MQTT5, I would like to know this, too.
> >
> > Regards
> >
> > Herbert
> >
> >
> >
> >
> >
> > Von:"Tim Bain" 
> > An: "ActiveMQ Users" 
> > Datum:  04.10.2019 21:22
> > Betreff:Re: mqtt adapter roadmap
> >
> >
> >
> > Is your question about ActiveMQ 5.x, or about Artemis?
> >
> > Tim
> >
> > On Fri, Oct 4, 2019, 9:12 AM  wrote:
> >
> >> Hello,
> >>
> >> can somebody say, if it is planned to support MQTTv5 adapter in
> > ActiveMQ?
> >> I found a similar question in the archives with answers pointing to
> > jetty.
> >> But I do not see, what jetty has to do with that.
> >> Thank You!
> >>
> >> Herbert
> >>
> >>
> >
> >
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Authorization plugin - don't know what to do with client attempting to write to weird advisory topic

[Christopher Shannon]

These are advisory messages, I suggest you read
https://activemq.apache.org/advisory-message.html which will explain what
they are and how to configure/disable them.

On Tue, Sep 24, 2019 at 4:52 PM Jędrzej Dudkiewicz <
jedrzej.dudkiew...@gmail.com> wrote:

> I wrote yet another certificate-based authentication/authorization
> plugin. It reads CN from certificate provided by the client and
> depending on what is in there it allows or dissalows
> creation/deletion/writing to topics/queues. To test it I wrote a
> simple Java client that uses OpenWire. Connection is made
> successfully, CN is read and permissions are added are expected.
> Unfortunately after connection is created (addConnection in plugin is
> called), destination "topic://ActiveMQ.Advisory.Connection" is created
> by the client, or rather in its context (ok, unexpected, but it makes
> sense as I used advisory topics), method addConsumer() (from
> BrokerFilter) is called, and its destination is:
>
> DEST:
> topic://ActiveMQ.Advisory.TempQueue,topic://ActiveMQ.Advisory.TempTopic
> IS TOPIC: true
> PHYSNAME:
> topic://ActiveMQ.Advisory.TempQueue,topic://ActiveMQ.Advisory.TempTopic
> DEST AS STR: Topic
> QUALIFIED NAME:
> topic://ActiveMQ.Advisory.TempQueue,topic://ActiveMQ.Advisory.TempTopic
> DEST PATHS:
> topic://ActiveMQ|Advisory|TempQueue,topic://ActiveMQ|Advisory|TempTopic
> IS TEMP: false
>
> This means that it is a topic, its physical name is equal to qualified
> name, which makes no sense whatsoever, what more this name is made up
> from two topics names, it isn't temporary (not what name suggests) and
> to add insult to the injury its "getDestinationPaths()" method returns
> array with the following elements:
> "topic://ActiveMQ"
> "Advisory"
> "TempQueue,topic://ActiveMQ"
> "Advisory"
> "TempTopic"
>
> I wrote my plugin using
> "org.apache.activemq.security.AuthorizationBroker" as a base and aside
> from this and single problem with MQTT protocol it works fine.
>
> What is the reason for this topic's existence?
> Why is its name so weird?
> Should I expect more destinations with such names?
> Is it enough to check for exactly this name and I will be done? I did
> it and it works, but I can't be sure that it won't happen again with
> different weird topic name.
>
> Thanks in advance,
> --
> Jędrzej Dudkiewicz
>
> I really hate this damn machine, I wish that they would sell it.
> It never does just what I want, but only what I tell it.
>

Re: Artemis - Implement ACL programmatically

[Christopher Shannon]

You might need to write some custom code to do what you want and you could
try a custom Security plugin.
See the API and Java docs for the security setting plugin:
https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/SecuritySettingPlugin.java

If you need even more control you can create your own SecurityManager and
register it with the broker.  The interface to extend is:
https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager3.java

The validateUserAndRole() method is where you do your ACL checks

A default implementation that delegates to a JAAS module is including in
the broker already which you can use as an example or to extend:
https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java

On Mon, Aug 26, 2019 at 8:01 AM Modanese, Riccardo
 wrote:

> I already read this page and I wasn’t able to find any helpful information.
> In our use case each user has ACL depending on the username itself.
> Moreover a user can be added at runtime and the broker must be able to
> create and handle correctly the ACL also for the new created user.
>
> So, at the end, what I need is the capability of creating ACL
> programmatically and keep them in a session in order to be used every time
> a client publishes a message or subscribes an address.
> In ActiveMQ 5 this was possible ( [1] - [2] ) by creating a
> DefaultAuthorizationMap object, but I cannot find a similar object in
> Artemis
>
> [1]
> https://github.com/eclipse/kapua/blob/develop/broker-core/src/main/java/org/eclipse/kapua/broker/core/plugin/KapuaSecurityBrokerFilter.java#L683
> [2]
> https://github.com/eclipse/kapua/blob/develop/broker-core/src/main/java/org/eclipse/kapua/broker/core/plugin/KapuaSecurityBrokerFilter.java#L557
>
>
> Il giorno 26 ago 2019, alle ore 13:43, Christopher Shannon <
> christopher.l.shan...@gmail.com<mailto:christopher.l.shan...@gmail.com>>
> ha scritto:
>
> All of the info you should need to get started should be here:
>
> https://activemq.apache.org/components/artemis/documentation/latest/security.html
>
> On Mon, Aug 26, 2019 at 6:24 AM Modanese, Riccardo
>  wrote:
>
> Hello,
>In our ActiveMQ 5.x security plugin code we are enforcing ACL
> programmatically so I’m investigating how to migrate our current ACL from
> ActiveMQ 5.x to Artemis.
>
> I took a look into Artemis source code and I didn’t find any similar
> object to those present in ActiveMQ 5.x (E.g.
> org.apache.activemq.security.AuthorizationMap,
> org.apache.activemq.security.AuthorizationEntry, ...)
>
> Can you point me to the right direction?
>
>
>

Re: Artemis - Implement ACL programmatically

[Christopher Shannon]

All of the info you should need to get started should be here:
https://activemq.apache.org/components/artemis/documentation/latest/security.html

On Mon, Aug 26, 2019 at 6:24 AM Modanese, Riccardo
 wrote:

> Hello,
> In our ActiveMQ 5.x security plugin code we are enforcing ACL
> programmatically so I’m investigating how to migrate our current ACL from
> ActiveMQ 5.x to Artemis.
>
> I took a look into Artemis source code and I didn’t find any similar
> object to those present in ActiveMQ 5.x (E.g.
> org.apache.activemq.security.AuthorizationMap,
> org.apache.activemq.security.AuthorizationEntry, ...)
>
> Can you point me to the right direction?
>

Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus

[Christopher Shannon]

Dev list got dropped so adding back in (really this probably only belongs
the dev list anyways)

On Thu, Jul 11, 2019 at 12:08 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Many of those pull requests are years old.  Furthermore no one is saying
> there is no interest in a project.  But there is a huge difference from
> supporting 5.x in terms of bug fixes and small features than talking about
> doing something like adding new protocols or JMS 2.0 support.  For example
> the level of effort to add JMS 2.0 correctly is quite high and I highly
> doubt there's going to be anyone to do the work.  You need to update
> everything from the client libraries to the broker logic all the way to the
> data store (KahaDB) etc.
>
> Doing something like that is a massive undertaking and makes 0 sense to me
> at this point.  Why would we add JMS 2.0 support to 5.x when we already
> have Artemis that supports JMS 2.0 and as a project we had previously
> agreed to work towards Artemis as the next generation broker and as the
> follow on?  And yes we had established that fact already as a project and
> it's already on our website etc.  If someone has enough time to try and add
> JMS 2.0 to 5.x then why not use that time to help make Artemis a drop in
> replacement or make it easier to upgrade? Bruce brought that up and I do
> think that having a drop in replacement should still be a goal or at least
> close to it.  We want to be able to make the upgrade process as easy as
> possible for people.
>
> As I mentioned in my initial response I just don't think it makes any
> sense to start adding major new features to what is supposed to be a legacy
> broker as we decided to make Artemis the next generation when it was
> ready.  And if people want to go down that path I don't see how it benefits
> either project to do it concurrently under the same umbrella and have
> competing brokers.
>
> On Thu, Jul 11, 2019 at 11:27 AM Bruce Snyder 
> wrote:
>
>> (Reposting in this roadmap discussion)
>>
>> I agree that we must define a clear roadmap. We should create a new wiki
>> page for an overall ActiveMQ project roadmap that includes info for all
>> the
>> ActiveMQ components (ActiveMQ, ActiveMQ Artemis, ActiveMQ NMS and ActiveMQ
>> CMS). There is already an ActiveMQ Artemis Roadmap wiki page, is this info
>> still relevant/usable (
>>
>> https://cwiki.apache.org/confluence/display/ACTIVEMQ/ActiveMQ+Artemis+Roadmap
>> )?
>>
>> We need to work openly via the dev@activemq list on this roadmap page so
>> that it is defined in the open, is unambiguous and includes the entire
>> ActiveMQ community. It's very important that we hear from users of each
>> component because these folks have various ActiveMQ components deployed in
>> production and we need to know what is important to them instead of
>> speaking for them.
>>
>> As part of the roadmap discussion, we must also decide if one of the goals
>> for Artemis is still to be a drop-in replacement for ActiveMQ. I know that
>> at one time this was the goal, i.e., allow current ActiveMQ users to drop
>> in Artemis and have everything just continue to work. Is there still value
>> in this goal?
>>
>> Bruce
>>
>> On Thu, Jul 11, 2019 at 1:37 AM 
>> wrote:
>>
>> > Its about having clear direction as a project. Im not saying it has to
>> be
>> > artemis im not saying it has to be classic
>> >
>> >
>> >
>> >
>> > But there does have to be a single and very clear direction so end users
>> > have a clear understanding in the long term direction.
>> >
>> >
>> >
>> >
>> >  Having ever changing direction is worse than having none at all also.
>> It
>> > actually has a negative impact.
>> >
>> >
>> >
>> >
>> >
>> >
>> > This said last year i thought a clear direction was agreed. But if that
>> is
>> > to change, i think we need to be very clear what that is for both
>> classic,
>> > artemis and the clients. With actual real commitments, not just wooly
>> > aspirational ideas.
>> >
>> >
>> >
>> >
>> > Get Outlook for Android
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Jul 11, 2019 at 7:59 AM +0100, "Francois Papon" <
>> > francois.pa...@openobject.fr> wrote:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>

Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus

[Christopher Shannon]

Many of those pull requests are years old.  Furthermore no one is saying
there is no interest in a project.  But there is a huge difference from
supporting 5.x in terms of bug fixes and small features than talking about
doing something like adding new protocols or JMS 2.0 support.  For example
the level of effort to add JMS 2.0 correctly is quite high and I highly
doubt there's going to be anyone to do the work.  You need to update
everything from the client libraries to the broker logic all the way to the
data store (KahaDB) etc.

Doing something like that is a massive undertaking and makes 0 sense to me
at this point.  Why would we add JMS 2.0 support to 5.x when we already
have Artemis that supports JMS 2.0 and as a project we had previously
agreed to work towards Artemis as the next generation broker and as the
follow on?  And yes we had established that fact already as a project and
it's already on our website etc.  If someone has enough time to try and add
JMS 2.0 to 5.x then why not use that time to help make Artemis a drop in
replacement or make it easier to upgrade? Bruce brought that up and I do
think that having a drop in replacement should still be a goal or at least
close to it.  We want to be able to make the upgrade process as easy as
possible for people.

As I mentioned in my initial response I just don't think it makes any sense
to start adding major new features to what is supposed to be a legacy
broker as we decided to make Artemis the next generation when it was
ready.  And if people want to go down that path I don't see how it benefits
either project to do it concurrently under the same umbrella and have
competing brokers.

On Thu, Jul 11, 2019 at 11:27 AM Bruce Snyder 
wrote:

> (Reposting in this roadmap discussion)
>
> I agree that we must define a clear roadmap. We should create a new wiki
> page for an overall ActiveMQ project roadmap that includes info for all the
> ActiveMQ components (ActiveMQ, ActiveMQ Artemis, ActiveMQ NMS and ActiveMQ
> CMS). There is already an ActiveMQ Artemis Roadmap wiki page, is this info
> still relevant/usable (
>
> https://cwiki.apache.org/confluence/display/ACTIVEMQ/ActiveMQ+Artemis+Roadmap
> )?
>
> We need to work openly via the dev@activemq list on this roadmap page so
> that it is defined in the open, is unambiguous and includes the entire
> ActiveMQ community. It's very important that we hear from users of each
> component because these folks have various ActiveMQ components deployed in
> production and we need to know what is important to them instead of
> speaking for them.
>
> As part of the roadmap discussion, we must also decide if one of the goals
> for Artemis is still to be a drop-in replacement for ActiveMQ. I know that
> at one time this was the goal, i.e., allow current ActiveMQ users to drop
> in Artemis and have everything just continue to work. Is there still value
> in this goal?
>
> Bruce
>
> On Thu, Jul 11, 2019 at 1:37 AM 
> wrote:
>
> > Its about having clear direction as a project. Im not saying it has to be
> > artemis im not saying it has to be classic
> >
> >
> >
> >
> > But there does have to be a single and very clear direction so end users
> > have a clear understanding in the long term direction.
> >
> >
> >
> >
> >  Having ever changing direction is worse than having none at all also. It
> > actually has a negative impact.
> >
> >
> >
> >
> >
> >
> > This said last year i thought a clear direction was agreed. But if that
> is
> > to change, i think we need to be very clear what that is for both
> classic,
> > artemis and the clients. With actual real commitments, not just wooly
> > aspirational ideas.
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jul 11, 2019 at 7:59 AM +0100, "Francois Papon" <
> > francois.pa...@openobject.fr> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > We can a see there is still an interest from the users to Apache
> > ActiveMQ 5.x.
> >
> > In github we have 61 open PR => https://github.com/apache/activemq/pulls
> >
> > Why forcing users to migrate to Artemis if the community is still active?
> >
> > regards,
> >
> > François
> > fpa...@apache.org
> >
> > Le 08/07/2019 à 18:15, michael.andre.pea...@me.com.INVALID a écrit :
> > > I think as a project we need to be clear in direction here with one
> > roadmap. To avoid users confusion.
> > >
> > >
> > >
> > >
> > > I was on the understanding that as a community and PMC a roadmap was
> > already agreed.
> > >
> > >
> > >
> > >
> > > And this was for artemis to become activemq 6 was agreed and once it
> has
> > all features (and more) of 5 which is now nearing.
> > >
> > >
> > >
> > >
> > > Its one of the reasons over the years features like jms 2 there hasnt
> > been effort to add it, as Artemis was the planned replacement that
> brought
> > jms 2 features amongst others.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Get Outlook for Android
> > >
> > >
> > 

Re: [DISCUSSION] ActiveMQ 5.x roadmap, codename ActiveMQ Missus

[Christopher Shannon]

So I will preface this by saying hopefully my comments are not taken the
wrong way and turn into a big fight but instead can lead to a productive
discussion about the next steps.

First, I'm certainly not opposed to anyone who wants to work on modernizing
and adding features to existing software.  It is after all community driven
so if there are people willing to do the work then go for it. I myself am a
heavy user still of 5.x and some of those features could be useful and
intriguing if they were ultimately implemented.  They are quite major
features so it would require a lot of people/work to actually make it a
reality.

However...The main focus has generally been to maintain 5.x (bug fixes,
small features etc) and keep it around but to work on modernizing AMQ by
going with Artemis as the next generation.  There's been work to add
feature parity (still on going) in order to promote it as the future broker
that people would move to when ready.  Our new website even describes
Artemis as the next generation etc with the intention for people to
ultimately migrate.

My primary concern here is that putting resources and effort into a major
upgrade of 5.x will just create further divide in the AMQ community and you
will just end up with one faction focused on 5.x and one on Artemis and
divide up resources vs putting resources towards one ultimate broker.  I
think that in this scenario it would be somewhat counterproductive to be
essentially competing against ourselves with 2 brokers working to be
modernized under the same project (not to mention confusing for users).  So
personally I think it would be more beneficial if the community would work
towards one future broker (Artemis) to improve it vs trying to modernize 2
brokers.  Why not take the effort that would be put towards modernizing 5.x
into Artemis instead so we have 1 ultimate next generation broker?

However, again, this is community driven so if there's enough support to
modernize 5.x then it certainly can be done.  But that leads me to a
discussion that I have been hesitant to bring up but is this...if there is
enough support to want to go with 5.x modernization and put significant
resources towards it then I feel like it might finally be time to split up
the community and have AMQ and Artemis go their separate ways so they each
can thrive in their own environment and not have to deal with competing
groups stepping on each other.

On Tue, Jun 18, 2019 at 11:44 AM Jean-Baptiste Onofré 
wrote:

> Hi all,
>
> I would like to discuss with you about the ActiveMQ 5.x roadmap.
>
> Even if Artemis is there, the stack is different and we still have lot
> of users on ActiveMQ, and, as a ActiveMQ 5.x fan and contributor, I
> think it's worth to give a new "dimension" to ActiveMQ 5.x.
>
> As all Apache projects, ActiveMQ 5.x roadmap and use is driven by the
> community, so I would like to propose and share some ideas with the
> ActiveMQ community.
>
> I already imagine a new codename for ActiveMQ 5.x roadmap: ActiveMQ Missus.
>
> Basically, I would like to propose a roadmap around three major points:
>
> 1. Modularity
> Today, ActiveMQ 5.x is a monolythic broker, even if most of the parts
> are already well isolated (persistent stores, transport connectors,
> etc). It makes sense to have some more "modular" and micro-services
> oriented, why not leveraging Apache Karaf with services.
>
> 2. Configuration backends
> We currently use Spring beans XML as main configuration backend (or
> blueprint in Karaf). I think it makes sense to update and split the
> configuration backend with something more "pluggable", and be able to
> expose new configuration format like yml.
>
> 3. Protocol/API update
> I would like to add support of JMS 2.0 in ActiveMQ 5.x and check/update
> the other protocols/APIs.
>
> 4. Cloud friendly
> I already sent some ideas weeks ago about "cloud friendly features" in
> ActiveMQ 5.x.
> Basically, I would like to propose:
> - a replicated/distributed persistent store to be able to have several
> brokers running with a distributed store. I'm testing an update to
> KahaDB using Bookkeeper.
> - provide new discovery agents with support of Kubernetes, Hazelcast, ...
>
> I would love to hear the community about this ! ;)
> I'm planning to start a complete document to provide more details and
> "milestone".
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: kahadb index file larger than journal file on apache-activemq-5.15.9

[Christopher Shannon]

There is currently no way to shrink the index file and no plans to add
that. The index file generally grows and stabilizes with your use case
based on the max number of messages the broker will have stored at any
given time.  There's not really any reason to need to worry about shrinking
the index file and it shouldn't grow much larger than 10% of your max
journal size.  This is just an estimate though because the index could in
theory get much larger if you have a ton of really small messages (< 1KB)
to track and it would be smaller if you have lots of big messages
(megabytes)

On Wed, May 29, 2019 at 7:51 AM yanghao441286376 <441286...@qq.com> wrote:

> Hi, All,
>
> In my activemq instance(5.15.4 or 5.15.9), I find that the kahadb index
> file
> is larger than the journal file.
>
> As far as I know, want to shrink it the only way right now is to *stop the
> broker, delete the index* and restart so it does a replay and rebuilds the
> index but the size would just grow again as messages flow.  And most of the
> time, not allowed to stop the broker on PRD env.
>
> Do you plan to have other proper ways to shrink the index file in future
> ActiveMQ versions? Thanks.
>
> Log attached:
> [root@localhost kahadb]# pwd
> /opt/mq/apache-activemq-5.15.9/data/kahadb
> [root@localhost kahadb]# du -sh *
> 19M db-87.log
> 531Mdb.data
> 3.2Mdb.redo
> 4.0Klock
>
> Kind regards,
> air
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: ActiveMQ cannot handle too many topic with redeliveryPlugin

[Christopher Shannon]

20k messages and 30k topics is quite a bit so I'm not surprised the CPU
usage is very high.  The reason the CPU is high after stopping the
publishing is probably because you have a backlog on the broker that the
consumers need to work off.  You might also have a lot of messages being
processed for the DLQ.

If you think the issue is related specifically to the redelivery plugin
then your best bet is to hook up a profiler to the broker and to see where
the hot spot is that is using the most CPU in the plugin.  You can also
trying using a thread dump to figure it out.

On Thu, May 2, 2019 at 5:53 AM Franco Ng  wrote:

> No problem, I can provide heap dump but the file size is over 1GB.  Please
> provide location /link to upload, thanks.
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Kahadb journal logs only deleted when activemq restarts

[Christopher Shannon]

This page has some info that might help you:
https://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html

On Wed, Apr 17, 2019 at 7:43 PM TC  wrote:

> Hi,
>
> I have broker that runs with increasing journal logs file with mKahadb
> store
> for each destination.
>
> One of the queue - journal logs are keep increasing overtime.
>
> The strange part is that - everytime I restart activemq, these journal log
> files get deleted.
> To me, it looks like the message within these  journal log files are not
> referenced anymore - it should be get deleted during the gc cycle.
>
> The question - what could caused this problem ?
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Migrating storage from 5.10.0 to 5.14.5

[Christopher Shannon]

I don't think there's any current fallback option for SQL right now.
Contributions are welcome though so if you wanted to take a shot at adding
a property for that you could create a PR.

On Wed, Apr 17, 2019 at 4:28 PM mikmela  wrote:

> We seems to experience the same issue upgrading from 5.6.0 to 515.8, but in
> our case we use SQL database as a message store. As it was mentioned and
> confirmed by us KahaDB has a fallback capability when it encounter older
> (Version 6) of OpenWire.
> Unfortunately, it looks like for SQL databases there is no fallback option
> implemented:
> 2019-04-17 15:50:26,361 ERROR [Thread-8] (BrokerService.java:639) - Failed
> to start Apache ActiveMQ (RTCV180R1GPWR78QA12T3DEV-NY-CONNEX61616, null)
> java.io.UTFDataFormatException: bad string
> at
>
> org.apache.activemq.util.DataByteArrayInputStream.readUTF(DataByteArrayInputStream.java:265)
> at
>
> org.apache.activemq.openwire.v11.BaseDataStreamMarshaller.looseUnmarshalString(BaseDataStreamMarshaller.java:571)
> at
>
> org.apache.activemq.openwire.v11.MessageIdMarshaller.looseUnmarshal(MessageIdMarshaller.java:122)
> at
>
> org.apache.activemq.openwire.OpenWireFormat.looseUnmarshalNestedObject(OpenWireFormat.java:474)
> at
>
> org.apache.activemq.openwire.v11.BaseDataStreamMarshaller.looseUnmarsalNestedObject(BaseDataStreamMarshaller.java:466)
> at
>
> org.apache.activemq.openwire.v11.MessageMarshaller.looseUnmarshal(MessageMarshaller.java:220)
> at
>
> org.apache.activemq.openwire.v11.ActiveMQMessageMarshaller.looseUnmarshal(ActiveMQMessageMarshaller.java:101)
> at
>
> org.apache.activemq.openwire.v11.ActiveMQTextMessageMarshaller.looseUnmarshal(ActiveMQTextMessageMarshaller.java:101)
> at
>
> org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:367)
> at
>
> org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:201)
> at
>
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getLastMessageBrokerSequenceId(JDBCPersistenceAdapter.java:266)
> at
>
> org.apache.activemq.broker.region.DestinationFactoryImpl.getLastMessageBrokerSequenceId(DestinationFactoryImpl.java:147)
> at
>
> org.apache.activemq.broker.region.RegionBroker.(RegionBroker.java:130)
> at
>
> org.apache.activemq.broker.jmx.ManagedRegionBroker.(ManagedRegionBroker.java:108)
> at
>
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:2399)
> at
>
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:2391)
> at
>
> org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:2348)
> at
> org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:1045)
> at
>
> org.apache.activemq.broker.BrokerService.getAdminConnectionContext(BrokerService.java:2619)
> at
>
> org.apache.activemq.broker.BrokerService.startVirtualConsumerDestinations(BrokerService.java:2780)
> at
>
> org.apache.activemq.broker.BrokerService.startDestinations(BrokerService.java:2610)
> at
>
> org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:739)
> at
>
> org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:733)
> at
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:636)
> at
>
> COM.olf.adapter.jbroker.JBrokerService.startBroker(JBrokerService.java:1507)
> at
> COM.olf.adapter.jbroker.JBrokerComponent.run(JBrokerComponent.java:220)
> at java.lang.Thread.run(Thread.java:748)
>
> I'm wondering if there is a way to enable backward compatibility via some
> kind of property, or  there are some other ways to do it?
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: ActiveMQ freeze

[Christopher Shannon]

If you want help you are going to need to upgrade to a supported version.
There have been over 4200 commits since 5.6.0 so no one is going to try and
debug a version that old when the issue may have been fixed years ago.

On Thu, Apr 4, 2019 at 8:11 AM mcrandy  wrote:

> I logged the size of the write this time. We crashed just after trying to
> allocate 26MB. Is that considered to be much? Looking at the total heap
> usage at the time of the crash we seem far away from the max provided limit
> of 2,5GB so seems strange to me.
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

[ANNOUNCE] Apache ActiveMQ 5.15.9 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.9
has been released.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12344450

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5159-release.html

A big thanks to everyone who contributed to this release.

Re: Artemis GitHub repo archived?

[Christopher Shannon]

Thanks Robbie

On Tue, Mar 26, 2019 at 8:26 AM Robbie Gemmell 
wrote:

> I brought it to attention of Daniel from the infra team once he was
> around on chat and he fixed thigns up swiftly, the repo is now back in
> action.
>
> Robbie
>
> On Tue, 26 Mar 2019 at 09:46,  wrote:
> >
> > Thanks Robbie
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Mar 26, 2019 at 9:43 AM +, "Robbie Gemmell" <
> robbie.gemm...@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I also asked for assistance in infras chat but as expected though its
> > a bit quiet in there just now, likely need to wait until a little
> > later in the day.
> >
> > Robbie
> >
> > On Tue, 26 Mar 2019 at 08:57,  wrote:
> > >
> > > This is a mistake.
> > >
> > >
> > >
> > >
> > > The PMC voted to deprecate apollo sub project. And i raised a ticket
> with infra to do this. But whislt the title of the ticket was for apollo i
> accidentally put artemis git in the comment (copy error). Confusing infra.
> I have already messaged infra on the same ticket.
> > >
> > >
> > >
> > >
> > > This is entirely my mistake. Artemis is most definitely alive
> > >
> > >
> > >
> > >
> > > Get Outlook for Android
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Mar 26, 2019 at 8:47 AM +,  wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > > I just saw the message "This repository has been archived by the
> owner. It is now read-only." on https://github.com/apache/activemq-artemis
> (https://github.com/apache/activemq-artemis) and since I didn't see an
> announcement in the mailing list I wanted to ask if this was a mistake or
> if you no more accept PRs via github.
> > >
> > > Thanks,
> > > Jo
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>

Re: Slow performance to handle over 60,000 wildcard topics with 2,000msg/s

[Christopher Shannon]

The authorization plugin has to do a lot of processing as it is tracking
and checking ACLs for all of your topics (which is a ton) for every message
going through the broker and is going to eat up a lot of CPU. Your best bet
is to try and isolate which part is causing high cpu usage using a profiler
which might help someone come up with an optimization to help with the CPU
usage.  And as Justin mentioned this is open source software and a
community project and everyone is a volunteer so pull requests and patches
are always welcome if you can suggest a fix.

And Tim pointed out early on in this thread that keep in mind if you find
that the plugin is causing you trouble you are free to implement your own
authorization plugin.  The point of the plugin API is you can customize
stuff to your needs and if the plugin does not meet your performance
requirements then you can implement your own for your use case.

On Tue, Feb 19, 2019 at 1:25 AM Franco Ng  wrote:

> I set authorizationPlugin plugin as belolw, assign "user" can create &
> publish any queues and topics.  When I publish 2,000 message/sec with
> 60,000
> wildcard topics (E.g. stock.01), whole ActiveMQ server performance is
> down, CPU usage eat up to 50% and too many topic JMS messages are pending
> in
> ActiveMQ server.  However, I remove authorizationPlugin from activemq.xml,
> the problem is solved and CPU usage just eat up 2% and no pending JMS
> message.
>
> 
> 
>  groups="users,admins"/>
> 
> 
> 
> 
> 
> 
>  write="admins,users" read="admins,users" admin="admins,users" />
>  write="admins,users" read="admins,users" admin="admins,users" />
> 
> 
> 
> 
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Durable subscription across network connector

[Christopher Shannon]

First make sure you are using the latest version of the broker.

 Second, are you using a mixture of durable subscriptions and non-durable
subscriptions? If you are you might need to add a forceDurable flag to your
set up. Normally the creation of a durable subscription by S on broker B
should create a network durable subscription for B on broker A which would
collect the messages while B is offline and then forward the messages to B
when B comes back online.  I just added some documentation for this on the
wiki but you can also see it here:
https://issues.apache.org/jira/browse/AMQ-6383



On Sat, Jan 19, 2019 at 4:15 PM carl  wrote:

> Hi,
>
> I'm having trouble with the following problem. This is my layout with a
> Publisher P, Subscriber S and brokers A and B.
>
> P ---> A ---> B ---> S
>
> I need any message that P publishes to any topic to reliably reach S. I
> successfully setup a durable subscription between B and S. So that covers
> the case where S fails. However, when B fails, the messages published by P
> in the time that B is down are lost.
>
> This is my network connector configuration on A:
>
>   name="T:localhost->localhost"
> duplex="false"
> uri="static:(tcp:/...:61616)"
> userName="..."
> password="..."
> networkTTL="2"
> dynamicOnly="false">
> 
> 
> 
>  
>
> Is it possible to configure the network connector so that messages are not
> lost while B is down?
>
> Thanks for any help!
>
> Best,
>
> Carl
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: For Artemis, is there a way to set consumerWindowSize differently on per JMS consumer basis?

[Christopher Shannon]

When version 2.7.0 is released you will be able to set a default
consumerWindowSize per address so you should be able to accomplish what you
want.

See
https://github.com/apache/activemq-artemis/blob/master/docs/user-manual/en/address-model.md#configuring-addresses-and-queues-via-address-settings
At the bottom there is a new config parameter called
"default-consumer-window-size"

On Fri, Dec 14, 2018 at 8:59 AM Youyu Shao  wrote:

> Hello,
>
> We are using Artemis 2.6.2 as JMS server/broker. We have one JMS connection
> created from
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.
>
> We have two JMS queues, both are used as task distribution/load-balancing
> mechanism.
> One queue contains complex tasks taking long time to process, while the
> other
> contains simple tasks taking little time to finish.
>
> Each queue have multiple JMS consumers. We would like to see if there is a
> way
> to configure the consumers of the complex task queue with
> consumerWindowSize=0,
> and configure the consumers of the simple task queue with
> consumerWindowSize=-1.
>
> Simply put, is there a way to set consumerWindowSize differently on per JMS
> consumer basis?
>
> Thanks
>
> Youyu
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

[ANNOUNCE] Apache ActiveMQ 5.15.8 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.8
has been released.

A list of issues resolved in this release is available here:
https://jira.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12344359

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5158-release.html

A big thanks to everyone who contributed to this release.

Re: Next Artemis Release

[Christopher Shannon]

I agree it's probably time for a 2.7.0 soon.

Clebert, any idea what the time frame is for a 2.7.0 release?

On Tue, Nov 13, 2018 at 11:48 AM jlarkin  wrote:

> Hi,
>
> Is there any information on when the next Artemis release will be - 2.6.4 /
> 2.7.0?
>
> Looking to pick up some of the fixes that are in there.
>
> Thanks,
> John
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

[ANNOUNCE] Apache ActiveMQ 5.15.7 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.7
has been released.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12344049

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5157-release.html

A big thanks to everyone who contributed to this release.

Re: AMQ 5.8.0 leak on repetitive connections

[Christopher Shannon]

Version 5.8.0 is nearly 6 years old and there have been hundreds (maybe
thousands) of commits since then and one of them could have addressed your
issue even if you didn't find an exact match in Jira.  However, no one is
going to remember that far back to see if it is a known issue so you will
just need to test against the latest release as Justin pointed out.


On Wed, Sep 12, 2018 at 11:39 PM Justin Bertram  wrote:

> I have no idea if this is a known issue, but it seems like it would simple
> enough to run your test against the latest release to see if the issue
> still exists there.
>
>
> Justin
>
> On Wed, Sep 12, 2018 at 10:11 PM, SteveCherniak 
> wrote:
>
> > AMQ 5.8.0 - persistence false
> >
> > recreate leak with following:
> >
> > Add connection A
> > Loop
> > Add connection B
> > Add consumer on B
> > Add producer on A
> > Remove producer on A
> > Remove consumer on B
> > Remove disconnect B
> >
> > Triggered heap dumps after running test for a while. If left will run out
> > of
> > storage:
> >
> > Heap usage  288,896,736 bytes
> >
> > Object counts:
> >
> > 986,690 java/lang/Object
> > 752,581 java/lang/String
> > 636,931 java/util/concurrent/locks/ReentrantLock
> > 636,931 java/util/concurrent/locks/ReentrantLock$NonfairSync
> > 636,893 java/util/concurrent/CopyOnWriteArrayList
> > 479,962 char[]
> > 463,256 java/util/concurrent/atomic/AtomicLong
> > 463,183 org/apache/activemq/management/CountStatisticImpl
> > 289,690 java/util/LinkedList
> > 234,940 java/util/HashMap$Node
> > 231,779 java/util/concurrent/atomic/AtomicBoolean
> > 231,569 org/apache/activemq/usage/DefaultUsageCapacity
> > 155,569 java/util/concurrent/ConcurrentHashMap$Node
> > 154,979 java/util/HashMap
> > 116,377 java/util/ArrayList
> > 115,840 org/apache/activemq/filter/DestinationMapNode
> > 58,276 java/util/concurrent/ConcurrentHashMap
> > 58,162 org/apache/activemq/command/ActiveMQTopic
> >
> > Leak suspects:
> >
> > 65,124,744 (22.54%) [131,072] 12,522 array of java/util/HashMap$Node
> > 0xf054df70
> > |- 20,928 (0.01%) [24] 3 java/util/HashMap$Node 0xe1201338
> > |  |- 16,752 (0.01%) [24] 3 java/util/HashMap$Node 0xe44345c0
> > |  |- 4,112 (0%) [32] 4 org/apache/activemq/filter/DestinationMapNode
> > 0xe1201360
> > |  |- 40 (0%) [16] 1 java/lang/String 0xe1201350
> > |- 20,912 (0.01%) [24] 3 java/util/HashMap$Node 0xe4f77f48
> >|- 16,736 (0.01%) [24] 3 java/util/HashMap$Node 0xe5158a38
> >|- 4,112 (0%) [32] 4 org/apache/activemq/filter/DestinationMapNode
> > 0xe4f78e38
> >|- 40 (0%) [16] 1 java/lang/String 0xe4f78e28
> > ...
> >
> > 65,112,872 (22.54%) [131,072] 12,522 array of java/util/HashMap$Node
> > 0xf052df68
> > |- 20,928 (0.01%) [24] 3 java/util/HashMap$Node 0xe1202f98
> > |  |- 16,752 (0.01%) [24] 3 java/util/HashMap$Node 0xe4434590
> > |  |- 4,112 (0%) [32] 4 org/apache/activemq/filter/DestinationMapNode
> > 0xe1202fb0
> > |  |- 40 (0%) [16] 1 java/lang/String 0xe12256c0
> > |- 20,912 (0.01%) [24] 3 java/util/HashMap$Node 0xe2e25340
> >|- 16,736 (0.01%) [24] 3 java/util/HashMap$Node 0xe341a428
> >|- 4,112 (0%) [32] 4 org/apache/activemq/filter/DestinationMapNode
> > 0xe2e25c88
> >|- 40 (0%) [16] 1 java/lang/String 0xe2e25c78
> > ...
> >
> > 53,796,568 (18.62%) [131,072] 12,522 array of java/util/HashMap$Node
> > 0xee232140
> > |- 17,280 (0.01%) [24] 3 java/util/HashMap$Node 0xe2e25388
> > |  |- 13,824 (0%) [24] 3 java/util/HashMap$Node 0xe341a130
> > |  |- 3,432 (0%) [32] 4 org/apache/activemq/filter/DestinationMapNode
> > 0xe2e25d18
> > |  |- 40 (0%) [16] 1 java/lang/String 0xe2e25d08
> > |- 17,280 (0.01%) [24] 3 java/util/HashMap$Node 0xe121ee00
> >|- 13,824 (0%) [24] 3 java/util/HashMap$Node 0xe44346f0
> >|- 3,432 (0%) [32] 4 org/apache/activemq/filter/DestinationMapNode
> > 0xe121ee18
> >|- 40 (0%) [16] 1 java/lang/String 0xe11fd368
> > ...
> >
> > Searched error database. Did not find equivalent issue. I realize that
> this
> > scenario is not typical, but leak is consistent. Is this a known issue?
> Was
> > it fixed in a later release (> 5.8.0)?
> >
> > Thanks,
> > Steve
> >
> >
> >
> > --
> > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> > f2341805.html
> >
>

Re: [ANNOUNCE] CVE-2018-11775: ActiveMQ Client - Missing TLS Hostname Verification

[Christopher Shannon]

I just realized I had a typo in the announcement, the versions
affected should be:
Apache ActiveMQ 5.0.0 - 5.15.5

The file will be updated shortly.
On Mon, Sep 10, 2018 at 2:40 PM Christopher Shannon
 wrote:
>
> The following security vulnerability was reported against Apache
> ActiveMQ 5.15.5 and older versions.
>
> Please check the following document and see if you’re affected by the issue.
>
> http://activemq.apache.org/security-advisories.data/CVE-2018-11775-announcement.txt
>
> Apache ActiveMQ 5.15.6 has been released with appropriate fixes and is
> available for upgrade.

[ANNOUNCE] CVE-2018-11775: ActiveMQ Client - Missing TLS Hostname Verification

[Christopher Shannon]

The following security vulnerability was reported against Apache
ActiveMQ 5.15.5 and older versions.

Please check the following document and see if you’re affected by the issue.

http://activemq.apache.org/security-advisories.data/CVE-2018-11775-announcement.txt

Apache ActiveMQ 5.15.6 has been released with appropriate fixes and is
available for upgrade.

[ANNOUNCE] Apache ActiveMQ 5.15.6 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.6
has been released.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12343805

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5156-release.html

Please note that this release enables by default TLS hostname validation on
the ActiveMQ client which could cause issues for existing clients on
connection to the broker (for example if using self signed certs).  See the
release page for more details.

A big thanks to everyone who contributed to this release.

[ANNOUNCE] Apache ActiveMQ 5.15.5 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.5
has been released.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12343307

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5155-release.html

A big thanks to everyone who contributed to this release.

Re: Security features in Artemis 2.x

[Christopher Shannon]

I can answer a few of the questions however I suggest reading the migration
guide and the Artemis documentation as I think a lot of your questions will
be answered in there.

https://activemq.apache.org/artemis/migration/
https://activemq.apache.org/artemis/docs/latest/

1) Artemis supports its own CORE protocol (JMS), OpenWire(JMS), STOMP,
AMQP, and MQTT.  So it supports the same protocols as the 5.x broker along
with the CORE protocol.
2) For migration of clients, if you are just using JMS you can just use the
native CORE protocol and migrate easily.  You also have the option to use
OpenWire so all existing clients wouldn't need to change anything.
3) There is no KahaDB or MultiKahaDB as the journal is a completely
different implementation.  However there is a paging store so messages will
go to their own directory on the filesystem which is similar to
MultiKahaDB.  The journal also has compaction so the issues of KahaDB not
cleaning up shouldn't be a problem with Artemis.
4) For connectors your can use TCP and websockets (and TLS enable if you
want)
5) For authorization take a look at the above links.

For Kerberos I will let someone else answer as I haven't used it yet.

On Mon, Jun 11, 2018 at 2:40 AM xabhi  wrote:

> Hi,
>
> Can any Artemis dev please comment on these? The documentation doesn't
> touch
> upon these points and it isn't clear in what aspects the security is
> different/better when compared to ActiveMQ
>
> Thanks,
> Abhishek
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

[ANNOUNCE] Apache ActiveMQ 5.15.4 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.4
has been released.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12342685

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5154-release.html

A big thanks to everyone who contributed to this release.

[ANNOUNCE] CVE-2017-15709 - Information Leak

[Christopher Shannon]

CVE-2017-15709 - Information Leak

Severity: Low

Vendor:
The Apache Software Foundation

Versions Affected:
Apache ActiveMQ 5.14.0 - 5.15.2

Description:

When using the OpenWire protocol it was found that certain system
details (such as the OS and kernel version) are exposed as plain text.

Mitigation:

Use a TLS enabled transport or upgrade to Apache ActiveMQ 5.15.3.

Credit:
This issue was discovered by QingTeng cloud Security of Minded
Security Researcher jianan.huang

[ANNOUNCE] Apache ActiveMQ 5.15.3 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.3
has been released.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12311210&version=12341947

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5153-release.html

A big thanks to everyone who contributed to this release.

Re: Why ActiveMQ use sl4j like this?

[Christopher Shannon]

The best approach is to use something like Maven or Gradle that supports
dependency management for your application.  Using a build tool with
dependency management will allow you to pull in all the transitive
dependencies you need automatically for activemq-client (and other activemq
jars that you list) and you can easily override and manage certain versions
such as SLF4J.  Yes you still have to list out the specific ActiveMQ jars
that you need but usually you can just start with activemq-client for the
client and activemq-broker for the server side.  Those will pull in most
dependencies and you can add others as needed (such as jars for other wire
protocols)

On Tue, Dec 26, 2017 at 4:32 AM, Lara  wrote:

> because the activemq-all-5.15.2.jar has packaged sl4j as part of itself, it
> can cause conflict when I want to use the different version of sl4j.
> something like
>
> java.lang.NoClassDefFoundError: Could not initialize class org.slf4j.MDC
>
>
> otherwise, I have to pick out each jar that I want, such as
> activemq-client-5.15.2.jar and others. So what is the better way to use
> both
> activemq and sl4j together?
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805
> .html
>

Re: Amazon MQ

[Christopher Shannon]

Have you tried searching with bing?

On Fri, Dec 8, 2017 at 10:39 AM, Justin Bertram  wrote:

> > You can imagine that such organizations who make tons of investment in
> ActiveMQ are not impressed by claims of 'better architecture' or my
> 'journaling system is faster'.
>
> Do you have a list of what these companies are, in fact, impressed with?  I
> tried to Google for it but it didn't turn up much.
>
> > I think it would be good for you to interact more with other parts of RH.
>
> Which parts of Red Hat do I need to interact with more?  Please elaborate.
> I need your help here.
>
>
> Justin
>
> On Fri, Dec 8, 2017 at 9:27 AM, Hadrian Zbarcea 
> wrote:
>
> > What I know is exactly what I said: "effort was started part of the RH
> > partnership". I know very little about a partnership. The little I know I
> > cannot disclose and things change all the time anyway.
> >
> > RH's strategy, like any other business is driven by sales. What I can
> tell
> > you for instance that's public information is that the US (and other)
> > governments are heavy users of ActiveMQ (see USGS Earthquake Early
> Warning
> > [1], bottom of page 12 or search for ActiveMQ). You can imagine that such
> > organizations who make tons of investment in ActiveMQ are not impressed
> by
> > claims of 'better architecture' or my 'journaling system is faster'. It's
> > costs, training, a lot of factors to consider if you want to be
> successful
> > (see why even the faster RabbitMQ struggles). ActiveMQ 5.x is very
> reliable
> > when configured well. So it's no surprise that companies like Amazon
> decide
> > the way they do.
> >
> > We can talk more about what I see as a path to success and all, but I
> > think it would be good for you to interact more with other parts of RH.
> >
> > My $0.02,
> > Hadrian
> >
> > [1] https://pubs.usgs.gov/of/2014/1097/pdf/ofr2014-1097.pdf
> >
> >
> >
> > On 12/08/2017 09:38 AM, Justin Bertram wrote:
> >
> >> I'm not clear on what you're saying.  Are you indicating that Amazon and
> >> Red Hat are partnering on this venture for ActiveMQ 5.x in AWS?
> >>
> >>
> >> Justin
> >>
> >> On Fri, Dec 8, 2017 at 8:21 AM, Hadrian Zbarcea 
> >> wrote:
> >>
> >> I made some inquiries and have it on good authority that the AWS Managed
> >>> ActiveMQ effort was started part of the RH partnership [1]. So while
> the
> >>> community was not contacted, AWS did talk to people with ActiveMQ
> >>> expertise. Now I am surprised that the RH people on this list didn't
> know
> >>> about it (and given the inquiries I really believe they were not aware
> of
> >>> that). RH is a large company and it looks like opinions (regarding
> >>> ActiveMQ) are as diverse as they are in this community.
> >>>
> >>> Related to AWS, this was not a whim, an "it would be nice" sort of
> >>> service. They have serious interest from users. There is massive (and
> >>> increasing) interest in asynchronous messaging (see also Kafka,
> >>> RabbitMQ).
> >>> People make serious investments in such systems and the credibility of
> >>> the
> >>> community is super important.
> >>>
> >>> Hadrian
> >>>
> >>> [1] https://aws.amazon.com/partners/redhat/
> >>>
> >>>
> >>> On 11/28/2017 10:51 PM, Justin Bertram wrote:
> >>>
> >>> I saw that announcement as well and was a bit puzzled by the lack of
> any
>  involvement by Amazon in the community (at least that I could tell).
>  That
>  is, of course, their prerogative.
> 
>  Since it's so unclear at this point how this potentially new user-base
>  might impact the community I don't see how it can factor in to the
>  road-map.  It may complicate things; it may not.  There may be renewed
>  interest in 5.x; there may not.  Who's to say?  In my opinion this
>  further
>  highlights the need to clearly define a project road-map.  If such a
>  road-map had been defined 6-12 months ago maybe Amazon is making a
>  different announcement today.
> 
> 
>  Justin
> 
>  On Tue, Nov 28, 2017 at 9:32 PM, Tim Bain 
>  wrote:
> 
>  Amazon announced today a service called Amazon MQ that allows ActiveMQ
>  5.x
> 
> > to be run as a managed service in AWS:
> > https://aws.amazon.com/blogs/aws/amazon-mq-managed-message-
> > broker-service-for-activemq/
> >
> > Was anyone on this list aware of that effort prior to this
> > announcement?
> >
> > We should all be aware that there may be additional users coming to
> > ActiveMQ as a result of this service, who may have minimal experience
> > with
> > the configuration details of the broker and limited access to
> detailed
> > troubleshooting information such as logs and JMX. This may complicate
> > or
> > delay the eventual sunsetting of 5.x in favor of Artemis; there may
> be
> > interest in keeping 5.x alive for longer as a result of its use in
> this
> > service.
> >
> > Tim
> >
> >
> >
> 
> >>
>

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Christopher Shannon]

After reading the discussion and thinking about it I think I am on board
with going with ActiveMQ 6.

What's the next step with this?  Do we want to propose a vote or keep the
discussion open longer?

On Thu, Nov 23, 2017 at 3:09 PM, Gary Tully  wrote:

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

Re: Configure activemq-client to trust any SSL certificate from the broker without verifying it

[Christopher Shannon]

In 5.x it isn't quite as simple.

To trust all you'll need to extend ActiveMQSslConnectionFactory and
override the createTrustManager() method.  This should work:
@Override
protected TrustManager[] createTrustManager() throws Exception {
return new TrustManager[] { new X509TrustManager() {
public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[] {};
}

public void checkClientTrusted(final X509Certificate[] chain, final String
authType)
throws java.security.cert.CertificateException {
}

public void checkServerTrusted(final X509Certificate[] chain, final String
authType)
throws java.security.cert.CertificateException {
}
} };
}

Another example of this is how you can do this with Netty.  Artemis
achieves this by using the InsecureTrustManagerFactory class that is part
of Netty.  See:

https://github.com/apache/activemq-artemis/blob/master/
artemis-core-client/src/main/java/org/apache/activemq/
artemis/core/remoting/impl/ssl/SSLSupport.java
https://github.com/netty/netty/blob/4.1/handler/src/
main/java/io/netty/handler/ssl/util/InsecureTrustManagerFactory.java


To disable verifying host name you need to override the hostname verifier.
You could override the createTransport method.  I think something like this
would work:

@Override
protected Transport createTransport() throws JMSException {

final HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String arg0, SSLSession arg1) {
return true;
}
};

// Install the all-trusting host verifier
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);

return super.createTransport();
}


On Wed, Nov 29, 2017 at 5:52 AM, Jiri Danek  wrote:

> Hi,
>
> I need to configure activemq-client not to perform broker cerificate
> validation. I need this for testing purposes, because I need to test the
> system over SSL, but I do not yet have certificate distribution solved.
>
> In Artemis, with artemis-jms-client, there is verifyHost=false and
> trustAll=true connection url properties I can use for this purpose. How do
> I achieve the same with ActiveMQ?
>
> Thanks!
> --
> Jiri Daněk
>

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Christopher Shannon]

Jeff,

I don't think anyone is proposing killing off 5.x at this point, but just
clarifying what the future is in terms of Artemis and ActiveMQ 6.  I do
think we need to retire Apollo though.

Chris

On Mon, Nov 20, 2017 at 12:41 PM, jgenender  wrote:

> I'll throw in my .02 on this...
>
> I think the discussion should be here and in the open and I am confident
> the
> PMC will decide based on the community, and not on their personal view.
>
> I also think we need to be very careful in any discussion about sun-setting
> AMQ 5.X.  "Classic" as it has been discussed still is the #1 installed MQ
> in
> the world.  It is most certainly heavily used, still much more so than
> Artemis (at least from my view).  As long as the community is strong, AMQ
> 5.X should continue forward.
>
> I am looking forward to Artemis becoming ActiveMQ 6.  IMHO, it should be
> called ActiveMQ because I believe that was the original intent... that
> Artemis was the code name, and it would be ActiveMQ 6 once it hit 1.0 (at
> least that's what I thought was going to happen).  If we want people to
> take
> Artemis as a part of ActiveMQ, and we want to up its game regarding usage
> and community, I really think keeping it in the ActiveMQ lineup is really
> the way to go.  I hopefully look forward to that as I really want to see a
> lot more installations of the product. :-)
>
> Just my usual .02.
>
> Jeff
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Christopher Shannon]

Also, I should add that if a bunch of people think it's better to rename
Artemis to ActiveMQ 6 then that is fine too.  My opinion about keeping it
as Artemis is it would be easier but if people feel strongly about making
it ActiveMQ 6 and want to do the work to rename everything that is fine
with me as well.

On Wed, Nov 15, 2017 at 10:41 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I think it's pretty clear at this point that Artemis is the future.
> However, I don't know that renaming it to ActiveMQ 6 makes any sense as it
> would be a lot of work and more confusion.
>
> My opinion would be to just have the roadmap say Artemis is the future and
> recommended broker and drop plans to have an ActiveMQ 6 release.  We can
> just keep using the current versioning that Artemis is already using.
>
> On Wed, Nov 15, 2017 at 10:14 AM, Timothy Bish 
> wrote:
>
>> On 11/15/2017 10:04 AM, Jiri Danek wrote:
>>
>>> On Wed, Nov 15, 2017 at 3:59 PM, Justin Bertram 
>>> wrote:
>>>
>>> Ultimately I believe the decision is in the hands of the ActiveMQ PMC
>>>> [1].
>>>>
>>>> Where can I find a list of PMC members for ActiveMQ? The closest I got
>>> to
>>> it is http://activemq.apache.org/team.html
>>>
>> The info for that is here:
>> https://projects.apache.org/committee.html?activemq
>>
>>
>> --
>> Tim Bish
>>
>>
>

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Christopher Shannon]

I think it's pretty clear at this point that Artemis is the future.
However, I don't know that renaming it to ActiveMQ 6 makes any sense as it
would be a lot of work and more confusion.

My opinion would be to just have the roadmap say Artemis is the future and
recommended broker and drop plans to have an ActiveMQ 6 release.  We can
just keep using the current versioning that Artemis is already using.

On Wed, Nov 15, 2017 at 10:14 AM, Timothy Bish  wrote:

> On 11/15/2017 10:04 AM, Jiri Danek wrote:
>
>> On Wed, Nov 15, 2017 at 3:59 PM, Justin Bertram 
>> wrote:
>>
>> Ultimately I believe the decision is in the hands of the ActiveMQ PMC [1].
>>>
>>> Where can I find a list of PMC members for ActiveMQ? The closest I got to
>> it is http://activemq.apache.org/team.html
>>
> The info for that is here:
> https://projects.apache.org/committee.html?activemq
>
>
> --
> Tim Bish
>
>

Re: ActiveMQ 5.14 - Future support for Java7 users

[Christopher Shannon]

There is not currently any plans for more releases but if there's enough
demand for it (or critical fixes) then one could always be done.  The
releases have always been community driven so if someone speaks up and has
specific fixes they wanted to be merged back then it's possible to do
another release.

On Thu, Nov 2, 2017 at 11:35 PM, grandelok 
wrote:

> Hi devs,
>
> Would there be future releases of ActiveMQ 5.14 for Java7 users?
> If yes, can we expect some backport of bugs and security changes from
> 5.15.x?
>
> Thank you ActiveMQ Team.
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

[ANNOUNCE] Apache ActiveMQ 5.15.2 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.2
has been released.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12341669

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5152-release.html

A big thanks to everyone who contributed to this release.

Re: [ActiveMQ 6.0] Will ActiveMQ 6.0 will be released on Artemis codebase?

[Christopher Shannon]

Yes Artemis is being actively developed  and is the primary focus while the
old ActiveMQ 5.x line is mostly just maintenance mode at this point.  The
intention is that Artemis is the successor regardless of whether it keeps
the name Artemis or is renamed at some point.  In my opinion if you are
starting a new project I would use Artemis as that is where all current
development focus is and what will be actively maintained and improved in
the future.

On Fri, Jul 14, 2017 at 10:59 AM, Clebert Suconic  wrote:

> ...there's a lot of activity on Artemis with new code and features
> added each day.
>
>
> On Fri, Jul 14, 2017 at 3:20 AM, kkott00  wrote:
> > As it have been reported before  here
> >    Artemis become
> > successor of ActiveMQ line. Is it still actual? Is there  migration plan
> > expected? Should I prefer Artemis for new projects than ActiveMQ?
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMQ-6-0-Will-ActiveMQ-6-0-will-be-released-
> on-Artemis-codebase-tp4728543.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
>
> --
> Clebert Suconic
>

Re: Odd KahaDB journaling behaviour

[Christopher Shannon]

The KahaDB index does not drop in size after increasing.  It just keeps
track of free pages and will re-use them.  So the index tends to grow as
large as it needs and hits a consistent point.  A large backlog of messages
will cause the index to increase to track all of the messages. There was at
one point a bug that caused the index to grow too large but that has been
fixed as of https://issues.apache.org/jira/browse/AMQ-6590

On Wed, Jul 12, 2017 at 1:38 AM, Tim Bain  wrote:

> Jakub,
>
> I had hoped that someone who knows the internals of KahaDB (not me) would
> respond, but since no one has...
>
> If the percent utilization dropped from 100% after the index rebuild, then
> that's a bug (because the percent utilization should be the same in an
> existing index and a rebuilt one) and it should be reported in JIRA.
>
> I wouldn't say the size of the index file in and of itself is inherently a
> bug; nothing says that a file that balloons large and then is no longer
> needed will necessarily come back down to its minimum possible size later,
> and it wouldn't surprise me if an index file was maintained as a
> sparsely-populated file of the same size when its contents shrink
> (otherwise, you'd spent lots of I/O operations just moving bytes around to
> compact it whenever its content shrunk.
>
> Tim
>
> On Jun 28, 2017 12:06 PM, "Jakub Korab" 
> wrote:
>
> > Sorry, that last paragraph should have read:
> > --
> > The thing that brought this to my attention was that storePercentUsage
> was
> > hitting 100% for a multi-GB max store size. I suspect this is due to some
> > crusty data in the indexes themselves - after 5993 x 8mb journals,
> perhaps
> > a 79mb *index* is not unreasonable. When the *indexes* are deleted and
> > rebuilt, they go down to 2mb.
> > --
> >
> > Jakub
> >
> >
> > On Tue, Jun 27, 2017 at 10:20 AM, Jakub Korab <
> jakub.korab.li...@gmail.com
> > >
> > wrote:
> >
> > > Hi all,
> > >
> > > I am seeing some odd behaviour in a 5.14.5 ActiveMQ instance that used
> > > mKahaDB - I have not seen this sort of thing before, and was wondering
> if
> > > anyone could shed some light on it.
> > >
> > > The directory listing below is for one fragment of an mKahaDB
> > > installation. It is configured for 8mb journal files, and accepts
> > messages
> > > for a single queue only. Messages are 60-80kb in size.
> > >
> > > What I am seeing is a very large index (db.data), often far in excess
> of
> > > the total size of the journals. The following is not uncommon to what
> is
> > > happening in other mKahaDB fragments:
> > >
> > > -rw-r--r-- 1 activemq activemq  8388608 Jun 19 18:07 db-5985.log
> > > -rw-r--r-- 1 activemq activemq  8388608 Jun 19 18:09 db-5986.log
> > > -rw-r--r-- 1 activemq activemq  8388608 Jun 19 18:11 db-5987.log
> > > -rw-r--r-- 1 activemq activemq  8388608 Jun 19 18:14 db-5988.log
> > > -rw-r--r-- 1 activemq activemq  8388608 Jun 19 18:16 db-5989.log
> > >
> > >
> > >
> > >
> > > *-rw-r--r-- 1 activemq activemq99401 Jun 20 00:13
> > > db-5991.log-rw-r--r-- 1 activemq activemq  8388608 Jun 20 01:00
> > > db-5990.log-rw-r--r-- 1 activemq activemq  728 Jun 20 01:03
> > > db-5993.log-rw-r--r-- 1 activemq activemq  8388608 Jun 20 09:32
> > db-5992.log*-rw-r--r--
> > > 1 activemq activemq  3291400 Jun 20 17:54 db.redo
> > > *-rw-r--r-- 1 activemq activemq 79540224 Jun 20 17:54 db.data*
> > > -rw-r--r-- 1 activemq activemq  8388608 Jun 20 17:54 db-5994.log
> > >
> > > Points of note:
> > > - Total journal size is 67.2mb, indexes are 79.5mb.
> > > - db-5990.log is written after db-5991.log, db-5992.log after
> db-5993.log
> > > (non-sequential writes)
> > >
> > > The thing that brought this to my attention was that storePercentUsage
> > was
> > > hitting 100% for a multi-GB max store size. I suspect this is due to
> some
> > > crusty data in the indexes themselves - after 5993 x 8mb journals,
> > perhaps
> > > a 79mb journal is not unreasonable. When the journals are deleted and
> > > rebuilt, they go down to 2mb.
> > >
> > > Any ideas as to why the index is so large, and what might cause
> journals
> > > to be written out of order?
> > >
> > > Thanks,
> > >
> > > Jakub
> > >
> >
>

[ANNOUNCE] Apache ActiveMQ 5.15.0 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.0
has been released and includes many fixes and improvements.

Also note that this release bumps the minimum required Java version to Java
8.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338054

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5150-release.html

A big thanks to everyone who contributed to this release.

Re: AcativeMQ becomes slow suddenly in 60 minutes after starting a performance test

[Christopher Shannon]

How much memory have you allocated for the broker?  You might need to
simply allocate more memory or tune your memory limits.  See
http://activemq.apache.org/javalangoutofmemory.html

On Fri, Jun 30, 2017 at 7:10 AM, Hidekazu  wrote:

> Hi,
>
> We did a performance test for ActiveMQ and came across a problem.
> I hope someone help us understand what was wrong with my ActiveMQ.
> Let me explain it here.
>
> 
> Transaction time became long suddenly from 50 millsec to 60 sec in about 60
> minutes
> after starting a performance test.
> ActiveMQ kept cpu and memory usage in a normal condition during the
> performance test.
> However, iowait rose 10% in 60 minutes.
>
>
> 
> Our ActiveMQ version 5.14.3
>
> We emulated 1,000 IoT clients and sent data to ActiveMQ at one minute
> interval.
> Payload size sent by IoT client was about 2 Kbytes.
> KahaDB size is enough big. (100GB)
>
>
> 
> There was an error and out of memory in kahaDB log.
>
> --
> 2017-06-16 04:39:19,615 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 04:39:19,615 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 04:45:08,527 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 04:45:08,527 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 04:57:16,863 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 04:57:16,863 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 05:10:08,083 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 05:10:08,083 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 05:22:49,960 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 05:22:49,960 [eckpoint Worker] WARN  MessageDatabase
> - Failed to load next journal location: null
> 2017-06-16 08:19:45,059 [eckpoint Worker] ERROR MessageDatabase
> - Checkpoint failed
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 2017-06-16 08:19:45,059 [eckpoint Worker] ERROR MessageDatabase
> - Checkpoint failed
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> --
>
> Thanks.
> Hidekazu
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/AcativeMQ-becomes-slow-suddenly-in-60-minutes-
> after-starting-a-performance-test-tp4728103.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: How to monitor artemis ?

[Christopher Shannon]

As a follow up, there has been some discussion on building a web console
but no work has been done yet on it.

On Wed, Jun 7, 2017 at 5:32 PM, Brett Delle Grazie <
brett.dellegra...@gmail.com> wrote:

> You can also use HawtIO and this plugin:
> https://github.com/rh-messaging/artemis-hawtio
>
> Its not as complete as JConsole etc. but it only requires access to the
> Jolokia port, not direct JMX so works more easily over firewalls / proxies
> etc.
>
> On 6 June 2017 at 14:05, Justin Bertram  wrote:
>
> > You can using JConsole, JVisualVM, or any other GUI JMX tool to monitor
> > Artemis.  Currently there is no web console.
> >
> >
> > Justin
> >
> > - Original Message -
> > From: "wangqinghuan" <1095193...@qq.com>
> > To: users@activemq.apache.org
> > Sent: Tuesday, June 6, 2017 4:30:17 AM
> > Subject: How to monitor artemis ?
> >
> > I has installed artemis, but I couldn't monitor it in a web UI , like the
> > ActiveMQWeb for ActiveMQ.Has web UI for artemis?
> >
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/How-to-monitor-artemis-tp4727071.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
>
>
> --
> Kind regards,
>
> Brett Delle Grazie
>

Re: Switch to Artemis from ActiveMQ v5.14.4?

[Christopher Shannon]

Artemis supports all the same clients plus an extra one.  It supports the
Core protocol (The Artemis native protocol), OpenWire(which is the ActiveMQ
5.x native protocol), AMQP, MQTT, and STOMP.  So any of your existing
clients will work with the broker as long as you have enabled the protocol
support.   So if you want to use existing ActiveMQ clients then you would
need to enable OpenWire.

Take a look at
https://activemq.apache.org/artemis/docs/2.1.0/protocols-interoperability.html
for information on enabling protocols.  Also, I just noticed on that
documentation page under the OpenWire section that it says "Apache ActiveMQ
Artemis JMS client" which should say "Apache ActiveMQ 5.x JMS client".
I'll fix that in the documentation.


On Thu, Jun 8, 2017 at 3:40 AM, xabhi  wrote:

> How hard would be to switch just the messaging server from ActiveMQ to
> Artemis. There are a lot of JMS, Perl, Python clients connecting to our
> ActiveMQ instance.
>
> Is Artemis being developed as drop-in replacement for ActiveMQ that can
> work
> seamlessly with activemq-client libraries without much changes? It would be
> great if I can use it as a drop-in replacement for my current ActiveMQ
> instance without disturbing client side code, much easier to test if it is
> possible.
>
> Thanks,
> Abhi
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Switch-to-Artemis-from-ActiveMQ-v5-14-4-tp4727014p4727185.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: why AvtiveMq is slowly than Kafka?

[Christopher Shannon]

Justin,

Thanks for linking the design document for the benchmark test I will need
to take a look and see how what the test is for the results to come up with
that kind of speed.

Based on my own experience using several types of brokers a typical message
rate under any scenario (non-persistent and async producers included) is
going to be much slower and come no where near that number.


On Mon, Jun 5, 2017 at 11:53 AM, Justin Bertram  wrote:

> Couple of things...
>
>   1) I agree 100% that comparing Kafka to message brokers like ActiveMQ is
> like comparing apples to oranges.  They are really quite different.
>   2) My point wasn't necessarily to compare Artemis' performance with
> Kafka.  My reply was simply in response to your assertion that, "Any
> standalone broker like ActiveMQ, Artemis, etc is going to be measured at a
> rate of thousands per second."  I tried to make that clear by quoting this
> specific statement, but perhaps my intent wasn't as clear as I'd hoped.
>   3) I wasn't attempting to mislead anyone.  I apologize if it came across
> that way.
>   4) The chance of hitting 8 million messages per second is greater than
> zero - at least as it's measured by SpecJMS.  The benchmark results proves
> this.  Of course, as with all things performance related the devil is in
> the details.  Perhaps SpecJMS is measuring throughput in a different way
> than you might in your own test.  In any event, "the most important
> requirement for the SPECjms2007 benchmark is that it is based on a
> representative workload scenario including a representative set of
> interactions, message types, message sizes and message delivery modes." [1]
>   5) Certainly fully synchronous and persistent use-cases will reduce
> performance, but many use-cases don't require that.
>   6) Clebert's "benchmark" (both code and operating environment) is quite
> different from the SpecJMS results I linked.
>
>
> Justin
>
> [1] https://www.spec.org/jms2007/docs/DesignDocument.html#S1
>
> - Original Message -
> From: "Christopher Shannon" 
> To: users@activemq.apache.org
> Sent: Monday, June 5, 2017 8:28:50 AM
> Subject: Re: why AvtiveMq is slowly than Kafka?
>
> That may be what the benchmark says but there is zero chance of hitting 8
> million messages per second, especially persistent messages.  Take a look
> at Clebert's blog:
> http://clebertsuconic.blogspot.com/2016/12/50k-persistent-messages-per-
> second-on.html
>  And that required making the producer completely async.
>
> Even non-persistent messages, I think under most use cases and hardware I
> would be amazed if the performance was able to go past 100k messages a
> second.
>
> This is not to bash Artemis...it is very fast for a message broker but it
> is completely misleading to try and compare real world performance of a
> standalone broker (Artemis, ActiveMQ, EMS, etc) with something like Kafka.
>
>
>
> On Mon, Jun 5, 2017 at 9:03 AM, Justin Bertram 
> wrote:
>
> > > Any standalone broker like ActiveMQ, Artemis, etc is going to be
> > measured at a rate of thousands per second.
> >
> > For what it's worth, HornetQ (upon which Artemis is based) achieved over
> 8
> > million messages per second on SpecJMS [1].  I would expect Artemis'
> > performance to be comparable (or better given some enhancements put in
> > place since then).
> >
> >
> > Justin
> >
> > [1] http://hornetq.blogspot.com/2011/07/82-million-messages-
> > second-with-specjms.html
> >
> > - Original Message -
> > From: "Christopher Shannon" 
> > To: users@activemq.apache.org
> > Sent: Monday, June 5, 2017 6:45:26 AM
> > Subject: Re: why AvtiveMq is slowly than Kafka?
> >
> > You can't compare Kafka to a JMS type message broker.  Kafka is
> completely
> > different.
> >
> > Kafka is a system that scales horizontally and is essentially a big
> > write-ahead log and breaks up the topics into partitions across many
> > servers so they can be scanned concurrently.   This allows insane message
> > rates but the trade off is that the feature set is much less...there are
> no
> > features like message acknowledgement (messages are not deleted, they are
> > aged off and a client can seek to any point in the log), message
> > expiration, scheduled messages, transactions (although transaction
> support
> > is currently being worked on) etc which offloads a lot of work that a
> > typical message broker has to do.   Kafka clusters can scale to thousands
> > of nodes and handle millions of messages per second.
> &g

Re: why AvtiveMq is slowly than Kafka?

[Christopher Shannon]

That may be what the benchmark says but there is zero chance of hitting 8
million messages per second, especially persistent messages.  Take a look
at Clebert's blog:
http://clebertsuconic.blogspot.com/2016/12/50k-persistent-messages-per-second-on.html
 And that required making the producer completely async.

Even non-persistent messages, I think under most use cases and hardware I
would be amazed if the performance was able to go past 100k messages a
second.

This is not to bash Artemis...it is very fast for a message broker but it
is completely misleading to try and compare real world performance of a
standalone broker (Artemis, ActiveMQ, EMS, etc) with something like Kafka.



On Mon, Jun 5, 2017 at 9:03 AM, Justin Bertram  wrote:

> > Any standalone broker like ActiveMQ, Artemis, etc is going to be
> measured at a rate of thousands per second.
>
> For what it's worth, HornetQ (upon which Artemis is based) achieved over 8
> million messages per second on SpecJMS [1].  I would expect Artemis'
> performance to be comparable (or better given some enhancements put in
> place since then).
>
>
> Justin
>
> [1] http://hornetq.blogspot.com/2011/07/82-million-messages-
> second-with-specjms.html
>
> - Original Message -
> From: "Christopher Shannon" 
> To: users@activemq.apache.org
> Sent: Monday, June 5, 2017 6:45:26 AM
> Subject: Re: why AvtiveMq is slowly than Kafka?
>
> You can't compare Kafka to a JMS type message broker.  Kafka is completely
> different.
>
> Kafka is a system that scales horizontally and is essentially a big
> write-ahead log and breaks up the topics into partitions across many
> servers so they can be scanned concurrently.   This allows insane message
> rates but the trade off is that the feature set is much less...there are no
> features like message acknowledgement (messages are not deleted, they are
> aged off and a client can seek to any point in the log), message
> expiration, scheduled messages, transactions (although transaction support
> is currently being worked on) etc which offloads a lot of work that a
> typical message broker has to do.   Kafka clusters can scale to thousands
> of nodes and handle millions of messages per second.
>
> Any standalone broker like ActiveMQ, Artemis, etc is going to be measured
> at a rate of thousands per second.
>
> On Sat, Jun 3, 2017 at 3:13 PM, Clebert Suconic  >
> wrote:
>
> > For the use case you're after. (No hard syncs). Mmap is a good candidate.
> > Probably better.
> >
> >
> > Libaio was engineered the case where you hard sync with callbacks from
> the
> > Linux os
> > On Sat, Jun 3, 2017 at 12:46 PM wangqinghuan <1095193...@qq.com> wrote:
> >
> > > hi clebertsuconic:
> > > i read the blog
> > > https://activemq.apache.org/artemis/docs/2.1.0/persistence.html
> > > By default Apache ActiveMQ Artemis will try and use an AIO journal.But
> it
> > > seems like that Mmap is also a good implemention.which one gives more
> > > performance?
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://activemq.2283324.n4.nabble.com/why-AvtiveMq-is-
> slowly-than-Kafka-
> > tp4726911p4726992.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >
> > --
> > Clebert Suconic
> >
>

Re: Switch to Artemis from ActiveMQ v5.14.4?

[Christopher Shannon]

Artemis is intended to be the follow on to ActiveMQ 5.x.  It is currently
being actively developed to add new features to it with the goal that the
useful features from ActiveMQ will also be added to Artemis.  Most of the
development effort is being done there and ActiveMQ 5.x is basically in
maintenance mode at this point.  There are also some nice features that
Artemis has that don't exist in ActiveMQ 5.x such as replication support.

Performance wise Artemis should certainly be faster than ActievMQ 5.x.  It
has a more modern architecture and there has been a lot of work recently in
terms of performance to make it faster (like memory mapped journal files).
There are more optimizations planned going forward such as buffer pooling
to make it even faster.

In terms of production stability I would say that depends.  Artemis was
based off of HornetQ which was a production broker that supported JMS so
JMS support should generally be stable.  However, there's been a lot of new
features added recently and new features take a little bit of time to work
all of the kinks out of.  An example is AMQP support, the initial support
had issues but there have been a lot of fixes recently to make it more
stable.

Your best bet would be to just take a look at Artemis and try it out and
see if it has all the features that you require.  If it doesn't meet your
current use case then you could continue to use the ActiveMQ 5.x broker for
now but it would be helpful if you could create new Jiras or start
discussions on issues you find.

On Mon, Jun 5, 2017 at 7:49 AM, xabhi  wrote:

> What is the difference between Artemis and current ActiveMQ versions? When
> should one be preferred over another? Is there any difference between
> features?
> Artemis docs say it has outstanding performance - should this be preferred
> over ActiveMQ? How stable Artemis is in production environments?
>
> I have been using ActiveMQ since v5.8 and it has worked well and am hearing
> of new messaging products like Artemis(under ActiveMQ umbrella) and Kafka
> etc. I am looking for some feedback for these products when compared to
> ActiveMQ.
>
> Thanks,
> Abhi
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Switch-to-Artemis-from-ActiveMQ-v5-14-4-tp4727014.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: why AvtiveMq is slowly than Kafka?

[Christopher Shannon]

You can't compare Kafka to a JMS type message broker.  Kafka is completely
different.

Kafka is a system that scales horizontally and is essentially a big
write-ahead log and breaks up the topics into partitions across many
servers so they can be scanned concurrently.   This allows insane message
rates but the trade off is that the feature set is much less...there are no
features like message acknowledgement (messages are not deleted, they are
aged off and a client can seek to any point in the log), message
expiration, scheduled messages, transactions (although transaction support
is currently being worked on) etc which offloads a lot of work that a
typical message broker has to do.   Kafka clusters can scale to thousands
of nodes and handle millions of messages per second.

Any standalone broker like ActiveMQ, Artemis, etc is going to be measured
at a rate of thousands per second.

On Sat, Jun 3, 2017 at 3:13 PM, Clebert Suconic 
wrote:

> For the use case you're after. (No hard syncs). Mmap is a good candidate.
> Probably better.
>
>
> Libaio was engineered the case where you hard sync with callbacks from the
> Linux os
> On Sat, Jun 3, 2017 at 12:46 PM wangqinghuan <1095193...@qq.com> wrote:
>
> > hi clebertsuconic:
> > i read the blog
> > https://activemq.apache.org/artemis/docs/2.1.0/persistence.html
> > By default Apache ActiveMQ Artemis will try and use an AIO journal.But it
> > seems like that Mmap is also a good implemention.which one gives more
> > performance?
> >
> >
> >
> > --
> > View this message in context:
> > http://activemq.2283324.n4.nabble.com/why-AvtiveMq-is-slowly-than-Kafka-
> tp4726911p4726992.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
> --
> Clebert Suconic
>

Re: A question on RedeliveryPlugin Configuration

[Christopher Shannon]

You should be able to do in Java code if you have an embedded broker.  You
can get access to the Broker chain from the BrokerService object, get the
RedeliveryPlugin and then update the redeliveryPolicyMap.

BrokerService brokerService = new BrokerService();
//do configuration here
RedeliveryPlugin plugin =
brokerService.getBroker().getAdaptor(RedeliveryPlugin.class);
//update the map on the plugin

I don't think you can do it with just XML right now.  The only dynamic
stuff support with XML is here:
http://activemq.apache.org/runtime-configuration.html

On Sun, May 21, 2017 at 12:29 AM, snakorse <512979...@qq.com> wrote:

> Hi guys,
>
> I'm looking for a way to dynamically add redeliveryPolicy to the
> redeliveryPolicyEntries node of the RedeliveryPlugin. Is there any way to
> achieve this avoiding directly edit the activemq.xml and restart borker?
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/A-question-on-RedeliveryPlugin-Configuration-tp4726413.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Migrating storage from 5.10.0 to 5.14.5

[Christopher Shannon]

What kind of errors are you getting?  If it's related to data marshalling
then it could be because there was an Openwire upgrade (Openwire is the
format the messages are stored in) done in the KahaDB store between those
versions which could be causing your issue. I think there was also some
scheduler work done so not sure off the top of my head if that is the
problem without seeing the stack trace.

If you are simply copying over the journal files and trying to rebuild the
KahaDB index then it will fail as it will pick Openwire version 11 instead
of 6. You set the version manually using the storeOpenWireVersion
property.  See http://activemq.apache.org/kahadb.html.  If the index file
still exists (db.data) then KahaDB should be able to detect that it is an
old store and fall back automatically to the write openwire version.



On Fri, May 19, 2017 at 2:32 PM,  wrote:

> Good Day,
>
> I've been working on migrating servers and upgrading from 5.10.0
> to 5.14.5.
> We have a number of scheduled tasks and I want to preserve those along
> with other items in the queue. I tried moving the files in kahadb to the
> new server (after shutting down both servers), but have run into
> multiple errors which prevent the new server from starting.
> I am wondering what the appropriate way to migrate storage is. Should I
> attempt read all of the messages from the old queue and write them into
> the new queue? Has anyone else done this before?  It seems like this
> would be a useful utility.
>
> Thanks,
>
> Chris
>

Re: error in /admin/xml/queues.jsp

[Christopher Shannon]

This has been fixed as part of AMQ-6656 which AMQ-6685 duplicated.  The fix
will be part of 5.15.0 (and 5.14.6 if a release is done)

On Wed, May 24, 2017 at 10:22 AM, Adam Whitney 
wrote:

> one thing to note ... we were using the /admin/xml/queues.jsp page to get
> stats from ActiveMQ into splunk for monitoring and alerting. We've worked
> around the issue by using the jolokia endpoint, e.g.:
>
> /api/jolokia/read/org.apache.activemq:type=Broker,
> brokerName=*,destinationName=*,destinationType=Queue
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/error-in-admin-xml-queues-jsp-tp4726220p4726479.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: purge performance???

[Christopher Shannon]

How fast the messages get purged depend on many things such as how large
the messages are, if they are non-persistent, and if there is contention on
the Queue, and of course how fast your hardware is. The purge operation
works by paging in batches of messages at a time so if it has to go to disk
versus just in memory then it will take a little bit longer depending on
your disk performance.  Also if there are a lot of producers/consumers to a
Queue it will interfere with the purge as well as locks have to be obtained.

That being said, 10 thousand messages is not that many messages if they are
relatively small (no more than a couple KB) and in most situations I would
expect it to only take a few seconds, especially if they are in memory.  If
you have large messages (megabytes) then it will of course take a lot
longer.


On Fri, Apr 28, 2017 at 10:26 AM, pbCode  wrote:

> Hi,
>   I have a lot of messages in some DLQs.  These are in the order of 10
> thousand / DLQ!  Before I go and delete these from my production
> environment
> I wanted to know if theres anything I need to consider before I do it???
> ie
> performance.  As you can imagine I dont want to hit the purge button and
> then the CPU rocket through the roof!  I have tested it in my development
> environment by using the active mq web console to create 10 thousand
> messages and then purge them.  It was so quick it was unbelievable!  I was
> wondering why it was so quick, that maybe the 10 thousand messages that I
> created through the console  were deleted so quickly because the messages
> are effectively the same???  Any help will be appreciated.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nab
> ble.com/purge-performance-tp4725337.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: QueueSize == 0 && CursorMemoryUsage > 0 - is that a problem?

[Christopher Shannon]

Yes, memory usage should be 0 for a destination if there are no messages so
this seems like a bug.  There was another memory bug fixed more recently
but that only had to do with persistent messages when using concurrent
store and dispatch.  As you pointed out the best thing to do to help would
be to create a test case that can reproduce the issue but make sure you use
the latest version (5.14.4).

On Wed, Mar 15, 2017 at 7:01 AM,  wrote:

> Hi,
>
> I have an application using ActiveMQ 5.13.5 which uses non-persistent
> messages.  There is a queue which has several producers and a single
> consumer.
>
> At times I see the CursorMemoryUsage not being 0 despite the queue being
> empty.  When this application runs for a very long time,
> CursorMemoryUsage grows and this can become an issue with system memory
> usage.  My understanding might be wrong but is this a problem?
>
> At first this sounded like
> https://issues.apache.org/jira/browse/AMQ-6094 but this has apparently
> been fixed for this release.
>
> I've attached a jconsole view showing the issue.  When I invoked via JMX
> these operations they return:
>
> doesCursorHaveMessagesBuffered -> false
> cursorSize -> 0
> doesCursorHaveSpace -> 0
>
> On a different run, I had DEBUG enabled and I've seen these sort of
> lines confirming memory usage despite the queue being empty:
>
> 2017-03-15 21:47:55,624 [ActiveMQ
> BrokerService[cb01e0612bb1468d88828716182f7f39] Task-5] 214837 DEBUG
> org.apache.activemq.broker.region.Queue - queue://master-items-7.0,
> subscriptions=1, memory=0%, size=0, pending=0 toPageIn: 0, Inflight: 0,
> pagedInMessages.size 0, pagedInPendingDispatch.size 0, enqueueCount:
> 5518, dequeueCount: 5518, memUsage:28538
>
> Is this a bug?  I know I'll be asked for a test case, but I wanted to
> confirm it first before proceeding.
>
>
>
> --
> Cheers,
> David
>
>

[ANNOUNCE] Apache ActiveMQ 5.14.4 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.14.4
has been released and includes over 20 fixes and improvements.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338909

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5144-release.html

A big thanks to everyone who contributed to this release.

Re: ActiveMQ failures with strange exception "KahaDB failed to store to Journal" IOException: The parameter is incorrect

[Christopher Shannon]

I'm not sure what caused the exception when reading the index but the
behavior of the broker on IOException is defined by the IOExceptionHandler
that is configured on the broker.  Take a look at DefaultIOExceptionHandler
and all of the available options.  By default on IOException it will shut
down the broker and try and restart it.  It can be configured to ignore
IOExceptions or to disable the restart and just shutdown, or even to kill
the entire JVM, etc.

http://activemq.apache.org/configurable-ioexception-handling.html

As far as why the restart did not work I'm guessing the lock wasn't
released properly on shutdown for some reason.  5.10.0 is pretty old so I'm
not sure there have been any fixes for this already.  I personally set up
my brokers to exit the JVM on IOException and then I have some other
process restart the broker (puppet, etc) so that there is always a clean
JVM on broker start.


On Wed, Feb 22, 2017 at 7:45 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> Has anyone seen this before?
>
> After this exception the broker shuts down and is restarted by the wrapper
> but then we get "kahadb\lock could not be locked as lock is already held
> for this jvm.".
> So there are actually two problems. Why does the broker shut down at all
> and why is the restart not working?
>
> I would be happy about any feedback.
>
> Christian
>
> --
> 2017-01-30 03:56:26,910 | ERROR | KahaDB failed to store to Journal |
> org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Transport:
> tcp:///10.218.8.223:49837@61616
> java.io.IOException: The parameter is incorrect
> at java.io.RandomAccessFile.readBytes(Native Method)[:1.7.0_13]
> at java.io.RandomAccessFile.read(Unknown Source)[:1.7.0_13]
> at java.io.RandomAccessFile.readFully(Unknown Source)[:1.7.0_13]
> at java.io.RandomAccessFile.readFully(Unknown Source)[:1.7.0_13]
> at org.apache.activemq.util.RecoverableRandomAccessFile.readFul
> ly(RecoverableRandomAccessFile.java:75)[activemq-kahadb-stor
> e-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.page.PageFile.readPage
> (PageFile.java:878)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.page.Transaction$2.
> readPage(Transaction.java:456)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.page.Transaction$2.<
> init>(Transaction.java:447)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.page.Transaction.openI
> nputStream(Transaction.java:444)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.page.Transaction.load(
> Transaction.java:420)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.page.Transaction.load(
> Transaction.java:377)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.index.BTreeIndex.loadN
> ode(BTreeIndex.java:262)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.index.BTreeNode.getChi
> ld(BTreeNode.java:225)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.index.BTreeNode.getLea
> fNode(BTreeNode.java:676)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.index.BTreeNode.put(
> BTreeNode.java:369)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.index.BTreeIndex.put(
> BTreeIndex.java:189)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.MessageDatabase.updateIndex
> (MessageDatabase.java:1304)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.MessageDatabase$11.execute(
> MessageDatabase.java:1140)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.disk.page.Transaction.execu
> te(Transaction.java:779)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.MessageDatabase.process(
> MessageDatabase.java:1137)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.MessageDatabase$10.visit(
> MessageDatabase.java:1074)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.data.KahaAddMessageCommand.
> visit(KahaAddMessageCommand.java:241)[activemq-kahadb-
> store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.MessageDatabase.process(
> MessageDatabase.java:1071)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.MessageDatabase.store(Messa
> geDatabase.java:978)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.MessageDatabase.store(Messa
> geDatabase.java:958)[activemq-kahadb-store-5.10.0.jar:5.10.0]
> at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageSt
> ore.addMessage(Kah

Re: Cannot make multiple embedded MQTT brokers use different SSLContext

[Christopher Shannon]

Can you try creating each broker in a different thread in your tests?  The
issue I think is that in the SslContext class the ThreadLocal variable is
static so it is going to be shared and interfere when you try to configure
2 brokers in the same JVM and the same thread is creating transports.  This
may not work either and there might need to be some additional work here
done to fix this.

On Fri, Feb 10, 2017 at 10:07 AM, Dale Green 
wrote:

> Hi all,
> I don't know if this is a bug or there is a specific reason to be
> implemented in that way. So:
>
> Goal:
>
> Start 2 embedded MQTT brokers for integration tests purposes. Both brokers
> have different SSLContexts with different keystores with different
> certificates.
>
> Expected Result:
>
> Both brokers use different certificates.
>
> Actual Result:
>
> Both brokers use the same certificate, because both use the SSLContext of
> the second broker (the most recently set up and started broker).
>
> Version: 5.14.3
>
> The actual problem (not sure if this is the only one):
>
> The anonymous class created in
> MQTTNIOSSLTransportFactory::createTcpTransportServer(...) uses
> MQTTNIOSSLTransportFactory::context, which is incorrect IMO. The right
> context is NIOSSLTransportServer::context, but it is never used, because
> it
> is private.
>
> Any workarounds for this?
>
> Thanks!
>

Re: kahadb index file larger than journal file

[Christopher Shannon]

The broker will continue to work just fine and the index deletion is not
required.  You only need to delete the index file if you want to reclaim
the wasted space otherwise the fix will at least prevent the issue from
getting worse.

On Thu, Feb 2, 2017 at 8:27 AM, Tim Bain  wrote:

> Chris,
>
> What will be the behavior for anyone who doesn't delete their index after
> upgrading? Will the broker continue to function as-is in that scenario, or
> is this a required procedure during an upgrade beyond 5.14.3?
>
> Tim
>
> On Feb 2, 2017 5:02 AM, "Christopher Shannon" <
> christopher.l.shan...@gmail.com> wrote:
>
> > Sorry for taking a while to get back to you.
> >
> > Based on your originally message and after analyzing some index files I
> > have actually discovered a bug with KahaDB that causes the index file to
> > grow too large when things like out of memory errors occur or any unclean
> > shutdown.  On recovery the free pages in the index file are not being
> > properly tracked which is leading to excessive index file usage.  So this
> > is probably the issue that you are seeing.  I will be fixing this in
> > version 5.14.4.  Upon upgrade you will need to delete the old index and
> > have it be rebuilt and then going forward it should work as intended.
> You
> > can track the status of the bug here:
> > https://issues.apache.org/jira/browse/AMQ-6590
> >
> > In terms of the in memory cache, only a fixed number of pages are cached.
> > The default is 10 thousand pages and each page is 4KB.  So roughly 40 MB
> of
> > memory will be used at most.  If the number of pages in use grows beyond
> > that then the cache will swap pages based on the defined eviction
> > strategy.  You can increase the number of pages in memory (which would
> help
> > performance at the cost of eating up memory) by tweaking the
> indexCacheSize
> > value of KahaDB.  See http://activemq.apache.org/kahadb.html for more
> > info.
> >
> > On Tue, Jan 24, 2017 at 11:00 PM, Scorpio  wrote:
> >
> > > Christopher:
> > >
> > >
> > > Thank you for your explanation!
> > >
> > > Hope there would be other proper ways to shrink the index file in
> future
> > > ActiveMQ releases.
> > >
> > > Once we monitored that our broker is killed by system due to "out of
> > > memory".
> > >
> > > I know that meta cache in memory will be synced into index file at
> > > checking points. _*Does this mean there is as much memory as  the
> > > db.data file being used?*_
> > >
> > > Even though our broker is idle,  we still find that it uses up much
> > > memory. Could they be relevant associated? Thanks
> > >
> > >
> > > Kind regards,
> > >
> > > Scorpio
> > >
> > > On 2017/1/24 20:16, christopher.l.shannon [via ActiveMQ] wrote:
> > > > The index grows based off the amount of data it tracks in the
> journal,
> > > > but doesn't shrink.  This means if you had a lot of data in your
> > > > journal at some point (several gigabytes, etc) then the index would
> > > > have grown in size with enough page files to keep track of all of the
> > > > data.  This is usually not an issue because the index size generally
> > > > stabilizes at some point relative to the work load of the broker.
>  If
> > > > you really want to shrink it the only way right now is to stop the
> > > > broker, delete the index and restart so it does a replay and rebuilds
> > > > the index but the size would just grow again as messages flow.
> > > >
> > > > On Mon, Jan 23, 2017 at 8:06 PM, Scorpio <[hidden email]
> > > > > wrote:
> > > >
> > > > > Hi, All,
> > > > >
> > > > > In my activemq instance, I find that the kahadb index file is
> larger
> > > > than
> > > > > the journal file.
> > > > >
> > > > > As far as I know, /db.data/ is the meta store, index for the
> journal
> > > > file,
> > > > > which should means it is much smaller than the journal file.
> > > > However, it
> > > > > does not look like that. The index file seems to keep growing while
> > the
> > > > > journal file is rotated. Do I miss something? Thanks.
> > > > >
> > > > > Log attached:
> > > > > root@host:~/run/apache-activemq-5.13.1/data/kahadb# du * -sh
> > > > > 16M db-16.log
&g

Re: kahadb index file larger than journal file

[Christopher Shannon]

Sorry for taking a while to get back to you.

Based on your originally message and after analyzing some index files I
have actually discovered a bug with KahaDB that causes the index file to
grow too large when things like out of memory errors occur or any unclean
shutdown.  On recovery the free pages in the index file are not being
properly tracked which is leading to excessive index file usage.  So this
is probably the issue that you are seeing.  I will be fixing this in
version 5.14.4.  Upon upgrade you will need to delete the old index and
have it be rebuilt and then going forward it should work as intended.  You
can track the status of the bug here:
https://issues.apache.org/jira/browse/AMQ-6590

In terms of the in memory cache, only a fixed number of pages are cached.
The default is 10 thousand pages and each page is 4KB.  So roughly 40 MB of
memory will be used at most.  If the number of pages in use grows beyond
that then the cache will swap pages based on the defined eviction
strategy.  You can increase the number of pages in memory (which would help
performance at the cost of eating up memory) by tweaking the indexCacheSize
value of KahaDB.  See http://activemq.apache.org/kahadb.html for more info.

On Tue, Jan 24, 2017 at 11:00 PM, Scorpio  wrote:

> Christopher:
>
>
> Thank you for your explanation!
>
> Hope there would be other proper ways to shrink the index file in future
> ActiveMQ releases.
>
> Once we monitored that our broker is killed by system due to "out of
> memory".
>
> I know that meta cache in memory will be synced into index file at
> checking points. _*Does this mean there is as much memory as  the
> db.data file being used?*_
>
> Even though our broker is idle,  we still find that it uses up much
> memory. Could they be relevant associated? Thanks
>
>
> Kind regards,
>
> Scorpio
>
> On 2017/1/24 20:16, christopher.l.shannon [via ActiveMQ] wrote:
> > The index grows based off the amount of data it tracks in the journal,
> > but doesn't shrink.  This means if you had a lot of data in your
> > journal at some point (several gigabytes, etc) then the index would
> > have grown in size with enough page files to keep track of all of the
> > data.  This is usually not an issue because the index size generally
> > stabilizes at some point relative to the work load of the broker.   If
> > you really want to shrink it the only way right now is to stop the
> > broker, delete the index and restart so it does a replay and rebuilds
> > the index but the size would just grow again as messages flow.
> >
> > On Mon, Jan 23, 2017 at 8:06 PM, Scorpio <[hidden email]
> > > wrote:
> >
> > > Hi, All,
> > >
> > > In my activemq instance, I find that the kahadb index file is larger
> > than
> > > the journal file.
> > >
> > > As far as I know, /db.data/ is the meta store, index for the journal
> > file,
> > > which should means it is much smaller than the journal file.
> > However, it
> > > does not look like that. The index file seems to keep growing while the
> > > journal file is rotated. Do I miss something? Thanks.
> > >
> > > Log attached:
> > > root@host:~/run/apache-activemq-5.13.1/data/kahadb# du * -sh
> > > 16M db-16.log
> > > 1.2Gdb.data
> > > 3.2Mdb.redo
> > > 4.0Klock
> > > root@host:~/run/apache-activemq-5.13.1/data/kahadb#
> > >
> > > Kind regards,
> > > Scorpio
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > http://activemq.2283324.n4.nabble.com/kahadb-index-file-
> larger-than-journal-file-tp4721284.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
> >
> > 
> > If you reply to this email, your message will be added to the
> > discussion below:
> > http://activemq.2283324.n4.nabble.com/kahadb-index-file-
> larger-than-journal-file-tp4721284p4721300.html
> >
> > To start a new topic under ActiveMQ - User, email
> > ml-node+s2283324n2341805...@n4.nabble.com
> > To unsubscribe from kahadb index file larger than journal file, click
> > here
> >  unsubscribe_by_code&node=4721284&code=bnlAeGlhbmdqaWFiYW8uY29tfDQ3Mj
> EyODR8MTkzNzMzOTQ5NQ==>.
> > NAML
> >  NamlServlet.jtp?macro=macro_viewer&id=instant_html%
> 21nabble%3Aemail.naml&base=nabble.naml.namespaces.
> BasicNamespace-nabble.view.web.template.NabbleNamespace-
> nabble.view.web.template.NodeNamespace&breadcrumbs=
> notify_subscribers%21nabble%3Aemail.naml-instant_emails%
> 21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> >
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/kahadb-index-file-larger-than-journal-file-
> tp4721284p4721315.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: kahadb index file larger than journal file

[Christopher Shannon]

The index grows based off the amount of data it tracks in the journal,
but doesn't shrink.  This means if you had a lot of data in your
journal at some point (several gigabytes, etc) then the index would
have grown in size with enough page files to keep track of all of the
data.  This is usually not an issue because the index size generally
stabilizes at some point relative to the work load of the broker.   If
you really want to shrink it the only way right now is to stop the
broker, delete the index and restart so it does a replay and rebuilds
the index but the size would just grow again as messages flow.

On Mon, Jan 23, 2017 at 8:06 PM, Scorpio  wrote:
> Hi, All,
>
> In my activemq instance, I find that the kahadb index file is larger than
> the journal file.
>
> As far as I know, /db.data/ is the meta store, index for the journal file,
> which should means it is much smaller than the journal file. However, it
> does not look like that. The index file seems to keep growing while the
> journal file is rotated. Do I miss something? Thanks.
>
> Log attached:
> root@host:~/run/apache-activemq-5.13.1/data/kahadb# du * -sh
> 16M db-16.log
> 1.2Gdb.data
> 3.2Mdb.redo
> 4.0Klock
> root@host:~/run/apache-activemq-5.13.1/data/kahadb#
>
> Kind regards,
> Scorpio
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/kahadb-index-file-larger-than-journal-file-tp4721284.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Can you change the kahadb journal file size between broker starts

[Christopher Shannon]

Yes, I would expect maxFileLength should only be used on file
allocation.  My expectation is that the journal file length should be
able to be changed in between restarts and have everything work.  In
the past I have increased the size many times before without issues so
I'm not sure if the second use case is an issue (KahaDB might handle
it elsewhere) but the first portion of the startup code seems like it
might be a problem and need to be fixed.

Can you create a new Jira? I should have time to take a peak at this
next week to verify if a fix is needed.  It should be pretty
straightforward to write a quick unit test to check both scenarios
(length increasing and decreasing) to show if there is an issue and
validate any fix.

On Fri, Jan 20, 2017 at 9:58 AM, jahlborn  wrote:
> So, i was poking around to see the actual implications of changing the max
> journal file length, and i must say, the code doesn't seem to back up the
> claim that it is a safe thing to do.
>
> https://fisheye.apache.org/browse/activemq-6/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal/Journal.java?hb=true#to310
>
> This is the startup code.  it attempts to adjust the total length by shaving
> off an unused portion of the final data file.  if you have made the
> maxFileLength smaller since the last run, and you have actual data in the
> last journal file which is after the new maxFileLength, then this
> computation will incorrectly return a negative value.  my suspicion is that
> the length of the last data file should be used here instead of
> maxFileLength.
>
> https://fisheye.apache.org/browse/activemq-6/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal/Journal.java?hb=true#to867
>
> likewise, this code attempts to handle adjustments to maxFileLength since
> the journal file was created, but i think it again fails.  if the
> maxFileLength has been increased since the data file was created, this would
> seem to be setting an offset which is past the length of the current data
> file.  again, it seems like the length of the data file should be used
> directly.
>
> in general, in order for this to work correctly, the maxFileLength should
> only be used for code which is creating new files.  all the other code
> should be solely relying on the size of the existing file, right?
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Can-you-change-the-kahadb-journal-file-size-between-broker-starts-tp4721155p4721252.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Can you change the kahadb journal file size between broker starts

[Christopher Shannon]

Yes, that is safe to do.  The journalMaxFileLength value is only used
for allocating new journal files and doesn't have any effect on
previous files.  If you change the value the broker will continue to
work fine and be able to read the old files but all new allocated
files will be the new size.

On Tue, Jan 17, 2017 at 4:28 PM, jahlborn  wrote:
> I was wondering if it was safe to change the kahadb "journalMaxFileLength"
> cofiguration value between restarts of a broker.  in other words, will the
> broker function correctly with different journal files being different
> sizes?
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Can-you-change-the-kahadb-journal-file-size-between-broker-starts-tp4721155.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: HA in Master/Slave with shared mKahaDb not really HA because of slow failover?

[Christopher Shannon]

Which version are you using? Normally on start up the broker should
not need to replay the entire journal if the index already exists.  On
startup the broker tries to determine the last in doubt position from
the index and only replay from that point.  With HA I would expect
this to work the same way as the shared directory contains the index
and journal so I'm wondering if something was detected wrong with the
index to trigger the full replay.

It might help to turn on debug or trace logging to see what if there
is some more information on why there is a full journal replay.  The
two classes to enable logging on would be
org.apache.activemq.store.kahadb.MessageDatabase and
org.apache.activemq.store.kahadb.KahaDBStore

On Tue, Jan 17, 2017 at 2:51 AM, Johannes F. Knauf
 wrote:
> Hi,
>
> I filed a bug with JIRA about HA in Master/Slave mode with shared mKahaDb not 
> being really HA
> because of extremely slow failover.  Depending on the message load startup 
> time of the Slave when
> becoming Master can be seriously slowed down (in the order of minutes) which 
> yields an extremely
> slow failover and hence a phase of unavailability of the broker.
>
> https://issues.apache.org/jira/browse/AMQ-6564
>
> Timothy Bish suggested to discuss this issue first here on the Users Mailing 
> List. So I gladly repost.
>
> ---
>
> Consider the following scenario:
> * AMQ Host A and Host B are configured exactly the same
> * Host A and Host B share a common filesystem storage for their (m)kahadb in 
> order to create HA as
> described in http://activemq.apache.org/shared-file-system-master-slave.html
> * high-traffic scenario, where at each point in time quite some amount of 
> messages is still in each
> queue
>
> Expected:
> Given Host A is current master and Host B is polling for the lock every 10 
> seconds (default),
> when Host A is going down,
> then Host B should be able to serve producer enqueue requests after 10 
> seconds + some microseconds
> at max.
>
> Reality:
> Host B needs to replay the whole journals before being available to accept 
> new messages again. This
> can take a long time, especially if consistency checks are required. This 
> means Master/Slave with
> shared FS is not really providing HA.
>
> It is perfectly understandable, that for consumers the failover takes that 
> long. They can only
> continue receiving messages, when all journals have been read. Otherwise 
> order of messages would be
> destroyed.
>
> For producers this is not the case, as AMQ could just create a fresh journal 
> file and start
> appending immediately. Am I wrong?
>
> Also it seems, that each kahaDB in an mKahaDB is checked in sequence, so that 
> in worst case even
> less filled queues are not available before everything is checked completely.
>
> Long unavailability for producers is unacceptable in most scenarios. It means 
> that all producing
> clients have to take a serious amount of effort to protect against these 
> scenarios in order not to
> lose messages (buffering, etc.). Or is there a best practise workaround?
>
>
> ---
>
> Any ideas why it is like that?
>
> Thanks,
> Johannes

Re: Ignoring sub command log messages

[Christopher Shannon]

It's hard to say an exact time frame.  Finished new features would be
the driving force behind a 5.15.0 release as bug fixes are already
backported but right now there hasn't been much done to justify a
5.15.0 release.  Most work has been focused on Artemis but I would say
that mid year sounds about right to me.

On Wed, Jan 11, 2017 at 9:24 AM, xabhi  wrote:
> Thanks christopher for the explanation. This makes sense. What are the
> timelines for ActiveMQ v5.15.0 release - mid year? I am asking because I
> plan to upgrade to 5.14.3 and if this issue will be handled well in 5.15.0 i
> would love to upgrade directly to 5.15.0.
>
> Thanks,
> Abhi
>
>
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Ignoring-sub-command-log-messages-tp4720928p4720977.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Ignoring sub command log messages

[Christopher Shannon]

Yes if you have a ton of data on a durable subscription and delete the
durable it tends to write a large temp file because of the kahadb
index.  Even though the temp file should be deleted automatically
after deletion this is certainly not ideal.

Right now there isn't really a good way to discard all of the messages
other than the current deletion.  I've been working on a prototype for
purging a durable subscription that works similar to how purge works
for a Queue in that it iterates over the messages and acks them one by
one so it doesn't blow memory trying to delete them all at once.  I
haven't added it to the broker yet but it seems to work ok in my local
testing and is something I can probably add to the 5.15.0 release.

Also in regards to the inactive durable sub using up all of the
memory, that's something else I want to improve in 5.15.0.  If you
look at the discussion from
https://issues.apache.org/jira/browse/AMQ-4467 from the last couple of
days this issue came up.  One solution discussed is purging an
inactive destination from the in memory cache (but not from the store)
to save memory for other destinations.

On Wed, Jan 11, 2017 at 8:19 AM, xabhi  wrote:
> Hi,
>
> Yes these log messages appeared at the startup only. I had faced an issue
> where activemq dumped  7gb file - tx-14693130-1483907222896.tmp in one of
> the mkahadb directories when i tried to destroy a durable topic consumer
> which was inactive for quite some time and had hit the memory threshold of
> 70% (this was causing activemq to be unresponsive). I removed this file
> manually and when failover switch happened I saw above log messages in log
> file.
>
> Is there a clean way to discard all the messages in durable topic
> subscription without dumping a 7gb file?
>
> Thanks,
> Abhishek
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Ignoring-sub-command-log-messages-tp4720928p4720974.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Ignoring sub command log messages

[Christopher Shannon]

Did this happen while replaying the journal?  This message means that
an acknowledgement was processed in the journal that doesn't have a
matching message.  This log message would typically print out if you
were replaying the journal from the beginning to rebuild the index
because it's possible that the original journal files that contained
those messages have already been garbage collected but the journal
file that contains the acks hasn't been garbage collected yet.  If
this is the case then this is normal and nothing to worry about (which
is why it's a debug statement only)

On Tue, Jan 10, 2017 at 2:25 AM, xabhi  wrote:
> Hi,
>
> I saw below log messages in my ActiveMQ instance's logs. When does this
> happen and what effects can it have?
>
> [20170108 15:29:19.584 EST (main)
> org.apache.activemq.store.kahadb.MessageDatabase#updateIndex 1405 DEBUG] -
> no message sequence exists for id:
> ID:geneva13.nyc.43322-1482156880537-3:13196:1:1:3 and sub:
> gear-munshi-geneva.gear.sync.listener.GelbaseGenevaMessageListener
> [20170108 15:29:19.584 EST (main)
> org.apache.activemq.store.kahadb.MessageDatabase#updateIndex 1405 DEBUG] -
> no message sequence exists for id:
> ID:geneva13.nyc.43322-1482156880537-3:13196:1:1:4 and sub:
> gear-munshi-geneva.gear.sync.listener.GelbaseGenevaMessageListener
> [20170108 15:29:19.584 EST (main)
> org.apache.activemq.store.kahadb.MessageDatabase#updateIndex 1405 DEBUG] -
> no message sequence exists for id:
> ID:geneva13.nyc.43322-1482156880537-3:1:2:1:5946 and sub:
> gear-munshi-listener:geneva.gear.sync.listener.GelbaseGenevaMessageListener
> [20170108 15:29:19.585 EST (main)
> org.apache.activemq.store.kahadb.MessageDatabase#process 1047 DEBUG] -
> ignoring add sub command during recovery replay:destination {
>   type: TOPIC
>   name: geneva.loader.messageTopic
> }
> subscriptionKey:
> gear-munshi-listener:geneva.gear.sync.listener.GelbaseGenevaMessageListener
> retroactive: false
> subscriptionInfo: org.apache.activemq.protobuf.Buffer@ffc5
>
> [20170108 15:29:19.585 EST (main)
> org.apache.activemq.store.kahadb.MessageDatabase#process 1047 DEBUG] -
> ignoring add sub command during recovery replay:destination {
>   type: TOPIC
>   name: gear.tdpBundleCompletionTopic
> }
> subscriptionKey:
> post-tdp-bundle-listener:geneva.gear.sync.listener.PostTdpMessageListener
> retroactive: false
> subscriptionInfo: org.apache.activemq.protobuf.Buffer@ffea
>
>
> Thanks,
> Abhi
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Ignoring-sub-command-log-messages-tp4720928.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

[ANNOUNCE] Apache ActiveMQ 5.14.3 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.14.3
has been released and includes several fixes and improvements.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338822

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5143-release.html

A big thanks to everyone who contributed to this release.

Re: LevelDB vs KahaDB for master/slave Zookeeper setup

[Christopher Shannon]

There are currently no plans to revisit KahaDB replication that I know of.
But contributions are welcome so it's always possible someone could pick it
up.  At this point the main focus has become Artemis since that already
supports replication.

On Wed, Dec 21, 2016 at 12:22 PM, mlange  wrote:

> Another thing:
>
> If you need a master/slave configuration... You may want to check out
> Apache
> Artemis, which does "store replication"
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nab
> ble.com/LevelDB-vs-KahaDB-for-master-slave-Zookeeper-setup-t
> p4720633p4720699.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: How to retrieve the SSL protocol and cipher suites usedin ActiveMQCOnnection

[Christopher Shannon]

Unfortunately it is a bit convoluted to do this right now as you need
to get access to the SSLSocket that is part of the connection which
isn't exposed through the API so you need to use reflection to get
access to the Socket.  But the following is an example that should
work:

ActiveMQConnection connection = (ActiveMQConnection)
activeMQSslConnectionFactory.createConnection();
TcpTransport tcpTransport =
connection.getTransport().narrow(TcpTransport.class);
Field socketField = TcpTransport.class.getDeclaredField("socket");
socketField.setAccessible(true);

Socket socket = (Socket) socketField.get(tcpTransport);
if (socket instanceof SSLSocket) {
SSLSocket sslSocket = (SSLSocket)socket;
System.out.println("SSL/TLS Protocol: " +
sslSocket.getSession().getProtocol());
System.out.println("Cipher Suite: " +
sslSocket.getSession().getCipherSuite());
}

On Sun, Dec 18, 2016 at 7:41 PM, rmkreddy  wrote:
> Hello,
>
> I would like to retrieve the SSL/TLS protocol used and the cipher suite used
> when a secure AciveMQConnection is established. I do not find any
> appropriate api to find the same. Here is the sample code which I am using
> to connect to ActiveMQ.
>
> ActiveMQSslConnectionFactory sslConnectionFactory = new
> ActiveMQSslConnectionFactory("ssl://ActiveqMQIP:61617");
> sslConnectionFactory.setKeyStore(new
> File("C:\\users\\user\\desktop\\client.ks").toURI().toString());
> sslConnectionFactory.setTrustStore(new
> File("C:\\users\\user\\desktop\\client.ts").toURI().toString());
> sslConnectionFactory.setKeyStorePassword("test");
> sslConnectionFactory.setTrustStorePassword("test");
> connection = sslConnectionFactory.createConnection();
>
>
> I am able to connect to activemq successfully, create sessions/topics/queues
> and do all the needed operations. But I do not find any way to retrieve the
> protocol used(TLS or TLSv1.1 or TLSv1.2) and the ciphersuite used. Is there
> any way/api to find the same?
>
> Regards,
> Mahesh
>
>
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/How-to-retrieve-the-SSL-protocol-and-cipher-suites-usedin-ActiveMQCOnnection-tp4720573.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Custom code to browse messages in the message store?

[Christopher Shannon]

The transaction you are referring to is a transaction on the KahaDB
index and a new one will be created by KahaDB when calling that method
so you don't need to worry about it.  In terms of statefulness, you
are correct that the order index tracks state of where it left off.
But I believe it is safe to use the recover() method (which always
resets the cursor and starts at the beginning) as there are things
like duplicate detection in place so it should be able to handle it.

In fact, if you call browse() on a Topic from JMX it will eventually
end up delegating to the recover method on the Topic Store and it will
return up to the number of messages of the browse page size so it has
been designed to be called multiple times because it will be called
every time you call browse().  Here is how it is used and might be a
good example for basing your code off of:
https://github.com/apache/activemq/blob/activemq-5.14.2/activemq-broker/src/main/java/org/apache/activemq/broker/region/Topic.java#L638
 For recoverNextMessages I don't remember if it would work or not
without taking a closer look.

Unfortunately I don't think there is really any other methods right
now to try and iterate over the messages in the store. The best thing
to do would be to write a quick test and see if it works for you.

On Fri, Dec 16, 2016 at 3:26 PM, jahlborn  wrote:
> So, digging into the message store recoverNextMessages() code, it's tough to
> tell what is going in in terms of statefulness.  That method certainly seems
> like it would get me the information that i'm after.  two concerns: 1. it
> looks to be expecting an existing Transaction (maybe i already have one in
> place since i'm working off of an existing session). 2.
> "recoverNextMessages" seems to imply that it's basing the notion of "next"
> off of current state and calling this method will change that state.  do i
> need to do something with the store state to ensure that i don't mess up
> this state for normal message consumption?
>
> thanks for your help so far!
>
>
> christopher.l.shannon wrote
>> You should be able to implement your own MessageRecoveryListener and
>> use the recover() or recoverNextMessages() methods on the MessageStore
>> interface.  The MessageStore object is part of the region Queue (it is
>> inherited from the parent BaseDestination class)
>> http://activemq.apache.org/maven/apidocs/org/apache/activemq/store/MessageStore.html
>>
>> Calling that method will iterate over each message in the store, load
>> it into memory and then and pass it to the MessageRecoveryListener
>> that you provide.  If you are using KahaDB then calling these methods
>> will lock the index and prevent other writes/reads from the store
>> while executing the method.
>>
>> On Thu, Dec 15, 2016 at 11:09 AM, jahlborn <
>
>> jahlborn@
>
>> > wrote:
>>> We have activemq embedded in our product.  Since it runs in the same jvm,
>>> we
>>> have various resource limits in place.  These limits make the browsing
>>> functionality somewhat less than ideal (you can only read so many
>>> messages
>>> in a large queue).  I was wondering if someone who has deeper knowledge
>>> of
>>> activemq could suggest a way to read messages directly from the data
>>> store
>>> (or some other way to do unbounded browsing which doesn't use up all
>>> system
>>> memory).
>>>
>>> I already attempted this a bit myself by adding a method to the region
>>> Queue
>>> for first pulling from the "paged in" messages, and then directly from
>>> the
>>> "PendingMessageCursor messages" to read messages.  However, despite the
>>> fact
>>> that the cursor is backed by the message store, it still seems to want to
>>> "page in" messages, and also abides by the resource limits.  (i was
>>> borrowing code from Queue.getMessage(String id)).
>>>
>>> Is there any way to "bypass" the "paging in" logic and just read messages
>>> directly from the message store?  i'm okay with this being "slow", i'd
>>> prefer to have a solution which works slowly rather than no solution at
>>> all...
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://activemq.2283324.n4.nabble.com/Custom-code-to-browse-messages-in-the-message-store-tp4720423.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Custom-code-to-browse-messages-in-the-message-store-tp4720423p4720542.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Custom code to browse messages in the message store?

[Christopher Shannon]

You should be able to implement your own MessageRecoveryListener and
use the recover() or recoverNextMessages() methods on the MessageStore
interface.  The MessageStore object is part of the region Queue (it is
inherited from the parent BaseDestination class)
http://activemq.apache.org/maven/apidocs/org/apache/activemq/store/MessageStore.html

Calling that method will iterate over each message in the store, load
it into memory and then and pass it to the MessageRecoveryListener
that you provide.  If you are using KahaDB then calling these methods
will lock the index and prevent other writes/reads from the store
while executing the method.

On Thu, Dec 15, 2016 at 11:09 AM, jahlborn  wrote:
> We have activemq embedded in our product.  Since it runs in the same jvm, we
> have various resource limits in place.  These limits make the browsing
> functionality somewhat less than ideal (you can only read so many messages
> in a large queue).  I was wondering if someone who has deeper knowledge of
> activemq could suggest a way to read messages directly from the data store
> (or some other way to do unbounded browsing which doesn't use up all system
> memory).
>
> I already attempted this a bit myself by adding a method to the region Queue
> for first pulling from the "paged in" messages, and then directly from the
> "PendingMessageCursor messages" to read messages.  However, despite the fact
> that the cursor is backed by the message store, it still seems to want to
> "page in" messages, and also abides by the resource limits.  (i was
> borrowing code from Queue.getMessage(String id)).
>
> Is there any way to "bypass" the "paging in" logic and just read messages
> directly from the message store?  i'm okay with this being "slow", i'd
> prefer to have a solution which works slowly rather than no solution at
> all...
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Custom-code-to-browse-messages-in-the-message-store-tp4720423.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Using embedded and standalone, switching on the fly.

[Christopher Shannon]

Everything should resume and continue to process messages already in
KahaDB.  It won't overwrite them.  Essentially you should not notice
any difference switching between the two modes because there's nothing
different between a standalone version and embedded version except
that the standalone version uses Spring configuration and a Spring
context to create the BrokerService instead of manually doing it in
embedded mode but the end result is the same.

On Mon, Dec 12, 2016 at 12:34 PM, appy  wrote:
> The configuration is same; if there are some messages in the queue when I
> switch, what will be the action of embedded to standalone i.e. will the
> standalone version allow the process to consume the messages or will it
> overwrite them?
>
> Delivery mode is set to PERSISTENT; hence I wish to know what will be the
> behavior of KahaDB?
>
> Thanks for the reply.
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Using-embedded-and-standalone-switching-on-the-fly-tp4720120p4720193.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Using embedded and standalone, switching on the fly.

[Christopher Shannon]

You should be able to switch without an issue as long as your
configuration is the same between your XML config for standalone and
and your embedded config.

On Mon, Dec 12, 2016 at 3:42 AM, appy  wrote:
> Hello,
>
> I am using activeMQ embedded currently and would like to switch to the
> standalone version. Can I use both of them simultaneously; switching in
> between them on the fly?
>
> How will this affect KahaDB if the Queues and Topics are the same?
>
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Using-embedded-and-standalone-switching-on-the-fly-tp4720120.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Is BrokerFilter a "blocking" interceptor?

[Christopher Shannon]

Yes, it is blocking.  The BrokerFilter class implements Broker and
simply delegates to the parent Broker so if whatever you are doing is
stuck then processing won't continue.  If you were to print out a
stacktrace from inside one of those methods you will see that there
are many BrokerFilter implementations in the chain already to add in
various behavior to the broker (logging, authentication, etc)

On Mon, Dec 12, 2016 at 11:23 AM, Devlin  wrote:
> We're experimenting with BrokerFilter to capture detailed info of producer,
> consumer, message headers, etc., for logging and analysis, and want to be
> very careful to avoid delaying or blocking the broker.
>
> If a broker interceptor, for whatever reason, got stuck, would that block a
> broker thread from continuing?
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Is-BrokerFilter-a-blocking-interceptor-tp4720182.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

[ANNOUNCE] CVE-2016-6810: ActiveMQ Web Console - Cross-Site Scripting

[Christopher Shannon]

The following security vulnerability was reported against Apache
ActiveMQ 5.14.1 and older versions.

Please check the following document and see if you’re affected by the issue.

http://activemq.apache.org/security-advisories.data/CVE-2016-6810-announcement.txt

Apache ActiveMQ 5.14.2 has been released with appropriate fixes and is
available for upgrade.

[ANNOUNCE] Apache ActiveMQ 5.14.2 Released

[Christopher Shannon]

Hi everyone,

The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.14.2 has
now been released and includes over 30 bug fixes and improvements.

A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338329

The Wiki page for the release is here:
http://activemq.apache.org/activemq-5142-release.html

A big thanks to everyone who contributed to this release.

Re: Regarding replicated DB store solutions

[Christopher Shannon]

You probably figured this out but to be clear in my previous message in the
first paragraph I meant to say that LevelDB was "intended to be the follow
on to KahaDB", and not "was intended to be the follow on to ActiveMQ" as it
currently states.

On Wed, Dec 7, 2016 at 3:26 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> The issue with the current LevelDB implementation is that it is not
> stable.  There have been numerous bugs reported against it that have not
> been fixed including corruption problems so it is not really usable in a
> production environment. Originally it was intended to be the follow on to
> ActiveMQ but it has basically been abandoned as there hasn't been anyone
> who has shown any interest the past couple of years to fix it up so it has
> been deprecated.
>
> The link you have found is old as originally replication support was
> planned for KahaDB but that was migrated to LevelDB instead and KahaDB does
> not currently have replication.  However if you are ok with a shared file
> system solution for high availability then you can use KahaDB.
> http://activemq.apache.org/shared-file-system-master-slave.html .
>
> If you are interested in replication support I would take a look at
> Artemis (https://activemq.apache.org/artemis/), which you alluded to by
> mentioning the ActiveMQ sibling project.  Artemis supports replication and
> is currently under heavy development with the goal to ultimately have it
> replace the current 5.x broker if/when the community decides it is ready.
> So I would give it a shot and see if it works for you if you need a
> replication.  I doubt that there will ever be replication added to KahaDB
> as most of the active development is going towards Artemis at this point.
>
> On Mon, Dec 5, 2016 at 10:15 AM, JR John Roach (5298) 
> wrote:
>
>> Hi,
>>
>> We need a high availability solution. To this extent I did some research
>> on the usage of ActiveMQ.
>>
>> According to this documentation (http://activemq.apache.org/re
>> plicated-leveldb-store.html) LevelDB store is no longer supported.
>> Wasn’t LevelDB newer DB solution? Wasn’t it going to replace KahaDB?
>>
>> According to this documentation (http://activemq.apache.org/ka
>> hadb-master-slave.html) KahaDB replication is not currently supported.
>> Will it ever be? Also it looks like the documentation is broken, could it
>> be fixed?
>>
>> If replicated DB is not supported what is the supported high availability
>> solution that ActiveMQ has that can;
>>
>>   *   Support multiple slaves
>>   *   Replication of queues
>>
>> ?
>>
>> Could the ActiveMQ sibling be the solution?
>>
>> Thank you for any information you can provide.
>>
>>
>>
>

Re: Regarding replicated DB store solutions

[Christopher Shannon]

The issue with the current LevelDB implementation is that it is not
stable.  There have been numerous bugs reported against it that have not
been fixed including corruption problems so it is not really usable in a
production environment. Originally it was intended to be the follow on to
ActiveMQ but it has basically been abandoned as there hasn't been anyone
who has shown any interest the past couple of years to fix it up so it has
been deprecated.

The link you have found is old as originally replication support was
planned for KahaDB but that was migrated to LevelDB instead and KahaDB does
not currently have replication.  However if you are ok with a shared file
system solution for high availability then you can use KahaDB.
http://activemq.apache.org/shared-file-system-master-slave.html .

If you are interested in replication support I would take a look at Artemis
(https://activemq.apache.org/artemis/), which you alluded to by mentioning
the ActiveMQ sibling project.  Artemis supports replication and is
currently under heavy development with the goal to ultimately have it
replace the current 5.x broker if/when the community decides it is ready.
So I would give it a shot and see if it works for you if you need a
replication.  I doubt that there will ever be replication added to KahaDB
as most of the active development is going towards Artemis at this point.

On Mon, Dec 5, 2016 at 10:15 AM, JR John Roach (5298)  wrote:

> Hi,
>
> We need a high availability solution. To this extent I did some research
> on the usage of ActiveMQ.
>
> According to this documentation (http://activemq.apache.org/
> replicated-leveldb-store.html) LevelDB store is no longer supported.
> Wasn’t LevelDB newer DB solution? Wasn’t it going to replace KahaDB?
>
> According to this documentation (http://activemq.apache.org/
> kahadb-master-slave.html) KahaDB replication is not currently supported.
> Will it ever be? Also it looks like the documentation is broken, could it
> be fixed?
>
> If replicated DB is not supported what is the supported high availability
> solution that ActiveMQ has that can;
>
>   *   Support multiple slaves
>   *   Replication of queues
>
> ?
>
> Could the ActiveMQ sibling be the solution?
>
> Thank you for any information you can provide.
>
>
>

Re: JournalDiskSyncStrategy in KahaDBStore

[Christopher Shannon]

I can update the documentation for this feature.

There is a new property on KahaDB called "journalDiskSyncStrategy" that can
be set either in XML config or with Java on the persistence adapter.

For example, if using XML:


 
 

Setting to periodic will trigger disk flushes at set intervals instead of
after every message which will reduce the load on the disk and should
improve throughput.  The default strategy is still set to "always" as it is
the safest option.  If necessary you can also tune the frequency of the
periodic sync using the property "journalDiskSyncInterval".   The default
is set to sync once a second and that seems to give a good combination of
performance vs reliability if you can tolerate up to one second of
potential message loss.


On Wed, Nov 30, 2016 at 5:30 AM, yogu13  wrote:

> As part of https://issues.apache.org/jira/browse/AMQ-6377 there is a new
> option introduced of periodic Sync for journal data. I do not see any
> documentation of how to go about using it.
>
> Does anyone know how to use it ?
>
> Regards,
> -Yogesh
>
>
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/
> JournalDiskSyncStrategy-in-KahaDBStore-tp4719603.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: 5.14.1 Upgrade causes Failed to browse Topic NullPointerException

[Christopher Shannon]

Can you post your broker configuration?  This seems odd that would happen
if you removed the db.

On Wed, Nov 30, 2016 at 5:04 AM, jack patwork  wrote:

> Hi,
>
>
> After upgrading a 4 node cluster from 5.9.1 to 5.14.1 I'm seeing my amq
> logs spammed with 1000's of the following warnings. This was after shutting
> down all 4 instances, deleting the db and restarting them.
>
> It looks like the scheduler is stuck in a loop trying to deal with topics
> that have been deleted. I'm just wondering where the scheduler has picked
> up these tasks from given that the db was completely removed.
>
> 2016-11-29 15:14:55,555 | WARN | Failed to browse Topic:
> my.custom.topic.123 | org.apache.activemq.broker.region.Topic | ActiveMQ
> Broker[myBrokerName] Scheduler
> java.lang.NullPointerException
> at
> org.apache.activemq.broker.region.policy.FixedCountSubscriptionRecovery
> Policy.browse(FixedCountSubscriptionRecoveryPolicy.java:102)
> [activemq-broker-5.14.1.jar:5.14.1]
> at
> org.apache.activemq.broker.region.policy.RetainedMessageSubscriptionRec
> overyPolicy.browse(RetainedMessageSubscriptionRecoveryPolicy.java:111)
> [activemq-broker-5.14.1.jar:5.14.1]
> at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:674)
> [activemq-broker-5.14.1.jar:5.14.1]
> at org.apache.activemq.broker.region.Topic.access$100(Topic.java:69)
> [activemq-broker-5.14.1.jar:5.14.1]
> at org.apache.activemq.broker.region.Topic$6.run(Topic.java:780)
> [activemq-broker-5.14.1.jar:5.14.1]
> at
> org.apache.activemq.thread.SchedulerTimerTask.run(
> SchedulerTimerTask.java:33)
> [activemq-client-5.14.1.jar:5.14.1]
> at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_101]
> at java.util.TimerThread.run(Timer.java:505)[:1.7.0_101]
>
>
> Thanks in advance for any help on this,
>
> Jack
>

Re: How to get visibility into per destination store usage

[Christopher Shannon]

If you look at at destination when using JMX, there is
getStoreMessageSize() which will give you the usage of the message store
for the destination.  It's part of the DestinationView interface.

On Fri, Nov 18, 2016 at 6:25 PM, Brian Cole  wrote:

> I am using the statistcsBrokerPlugin to query broker statistics. I am
> retrieving both broker and per destination statistics. The counters
> returned
> for the broker include the percentage of store used, but the destination
> specifics counters don't include this. I really want the per destination
> store usage statistics. Is there a way to get this?
>
> Thanks
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/How-to-get-visibility-into-per-destination-store-usage-
> tp4719309.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: mkahadb with error: java.lang.IllegalStateException: PageFile is not loaded

[Christopher Shannon]

That's odd because the page file should be loaded right before the journal
is loaded in that open() method.  Did you see a log message about the index
being corrupted?

On Mon, Oct 24, 2016 at 3:11 AM, RuralHunter  wrote:

> I'm using 5.13.4 with mkahadb. Sometimes I saw this error:
> java.lang.IllegalStateException: PageFile is not loaded
> at
> org.apache.activemq.store.kahadb.disk.page.PageFile.
> assertLoaded(PageFile.java:811)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.disk.page.PageFile.tx(
> PageFile.java:304)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.
> recover(MessageDatabase.java:672)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.open(
> MessageDatabase.java:436)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(
> MessageDatabase.java:454)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.
> doStart(MessageDatabase.java:287)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.doStart(
> KahaDBStore.java:216)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)[
> activemq-client-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(
> KahaDBPersistenceAdapter.java:223)[activemq-kahadb-store-5.
> 13.4.jar:5.13.4]
> at
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)[
> activemq-client-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.
> startAdapter(MultiKahaDBPersistenceAdapter.java:207)[activemq-kahadb-
> store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.
> getMatchingPersistenceAdapter(MultiKahaDBPersistenceAdapter.
> java:200)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter.
> createQueueMessageStore(MultiKahaDBPersistenceAdapter.
> java:184)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.region.DestinationFactoryImpl.
> createDestination(DestinationFactoryImpl.java:84)[activemq-broker-5.13.4.
> jar:5.13.4]
> at
> org.apache.activemq.broker.region.AbstractRegion.createDestination(
> AbstractRegion.java:629)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.jmx.ManagedQueueRegion.createDestination(
> ManagedQueueRegion.java:56)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.region.AbstractRegion.
> addDestination(AbstractRegion.java:155)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.region.RegionBroker.
> addDestination(RegionBroker.java:348)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(
> BrokerFilter.java:173)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(
> BrokerFilter.java:173)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.MutableBrokerFilter.addDestination(
> MutableBrokerFilter.java:178)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.region.RegionBroker.
> addProducer(RegionBroker.java:398)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.jmx.ManagedRegionBroker.addProducer(
> ManagedRegionBroker.java:263)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.CompositeDestinationBroker.addProducer(
> CompositeDestinationBroker.java:56)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.BrokerFilter.addProducer(
> BrokerFilter.java:108)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.MutableBrokerFilter.addProducer(
> MutableBrokerFilter.java:113)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.TransportConnection.processAddProducer(
> TransportConnection.java:618)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)[
> activemq-client-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.TransportConnection.service(
> TransportConnection.java:338)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.broker.TransportConnection$1.
> onCommand(TransportConnection.java:188)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.transport.MutexTransport.onCommand(
> MutexTransport.java:50)[activemq-client-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(
> WireFormatNegotiator.java:125)[activemq-client-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.

Re: ActiveMq 5.14.1 - Memory Leak?

[Christopher Shannon]

As far as I know there haven't been any reports or issues having to do with
a memory leak in recent versions.

How much memory is being used is really up to the JVM in terms of how it
handles allocation and GC.  The only way to really know if there is a
memory leak is to analyze the results of a heap dump and see what's
actually in memory and not just how much memory is allocated.


On Thu, Oct 20, 2016 at 9:13 AM, swidnow2 
wrote:

> Hi Guys
>
> I am running Broker using: 'java -cp activemq-all-5.14.1.jar
> org.apache.activemq.console.command.ShellCommand start' (JDK8u60).
>
> Besides of this I used OpenWire example code for Java:
> https://www.dropbox.com/s/y654vrltof1w0p2/openwire2.zip?dl=0
>
> I have just modified Producer's code to send messages for longer time.
>
> What I observed is that memory consumed by Broker process is increasing in
> time - about 15 MB after 2 hours ('WS Private' in Process Explorer or
> 'Private Working Set' in Task Manager).
>
> On the other side I do not see anything suspicious using Yourkit Profiler
> (heap space is GC collected correctly).
>
> I have also checked the queue status using mBeans, but it looks that there
> are no messages not consumed.
>
> As I am new in ActiveMQ, could someone explain to me why is the memory
> consumption increasing in time for Broker process? Is it a memory leak?
>
> I was looking for similar topic, but could not find any - if there is,
> please guide me.
>
> Thank you
> Damian
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMq-5-14-1-Memory-Leak-tp4718129.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>