Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

[Tim Bain]

I don't have personal experience running with that number of connected
clients (I've only used ActiveMQ with a few dozen to a few hundred), but if
it's a problem, the JVisualVM CPU sampling we talked about in that thread
should make that clear pretty quickly.

Tim

On May 19, 2017 12:11 PM, "Shobhana"  wrote:

> Tim, each client process will open just one connection.
> There can be hundreds of thousands of different client processes (as many
> as
> no of users using our app) connected to the broker at the same time.
>
> In another thread
> (http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-
> becomes-unresponsive-after-sometime-td4725278.html#a4726390)
> I had mentioned that broker becomes unresponsive after some time; wanted to
> chcek if our usage itself was wrong; hence posted this thread.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Is-creating-thousands-of-connections-to-a-
> single-AMQ-broker-node-and-keeping-them-open-an-anti-
> patte-tp4726391p4726400.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: JMX url in master/slave mode

[Steve Hill]

I would recommend using a load balancer. You would put both up addresses in the 
load balancer.

Thanks

Sent from my iPhone

> On May 19, 2017, at 3:17 PM, kpdude7  wrote:
> 
> How would someone programmatically access the correct JMX server in this
> master/slave configuration? For example, I have the JMX url:
> 
> service:jmx:rmi:///jndi/rmi://${jmxTransferUrl}/jmxrmi
> 
> My JMS is using a failover url:
> failover:(ssl://10.91.5.190:61616,ssl://10.91.5.115:61616)
> 
> What value should be substituted for ${jmxTransferUrl} above? Do I have to
> try each IP in the failover url manually and catch an exception before
> trying the next one? Is there another way to do this?
> 
> Thanks,
> Kyle
> 
> 
> 
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/JMX-url-in-master-slave-mode-tp4726404.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: AMQCPP -- Cannot publish to a delete Destination: temp-queue

[Clebert Suconic]

I would use either a newer activemq or Artemis version.



On Fri, May 19, 2017 at 8:09 PM bobeo  wrote:

> hi Tim,
>
> Maybe I wasn't clear enough. Let me make it clear again:
>
> First, I have a queue : sn.queue.settings.
>
> From Java, I send a message to that queue, and I can see from the log of
> activemq broker, I highlight important bits:
>
> INFO | Sending message: ActiveMQTextMessage {commandId = 24,
> responseRequired = false, *messageId =
> ID:ubuntu-14-dev-49451-1495115456046-1:1:1:1:3*, originalDestination =
> null,
> originalTransactionId = null, producerId =
> ID:ubuntu-14-dev-49451-1495115456046-1:1:1:1, destination =
> queue://sn.queue.settings, transactionId = null, expiration =
> 1495115724634,
> timestamp = 1495115722634, arrival = 0, brokerInTime = 0, brokerOutTime =
> 0,
> correlationId = null, *replyTo =
> temp-queue://ID:ubuntu-14-dev-49451-1495115456046-1:1:3*, persistent =
> false, type = null, priority = 4, groupID = null, groupSequence = 0,
> targetConsumerId = null, compressed = false, userID = null, content =
> org.apache.activemq.util.ByteSequence@1cf5297b, marshalledProperties =
> org.apache.activemq.util.ByteSequence@21c49053, dataStructure = null,
> redeliveryCounter = 0, size = 0, properties = {fromHost=central,
> toHost=central}, readOnlyProperties = false, readOnlyBody = false,
> droppable
> = false, jmsXGroupFirstForConsumer = false, text =  encoding="UTF-8" standalo...>
>
> As you can see, I set replyTo to a temporary queu
> "temp-queue://ID:ubuntu-14-dev-49451-1495115456046-1:1:3"
>
> My consumer( client ) is written in C++, from onMessage() callback, I
> receive the message :
>
> Message ID =
> ID:sensen-hyd-edge-demo-01-42179-1495108420785-1:1:1:1:3:-1:-1:2
> Destination type = 3
>
> And when I try to send back the reply with the destination from
> message->getCMSReplyTo(), it gives me exception:
>
>  Cannot publish to a deleted Destination: temp-queue://
> FILE: activemq/core/kernels/ActiveMQSessionKernel.cpp, LINE: 1013
> FILE: activemq/core/kernels/ActiveMQProducerKernel.cpp, LINE: 274
> FILE: activemq/core/kernels/ActiveMQProducerKernel.cpp, LINE: 184
> FILE: activemq/core/ActiveMQProducer.cpp, LINE: 100
>
> I hope this is clearer. Do you still think the broker has advisory support
> disabled? ( How to check this? ).
>
> Is this the right way to disable the watching of temp destination?
>
>   amqConnFactory = new ActiveMQConnectionFactory(CONN);
>   amqConnFactory.setWatchTopicAdvisories(false);
>
> Thanks a lot for your help.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/AMQCPP-Cannot-publish-to-a-delete-Destination-temp-queue-tp4672611p4726407.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
-- 
Clebert Suconic

Re: AMQCPP -- Cannot publish to a delete Destination: temp-queue

[bobeo]

hi Tim,

Maybe I wasn't clear enough. Let me make it clear again:

First, I have a queue : sn.queue.settings.

>From Java, I send a message to that queue, and I can see from the log of
activemq broker, I highlight important bits: 

INFO | Sending message: ActiveMQTextMessage {commandId = 24,
responseRequired = false, *messageId =
ID:ubuntu-14-dev-49451-1495115456046-1:1:1:1:3*, originalDestination = null,
originalTransactionId = null, producerId =
ID:ubuntu-14-dev-49451-1495115456046-1:1:1:1, destination =
queue://sn.queue.settings, transactionId = null, expiration = 1495115724634,
timestamp = 1495115722634, arrival = 0, brokerInTime = 0, brokerOutTime = 0,
correlationId = null, *replyTo =
temp-queue://ID:ubuntu-14-dev-49451-1495115456046-1:1:3*, persistent =
false, type = null, priority = 4, groupID = null, groupSequence = 0,
targetConsumerId = null, compressed = false, userID = null, content =
org.apache.activemq.util.ByteSequence@1cf5297b, marshalledProperties =
org.apache.activemq.util.ByteSequence@21c49053, dataStructure = null,
redeliveryCounter = 0, size = 0, properties = {fromHost=central,
toHost=central}, readOnlyProperties = false, readOnlyBody = false, droppable
= false, jmsXGroupFirstForConsumer = false, text = 

As you can see, I set replyTo to a temporary queu
"temp-queue://ID:ubuntu-14-dev-49451-1495115456046-1:1:3" 

My consumer( client ) is written in C++, from onMessage() callback, I
receive the message :

Message ID =
ID:sensen-hyd-edge-demo-01-42179-1495108420785-1:1:1:1:3:-1:-1:2
Destination type = 3

And when I try to send back the reply with the destination from
message->getCMSReplyTo(), it gives me exception:

 Cannot publish to a deleted Destination: temp-queue://
FILE: activemq/core/kernels/ActiveMQSessionKernel.cpp, LINE: 1013
FILE: activemq/core/kernels/ActiveMQProducerKernel.cpp, LINE: 274
FILE: activemq/core/kernels/ActiveMQProducerKernel.cpp, LINE: 184
FILE: activemq/core/ActiveMQProducer.cpp, LINE: 100

I hope this is clearer. Do you still think the broker has advisory support
disabled? ( How to check this? ). 

Is this the right way to disable the watching of temp destination?

  amqConnFactory = new ActiveMQConnectionFactory(CONN); 
  amqConnFactory.setWatchTopicAdvisories(false);

Thanks a lot for your help.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/AMQCPP-Cannot-publish-to-a-delete-Destination-temp-queue-tp4672611p4726407.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Client compatibility of Artemis with AMQ and HQ

[Clebert Suconic]

I'm not sure about 2.4.7 but it should work.


The thing thought is the prefix on acceptors


With 2.1.0 destinations won't have prefixes.  So you may have to tweak the
configuration. Maybe having a different port for newer clients.



On Fri, May 19, 2017 at 9:46 AM Claudio Tagliola 
wrote:

> We have two separate projects in development, one project running on
> HornetQ 2.4.7 and another on ActiveMQ 5.8.0. Currently we are
> investigating in upgrading at least the HQ one to Artemis, as HQ is no
> longer maintained. Next to this, we might also migrate the AMQ one, to
> simplify our software stack. The question I have is: how feasible would
> these migrations be with respect to client compatibility? In our
> environment it is not possible to migrate all brokers and clients in a
> single sweep without major trouble. The migration obviously would be
> much easier if current clients can connect to Artemis on it's respective
> protocol handler. Do people already have experience with these
> migrations and are there any pitfalls we should be aware of?
>
> The background of this question is that we had some unexpected
> incompatibilities between client and broker when upgrading to a newer
> ActiveMQ, around the 5.3/5.4 versions. We will upgrade the clients as
> well, but this will take a few days/weeks to roll out completely.
>
> 
>
> The information in this e-mail is intended only for the person or entity
> to which it is addressed.
>
> It may contain confidential and /or privileged material. If someone other
> than the intended recipient should receive this e-mail, he / she shall not
> be entitled to read, disseminate, disclose or duplicate it.
>
> If you receive this e-mail unintentionally, please inform us immediately
> by "reply" and then delete it from your system. Although this information
> has been compiled with great care, neither IMC Financial Markets & Asset
> Management nor any of its related entities shall accept any responsibility
> for any errors, omissions or other inaccuracies in this information or for
> the consequences thereof, nor shall it be bound in any way by the contents
> of this e-mail or its attachments. In the event of incomplete or incorrect
> transmission, please return the e-mail to the sender and permanently delete
> this message and any attachments.
>
> Messages and attachments are scanned for all known viruses. Always scan
> attachments before opening them.
>
-- 
Clebert Suconic

JMX url in master/slave mode

[kpdude7]

How would someone programmatically access the correct JMX server in this
master/slave configuration? For example, I have the JMX url:

service:jmx:rmi:///jndi/rmi://${jmxTransferUrl}/jmxrmi

My JMS is using a failover url:
failover:(ssl://10.91.5.190:61616,ssl://10.91.5.115:61616)

What value should be substituted for ${jmxTransferUrl} above? Do I have to
try each IP in the failover url manually and catch an exception before
trying the next one? Is there another way to do this?

Thanks,
Kyle



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/JMX-url-in-master-slave-mode-tp4726404.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Migrating storage from 5.10.0 to 5.14.5

[christopher]

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: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

[Clebert Suconic]

Artemis has a new architecture and is more effective on keeping
managing connections. Starting from the Journal where we do everything
asynchronous using a lot less threads and more performant. It's the
reason why Artemis merged ActiveMQ.. and it's been quite improved at
2.1.0.. It's worth to at least check it.

On Fri, May 19, 2017 at 1:59 PM, Shobhana  wrote:
> @clebertsuconic, ActiveMQ also supports NIO and we have already configured to
> use it. How is this different from that supported in Artemis?
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Is-creating-thousands-of-connections-to-a-single-AMQ-broker-node-and-keeping-them-open-an-anti-patte-tp4726391p4726401.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.



-- 
Clebert Suconic

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

[Shobhana]

@clebertsuconic, ActiveMQ also supports NIO and we have already configured to
use it. How is this different from that supported in Artemis?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Is-creating-thousands-of-connections-to-a-single-AMQ-broker-node-and-keeping-them-open-an-anti-patte-tp4726391p4726401.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

[Shobhana]

Tim, each client process will open just one connection.
There can be hundreds of thousands of different client processes (as many as
no of users using our app) connected to the broker at the same time.

In another thread
(http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-becomes-unresponsive-after-sometime-td4725278.html#a4726390)
I had mentioned that broker becomes unresponsive after some time; wanted to
chcek if our usage itself was wrong; hence posted this thread.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Is-creating-thousands-of-connections-to-a-single-AMQ-broker-node-and-keeping-them-open-an-anti-patte-tp4726391p4726400.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Random port listening on 0.0.0.0 for tcp transport

[pheitman]

When I start up an activemq broker, besides listening on the configured ports
of 61616 and 8161 it is also listening on a random port. My problem is that
I can not find out how to configure the interface that it should listen on.
It listens on 0.0.0.0 which is not acceptable for my company's security
policies. 

Note that according to  IBM Ports used by activemq in HPC - United States
  ,

"c. Any random port like 37551, 35134 etc. : This port is used to
communicate with already connected clients."

Can someone tell me how to restrict this port to a particular IP address? Or
at least point to where in the code the socket is getting created? Thank
you.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Random-port-listening-on-0-0-0-0-for-tcp-transport-tp4726399.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ broker becomes unresponsive after sometime

[nigro_franz]

Hi!!!

In the last period I'm enjoying using this:  http://gceasy.io/
  

You need to pass the following JVM arguments: -XX:+PrintGCDetails
-XX:+PrintGCDateStamps -Xloggc:[file-path]

With [file-path] as the location where garbage collection log should be
saved.
Then run your tests and upload the log to http://gceasy.io/: you'll have
tons of graphs useful to get insights on the problem.

About G1: on Artemis we found that with a too big old generations G1 wasn't
fast enough on Full GCs (are single threaded on it!) while using
-XX:+UseParallelOldGC yes, so it worth to try it.

While If you have a Fedora machine wiht OpenJDK 8 or something similar, you
have the option to use -XX:+UseShenandoahGC and find out if the problem is
really a GC related one (do not use it in production yet!).
http://openjdk.java.net/jeps/189
If ShenandoahGC will solve the issue then it is very likely to be GC problem
:)





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-becomes-unresponsive-after-sometime-tp4725278p4726398.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ broker becomes unresponsive after sometime

[Shobhana]

Hahah .. that's okay :-)

I have never used JVisualVM; will understand how to use this tool and report
my observations. Thanks for all inputs so far!



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-becomes-unresponsive-after-sometime-tp4725278p4726397.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Client compatibility of Artemis with AMQ and HQ

[Claudio Tagliola]

We have two separate projects in development, one project running on
HornetQ 2.4.7 and another on ActiveMQ 5.8.0. Currently we are
investigating in upgrading at least the HQ one to Artemis, as HQ is no
longer maintained. Next to this, we might also migrate the AMQ one, to
simplify our software stack. The question I have is: how feasible would
these migrations be with respect to client compatibility? In our
environment it is not possible to migrate all brokers and clients in a
single sweep without major trouble. The migration obviously would be
much easier if current clients can connect to Artemis on it's respective
protocol handler. Do people already have experience with these
migrations and are there any pitfalls we should be aware of?

The background of this question is that we had some unexpected
incompatibilities between client and broker when upgrading to a newer
ActiveMQ, around the 5.3/5.4 versions. We will upgrade the clients as
well, but this will take a few days/weeks to roll out completely.



The information in this e-mail is intended only for the person or entity to 
which it is addressed.

It may contain confidential and /or privileged material. If someone other than 
the intended recipient should receive this e-mail, he / she shall not be 
entitled to read, disseminate, disclose or duplicate it.

If you receive this e-mail unintentionally, please inform us immediately by "reply" 
and then delete it from your system. Although this information has been compiled with great 
care, neither IMC Financial Markets & Asset Management nor any of its related entities 
shall accept any responsibility for any errors, omissions or other inaccuracies in this 
information or for the consequences thereof, nor shall it be bound in any way by the contents 
of this e-mail or its attachments. In the event of incomplete or incorrect transmission, 
please return the e-mail to the sender and permanently delete this message and any 
attachments.

Messages and attachments are scanned for all known viruses. Always scan 
attachments before opening them.

Re: AMQCPP -- Cannot publish to a delete Destination: temp-queue

[bobeo]

hi Tim,

I'm facing the same problem of Cannot publish to a deleted Destination:
temp-queue:// 

I've tried both Java server - C++ client and C++ server - C++ client , but
both end up with the same error "Cannot publish to a deleted Destination:
temp-queue://"

I'm using Activemq 3.9.1 on Ubuntu. I've attach my unit test in cpp in case
you need to reproduce the problem.

Thanks.

testActiveMQ_RequestResponse.cpp

  



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/AMQCPP-Cannot-publish-to-a-delete-Destination-temp-queue-tp4672611p4726381.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

[Clebert Suconic]

Why don't you look at ActivMQ Artemis.

It's using NIO/epoll so it won't use as much memory as you keep lots
of active connections.



On Fri, May 19, 2017 at 8:42 AM, Tim Bain  wrote:
> If you have many connections from a single client process, then yes, that's
> an antipattern. Connection setup/teardown is somewhat expensive (and
> everyone will have to do it at the same time if the broker restarts), so
> you should be minimizing the number if possible by using a pooling
> connection factory. The broker also has to do a small amount of work to
> send keepalive messages and check for idle connections, if you're using
> keepalives; that's probably not a huge drain on system resources, but
> there's no reason to do more of it than you have to.
>
> If you have 100,000 separate client processes, then there's nothing you can
> do to improve that as long as the broker process is holding up OK. (If not,
> increase RAM and/or put it on a machine with beefier CPUs, as needed.) The
> antipattern is many connections from a single process, not having lots of
> long-running idle connections (though you will incur the costs I described
> above).
>
> Tim
>
> On May 19, 2017 3:53 AM, "Shobhana"  wrote:
>
>> We use a single AMQ broker (using 5.14.1 version) node to exchange MQTT
>> messages between our server and apps running on mobile devices (both
>> Android
>> and iOS).
>> The app establishes a connection with AMQ broker using Eclipse Paho client
>> lib. To be able to receive messages as soon as they are published, the app
>> keeps this connection open all the time. Even when the app is closed, a
>> background service gets started (in case of Android) which establishes a
>> connection with the broker.
>> In effect, if there are 10 users using the app, there would be 10
>> connections to AMQ broker. Is there any known issue in using AMQ broker
>> this
>> way?
>>
>>
>>
>> --
>> View this message in context: http://activemq.2283324.n4.
>> nabble.com/Is-creating-thousands-of-connections-to-a-
>> single-AMQ-broker-node-and-keeping-them-open-an-anti-patte-tp4726391.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>



-- 
Clebert Suconic

Re: ActiveMQ broker becomes unresponsive after sometime

[Tim Bain]

My brain swapped the units in your description, to an 8 minute GC with
unresponsiveness 15 seconds later. Sorry for the confusion.

8 seconds is long, but not unheard of, especially if the heap is large. G1
aims to shorten the Old Gen GC pause time by doing multiple small GCs of
Old Gen rather than a full GC (though it'll fall back to a full GC if the
incremental Old Gen collects don't work for some reason), so you you might
be happier with it if you care about pause times. But I'd have expected
lots and lots of full GCs if you were hitting CMS's failure mode, so GC no
longer sounds like our problem.

Can you use JVisualVM's CPU sampler (attach via JMX) to see what the broker
is spending its time on when you're in the unresponsive state? That might
give us more information.

Tim

On May 19, 2017 3:42 AM, "Shobhana"  wrote:

> Tim, full GC takes 8 seconds, not 8 minutes.
>
> Also, after full GC, large amount of memory is reclaimed (13G to <2G) :
>
> 2017-05-17T14:01:46.179+0530: 34205.488: [Full
> GC2017-05-17T14:01:46.179+0530: 34205.488: [CMS:
> 13039360K->1895795K(26214400K), 8.5260340 secs]
> 13578056K->1895795K(27158144K), [CMS Perm : 33865K->33826K(131072K)],
> 8.5261390 secs] [Times: user=8.87 sys=0.00, real=8.52 secs]
>
> Considering so much memory is freed up, do you think fragmentation would
> still be a cause for concern? I checked for size of few objects in histo
> report but couldn't find any object greater than 1.5KB.
>
> Haven't used JConsole, but from GC logs I see just one or 2 full GCs before
> broker becomes unresponsive.
>
> I'll also try by switching to G1GC and see if it makes any difference.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMQ-broker-becomes-unresponsive-after-
> sometime-tp4725278p4726390.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

[Tim Bain]

If you have many connections from a single client process, then yes, that's
an antipattern. Connection setup/teardown is somewhat expensive (and
everyone will have to do it at the same time if the broker restarts), so
you should be minimizing the number if possible by using a pooling
connection factory. The broker also has to do a small amount of work to
send keepalive messages and check for idle connections, if you're using
keepalives; that's probably not a huge drain on system resources, but
there's no reason to do more of it than you have to.

If you have 100,000 separate client processes, then there's nothing you can
do to improve that as long as the broker process is holding up OK. (If not,
increase RAM and/or put it on a machine with beefier CPUs, as needed.) The
antipattern is many connections from a single process, not having lots of
long-running idle connections (though you will incur the costs I described
above).

Tim

On May 19, 2017 3:53 AM, "Shobhana"  wrote:

> We use a single AMQ broker (using 5.14.1 version) node to exchange MQTT
> messages between our server and apps running on mobile devices (both
> Android
> and iOS).
> The app establishes a connection with AMQ broker using Eclipse Paho client
> lib. To be able to receive messages as soon as they are published, the app
> keeps this connection open all the time. Even when the app is closed, a
> background service gets started (in case of Android) which establishes a
> connection with the broker.
> In effect, if there are 10 users using the app, there would be 10
> connections to AMQ broker. Is there any known issue in using AMQ broker
> this
> way?
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Is-creating-thousands-of-connections-to-a-
> single-AMQ-broker-node-and-keeping-them-open-an-anti-patte-tp4726391.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Pure JMS management

[Clebert Suconic]

Create a JIRA as well.  Thanks.
On Fri, May 19, 2017 at 2:21 AM Guillaume Nodet  wrote:

> It seems to work well for me.
> I'll run a full build and will create a PR.
>
> 2017-05-19 8:03 GMT+02:00 Guillaume Nodet :
>
> > I'm enhancing a layer in OSGi to support Artemis, and I'd like to avoid
> > adding package dependencies.
> > That's why I'm using the connection's classloader to load the needed
> > class, as it's not available from the class which defines this code.
> >
> > To refine my question further: could the reply be typed as a text message
> > rather than not typed ? This would allow retrieving the json body as a
> > string.
> > Basically, I'm proposing the following patch:
> >
> > *---
> >
> a/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/impl/ManagementServiceImpl.java*
> >
> > *+++
> >
> b/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/impl/ManagementServiceImpl.java*
> >
> > @@ -370,6 +370,7 @@ public class ManagementServiceImpl implements
> > ManagementService {
> >
> >message = message.toCore();
> >
> >// a reply message is sent with the result stored in the message
> > body.
> >
> >CoreMessage reply = new CoreMessage(storageManager.generateID(),
> > 512);
> >
> > +  reply.setType(Message.TEXT_TYPE);
> >
> >reply.setReplyTo(message.getReplyTo());
> >
> >
> >
> >String resourceName = message.getStringProperty(
> > ManagementHelper.HDR_RESOURCE_NAME);
> >
> >
> > 2017-05-19 3:10 GMT+02:00 Clebert Suconic :
> >
> >> @Tim Bain: yes.. Artemis from what I see on the class Names (I also
> >> spoke to him gnodet on the IRC channel earlier today).
> >>
> >> @gnodet: I am not understanding why you would need to use reflection.
> >> You can just simply use JMSManagementHelper directly. they are all
> >> static methods...
> >>
> >>
> >> This example here, part of distribution under
> >> examples/features/standard/management shows how it was intended to be
> >> used:
> >>
> >>
> >> https://github.com/apache/activemq-artemis/blob/master/examp
> >> les/features/standard/management/src/main/java/org/apache/ac
> >> tivemq/artemis/jms/example/ManagementExample.java
> >>
> >>
> >>
> >> Maybe I"m misunderstanding your question?
> >>
> >> On Thu, May 18, 2017 at 6:23 PM, Guillaume Nodet 
> >> wrote:
> >> > I'm trying do perform management operation with pure JMS api.
> >> > To retrieve the list of queues, I'm currently using the following
> code:
> >> >
> >> > QueueSession session = ((QueueConnection)
> >> > connection).createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
> >> > Queue managementQueue = session.createQueue("activemq.management");
> >> > QueueRequestor requestor = new QueueRequestor(session,
> managementQueue);
> >> > connection.start();
> >> > TextMessage m = session.createTextMessage();
> >> > m.setStringProperty("_AMQ_ResourceName", "broker");
> >> > m.setStringProperty("_AMQ_OperationName", "getQueueNames");
> >> > m.setText("[\"" + routing + "\"]");
> >> > Message reply = requestor.request(m);
> >> > Class mgmtHelperClass =
> >> > connection.getClass().getClassLoader().loadClass("org.apache
> >> .activemq.artemis.api.jms.management.JMSManagementHelper");
> >> > Method getResultsMethod = mgmtHelperClass.getMethod("getResults",
> >> > Message.class);
> >> > Object[] results = (Object[]) getResultsMethod.invoke(null, reply);
> >> > List names = new ArrayList<>();
> >> > for (Object o : (Object[]) (results[0])) {
> >> > names.add(o.toString());
> >> > }
> >> > return names;
> >> >
> >> >
> >> > It works, but I think I should not have to use reflection to access
> the
> >> > result message, hence the use of reflection to access the
> >> > JMSManagementHelper methods.
> >> > It seems to me the reply should be of type TextMessage, but it's
> >> currently
> >> > untyped, so I can't use TextMessage#getText to retrieve the json
> result,
> >> > and I can't find a way to retrieve it another way.
> >> > Do I miss anything ?
> >> >
> >> > --
> >> > 
> >> > Guillaume Nodet
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >>
> >
> >
> >
> > --
> > 
> > Guillaume Nodet
> >
> >
>
>
> --
> 
> Guillaume Nodet
>
-- 
Clebert Suconic

Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

[Shobhana]

We use a single AMQ broker (using 5.14.1 version) node to exchange MQTT
messages between our server and apps running on mobile devices (both Android
and iOS).
The app establishes a connection with AMQ broker using Eclipse Paho client
lib. To be able to receive messages as soon as they are published, the app
keeps this connection open all the time. Even when the app is closed, a
background service gets started (in case of Android) which establishes a
connection with the broker.
In effect, if there are 10 users using the app, there would be 10
connections to AMQ broker. Is there any known issue in using AMQ broker this
way?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Is-creating-thousands-of-connections-to-a-single-AMQ-broker-node-and-keeping-them-open-an-anti-patte-tp4726391.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ broker becomes unresponsive after sometime

[Shobhana]

Tim, full GC takes 8 seconds, not 8 minutes.

Also, after full GC, large amount of memory is reclaimed (13G to <2G) :

2017-05-17T14:01:46.179+0530: 34205.488: [Full
GC2017-05-17T14:01:46.179+0530: 34205.488: [CMS:
13039360K->1895795K(26214400K), 8.5260340 secs]
13578056K->1895795K(27158144K), [CMS Perm : 33865K->33826K(131072K)],
8.5261390 secs] [Times: user=8.87 sys=0.00, real=8.52 secs] 

Considering so much memory is freed up, do you think fragmentation would
still be a cause for concern? I checked for size of few objects in histo
report but couldn't find any object greater than 1.5KB.

Haven't used JConsole, but from GC logs I see just one or 2 full GCs before
broker becomes unresponsive.

I'll also try by switching to G1GC and see if it makes any difference.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-becomes-unresponsive-after-sometime-tp4725278p4726390.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Pure JMS management

[Guillaume Nodet]

It seems to work well for me.
I'll run a full build and will create a PR.

2017-05-19 8:03 GMT+02:00 Guillaume Nodet :

> I'm enhancing a layer in OSGi to support Artemis, and I'd like to avoid
> adding package dependencies.
> That's why I'm using the connection's classloader to load the needed
> class, as it's not available from the class which defines this code.
>
> To refine my question further: could the reply be typed as a text message
> rather than not typed ? This would allow retrieving the json body as a
> string.
> Basically, I'm proposing the following patch:
>
> *---
> a/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/impl/ManagementServiceImpl.java*
>
> *+++
> b/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/impl/ManagementServiceImpl.java*
>
> @@ -370,6 +370,7 @@ public class ManagementServiceImpl implements
> ManagementService {
>
>message = message.toCore();
>
>// a reply message is sent with the result stored in the message
> body.
>
>CoreMessage reply = new CoreMessage(storageManager.generateID(),
> 512);
>
> +  reply.setType(Message.TEXT_TYPE);
>
>reply.setReplyTo(message.getReplyTo());
>
>
>
>String resourceName = message.getStringProperty(
> ManagementHelper.HDR_RESOURCE_NAME);
>
>
> 2017-05-19 3:10 GMT+02:00 Clebert Suconic :
>
>> @Tim Bain: yes.. Artemis from what I see on the class Names (I also
>> spoke to him gnodet on the IRC channel earlier today).
>>
>> @gnodet: I am not understanding why you would need to use reflection.
>> You can just simply use JMSManagementHelper directly. they are all
>> static methods...
>>
>>
>> This example here, part of distribution under
>> examples/features/standard/management shows how it was intended to be
>> used:
>>
>>
>> https://github.com/apache/activemq-artemis/blob/master/examp
>> les/features/standard/management/src/main/java/org/apache/ac
>> tivemq/artemis/jms/example/ManagementExample.java
>>
>>
>>
>> Maybe I"m misunderstanding your question?
>>
>> On Thu, May 18, 2017 at 6:23 PM, Guillaume Nodet 
>> wrote:
>> > I'm trying do perform management operation with pure JMS api.
>> > To retrieve the list of queues, I'm currently using the following code:
>> >
>> > QueueSession session = ((QueueConnection)
>> > connection).createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
>> > Queue managementQueue = session.createQueue("activemq.management");
>> > QueueRequestor requestor = new QueueRequestor(session, managementQueue);
>> > connection.start();
>> > TextMessage m = session.createTextMessage();
>> > m.setStringProperty("_AMQ_ResourceName", "broker");
>> > m.setStringProperty("_AMQ_OperationName", "getQueueNames");
>> > m.setText("[\"" + routing + "\"]");
>> > Message reply = requestor.request(m);
>> > Class mgmtHelperClass =
>> > connection.getClass().getClassLoader().loadClass("org.apache
>> .activemq.artemis.api.jms.management.JMSManagementHelper");
>> > Method getResultsMethod = mgmtHelperClass.getMethod("getResults",
>> > Message.class);
>> > Object[] results = (Object[]) getResultsMethod.invoke(null, reply);
>> > List names = new ArrayList<>();
>> > for (Object o : (Object[]) (results[0])) {
>> > names.add(o.toString());
>> > }
>> > return names;
>> >
>> >
>> > It works, but I think I should not have to use reflection to access the
>> > result message, hence the use of reflection to access the
>> > JMSManagementHelper methods.
>> > It seems to me the reply should be of type TextMessage, but it's
>> currently
>> > untyped, so I can't use TextMessage#getText to retrieve the json result,
>> > and I can't find a way to retrieve it another way.
>> > Do I miss anything ?
>> >
>> > --
>> > 
>> > Guillaume Nodet
>>
>>
>>
>> --
>> Clebert Suconic
>>
>
>
>
> --
> 
> Guillaume Nodet
>
>


-- 

Guillaume Nodet

Re: Pure JMS management

[Guillaume Nodet]

I'm enhancing a layer in OSGi to support Artemis, and I'd like to avoid
adding package dependencies.
That's why I'm using the connection's classloader to load the needed class,
as it's not available from the class which defines this code.

To refine my question further: could the reply be typed as a text message
rather than not typed ? This would allow retrieving the json body as a
string.
Basically, I'm proposing the following patch:

*---
a/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/impl/ManagementServiceImpl.java*

*+++
b/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/impl/ManagementServiceImpl.java*

@@ -370,6 +370,7 @@ public class ManagementServiceImpl implements
ManagementService {

   message = message.toCore();

   // a reply message is sent with the result stored in the message
body.

   CoreMessage reply = new CoreMessage(storageManager.generateID(),
512);

+  reply.setType(Message.TEXT_TYPE);

   reply.setReplyTo(message.getReplyTo());



   String resourceName =
message.getStringProperty(ManagementHelper.HDR_RESOURCE_NAME);


2017-05-19 3:10 GMT+02:00 Clebert Suconic :

> @Tim Bain: yes.. Artemis from what I see on the class Names (I also
> spoke to him gnodet on the IRC channel earlier today).
>
> @gnodet: I am not understanding why you would need to use reflection.
> You can just simply use JMSManagementHelper directly. they are all
> static methods...
>
>
> This example here, part of distribution under
> examples/features/standard/management shows how it was intended to be
> used:
>
>
> https://github.com/apache/activemq-artemis/blob/master/examp
> les/features/standard/management/src/main/java/org/apache/
> activemq/artemis/jms/example/ManagementExample.java
>
>
>
> Maybe I"m misunderstanding your question?
>
> On Thu, May 18, 2017 at 6:23 PM, Guillaume Nodet 
> wrote:
> > I'm trying do perform management operation with pure JMS api.
> > To retrieve the list of queues, I'm currently using the following code:
> >
> > QueueSession session = ((QueueConnection)
> > connection).createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
> > Queue managementQueue = session.createQueue("activemq.management");
> > QueueRequestor requestor = new QueueRequestor(session, managementQueue);
> > connection.start();
> > TextMessage m = session.createTextMessage();
> > m.setStringProperty("_AMQ_ResourceName", "broker");
> > m.setStringProperty("_AMQ_OperationName", "getQueueNames");
> > m.setText("[\"" + routing + "\"]");
> > Message reply = requestor.request(m);
> > Class mgmtHelperClass =
> > connection.getClass().getClassLoader().loadClass("org.
> apache.activemq.artemis.api.jms.management.JMSManagementHelper");
> > Method getResultsMethod = mgmtHelperClass.getMethod("getResults",
> > Message.class);
> > Object[] results = (Object[]) getResultsMethod.invoke(null, reply);
> > List names = new ArrayList<>();
> > for (Object o : (Object[]) (results[0])) {
> > names.add(o.toString());
> > }
> > return names;
> >
> >
> > It works, but I think I should not have to use reflection to access the
> > result message, hence the use of reflection to access the
> > JMSManagementHelper methods.
> > It seems to me the reply should be of type TextMessage, but it's
> currently
> > untyped, so I can't use TextMessage#getText to retrieve the json result,
> > and I can't find a way to retrieve it another way.
> > Do I miss anything ?
> >
> > --
> > 
> > Guillaume Nodet
>
>
>
> --
> Clebert Suconic
>



-- 

Guillaume Nodet