Sure I created this issue: https://issues.apache.org/jira/browse/AMQ-7090
Best regards,
Arjen
On 2-11-2018 13:32, Tim Bain wrote:
> This sounds like a bug. Can one of you please submit a bug in JIRA for it?
>
> Tim
>
> On Fri, Nov 2, 2018, 3:42 AM Arjen van der Meijden wrot
We have roughly the same issue, did you find a solution yet?
We use Stomp queue consumers with which we had a message that caused a
crash, the consumer restarted, crashed again, etc.
Obviously the crashing part is our responsibility, but we wanted to see
if we could prevent endless resends from Ac
It looks like the below configuration for Spring is actually working.
Is it indeed the expected way to do this properly?
Best regards,
Arjen
On 25-10-2018 19:46, Arjen van der Meijden wrote:
> Hi list,
>
> I know this question has occasionally been asked before, but I can't
&g
Hi list,
I know this question has occasionally been asked before, but I can't
seem to figure out the correct method with the most recent ActiveMQ.
Our application runs with an in-memory database which is kept in sync by
listening to about 30 different topics on ActiveMQ which are monitored
via Sp
html
Best regards,
Arjen
On 2-10-2016 13:37, Arjen van der Meijden wrote:
> Hi,
>
> We have a network of brokers using the multicast protocol. Some messages
> on that network disappear.
>
> Our application is a large php website, where we use Stomp+activemq to
> of
Hi,
We have a network of brokers using the multicast protocol. Some messages
on that network disappear.
Our application is a large php website, where we use Stomp+activemq to
offload some of the work to allow asynchronous processing. Among that
are notifications similar to Facebook's, but also ot
Afaik, in modern JVM versions, many of the 'old' recommendations may not
really apply anymore or even reduce performance. The book 'Java
Performance: The Definitive Guide' for instance has this statement on
heap sizing:
"1. The JVM will attempt to find a reasonable minimum and maximum heap
size ba
I think he was referring to your clients which could be adjusted to pool
a small amount of connections, rather than opening many.
You obviously can't control this from the server-side. Still its very
uncommon to really need 1000 connections at the same time, it generally
suggests your clients
By default, ActiveMQ closes connections asynchronously. That is normally
not a problem, unless you open and close many connections (in our case,
hundreds per minute).
In that case, the asynchronous closing may not be able to keep up with
your opening/closing-rate and you start accumulating file
Hello Muthana,
By switching to asynchronous connections, you don't solve the underlying
problem. You just stop waiting for the final delivery of the messages.
But they'll most likely still take 4 seconds to deliver.
You can't have both ways; asynchronous message delivery and a easy and
relia
Hi Muthana,
While connect, send, disconnect is not super efficient, I wouldn't look
into replacing that right now... You should first identify the problem,
rather than jumping to solutions that may not work at all.
The overhead of repeated connect/disconnect should not be ignored. But
they d
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
If you have short lived connections: Try adding
'?transport.closeAsync=false' to your connection construct, i.e.
something like this:
uri="stomp://0.0.0.0:61613?transport.closeAsync=false" />
We have many very short lived stomp producers and due to the
asynchronous disconnect code, it would ta
It is doing that. Normally a queue/topic-consumer is a long-running
client that will basically just do work whenever a message arrives. It
will normally not connect to see if there is a message and than
disconnect to repeat things later on.
If you have different requirements, that obviously ch
First off, I wouldn't call "< 10k/minute" low volume (unless its also <
1k orso), but that's a matter of opinion. I think my peak of about 10k
messages/minute constitutes of a "relatively high volume".
At least on the comment of not being able to run out of the box... it
did for me every time
BytesMessages and the client got
nothing. I changed it to send TextMessage and all was OK.
Could this be your problem?
On 25/08/2010 3:49 PM, Arjen van der Meijden wrote:
Noone? I've done some follow-up research, but still have no idea which
part of ActiveMQ fails. It turns out that the incoming
/AMQ-2871
Any ideas how to proceed from here?
Best regards,
Arjen
On 14-8-2010 20:05 Arjen van der Meijden wrote:
Hi List,
I have a fairly simple set-up with a single Activemq (currently 5.3.2,
but the behavior existed with previous versions).
On that AMQ we have a few queue's and topics, wh
Hi List,
I have a fairly simple set-up with a single Activemq (currently 5.3.2,
but the behavior existed with previous versions).
On that AMQ we have a few queue's and topics, where the topics are
filled using PHP producers with Stomp and four Java subscribers with the
normal openwire protoc
connection block
pending the broker start.
see: https://issues.apache.org/activemq/browse/AMQ-2385
On 2 July 2010 09:54, Arjen van der Meijden wrote:
Hi,
We have a simple single-server ActiveMQ-setup with multiple consumers, some
of which use Java and connect via JMS. As the ActiveMQ-server might
Hi,
We have a simple single-server ActiveMQ-setup with multiple consumers,
some of which use Java and connect via JMS. As the ActiveMQ-server might
some times need a restart or some other down time we configured it to
use the failover protocol (failover:tcp://localhost:61616), so it will
reco
).
HTH,
Roger
On Wed, Jan 20, 2010 at 1:08 PM, Arjen van der Meijden<
acmmail...@tweakers.net> wrote:
Hi List,
I just restarted a activemq 5.3-instance which was causing 1000% cpu (the
machine has 8 cores, so all where fully working) and a load of 1035.
I'm pretty confident th
Hi List,
I just restarted a activemq 5.3-instance which was causing 1000% cpu
(the machine has 8 cores, so all where fully working) and a load of 1035.
I'm pretty confident that this load/cpu-usage was caused by using
stomp+nio rather than 'stomp' (whether it was just nio or not, I don't
kno
wrote:
Hi Arjen,
did you try to enable failover transport mechanism :
http://activemq.apache.org/failover-transport-reference.html
This will enable the client to reconnect in case of disconnection. the
default transport url you use will NOT automatically reconnect.
Cheers,
Felix
Arjen van der
Noone with an idea? Do I need to supply more information and/or do more
testing?
Best regards,
Arjen
On 25-9-2009 9:09, Arjen van der Meijden wrote:
Hi List,
I have some topics with very few messages (it can be days or weeks
before a message arrives) on it. The consumers to those topics
Hi List,
I have some topics with very few messages (it can be days or weeks
before a message arrives) on it. The consumers to those topics
disconnect after some time and don't reconnect afterwards.
I have no idea where to put the blame (activemq-server,
activemq-consumer, spring?), but I'd lik
On 8-6-2009 16:25 Aleksandar Ivanisevic wrote:
Arjen van der Meijden
writes:
As soon as those second-queue-consumers exit however, they don't
consume much messages. Most of the time it seems that only one is
actually doing any work and the other three are idle, even if the
queue has more
essing, is actually "locking" the other messages.
Best regards,
Arjen
On 8-6-2009 15:40, Arjen van der Meijden wrote:
Hello list,
In a somewhat complicated set of consumption-processing, I have three
queues. One to indicate a new job, which is consumed by a single
long-running consumer
Hello list,
In a somewhat complicated set of consumption-processing, I have three
queues. One to indicate a new job, which is consumed by a single
long-running consumer that sends messages to a second queue.
That second queue is consumed by four consumers that kill themselves
after having proc
e Centos 5.3 .
What is the best linux distro to use with activemq?
Also, are there ports we should not use for transport?
Arjen van der Meijden wrote:
Well, that is really mostly the default config with some small
differences.
- I completely commented out the "destinationPolicy"-
We have four php-webservers together handling about three million
pageviews per day, and for each pageview a connection is made to
ActiveMQ (via Stomp) and at least one, often two and sometimes more
messages are sent via that connection.
The default settings of ActiveMQ don't really support th
queue sizes, is there a limit?
Are there best practices anywhere?
Arjen van der Meijden wrote:
There may be at one or more of these three issues that I ran into:
- You actually have a too low setting for the open files. Try increasing
it (see man ulimit etc, be careful that normally only roo
There may be at one or more of these three issues that I ran into:
- You actually have a too low setting for the open files. Try increasing
it (see man ulimit etc, be careful that normally only root can increase
it beyond 1024, but other programs, including su do inherit it).
- You're opening
Did you also remove the limits for queue sizes (most notably the one
that limits all queues to only 5MB)?
With the ulimit up to 10240, the async closing turned off and the limits
for the seperate queues removed (we just disabled the entire
'destinationPolicy'-element from the default config) a
Hi,
We were seeing that same issue with 5.0 as well. But with 5.1 it seems
to be gone.
Here is a graph of the JVM's garbage collection with 5.0, the line
represents the 'Used tenured + new' i.e. if the general trend is up, its
the Old Gen that increases:
http://achelois.tweakers.net/~acm/tn
On 3-4-2008 8:50, Joel Poloney wrote:
Is your "kill"-message on every call? Or is that only when you manually
interrupt it? I'm wondering if you changed the Stomp-implementation such
that if you've consumed all of the messages (and it's waiting for a new
message to come through), it automatically
On 3-4-2008 7:47, Joel Poloney wrote:
1. I have a consumer in a while(1) { //consume } fashion. That would
basically run forever. As I understand it, this is the way most web servers
work (at the core, core level). In this model, I would have to make sure
that the consumer was always running (per
I've memory leaks with 1.6.0.4 (64bit on debian linux and activemq
5.0/fuse 5.0.0.8). I'm not able to reproduce it on my testing platforms,
but I can supply a heap-dump of the activemq-instance that is actually
having a continuously growing heap.
Or am I just looking at a different kind of hea
Is there noone with an idea?
I've made a new graph with a longer timeperiod:
http://achelois.tweakers.net/~acm/tnet/long-activemq-gc.png
For now we can only fix this by periodically restart ActiveMQ, but
that's not a very nice aproach.
Best regards,
Arjen
Arjen van der Meijden
couldn't keep up when the heap grew over 700MB. AMQ is running
on a dual processor opteron with 8GB of memory and several 15k-rpm scsi
disks in a raid 5 for its storage.
I'm clueless as to what this increase in memory consumption may cause
and/or how to prevent it.
Any ideas
On 31-1-2008 14:04 Maarten Manders wrote:
I'm running a cluster of webservers and I'd like to write certain events
(logins, logouts, etc.) to a central log. To do that, I'd like the
webservers to send event messages to a broker. A logging machine should
periodically fetch, process, aggregate and
40 matches
Mail list logo
