AMQ Stops dispatching messages after a period of time without errors/warnings

• Key: AMQ-1028
• Type: Bug
• Status: Closed
• Resolution: Incomplete
• Priority: Critical
• Assignee: Unassigned
• Reporter: Bas van Beek
• Affects Version/s: 4.0.2
• Fix Version/s: 4.0.2

Description

The ActiveMQ stand alone server seems to stop dispatching messages to topics after a period of time.

New clients can connect... new subscriptions to topics can be made... no errors are shown... messages are just not sent... including to and from the new clients...

No errors or warnings can be found in the ActiveMQ.log (even in debug mode)

JConsole doesn't show the new messages coming in (EnqueueCount doesn't change)

Stomp Protocol is used exclusively

Comments

[Adrian Co]

Could you provide more details of the setup?

Are you using a cluster of brokers or a standalone broker?

Are you using the default persistence adapter?

Are you sending persistent messages or non-persistent messages?

Do you have durable subscribers or non-durable subscribers?

Are your subscribers connected all the time and is consuming messages every time?

If you can provide a small test case to replicate this issue, it will make it easier to fix.

[Bas van Beek]

major oops...

I set "ack:client " in the stomp subscription header and acknowlegded incorrect message id's...

Reason I didn't see anything in the logs was because of a filesystem error... after a reboot and filesystem fix
the log informed me of used memory getting full...

I do think it's a problem that a consumer behaving badly can bring the entire messaging system down...

[James Strachan]

A badly behaved consumer can't bring the entire messaging system down. Dealing with slow consumers on non-persistent messaging is a common problem though - either increase the RAM, enforce persistence or use slow consumer handling...

http://incubator.apache.org/activemq/slow-consumer-handling.html

[Bas van Beek]

Well at the moment it does bring the system "down" in a way...

one consumer subscribed (with ack:client) on topic FOO behaves badly by not correctly consuming it's messages (not acknowledging them).

Effect... the messaging system's RAM usage is increasing until it's depleted of available space and all subscribers (also the ones on topic BAR) stop
receiving messages.

Now imagine the badly behaving consumer being killed without closing the TCP transport like it should and the effect is the system is still not processing
messages until that subscription times out (I'm not sure if it even does this... I have the distinct feeling I saw lingering subscriptions even when the connection was
closed correctly... but I'll check that next week when back at the office again...

in my opinion it should never be possible to let a consumer lock up the system like this...