[GitHub] activemq-artemis pull request #652: ARTEMIS-645 ClusteredGroupingTest fails

2016-07-21 Thread dudaerich
GitHub user dudaerich opened a pull request:

https://github.com/apache/activemq-artemis/pull/652

ARTEMIS-645 ClusteredGroupingTest fails

In testGroupingSendTo3queuesNoConsumerOnLocalQueue the batch
of messages can be received also by the second consumer. It
depends on cluster decision.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-645

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/652.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #652


commit 0dc6fb8edfeac1dbaf9a65902402f4d1aba1df6d
Author: Erich Duda 
Date:   2016-07-20T13:48:10Z

ARTEMIS-645 ClusteredGroupingTest fails

In testGroupingSendTo3queuesNoConsumerOnLocalQueue the batch
of messages can be received also by the second consumer. It
depends on cluster decision.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Contributing to the ActiveMQ-artemis

2016-07-21 Thread Lahiru Dilshan
I'm Lahiru Dilshan. I am an undergraduate at Faculty of Engineering,
University of Peradeniya. I would like to contribute to the
activemq-artemis. It will be great if you can tell me how to start with
contributing to develop the software. As for now, I downloaded the software
and using it. Thanks.


Re: Contributing to the ActiveMQ-artemis

2016-07-21 Thread John D. Ament
Hi Lahiru,

A good place to start is with Artemis' hacking guide, which helps get new
devs started on working on the code base.
https://github.com/apache/activemq-artemis/tree/master/docs/hacking-guide/en

Then you probably want to look for a JIRA ticket to work on.

John

On Thu, Jul 21, 2016 at 6:57 AM Lahiru Dilshan 
wrote:

> I'm Lahiru Dilshan. I am an undergraduate at Faculty of Engineering,
> University of Peradeniya. I would like to contribute to the
> activemq-artemis. It will be great if you can tell me how to start with
> contributing to develop the software. As for now, I downloaded the software
> and using it. Thanks.
>


[GitHub] activemq-artemis issue #640: ARTEMIS-565 Replace json.org with javax.json

2016-07-21 Thread johnament
Github user johnament commented on the issue:

https://github.com/apache/activemq-artemis/pull/640
  
@puntogil yep, that's why i'm not saying this is ready.

@mtaylor Ok, I'll clean it up.

Thanks for looking at this guys!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[ANNOUNCE] Apache ActiveMQ 5.13.4 Released

2016-07-21 Thread Christopher Shannon
Hello Everyone,

Apache ActiveMQ 5.13.4 has been released.

This release contains a number of improvements and bug fixes found since
the 5.13.3 release.

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

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

API documentation for 5.13.4 is located here:
http://activemq.apache.org/maven/5.13.4/apidocs/index.html


Adding new maven dependency for mqtt protocol project

2016-07-21 Thread aries.aries
I am working on implementing few things in the mqtt protocol project. I have
used the below two dependencies


org.apache.commons
commons-collections4
4.1



org.toubassi.femtozip
femtozip
1.0


It is working perfectly fine when I build and run from IntelliJ IDE.
However, when I use the command "mvn clean install -Prelease", the build is
successful but I get classNotFound exception at runtime. 

Could someone please guide me what the issue might be?

Thanks,
Vicky 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Adding-new-maven-dependency-for-mqtt-protocol-project-tp4714220.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Adding new maven dependency for mqtt protocol project

2016-07-21 Thread Christopher Shannon
Which class can't be found?

On Thu, Jul 21, 2016 at 4:24 AM, aries.aries 
wrote:

> I am working on implementing few things in the mqtt protocol project. I
> have
> used the below two dependencies
>
> 
> org.apache.commons
> commons-collections4
> 4.1
> 
>
> 
> org.toubassi.femtozip
> femtozip
> 1.0
> 
>
> It is working perfectly fine when I build and run from IntelliJ IDE.
> However, when I use the command "mvn clean install -Prelease", the build is
> successful but I get classNotFound exception at runtime.
>
> Could someone please guide me what the issue might be?
>
> Thanks,
> Vicky
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Adding-new-maven-dependency-for-mqtt-protocol-project-tp4714220.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>


[GitHub] activemq-artemis pull request #650: Handful of changes related to ARTEMIS-61...

2016-07-21 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/650


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] activemq-artemis pull request #651: ARTEMIS-405 more docs for JMS destinatio...

2016-07-21 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/651


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


RE: FW: STOMP server quits sending to all subscribers when one client disconnects

2016-07-21 Thread Ed Kaltenbach
John,
I had some time this morning to try against the 1.3 standalone broker.  The 
problem seems to be fixed in 1.3.  I first tried two clients, each with a 
unique subscription ID, and could not replicate the error.  When one client 
ended, the other client still posted and received messages from the topic.  
I also tried it with both clients using the same subscription ID.  I could not 
replicate the error here either.  When one client ended, the other continued to 
send and receive messages.
I even killed one of the clients abruptly and the other one continued to send 
and receive messages.

So, in summary, the problem seems to be fixed in 1.3.

