Re: How is ActiveMQ 6.0 for continual integration / testing?

[Clebert Suconic]

it should take 1 hour and half. Maybe we could fix some issues on the
tests and make it to 1 hour.


Up to now we have been taking good care on avoiding sleeps and making
sure the tests run without delays. There are a few tests that will
need to validate expiration and etc so it's unavoidable a few sleeps
(like failover for instance).

A lot of time on the testsuite is being spent on Failover and Bridge
Tests.. we could make them running faster without losing coverage.


There is also the stress-testsuite and soak tests but those are
basically an extension of the testsuite (increasing number of
iterations in some of the tests); we will eventually make that part of
the regression builds.. but we should make that less frequent (once a
week and always before releases).



The testsuite now is not working as I broke the testsuite in some of
my last commits (I'm trying to fix that now), but this should give you
an idea of what we run:

https://builds.apache.org/view/All/job/ActiveMQ6-Nightly-Regression-Test/68/testReport/




I should have it fixed after the holidays (working on it)



On Thu, Apr 2, 2015 at 9:22 PM, Kevin Burton  wrote:
> NICE.  Also, how long does the entire test / regression suite take?  …
> roughly.
>
> On Wed, Apr 1, 2015 at 1:01 PM, Clebert Suconic 
> wrote:
>
>> For every Pull Request sent (e.g:
>> https://github.com/apache/activemq-6/pull/197)
>>
>> There will be a build with a considerable sized testsuite running..
>> which we call fast-test
>> https://builds.apache.org/job/ActiveMQ6-PR-Build/223/
>>
>>
>> This will validate tests, CheckStyle and Licensing.
>>
>>
>>
>> This will run the entire JMS tests, unit-tests and some other tests.
>> It's worth looking at:
>> https://builds.apache.org/job/ActiveMQ6-PR-Build/223/testReport/
>>
>>
>>
>> We then run the entire testsuite daily:
>> https://builds.apache.org/view/All/job/ActiveMQ6-Nightly-Regression-Test/
>>
>>
>> There are some failures on this environment now but that's something
>> we are working to solve with Infra. They run ok on my personal dev
>> enrionment and some other servers I have access to.
>>
>> We are in hold now based on the discussions on dev-list this week, but
>> we should fix that soon.
>>
>>
>> Anyway, I hope you get the picture.. PRs are rejected if they fail the
>> basic testsuite, and we will monitor the entire testsuite daily.
>>
>> On Wed, Apr 1, 2015 at 3:48 PM, Kevin Burton  wrote:
>> > This was one of the things that bothered/bothers me about ActiveMQ 5.x…
>> the
>> > test takes 24 hours to run.  I’ve never actually had any success getting
>> it
>> > to run because it’s crashed on me every time.  (even for release builds).
>> >
>> > Our internal tests take 20 minutes to build… and that is too long IMO.
>> > Certainly our tests could be more comprehensive but I think they’re
>> pretty
>> > damn good right now.
>> >
>> > Would be good if ActiveMQ 6.0 could resolve this and we could get builds
>> > integrated quickly after a commit. :)
>> >
>> > Kevin
>> >
>> > --
>> >
>> > Founder/CEO Spinn3r.com
>> > Location: *San Francisco, CA*
>> > blog: http://burtonator.wordpress.com
>> > … or check out my Google+ profile
>> > 
>> > 
>>
>>
>>
>> --
>> Clebert Suconic
>> http://community.jboss.org/people/clebert.suco...@jboss.com
>> http://clebertsuconic.blogspot.com
>>
>
>
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suco...@jboss.com
http://clebertsuconic.blogspot.com

Re: How is ActiveMQ 6.0 for continual integration / testing?

[Kevin Burton]

NICE.  Also, how long does the entire test / regression suite take?  …
roughly.

On Wed, Apr 1, 2015 at 1:01 PM, Clebert Suconic 
wrote:

> For every Pull Request sent (e.g:
> https://github.com/apache/activemq-6/pull/197)
>
> There will be a build with a considerable sized testsuite running..
> which we call fast-test
> https://builds.apache.org/job/ActiveMQ6-PR-Build/223/
>
>
> This will validate tests, CheckStyle and Licensing.
>
>
>
> This will run the entire JMS tests, unit-tests and some other tests.
> It's worth looking at:
> https://builds.apache.org/job/ActiveMQ6-PR-Build/223/testReport/
>
>
>
> We then run the entire testsuite daily:
> https://builds.apache.org/view/All/job/ActiveMQ6-Nightly-Regression-Test/
>
>
> There are some failures on this environment now but that's something
> we are working to solve with Infra. They run ok on my personal dev
> enrionment and some other servers I have access to.
>
> We are in hold now based on the discussions on dev-list this week, but
> we should fix that soon.
>
>
> Anyway, I hope you get the picture.. PRs are rejected if they fail the
> basic testsuite, and we will monitor the entire testsuite daily.
>
> On Wed, Apr 1, 2015 at 3:48 PM, Kevin Burton  wrote:
> > This was one of the things that bothered/bothers me about ActiveMQ 5.x…
> the
> > test takes 24 hours to run.  I’ve never actually had any success getting
> it
> > to run because it’s crashed on me every time.  (even for release builds).
> >
> > Our internal tests take 20 minutes to build… and that is too long IMO.
> > Certainly our tests could be more comprehensive but I think they’re
> pretty
> > damn good right now.
> >
> > Would be good if ActiveMQ 6.0 could resolve this and we could get builds
> > integrated quickly after a commit. :)
> >
> > Kevin
> >
> > --
> >
> > Founder/CEO Spinn3r.com
> > Location: *San Francisco, CA*
> > blog: http://burtonator.wordpress.com
> > … or check out my Google+ profile
> > 
> > 
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suco...@jboss.com
> http://clebertsuconic.blogspot.com
>



-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile

[jira] [Resolved] (AMQ-5433) AMQP messages stuck in broker when receiver detaches while receiving

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQ-5433.
---
   Resolution: Fixed
Fix Version/s: 5.12.0
 Assignee: Timothy Bish

This is resolved with the recent addition of proper drain support and fixes to 
set lastDeliverSequenceId properly on receiver close.  

> AMQP messages stuck in broker when receiver detaches while receiving
> 
>
> Key: AMQ-5433
> URL: https://issues.apache.org/jira/browse/AMQ-5433
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.11.0
> Environment: broker: snapshot 
> apache-activemq-5.11-20141022.222801-124-bin.tar.gz
> Wed Oct 22 22:28:02 UTC 2014
> host: Linux Fedora 19 x64
> client: Amqp.Net Lite self tests
>Reporter: Chuck Rolke
>Assignee: Timothy Bish
> Fix For: 5.12.0
>
> Attachments: lite_58_amq5.11_closeBusyReceiver_run_2_times.htm..htm
>
>
> [Amqp.Net Lite|https://amqpnetlite.codeplex.com/] has a set of self tests 
> that work OK when run against a Qpidd 0.30 (proton 0.8) broker. However, when 
> run against ActiveMQ 5.10 or 5.11 SNAPSHOT one self tests causes a batch of 
> messages to get stuck in the broker.
> The self test in question is [LinkTests.cs 
> CloseBusyReceiver|https://amqpnetlite.codeplex.com/SourceControl/latest#test/Test.Amqp.NetMF/LinkTests.cs].
> The test 
> * opens a sender and receiver to node q1.
> * sends 20 messages. 
> * when the receiver receives the first message it closes the receiver and 
> that causes an AMQP detach. 
> * then the test opens a second receiver and tries to drain the 20 messages.
> The test fails because the second receiver never receives anything. The AMQ 
> web console shows the 20 messages in the queue. 
> Running the test again without clearing the queue results in 40 messages in 
> the queue and the self test fails because the first receiver never receives 
> any messages and thus never closes the busy receiver. The first 20 messages 
> jam that queue.
> Also, the messages are not received by tools that normally work fine, like 
> qpid-receive.
> This effect is 100% repeatable.
> Protocol trace file to be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (AMQ-4375) JoramJmsTest UnifiedSessionTest and TopicConnectionTest hang when run with SSL, or on windows.

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed AMQ-4375.
-
Resolution: Cannot Reproduce

This has not been happening with these tests enabled since switching to the new 
JMS AMQP client from QPid.  

> JoramJmsTest UnifiedSessionTest and TopicConnectionTest hang when run with 
> SSL, or on windows.
> --
>
> Key: AMQ-4375
> URL: https://issues.apache.org/jira/browse/AMQ-4375
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
> Environment: Windows 7 and Windows 2008 Server
>Reporter: Kevin Earls
> Attachments: AMQ-4375.patch, UnifiedSessionTestWithSSL.txt
>
>
> This test suite results in a hang when run on windows.  I'll attach a patch 
> which excludes it on Windows for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-5413) AMQP test client delivery/redelivery anomoly

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQ-5413.
---
   Resolution: Fixed
Fix Version/s: 5.12.0
 Assignee: Timothy Bish

This is resolved with the addition of proper drain support.  

> AMQP test client delivery/redelivery anomoly
> 
>
> Key: AMQ-5413
> URL: https://issues.apache.org/jira/browse/AMQ-5413
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 5.11.0
> Environment: broker: snapshot 
> apache-activemq-5.11-20141022.222801-124-bin.tar.gz 
>   Wed Oct 22 22:28:02 UTC 2014
> host: Linux Fedora 19 x64
> clients: Apache Qpid C++ messaging qpid-send qpid-receive (current trunk)
> protocol: AMQP 1.0
>Reporter: Chuck Rolke
>Assignee: Timothy Bish
> Fix For: 5.12.0
>
>
> Using Apache Qpid test clients qpid-send and qpid-receive ActiveMQ broker 
> behaves differently from qpidd and I'm wondering if the difference is 
> important.
> The test code command lines are:
> {noformat}
> qpid-send -a "chuck; {create:always}" --connection-options {protocol:amqp1.0} 
> --sequence yes --content-string 0
> qpid-receive -a chuck -m 1 --connection-options "{protocol:amqp1.0}" 
> --print-headers yes
> {noformat}
> When I run the tests against qpidd they send one message and receive one 
> message every time. However against ActiveMQ 5.11 the qpid-receive does not 
> receive the message until one of several conditions:
> * the qpid-receive command also includes "--timeout 1"
> * the qpid-receive command is repeated several, possibly dozens, of times.
> When qpidd broker is running or when activemq is running and --timeout is 
> specified then the qpid-receive output is:
> {noformat}
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options 
> "{protocol:amqp1.0}" --print-headers yes
> Properties: {sn:1, ts:1414177685195174548, x-amqp-first-acquirer:True}
> 0
> {noformat}
> However, activemq running the client twice without the timeout and once with 
> the timeout looks like this:
> {noformat}
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options 
> "{protocol:amqp1.0}" --print-headers yes
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options 
> "{protocol:amqp1.0}" --print-headers yes
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options 
> "{protocol:amqp1.0}" --print-headers yes --timeout 1
> Redelivered: true
> Properties: {sn:1, ts:1414178091185765136, x-amqp-delivery-count:1}
> 0
> {noformat}
> The false receive attempts make the message look like it was already 
> delivered, hence the Redelivered: true, first-acquirer absent and the 
> x-amqp-delivery-count setting.
> Views of the protocol interactions between the brokers and clients are here:
> http://people.apache.org/~chug/adverb_qpid_send_receive_1/
> I ran the tests twice on ActiveMQ with the tcpnodelay option turned on and 
> off but that didn't seem to make any difference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (AMQ-5598) MQTT+NIO+SSL: Concurrent connections lead to 100% CPU usage

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed AMQ-5598.
-
Resolution: Cannot Reproduce

Have not been able to reproduce this at all.  If a means of reproducing it 
becomes available please reopen. 

> MQTT+NIO+SSL: Concurrent connections lead to 100% CPU usage
> ---
>
> Key: AMQ-5598
> URL: https://issues.apache.org/jira/browse/AMQ-5598
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.10.0, 5.11.0
> Environment: Red Hat Enterprise Linux Server release 6.6 (Santiago), 
> Open JDK 64bit 1.7.0.75, 3Gig RAM, 30Gig HDD - 1x ActiveMQ 5.10
> Windows 7 x64, Java 64bit 1.7.0, 8Gig RAM, 1x ActiveMQ 5.10, 1x ActiveMQ 5.11
>Reporter: Josef Awad
>  Labels: performance, security
> Attachments: Screen Shot 2015-02-12 at 8.31.58 PM.png
>
>
> Connecting with multiple instances of  mqtt clients via ssl at the same time 
> causes the borker server to run on 100% CPU usage forever. Only restart of 
> ActiveMQ helps. Thread count maximizes during connection attempt.
> Critical: It doesn't matter if the certificate is valid or not, I am able to 
> shut down the broker from one client with 500 concurrent connecting 
> instances. The payload size is not important. The problem is somewhere at the 
> ssl handshake located. Without ssl everything works fine. Single ssl 
> connections work.
> Similar issues (with older versions) described are here:
> - 
> http://activemq.2283324.n4.nabble.com/SSL-handshake-stalls-broker-with-NIO-td4677916.html
> - 
> http://stackoverflow.com/questions/19395769/activemq-mqtt-maxes-cpu-on-first-client-connect
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-5647) AMQP: Close busy receiver link to queue and open new link: new link never receives

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQ-5647.
---
   Resolution: Fixed
Fix Version/s: 5.12.0
 Assignee: Timothy Bish

This is resolved by the addition of proper drain support and removal of the old 
drainCheck method which could lead to a race that removed all credit from the 
link before any message was dispatched. 

> AMQP: Close busy receiver link to queue and open new link: new link never 
> receives
> --
>
> Key: AMQ-5647
> URL: https://issues.apache.org/jira/browse/AMQ-5647
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 5.11.0
> Environment: ActiveMQ 5.11.1 release on Fedora 19
> Test client: http://amqpnetlite.codeplex.com/ 
> LinkTests.cs 
> http://amqpnetlite.codeplex.com/SourceControl/latest#test/Test.Amqp.NetMF/LinkTests.cs
>Reporter: Chuck Rolke
>Assignee: Timothy Bish
> Fix For: 5.12.0
>
> Attachments: amq-5.11-close-busy-receiver-hangs.html
>
>
> This issue is similar to AMQ-5646 with the notable exception that the first 
> link is closed after receiving one message but before acknowledging any 
> messages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Code donation for stomp.js

[Clebert Suconic]

Have its own repo would be actually a good thing.. it would be even
independent of broker. (think of Apollo, ActiveMQ, ActiveMQ-?, and
even the actual HornetQ would work with this).

Are there any examples within ActiveMQ5 that could consume this?


You would need a maven pom anyways so it could be uploaded and
consumed from projects.

On Thu, Apr 2, 2015 at 4:12 PM, artnaseef  wrote:
> On the placement question - is there anything ActiveMQ-specific?
>
> If not, would it be best with its own repo, like ActiveMQ-CPP?
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/Code-donation-for-stomp-js-tp4694260p4694276.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suco...@jboss.com
http://clebertsuconic.blogspot.com

Re: Code donation for stomp.js

[artnaseef]

On the placement question - is there anything ActiveMQ-specific?

If not, would it be best with its own repo, like ActiveMQ-CPP?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Code-donation-for-stomp-js-tp4694260p4694276.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Comment Edited] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening

[Jim Robinson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392908#comment-14392908
 ] 

Jim Robinson edited comment on AMQ-5082 at 4/2/15 7:39 PM:
---

On Thu, Apr 2, 2015 at 6:30 AM, anselme dewavrin (JIRA) 



You can just drop in the updated files into the 5.11 source tree and
rebuild the activemq-leveldb-store tree.  You should then be able to
take new activemq-leveldb-store-5.11.2-SNAPSHOT.jar and use that
to run the updated code.

The two fixes were in:

https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/ElectingLevelDBStore.scala
https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/groups/ZooKeeperGroup.scala

The unit test changes were:

https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/test/java/org/apache/activemq/leveldb/test/ElectingLevelDBStoreTest.java
https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/test/java/org/apache/activemq/leveldb/test/ZooKeeperTestSupport.java
https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/test/java/org/apache/zookeeper/server/TestServerCnxnFactory.java

Jim



was (Author: jim.robin...@gmail.com):
On Thu, Apr 2, 2015 at 6:30 AM, anselme dewavrin (JIRA) 



You can just drop in the updated files into the 5.11 source tree and
rebuild the activemq-leveldb-store tree.  You should then be able to
take new activemq-leveldb-store-5.11.2-SNAPSHOT.jar and use that
to run the updated code.

