Based on the doGetLastMessageStoreSequenceId() method in
https://fisheye.apache.org/browse/activemq-6/activemq-jdbc-store/src/main/java/org/apache/activemq/store/jdbc/adapter/DefaultJDBCAdapter.java?r=d54d046b8a8f2e9e5c0a28e1f8c7634b3c8b18e4&r=d54d046b8a8f2e9e5c0a28e1f8c7634b3c8b18e4&r=d54d046b8a8f
Could you post the full stack trace of each of the two categories of
threads you referenced?
If I understand your description, you have an intermittent network
connection, but the CPU utilization eventually grows to 100-150% *even
after* you re-establish a strong network connection over the mobile
I'm not an expert on the dispatch code, but this isn't the behavior I'd
expect to see, so please submit a bug in JIRA for it so we can get someone
who knows that code well can fix it (or explain why this is the intended
behavior, if that's the case).
Tim
On Tue, Apr 11, 2017 at 1:15 PM, Fabian Go
To the best of my knowledge, it's not possible in ActiveMQ to guarantee
that the broker will deliver all messages in a topic including the ones
before the first consumer joins the topic. Unlike some other message
brokers such as Kafka and Kinesis, ActiveMQ's design is to delete messages
once they
TCP connections are always bi-directional; even if you don't pass
application-layer content in one direction, you still have to send acks for
the messages containing content coming in the other direction.
There's another email thread (
http://activemq.2283324.n4.nabble.com/org-apache-activemq-brok
Hi everyone.
I want your help to understand what have happened on my ActiveMQ.
I use AcitveMQ ver 5.14.3.
I noticed that I had a lot of WARN logs on the ActiveMQ as follows.
2017-04-11 00:00:07,675 | WARN | Transport Connection to:
tcp://10.0.2.8:47505 failed: java.io.EO
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.14.5
has been released and includes 12 fixes and improvements.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12339772
The
Also, what does the stack trace for the EOFException say the broker was
doing when the EOFException occurred?
On Apr 17, 2017 7:01 AM, "Tim Bain" wrote:
> OK, for the EOFException, are your brokers behind a load balancer like
> this thread's OP was? It sounds like you're not, so what's on the ot
OK, for the EOFException, are your brokers behind a load balancer like this
thread's OP was? It sounds like you're not, so what's on the other end of
those connections? One possibility is real client processes, or another is
another broker in a network of brokers setup. In either case, are all
clie
