[jira] Commented: (AMQ-2829) HealthCheck for hardware loadbalancers

[JIRA]

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

Dirk Alexander Schäfer commented on AMQ-2829:
-

so we could say: it's not a bug, it's feature... ;)

> HealthCheck for hardware loadbalancers
> --
>
> Key: AMQ-2829
> URL: https://issues.apache.org/activemq/browse/AMQ-2829
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
> Environment: ALL
>Reporter: Dirk Alexander Schäfer
>Assignee: Gary Tully
>Priority: Minor
> Fix For: 5.4.0
>
> Attachments: com.swisscom.ei.commons.activemq.zip, jetty.xml
>
>
> hi there,
> we had the problem that we were not able to integrate our network of brokers 
> in our cluster setup where a hardware loadbalancer was in front of the 
> cluster. as the loadbalancer needs to run health checks against each node in 
> the cluster, we needed to find a way to offer an endpoint the loadbalancer 
> could send its probe requests to.
> we decided to develope a little web application that returns "pong" if the 
> jms provider is available, "offline" else. we've created a webapp that can be 
> deployed in the jetty that comes with activemq. i attach the whole eclipse 
> project ziped to this issue. i haven't cleaned it so it will not fitt into 
> the activemq package hierarchy but it should be enough to get an idea of how 
> we did it. i also attach the modified jetty.xml were we added the webapp in 
> order to become it loaded.
> it might look a bit oversized as it is based upon spring web mvc, spring 
> security and tiles but our intention was to be able to put further 
> administrative functionality into the web app once needed.
> how it works: a consumer as well as a producer are being created during the 
> startup of the app. the consumer makes sure that messages get dispatched and 
> do not fill the queue, allthough the messages are marked none-persistence and 
> have a ttl of 5 secs, just to be sure. if a check request comes in 
> (/lbProbe/ping.htm) the app tries to put a message into the queue (the queue 
> name is configurable through spring). if this succeeds, the OK-result will be 
> returned, otherwise the NOT-OK-result. both are configurable through spring.
> known bugs: if one deletes the queue the app is using through e.g. the admin 
> web app, the check will strill return OK.
> things to beware of: the name of the queue the webapp uses should be 
> configured in the excludes of the networkConnector settings ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQ-2827) Intermittent 204 response using REST

[Michael Lok (JIRA)]

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

Michael Lok updated AMQ-2827:
-

Description: 
Was able to successfully send 20 messages to AMQ via REST.  I can see that the 
messages were consumed and there are 20 messages in the response queue.  
However, when reading the response queue using selector via REST, it 
intermittently returns HTTP code 204.  By looking at the "Active Consumers" for 
the response queue, I can see that the specific message has been dispatched to 
the consumer as the "Enqueues", "Dequeues" and "Dispatched" values are set to 1.

The server has been configured with consumer.prefetchSize=1.

I've further tried reproducing the problem by setting consumer.prefetchSize=0.  
When I get a 204 response, I can see that the message is in the outgoing queue. 
 But executing another GET with the same Correlation ID will hang the client 
even though readTimeout is set.

This has been tested with 5.4-SNAPSHOT 15-July.



  was:
Was able to successfully send 20 messages to AMQ via REST.  I can see that the 
messages were consumed and there are 20 messages in the response queue.  
However, when reading the response queue using selector via REST, it 
intermittently returns HTTP code 204.  By looking at the "Active Consumers" for 
the response queue, I can see that the specific message has been dispatched to 
the consumer as the "Enqueues", "Dequeues" and "Dispatched" values are set to 1.

The server has been configured with consumer.prefetchSize=1.

I've further tried reproducing the problem by setting consumer.prefetchSize=0.  
When I get a 204 response, I can see that the message is in the outgoing queue. 
 But executing another GET with the same Correlation ID will hang the client 
even though readTimeout is set.




> Intermittent 204 response using REST
> 
>
> Key: AMQ-2827
> URL: https://issues.apache.org/activemq/browse/AMQ-2827
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.4.0
> Environment: Linux
> JDK5
>Reporter: Michael Lok
> Attachments: restclient.java
>
>
> Was able to successfully send 20 messages to AMQ via REST.  I can see that 
> the messages were consumed and there are 20 messages in the response queue.  
> However, when reading the response queue using selector via REST, it 
> intermittently returns HTTP code 204.  By looking at the "Active Consumers" 
> for the response queue, I can see that the specific message has been 
> dispatched to the consumer as the "Enqueues", "Dequeues" and "Dispatched" 
> values are set to 1.
> The server has been configured with consumer.prefetchSize=1.
> I've further tried reproducing the problem by setting 
> consumer.prefetchSize=0.  When I get a 204 response, I can see that the 
> message is in the outgoing queue.  But executing another GET with the same 
> Correlation ID will hang the client even though readTimeout is set.
> This has been tested with 5.4-SNAPSHOT 15-July.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[AMQ-CPP] Issues with 3.2.1

