Re: [Artemis] upgrade from 2.1.0 getting errors around config-delete-queues

2018-07-20 Thread Dan Langford 
created https://issues.apache.org/jira/browse/ARTEMIS-1984 sorry for the
delay. i was trying to perform some due diligence and test on the latest
version but with how long my restarts are taking (another issue addressed
in another thread) it made validating the error a bit more time consuming.

thank you so much for the ideas around exporting and migrating up to a
newer version.

On Fri, Jul 20, 2018 at 4:00 PM Justin Bertram  wrote:

> I'm looking at a possible solution to this issue.  Please open a JIRA as
> previously requested.
>
> In the mean-time I think you could just use the "data" command to export
> your 2.2.0 journal and then import into a new instance of 2.6.2 (or
> whatever).  Make sure your 2.2.0 instance is not running then from your
> 2.2.0 instance's "bin" directory run:
>
>   ./artemis data exp > /path/to/export.xml
>
> Delete the first line from export.xml (errant logging makes it into the
> output).  Then start the new instance and run this from the new instance's
> "bin" directory:
>
>   ./artemis data imp --input /path/to/export.xml
>
> Then shutdown the new broker instance and copy your address-settings, etc.
> over.
>
>
> Justin
>
> On Tue, May 15, 2018 at 3:51 PM, Dan Langford 
> wrote:
>
> > i have been heads down for a few weeks with a couple big production
> deploys
> > and unable to come back to this until now.
> >
> > would you still like me to make a ticket in jira?
> >
> > @Clebert, you said you added compatibility tests in 2.5.0 "that should
> > cover moving forward" does that mean that you think i should be able to
> > move to 2.5 or i should be able to move up AFTER 2.5?
> >
> > also, is there anything you guys think of that i can do to upgrade my
> 2.1.0
> > without destroying all my queues and rebuilding them on a newer version
> >
> > On Wed, May 9, 2018 at 8:11 PM Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> > > I have added compatibility tests in 2.5.0.  That should cover moving
> > > forward.
> > >
> > >
> > > Any other issues we can add more compatibility tests.
> > >
> > > On Tue, May 1, 2018 at 3:03 AM michael.andre.pearce <
> > > michael.andre.pea...@me.com> wrote:
> > >
> > > > This seems genuine bug for the upgrade from 2.1 to 2.2 suprised no
> one
> > > > else has seen it though including ourselves (we upgraded a long while
> > > back
> > > > and don't remember such issue), can you raise a Jira for this.
> > > >
> > > >
> > > >
> > > >
> > > > Sent from my Samsung Galaxy smartphone.
> > > >  Original message From: Dan Langford <
> > > > danlangf...@gmail.com> Date: 30/04/2018  22:12  (GMT+00:00) To:
> > > > users@activemq.apache.org Subject: [Artemis] upgrade from 2.1.0
> > getting
> > > > errors around config-delete-queues
> > > > we are running 2.1.0 and i tried to upgrade to 2.5.0 and ran into
> some
> > > > problems. in an attempt to isolate the problem i rolled things back
> and
> > > > just attempted to upgrade to 2.2.0. The startup exception i saw on
> both
> > > > 2.5.0 and 2.2.0 are quite similar.
> > > >
> > > > 2.5.0
> > > > 
> > > >
> > > > ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure in
> > > > initialisation: java.lang.NegativeArraySizeException
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.api.core.SimpleString.
> > readSimpleString(SimpleString.java:182)
> > > > [artemis-commons-2.5.0.jar:2.5.0]
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.api.core.SimpleString.
> > readSimpleString(SimpleString.java:171)
> > > > [artemis-commons-2.5.0.jar:2.5.0]
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.api.core.SimpleString.
> > readNullableSimpleString(SimpleString.java:158)
> > > > [artemis-commons-2.5.0.jar:2.5.0]
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.
> > readNullableSimpleString(ChannelBufferWrapper.java:69)
> > > > [artemis-commons-2.5.0.jar:2.5.0]
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.core.settings.impl.AddressSettings.decode(
> > AddressSettings.java:736)
> > > > [artemis-server-2.5.0.jar:2.5.0]
> > > >
> > > > 2.2.0
> > > > 
> > > > ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure in
> > > > initialisation: java.lang.NegativeArraySizeException
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.api.core.SimpleString.
> > readSimpleString(SimpleString.java:149)
> > > > [artemis-commons-2.2.0.jar:2.2.0]
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.api.core.SimpleString.
> > readNullableSimpleString(SimpleString.java:143)
> > > > [artemis-commons-2.2.0.jar:2.2.0]
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.
> > readNullableSimpleString(ChannelBufferWrapper.java:69)
> > > > [artemis-commons-2.2.0.jar:2.2.0]
> > > > at
> > > >
> > > >
> > > org.apache.activemq.artemis.core.settings.impl.AddressSettings.decode(
> > AddressSettings.java:724)
> > > > [artemis-serv

Re: [Artemis] upgrade from 2.1.0 getting errors around config-delete-queues

2018-07-20 Thread Justin Bertram 
I'm looking at a possible solution to this issue.  Please open a JIRA as
previously requested.

In the mean-time I think you could just use the "data" command to export
your 2.2.0 journal and then import into a new instance of 2.6.2 (or
whatever).  Make sure your 2.2.0 instance is not running then from your
2.2.0 instance's "bin" directory run:

  ./artemis data exp > /path/to/export.xml

Delete the first line from export.xml (errant logging makes it into the
output).  Then start the new instance and run this from the new instance's
"bin" directory:

  ./artemis data imp --input /path/to/export.xml

Then shutdown the new broker instance and copy your address-settings, etc.
over.


Justin

On Tue, May 15, 2018 at 3:51 PM, Dan Langford  wrote:

> i have been heads down for a few weeks with a couple big production deploys
> and unable to come back to this until now.
>
> would you still like me to make a ticket in jira?
>
> @Clebert, you said you added compatibility tests in 2.5.0 "that should
> cover moving forward" does that mean that you think i should be able to
> move to 2.5 or i should be able to move up AFTER 2.5?
>
> also, is there anything you guys think of that i can do to upgrade my 2.1.0
> without destroying all my queues and rebuilding them on a newer version
>
> On Wed, May 9, 2018 at 8:11 PM Clebert Suconic 
> wrote:
>
> > I have added compatibility tests in 2.5.0.  That should cover moving
> > forward.
> >
> >
> > Any other issues we can add more compatibility tests.
> >
> > On Tue, May 1, 2018 at 3:03 AM michael.andre.pearce <
> > michael.andre.pea...@me.com> wrote:
> >
> > > This seems genuine bug for the upgrade from 2.1 to 2.2 suprised no one
> > > else has seen it though including ourselves (we upgraded a long while
> > back
> > > and don't remember such issue), can you raise a Jira for this.
> > >
> > >
> > >
> > >
> > > Sent from my Samsung Galaxy smartphone.
> > >  Original message From: Dan Langford <
> > > danlangf...@gmail.com> Date: 30/04/2018  22:12  (GMT+00:00) To:
> > > users@activemq.apache.org Subject: [Artemis] upgrade from 2.1.0
> getting
> > > errors around config-delete-queues
> > > we are running 2.1.0 and i tried to upgrade to 2.5.0 and ran into some
> > > problems. in an attempt to isolate the problem i rolled things back and
> > > just attempted to upgrade to 2.2.0. The startup exception i saw on both
> > > 2.5.0 and 2.2.0 are quite similar.
> > >
> > > 2.5.0
> > > 
> > >
> > > ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure in
> > > initialisation: java.lang.NegativeArraySizeException
> > > at
> > >
> > >
> > org.apache.activemq.artemis.api.core.SimpleString.
> readSimpleString(SimpleString.java:182)
> > > [artemis-commons-2.5.0.jar:2.5.0]
> > > at
> > >
> > >
> > org.apache.activemq.artemis.api.core.SimpleString.
> readSimpleString(SimpleString.java:171)
> > > [artemis-commons-2.5.0.jar:2.5.0]
> > > at
> > >
> > >
> > org.apache.activemq.artemis.api.core.SimpleString.
> readNullableSimpleString(SimpleString.java:158)
> > > [artemis-commons-2.5.0.jar:2.5.0]
> > > at
> > >
> > >
> > org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.
> readNullableSimpleString(ChannelBufferWrapper.java:69)
> > > [artemis-commons-2.5.0.jar:2.5.0]
> > > at
> > >
> > >
> > org.apache.activemq.artemis.core.settings.impl.AddressSettings.decode(
> AddressSettings.java:736)
> > > [artemis-server-2.5.0.jar:2.5.0]
> > >
> > > 2.2.0
> > > 
> > > ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure in
> > > initialisation: java.lang.NegativeArraySizeException
> > > at
> > >
> > >
> > org.apache.activemq.artemis.api.core.SimpleString.
> readSimpleString(SimpleString.java:149)
> > > [artemis-commons-2.2.0.jar:2.2.0]
> > > at
> > >
> > >
> > org.apache.activemq.artemis.api.core.SimpleString.
> readNullableSimpleString(SimpleString.java:143)
> > > [artemis-commons-2.2.0.jar:2.2.0]
> > > at
> > >
> > >
> > org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.
> readNullableSimpleString(ChannelBufferWrapper.java:69)
> > > [artemis-commons-2.2.0.jar:2.2.0]
> > > at
> > >
> > >
> > org.apache.activemq.artemis.core.settings.impl.AddressSettings.decode(
> AddressSettings.java:724)
> > > [artemis-server-2.2.0.jar:2.2.0]
> > >
> > > i went and looked at the source code for those and it appears during
> the
> > > decode when trying to read a value for config-delete-queues. I see that
> > > this value was added in 2.2.0.
> > >
> > > How do i upgrade from 2.1.0? All of my addresses and queues are defined
> > at
> > > runtime with the API (meaning they are not defined in the broker.xml
> > file).
> > > Is upgrade possible? did others run into this back when 2.2.0 was
> > released?
> > >
> > > thanks
> > >
> > --
> > Clebert Suconic
> >
>

Re: [artemis 2.1.0] taking 30+ minutes to boot & failover

2018-07-20 Thread Dan Langford 
Thank you that was very helpful. we actually do have an address settings
entry for each queue. there could be a better pattern for us. but currently
our automated system for creating queues creates an address setting at the
same time. i will look into improved patterns.

as far as upgrading goes. i agree we really want to upgrade. until i can
find a work around for the config-delete-queues deserialization bug
introduced in 2.2.0 i brought up back in April we will not be able to
easily move.

thanks again for all the help

On Fri, Jul 20, 2018 at 8:56 AM Clebert Suconic 
wrote:

> If you do not want to upgrade for any reason export the journal. Cleani
> uo.  Edit the text and remove the garbage (you will see) manually.   Delete
> all data and te import.
>
> (Make a backup to be safe of course)
>
>
> But I still recommend the upgrade.
>
> On Fri, Jul 20, 2018 at 10:54 AM Clebert Suconic <
> clebert.suco...@gmail.com>
> wrote:
>
> > The address setting is the garbage I was talking about.  Upgrade to the
> > latest broker and there will be a cleanup done at the load before it
> > starts.
> >
> >
> > I highly recommend upgrade.
> >
> > On Fri, Jul 20, 2018 at 10:05 AM Justin Bertram 
> > wrote:
> >
> >> Analyzing thread dumps like this is pretty simple.  I generally just
> >> scroll
> >> through and look for long stack-traces with lots of calls from
> >> org.apache.activemq.artemis.  In your case every single thread dump has
> a
> >> thread doing something like this:
> >>
> >> "main" #1 prio=5 os_prio=0 tid=0x7f902800eb20 nid=0x74fe runnable
> >> [0x7f9031675000]
> >>java.lang.Thread.State: RUNNABLE
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getPossibleMatches(HierarchicalObjectRepository.java:373)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getMatch(HierarchicalObjectRepository.java:192)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.reapplySettings(PagingManagerImpl.java:113)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.onChange(PagingManagerImpl.java:108)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.onChange(HierarchicalObjectRepository.java:348)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:168)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:147)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:120)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.recoverStoredConfigs(ActiveMQServerImpl.java:2424)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2374)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2219)
> >> - locked <0x80a8fce8> (a
> >> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:109)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:518)
> >> at
> >>
> >>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:466)
> >> - locked <0x80a8fce8> (a
> >> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
> >> at
> >>
> >>
> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:111)
> >> - locked <0x8098be80> (a
> >> org.apache.activemq.artemis.integration.FileBroker)
> >> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:73)
> >> at
> >>
> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:148)
> >> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:95)
> >> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:122)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >>
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >> at
> >>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> at java.lang.reflect.Method.invoke(Method.java:498)
> >> at
> org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:129)
> >> at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:49)
> >>
> >> In every case it's the "main" thread which isn't surprising as that is
> the
> >> thread responsible for starting the broker.  Also, you can pretty
> cle

Re: Basic question on AMQP 1.0 protocol support

2018-07-20 Thread Justin Bertram 
I think most of your questions were already answered on your other email
which was very similar to this one, but I'll here as well for clarity's
sake...

> Does this mean that the broker works equally well with any client that
complies with the standard spec?

In general, yes.

> ...the ActiveMQ 5 broker shouldn't care which of these I use if I "speak
AMQP" the same way at the protocol level.

>From a protocol perspective that's correct.

> I'm trying to clarify my understanding that AMQP 1.0 is an interface
standard that is somewhat independent of the client implementations...

That's correct.  AMQP 1.0 is a standard that exists independent of any
implementation.

> ...brokers and clients have to support the standard (whereas the specific
version of any given client library is not as important as supporting the
standard).

In general, yes.

> I should be fine using another version of the client library although I
accept risks if I pick one that doesn't properly implement the standard
spec for AMQP 1.0.

You should be fine.


I understand that you're interested specifically in AMQP 1.0 here, but that
detail could be removed and this discussion could easily just be about
standards in general.  You could just as easily be talking about TCP, HTTP,
SMTP, FTP, etc.  These are all standard protocols for networked devices
(i.e. like AMQP).  The reason standards exist is so that lots of different
implementations can work together.


Justin

On Fri, Jul 20, 2018 at 11:36 AM, dbeavon  wrote:

> The AMQP 1.0 protocol is a "vendor-neutral and platform-agnostic
> protocol".
> Does this mean that the broker works equally well with any client that
> complies with the standard spec?
>
> The reason I ask is because I have access to the amqpnetlite client version
> 1.1.8 from the redhat downloads, and a different version (2.1.2) on the
> upstream nuget repository (https://www.nuget.org/packages/AMQPNetLite/) .
> As far as I can gather, the ActiveMQ 5 broker shouldn't care which of these
> I use if I "speak AMQP" the same way at the protocol level.
>
> The reason I ask is because the newer client API is easier to use, and and
> has more interfaces and methods available to a developer in the later
> versions.
>
> I realize that if I ran into a problem then redhat would probably require
> me
> to create a reproducible using their (1.1.8) version of the client.  But
> I'm
> trying to clarify my understanding that AMQP 1.0 is an interface standard
> that is somewhat independent of the client implementations, and that
> brokers
> and clients have to support the standard (whereas the specific version of
> any given client library is not as important as supporting the standard).
> IE. I should be fine using another version of the client library although I
> accept risks if I pick one that doesn't properly implement the standard
> spec
> for AMQP 1.0.
>
> Please let me know if I have this wrong.  I realize that this is not a
> redhat forum and I won't get an official redhat recommendation from here.
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

Re: Using AWS EFS as the shared file system for master/slave broker pair

2018-07-20 Thread avmpt 
I am using a custom docker image rather than any of the ones available
online. The config uses a base os image and then has the following activemq
settings:
---

ENV ACTIVEMQ_VERSION 5.14.3
ENV ACTIVEMQ apache-activemq-$ACTIVEMQ_VERSION

ENV ACTIVEMQ_HOME /opt/activemq

RUN tdnf -y install tar gzip

RUN set -x && \
mkdir -p /opt && \
curl -s -S
https://archive.apache.org/dist/activemq/$ACTIVEMQ_VERSION/$ACTIVEMQ-bin.tar.gz
| tar xvz -C /opt && \
ln -s /opt/$ACTIVEMQ $ACTIVEMQ_HOME && \
useradd -r -M -d $ACTIVEMQ_HOME activemq

RUN chmod 764 $ACTIVEMQ_HOME
COPY activemq.xml $ACTIVEMQ_HOME/conf/
WORKDIR $ACTIVEMQ_HOME

CMD ["/bin/sh", "-c", "bin/activemq console"]

---

For this version of AMQ (5.14.3) would it still be possible to setup the EFS
without pluggable storage lockers? Also can you elaborate about changing the
data directory to being under the efs mount? I'm not sure I understand that
part. Thanks!


thall wrote
> There are a number of docker images for activemq, you will need to follow
> the documentation for that docker image.  
> Make sure your docker image is using the latest version of activemq.
> You are going to need to change the data directory to be under the efs
> mount, and you are going to have to configure a pluggable storage locker
> as well.
> https://cwiki.apache.org/confluence/display/ACTIVEMQ/Pluggable+storage+lockers
> ;
> https://activemq.apache.org/pluggable-storage-lockers.html
> 
> -Tom
> 
>> On Jul 18, 2018, at 3:47 PM, avmpt <

> patelakash@

> > wrote:
>> 
>> I would like to use EFS as the shared file system when I set up a
>> master/slave broker pair. What changes would I need to make to the
>> persistence adapter to use the mounted EFS path?
>> 
>> When I have
>> 
> 
>>
> 
>> 
> 
>> 
>> Would I need to change it to the path where EFS is mounted? Are there any
>> additional changes required? My activemq brokers are both docker
>> containers
>> so I'm not sure how exactly this would affect my setup. Thanks!
>> 
>> 
>> 
>> 
>> --
>> Sent from:
>> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Need Unix command to purge and delete queues and topics

2018-07-20 Thread Tim Bain 
You can use curl to hit a HTTP URL, either a Jolokia/JMX one (
https://stackoverflow.com/questions/25752045/activemq-jolokia-rest-api-for-deleting-a-queue)
or you might be able to look at the links on the web console and determine
the pattern of those links.

Tim

On Tue, Jul 17, 2018, 11:50 PM Shital24 
wrote:

> Hi Team,
>
> Can you please help me to share Unix command to purge and delete queues,
> also please share command to delete topics from ActiveMQ. We need this
> command create script to purge and delete ActiveMQ queues and topics,
> currently we are doing from web url "http://< ip>>:8161/admin/queues.jsp" and "http://< ip>>:8161/admin/topics.jsp"
>
> Thanks in advance.
>
> Thanks,
> Shital
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Simple question on AMQP 1.0 protocol support

2018-07-20 Thread Timothy Bish 

On 07/20/2018 12:49 PM, dbeavon wrote:

If a client and broker implement the AMQP 1.0 standard spec, then they should
be able to interoperate, right?  IE it is the standard that matters more
than the particular version/revision of the client code.

I'm asking because redhat distributes v.1.1.8 of the amqpnetlite client and
I can get a much improved version 2.1.2 out of nuget
(https://www.nuget.org/packages/AMQPNetLite/).  Both implement AMQP 1.0.  I
would like to user the newer one if possible.

I understand that I won't get an official response from redhat on these
forums.  But I just want to make sure that I'm accurate in thinking that any
client should work if it properly implements the standard.  I suspect if I
ran into a bug then redhat would ask me to repro it on 1.1.8 before they
would offer formal support.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

If a client implements the AMQP 1.0 specification correctly then it 
should work, notwithstanding any bugs in the chosen client or broker 
versions that might manifest themselves, subtle changes in behavior 
between client versions and broker versions have been know to surface 
issues from time to time.


--
Tim Bish

Re: Simple question on AMQP 1.0 protocol support

2018-07-20 Thread Justin Bertram 
> If a client and broker implement the AMQP 1.0 standard spec, then they
should be able to interoperate, right?

Right.

> IE it is the standard that matters more than the particular
version/revision of the client code.

That's correct.  That's what standards are for.

> But I just want to make sure that I'm accurate in thinking that any
client should work if it properly implements the standard.

You're accurate.

For what it's worth, every implementation of a specification will have its
share of bugs.


Justin

On Fri, Jul 20, 2018 at 11:49 AM, dbeavon  wrote:

> If a client and broker implement the AMQP 1.0 standard spec, then they
> should
> be able to interoperate, right?  IE it is the standard that matters more
> than the particular version/revision of the client code.
>
> I'm asking because redhat distributes v.1.1.8 of the amqpnetlite client and
> I can get a much improved version 2.1.2 out of nuget
> (https://www.nuget.org/packages/AMQPNetLite/).  Both implement AMQP 1.0.
> I
> would like to user the newer one if possible.
>
> I understand that I won't get an official response from redhat on these
> forums.  But I just want to make sure that I'm accurate in thinking that
> any
> client should work if it properly implements the standard.  I suspect if I
> ran into a bug then redhat would ask me to repro it on 1.1.8 before they
> would offer formal support.
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

Basic question on AMQP 1.0 protocol support

2018-07-20 Thread dbeavon 
The AMQP 1.0 protocol is a "vendor-neutral and platform-agnostic protocol". 
Does this mean that the broker works equally well with any client that
complies with the standard spec?

The reason I ask is because I have access to the amqpnetlite client version
1.1.8 from the redhat downloads, and a different version (2.1.2) on the
upstream nuget repository (https://www.nuget.org/packages/AMQPNetLite/) . 
As far as I can gather, the ActiveMQ 5 broker shouldn't care which of these
I use if I "speak AMQP" the same way at the protocol level.  

The reason I ask is because the newer client API is easier to use, and and
has more interfaces and methods available to a developer in the later
versions.

I realize that if I ran into a problem then redhat would probably require me
to create a reproducible using their (1.1.8) version of the client.  But I'm
trying to clarify my understanding that AMQP 1.0 is an interface standard
that is somewhat independent of the client implementations, and that brokers
and clients have to support the standard (whereas the specific version of
any given client library is not as important as supporting the standard). 
IE. I should be fine using another version of the client library although I
accept risks if I pick one that doesn't properly implement the standard spec
for AMQP 1.0.

Please let me know if I have this wrong.  I realize that this is not a
redhat forum and I won't get an official redhat recommendation from here.




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Simple question on AMQP 1.0 protocol support

2018-07-20 Thread dbeavon 
If a client and broker implement the AMQP 1.0 standard spec, then they should
be able to interoperate, right?  IE it is the standard that matters more
than the particular version/revision of the client code.

I'm asking because redhat distributes v.1.1.8 of the amqpnetlite client and
I can get a much improved version 2.1.2 out of nuget
(https://www.nuget.org/packages/AMQPNetLite/).  Both implement AMQP 1.0.  I
would like to user the newer one if possible.

I understand that I won't get an official response from redhat on these
forums.  But I just want to make sure that I'm accurate in thinking that any
client should work if it properly implements the standard.  I suspect if I
ran into a bug then redhat would ask me to repro it on 1.1.8 before they
would offer formal support.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: ActiveMQ 5.11.0: Out Of Memory, caused by PageFile object tree filling up heap

2018-07-20 Thread Tom Hall 
Hi Art,
What per destination limit are you looking for? The per destination limits will 
deal with memory used per queue.
http://activemq.apache.org/per-destination-policies.html 

 
   

-Tom

> On Jul 20, 2018, at 3:50 AM, art.licis  wrote:
> 
> 300mb memory limit is on a VM having -XmX 4Gb for heap; on 8Gb (most likely)
> it was more. While I totally agree 300 Mb memory limit is far from the
> optimal setting, and even better per-destination limits are needed.
> 
> However, I have stress tested ActiveMQ with much less memory, and I've seen
> the following in logs:
> 
> topic://topic-3, Usage Manager memory
> limit reached 5242880. Producers will be throttled to the rate at which
> messages are removed from this destination to prevent flooding it.
> 
> << just 5Mb of memory limit on this test!
> 
> .. and eventually this:
> 
> TopicSubscription: consumer=ID:a-thinkpad-44715-1532031318503-1:1:1:1,
> destinations=1, dispatched=32766, delivered=15963293, matched=1460,
> discarded=0, prefetchExtension=0: Pending message cursor
> [org.apache.activemq.broker.region.cursors.FilePendingMessageCursor@6bba423c]
> is full, temp usag (100%) or memory usage (0%) limit reached, blocking
> message add() pending the release of resources.
> 
> << all 10Gb of temp store filled!
> 
> 
> Which means filling up temp store and blocking the producer, but NOT
> crashing with out of memory, having all heap filled with PageFile-related
> data.
> 
> - Art
> 
> 
> 
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: [artemis 2.1.0] taking 30+ minutes to boot & failover

2018-07-20 Thread Clebert Suconic 
If you do not want to upgrade for any reason export the journal. Cleani
uo.  Edit the text and remove the garbage (you will see) manually.   Delete
all data and te import.

(Make a backup to be safe of course)


But I still recommend the upgrade.

On Fri, Jul 20, 2018 at 10:54 AM Clebert Suconic 
wrote:

> The address setting is the garbage I was talking about.  Upgrade to the
> latest broker and there will be a cleanup done at the load before it
> starts.
>
>
> I highly recommend upgrade.
>
> On Fri, Jul 20, 2018 at 10:05 AM Justin Bertram 
> wrote:
>
>> Analyzing thread dumps like this is pretty simple.  I generally just
>> scroll
>> through and look for long stack-traces with lots of calls from
>> org.apache.activemq.artemis.  In your case every single thread dump has a
>> thread doing something like this:
>>
>> "main" #1 prio=5 os_prio=0 tid=0x7f902800eb20 nid=0x74fe runnable
>> [0x7f9031675000]
>>java.lang.Thread.State: RUNNABLE
>> at
>>
>> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getPossibleMatches(HierarchicalObjectRepository.java:373)
>> at
>>
>> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getMatch(HierarchicalObjectRepository.java:192)
>> at
>>
>> org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.reapplySettings(PagingManagerImpl.java:113)
>> at
>>
>> org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.onChange(PagingManagerImpl.java:108)
>> at
>>
>> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.onChange(HierarchicalObjectRepository.java:348)
>> at
>>
>> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:168)
>> at
>>
>> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:147)
>> at
>>
>> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:120)
>> at
>>
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.recoverStoredConfigs(ActiveMQServerImpl.java:2424)
>> at
>>
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2374)
>> at
>>
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2219)
>> - locked <0x80a8fce8> (a
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
>> at
>>
>> org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:109)
>> at
>>
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:518)
>> at
>>
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:466)
>> - locked <0x80a8fce8> (a
>> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
>> at
>>
>> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:111)
>> - locked <0x8098be80> (a
>> org.apache.activemq.artemis.integration.FileBroker)
>> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:73)
>> at
>> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:148)
>> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:95)
>> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:122)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:129)
>> at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:49)
>>
>> In every case it's the "main" thread which isn't surprising as that is the
>> thread responsible for starting the broker.  Also, you can pretty clearly
>> see in the trace that this is the thread starting the broker, it's loading
>> the journals, & restoring stored configuration (either address settings or
>> security settings).  I've seen high broker start times when there are lots
>> and lots of addresses and lots of and lots of settings.  Do either (or
>> both) of these situations apply to you?
>>
>>
>> Justin
>>
>> On Fri, Jul 20, 2018 at 1:16 AM, Dan Langford 
>> wrote:
>>
>> > Dang I can’t easily upgrade past 2.1.0 because of the
>> config-delete-queues
>> > deserialization bug introduced in 2.2.0. Unless that bug was squashed in
>> > 2.6+. I don’t think I made a jira for it (vacation and work load) but we
>> > discussed it back in April. I should go confirm that bug on 2.6 and
>> make a
>> > jira for that
>> >
>> > Thanks
>> > On Thu, Jul 19, 2018 at 5:46 PM Clebert Suconic <
>>

