I have a question about what the expected behaviour of dropping a slow AMQP
consumer is/should be. I am using 5.11-SNAPSHOT. The behaviour I am
observing is as follows:
- I have an AMQP (proton-c) client that is consuming messages from ActiveMQ
from a specific queue via a specific AMQP link.
-
Hi Kevin,
Do you have any update on this issue?
It looks to me that this config is not really production ready.
What do you think?
Is someone of the development team having a look?
Chris
Il giorno gio 18 dic 2014 21:50 Kevin Burton bur...@spinn3r.com ha
scritto:
Are you using a non-zero wireFormat.maxInactivityDuration? This type of
situation is exactly what it's intended to detect.
On Dec 23, 2014 2:51 AM, Marcel Meulemans m.meulem...@tkhinnovations.com
wrote:
I have a question about what the expected behaviour of dropping a slow AMQP
consumer
Is there a bug report in Jira for it, and has someone been able to identify
a configuration and set of steps to reliably reproduce it? If not, the
odds are good that no one is actively investigating it, so doing those
things would be the first step towards getting the problem fixed.
On Dec 23,
Are you using a non-zero wireFormat.maxInactivityDuration? This type of
situation is exactly what it's intended to detect.
I don't think the AMQP protocol converter implements an
InactivityMonitor a.t.m. and I won't help I think. The problem is not
that there is no communication between the
Hi,
I'm having trouble getting activemq to start at all,
Error message is:
Error: Could not find or load main class Files
Note that I both my PATH and CLASSPATH variables are pointing to the
requisite jars.
So what else am I missing?
Thanks,
Tara
--
View this message in context:
the jira is the folowing
https://issues.apache.org/jira/browse/AMQ-5300
It was opened on july.
I can reproduce it always, with the configuration in my first mail.
Christian
On Tue, Dec 23, 2014 at 3:54 PM, Tim Bain tb...@alumni.duke.edu wrote:
Is there a bug report in Jira for it, and has
I'd have thought that if the broker no longer considered the consumer to be
active, it would have stopped sending keep-alive packets, which would then
cause the consumer to abort, but I haven't looked at that code in any depth.
Have you tried setting abortConnection=true on the
Are you running Windows with a space in one of your directory names? The
first two search results I got when I Googled for your error message relate
to problems starting from a path with a space.
On Tue, Dec 23, 2014 at 8:28 AM, tlwtheq t...@shadowfirehosting.com wrote:
Hi,
I'm having trouble
I was going to tell you that since you have a configuration that reliably
reproduces the problem, and it's not described in that JIRA (which
describes symptoms but no means of reproducing the problem), you should
update it to provide the configuration so that someone can investigate.
But looking
BTW, you never did answer the question about which GC strategy you're
using, and it occurred to me that if you're using CMS, lots of full GCs
that don't actually reclaim much memory after a long time being up is the
classic failure scenario for CMS. It happens when Old Gen gets fragmented,
which
Ref http://activemq.apache.org/replicated-leveldb-store.html
Is this page actually detailing that Zookeeper will maintain one master
BROKER and that writes through this broker will be replicated to slave
brokers?
I read - interpreted - the URL and title as being about leveldb data being
Yes, I am running with path name
C:\Program Files (x86)\apache-activemq-5.10.0\bin\activemq .
How else would I execute? I know Windows used to have nicknames for such
directories
as Program Files (x86) but it doesn't seem to have that now. (Or does
it? Pardon me,
I'm not a really bid
As I understand it, extended Windows paths always have an eight-character
short version formed by the first N characters (usually 6) plus ~ and one
or more digits. Usually Program Files was PROGRA~1 (you can confirm
that by doing dir C:\PROGRA~1 and seeing if it matches; if not, try
PROGRA~2,
So I recently updated to jre7 and have noticed a strange problem between jre7
and the microsoft_jdbc_driver_4_0_for_sql_server driver. Looks like a known
issue, resulting in the recommendation to update to
microsoft_jdbc_driver_4_1_for_sql_server. However, it would appear that 5.10
does not
I’m still working on it and trying to figure it out.. it might take me some
time to reproduce it as it seems to have a few issues that might be
compounding the issue.
Bumping up memory definitely seemed to help resolve the issue.
I think what would be ideal is for me to write a producer/consumer
that bug is very specifically about deleting the
index files for LevelDB and then restarting the broker, whereas you haven't
described doing either of those things.
Yes.. I agree as well. That’s why I didn’t follow up on that thread. I’m
concerned about the error message though.
On Tue, Dec
The default GC which I think is still parallel. But I should explicitly
set it. I’m working on getting JMX monitors up so that I can track
ActiveMQ counters but also GC state.
I can’t get a reliable and short term failure to occur so right now I’ve
focused on mitigating the issue and easily
Based on what Christian has said, it sounds like he's got a configuration
that reliably reproduces his problem whereas you're not at that point yet,
so let's have him create a JIRA bug for that so we don't lose the details
about how to produce it. As you investigate, hopefully you'll be able
19 matches
Mail list logo