[Romain CHANU]

Hi,

I am currently upgrading my client from 3.1.0 to 3.2.1.

The environment used is very broad:

- Centos 5.3 (gcc 4.1.2, APR 1.3.9, APR-util 1.3.9)
- Debian 5.0 (gcc 4.3.2, APR 1.3.5, APR-util 1.3.7)
- Fedora 11 (gcc 4.4.0, APR 1.3.5, APR-util 1.3.9)
- Ubuntu 10.04 (gcc 4.4.3, APR 1.3.8, APR-util 1.3.9)

The compilation works whatever the environment used :-)

However, I am facing major issues:

1) On Centos 5.3 and Debian 5.0, "make check" fails:

(error reported from Centos 5.3)

g++ -DHAVE_CONFIG_H -I. -I../..-ansi -pedantic   -DLINUX=2 -D_REENTRANT
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE  -I/usr/local/apr/include/apr-1
-I/usr/local/apr/include/apr-1   -W -Wall -Wextra -Wconversion -fPIC
-fstrict-aliasing -Wstrict-aliasing=2 -Wno-long-long   -DLINUX=2
-D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-I/usr/local/apr/include/apr-1   -I/usr/local/apr/include/apr-1
-Wno-non-virtual-dtor -Wno-unused-parameter -Wno-uninitialized -I./../main
-I/usr/local/include -g -O2 -pthread -MT
activemq/test/activemq_test_integration-MessageCompressionTest.o -MD -MP -MF
activemq/test/.deps/activemq_test_integration-MessageCompressionTest.Tpo -c
-o activemq/test/activemq_test_integration-MessageCompressionTest.o `test -f
'activemq/test/MessageCompressionTest.cpp' || echo
'./'`activemq/test/MessageCompressionTest.cpp
activemq/test/MessageCompressionTest.cpp:63: error: integer constant is too
large for ‘long’ type
activemq/test/MessageCompressionTest.cpp:69: error: integer constant is too
large for ‘long’ type


2) I tried to run the examples provided in the package:

- On Centos 5.3 and Debian 5.0, none of the examples worked... I got a
"segmentation fault"

- On Fedora 11 and Ubuntu 10.04, all the examples worked.


Do you have any idea on what's going on?


Thank you.

Regards,

Romain

[jira] Updated: (AMQ-2827) Intermittent 204 response using REST

[Michael Lok (JIRA)]

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

Michael Lok updated AMQ-2827:
-

Description: 
Was able to successfully send 20 messages to AMQ via REST.  I can see that the 
messages were consumed and there are 20 messages in the response queue.  
However, when reading the response queue using selector via REST, it 
intermittently returns HTTP code 204.  By looking at the "Active Consumers" for 
the response queue, I can see that the specific message has been dispatched to 
the consumer as the "Enqueues", "Dequeues" and "Dispatched" values are set to 1.

The server has been configured with consumer.prefetchSize=1.

I've further tried reproducing the problem by setting consumer.prefetchSize=0.  
When I get a 204 response, I can see that the message is in the outgoing queue. 
 But executing another GET with the same Correlation ID will hang the client 
even though readTimeout is set.



  was:
Was able to successfully send 20 messages to AMQ via REST.  I can see that the 
messages were consumed and there are 20 messages in the response queue.  
However, when reading the response queue using selector via REST, it 
intermittently returns HTTP code 204.  By looking at the "Active Consumers" for 
the response queue, I can see that the specific message has been dispatched to 
the consumer as the "Enqueues", "Dequeues" and "Dispatched" values are set to 1.

The server has been configured with consumer.prefetchSize=1.




> Intermittent 204 response using REST
> 
>
> Key: AMQ-2827
> URL: https://issues.apache.org/activemq/browse/AMQ-2827
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.4.0
> Environment: Linux
> JDK5
>Reporter: Michael Lok
> Attachments: restclient.java
>
>
> Was able to successfully send 20 messages to AMQ via REST.  I can see that 
> the messages were consumed and there are 20 messages in the response queue.  
> However, when reading the response queue using selector via REST, it 
> intermittently returns HTTP code 204.  By looking at the "Active Consumers" 
> for the response queue, I can see that the specific message has been 
> dispatched to the consumer as the "Enqueues", "Dequeues" and "Dispatched" 
> values are set to 1.
> The server has been configured with consumer.prefetchSize=1.
> I've further tried reproducing the problem by setting 
> consumer.prefetchSize=0.  When I get a 204 response, I can see that the 
> message is in the outgoing queue.  But executing another GET with the same 
> Correlation ID will hang the client even though readTimeout is set.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra

[Scott Clasen (JIRA)]

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

Scott Clasen commented on AMQ-2826:
---

So any suggestions on how to proceed? The maven profile for now could simply 
prevent the tests from being run... 

Not sure what type of infrastructure is available in the CI environment, as far 
as having the ability to stand up a single node cassandra and zookeeper 
instance to run the tests agains at some point...

How is the JDBC Store tested against all the different vendors that are 
supported?

> Look at the possibility of incorporating a cassandra persistence adapter from 
> http://github.com/ticktock/qsandra 
> -
>
> Key: AMQ-2826
> URL: https://issues.apache.org/activemq/browse/AMQ-2826
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Affects Versions: 5.3.2
>Reporter: Scott Clasen
>
> I am the author of http://github.com/ticktock/qsandra, which is a cassandra 
> persistence adapter for activemq. I am willing to donate it if it is 
> something that is of interest to ActiveMQ..
> Only current trouble with that is it needs JDK 1.6, so it would probably need 
> to wait until (if and when) ActiveMQ 5.x is built with JDK 6.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQNET-263) Upgrade to NUnit 2.5.5

[Jim Gomes (JIRA)]

Upgrade to NUnit 2.5.5
--

 Key: AMQNET-263
 URL: https://issues.apache.org/activemq/browse/AMQNET-263
 Project: ActiveMQ .Net
  Issue Type: Test
  Components: ActiveMQ, EMS, MSMQ, NMS, Stomp, WCF
Affects Versions: 1.4.0
Reporter: Jim Gomes
Assignee: Jim Gomes
 Fix For: 1.4.0


Upgrade to the latest NUnit 2.5.5 libraries and APIs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQNET-261) NMS URI handling in URISupport needs improvement.

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/activemq/browse/AMQNET-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60683#action_60683
 ] 

Timothy Bish commented on AMQNET-261:
-

Probably not going to support this one because the .NET Uri class really hates 
it:

failover://tcp://primary:61616

This works though so that's good enough I think.

failover:tcp://primary:61616


> NMS URI handling in URISupport needs improvement.
> -
>
> Key: AMQNET-261
> URL: https://issues.apache.org/activemq/browse/AMQNET-261
> Project: ActiveMQ .Net
>  Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 1.4.0
>
>
> The URI handling in NMS that allows for composite URIs and for setting 
> options via the URI needs some work.  
> 1. When setting options for the connection when a Failover URI is specified 
> you receive and exception because the options aren't filter out based on the 
> prefix, so for instance a value of connection=asyncSend=true will cause an 
> exception in the failover URI case but not in a plain TCP uri case.  Example: 
> The following URI additional test case added to NMSConnectionFactoryTest 
> should work, but it gives an exception.
> {noformat}
>   
> [Row("activemq:failover:(tcp://${activemqhost}:61616)?connection.asyncSend=true")]
> {noformat}
> 2. Those referring to the AMQ docs will assume that URIs like the one's below 
> should work but will get an exception instead.
> {noformat}
> 
> failover://(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
> failover://tcp://primary:61616
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AMQNET-262) NMS cannot be used if installed in the GAC

[Jim Gomes (JIRA)]

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

Jim Gomes resolved AMQNET-262.
--

Resolution: Fixed

Thanks for the patch, Daniel.  I applied it and made a few modifications to it. 
 The extension needed to be added back when searching for the full filenames.  
I also changed the call from Assembly.LoadWithPartialName() to Assembly.Load(), 
because LoadWithPartialName() is obsolete.  The functionality should be 
equivalent.

Please review the changes to make sure everything works as intended, and if it 
does, you can close this issue.

> NMS cannot be used if installed in the GAC
> --
>
> Key: AMQNET-262
> URL: https://issues.apache.org/activemq/browse/AMQNET-262
> Project: ActiveMQ .Net
>  Issue Type: Improvement
>  Components: NMS
>Affects Versions: 1.3.0
> Environment: Windows .NET 2.0
>Reporter: Daniel Ellis
>Assignee: Jim Gomes
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: NMS GAC.patch
>
>  Time Spent: 45 minutes
>  Remaining Estimate: 0 minutes
>
> If you install {{Apache.NMS.dll}} and {{Apache.NMS.ActiveMQ.dll}} in the GAC 
> then NMS is not able to load {{Apache.NMS.ActiveMQ.dll}}.
> {{NMSConnectionFactory.cs}} is storing the pre-defined connection factories 
> in _schemaProviderFactoryMap_, but is storing the DLL file names to locate 
> the assemblies.
> One solution would be to store the _AssemblyQualifiedName_ instead and leave 
> the assembly loading to the system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Work logged: (AMQNET-262) NMS cannot be used if installed in the GAC