Re: [artemis 2.1.0] taking 30+ minutes to boot & failover

2018-07-20 Thread Clebert Suconic 
The address setting is the garbage I was talking about.  Upgrade to the
latest broker and there will be a cleanup done at the load before it
starts.


I highly recommend upgrade.

On Fri, Jul 20, 2018 at 10:05 AM Justin Bertram  wrote:

> Analyzing thread dumps like this is pretty simple.  I generally just scroll
> through and look for long stack-traces with lots of calls from
> org.apache.activemq.artemis.  In your case every single thread dump has a
> thread doing something like this:
>
> "main" #1 prio=5 os_prio=0 tid=0x7f902800eb20 nid=0x74fe runnable
> [0x7f9031675000]
>java.lang.Thread.State: RUNNABLE
> at
>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getPossibleMatches(HierarchicalObjectRepository.java:373)
> at
>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getMatch(HierarchicalObjectRepository.java:192)
> at
>
> org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.reapplySettings(PagingManagerImpl.java:113)
> at
>
> org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.onChange(PagingManagerImpl.java:108)
> at
>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.onChange(HierarchicalObjectRepository.java:348)
> at
>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:168)
> at
>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:147)
> at
>
> org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:120)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.recoverStoredConfigs(ActiveMQServerImpl.java:2424)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2374)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2219)
> - locked <0x80a8fce8> (a
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
> at
>
> org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:109)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:518)
> at
>
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:466)
> - locked <0x80a8fce8> (a
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
> at
>
> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:111)
> - locked <0x8098be80> (a
> org.apache.activemq.artemis.integration.FileBroker)
> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:73)
> at
> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:148)
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:95)
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:129)
> at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:49)
>
> In every case it's the "main" thread which isn't surprising as that is the
> thread responsible for starting the broker.  Also, you can pretty clearly
> see in the trace that this is the thread starting the broker, it's loading
> the journals, & restoring stored configuration (either address settings or
> security settings).  I've seen high broker start times when there are lots
> and lots of addresses and lots of and lots of settings.  Do either (or
> both) of these situations apply to you?
>
>
> Justin
>
> On Fri, Jul 20, 2018 at 1:16 AM, Dan Langford 
> wrote:
>
> > Dang I can’t easily upgrade past 2.1.0 because of the
> config-delete-queues
> > deserialization bug introduced in 2.2.0. Unless that bug was squashed in
> > 2.6+. I don’t think I made a jira for it (vacation and work load) but we
> > discussed it back in April. I should go confirm that bug on 2.6 and make
> a
> > jira for that
> >
> > Thanks
> > On Thu, Jul 19, 2018 at 5:46 PM Clebert Suconic <
> clebert.suco...@gmail.com
> > >
> > wrote:
> >
> > > There is an issue I remember where the journal would have some dirt
> that
> > > was fixed on 2.3/0.
> > >
> > > I would ipgrade to 2.6.2.
> > >
> > > On Thu, Jul 19, 2018 at 6:34 PM Dan Langford 
> > > wrote:
> > >
> > > > would you be willing to help me translate these thread dumps?
> > > >
> > > > i attached a Zip file with some thread dumps in them. i will also
> sh

Re: Threads started in ActiveMQCPP

2018-07-20 Thread Timothy Bish 

On 07/19/2018 07:02 PM, developer wrote:

Hi,
This question is with reference to activemq cpp version 3.9.3

Once we call intialize and establish connection by calling

  activemq::library::ActiveMQCPP::initializeLibrary();
x= ActiveMQConnectionFactory() ;
connection = x->createConnection(xy,xz);
connection->start();

and communication starts ..

due to some reason if the connection to broker is lost,  (like disconnected
physical connection or broker stopped)

what is the best way to reestablish communication in this case?


Use the failover URI to have the client handle reconnects for you.


what is the correct sequence...

If i call
connection->close();


Be sure to delete the connection as well


and then reestablish everything via

activemq::library::ActiveMQCPP::initializeLibrary();


Don't call initialize more than once unless you've also shutdown the 
library in between



x= ActiveMQConnectionFactory() ;
connection = x->createConnection(xy,xz);
connection->start();

communication is back but this is creating some additional threads in qnx
environment.

calling just
  connection->close();
  connection->start();
doesn't reestablish the connection.










--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html



--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Webapp shutdown hangs on JMS Consumer

2018-07-20 Thread Mauro de Wit 
Hi all,

I have a webapp deployed on JBoss which connects to an external JMS broker
(ActiveMQ 5.15.4) using the the ActiveMQ resource adapter 5.15.4. The webapp
cannot be undeployed or shutdown because the ActiveMQMessageConsumer blocks.
(The entire JBoss container cannot even stop). Only when the broker is
shutdown, the webapp shutdown is continuing.

