You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by Michael Eugene <fa...@hotmail.com> on 2018/06/16 20:52:55 UTC
Retries
Hi I am trying to understand when to retry sending messages to topics and when to start trying to send to "retry" topics. The scenario is basically
1. A KafkaStreams application is consuming from a topic and sending to a topic. The "retries" is set at the default of 10.
2a. After 10 retries, does it make sense to then try to publish to another "retry topic"?
2a1. What mechanism is there to know its the 10th retry, and to then start sending to a "retry topic" after the 10th?
2b. Or after 10 retries - for that message if its not successful its just done. Since there is no real difference between sending to a "retry topic" and sending to a non-retry topic, why not just set retries to a high level (like 100).
3. On an implementation level (Ive read the kafka docs, i find it a bit high level) can someone throw a nugget out there about how exactly-once semantics would erase the need for an "retry topic"?
If u have time to answer any part of the above question, thank you in advance.
Get Outlook for Android<https://aka.ms/ghei36>
Re: Retries
Posted by Michael Eugene <fa...@hotmail.com>.
Well it does matter just because the variable wasn’t even in the 1.1 build, because as you probably know there was already a Jira opened that the variable was set as private and thus couldn’t be used. It was fixed but if you want to keep your build aligned with official releases then you can’t use the variable until the next one.
Well as far as the string being used, there must be something else going I guess because I am doing that already. I already have gone through it enough that it doesn’t really make sense to me why though. I have peeled my application so there isn’t that many moving pieces anymore so I’m not really sure. If you could just post a sample piece of code of when you got it to work that would be amazing. I know that’s asking a lot but I think it just doesn’t make sense at this point.
Sent from my iPhone
> On Jun 25, 2018, at 11:22 AM, Matthias J. Sax <ma...@confluent.io> wrote:
>
> `default.production.exception.handler` is the correct parameter.
>
> It should not make any difference if you pass in a plain String or
> `StreamConfig#DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG` -- the
> variable is also just a String...
>
> When you start the application, it should the config in the logs. Can
> you double check if it did pick up the handler there?
>
> -Matthias
>
>> On 6/24/18 6:42 PM, Michael Eugene wrote:
>> The thing about that is, when I try to register the handler, it doesn’t work. It’s easy to register the deserialization handler because there is a static final constant variable I can pass. But when I pass the string "default.production.exception.handler” it doesn’t work. (That actually might not be the exact string but I did get the string from the source code on GitHub.) Has anyone actually used this?
>>
>> Sent from my iPhone
>>
>>> On Jun 24, 2018, at 8:03 PM, Matthias J. Sax <ma...@confluent.io> wrote:
>>>
>>> Michael,
>>>
>>> It depends on the semantics you want to get. About retries in general,
>>> as long as a producer retries internally, you would not even notice.
>>> Only after retries are exhausted, an exception is thrown.
>>>
>>> Kafka Streams allows you to implement a handler for this (cf
>>> https://kafka.apache.org/11/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler)
>>> that allows you to react to the error as you wish.
>>>
>>> You can either use a provided handler or implement a custom one. You can
>>> either skip over a record or let Kafka Streams stop processing.
>>>
>>> It might make sense to write the record to a "retry topic", but it
>>> depends on the error. If the whole cluster is down, of course you cannot
>>> write to the retry topic either. If the output topic is currently
>>> under-repliated and does not allow for new write, the "retry topic"
>>> might be available thought.
>>>
>>>
>>> For exactly-once, producer retries are set to MAX_VALUE and thus the
>>> application would re-try practically forever.
>>>
>>>
>>> -Matthias
>>>
>>>> On 6/16/18 1:52 PM, Michael Eugene wrote:
>>>> Hi I am trying to understand when to retry sending messages to topics and when to start trying to send to "retry" topics. The scenario is basically
>>>>
>>>> 1. A KafkaStreams application is consuming from a topic and sending to a topic. The "retries" is set at the default of 10.
>>>>
>>>> 2a. After 10 retries, does it make sense to then try to publish to another "retry topic"?
>>>> 2a1. What mechanism is there to know its the 10th retry, and to then start sending to a "retry topic" after the 10th?
>>>>
>>>> 2b. Or after 10 retries - for that message if its not successful its just done. Since there is no real difference between sending to a "retry topic" and sending to a non-retry topic, why not just set retries to a high level (like 100).
>>>>
>>>> 3. On an implementation level (Ive read the kafka docs, i find it a bit high level) can someone throw a nugget out there about how exactly-once semantics would erase the need for an "retry topic"?
>>>>
>>>> If u have time to answer any part of the above question, thank you in advance.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Get Outlook for Android<https://aka.ms/ghei36>
>>>>
>>>>
>>>
>
Re: Retries
Posted by "Matthias J. Sax" <ma...@confluent.io>.
`default.production.exception.handler` is the correct parameter.
It should not make any difference if you pass in a plain String or
`StreamConfig#DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG` -- the
variable is also just a String...
When you start the application, it should the config in the logs. Can
you double check if it did pick up the handler there?
-Matthias
On 6/24/18 6:42 PM, Michael Eugene wrote:
> The thing about that is, when I try to register the handler, it doesn’t work. It’s easy to register the deserialization handler because there is a static final constant variable I can pass. But when I pass the string "default.production.exception.handler” it doesn’t work. (That actually might not be the exact string but I did get the string from the source code on GitHub.) Has anyone actually used this?
>
> Sent from my iPhone
>
>> On Jun 24, 2018, at 8:03 PM, Matthias J. Sax <ma...@confluent.io> wrote:
>>
>> Michael,
>>
>> It depends on the semantics you want to get. About retries in general,
>> as long as a producer retries internally, you would not even notice.
>> Only after retries are exhausted, an exception is thrown.
>>
>> Kafka Streams allows you to implement a handler for this (cf
>> https://kafka.apache.org/11/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler)
>> that allows you to react to the error as you wish.
>>
>> You can either use a provided handler or implement a custom one. You can
>> either skip over a record or let Kafka Streams stop processing.
>>
>> It might make sense to write the record to a "retry topic", but it
>> depends on the error. If the whole cluster is down, of course you cannot
>> write to the retry topic either. If the output topic is currently
>> under-repliated and does not allow for new write, the "retry topic"
>> might be available thought.
>>
>>
>> For exactly-once, producer retries are set to MAX_VALUE and thus the
>> application would re-try practically forever.
>>
>>
>> -Matthias
>>
>>> On 6/16/18 1:52 PM, Michael Eugene wrote:
>>> Hi I am trying to understand when to retry sending messages to topics and when to start trying to send to "retry" topics. The scenario is basically
>>>
>>> 1. A KafkaStreams application is consuming from a topic and sending to a topic. The "retries" is set at the default of 10.
>>>
>>> 2a. After 10 retries, does it make sense to then try to publish to another "retry topic"?
>>> 2a1. What mechanism is there to know its the 10th retry, and to then start sending to a "retry topic" after the 10th?
>>>
>>> 2b. Or after 10 retries - for that message if its not successful its just done. Since there is no real difference between sending to a "retry topic" and sending to a non-retry topic, why not just set retries to a high level (like 100).
>>>
>>> 3. On an implementation level (Ive read the kafka docs, i find it a bit high level) can someone throw a nugget out there about how exactly-once semantics would erase the need for an "retry topic"?
>>>
>>> If u have time to answer any part of the above question, thank you in advance.
>>>
>>>
>>>
>>>
>>>
>>> Get Outlook for Android<https://aka.ms/ghei36>
>>>
>>>
>>
Re: Retries
Posted by Michael Eugene <fa...@hotmail.com>.
The thing about that is, when I try to register the handler, it doesn’t work. It’s easy to register the deserialization handler because there is a static final constant variable I can pass. But when I pass the string "default.production.exception.handler” it doesn’t work. (That actually might not be the exact string but I did get the string from the source code on GitHub.) Has anyone actually used this?
Sent from my iPhone
> On Jun 24, 2018, at 8:03 PM, Matthias J. Sax <ma...@confluent.io> wrote:
>
> Michael,
>
> It depends on the semantics you want to get. About retries in general,
> as long as a producer retries internally, you would not even notice.
> Only after retries are exhausted, an exception is thrown.
>
> Kafka Streams allows you to implement a handler for this (cf
> https://kafka.apache.org/11/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler)
> that allows you to react to the error as you wish.
>
> You can either use a provided handler or implement a custom one. You can
> either skip over a record or let Kafka Streams stop processing.
>
> It might make sense to write the record to a "retry topic", but it
> depends on the error. If the whole cluster is down, of course you cannot
> write to the retry topic either. If the output topic is currently
> under-repliated and does not allow for new write, the "retry topic"
> might be available thought.
>
>
> For exactly-once, producer retries are set to MAX_VALUE and thus the
> application would re-try practically forever.
>
>
> -Matthias
>
>> On 6/16/18 1:52 PM, Michael Eugene wrote:
>> Hi I am trying to understand when to retry sending messages to topics and when to start trying to send to "retry" topics. The scenario is basically
>>
>> 1. A KafkaStreams application is consuming from a topic and sending to a topic. The "retries" is set at the default of 10.
>>
>> 2a. After 10 retries, does it make sense to then try to publish to another "retry topic"?
>> 2a1. What mechanism is there to know its the 10th retry, and to then start sending to a "retry topic" after the 10th?
>>
>> 2b. Or after 10 retries - for that message if its not successful its just done. Since there is no real difference between sending to a "retry topic" and sending to a non-retry topic, why not just set retries to a high level (like 100).
>>
>> 3. On an implementation level (Ive read the kafka docs, i find it a bit high level) can someone throw a nugget out there about how exactly-once semantics would erase the need for an "retry topic"?
>>
>> If u have time to answer any part of the above question, thank you in advance.
>>
>>
>>
>>
>>
>> Get Outlook for Android<https://aka.ms/ghei36>
>>
>>
>
Re: Retries
Posted by "Matthias J. Sax" <ma...@confluent.io>.
Michael,
It depends on the semantics you want to get. About retries in general,
as long as a producer retries internally, you would not even notice.
Only after retries are exhausted, an exception is thrown.
Kafka Streams allows you to implement a handler for this (cf
https://kafka.apache.org/11/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler)
that allows you to react to the error as you wish.
You can either use a provided handler or implement a custom one. You can
either skip over a record or let Kafka Streams stop processing.
It might make sense to write the record to a "retry topic", but it
depends on the error. If the whole cluster is down, of course you cannot
write to the retry topic either. If the output topic is currently
under-repliated and does not allow for new write, the "retry topic"
might be available thought.
For exactly-once, producer retries are set to MAX_VALUE and thus the
application would re-try practically forever.
-Matthias
On 6/16/18 1:52 PM, Michael Eugene wrote:
> Hi I am trying to understand when to retry sending messages to topics and when to start trying to send to "retry" topics. The scenario is basically
>
> 1. A KafkaStreams application is consuming from a topic and sending to a topic. The "retries" is set at the default of 10.
>
> 2a. After 10 retries, does it make sense to then try to publish to another "retry topic"?
> 2a1. What mechanism is there to know its the 10th retry, and to then start sending to a "retry topic" after the 10th?
>
> 2b. Or after 10 retries - for that message if its not successful its just done. Since there is no real difference between sending to a "retry topic" and sending to a non-retry topic, why not just set retries to a high level (like 100).
>
> 3. On an implementation level (Ive read the kafka docs, i find it a bit high level) can someone throw a nugget out there about how exactly-once semantics would erase the need for an "retry topic"?
>
> If u have time to answer any part of the above question, thank you in advance.
>
>
>
>
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
>