[Jim Gomes (JIRA)]

 [ 
https://issues.apache.org/activemq/browse/AMQNET-262?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#action_36921
 ]

Jim Gomes logged work on AMQNET-262:


Author: Jim Gomes
Created on: 15/Jul/10 03:29 PM
Start Date: 15/Jul/10 03:29 PM
Worklog Time Spent: 45 minutes 
  Work Description: Applied patch and made some modifications.

Issue Time Tracking
---

Remaining Estimate: 0 minutes
Time Spent: 45 minutes

> NMS cannot be used if installed in the GAC
> --
>
> Key: AMQNET-262
> URL: https://issues.apache.org/activemq/browse/AMQNET-262
> Project: ActiveMQ .Net
>  Issue Type: Improvement
>  Components: NMS
>Affects Versions: 1.3.0
> Environment: Windows .NET 2.0
>Reporter: Daniel Ellis
>Assignee: Jim Gomes
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: NMS GAC.patch
>
>  Time Spent: 45 minutes
>  Remaining Estimate: 0 minutes
>
> If you install {{Apache.NMS.dll}} and {{Apache.NMS.ActiveMQ.dll}} in the GAC 
> then NMS is not able to load {{Apache.NMS.ActiveMQ.dll}}.
> {{NMSConnectionFactory.cs}} is storing the pre-defined connection factories 
> in _schemaProviderFactoryMap_, but is storing the DLL file names to locate 
> the assemblies.
> One solution would be to store the _AssemblyQualifiedName_ instead and leave 
> the assembly loading to the system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQ-2829) HealthCheck for hardware loadbalancers

[Gary Tully (JIRA)]

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

Gary Tully updated AMQ-2829:


Fix Version/s: 5.4.0
   Patch Info: [Patch Available]
  Component/s: Broker

This looks like an nice addition. Will try and get this integrated for the 5.4 
release. Thanks for the contribution :-)
Possibly we can choose a queue name that is auto excluded from networks, 
possibly even a temp queue.

The issue with the pong working when the queue is removed using the admin 
console is simply the default activemq on demand destination creation policy, 
it is auto created on the next send attempt.

> HealthCheck for hardware loadbalancers
> --
>
> Key: AMQ-2829
> URL: https://issues.apache.org/activemq/browse/AMQ-2829
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
> Environment: ALL
>Reporter: Dirk Alexander Schäfer
>Assignee: Gary Tully
>Priority: Minor
> Fix For: 5.4.0
>
> Attachments: com.swisscom.ei.commons.activemq.zip, jetty.xml
>
>
> hi there,
> we had the problem that we were not able to integrate our network of brokers 
> in our cluster setup where a hardware loadbalancer was in front of the 
> cluster. as the loadbalancer needs to run health checks against each node in 
> the cluster, we needed to find a way to offer an endpoint the loadbalancer 
> could send its probe requests to.
> we decided to develope a little web application that returns "pong" if the 
> jms provider is available, "offline" else. we've created a webapp that can be 
> deployed in the jetty that comes with activemq. i attach the whole eclipse 
> project ziped to this issue. i haven't cleaned it so it will not fitt into 
> the activemq package hierarchy but it should be enough to get an idea of how 
> we did it. i also attach the modified jetty.xml were we added the webapp in 
> order to become it loaded.
> it might look a bit oversized as it is based upon spring web mvc, spring 
> security and tiles but our intention was to be able to put further 
> administrative functionality into the web app once needed.
> how it works: a consumer as well as a producer are being created during the 
> startup of the app. the consumer makes sure that messages get dispatched and 
> do not fill the queue, allthough the messages are marked none-persistence and 
> have a ttl of 5 secs, just to be sure. if a check request comes in 
> (/lbProbe/ping.htm) the app tries to put a message into the queue (the queue 
> name is configurable through spring). if this succeeds, the OK-result will be 
> returned, otherwise the NOT-OK-result. both are configurable through spring.
> known bugs: if one deletes the queue the app is using through e.g. the admin 
> web app, the check will strill return OK.
> things to beware of: the name of the queue the webapp uses should be 
> configured in the excludes of the networkConnector settings ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (AMQ-2829) HealthCheck for hardware loadbalancers

[Gary Tully (JIRA)]

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

Gary Tully reassigned AMQ-2829:
---

