OK, I've found out what's causing this and would greatly appreciate some
advice for moving forward. I'm not even sure that this is an AMQ issue
anymore...
The internal framework I depend on uses spring-integration-jms to wrap the
JMS message. The code in question looks like this:
the problem here is that the network bridge 'proxy' consumer is faster
than the local consumers.
you can use decreaseNetworkConsumerPriority=true to slow down the
network bridge but even this will not give you the desired effect with
prefetch=1, but it will help.
The other alternative is to build
Gary Tully uttered:
You would need to write some code, but the locker implementation can
be easily overridden.
The interface is: org.apache.activemq.store.jdbc.DatabaseLocker
It acquires the lock in start which typically blocks till it can get a
lock and there are periodic calls to keepalive onc
Sorry, my bad. You are correct. It is just the server side 'socket'
close that is async, not the tear down of broker state relating to a
connection, so there is no client impact.
asyncSync close really just means that there is a thread pool handling
close rather than the transport thread, so the t
Are you sure the client even notices this?
From our experience, I'm fairly certain that only the server side of
the connections where still open when we ran into this IOException.
I.e. isn't the correctly and completely closed (in Stomp-communication
terms from the client perspective) connect
Hello,
We are using a network of brokers but it's giving us some problems with load
balancing. Most of the messages are being delivered to the remote broker
instead of being shared between the network connector and the broker's
consumer. If a broker has 5 consumers and 1 network connector, and rec
You would need to write some code, but the locker implementation can
be easily overridden.
The interface is: org.apache.activemq.store.jdbc.DatabaseLocker
It acquires the lock in start which typically blocks till it can get a
lock and there are periodic calls to keepalive once the lock is
obtained
Hi,
We are running activemq 5.5.1 in an active/passive failover configuration with
JDBC Persistence to an Oracle backend. The default strategy for determining
whether the current master has failed is for the secondary server to attempt to
get a lock on the database table, waiting indefinitely
Hello,
I'm trying to use MQTT protocol between ActiveMQ broker and JMS client.
Broker is started with MQTT transport:
One queue and one topic are configured.
1. For testing I use HermesJMS tool. I've configured the tool with
MQTT jars (from /apache-activemq-5.6.0/lib/optional folder) and
brocke
yes, closeAsync=false can help reduce the number of open sockets if
the broker is busy at the cost of delaying the close response to the
client, but you need to really ask your computer that question; in
other words, do an empirical test.
On 23 May 2012 21:57, johneboyer wrote:
> Thank you Gary v
Apache *HTTPD *- the webserver - is an Apache Software Foundation (ASF)
project: http://httpd.apache.org/
Various support fora/mail lists are here: http://httpd.apache.org/lists.html
Is that what you are looking for? If not, read on...
Apache *ActiveMQ* - User discussion is right here on nabble.c
Great.
Look forward to trying it out. What I was trying to say was I like the
Atlassian approach to jira (we pay for licenses, whereas FOSS projects may
get a free license), and would be /more happy/ with an instance of a
facility such as yours being in the hands of the opensource projects, a la
j
12 matches
Mail list logo
