Re: Apache Artemis - Stress-test time

[Martyn Taylor]

Francesco,

I think you've stumbled upon a bug.  In order to support the Exact;y Once 4
way ack for MQTT we schedule pub rel messages on a management queue (in
case we need to resend).  It appears these were not getting removed from
the queue after the broker got the PubComp back from the client, which is
why you're seeing the management queue size grow.

I've opened a JIRA [1] and sent a fix [2].

1. https://issues.apache.org/jira/browse/ARTEMIS-1061
2. https://github.com/apache/activemq-artemis/pull/1122

Thanks
Martyn

On Wed, Mar 22, 2017 at 6:55 PM, Clebert Suconic 
wrote:

> it's MQTT.. I would recommend you using block for these address
> though.. unless you really need paging.
>
> or a bigger maxSize and bigger memory.
>
> On Wed, Mar 22, 2017 at 1:39 PM, Francesco PADOVANI
>  wrote:
> > Hi all,
> >
> > we're currently performing some stress-test sessions against our Apache
> Artemis instance.
> > To do this, we have developed a java program which uses the paho
> library. We are simulating (just to start) 1000 subscriber clients each one
> who connects in qos2 and subscribes 50 specific topics dedicated to him,
> and other 1000 publisher clients each one who connects in qos2 and
> publishes a retained message every second on a specific topic inside the
> range of the 50 of its own dedicated subscriber.
> >
> >
> > Hence, for every publisher there's a subscriber: each subscriber
> subscribes 50 topics. Each publisher publishes on a single specific topic.
> The total amount of topics (addresses) involved are 1000x50 = 5.
> >
> >
> > Our Artemis instance runs on a Centos 7 Server (64bit) with 8GB of RAM
> (4GB Xms and Xmx heap) and 4 vCpu. Max number of processes for the artemis
> process is 4096. Max open files are 64000.
> >
> >
> > We are able to start 1000 publishers and 1000 subscribers. Cpu is fine.
> Memory increases time by time. At a certain point (after about 5 mins) heap
> goes full and Artemis starts to page... and this is its death! When the
> broker starts to page, it becomes unusable. Almost all connected clients
> are disconnected, ram is never more freed and the file system partition
> used for paging (no SSD unfortunately) increases time by time since it
> reaches 100%.
> >
> >
> > As I said, Artemis works well until it starts to page. Exactly in the
> moment I see the following lines inside log:
> >
> > ...
> >
> > AMQ222038: Starting paging on address 
> > '.cro.plantid.1075528.gwid.50437.device_state';
> size is
> >
> > currently: 1,521 bytes; max-size-bytes: -1
> >
> > AMQ222038: Starting paging on address 
> > '.cro.plantid.1075520.gwid.50451.device_state';
> size is currently: 1,521 bytes; max-size-bytes: -1
> >
> > ...
> >
> > AMQ222038: Starting paging on address '$sys.mqtt.queue.qos2.50687s';
> size is currently: 107,379 bytes; max-size-bytes: -1
> >
> >
> > It seems that addresses related to the topics (like
> "cro.plantid.1075520.gwid.50451.device_state") are always of the same
> size (I think because there are always only a publisher and a subscriber
> and on topics are sent only retained messages, where the last one replace
> the previous one).
> >
> > Instead, "system" addresses (like "$sys.mqtt.queue.qos2.50687s") grow
> constantly.
> >
> >
> > Please, could someone explain me how to manage system addresses and how
> to do in order they don't grow so much? maybe I'm wrong somewhere inside
> the configuration? Which is the better configuration for my specific case
> (the one we are testing as above)?
> >
> >
> > Thanks so much in advance, guys.
> >
> >
> > Francesco
> >
> >
> > 
> >
> > Ce message, ainsi que tous les fichiers joints à ce message, peuvent
> contenir des informations sensibles et/ ou confidentielles ne devant pas
> être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que
> vous recevez ce message par erreur), nous vous remercions de le notifier
> immédiatement à son expéditeur, et de détruire ce message. Toute copie,
> divulgation, modification, utilisation ou diffusion, non autorisée, directe
> ou indirecte, de tout ou partie de ce message, est strictement interdite.
> >
> >
> > This e-mail, and any document attached hereby, may contain confidential
> and/or privileged information. If you are not the intended recipient (or
> have received this e-mail in error) please notify the sender immediately
> and destroy this e-mail. Any unauthorized, direct or indirect, copying,
> disclosure, distribution or other use of the material or parts thereof is
> strictly forbidden.
>
>
>
> --
> Clebert Suconic
>

Re: Artemis 2.0: How to get the list of Queues and Topics from a server? (Fails in 2.0 with v1.5.3 code)

[titou10 titou10]

Thanks again for your help