Assignee: Gary Tully

> HealthCheck for hardware loadbalancers
> --
>
> Key: AMQ-2829
> URL: https://issues.apache.org/activemq/browse/AMQ-2829
> Project: ActiveMQ
>  Issue Type: New Feature
> Environment: ALL
>Reporter: Dirk Alexander Schäfer
>Assignee: Gary Tully
>Priority: Minor
> Attachments: com.swisscom.ei.commons.activemq.zip, jetty.xml
>
>
> hi there,
> we had the problem that we were not able to integrate our network of brokers 
> in our cluster setup where a hardware loadbalancer was in front of the 
> cluster. as the loadbalancer needs to run health checks against each node in 
> the cluster, we needed to find a way to offer an endpoint the loadbalancer 
> could send its probe requests to.
> we decided to develope a little web application that returns "pong" if the 
> jms provider is available, "offline" else. we've created a webapp that can be 
> deployed in the jetty that comes with activemq. i attach the whole eclipse 
> project ziped to this issue. i haven't cleaned it so it will not fitt into 
> the activemq package hierarchy but it should be enough to get an idea of how 
> we did it. i also attach the modified jetty.xml were we added the webapp in 
> order to become it loaded.
> it might look a bit oversized as it is based upon spring web mvc, spring 
> security and tiles but our intention was to be able to put further 
> administrative functionality into the web app once needed.
> how it works: a consumer as well as a producer are being created during the 
> startup of the app. the consumer makes sure that messages get dispatched and 
> do not fill the queue, allthough the messages are marked none-persistence and 
> have a ttl of 5 secs, just to be sure. if a check request comes in 
> (/lbProbe/ping.htm) the app tries to put a message into the queue (the queue 
> name is configurable through spring). if this succeeds, the OK-result will be 
> returned, otherwise the NOT-OK-result. both are configurable through spring.
> known bugs: if one deletes the queue the app is using through e.g. the admin 
> web app, the check will strill return OK.
> things to beware of: the name of the queue the webapp uses should be 
> configured in the excludes of the networkConnector settings ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQ-2829) HealthCheck for hardware loadbalancers

[JIRA]

HealthCheck for hardware loadbalancers
--

 Key: AMQ-2829
 URL: https://issues.apache.org/activemq/browse/AMQ-2829
 Project: ActiveMQ
  Issue Type: New Feature
 Environment: ALL
Reporter: Dirk Alexander Schäfer
Priority: Minor


hi there,

we had the problem that we were not able to integrate our network of brokers in 
our cluster setup where a hardware loadbalancer was in front of the cluster. as 
the loadbalancer needs to run health checks against each node in the cluster, 
we needed to find a way to offer an endpoint the loadbalancer could send its 
probe requests to.

we decided to develope a little web application that returns "pong" if the jms 
provider is available, "offline" else. we've created a webapp that can be 
deployed in the jetty that comes with activemq. i attach the whole eclipse 
project ziped to this issue. i haven't cleaned it so it will not fitt into the 
activemq package hierarchy but it should be enough to get an idea of how we did 
it. i also attach the modified jetty.xml were we added the webapp in order to 
become it loaded.

it might look a bit oversized as it is based upon spring web mvc, spring 
security and tiles but our intention was to be able to put further 
administrative functionality into the web app once needed.

how it works: a consumer as well as a producer are being created during the 
startup of the app. the consumer makes sure that messages get dispatched and do 
not fill the queue, allthough the messages are marked none-persistence and have 
a ttl of 5 secs, just to be sure. if a check request comes in 
(/lbProbe/ping.htm) the app tries to put a message into the queue (the queue 
name is configurable through spring). if this succeeds, the OK-result will be 
returned, otherwise the NOT-OK-result. both are configurable through spring.

known bugs: if one deletes the queue the app is using through e.g. the admin 
web app, the check will strill return OK.

things to beware of: the name of the queue the webapp uses should be configured 
in the excludes of the networkConnector settings ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQ-2829) HealthCheck for hardware loadbalancers

[JIRA]

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

Dirk Alexander Schäfer updated AMQ-2829:


Attachment: com.swisscom.ei.commons.activemq.zip
jetty.xml