How confident are people that Artemis 1.3 will work in Wildfly 10 seamlessly?

Ed

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Tuesday, July 19, 2016 5:22 PM
To: dev@activemq.apache.org
Subject: Re: FW: STOMP server quits sending to all subscribers when one client 
disconnects

Ed,

Sorry one more thing to try.  Can you try against the 1.3 standalone broker 
instead of the 1.1 that ships w/ Wildfly?  I'm wondering if the auto creation 
feature fixes this error.

John

On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach  wrote:

>
>
> I just modified my test client application so that each client has a 
> unique subscription id.  Here is the new code:
>
>
>
> String destID = String.format("%d", System.currentTimeMillis());
>
> msg = "SUBSCRIBE\n";
>
> msg = msg + "destination:" + topicName + "\n";
>
> msg = msg + "id:" + destID + "\n";
>
> msg = msg + "ack:auto\n";
>
> msg = msg + "\n";
>
> msg = msg + '\0';
>
>
>
> I still see the same error.  When one of the clients ends, the other 
> clients start getting the “AMQ339001\c Destination does not exist\c 
> jms.topic.ACRS_Exit” error when they try to SEND a message to the JMS topic.
>
>
>
> It all seems to work fine until one of the clients UNSUBSCRIBES, 
> DISCONNECTS, and shutdowns the socket.  All of the clients were 
> receiving all of the messages.
>
>
>
> Here is some new information.  If I run multiple instances of my test 
> client application (the new one that has unique subscription IDs for 
> each
> client) and then I kill one using “ctrl-c” then I see the same error.  
> The other client instance starts getting the “AMQ339001\c Destination 
> does not exist\c jms.topic.ACRS_Exit” error when it tries to SEND a 
> message to the JMS topic.  Therefore, I don’t think the problem is 
> related to the “UNSUBSCRIBE” or “DISCONNECT” messages because they 
> were never sent when the problem started.
>
>
>
> Ed
>
>
>
> *From:* Martyn Taylor [mailto:mtay...@redhat.com ]
> *Sent:* Tuesday, July 19, 2016 9:00 AM
> *To:* dev@activemq.apache.org
> *Cc:* Ed Kaltenbach 
>
>
> *Subject:* Re: STOMP server quits sending to all subscribers when one 
> client disconnects
>
>
>
> Hi Ed,
>
>
>
> You mentioned that using a unique subscription ID does not resolve 
> this issue.  Can you confirm that using different subscription IDs 
> across all your clients is the same?  Were you seeing subscription 
> semantics before the error (i.e. was every subscription seeing every 
> message?).
>
>
>
> I've taken a quick look and there may be an issue in the STOMP 
> protocol handler.  The subscription ID is used to identify consumer 
> queues, this could cause some issues with multiple clients using the 
> same subscription ID during unsubscribe.  The subscription ID only 
> needs to be unique within connections 
> https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE
>
>
>
> Thanks
> Martyn
>


Re: STOMP server quits sending to all subscribers when one client disconnects

2016-07-21 Thread Justin Bertram
I'm pretty confident it would work, but you never know until you try (which I 
haven't).


Justin

- Original Message -
From: "Ed Kaltenbach" 
To: dev@activemq.apache.org
Sent: Thursday, July 21, 2016 12:56:12 PM
Subject: RE: FW: STOMP server quits sending to all subscribers when one client 
disconnects

John,
I had some time this morning to try against the 1.3 standalone broker.  The 
problem seems to be fixed in 1.3.  I first tried two clients, each with a 
unique subscription ID, and could not replicate the error.  When one client 
ended, the other client still posted and received messages from the topic.  
I also tried it with both clients using the same subscription ID.  I could not 
replicate the error here either.  When one client ended, the other continued to 
send and receive messages.
I even killed one of the clients abruptly and the other one continued to send 
and receive messages.

So, in summary, the problem seems to be fixed in 1.3.

How confident are people that Artemis 1.3 will work in Wildfly 10 seamlessly?

Ed

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Tuesday, July 19, 2016 5:22 PM
To: dev@activemq.apache.org
Subject: Re: FW: STOMP server quits sending to all subscribers when one client 
disconnects

Ed,

Sorry one more thing to try.  Can you try against the 1.3 standalone broker 
instead of the 1.1 that ships w/ Wildfly?  I'm wondering if the auto creation 
feature fixes this error.

John

On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach  wrote:

>
>
> I just modified my test client application so that each client has a 
> unique subscription id.  Here is the new code:
>
>
>
> String destID = String.format("%d", System.currentTimeMillis());
>
> msg = "SUBSCRIBE\n";
>
> msg = msg + "destination:" + topicName + "\n";
>
> msg = msg + "id:" + destID + "\n";
>
> msg = msg + "ack:auto\n";
>
> msg = msg + "\n";
>
> msg = msg + '\0';
>
>
>
> I still see the same error.  When one of the clients ends, the other 
> clients start getting the “AMQ339001\c Destination does not exist\c 
> jms.topic.ACRS_Exit” error when they try to SEND a message to the JMS topic.
>
>
>
> It all seems to work fine until one of the clients UNSUBSCRIBES, 
> DISCONNECTS, and shutdowns the socket.  All of the clients were 
> receiving all of the messages.
>
>
>
> Here is some new information.  If I run multiple instances of my test 
> client application (the new one that has unique subscription IDs for 
> each
> client) and then I kill one using “ctrl-c” then I see the same error.  
> The other client instance starts getting the “AMQ339001\c Destination 
> does not exist\c jms.topic.ACRS_Exit” error when it tries to SEND a 
> message to the JMS topic.  Therefore, I don’t think the problem is 
> related to the “UNSUBSCRIBE” or “DISCONNECT” messages because they 
> were never sent when the problem started.
>
>
>
> Ed
>
>
>
> *From:* Martyn Taylor [mailto:mtay...@redhat.com ]
> *Sent:* Tuesday, July 19, 2016 9:00 AM
> *To:* dev@activemq.apache.org
> *Cc:* Ed Kaltenbach 
>
>
> *Subject:* Re: STOMP server quits sending to all subscribers when one 
> client disconnects
>
>
>
> Hi Ed,
>
>
>
> You mentioned that using a unique subscription ID does not resolve 
> this issue.  Can you confirm that using different subscription IDs 
> across all your clients is the same?  Were you seeing subscription 
> semantics before the error (i.e. was every subscription seeing every 
> message?).
>
>
>
> I've taken a quick look and there may be an issue in the STOMP 
> protocol handler.  The subscription ID is used to identify consumer 
> queues, this could cause some issues with multiple clients using the 
> same subscription ID during unsubscribe.  The subscription ID only 
> needs to be unique within connections 
> https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE
>
>
>
> Thanks
> Martyn
>


Re: STOMP server quits sending to all subscribers when one client disconnects

2016-07-21 Thread John D. Ament
I see that wf10 ships a custom build for 1.1, was there anything special
about it?

On Jul 21, 2016 14:09, "Justin Bertram"  wrote:

> I'm pretty confident it would work, but you never know until you try
> (which I haven't).
>
>
> Justin
>
> - Original Message -
> From: "Ed Kaltenbach" 
> To: dev@activemq.apache.org
> Sent: Thursday, July 21, 2016 12:56:12 PM
> Subject: RE: FW: STOMP server quits sending to all subscribers when one
> client disconnects
>
> John,
> I had some time this morning to try against the 1.3 standalone broker.
> The problem seems to be fixed in 1.3.  I first tried two clients, each with
> a unique subscription ID, and could not replicate the error.  When one
> client ended, the other client still posted and received messages from the
> topic.
> I also tried it with both clients using the same subscription ID.  I could
> not replicate the error here either.  When one client ended, the other
> continued to send and receive messages.
> I even killed one of the clients abruptly and the other one continued to
> send and receive messages.
>
> So, in summary, the problem seems to be fixed in 1.3.
>
> How confident are people that Artemis 1.3 will work in Wildfly 10
> seamlessly?
>
> Ed
>
> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Tuesday, July 19, 2016 5:22 PM
> To: dev@activemq.apache.org
> Subject: Re: FW: STOMP server quits sending to all subscribers when one
> client disconnects
>
> Ed,
>
> Sorry one more thing to try.  Can you try against the 1.3 standalone
> broker instead of the 1.1 that ships w/ Wildfly?  I'm wondering if the auto
> creation feature fixes this error.
>
> John
>
> On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach 
> wrote:
>
> >
> >
> > I just modified my test client application so that each client has a
> > unique subscription id.  Here is the new code:
> >
> >
> >
> > String destID = String.format("%d", System.currentTimeMillis());
> >
> > msg = "SUBSCRIBE\n";
> >
> > msg = msg + "destination:" + topicName + "\n";
> >
> > msg = msg + "id:" + destID + "\n";
> >
> > msg = msg + "ack:auto\n";
> >
> > msg = msg + "\n";
> >
> > msg = msg + '\0';
> >
> >
> >
> > I still see the same error.  When one of the clients ends, the other
> > clients start getting the “AMQ339001\c Destination does not exist\c
> > jms.topic.ACRS_Exit” error when they try to SEND a message to the JMS
> topic.
> >
> >
> >
> > It all seems to work fine until one of the clients UNSUBSCRIBES,
> > DISCONNECTS, and shutdowns the socket.  All of the clients were
> > receiving all of the messages.
> >
> >
> >
> > Here is some new information.  If I run multiple instances of my test
> > client application (the new one that has unique subscription IDs for
> > each
> > client) and then I kill one using “ctrl-c” then I see the same error.
> > The other client instance starts getting the “AMQ339001\c Destination
> > does not exist\c jms.topic.ACRS_Exit” error when it tries to SEND a
> > message to the JMS topic.  Therefore, I don’t think the problem is
> > related to the “UNSUBSCRIBE” or “DISCONNECT” messages because they
> > were never sent when the problem started.
> >
> >
> >
> > Ed
> >
> >
> >
> > *From:* Martyn Taylor [mailto:mtay...@redhat.com ]
> > *Sent:* Tuesday, July 19, 2016 9:00 AM
> > *To:* dev@activemq.apache.org
> > *Cc:* Ed Kaltenbach 
> >
> >
> > *Subject:* Re: STOMP server quits sending to all subscribers when one
> > client disconnects
> >
> >
> >
> > Hi Ed,
> >
> >
> >
> > You mentioned that using a unique subscription ID does not resolve
> > this issue.  Can you confirm that using different subscription IDs
> > across all your clients is the same?  Were you seeing subscription
> > semantics before the error (i.e. was every subscription seeing every
> message?).
> >
> >
> >
> > I've taken a quick look and there may be an issue in the STOMP
> > protocol handler.  The subscription ID is used to identify consumer
> > queues, this could cause some issues with multiple clients using the
> > same subscription ID during unsubscribe.  The subscription ID only
> > needs to be unique within connections
> > https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE
> >
> >
> >
> > Thanks
> > Martyn
> >
>


RE: STOMP server quits sending to all subscribers when one client disconnects

2016-07-21 Thread Ed Kaltenbach
Does anybody know the steps to replace 1.1 with 1.3 in Wildfly 10?

I see that Wildfly has a directory 
"wildfly-10.0.0.Final\modules\system\layers\base\org\wildfly\extension\messaging-activemq\main"
 that contains
 - artemis-wildfly-integration-1.0.2.jar
 - module.xml
 - wildfly-messaging-activemq-10.0.0.Final.jar

Wildfly also has the directory 
"wildfly-10.0.0.Final\modules\system\layers\base\org\apache\activemq\artemis" 
that contains subdirectories:
 - "main",
 - "protocol", 
 - "ra". 
 I see a lot of artemis-xxx.jar files in all of these subdirectories.

Does anybody have any suggestions or inputs?

Thanks,
Ed

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Thursday, July 21, 2016 12:51 PM
To: dev@activemq.apache.org
Subject: Re: STOMP server quits sending to all subscribers when one client 
disconnects

I see that wf10 ships a custom build for 1.1, was there anything special about 
it?

On Jul 21, 2016 14:09, "Justin Bertram"  wrote:

> I'm pretty confident it would work, but you never know until you try 
> (which I haven't).
>
>
> Justin
>
> - Original Message -
> From: "Ed Kaltenbach" 
> To: dev@activemq.apache.org
> Sent: Thursday, July 21, 2016 12:56:12 PM
> Subject: RE: FW: STOMP server quits sending to all subscribers when 
> one client disconnects
>
> John,
> I had some time this morning to try against the 1.3 standalone broker.
> The problem seems to be fixed in 1.3.  I first tried two clients, each 
> with a unique subscription ID, and could not replicate the error.  
> When one client ended, the other client still posted and received 
> messages from the topic.
> I also tried it with both clients using the same subscription ID.  I 
> could not replicate the error here either.  When one client ended, the 
> other continued to send and receive messages.
> I even killed one of the clients abruptly and the other one continued 
> to send and receive messages.
>
> So, in summary, the problem seems to be fixed in 1.3.
>
> How confident are people that Artemis 1.3 will work in Wildfly 10 
> seamlessly?
>
> Ed
>
> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Tuesday, July 19, 2016 5:22 PM
> To: dev@activemq.apache.org
> Subject: Re: FW: STOMP server quits sending to all subscribers when 
> one client disconnects
>
> Ed,
>
> Sorry one more thing to try.  Can you try against the 1.3 standalone 
> broker instead of the 1.1 that ships w/ Wildfly?  I'm wondering if the 
> auto creation feature fixes this error.
>
> John
>
> On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach 
> wrote:
>
> >
> >
> > I just modified my test client application so that each client has a 
> > unique subscription id.  Here is the new code:
> >
> >
> >
> > String destID = String.format("%d", System.currentTimeMillis());
> >
> > msg = "SUBSCRIBE\n";
> >
> > msg = msg + "destination:" + topicName + "\n";
> >
> > msg = msg + "id:" + destID + "\n";
> >
> > msg = msg + "ack:auto\n";
> >
> > msg = msg + "\n";
> >
> > msg = msg + '\0';
> >
> >
> >
> > I still see the same error.  When one of the clients ends, the other 
> > clients start getting the “AMQ339001\c Destination does not exist\c 
> > jms.topic.ACRS_Exit” error when they try to SEND a message to the 
> > JMS
> topic.
> >
> >
> >
> > It all seems to work fine until one of the clients UNSUBSCRIBES, 
> > DISCONNECTS, and shutdowns the socket.  All of the clients were 
> > receiving all of the messages.
> >
> >
> >
> > Here is some new information.  If I run multiple instances of my 
> > test client application (the new one that has unique subscription 
> > IDs for each
> > client) and then I kill one using “ctrl-c” then I see the same error.
> > The other client instance starts getting the “AMQ339001\c 
> > Destination does not exist\c jms.topic.ACRS_Exit” error when it 
> > tries to SEND a message to the JMS topic.  Therefore, I don’t think 
> > the problem is related to the “UNSUBSCRIBE” or “DISCONNECT” messages 
> > because they were never sent when the problem started.
> >
> >
> >
> > Ed
> >
> >
> >
> > *From:* Martyn Taylor [mailto:mtay...@redhat.com 
> > ]
> > *Sent:* Tuesday, July 19, 2016 9:00 AM
> > *To:* dev@activemq.apache.org
> > *Cc:* Ed Kaltenbach 
> >
> >
> > *Subject:* Re: STOMP server quits sending to all subscribers when 
> > one client disconnects
> >
> >
> >
> > Hi Ed,
> >
> >
> >
> > You mentioned that using a unique subscription ID does not resolve 
> > this issue.  Can you confirm that using different subscription IDs 
> > across all your clients is the same?  Were you seeing subscription 
> > semantics before the error (i.e. was every subscription seeing every
> message?).
> >
> >
> >
> > I've taken a quick look and there may be an issue in the STOMP 
> > protocol handler.  The subscription ID is used to identify consumer 
> > queues, this could cause some issues with multiple clients using the 
> > same subscription ID during unsubscribe.  The subscription ID only 
> >

Re: STOMP server quits sending to all subscribers when one client disconnects

2016-07-21 Thread John D. Ament
Ed,

I would replace only the latter.  I may be able to test it out tonight and
give you some feedback.

John

On Thu, Jul 21, 2016 at 3:30 PM Ed Kaltenbach  wrote:

> Does anybody know the steps to replace 1.1 with 1.3 in Wildfly 10?
>
> I see that Wildfly has a directory
> "wildfly-10.0.0.Final\modules\system\layers\base\org\wildfly\extension\messaging-activemq\main"
> that contains
>  - artemis-wildfly-integration-1.0.2.jar
>  - module.xml
>  - wildfly-messaging-activemq-10.0.0.Final.jar
>
> Wildfly also has the directory
> "wildfly-10.0.0.Final\modules\system\layers\base\org\apache\activemq\artemis"
> that contains subdirectories:
>  - "main",
>  - "protocol",
>  - "ra".
>  I see a lot of artemis-xxx.jar files in all of these subdirectories.
>
> Does anybody have any suggestions or inputs?
>
> Thanks,
> Ed
>
> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Thursday, July 21, 2016 12:51 PM
> To: dev@activemq.apache.org
> Subject: Re: STOMP server quits sending to all subscribers when one client
> disconnects
>
> I see that wf10 ships a custom build for 1.1, was there anything special
> about it?
>
> On Jul 21, 2016 14:09, "Justin Bertram"  wrote:
>
> > I'm pretty confident it would work, but you never know until you try
> > (which I haven't).
> >
> >
> > Justin
> >
> > - Original Message -
> > From: "Ed Kaltenbach" 
> > To: dev@activemq.apache.org
> > Sent: Thursday, July 21, 2016 12:56:12 PM
> > Subject: RE: FW: STOMP server quits sending to all subscribers when
> > one client disconnects
> >
> > John,
> > I had some time this morning to try against the 1.3 standalone broker.
> > The problem seems to be fixed in 1.3.  I first tried two clients, each
> > with a unique subscription ID, and could not replicate the error.
> > When one client ended, the other client still posted and received
> > messages from the topic.
> > I also tried it with both clients using the same subscription ID.  I
> > could not replicate the error here either.  When one client ended, the
> > other continued to send and receive messages.
> > I even killed one of the clients abruptly and the other one continued
> > to send and receive messages.
> >
> > So, in summary, the problem seems to be fixed in 1.3.
> >
> > How confident are people that Artemis 1.3 will work in Wildfly 10
> > seamlessly?
> >
> > Ed
> >
> > -Original Message-
> > From: John D. Ament [mailto:johndam...@apache.org]
> > Sent: Tuesday, July 19, 2016 5:22 PM
> > To: dev@activemq.apache.org
> > Subject: Re: FW: STOMP server quits sending to all subscribers when
> > one client disconnects
> >
> > Ed,
> >
> > Sorry one more thing to try.  Can you try against the 1.3 standalone
> > broker instead of the 1.1 that ships w/ Wildfly?  I'm wondering if the
> > auto creation feature fixes this error.
> >
> > John
> >
> > On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach 
> > wrote:
> >
> > >
> > >
> > > I just modified my test client application so that each client has a
> > > unique subscription id.  Here is the new code:
> > >
> > >
> > >
> > > String destID = String.format("%d", System.currentTimeMillis());
> > >
> > > msg = "SUBSCRIBE\n";
> > >
> > > msg = msg + "destination:" + topicName + "\n";
> > >
> > > msg = msg + "id:" + destID + "\n";
> > >
> > > msg = msg + "ack:auto\n";
> > >
> > > msg = msg + "\n";
> > >
> > > msg = msg + '\0';
> > >
> > >
> > >
> > > I still see the same error.  When one of the clients ends, the other
> > > clients start getting the “AMQ339001\c Destination does not exist\c
> > > jms.topic.ACRS_Exit” error when they try to SEND a message to the
> > > JMS
> > topic.
> > >
> > >
> > >
> > > It all seems to work fine until one of the clients UNSUBSCRIBES,
> > > DISCONNECTS, and shutdowns the socket.  All of the clients were
> > > receiving all of the messages.
> > >
> > >
> > >
> > > Here is some new information.  If I run multiple instances of my
> > > test client application (the new one that has unique subscription
> > > IDs for each
> > > client) and then I kill one using “ctrl-c” then I see the same error.
> > > The other client instance starts getting the “AMQ339001\c
> > > Destination does not exist\c jms.topic.ACRS_Exit” error when it
> > > tries to SEND a message to the JMS topic.  Therefore, I don’t think
> > > the problem is related to the “UNSUBSCRIBE” or “DISCONNECT” messages
> > > because they were never sent when the problem started.
> > >
> > >
> > >
> > > Ed
> > >
> > >
> > >
> > > *From:* Martyn Taylor [mailto:mtay...@redhat.com
> > > ]
> > > *Sent:* Tuesday, July 19, 2016 9:00 AM
> > > *To:* dev@activemq.apache.org
> > > *Cc:* Ed Kaltenbach 
> > >
> > >
> > > *Subject:* Re: STOMP server quits sending to all subscribers when
> > > one client disconnects
> > >
> > >
> > >
> > > Hi Ed,
> > >
> > >
> > >
> > > You mentioned that using a unique subscription ID does not resolve
> > > this issue.  Can you confirm that using different subscription IDs
> > > across all your clients 

Re: STOMP server quits sending to all subscribers when one client disconnects

2016-07-21 Thread Justin Bertram
The org.wildfly.extension.messaging-activemq module is for the 
"messaging-activemq" subsystem which is for Artemis integration.  The 
org.apache.activemq.artemis module is for Artemis itself which will have the 
jars you need to replace.


Justin

- Original Message -
From: "Ed Kaltenbach" 
To: dev@activemq.apache.org
Sent: Thursday, July 21, 2016 2:30:13 PM
Subject: RE: STOMP server quits sending to all subscribers when one client 
disconnects

Does anybody know the steps to replace 1.1 with 1.3 in Wildfly 10?

I see that Wildfly has a directory 
"wildfly-10.0.0.Final\modules\system\layers\base\org\wildfly\extension\messaging-activemq\main"
 that contains
 - artemis-wildfly-integration-1.0.2.jar
 - module.xml
 - wildfly-messaging-activemq-10.0.0.Final.jar

Wildfly also has the directory 
"wildfly-10.0.0.Final\modules\system\layers\base\org\apache\activemq\artemis" 
that contains subdirectories:
 - "main",
 - "protocol", 
 - "ra". 
 I see a lot of artemis-xxx.jar files in all of these subdirectories.

Does anybody have any suggestions or inputs?

Thanks,
Ed

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Thursday, July 21, 2016 12:51 PM
To: dev@activemq.apache.org
Subject: Re: STOMP server quits sending to all subscribers when one client 
disconnects

I see that wf10 ships a custom build for 1.1, was there anything special about 
it?

On Jul 21, 2016 14:09, "Justin Bertram"  wrote:

> I'm pretty confident it would work, but you never know until you try 
> (which I haven't).
>
>
> Justin
>
> - Original Message -
> From: "Ed Kaltenbach" 
> To: dev@activemq.apache.org
> Sent: Thursday, July 21, 2016 12:56:12 PM
> Subject: RE: FW: STOMP server quits sending to all subscribers when 
> one client disconnects
>
> John,
> I had some time this morning to try against the 1.3 standalone broker.
> The problem seems to be fixed in 1.3.  I first tried two clients, each 
> with a unique subscription ID, and could not replicate the error.  
> When one client ended, the other client still posted and received 
> messages from the topic.
> I also tried it with both clients using the same subscription ID.  I 
> could not replicate the error here either.  When one client ended, the 
> other continued to send and receive messages.
> I even killed one of the clients abruptly and the other one continued 
> to send and receive messages.
>
> So, in summary, the problem seems to be fixed in 1.3.
>
> How confident are people that Artemis 1.3 will work in Wildfly 10 
> seamlessly?
>
> Ed
>
> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Tuesday, July 19, 2016 5:22 PM
> To: dev@activemq.apache.org
> Subject: Re: FW: STOMP server quits sending to all subscribers when 
> one client disconnects
>
> Ed,
>
> Sorry one more thing to try.  Can you try against the 1.3 standalone 
> broker instead of the 1.1 that ships w/ Wildfly?  I'm wondering if the 
> auto creation feature fixes this error.
>
> John
>
> On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach 
> wrote:
>
> >
> >
> > I just modified my test client application so that each client has a 
> > unique subscription id.  Here is the new code:
> >
> >
> >
> > String destID = String.format("%d", System.currentTimeMillis());
> >
> > msg = "SUBSCRIBE\n";
> >
> > msg = msg + "destination:" + topicName + "\n";
> >
> > msg = msg + "id:" + destID + "\n";
> >
> > msg = msg + "ack:auto\n";
> >
> > msg = msg + "\n";
> >
> > msg = msg + '\0';
> >
> >
> >
> > I still see the same error.  When one of the clients ends, the other 
> > clients start getting the “AMQ339001\c Destination does not exist\c 
> > jms.topic.ACRS_Exit” error when they try to SEND a message to the 
> > JMS
> topic.
> >
> >
> >
> > It all seems to work fine until one of the clients UNSUBSCRIBES, 
> > DISCONNECTS, and shutdowns the socket.  All of the clients were 
> > receiving all of the messages.
> >
> >
> >
> > Here is some new information.  If I run multiple instances of my 
> > test client application (the new one that has unique subscription 
> > IDs for each
> > client) and then I kill one using “ctrl-c” then I see the same error.
> > The other client instance starts getting the “AMQ339001\c 
> > Destination does not exist\c jms.topic.ACRS_Exit” error when it 
> > tries to SEND a message to the JMS topic.  Therefore, I don’t think 
> > the problem is related to the “UNSUBSCRIBE” or “DISCONNECT” messages 
> > because they were never sent when the problem started.
> >
> >
> >
> > Ed
> >
> >
> >
> > *From:* Martyn Taylor [mailto:mtay...@redhat.com 
> > ]
> > *Sent:* Tuesday, July 19, 2016 9:00 AM
> > *To:* dev@activemq.apache.org
> > *Cc:* Ed Kaltenbach 
> >
> >
> > *Subject:* Re: STOMP server quits sending to all subscribers when 
> > one client disconnects
> >
> >
> >
> > Hi Ed,
> >
> >
> >
> > You mentioned that using a unique subscription ID does not resolve 
> > this issue.  Can you confirm that using different subscription IDs 
>

[GitHub] activemq-artemis pull request #653: ARTEMIS-548 Stomp durable sub unsubscrbe

2016-07-21 Thread jbertram
GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/653

ARTEMIS-548 Stomp durable sub unsubscrbe

Implement ability for Stomp clients to unsubscribe durable
subscriptions.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-548

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/653.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #653


commit b6a026bbc5a8df326798bb32ce9f2c5548e1d8cb
Author: jbertram 
Date:   2016-07-21T19:10:04Z

ARTEMIS-548 Stomp durable sub unsubscrbe

Implement ability for Stomp clients to unsubscribe durable
subscriptions.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] activemq-artemis pull request #653: ARTEMIS-548 Stomp durable sub unsubscrbe

2016-07-21 Thread johnament
Github user johnament commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/653#discussion_r71780013
  
--- Diff: 
artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompProtocolManager.java
 ---
@@ -393,7 +393,8 @@ public void unsubscribe(StompConnection connection,
String subscriptionID,
String durableSubscriberName) throws Exception {
   StompSession stompSession = getSession(connection);
-  boolean unsubscribed = stompSession.unsubscribe(subscriptionID, 
durableSubscriberName);
+  String clientID = (connection.getClientID() != null) ? 
connection.getClientID() : null;
--- End diff --

null check looks redundant, its always the value of 
`connection.getClientID()`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] activemq-artemis pull request #654: ARTEMIS-413 doc for Stomp durable subs

2016-07-21 Thread jbertram
GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/654

ARTEMIS-413 doc for Stomp durable subs



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-413

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/654.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #654


commit a6fd65cd9d00e002a0e3a9c5368c39a0b7471ef9
Author: jbertram 
Date:   2016-07-21T18:45:47Z

ARTEMIS-413 doc for Stomp durable subs




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] activemq-artemis issue #640: ARTEMIS-565 Replace json.org with javax.json

2016-07-21 Thread johnament
Github user johnament commented on the issue:

https://github.com/apache/activemq-artemis/pull/640
  
Ok, the changes should be good.  I manually ran the integration tests that 
were touched, and fixed a bunch of issues identified there.  

I'm going to create a ticket to create more lower level json tests.  
They're a good way to verify contracts in a situation like this.  If I were 
starting this over, I would have added the contracts first.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] activemq-artemis issue #641: Update version of netty4

2016-07-21 Thread jbertram
Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/641
  
I think the Netty upgrade may have broken a bunch of the large-message 
tests.  See 
https://builds.apache.org/job/ActiveMQ-Artemis-Nightly-Regression-Test/582/.  I 
get failures in 
org.apache.activemq.artemis.tests.integration.client.LargeMessageCompressTest 
when I run locally as well, but if I put the Netty version back to 4.0.32.Final 
all the tests pass.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


RE: STOMP server quits sending to all subscribers when one client disconnects

2016-07-21 Thread Ed Kaltenbach
I got 1.3 working in Wildfly 10.  I replaced the jar files in the 
"wildfly-10.0.0.Final\modules\system\layers\base\org\apache\activemq\artemis" 
subdirectories with the ActiveMQ Artimis 1.3 versions.  I updated the jar 
filenames in the "modules.xml" files in each of the subdirectories.  

I am running multiple clients and they are all working correctly.

Thanks for all of you help,

Ed

-Original Message-
From: Justin Bertram [mailto:jbert...@apache.com] 
Sent: Thursday, July 21, 2016 1:38 PM
To: dev@activemq.apache.org
Subject: Re: STOMP server quits sending to all subscribers when one client 
disconnects

The org.wildfly.extension.messaging-activemq module is for the 
"messaging-activemq" subsystem which is for Artemis integration.  The 
org.apache.activemq.artemis module is for Artemis itself which will have the 
jars you need to replace.


Justin

- Original Message -
From: "Ed Kaltenbach" 
To: dev@activemq.apache.org
Sent: Thursday, July 21, 2016 2:30:13 PM
Subject: RE: STOMP server quits sending to all subscribers when one client 
disconnects

Does anybody know the steps to replace 1.1 with 1.3 in Wildfly 10?

I see that Wildfly has a directory 
"wildfly-10.0.0.Final\modules\system\layers\base\org\wildfly\extension\messaging-activemq\main"
 that contains
 - artemis-wildfly-integration-1.0.2.jar
 - module.xml
 - wildfly-messaging-activemq-10.0.0.Final.jar

Wildfly also has the directory 
"wildfly-10.0.0.Final\modules\system\layers\base\org\apache\activemq\artemis" 
that contains subdirectories:
 - "main",
 - "protocol",
 - "ra". 
 I see a lot of artemis-xxx.jar files in all of these subdirectories.

Does anybody have any suggestions or inputs?

Thanks,
Ed

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org]
Sent: Thursday, July 21, 2016 12:51 PM
To: dev@activemq.apache.org
Subject: Re: STOMP server quits sending to all subscribers when one client 
disconnects