2017-03-22 16:06 GMT-04:00 Justin Bertram :
> Did you try modifying your code as I recommended?  If so, what was the result?
>
> I modified the "management" example locally as a proof-of-concept and it 
> worked fine.  Here's the code (comments redacted):
>
>  QueueSession session = connection.createQueueSession(false, 
> Session.AUTO_ACKNOWLEDGE);
>  Queue managementQueue = 
> ActiveMQJMSClient.createQueue("activemq.management");
>  QueueRequestor requestor = new QueueRequestor(session, 
> managementQueue);
>  connection.start();
>  Message m = session.createMessage();
>  JMSManagementHelper.putAttribute(m, ResourceNames.BROKER, 
> "queueNames");
>  Message reply = requestor.request(m);
>  Object[] queueNames = (Object[]) 
> JMSManagementHelper.getResult(reply);
>  for (Object queueName : queueNames) {
> System.out.println("Queue name: " + queueName);
>  }
>
> To be clear, 
> org.apache.activemq.artemis.api.core.management.ResourceNames.BROKER 
> essentially links to 
> org.apache.activemq.artemis.api.core.management.ActiveMQServerControl.  Among 
> others, it has methods getQueueNames() and getAddressNames() which should 
> suffice for your purposes.  The idea of a JMS "server" and even a JMS topic 
> was always a thin facade on top of the core implementation.  From a 
> management and configuration perspective this facade has been removed to 
> allow cleaner support for additional protocols (e.g. AMQP, MQTT, STOMP, etc.).
>

I understand, and this is was I was asking for (what features have
been changed/removed deprecated, in this case the JMS management
facade has been removed...)

Yes I did the same test as you in parallel and the getQueueName() does
not fails but it returns the Queues and the Topics mixed (ie
multicast..)
How about Topics, there is no "getTopicNames()"  method in
ActiveMQServerControl and logically causes this exception on the
server...

Caused by: java.lang.IllegalArgumentException: AMQ119068: no getter
method for topicNames
at 
org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.getAttribute(ManagementServiceImpl.java:687)
[artemis-server-2.0.0.jar:2.0.0]
... 30 more

Is there another way to list the Topics destination from a v2.0.x
server and to get a "clean" list of Queues names from a JMS point of
view?

Thanks.

Denis (Author of JMSToolBox on sourceforge)

> Hope that helps.
>
>
> Justin
>
> - Original Message -
> From: "titou10 titou10" 
> To: users@activemq.apache.org
> Sent: Wednesday, March 22, 2017 2:35:43 PM
> Subject: Re: Artemis 2.0: How to get the list of Queues and Topics from a 
> server? (Fails in 2.0 with v1.5.3 code)
>
> Thanks for your answer
>
>>> how to retrieve the list of Queues and Topics from an Artemis v2.0.0 server?
>>
>> I think you'll be good to just use 
>> org.apache.activemq.artemis.api.core.management.ResourceNames.BROKER rather 
>> than JMS_SERVER with your existing code.
>
> It will not work...
> Given the v1.5.x doc, JMS_SERVER (="jms.server") is linked to the
> "org.apache.activemq.artemis.api.jms.management.JMSServerControl"
> control class. This class has amongst many other methods, 2 methods
> named "getQueueNames()" and "getTopicNames()"
> This class has been removed from v2.0.0
> I wasn't able to find to what control class the BROKER (="broker")
> value is associated to in v2.0.0...
>
> I was not able to find also if the methods from the JMSServerControl
> that has been removed are available somewhere else in v2.0.x
>
> So the question is still there, how to retrieve the list of topics and
> queues from a v2.0.x Artemis server from a client?
>
> Thanks
>
> Denis (Author of JMSToolBox on sourceforge)

Re: Artemis 2.0: How to get the list of Queues and Topics from a server? (Fails in 2.0 with v1.5.3 code)

[Justin Bertram]

Did you try modifying your code as I recommended?  If so, what was the result?

I modified the "management" example locally as a proof-of-concept and it worked 
fine.  Here's the code (comments redacted):

 QueueSession session = connection.createQueueSession(false, 
Session.AUTO_ACKNOWLEDGE);
 Queue managementQueue = 
ActiveMQJMSClient.createQueue("activemq.management");
 QueueRequestor requestor = new QueueRequestor(session, 
managementQueue);
 connection.start();
 Message m = session.createMessage();
 JMSManagementHelper.putAttribute(m, ResourceNames.BROKER, 
"queueNames");  
 Message reply = requestor.request(m);
 Object[] queueNames = (Object[]) JMSManagementHelper.getResult(reply);
 for (Object queueName : queueNames) {
System.out.println("Queue name: " + queueName);
 }

To be clear, 
org.apache.activemq.artemis.api.core.management.ResourceNames.BROKER 
essentially links to 
org.apache.activemq.artemis.api.core.management.ActiveMQServerControl.  Among 
others, it has methods getQueueNames() and getAddressNames() which should 
suffice for your purposes.  The idea of a JMS "server" and even a JMS topic was 
always a thin facade on top of the core implementation.  From a management and 
configuration perspective this facade has been removed to allow cleaner support 
for additional protocols (e.g. AMQP, MQTT, STOMP, etc.).