> HealthCheck for hardware loadbalancers
> --
>
> Key: AMQ-2829
> URL: https://issues.apache.org/activemq/browse/AMQ-2829
> Project: ActiveMQ
>  Issue Type: New Feature
> Environment: ALL
>Reporter: Dirk Alexander Schäfer
>Priority: Minor
> Attachments: com.swisscom.ei.commons.activemq.zip, jetty.xml
>
>
> hi there,
> we had the problem that we were not able to integrate our network of brokers 
> in our cluster setup where a hardware loadbalancer was in front of the 
> cluster. as the loadbalancer needs to run health checks against each node in 
> the cluster, we needed to find a way to offer an endpoint the loadbalancer 
> could send its probe requests to.
> we decided to develope a little web application that returns "pong" if the 
> jms provider is available, "offline" else. we've created a webapp that can be 
> deployed in the jetty that comes with activemq. i attach the whole eclipse 
> project ziped to this issue. i haven't cleaned it so it will not fitt into 
> the activemq package hierarchy but it should be enough to get an idea of how 
> we did it. i also attach the modified jetty.xml were we added the webapp in 
> order to become it loaded.
> it might look a bit oversized as it is based upon spring web mvc, spring 
> security and tiles but our intention was to be able to put further 
> administrative functionality into the web app once needed.
> how it works: a consumer as well as a producer are being created during the 
> startup of the app. the consumer makes sure that messages get dispatched and 
> do not fill the queue, allthough the messages are marked none-persistence and 
> have a ttl of 5 secs, just to be sure. if a check request comes in 
> (/lbProbe/ping.htm) the app tries to put a message into the queue (the queue 
> name is configurable through spring). if this succeeds, the OK-result will be 
> returned, otherwise the NOT-OK-result. both are configurable through spring.
> known bugs: if one deletes the queue the app is using through e.g. the admin 
> web app, the check will strill return OK.
> things to beware of: the name of the queue the webapp uses should be 
> configured in the excludes of the networkConnector settings ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hudson build is still unstable: ActiveMQ » ActiveMQ :: RA #407

[Apache Hudson Server]

See 

Hudson build is still unstable: ActiveMQ » ActiveMQ :: Core #407

[Apache Hudson Server]

See 

Hudson build is still unstable: ActiveMQ #407

[Apache Hudson Server]

See 

Hudson build is back to stable : ActiveMQ » ActiveMQ :: XMPP #407

[Apache Hudson Server]

See 

[jira] Commented: (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra

[Dejan Bosanac (JIRA)]

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

Dejan Bosanac commented on AMQ-2826:


I think introducing the new maven profile for running these tests is the way to 
go for now. We also need to ensure that our CI tools test this code properly. 
Maybe with some future release (AMQ 6.0) we can also introduce JDK 6 
compatibility?

> Look at the possibility of incorporating a cassandra persistence adapter from 
> http://github.com/ticktock/qsandra 
> -
>
> Key: AMQ-2826
> URL: https://issues.apache.org/activemq/browse/AMQ-2826
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Affects Versions: 5.3.2
>Reporter: Scott Clasen
>
> I am the author of http://github.com/ticktock/qsandra, which is a cassandra 
> persistence adapter for activemq. I am willing to donate it if it is 
> something that is of interest to ActiveMQ..
> Only current trouble with that is it needs JDK 1.6, so it would probably need 
> to wait until (if and when) ActiveMQ 5.x is built with JDK 6.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra

[Scott Clasen (JIRA)]

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

Scott Clasen commented on AMQ-2826:
---

Gary-

   The 1.6 dependency is more of a dependency for testing.  Cassandra itself 
requires 1.6, and the unit tests use an embedded cassandra server as the 
backend.

They could be easily made to run against an external instance, but that 
complicates the build, maybe they could be constrained to run only against a 
certain maven profile?

Other than that the persistence adapter uses only the cassandra thrift 
interface, and also a BloomFilter from Cassandra. Both the thrift interface and 
the bloom filter could be extracted and compiled under 1.5...I think

Thoughts?

> Look at the possibility of incorporating a cassandra persistence adapter from 
> http://github.com/ticktock/qsandra 
> -
>
> Key: AMQ-2826
> URL: https://issues.apache.org/activemq/browse/AMQ-2826
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Affects Versions: 5.3.2
>Reporter: Scott Clasen
>
> I am the author of http://github.com/ticktock/qsandra, which is a cassandra 
> persistence adapter for activemq. I am willing to donate it if it is 
> something that is of interest to ActiveMQ..
> Only current trouble with that is it needs JDK 1.6, so it would probably need 
> to wait until (if and when) ActiveMQ 5.x is built with JDK 6.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQ-2828) Broker connection string does not allow both failover and compression

[Gary Tully (JIRA)]

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

Gary Tully commented on AMQ-2828:
-