I see that wf10 ships a custom build for 1.1, was there anything special about 
it?

On Jul 21, 2016 14:09, "Justin Bertram"  wrote:

> I'm pretty confident it would work, but you never know until you try 
> (which I haven't).
>
>
> Justin
>
> - Original Message -
> From: "Ed Kaltenbach" 
> To: dev@activemq.apache.org
> Sent: Thursday, July 21, 2016 12:56:12 PM
> Subject: RE: FW: STOMP server quits sending to all subscribers when 
> one client disconnects
>
> John,
> I had some time this morning to try against the 1.3 standalone broker.
> The problem seems to be fixed in 1.3.  I first tried two clients, each 
> with a unique subscription ID, and could not replicate the error.
> When one client ended, the other client still posted and received 
> messages from the topic.
> I also tried it with both clients using the same subscription ID.  I 
> could not replicate the error here either.  When one client ended, the 
> other continued to send and receive messages.
> I even killed one of the clients abruptly and the other one continued 
> to send and receive messages.
>
> So, in summary, the problem seems to be fixed in 1.3.
>
> How confident are people that Artemis 1.3 will work in Wildfly 10 
> seamlessly?
>
> Ed
>
> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Tuesday, July 19, 2016 5:22 PM
> To: dev@activemq.apache.org
> Subject: Re: FW: STOMP server quits sending to all subscribers when 
> one client disconnects
>
> Ed,
>
> Sorry one more thing to try.  Can you try against the 1.3 standalone 
> broker instead of the 1.1 that ships w/ Wildfly?  I'm wondering if the 
> auto creation feature fixes this error.
>
> John
>
> On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach 
> wrote:
>
> >
> >
> > I just modified my test client application so that each client has a 
> > unique subscription id.  Here is the new code:
> >
> >
> >
> > String destID = String.format("%d", System.currentTimeMillis());
> >
> > msg = "SUBSCRIBE\n";
> >
> > msg = msg + "destination:" + topicName + "\n";
> >
> > msg = msg + "id:" + destID + "\n";
> >
> > msg = msg + "ack:auto\n";
> >
> > msg = msg + "\n";
> >
> > msg = msg + '\0';
> >
> >
> >
> > I still see the same error.  When one of the clients ends, the other 
> > clients start getting the “AMQ339001\c Destination does not exist\c 
> > jms.topic.ACRS_Exit” error when they try to SEND a message to the 
> > JMS
> topic.
> >
> >
> >
> > It all seems to work fine until one of the clients UNSUBSCRIBES, 
> > DISCONNECTS, and shutdowns the socket.  All of the clients were 
> > receiving all of the messages.
> >
> >
> >
> > Here is some new information.  If I run multiple instances of my 
> > test client application (the new one that has unique subscription 
> > IDs for each
> > client) and then I kill one using “ctrl-c” then I see the same error.
> > The other client instance starts getting the “AMQ339001\c 
> > Destination does not exist\c jms.topic.ACRS_Exit” error when it 
> > tries to SEND a message to the JMS topic.  Therefore, I don’

Jenkins build is back to normal : ActiveMQ-Trunk-Deploy #1655

2016-07-21 Thread Apache Jenkins Server
See