A thread dump reveals te following information:

   java.lang.Thread.State: TIMED_WAITING (on object monitor)at
java.lang.Object.wait(Native Method)at
org.apache.activemq.FifoMessageDispatchChannel.dequeue(FifoMessageDispatchChannel.java:74)
 
- locked <0x8bc1a1a8> (a java.lang.Object)  at
org.apache.activemq.ActiveMQMessageConsumer.dequeue(ActiveMQMessageConsumer.java:486)
 
at
org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:653)

The queue is being read by a MessageConsumer like:

Message message = this.consumer.receive(1000);

Any suggestions? In the activeMQ sources I saw that a prefetch policy of 0
causes an indefinite wait, but setting this to a higher value had no result.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Threads started in ActiveMQCPP

2018-07-20 Thread developer 
Hi,
This question is with reference to activemq cpp version 3.9.3 

Once we call intialize and establish connection by calling 

 activemq::library::ActiveMQCPP::initializeLibrary(); 
x= ActiveMQConnectionFactory() ;
connection = x->createConnection(xy,xz);
connection->start();

and communication starts ..

due to some reason if the connection to broker is lost,  (like disconnected
physical connection or broker stopped)

what is the best way to reestablish communication in this case?
what is the correct sequence...

If i call 
   connection->close();

and then reestablish everything via