what about: failover:(tcp://localhost:61616)?jms.useCompression=true ?

> Broker connection string does not allow both failover and compression
> -
>
> Key: AMQ-2828
> URL: https://issues.apache.org/activemq/browse/AMQ-2828
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: 5.3.0
> Environment: apache camel, grails 1.3.2 - server is spring 2.5.6. 
> activemq-all-5.3.0.jar activemq-pool5.3-SNAPSHOT.jar
>Reporter: john robens
>
> This works (spring resources.groovy in grails): 
> _jmsConnectionFactory(ActiveMQConnectionFactory) {
> brokerURL = tcp://localhost:61616?jms.useCompression=true
>   }
> So does this: 
> _jmsConnectionFactory(ActiveMQConnectionFactory) {
> brokerURL = failover:(tcp://localhost:61616)
>   }
> But this doesn't 
> _jmsConnectionFactory(ActiveMQConnectionFactory) {
> brokerURL = failover:(tcp://localhost:61616?jms.useCompression=true)
>   }
> Error message is: 
> 195562 [ActiveMQ Task] DEBUG 
> org.apache.activemq.transport.failover.FailoverTransport  - Connect fail to: 
> tcp://localhost:61616?jms.useCompression=true, reason: 
> java.lang.IllegalArgumentException: Invalid connect parameters: 
> {jms.useCompression=true}
> Had a look at the code and it does seem to say this by default.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQ-2828) Broker connection string does not allow both failover and compression

[john robens (JIRA)]

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

john robens commented on AMQ-2828:
--

Gary - yes tried that too.

> Broker connection string does not allow both failover and compression
> -
>
> Key: AMQ-2828
> URL: https://issues.apache.org/activemq/browse/AMQ-2828
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
>Affects Versions: 5.3.0
> Environment: apache camel, grails 1.3.2 - server is spring 2.5.6. 
> activemq-all-5.3.0.jar activemq-pool5.3-SNAPSHOT.jar
>Reporter: john robens
>
> This works (spring resources.groovy in grails): 
> _jmsConnectionFactory(ActiveMQConnectionFactory) {
> brokerURL = tcp://localhost:61616?jms.useCompression=true
>   }
> So does this: 
> _jmsConnectionFactory(ActiveMQConnectionFactory) {
> brokerURL = failover:(tcp://localhost:61616)
>   }
> But this doesn't 
> _jmsConnectionFactory(ActiveMQConnectionFactory) {
> brokerURL = failover:(tcp://localhost:61616?jms.useCompression=true)
>   }
> Error message is: 
> 195562 [ActiveMQ Task] DEBUG 
> org.apache.activemq.transport.failover.FailoverTransport  - Connect fail to: 
> tcp://localhost:61616?jms.useCompression=true, reason: 
> java.lang.IllegalArgumentException: Invalid connect parameters: 
> {jms.useCompression=true}
> Had a look at the code and it does seem to say this by default.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQ-2828) Broker connection string does not allow both failover and compression

[john robens (JIRA)]

Broker connection string does not allow both failover and compression
-

 Key: AMQ-2828
 URL: https://issues.apache.org/activemq/browse/AMQ-2828
 Project: ActiveMQ
  Issue Type: Bug
  Components: Connector
Affects Versions: 5.3.0
 Environment: apache camel, grails 1.3.2 - server is spring 2.5.6. 
activemq-all-5.3.0.jar activemq-pool5.3-SNAPSHOT.jar
Reporter: john robens


This works (spring resources.groovy in grails): 


_jmsConnectionFactory(ActiveMQConnectionFactory) {
brokerURL = tcp://localhost:61616?jms.useCompression=true
  }


So does this: 
_jmsConnectionFactory(ActiveMQConnectionFactory) {
brokerURL = failover:(tcp://localhost:61616)
  }


But this doesn't 
_jmsConnectionFactory(ActiveMQConnectionFactory) {
brokerURL = failover:(tcp://localhost:61616?jms.useCompression=true)
  }


Error message is: 
195562 [ActiveMQ Task] DEBUG 
org.apache.activemq.transport.failover.FailoverTransport  - Connect fail to: 
tcp://localhost:61616?jms.useCompression=true, reason: 
java.lang.IllegalArgumentException: Invalid connect parameters: 
{jms.useCompression=true}

Had a look at the code and it does seem to say this by default.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra

[Gary Tully (JIRA)]

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

Gary Tully commented on AMQ-2826:
-

Sure, it is of interest, what is the 1.6 dependency, any chance that it can be 
worked around?

> Look at the possibility of incorporating a cassandra persistence adapter from 
> http://github.com/ticktock/qsandra 
> -
>
> Key: AMQ-2826
> URL: https://issues.apache.org/activemq/browse/AMQ-2826
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Message Store
>Affects Versions: 5.3.2
>Reporter: Scott Clasen
>
> I am the author of http://github.com/ticktock/qsandra, which is a cassandra 
> persistence adapter for activemq. I am willing to donate it if it is 
> something that is of interest to ActiveMQ..
> Only current trouble with that is it needs JDK 1.6, so it would probably need 
> to wait until (if and when) ActiveMQ 5.x is built with JDK 6.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AMQ-2811) Network of Brokers: NIO-Transport: Members die after some hours

[Gary Tully (JIRA)]

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

Gary Tully resolved AMQ-2811.
-

 Assignee: Gary Tully
Fix Version/s: 5.4.0
   Resolution: Fixed

fix for NPE in r964367

> Network of Brokers: NIO-Transport: Members die after some hours
> ---
>
> Key: AMQ-2811
> URL: https://issues.apache.org/activemq/browse/AMQ-2811
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.3.1
> Environment: RedHat Linux, Java 1.6
>Reporter: Dirk Alexander Schäfer
>Assignee: Gary Tully
> Fix For: 5.4.0
>
>
> i have a network of brokers configured with four nodes where each node knows 
> the other three nodes through the networkConnector config. two of these four 
> nodes are currently down/unavailable. the other two nodes are working for 
> about four hours then they die. in the log file i see a lot of entries like 
> this one:
> 2010-07-05 00:53:01,741 | ERROR | Could not stop service: tcp://null:0. 
> Reason: java.lang.NullPointerException | 
> org.apache.activemq.transport.nio.NIOTransport | Simple Discovery Agent: 
> java.util.concurrent.threadpoolexecutor$wor...@f782b1
> java.lang.NullPointerException
> at 
> org.apache.activemq.transport.nio.NIOTransport.doStop(NIOTransport.java:152)
> at 
> org.apache.activemq.util.ServiceSupport.stop(ServiceSupport.java:69)
> at 
> org.apache.activemq.transport.tcp.TcpTransport.stop(TcpTransport.java:500)
> at 
> org.apache.activemq.transport.InactivityMonitor.stop(InactivityMonitor.java:121)
> at 
> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:64)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.stop(WireFormatNegotiator.java:91)
> at 
> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:64)
> at 
> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:64)
> at 
> org.apache.activemq.transport.ResponseCorrelator.stop(ResponseCorrelator.java:132)
> at 
> org.apache.activemq.util.ServiceSupport.dispose(ServiceSupport.java:43)
> at 
> org.apache.activemq.network.DiscoveryNetworkConnector.onServiceAdd(DiscoveryNetworkConnector.java:134)
> at 
> org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent$1.run(SimpleDiscoveryAgent.java:164)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQ-2827) Intermittent 204 response using REST

