Java EventhubsProducer ServerBusyException handling

["Peleg, Roni" <Ro...@arris.com>]

Hi,

I'm using the next Java Producer for sending messages to an Azure Event Hub:
https://azure.microsoft.com/en-us/documentation/articles/event-hubs-java-ephcs-getstarted/

I'm using an Eventhub with 10 partitions and 10 Throughput Units.
The producer sends 6 Million small messages (<1KB).

I sometimes see errors on the Eventhubs Dashboard counters:

*         ServerBusyErrors together with num of messages smaller than the num of messages that I sent

*         ServerBusyErrors but with num of messages equal to the num of messages that I sent

*         Other types of errors.

The problem is that the Java Producer does not catch (or does not expose out) any exceptions when those errors occur (or probably I fail to understand how exactly should I catch those exceptions in code).

Could it be that maybe the producer get the ServerBusyErros, handles them by itself (re-send policy of some sort) and does not expose all that out to me? Because that may partly explain how come there are errors but all messages were received.

(Or, could it be that Eventhub itself successfully receives a message although it issues a ServerBusyError?)


By the way, how accurate and reliable ar those dashboard counters?


Thanks,
Roni

Re: Java EventhubsProducer ServerBusyException handling

[Robbie Gemmell <ro...@gmail.com>]

On 26 January 2016 at 07:24, Peleg, Roni <Ro...@arris.com> wrote:
> Hi,
>
> I'm using the next Java Producer for sending messages to an Azure Event Hub:
> https://azure.microsoft.com/en-us/documentation/articles/event-hubs-java-ephcs-getstarted/
>
> I'm using an Eventhub with 10 partitions and 10 Throughput Units.
> The producer sends 6 Million small messages (<1KB).
>
> I sometimes see errors on the Eventhubs Dashboard counters:
>
> *         ServerBusyErrors together with num of messages smaller than the num of messages that I sent
>
> *         ServerBusyErrors but with num of messages equal to the num of messages that I sent
>
> *         Other types of errors.
>
> The problem is that the Java Producer does not catch (or does not expose out) any exceptions when those errors occur (or probably I fail to understand how exactly should I catch those exceptions in code).
>
> Could it be that maybe the producer get the ServerBusyErros, handles them by itself (re-send policy of some sort) and does not expose all that out to me? Because that may partly explain how come there are errors but all messages were received.
>
> (Or, could it be that Eventhub itself successfully receives a message although it issues a ServerBusyError?)
>
>
> By the way, how accurate and reliable ar those dashboard counters?
>
>
> Thanks,
> Roni
>

Hi Roni,

>From your link it looks like you are using the older
'qpid-amqp-1-0-client-jms' AMQP 1.0 JMS client. It also seems the
configruation in the example is defined to force sending of messages
to be done asynchronously. From a quick peek at that clients source it
seems that in that scenario, any 'disposition' updates for the message
effectively get ignored, meaning that even if the server rejected
receipt of them there would be no way to tell that had occurred.

With the newer AMQP 1.0 JMS client ('qpid-jms-client', currently at
0.7.0 release) when a non-accepting disposition is returned for
delivery that was sent asynchronously, the client emits an exception
through the connection ExceptionListener. From a quick peek at its
source, it doesn't however look to make it possible to determine from
the exception which JMS Message object that related to.

As a result, in both cases you would currently need to utilise
synchronous sends (which is the default behaviour for persistent
messages, in both cases I believe) to ensure you received an exception
(from the send method) and be able to relate it to the particular JMS
Message being sent.

This behaviour is mostly due to JMS 1.1 not actually catering to
asynchronous sending at all (send is really meant to be synchronous,
but most providers allow using it async). That being one of the things
handled by new APIs in JMS 2.0. We do intend to make the newer client
implement JMS 2.0 eventually, but I don't yet know when that will be.
We could likely improve its current handling regardless though.

Neither client implements a re-send policy when a particular message
is rejected by a server, the application would have to handle that.

In terms of your questions about EventHub behaviour/dashboard, you'd
have to ask the Azure folks about that side of things as it isn't
something I'm familiar with.

Robbie

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org