The two fixes were in:

https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/ElectingLevelDBStore.scala
https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/groups/ZooKeeperGroup.scala

The unit test changes were:

https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/test/java/org/apache/activemq/leveldb/test/ElectingLevelDBStoreTest.java
https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/test/java/org/apache/activemq/leveldb/test/ZooKeeperTestSupport.java

Jim


> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz, 
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure, 
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB 
> persistence adapter.
> {code}
> 
>directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zookeep0:2181"
>   zkPath="/activemq/leveldb-stores"/>
> 
> {code}
> After about a day or so of sitting idle there are cascading failures and the 
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit 
> 2360fb859694bacac1e48092e53a56b388e1d2f0).  I am going to attach logs from 
> the three mq nodes and the zookeeper logs that reflect the time where the 
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an 
> issue.
> If you need more data it should be pretty easy to get whatever is needed 
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a 
> separate issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Code donation for stomp.js

[Clebert Suconic]

+1


Should we add a pom.xml into this?


I looked into jeff's folder and there is no Maven.. but this is javascript

How would that get packaged on the distribution within activemq-5? (I
will take a look on monday after the holidays.. but if anyone have any
pointers...)



On Thu, Apr 2, 2015 at 11:13 AM, Christian Posta
 wrote:
> I think this would be a valuable contribution to the ActiveMQ code base.
> Thanks for offering!
>
> On Thu, Apr 2, 2015 at 6:13 AM, Jeff Mesnil  wrote:
>
>> Hi,
>>
>> I'm the writer of the stomp.js[1] which is a JavaScript library to use
>> STOMP (over TCP or Web Sockets).
>> This library is used to send and receive messages from Web
>> applications and is often used in conjunction with ActiveMQ. It can
>> also be used from JavaScript applications running in node.js[2] too.
>> ActiveMQ is shipped with it to run its we socket example[3]
>>
>> This library was developed and maintained on my spare time but due to
>> recent development in my life (mainly having a new baby) I no longer
>> have much free time to maintain this library.
>> The library is small, quite stable and documented[4] (I also wrote a
>> book[5] for O'Reilly about it using ActiveMQ as the broker :) but
>> there is still work to iron things out (mainly compatibility with
>> various Web browsers).
>>
>> I don't want it to become abandonware and I'm looking for an Open
>> Source community which could take care of it.
>> ActiveMQ is my first choice as it has always been very supportive of
>> STOMP and was one of the first broker to support Web Sockets.
>>
>> The project is under the Apache License v2.0
>>
>> My only regret with this project is to have rewritten it at one point
>> using CoffeeScript. I think it has hampered contributions (most of the
>> patches updates the generated JavaScript) without much benefit (the
>> CoffeeScript code[6] is just a bit more readable than the generated
>> JavaScript[7]).
>> If the ActiveMQ community is interested by this library, I'd be happy
>> to provide any assistance during the transition.
>>
>> What do you think of this code donation? Would there be some interest?
>>
>> Thanks,
>> jeff
>>
>> [1] https://github.com/jmesnil/stomp-websocket
>> [2] https://www.npmjs.com/package/stompjs
>> [3]
>> https://github.com/apache/activemq/tree/master/activemq-web-demo/src/main/webapp/websocket
>> [4] http://jmesnil.net/stomp-websocket/doc/
>> [5] http://shop.oreilly.com/product/0636920032366.do
>> [6]
>> https://github.com/jmesnil/stomp-websocket/blob/master/src/stomp.coffee
>> [7] https://github.com/jmesnil/stomp-websocket/blob/master/lib/stomp.js
>>
>> --
>> Jeff Mesnil
>> jmes...@gmail.com
>> http://jmesnil.net/weblog/
>>
>
>
>
> --
> *Christian Posta*
> twitter: @christianposta
> http://www.christianposta.com/blog
> http://fabric8.io



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suco...@jboss.com
http://clebertsuconic.blogspot.com

[jira] [Commented] (AMQ-5705) originBrokerURL incorrectly set in advisory messages

[Vu Le (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392966#comment-14392966
 ] 

Vu Le commented on AMQ-5705:


Actually, this is an issue for us. We are capturing metrics from the advisory 
messages and this is causing our metrics to be off.

> originBrokerURL incorrectly set in advisory messages
> 
>
> Key: AMQ-5705
> URL: https://issues.apache.org/jira/browse/AMQ-5705
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: Vu Le
>Priority: Minor
>
> With a broker configured with multiple transports, the "originBrokerURL" 
> property of advisory messages is incorrectly set. 
> Assuming a broker that has two transports configured, an advisory message for 
> a connection made to transport-A may have the "originBrokerURL" property set 
> to transport-B.
> Looks like the "originBrokerURL" value is set from the 
> getDefaultSocketURIString() method in the BrokerService class. Is there a 
> good reason why the "originBrokerURL" value does not correlate with the 
> transport where the advisory event is actually being triggered?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening

[anselme dewavrin (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392950#comment-14392950
 ] 

anselme dewavrin commented on AMQ-5082:
---

Thanks Jim for these precisions.

doing it very soon !

Anselme

> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz, 
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure, 
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB 
> persistence adapter.
> {code}
> 
>directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zookeep0:2181"
>   zkPath="/activemq/leveldb-stores"/>
> 
> {code}
> After about a day or so of sitting idle there are cascading failures and the 
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit 
> 2360fb859694bacac1e48092e53a56b388e1d2f0).  I am going to attach logs from 
> the three mq nodes and the zookeeper logs that reflect the time where the 
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an 
> issue.
> If you need more data it should be pretty easy to get whatever is needed 
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a 
> separate issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening

[Jim Robinson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392908#comment-14392908
 ] 

Jim Robinson commented on AMQ-5082:
---

On Thu, Apr 2, 2015 at 6:30 AM, anselme dewavrin (JIRA) 



You can just drop in the updated files into the 5.11 source tree and
rebuild the activemq-leveldb-store tree.  You should then be able to
take new activemq-leveldb-store-5.11.2-SNAPSHOT.jar and use that
to run the updated code.

The two fixes were in:

https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/ElectingLevelDBStore.scala
https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/main/scala/org/apache/activemq/leveldb/replicated/groups/ZooKeeperGroup.scala

The unit test changes were:

https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/test/java/org/apache/activemq/leveldb/test/ElectingLevelDBStoreTest.java
https://github.com/apache/activemq/blob/master/activemq-leveldb-store/src/test/java/org/apache/activemq/leveldb/test/ZooKeeperTestSupport.java

Jim


> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz, 
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure, 
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB 
> persistence adapter.
> {code}
> 
>directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zookeep0:2181"
>   zkPath="/activemq/leveldb-stores"/>
> 
> {code}
> After about a day or so of sitting idle there are cascading failures and the 
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit 
> 2360fb859694bacac1e48092e53a56b388e1d2f0).  I am going to attach logs from 
> the three mq nodes and the zookeeper logs that reflect the time where the 
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an 
> issue.
> If you need more data it should be pretty easy to get whatever is needed 
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a 
> separate issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Code donation for stomp.js

[Christian Posta]

I think this would be a valuable contribution to the ActiveMQ code base.
Thanks for offering!

On Thu, Apr 2, 2015 at 6:13 AM, Jeff Mesnil  wrote:

> Hi,
>
> I'm the writer of the stomp.js[1] which is a JavaScript library to use
> STOMP (over TCP or Web Sockets).
> This library is used to send and receive messages from Web
> applications and is often used in conjunction with ActiveMQ. It can
> also be used from JavaScript applications running in node.js[2] too.
> ActiveMQ is shipped with it to run its we socket example[3]
>
> This library was developed and maintained on my spare time but due to
> recent development in my life (mainly having a new baby) I no longer
> have much free time to maintain this library.
> The library is small, quite stable and documented[4] (I also wrote a
> book[5] for O'Reilly about it using ActiveMQ as the broker :) but
> there is still work to iron things out (mainly compatibility with
> various Web browsers).
>
> I don't want it to become abandonware and I'm looking for an Open
> Source community which could take care of it.
> ActiveMQ is my first choice as it has always been very supportive of
> STOMP and was one of the first broker to support Web Sockets.
>
> The project is under the Apache License v2.0
>
> My only regret with this project is to have rewritten it at one point
> using CoffeeScript. I think it has hampered contributions (most of the
> patches updates the generated JavaScript) without much benefit (the
> CoffeeScript code[6] is just a bit more readable than the generated
> JavaScript[7]).
> If the ActiveMQ community is interested by this library, I'd be happy
> to provide any assistance during the transition.
>
> What do you think of this code donation? Would there be some interest?
>
> Thanks,
> jeff
>
> [1] https://github.com/jmesnil/stomp-websocket
> [2] https://www.npmjs.com/package/stompjs
> [3]
> https://github.com/apache/activemq/tree/master/activemq-web-demo/src/main/webapp/websocket
> [4] http://jmesnil.net/stomp-websocket/doc/
> [5] http://shop.oreilly.com/product/0636920032366.do
> [6]
> https://github.com/jmesnil/stomp-websocket/blob/master/src/stomp.coffee
> [7] https://github.com/jmesnil/stomp-websocket/blob/master/lib/stomp.js
>
> --
> Jeff Mesnil
> jmes...@gmail.com
> http://jmesnil.net/weblog/
>



-- 
*Christian Posta*
twitter: @christianposta
http://www.christianposta.com/blog
http://fabric8.io

Re: Code donation for stomp.js

[Clebert Suconic]

IMHO I think this should be imported as a folder on both activemq5
project, and activemq-6.. and be integrated with Maven.

On Thu, Apr 2, 2015 at 9:13 AM, Jeff Mesnil  wrote:
> Hi,
>
> I'm the writer of the stomp.js[1] which is a JavaScript library to use
> STOMP (over TCP or Web Sockets).
> This library is used to send and receive messages from Web
> applications and is often used in conjunction with ActiveMQ. It can
> also be used from JavaScript applications running in node.js[2] too.
> ActiveMQ is shipped with it to run its we socket example[3]
>
> This library was developed and maintained on my spare time but due to
> recent development in my life (mainly having a new baby) I no longer
> have much free time to maintain this library.
> The library is small, quite stable and documented[4] (I also wrote a
> book[5] for O'Reilly about it using ActiveMQ as the broker :) but
> there is still work to iron things out (mainly compatibility with
> various Web browsers).
>
> I don't want it to become abandonware and I'm looking for an Open
> Source community which could take care of it.
> ActiveMQ is my first choice as it has always been very supportive of
> STOMP and was one of the first broker to support Web Sockets.
>
> The project is under the Apache License v2.0
>
> My only regret with this project is to have rewritten it at one point
> using CoffeeScript. I think it has hampered contributions (most of the
> patches updates the generated JavaScript) without much benefit (the
> CoffeeScript code[6] is just a bit more readable than the generated
> JavaScript[7]).
> If the ActiveMQ community is interested by this library, I'd be happy
> to provide any assistance during the transition.
>
> What do you think of this code donation? Would there be some interest?
>
> Thanks,
> jeff
>
> [1] https://github.com/jmesnil/stomp-websocket
> [2] https://www.npmjs.com/package/stompjs
> [3] 
> https://github.com/apache/activemq/tree/master/activemq-web-demo/src/main/webapp/websocket
> [4] http://jmesnil.net/stomp-websocket/doc/
> [5] http://shop.oreilly.com/product/0636920032366.do
> [6] https://github.com/jmesnil/stomp-websocket/blob/master/src/stomp.coffee
> [7] https://github.com/jmesnil/stomp-websocket/blob/master/lib/stomp.js
>
> --
> Jeff Mesnil
> jmes...@gmail.com
> http://jmesnil.net/weblog/



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suco...@jboss.com
http://clebertsuconic.blogspot.com

[jira] [Commented] (AMQ-5705) originBrokerURL incorrectly set in advisory messages

[Vu Le (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392775#comment-14392775
 ] 

Vu Le commented on AMQ-5705:


No specific issue...just noticed as I ran through some testing. That's why I 
was asking if there was a good reason why they values do not correlate? To me, 
it would make sense if they matched up.

> originBrokerURL incorrectly set in advisory messages
> 
>
> Key: AMQ-5705
> URL: https://issues.apache.org/jira/browse/AMQ-5705
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: Vu Le
>Priority: Minor
>
> With a broker configured with multiple transports, the "originBrokerURL" 
> property of advisory messages is incorrectly set. 
> Assuming a broker that has two transports configured, an advisory message for 
> a connection made to transport-A may have the "originBrokerURL" property set 
> to transport-B.
> Looks like the "originBrokerURL" value is set from the 
> getDefaultSocketURIString() method in the BrokerService class. Is there a 
> good reason why the "originBrokerURL" value does not correlate with the 
> transport where the advisory event is actually being triggered?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5701) Invalid TLS Padding data Error

[Harikrishnan P (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392716#comment-14392716
 ] 

Harikrishnan P commented on AMQ-5701:
-

It worked !! Thanks for your help .. 

> Invalid TLS Padding data Error
> --
>
> Key: AMQ-5701
> URL: https://issues.apache.org/jira/browse/AMQ-5701
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.0
> Environment: Ubuntu 12.04 Kernel 3.13, java version 
> "1.7.0_72",OpenSSL 1.0.1 
>Reporter: Harikrishnan P
>
> 
> 
>  uri="tcp://0.0.0.0:1883?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
> 
> 
> Tried creating certificates as per the following link:
> https://github.com/rethab/php-stomp-cert-example/blob/master/README.md



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5155) Heartbeat fails in STOMP over WebSockets

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392674#comment-14392674
 ] 

Timothy Bish commented on AMQ-5155:
---

Added a fix, let me know if it works for you.

> Heartbeat fails in STOMP over WebSockets
> 
>
> Key: AMQ-5155
> URL: https://issues.apache.org/jira/browse/AMQ-5155
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.9.1, 5.10.0
>Reporter: Arjan van den Berg
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.12.0
>
> Attachments: AMQ-5155-jetty8.diff, AMQ-5155-jetty9.diff
>
>
> From AMQ-4740:
> I receive the following error after establishing a connection and heartbeat 
> through stomp.js. This seems to occur after the 'PING' is sent.
> -- stomp.js output
> <<< CONNECTED
> heart-beat:1,1
> session:ID:localhost.localdomain-45596-1396530920609-2:2
> server:ActiveMQ/5.10-SNAPSHOT
> version:1.1
> send PING every 1ms 
> check PONG every 1ms 
> <<< PONG 
> >>> PING 
> did not receive server activity for the last 20005ms 
> Whoops! Lost connection to ws://172.16.99.73:61614/stomp
> - activemq console ---
> WARN | Transport Connection to: StompSocket_19548821 failed: 
> java.io.IOException
> Exception in thread "ActiveMQ InactivityMonitor Worker" 
> java.lang.NullPointerException
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onException(AbstractInactivityMonitor.java:314)
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:215)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> WARN | Transport Connection to: StompSocket_19548821 failed: 
> java.io.IOException
> Exception in thread "ActiveMQ InactivityMonitor Worker" 
> java.lang.NullPointerException
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onException(AbstractInactivityMonitor.java:314)
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:215)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> For me it looks as if the StompInactivityMonitor is delivering its events to 
> the wrong Transport, i.e. it needs a "narrow()" when setting it up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening

[anselme dewavrin (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392618#comment-14392618
 ] 

anselme dewavrin commented on AMQ-5082:
---

Well, it depends... When do you think v5.12 is planned for release ?

How do I patch a 5.11 ?

Thank you, we have been using ActiveMQ a lot in production for 20 months and it 
works well. We could give testimonial.

Anselme

> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz, 
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure, 
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB 
> persistence adapter.
> {code}
> 
>directory="${activemq.data}/leveldb"
>   replicas="3"
>   bind="tcp://0.0.0.0:0"
>   zkAddress="zookeep0:2181"
>   zkPath="/activemq/leveldb-stores"/>
> 
> {code}
> After about a day or so of sitting idle there are cascading failures and the 
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit 
> 2360fb859694bacac1e48092e53a56b388e1d2f0).  I am going to attach logs from 
> the three mq nodes and the zookeeper logs that reflect the time where the 
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an 
> issue.
> If you need more data it should be pretty easy to get whatever is needed 
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a 
> separate issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5705) originBrokerURL incorrectly set in advisory messages

[Abhi (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392549#comment-14392549
 ] 

Abhi commented on AMQ-5705:
---

What kind of issues can be triggered by this?

> originBrokerURL incorrectly set in advisory messages
> 
>
> Key: AMQ-5705
> URL: https://issues.apache.org/jira/browse/AMQ-5705
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: Vu Le
>Priority: Minor
>
> With a broker configured with multiple transports, the "originBrokerURL" 
> property of advisory messages is incorrectly set. 
> Assuming a broker that has two transports configured, an advisory message for 
> a connection made to transport-A may have the "originBrokerURL" property set 
> to transport-B.
> Looks like the "originBrokerURL" value is set from the 
> getDefaultSocketURIString() method in the BrokerService class. Is there a 
> good reason why the "originBrokerURL" value does not correlate with the 
> transport where the advisory event is actually being triggered?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5701) Invalid TLS Padding data Error

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392481#comment-14392481
 ] 