Hope that helps.


Justin

- Original Message -
From: "titou10 titou10" 
To: users@activemq.apache.org
Sent: Wednesday, March 22, 2017 2:35:43 PM
Subject: Re: Artemis 2.0: How to get the list of Queues and Topics from a 
server? (Fails in 2.0 with v1.5.3 code)

Thanks for your answer

>> how to retrieve the list of Queues and Topics from an Artemis v2.0.0 server?
>
> I think you'll be good to just use 
> org.apache.activemq.artemis.api.core.management.ResourceNames.BROKER rather 
> than JMS_SERVER with your existing code.

It will not work...
Given the v1.5.x doc, JMS_SERVER (="jms.server") is linked to the
"org.apache.activemq.artemis.api.jms.management.JMSServerControl"
control class. This class has amongst many other methods, 2 methods
named "getQueueNames()" and "getTopicNames()"
This class has been removed from v2.0.0
I wasn't able to find to what control class the BROKER (="broker")
value is associated to in v2.0.0...

I was not able to find also if the methods from the JMSServerControl
that has been removed are available somewhere else in v2.0.x

So the question is still there, how to retrieve the list of topics and
queues from a v2.0.x Artemis server from a client?

Thanks

Denis (Author of JMSToolBox on sourceforge)

Re: Artemis 2.0 - Karaf - JsonLoader not found issue

[mtod]

Seems this has to do with adding Hawtio to the system.

Seems to work fine on a local instance.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-2-0-Karaf-JsonLoader-not-found-issue-tp4723979p4724007.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Artemis 2.0: How to get the list of Queues and Topics from a server? (Fails in 2.0 with v1.5.3 code)

[titou10 titou10]

Thanks for your answer

>> how to retrieve the list of Queues and Topics from an Artemis v2.0.0 server?
>
> I think you'll be good to just use 
> org.apache.activemq.artemis.api.core.management.ResourceNames.BROKER rather 
> than JMS_SERVER with your existing code.

It will not work...
Given the v1.5.x doc, JMS_SERVER (="jms.server") is linked to the
"org.apache.activemq.artemis.api.jms.management.JMSServerControl"
control class. This class has amongst many other methods, 2 methods
named "getQueueNames()" and "getTopicNames()"
This class has been removed from v2.0.0
I wasn't able to find to what control class the BROKER (="broker")
value is associated to in v2.0.0...

I was not able to find also if the methods from the JMSServerControl
that has been removed are available somewhere else in v2.0.x

So the question is still there, how to retrieve the list of topics and
queues from a v2.0.x Artemis server from a client?

Thanks

Denis (Author of JMSToolBox on sourceforge)

Re: Apache Artemis - Stress-test time

[Clebert Suconic]

it's MQTT.. I would recommend you using block for these address
though.. unless you really need paging.

or a bigger maxSize and bigger memory.

On Wed, Mar 22, 2017 at 1:39 PM, Francesco PADOVANI
 wrote:
> Hi all,
>
> we're currently performing some stress-test sessions against our Apache 
> Artemis instance.
> To do this, we have developed a java program which uses the paho library. We 
> are simulating (just to start) 1000 subscriber clients each one who connects 
> in qos2 and subscribes 50 specific topics dedicated to him, and other 1000 
> publisher clients each one who connects in qos2 and  publishes a retained 
> message every second on a specific topic inside the range of the 50 of its 
> own dedicated subscriber.
>
>
> Hence, for every publisher there's a subscriber: each subscriber subscribes 
> 50 topics. Each publisher publishes on a single specific topic. The total 
> amount of topics (addresses) involved are 1000x50 = 5.
>
>
> Our Artemis instance runs on a Centos 7 Server (64bit) with 8GB of RAM (4GB 
> Xms and Xmx heap) and 4 vCpu. Max number of processes for the artemis process 
> is 4096. Max open files are 64000.
>
>
> We are able to start 1000 publishers and 1000 subscribers. Cpu is fine. 
> Memory increases time by time. At a certain point (after about 5 mins) heap 
> goes full and Artemis starts to page... and this is its death! When the 
> broker starts to page, it becomes unusable. Almost all connected clients are 
> disconnected, ram is never more freed and the file system partition used for 
> paging (no SSD unfortunately) increases time by time since it reaches 100%.
>
>
> As I said, Artemis works well until it starts to page. Exactly in the moment 
> I see the following lines inside log:
>
> ...
>
> AMQ222038: Starting paging on address 
> '.cro.plantid.1075528.gwid.50437.device_state'; size is
>
> currently: 1,521 bytes; max-size-bytes: -1
>
> AMQ222038: Starting paging on address 
> '.cro.plantid.1075520.gwid.50451.device_state'; size is currently: 1,521 
> bytes; max-size-bytes: -1
>
> ...
>
> AMQ222038: Starting paging on address '$sys.mqtt.queue.qos2.50687s'; size is 
> currently: 107,379 bytes; max-size-bytes: -1
>
>
> It seems that addresses related to the topics (like 
> "cro.plantid.1075520.gwid.50451.device_state") are always of the same size (I 
> think because there are always only a publisher and a subscriber and on 
> topics are sent only retained messages, where the last one replace the 
> previous one).
>
> Instead, "system" addresses (like "$sys.mqtt.queue.qos2.50687s") grow 
> constantly.
>
>
> Please, could someone explain me how to manage system addresses and how to do 
> in order they don't grow so much? maybe I'm wrong somewhere inside the 
> configuration? Which is the better configuration for my specific case (the 
> one we are testing as above)?
>
>
> Thanks so much in advance, guys.
>
>
> Francesco
>
>
> 
>
> Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir 
> des informations sensibles et/ ou confidentielles ne devant pas être 
> divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous 
> recevez ce message par erreur), nous vous remercions de le notifier 
> immédiatement à son expéditeur, et de détruire ce message. Toute copie, 
> divulgation, modification, utilisation ou diffusion, non autorisée, directe 
> ou indirecte, de tout ou partie de ce message, est strictement interdite.
>
>
> This e-mail, and any document attached hereby, may contain confidential 
> and/or privileged information. If you are not the intended recipient (or have 
> received this e-mail in error) please notify the sender immediately and 
> destroy this e-mail. Any unauthorized, direct or indirect, copying, 
> disclosure, distribution or other use of the material or parts thereof is 
> strictly forbidden.



-- 
Clebert Suconic

Re: Artemis 1.x support model

[Justin Bertram]

As far as I see it as long as there are community members willing to send PRs, 
committers willing to review and merge them, and then someone willing to 
perform a release then 1.x will live on.  There is no official "support model" 
as far as I'm aware.  There's just a community contributing to the project.


Justin

- Original Message -
From: "abhijith" 
To: users@activemq.apache.org
Sent: Wednesday, March 22, 2017 9:37:29 AM
Subject: Artemis 1.x support model

Congrats everyone on successful release. 

We are using Artemis v1.4 today and would like to know support model for 1.x
version after major version update.  Is there any plan to deprecate 1.x
version in near future and not accept any more bug submission? 

We are trying to determine when to upgrade to 2.x and knowing the
deprecation timeline would help us making this decision.

Thanks

Abhi



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-1-x-support-model-tp4723981.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Artemis 2.0: How to get the list of Queues and Topics from a server? (Fails in 2.0 with v1.5.3 code)

[Justin Bertram]

> how to retrieve the list of Queues and Topics from an Artemis v2.0.0 server?

I think you'll be good to just use 
org.apache.activemq.artemis.api.core.management.ResourceNames.BROKER rather 
than JMS_SERVER with your existing code.


> is there a migration/upgrade guide to upgrade from 1.5.x to 2.0.x?

There isn't a migration guide for 1.5.x to 2.0.x as such, but the documentation 
shipped with 2.0 should be up to date (although a few things might have been 
missed).


> or a least is there a list of "deprecated/removed/changed" features from 
> v1.5.x to 2.0.x?

The release notes [1] is the closest thing you'll find.


Justin

[1] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12338813

- Original Message -
From: "titou10 titou10" 
To: users@activemq.apache.org
Sent: Wednesday, March 22, 2017 1:01:31 PM
Subject: Artemis 2.0: How to get the list of Queues and Topics from a server? 
(Fails in 2.0 with v1.5.3 code)

Hi,
With Artemis v1.5.3, to retrieve the list of queues and topics, I was
using this code (inspired from the example)

Queue managementQueue = ActiveMQJMSClient.createQueue("activemq.management");
Session sessionJMS = jmsConnection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
QueueRequestor requestorJMS = new QueueRequestor((QueueSession)
sessionJMS, managementQueue);
Message m = sessionJMS.createMessage();
JMSManagementHelper.putAttribute(m, ResourceNames.JMS_SERVER,
"queueNames"); // "topicNames" for topics
Message r = requestorJMS.request(m);
Object q = JMSManagementHelper.getResult(r);
...

If I run this code from a client with the v1.5.3 jars to a v2.0.0 server I got:
An exception on the server:

Caused by: java.lang.IllegalArgumentException: AMQ119067: Cannot find
resource with name jms.server
at 
org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.getAttribute(ManagementServiceImpl.java:675)
[artemis-server-2.0.0.jar:2.0.0]
... 30 more

