[
https://issues.apache.org/jira/browse/KAFKA-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13868144#comment-13868144
]
Jason Rosenberg commented on KAFKA-1025:
----------------------------------------
[~joestein], I'm not sure I understand your reasoning......and please
understand that my primary issue in the ticket, is to provide visibility when
we see a MessageSizeTooLargeException. Adding better documentation is nice
(and great actually!), but does not address my issue raised in this ticket.
Regarding KAFKA-998, I think all that does is not repeatedly retry (e.g. 3
times) if the broker responds with a MessageSizeTooLargeException. So, I don't
think that's an api breaking change to merge the patch there (not sure what
[~junrao]'s concerns are there?).
But certainly, currently, you cannot have any logic in the api that looks for
the MessageSizeTooLargeException, so adding that visibility would not break any
existing client code. You'd still throw a FailedToSendException as before, I'm
just asking for extra info in the exception.
I literally have TODO's in my code to the likes of "Once KAFKA-1025 is solved,
remove this bogus guess-work logic to handle the possibility of a
MessageSizeTooLargeException....
> Producer.send should provide recoverability info on failiure
> ------------------------------------------------------------
>
> Key: KAFKA-1025
> URL: https://issues.apache.org/jira/browse/KAFKA-1025
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Jason Rosenberg
> Labels: newbie
> Attachments: KAFKA-1025.patch
>
>
> Currently, in 0.8, the Producer.send() method either succeeds, or fails by
> throwing an Exception.
> There are several exceptions that can be thrown, including:
> FailedToSendException
> QueueFullException
> ClassCastExeption
> These are all sub-classes of RuntimeException.
> Under the covers, the producer will retry sending messages up to a maximum
> number of times (according to the message.send.max.retries property).
> Internally, the producer may decide which sorts of failures are recoverable,
> and will retry those. Alternatively (via an upcoming change, see KAFKA-998),
> it may decide to not retry at all, if the error is not recoverable.
> The problem is, if FailedToSendException is returned, the caller to
> Producer.send doesn't have a way to decide if a send failed due to an
> unrecoverable error, or failed after exhausting a maximum number of retries.
> A caller may want to decide to retry more times, perhaps after waiting a
> while. But it should know first whether it's even likely that the failure is
> retryable.
> An example of this might be a if the message size is too large (represented
> internally as a MessageSizeTooLargeException). In this case, it is not
> recoverable, but it is still wrapped as a FailedToSendException, and should
> not be retried.
> So the suggestion is to make clear in the api javadoc (or scaladoc) for
> Producer.send, the set of exception types that can be thrown (so that we
> don't have to search through source code to find them). And add exception
> types, or perhaps fields within FailedToSendException, so that it's possible
> to reason about whether retrying might make sense.
> Currently, in addition, I've found that Producer.send can throw a
> QueueFullException in async mode (this should be a retryable exception, after
> time has elapsed, etc.), and also a ClassCastException, if there's a
> misconfiguration between the configured Encoder and the message data type. I
> suspect there are other RuntimeExceptions that can also be thrown (e.g.
> NullPointerException if the message/topic are null).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
