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
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
> se
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
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
> offload some
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
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
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
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
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)
If you have short lived connections: Try adding
'?transport.closeAsync=false' to your connection construct, i.e.
something like this:
transportConnector name=stomp
uri=stomp://0.0.0.0:61613?transport.closeAsync=false /
We have many very short lived stomp producers and due to the
asynchronous
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
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 and
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 stomp
,
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, where the topics are
filled using PHP producers with Stomp and four
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
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
Thanks, that seems to work.
Best regards,
Arjen
On 2-7-2010 11:06 Gary Tully wrote:
There is a *startupMaxReconnectAttempts *option on the failover transport
that allow the transport to fail early on the first connect attempt so that
spring gets a chance to do retries rather than have the
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
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 Meijden wrote:
Noone with an idea? Do I need to supply more
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
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
, 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 that sends messages
On 8-6-2009 16:25 Aleksandar Ivanisevic wrote:
Arjen van der Meijden
acmmail...@tweakers.net 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
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-tag. This also
disables the per-queue/topic size limits.
- I
?
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 root can increase
it beyond 1024, but other
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)
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:
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
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
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
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 wrote:
Hi
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?
Best regards,
Arjen van der Meijden
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
37 matches
Mail list logo