And an exception on the client:
java.lang.IndexOutOfBoundsException: readerIndex(22) + length(98)
exceeds writerIndex(116): UnpooledDuplicatedByteBuf(ridx: 22, widx:
116, cap: 451, unwrapped: UnpooledUnsafeHeapByteBuf(ridx: 439, widx:
451, cap: 451))
at 
io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1395)
at 
io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1389)
at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:850)
at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:858)
at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:649)
at 
org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readSimpleStringInternal(ChannelBufferWrapper.java:93)
at 
org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:73)
at 
org.apache.activemq.artemis.api.core.management.ManagementHelper.getResults(ManagementHelper.java:196)
at 
org.apache.activemq.artemis.api.core.management.ManagementHelper.getResult(ManagementHelper.java:224)
at 
org.apache.activemq.artemis.api.jms.management.JMSManagementHelper.getResult(JMSManagementHelper.java:149)
at 
org.apache.activemq.artemis.api.jms.management.JMSManagementHelper.getResult(JMSManagementHelper.java:139)

I tried to update the client jars to v2.0.0. In v1.5.3, the
"ResourceNames.JMS_SERVER" variable exists with value "jms.server", in
v2.0.0, The ResourceName has benne totally changed and no "JMS_SERVER"
variable anymore (and no "SERVER" lookalike variable..).

So the question are
- how to retrieve the list of Queues and Topics from an Artemis v2.0.0 server?
- is there a migration/upgrade guide to upgrade from 1.5.x to 2.0.x?
- or a least is there a list of "deprecated/removed/changed" features
from v1.5.x to 2.0.x?

Thanks

Denis (Author of JMSToolBox on sourceforge)

Artemis 1.x support model

[abhijith]

Congrats everyone on successful release. 

We are using Artemis v1.4 today and would like to know support model for 1.x
version after major version update.  Is there any plan to deprecate 1.x
version in near future and not accept any more bug submission? 

We are trying to determine when to upgrade to 2.x and knowing the
deprecation timeline would help us making this decision.

Thanks

Abhi



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Artemis-1-x-support-model-tp4723981.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Artemis 2.0: How to get the list of Queues and Topics from a server? (Fails in 2.0 with v1.5.3 code)

[titou10 titou10]

Hi,
With Artemis v1.5.3, to retrieve the list of queues and topics, I was
using this code (inspired from the example)

Queue managementQueue = ActiveMQJMSClient.createQueue("activemq.management");
Session sessionJMS = jmsConnection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
QueueRequestor requestorJMS = new QueueRequestor((QueueSession)
sessionJMS, managementQueue);
Message m = sessionJMS.createMessage();
JMSManagementHelper.putAttribute(m, ResourceNames.JMS_SERVER,
"queueNames"); // "topicNames" for topics
Message r = requestorJMS.request(m);
Object q = JMSManagementHelper.getResult(r);
...

If I run this code from a client with the v1.5.3 jars to a v2.0.0 server I got:
An exception on the server:

Caused by: java.lang.IllegalArgumentException: AMQ119067: Cannot find
resource with name jms.server
at 
org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.getAttribute(ManagementServiceImpl.java:675)
[artemis-server-2.0.0.jar:2.0.0]
... 30 more

And an exception on the client:
java.lang.IndexOutOfBoundsException: readerIndex(22) + length(98)
exceeds writerIndex(116): UnpooledDuplicatedByteBuf(ridx: 22, widx:
116, cap: 451, unwrapped: UnpooledUnsafeHeapByteBuf(ridx: 439, widx:
451, cap: 451))
at 
io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1395)
at 
io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1389)
at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:850)
at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:858)
at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:649)
at 
org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readSimpleStringInternal(ChannelBufferWrapper.java:93)
at 
org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:73)
at 
org.apache.activemq.artemis.api.core.management.ManagementHelper.getResults(ManagementHelper.java:196)
at 
org.apache.activemq.artemis.api.core.management.ManagementHelper.getResult(ManagementHelper.java:224)
at 
org.apache.activemq.artemis.api.jms.management.JMSManagementHelper.getResult(JMSManagementHelper.java:149)
at 
org.apache.activemq.artemis.api.jms.management.JMSManagementHelper.getResult(JMSManagementHelper.java:139)

I tried to update the client jars to v2.0.0. In v1.5.3, the
"ResourceNames.JMS_SERVER" variable exists with value "jms.server", in
v2.0.0, The ResourceName has benne totally changed and no "JMS_SERVER"
variable anymore (and no "SERVER" lookalike variable..).

So the question are
- how to retrieve the list of Queues and Topics from an Artemis v2.0.0 server?
- is there a migration/upgrade guide to upgrade from 1.5.x to 2.0.x?
- or a least is there a list of "deprecated/removed/changed" features
from v1.5.x to 2.0.x?

Thanks

Denis (Author of JMSToolBox on sourceforge)

Closing a ActiveMQMessageProducer after publishing asynchronously

[rth]

I am trying to determine if it is ok to close an ActiveMQMessageProducer
after it has been used to publish a message asynchronously. Presumably
publishing asynchronously uses a separate thread, which could be blocked
(perhaps because of flow control).

So, what happens if the publishing thread closes the producer before the
message was published?

For what it's worth, all my unit tests involving this scenario pass, but I'm
still not convinced.





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Closing-a-ActiveMQMessageProducer-after-publishing-asynchronously-tp4724001.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Apache Artemis - Stress-test time

[Clebert Suconic]

Well.  I always say you can't beat physics.  When u start to page that many
destinations you are doing a lot more IO. You can't make Artemis to go
faster than the physical barriers you have on disks.

You should probably use more memory.  Bigger global size.


Also look at the Tip of master (upcoming 2.0.1) as I committed a few
improvements.



On Wed, Mar 22, 2017 at 1:39 PM Francesco PADOVANI <
francesco.padov...@bticino.it> wrote:

> Hi all,
>
> we're currently performing some stress-test sessions against our Apache
> Artemis instance.
> To do this, we have developed a java program which uses the paho library.
> We are simulating (just to start) 1000 subscriber clients each one who
> connects in qos2 and subscribes 50 specific topics dedicated to him, and
> other 1000 publisher clients each one who connects in qos2 and  publishes a
> retained message every second on a specific topic inside the range of the
> 50 of its own dedicated subscriber.
>
>
> Hence, for every publisher there's a subscriber: each subscriber
> subscribes 50 topics. Each publisher publishes on a single specific topic.
> The total amount of topics (addresses) involved are 1000x50 = 5.
>
>
> Our Artemis instance runs on a Centos 7 Server (64bit) with 8GB of RAM
> (4GB Xms and Xmx heap) and 4 vCpu. Max number of processes for the artemis
> process is 4096. Max open files are 64000.
>
>
> We are able to start 1000 publishers and 1000 subscribers. Cpu is fine.
> Memory increases time by time. At a certain point (after about 5 mins) heap
> goes full and Artemis starts to page... and this is its death! When the
> broker starts to page, it becomes unusable. Almost all connected clients
> are disconnected, ram is never more freed and the file system partition
> used for paging (no SSD unfortunately) increases time by time since it
> reaches 100%.
>
>
> As I said, Artemis works well until it starts to page. Exactly in the
> moment I see the following lines inside log:
>
> ...
>
> AMQ222038: Starting paging on address
> '.cro.plantid.1075528.gwid.50437.device_state'; size is
>
> currently: 1,521 bytes; max-size-bytes: -1
>
> AMQ222038: Starting paging on address
> '.cro.plantid.1075520.gwid.50451.device_state'; size is currently: 1,521
> bytes; max-size-bytes: -1
>
> ...
>
> AMQ222038: Starting paging on address '$sys.mqtt.queue.qos2.50687s'; size
> is currently: 107,379 bytes; max-size-bytes: -1
>
>
> It seems that addresses related to the topics (like
> "cro.plantid.1075520.gwid.50451.device_state") are always of the same size
> (I think because there are always only a publisher and a subscriber and on
> topics are sent only retained messages, where the last one replace the
> previous one).
>
> Instead, "system" addresses (like "$sys.mqtt.queue.qos2.50687s") grow
> constantly.
>
>
> Please, could someone explain me how to manage system addresses and how to
> do in order they don't grow so much? maybe I'm wrong somewhere inside the
> configuration? Which is the better configuration for my specific case (the
> one we are testing as above)?
>
>
> Thanks so much in advance, guys.
>
>
> Francesco
>
>
> 
>
> Ce message, ainsi que tous les fichiers joints à ce message, peuvent
> contenir des informations sensibles et/ ou confidentielles ne devant pas
> être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que
> vous recevez ce message par erreur), nous vous remercions de le notifier
> immédiatement à son expéditeur, et de détruire ce message. Toute copie,
> divulgation, modification, utilisation ou diffusion, non autorisée, directe
> ou indirecte, de tout ou partie de ce message, est strictement interdite.
>
>
> This e-mail, and any document attached hereby, may contain confidential
> and/or privileged information. If you are not the intended recipient (or
> have received this e-mail in error) please notify the sender immediately
> and destroy this e-mail. Any unauthorized, direct or indirect, copying,
> disclosure, distribution or other use of the material or parts thereof is
> strictly forbidden.
>
-- 
Clebert Suconic

Apache Artemis - Stress-test time

[Francesco PADOVANI]

Hi all,

we're currently performing some stress-test sessions against our Apache Artemis 
instance.
To do this, we have developed a java program which uses the paho library. We 
are simulating (just to start) 1000 subscriber clients each one who connects in 
qos2 and subscribes 50 specific topics dedicated to him, and other 1000 
publisher clients each one who connects in qos2 and  publishes a retained 
message every second on a specific topic inside the range of the 50 of its own 
dedicated subscriber.