Timothy Bish commented on AMQ-5701:
---

This would of course fail as the transport connection being defined there for 
ssl is for OpenWire protocol based clients.  You should instead use mqtt+ssl or 
mqtt+nio+ssl as the transport connector.  

> Invalid TLS Padding data Error
> --
>
> Key: AMQ-5701
> URL: https://issues.apache.org/jira/browse/AMQ-5701
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.0
> Environment: Ubuntu 12.04 Kernel 3.13, java version 
> "1.7.0_72",OpenSSL 1.0.1 
>Reporter: Harikrishnan P
>
> 
> 
>  uri="tcp://0.0.0.0:1883?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
> 
> 
> Tried creating certificates as per the following link:
> https://github.com/rethab/php-stomp-cert-example/blob/master/README.md



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Code donation for stomp.js

[Jeff Mesnil]

Hi,

I'm the writer of the stomp.js[1] which is a JavaScript library to use
STOMP (over TCP or Web Sockets).
This library is used to send and receive messages from Web
applications and is often used in conjunction with ActiveMQ. It can
also be used from JavaScript applications running in node.js[2] too.
ActiveMQ is shipped with it to run its we socket example[3]

This library was developed and maintained on my spare time but due to
recent development in my life (mainly having a new baby) I no longer
have much free time to maintain this library.
The library is small, quite stable and documented[4] (I also wrote a
book[5] for O'Reilly about it using ActiveMQ as the broker :) but
there is still work to iron things out (mainly compatibility with
various Web browsers).

I don't want it to become abandonware and I'm looking for an Open
Source community which could take care of it.
ActiveMQ is my first choice as it has always been very supportive of
STOMP and was one of the first broker to support Web Sockets.

The project is under the Apache License v2.0

My only regret with this project is to have rewritten it at one point
using CoffeeScript. I think it has hampered contributions (most of the
patches updates the generated JavaScript) without much benefit (the
CoffeeScript code[6] is just a bit more readable than the generated
JavaScript[7]).
If the ActiveMQ community is interested by this library, I'd be happy
to provide any assistance during the transition.

What do you think of this code donation? Would there be some interest?

Thanks,
jeff

[1] https://github.com/jmesnil/stomp-websocket
[2] https://www.npmjs.com/package/stompjs
[3] 
https://github.com/apache/activemq/tree/master/activemq-web-demo/src/main/webapp/websocket
[4] http://jmesnil.net/stomp-websocket/doc/
[5] http://shop.oreilly.com/product/0636920032366.do
[6] https://github.com/jmesnil/stomp-websocket/blob/master/src/stomp.coffee
[7] https://github.com/jmesnil/stomp-websocket/blob/master/lib/stomp.js

-- 
Jeff Mesnil
jmes...@gmail.com
http://jmesnil.net/weblog/

[jira] [Commented] (AMQ-5155) Heartbeat fails in STOMP over WebSockets

[Peter Pfort (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392271#comment-14392271
 ] 

Peter Pfort commented on AMQ-5155:
--

Hi Timothy,
your change in version 5.12 isn't complete. You forget the "else" before the 
"onStompCommand ...", like in the snippet from Claudio.

The "(StompFrame)wireFormat.unmarshal" throw an EOFException, because the 
KeepAlive command isn't handled in it. Then the session is marked as failed.

Please complete the code.

Peter

> Heartbeat fails in STOMP over WebSockets
> 
>
> Key: AMQ-5155
> URL: https://issues.apache.org/jira/browse/AMQ-5155
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.9.1, 5.10.0
>Reporter: Arjan van den Berg
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.12.0
>
> Attachments: AMQ-5155-jetty8.diff, AMQ-5155-jetty9.diff
>
>
> From AMQ-4740:
> I receive the following error after establishing a connection and heartbeat 
> through stomp.js. This seems to occur after the 'PING' is sent.
> -- stomp.js output
> <<< CONNECTED
> heart-beat:1,1
> session:ID:localhost.localdomain-45596-1396530920609-2:2
> server:ActiveMQ/5.10-SNAPSHOT
> version:1.1
> send PING every 1ms 
> check PONG every 1ms 
> <<< PONG 
> >>> PING 
> did not receive server activity for the last 20005ms 
> Whoops! Lost connection to ws://172.16.99.73:61614/stomp
> - activemq console ---
> WARN | Transport Connection to: StompSocket_19548821 failed: 
> java.io.IOException
> Exception in thread "ActiveMQ InactivityMonitor Worker" 
> java.lang.NullPointerException
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onException(AbstractInactivityMonitor.java:314)
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:215)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> WARN | Transport Connection to: StompSocket_19548821 failed: 
> java.io.IOException
> Exception in thread "ActiveMQ InactivityMonitor Worker" 
> java.lang.NullPointerException
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onException(AbstractInactivityMonitor.java:314)
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:215)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> For me it looks as if the StompInactivityMonitor is delivering its events to 
> the wrong Transport, i.e. it needs a "narrow()" when setting it up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)