[Michael Lok (JIRA)]

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

Michael Lok updated AMQ-2827:
-

Attachment: restclient.java

> Intermittent 204 response using REST
> 
>
> Key: AMQ-2827
> URL: https://issues.apache.org/activemq/browse/AMQ-2827
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.4.0
> Environment: Linux
> JDK5
>Reporter: Michael Lok
> Attachments: restclient.java
>
>
> Was able to successfully send 20 messages to AMQ via REST.  I can see that 
> the messages were consumed and there are 20 messages in the response queue.  
> However, when reading the response queue using selector via REST, it 
> intermittently returns HTTP code 204.  By looking at the "Active Consumers" 
> for the response queue, I can see that the specific message has been 
> dispatched to the consumer as the "Enqueues", "Dequeues" and "Dispatched" 
> values are set to 1.
> The server has been configured with consumer.prefetchSize=1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Getting Slow Response

[sandip kanzariya]

I am implementing flickr api in  activemq with stomp client using php.I am
getting very slow response.Is there any configuration setting to make
faster?
Please suggest .
Thanks in Advance..

Sandip Kanzariya
-- 
View this message in context: 
http://old.nabble.com/Getting-Slow-Response-tp29170489p29170489.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] Created: (AMQ-2827) Intermittent 204 response using REST

[Michael Lok (JIRA)]

Intermittent 204 response using REST


 Key: AMQ-2827
 URL: https://issues.apache.org/activemq/browse/AMQ-2827
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.4.0
 Environment: Linux
JDK5
Reporter: Michael Lok


Was able to successfully send 20 messages to AMQ via REST.  I can see that the 
messages were consumed and there are 20 messages in the response queue.  
However, when reading the response queue using selector via REST, it 
intermittently returns HTTP code 204.  By looking at the "Active Consumers" for 
the response queue, I can see that the specific message has been dispatched to 
the consumer as the "Enqueues", "Dequeues" and "Dispatched" values are set to 1.

The server has been configured with consumer.prefetchSize=1.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.