Hence, for every publisher there's a subscriber: each subscriber subscribes 50 
topics. Each publisher publishes on a single specific topic. The total amount 
of topics (addresses) involved are 1000x50 = 5.


Our Artemis instance runs on a Centos 7 Server (64bit) with 8GB of RAM (4GB Xms 
and Xmx heap) and 4 vCpu. Max number of processes for the artemis process is 
4096. Max open files are 64000.


We are able to start 1000 publishers and 1000 subscribers. Cpu is fine. Memory 
increases time by time. At a certain point (after about 5 mins) heap goes full 
and Artemis starts to page... and this is its death! When the broker starts to 
page, it becomes unusable. Almost all connected clients are disconnected, ram 
is never more freed and the file system partition used for paging (no SSD 
unfortunately) increases time by time since it reaches 100%.


As I said, Artemis works well until it starts to page. Exactly in the moment I 
see the following lines inside log:

...

AMQ222038: Starting paging on address 
'.cro.plantid.1075528.gwid.50437.device_state'; size is

currently: 1,521 bytes; max-size-bytes: -1

AMQ222038: Starting paging on address 
'.cro.plantid.1075520.gwid.50451.device_state'; size is currently: 1,521 bytes; 
max-size-bytes: -1

...

AMQ222038: Starting paging on address '$sys.mqtt.queue.qos2.50687s'; size is 
currently: 107,379 bytes; max-size-bytes: -1


It seems that addresses related to the topics (like 
"cro.plantid.1075520.gwid.50451.device_state") are always of the same size (I 
think because there are always only a publisher and a subscriber and on topics 
are sent only retained messages, where the last one replace the previous one).

Instead, "system" addresses (like "$sys.mqtt.queue.qos2.50687s") grow 
constantly.


Please, could someone explain me how to manage system addresses and how to do 
in order they don't grow so much? maybe I'm wrong somewhere inside the 
configuration? Which is the better configuration for my specific case (the one 
we are testing as above)?


Thanks so much in advance, guys.


Francesco




Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir 
des informations sensibles et/ ou confidentielles ne devant pas être 
divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous 
recevez ce message par erreur), nous vous remercions de le notifier 
immédiatement à son expéditeur, et de détruire ce message. Toute copie, 
divulgation, modification, utilisation ou diffusion, non autorisée, directe ou 
indirecte, de tout ou partie de ce message, est strictement interdite.


This e-mail, and any document attached hereby, may contain confidential and/or 
privileged information. If you are not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution 
or other use of the material or parts thereof is strictly forbidden.

Artemis 2.0 - Karaf - JsonLoader no found issue

[mtod]

Hi I'm loading up Artemis 2.0 on AWS EC2 in a karaf container.
It loaded fine and is working except for the following error when executing
listAllConsumersAsJSON() 

javax.management.RuntimeErrorException: java.lang.NoClassDefFoundError:
Could not initialize class org.apache.activemq.artemis.utils.JsonLoader
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:841)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:821)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at org.jolokia.handler.ExecHandler.doHandleRequest(ExecHandler.java:98)
at org.jolokia.handler.ExecHandler.doHandleRequest(ExecHandler.java:40)
at
org.jolokia.handler.JsonRequestHandler.handleRequest(JsonRequestHandler.java:89)
at
org.jolokia.backend.MBeanServerExecutorLocal.handleRequest(MBeanServerExecutorLocal.java:109)
at
org.jolokia.backend.MBeanServerHandler.dispatchRequest(MBeanServerHandler.java:159)
at
org.jolokia.backend.LocalRequestDispatcher.dispatchRequest(LocalRequestDispatcher.java:99)
at
org.jolokia.backend.BackendManager.callRequestDispatcher(BackendManager.java:413)
at
org.jolokia.backend.BackendManager.handleRequest(BackendManager.java:158)
at
org.jolokia.http.HttpRequestHandler.executeRequest(HttpRequestHandler.java:197)
at
org.jolokia.http.HttpRequestHandler.handlePostRequest(HttpRequestHandler.java:137)
at org.jolokia.http.AgentServlet$3.handleRequest(AgentServlet.java:420)
at org.jolokia.http.AgentServlet.handleSecurely(AgentServlet.java:301)
at org.jolokia.http.AgentServlet.handle(AgentServlet.java:277)
at org.jolokia.http.AgentServlet.doPost(AgentServlet.java:244)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772)
at
org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:193)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at io.hawt.web.AuthenticationFilter$3.run(AuthenticationFilter.java:227)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
io.hawt.web.AuthenticationFilter.executeAs(AuthenticationFilter.java:224)
at 
io.hawt.web.AuthenticationFilter.doFilter(AuthenticationFilter.java:162)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at 
io.hawt.web.XXSSProtectionFilter.doFilter(XXSSProtectionFilter.java:28)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at io.hawt.web.XFrameOptionsFilter.doFilter(XFrameOptionsFilter.java:28)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at io.hawt.web.CORSFilter.doFilter(CORSFilter.java:42)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at io.hawt.web.CacheHeadersFilter.doFilter(CacheHeadersFilter.java:37)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at io.hawt.web.SessionExpiryFilter.process(SessionExpiryFilter.java:163)
at io.hawt.web.SessionExpiryFilter.doFilter(SessionExpiryFilter.java:57)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at io.hawt.web.RedirectFilter.process(RedirectFilter.java:73)
at io.hawt.web.RedirectFilter.doFilter(RedirectFilter.java:38)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at
org.eclipse.jetty.server.session.