activemq::library::ActiveMQCPP::initializeLibrary(); 
x= ActiveMQConnectionFactory() ;
connection = x->createConnection(xy,xz);
connection->start();

communication is back but this is creating some additional threads in qnx
environment.

calling just 
 connection->close();
 connection->start();
doesn't reestablish the connection.










--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: [artemis 2.1.0] taking 30+ minutes to boot & failover

2018-07-20 Thread Justin Bertram 
Analyzing thread dumps like this is pretty simple.  I generally just scroll
through and look for long stack-traces with lots of calls from
org.apache.activemq.artemis.  In your case every single thread dump has a
thread doing something like this:

"main" #1 prio=5 os_prio=0 tid=0x7f902800eb20 nid=0x74fe runnable
[0x7f9031675000]
   java.lang.Thread.State: RUNNABLE
at
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getPossibleMatches(HierarchicalObjectRepository.java:373)
at
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.getMatch(HierarchicalObjectRepository.java:192)
at
org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.reapplySettings(PagingManagerImpl.java:113)
at
org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl.onChange(PagingManagerImpl.java:108)
at
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.onChange(HierarchicalObjectRepository.java:348)
at
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:168)
at
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:147)
at
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository.addMatch(HierarchicalObjectRepository.java:120)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.recoverStoredConfigs(ActiveMQServerImpl.java:2424)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2374)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2219)
- locked <0x80a8fce8> (a
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
at
org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:109)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:518)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:466)
- locked <0x80a8fce8> (a
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl)
at
org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:111)
- locked <0x8098be80> (a
org.apache.activemq.artemis.integration.FileBroker)
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:73)
at
org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:148)
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:95)
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:129)
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:49)

