Hi,
please find attached the thread dump.
Regards,
Anna
-Original Message-
From: Ganesh Murthy [mailto:gmur...@redhat.com]
Sent: Dienstag, 29. September 2015 16:52
To: users@activemq.apache.org
Subject: Re: Problem shutting down activemq client with failover transport
Can you please prov
Thanks. Tim. sorry to confuse you, I am doing C++ and the Java broker did
not exit when my c++ application exited. Yes, I am using one processor
with two threads involved. I appreciate your suggestions, now I understand
how that CountDownLatch works, that made me realize I modified the
HellowWorl
Maybe I'm not using the network of brokers in the correct manner. Should a
network of brokers be used for HA, or just scalability and load balancing?
We are not concerned with the loss of a few messages if one broker fails;
however, we want to make sure there is not a single point of failure in
Thanks Tim,
Subscribers only subscribe to queues. I restarted the server, but, that
didn't fix the problem either, haven't tried destroying all destinations
yet.
The problem occurred in production, we have to drain all the queues and
start with a new kahadb to solve the problem. I took backup of
I've seen this behaviour as well and did not find a way around it besides
limiting the number of _startup_ reconnect attempts.
Append something like "?startupMaxReconnectAttempts=5" to the Url.
On 29.09.2015 15:31, Anna Maier wrote:
Hi,
I am using Camel to connect to ActiveMQ and it fails to
Why would the txlog (transaction log) be constantly growing with no messages on
the queues? This is taking up all of our disk space, not the kahadb journal
files!
Are there any howl log settings we should be using aside from the defaults?
Regards,
Barry
-Original Message-
From: Chr
What if the problem isn't with messages being consumed at different times?
What if they all are being consumed right away but yet the journal files
continue to grow?
Regards,
Barry
-Original Message-
From: Christopher Shannon [mailto:christopher.l.shan...@gmail.com]
Sent: Tuesday, S
BrokerXmlConfig =
broker:(nio://0.0.0.0:61617?discoveryUri:multicast://224.6.1.6:61616,network:static:(tcp://localhost:61616)?useInactivityMonitor=false)/tomee0?persistent=false
ServerUrl = vm://tomee0
datasource =
In Apache TomEE,
There is no option to compact KahaDB. The current solution for the problem
of journal files not being cleaned up is to use multi kahadb. Gary has a
good post about it here
http://blog.garytully.com/2011/11/activemq-multiple-kahadb-instances.html
There's a couple open tickets to add compaction to
Can you please provide a thread dump? That would throw some light on exactly
what is going on.
Thanks.
- Original Message -
From: "Anna Maier"
To: users@activemq.apache.org
Sent: Tuesday, September 29, 2015 9:31:13 AM
Subject: Problem shutting down activemq client with failover transpor
But if the message and its ACK are in different files due to high volumes, and
cleanup is not occurring due to this, wouldn't you want to increase file size
from 32mb?
Regards,
Barry
-Original Message-
From: Clebert Suconic [mailto:clebert.suco...@gmail.com]
Sent: Tuesday, September
I did find something, but need some advice:
We are using ActiveMQ 5.11.1 in our environments.
The behaviour we noticed was that ActiveMQ wrote the messages to a new kahadb
file (journal log) after every 32 mb (default configuration). This lead to the
message and its corresponding ack ending up
Isn't there any option to compact the journals on activemq5?
In a journal sometimes you have the add-delete-add-add-delete somehow that
you can't can't really clean it unless you compact the whole thing. Most of
the times I had this issue was because I had a pending TX or something.
Also: is the
Hi,
I am using Camel to connect to ActiveMQ and it fails to shutdown when the
ActiveMQComponent cannot make a connection to the broker with the failover
protocol (activemq version 5.12.0).
The problem seems to be that the failover transport tries to connect to the
broker in an endless loop o
All Topic queue sizes in JConsole show 0, and dispatch counts show 0. Any
other suggestions?
Regards,
Barry
-Original Message-
From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain
Sent: Tuesday, September 29, 2015 1:14 AM
To: ActiveMQ Users
Subject: Re: Nothing on q
You're right, "cluster" isn't a term with an unambiguous definition. Your
restatement of my point removes the ambiguity without changing the point.
On Sep 29, 2015 6:42 AM, "Basmajian, Raffi"
wrote:
> Tim,
>
> To be clear, NoB and M/S are mutually exclusive within the same
> master/slave group,
Tim,
To be clear, NoB and M/S are mutually exclusive within the same master/slave
group, but the same does not hold true for "cluster" given its ambiguity.
Raffi
-Original Message-
From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain
Sent: Tuesday, September 29, 2015
17 matches
Mail list logo