[ANNOUNCE] Apache Artemis 2.0.0

[Martyn Taylor]

All,

I am extremely pleased to announce the release of Apache Artemis 2.0.0.

This 2.0.0 release represents a major milestone for Apache Artemis and
contains a bunch of new features and performance enhancements.  See the
release notes for details.

The project website for Apache Artemis has been updated include this
release and can be found here:
http://activemq.apache.org/artemis/

A list of issues fixed in Apache Artemis 2.0.0 is available here:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12338813
*

API and User documentation can be found here:
https://activemq.apache.org/artemis/docs.html

Regards
Martyn

Re: [ANNOUNCE] Apache Artemis 2.0.0

[Jamie G.]

Congratulations on the release of Apache ActiveMQ Artemis 2.0.0!

On Wed, Mar 22, 2017 at 10:33 AM, Martyn Taylor  wrote:
> All,
>
> I am extremely pleased to announce the release of Apache Artemis 2.0.0.
>
> This 2.0.0 release represents a major milestone for Apache Artemis and
> contains a bunch of new features and performance enhancements.  See the
> release notes for details.
>
> The project website for Apache Artemis has been updated include this
> release and can be found here:
> http://activemq.apache.org/artemis/
>
> A list of issues fixed in Apache Artemis 2.0.0 is available here:
> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12338813
> *
>
> API and User documentation can be found here:
> https://activemq.apache.org/artemis/docs.html
>
> Regards
> Martyn

Re: ActiveMQ lease-database-locker in Servicemix - Class not found

[Tim Bain]

I have no experience with ServiceMix, but is it available as an optional
feature (http://servicemix.apache.org/docs/7.x/quickstart/features.html)?

Otherwise, you'll probably want to post to the ServiceMix mailing list:
http://servicemix.apache.org/community/mailing-lists.html

Tim

On Mar 20, 2017 4:14 PM, "mtod"  wrote:

> I'm working with ActiveMQ in Servicemix 7.0 trying to get the
> lease-database-locker working.
>
> I have it working in stand alone mode using MSSql but when I place the same
> configuration in Servicemix it says :
>
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.dbcp2.BasicDataSource not found by
> org.apache.activemq.activemq-osgi.
>
> I can't find how to install that class in Servicemix.
>
> I'm not sure what I'm missing or if there is another way to do this.
>
> Thanks
>
> Mike
>
> ActiveMQ.xml config
>
>
> 
>  lockKeepAlivePeriod="5000"
> checkForCorruptJournalFiles="true" enableAckCompaction="false" >
> 
>
>lockAcquireSleepInterval="1"
> dataSource="#mssql-ds" createTablesOnStartup="true">
> 
>
>lockTableName="activemq_lock"/>
> 
>   
> 
> 
> 
>
> .
>
>  destroy-method="close">
>  value="com.microsoft.sqlserver.jdbc.SQLServerDriver"/>
> 
> 
> 
> 
> 
>
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMQ-lease-database-locker-in-Servicemix-
> Class-not-found-tp4723913.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Activemq 5.7: Restarting Consumer results in duplicate message delivery for all messages consumed after restart.

[jayas]

This is observed during our tests where a consumer is restarted , after which
we see that consumer receives duplicate messages for all the messages sent
post restart.
Here is the test environment.
Active MQ 5.7.0
One Topic, with two active consumers and one producer.
There are three JVM instances.
1. Runs the broker, 
2. Runs the producer and consumer#1
3. Runs the consumer#2
When instance#3 is restarted, that consumer will start receiving duplicate
messages for all the messages that producer sends (instance#2). 
Note that consumer running in instance #2 (which was not restarted) does not
receive duplicate messages.
The duplicate message delivery is not just for those messages that producer
sends when consumer#2 was being restarted. It is observed for all the
messages that producer sends after consumer#2 is back online as well.
Can you please confirm whether this is a known issue with activeMQ 5.7 ?
I tried to search the issues in JIRA but could not see a matching one.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Activemq-5-7-Restarting-Consumer-results-in-duplicate-message-delivery-for-all-messages-consumed-aft-tp4723956.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.