In every case it's the "main" thread which isn't surprising as that is the
thread responsible for starting the broker.  Also, you can pretty clearly
see in the trace that this is the thread starting the broker, it's loading
the journals, & restoring stored configuration (either address settings or
security settings).  I've seen high broker start times when there are lots
and lots of addresses and lots of and lots of settings.  Do either (or
both) of these situations apply to you?


Justin

On Fri, Jul 20, 2018 at 1:16 AM, Dan Langford  wrote:

> Dang I can’t easily upgrade past 2.1.0 because of the config-delete-queues
> deserialization bug introduced in 2.2.0. Unless that bug was squashed in
> 2.6+. I don’t think I made a jira for it (vacation and work load) but we
> discussed it back in April. I should go confirm that bug on 2.6 and make a
> jira for that
>
> Thanks
> On Thu, Jul 19, 2018 at 5:46 PM Clebert Suconic  >
> wrote:
>
> > There is an issue I remember where the journal would have some dirt that
> > was fixed on 2.3/0.
> >
> > I would ipgrade to 2.6.2.
> >
> > On Thu, Jul 19, 2018 at 6:34 PM Dan Langford 
> > wrote:
> >
> > > would you be willing to help me translate these thread dumps?
> > >
> > > i attached a Zip file with some thread dumps in them. i will also share
> > > the fasthread.io links for each file. (i was struggling getting
> > > fastthread to do a combo report with the threads in the correct order)
> > >
> > > artemis04-20180719-1525 https://goo.gl/d88azU
> > > artemis04-20180719-1530 https://goo.gl/G78qn3
> > > artemis04-20180719-1535 https://goo.gl/aMBSBw
> > > artemis04-20180719-1540 https://goo.gl/brKxxk
> > > artemis04-20180719-1545 https://goo.gl/RaXXCs
> > > artemis04-20180719-1550 https://goo.gl/r5dndK
> > > artemis04-2018071

Re: Using AWS EFS as the shared file system for master/slave broker pair

2018-07-20 Thread Tim Bain 
Also look at https://issues.apache.org/jira/browse/AMQ-6441, including the
discussion in the comments.

Tim

On Wed, Jul 18, 2018, 5:04 PM Tom Hall  wrote:

> There are a number of docker images for activemq, you will need to follow
> the documentation for that docker image.
> Make sure your docker image is using the latest version of activemq.
> You are going to need to change the data directory to be under the efs
> mount, and you are going to have to configure a pluggable storage locker as
> well.
>
> https://cwiki.apache.org/confluence/display/ACTIVEMQ/Pluggable+storage+lockers
> <
> https://cwiki.apache.org/confluence/display/ACTIVEMQ/Pluggable+storage+lockers
> >
> https://activemq.apache.org/pluggable-storage-lockers.html
>
> -Tom
>
> > On Jul 18, 2018, at 3:47 PM, avmpt  wrote:
> >
> > I would like to use EFS as the shared file system when I set up a
> > master/slave broker pair. What changes would I need to make to the
> > persistence adapter to use the mounted EFS path?
> >
> > When I have
> > 
> >
> > 
> >
> > Would I need to change it to the path where EFS is mounted? Are there any
> > additional changes required? My activemq brokers are both docker
> containers
> > so I'm not sure how exactly this would affect my setup. Thanks!
> >
> >
> >
> >
> > --
> > Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
>

Re: ActiveMQ 5.11.0: Out Of Memory, caused by PageFile object tree filling up heap

2018-07-20 Thread art.licis 
300mb memory limit is on a VM having -XmX 4Gb for heap; on 8Gb (most likely)
it was more. While I totally agree 300 Mb memory limit is far from the
optimal setting, and even better per-destination limits are needed.

However, I have stress tested ActiveMQ with much less memory, and I've seen
the following in logs:

topic://topic-3, Usage Manager memory
 limit reached 5242880. Producers will be throttled to the rate at which
messages are removed from this destination to prevent flooding it.

<< just 5Mb of memory limit on this test!

.. and eventually this:

TopicSubscription: consumer=ID:a-thinkpad-44715-1532031318503-1:1:1:1,
destinations=1, dispatched=32766, delivered=15963293, matched=1460,
discarded=0, prefetchExtension=0: Pending message cursor
[org.apache.activemq.broker.region.cursors.FilePendingMessageCursor@6bba423c]
is full, temp usag (100%) or memory usage (0%) limit reached, blocking
message add() pending the release of resources.

<< all 10Gb of temp store filled!


Which means filling up temp store and blocking the producer, but NOT
crashing with out of memory, having all heap filled with PageFile-related
data.

- Art



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html