Hello,
with the final release, using Stomp 1.0 and 1.0, the broker still sends
messages to the client after unsubscribing. Is this designed as
different from ActiveMQ?
The sequence is:
* connect, create durable subscription test, disconnect
* connect, send message to durable subscription
Thanks! So there is no way to have both long and short timeouts in one
connection?
I would like to keep the infinite failover, but then for certain API
calls, have it fail immediately if connection is lost.
On 2012-02-06 17:06, Timothy Bish wrote:
You need to use the Failover transport
Hello,
When the Stomp client opens a queue browser, the broker logs an
AssertionError:
send:
CONNECT
login:admin
passcode:password
accept-version:1.0,1.1
server:localhost
heart-beat:0,0
received:
CONNECTED
version:1.1
server:apache-apollo/1.0
session:mybroker-1238
heart-beat:100,1
security is configured on the broker so it is client agnostic.
see: http://activemq.apache.org/security.html
google really is your friend here :-)
On 7 February 2012 03:37, Gaya3 way2...@hotmail.com wrote:
Thanks gtully,
here the challenge is i'm using AMQ C APIs for sending and receiving
You can use some of the maven:release plugin, the process is documented at:
http://activemq.apache.org/release-guide.html
but you will need to find that arg that stops it creating a branch.
The simplest thing for you may just be find and replace:
something like:
find . -type f -name 'pom.xml'
I am using 2 ActiveMQ brokers 5.5.0 with failover on Windows. I have a C#
windows service which connects to the broker queue via NMS. Windows service
creates 100 threads and each thread has its own consumer. I use
AutoAcknowledge mode. I run 4 instances of the windows service on separate
machines.
Your best bet is to try and create a test case that can reproduce the
issue. The stack traces look fine, seems they are waiting on more
messages.
Make sure you are using the latest NMS ActiveMQ version to ensure you
have all the latest fixes.
On Tue, 2012-02-07 at 05:17 -0800, Ishitori wrote:
It is hard to reproduce this problem in a test case.
But I do use latest version of ActiveMQ.NMS. I am also think about upgrading
5.5.0 ActiveMQ to 5.6.0 to resolve the problem with Scheduler (I use it for
redelivery).
Can you recommend me anything to get closer to the root of the problem?
--
Title: Signature
Hi Brian-
This list is fine, as it sounds like an ActiveMQ-related issue.
There are some known issues with AMQ 5.4.2 that could lead to that
problem. Also, client-side issues such as exhausting connection
pools, or leaking connections could cause
Abimael-
A couple of things:
You don't use a networkConnector for master/slave. This is definitely
causing a problem. Network Connectors are to connect to *other*
master/slave pairs to provide scaling of traffic load. Remember:
Master/Slave *only* provides high availability for the
Sounds like a bug. Could you log an issue at:
https://issues.apache.org/jira/browse/APLO
On Tue, Feb 7, 2012 at 3:05 AM, Michael Justin michael.jus...@gmx.netwrote:
Hello,
with the final release, using Stomp 1.0 and 1.0, the broker still sends
messages to the client after unsubscribing. Is
Thanks for the bug report. Could you also open an issue at:
https://issues.apache.org/jira/browse/APLO
On Tue, Feb 7, 2012 at 4:20 AM, Michael Justin michael.jus...@gmx.netwrote:
Hello,
When the Stomp client opens a queue browser, the broker logs an
AssertionError:
send:
CONNECT
Hi there,
we are still testing AciveMQ in preproduction here. Imagine following
situation:
we have two topics here that work as a request/response pair. The data
producer is permanently(not durable) subscribed to the request topic and
puts its payload into the response topic. The client uses a
More details to the issue: This is how I configured the JmsTemplate:
public @Bean
JmsTemplate jmsTemplate() {
JmsTemplate template = new JmsTemplate();
template.setConnectionFactory(cachingConnectionFactory());
template.setDeliveryPersistent(false);
return
Spring Caching connection factory has been reported to have a number of
issues. I do not have a specific bug ticket or link, but I hear about
it quite a bit. I would suggest trying to just use ActiveMQ's
connection factory, instead of Spring's and see if that helps.
If that doesn't fix it,
15 matches
Mail list logo
