Thanks Neha,

On Sat, Aug 24, 2013 at 10:06 AM, Neha Narkhede <[EMAIL PROTECTED]>wrote:

Ok, but perhaps the producer will handle something like this in the future?
So, it seems there might be a bit of a gray area.  There is a configurable
retry count, which we can increase perhaps to gain confidence that anything
recoverable has been sent.  But, since this retry count is finite, there's
no way to know for sure that it won't succeed if it were retried just one
more time.  So, it is then difficult to conclude that  if Producer.send
throws a FailedToSendMessageException, the message shouldn't be retried.

Perhaps it would be useful to define different exception types, so that a
caller can have clearer semantics:

UnretryableFailedToSendMessageException (wraps the root cause)
NoMoreRetriesFailedToSendMessageException (wraps the root cause, from the
final attempt)

Probably shorter names are possible here!  Perhaps these could be
subclasses of FailedToSendMessageException.  Alternately,
FailedToSendMessageException could include information, such as the number
of retries attempted, and a flag indicating whether it's possible to retry
the message.


NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB