Is this a realistic expectation of a distributed mechanism?

Question

I've been evaluating ActiveMQ as a candidate message broker. I've written some test code to try and get an understanding of ActiveMQ's performance limitations.

I can produce a failure state in the broker by sending messages as fast as possible like this:

try {
    while(true) {
        byte[] payload = new byte[(int) (Math.random() * 16384)];
        BytesMessage message = session.createBytesMessage();
        message.writeBytes(payload);
        producer.send(message);
} catch (JMSException ex) { ... }

I was surprised that the line

producer.send(message);

blocks when the broker enters a failed state. I was hoping that some exception would be thrown, so there would be some indication that the broker has failed.

I realize that my test code is spamming the broker, and I expect the broker to fail. However, I would prefer that the broker failed "loudly" as opposed to simply blocking.

Is this an unrealistic expectation?

Update:

Uri's answer references an ActiveMQ bug report that was filed in March. The bug description includes a proposal that sounds like what I'm looking for: "if the request on the transport had a timeout (this is to catch failure scenarios, so something that's not expected to reasonably happen), things would have errored out rather than building waiting threads."

However, after 8 months the bug is currently unassigned with a single vote. So I guess the question still stands, is this something ActiveMQ should (will?) implement?

Answer 1

Not sure about ActiveMQ config, but other JMS providers have various configuration options - so you maybe able to get ActiveMQ to do as you wish in that situation.

I know Fiorano has options to specify whether providers block or not in this situation.

Answer 2

You are testing the 'slow consumer' and producer flowcontrol issue all message brokers have to deal with. Do you wanna fail producers, block them or spool to disk?

Basically the out of the box default in ActiveMQ is to block producers. But you can configure message cursors to spool to disk.

BTW you've not said if you are using queues/topics or persistent/non-persistent; if you are using non persistent topics there are other strategies you can use for discarding messages etc.

Answer 3

Apprently there's a known issue, not sure if it's been fixed:

https://issues.apache.org/activemq/browse/AMQ-1625