Makes sense, thanks!
On Tue, Aug 27, 2019 at 10:38 AM Jason Gustafson wrote:
> Hi Guozhang,
>
> 1. I think there are still some retriable errors that could affect the
> transaction APIs. For example, COORDINATOR_LOAD_IN_PROGRESS.
> 2. Yes, this is right. The only fatal error is when the
Hi Guozhang,
1. I think there are still some retriable errors that could affect the
transaction APIs. For example, COORDINATOR_LOAD_IN_PROGRESS.
2. Yes, this is right. The only fatal error is when the producer has been
fenced by another instance.
Thanks,
Jason
On Mon, Aug 26, 2019 at 6:05 PM
Hi Jason,
I've made another pass on the wiki page and it reads much better now. One
more clarification about the "Simplified error handling" section:
1. There will be no "retriable error" from the broker side regarding any
send requests and txn requests (to txn coordinators). All errors would
Thanks Jason!
LGTM.
On 8/21/19 3:07 PM, Jason Gustafson wrote:
> Hi Matthias,
>
> Thanks, I appreciate the thorough review. I've revised the section to make
> the logic clearer. I think you have it right except for the 1). We only
> generate a new PID if the epoch cannot be incremented without
Hi Matthias,
Thanks, I appreciate the thorough review. I've revised the section to make
the logic clearer. I think you have it right except for the 1). We only
generate a new PID if the epoch cannot be incremented without overflow.
-Jason
On Tue, Aug 20, 2019 at 5:45 PM Matthias J. Sax
wrote:
Thanks for the KIP. I just have some clarification questions to make
sure I understand the proposal correctly:
1) "Safe Epoch Incrementing"
> When the coordinator receives a new InitProducerId request, we will use the
> following logic to update the epoch:
>
> 1. No epoch is provided: the
@Adam:
As workaround, you can increase the repartition topic config
`segment.bytes` and set a larger segment size. This should mitigate the
issue.
-Matthias
On 4/4/19 3:47 PM, Jason Gustafson wrote:
> Hi Everyone,
>
> Sorry for the long delay on this KIP. I have updated it to include the
>
Hi Everyone,
Sorry for the long delay on this KIP. I have updated it to include the
handling of INVALID_PRODUCER_ID_MAPPING as suggested above. If there are no
further comments, I will plan to start a vote early next week.
Thanks!
Jason
On Mon, Mar 25, 2019 at 2:33 PM Adam Bellemare
wrote:
>
Ach - Sorry. I meant Jason. I had just read a John Roesler email.
On Mon, Mar 25, 2019 at 5:21 PM Adam Bellemare
wrote:
> Hi John
>
> What is the status of this KIP?
>
> My teammates and I are running into the "UNKNOWN_PRODUCER_ID" error on
> 2.1.1 for a multitude of our internal topics, and I
Hi John
What is the status of this KIP?
My teammates and I are running into the "UNKNOWN_PRODUCER_ID" error on
2.1.1 for a multitude of our internal topics, and I suspect that a proper
fix is needed.
Adam
On Mon, Jan 7, 2019 at 7:42 PM Guozhang Wang wrote:
> Thanks Jason. The proposed
Thanks Jason. The proposed solution sounds good to me.
Guozhang
On Mon, Jan 7, 2019 at 3:52 PM Jason Gustafson wrote:
> Hey Guozhang,
>
> Thanks for sharing the article. The INVALID_PRODUCER_ID_MAPPING error
> occurs following expiration of the producerId. It's possible that another
>
Hey Guozhang,
Thanks for sharing the article. The INVALID_PRODUCER_ID_MAPPING error
occurs following expiration of the producerId. It's possible that another
producerId has been installed in its place following expiration (if another
producer instance has become active), or the mapping is empty.
You're right about the dangling txn since it will actually block
read-committed consumers from proceeding at all. I'd agree that since this
is a very rare case, we can consider fixing it not via broker-side logic
but via tooling in a future work.
I've also discovered some related error handling
Hey Guozhang,
To clarify, the broker does not actually use the ApiVersion API for
inter-broker communications. The use of an API and its corresponding
version is controlled by `inter.broker.protocol.version`.
Nevertheless, it sounds like we're on the same page about removing
0. My original question is about the implementation details primarily,
since current the handling logic of the APIVersionResponse is simply "use
the highest supported version of the corresponding request", but if the
returned response from APIVersionRequest says "I don't even know about the
Hey Guozhang,
Thanks for the comments. Responses below:
0. The new API is used between brokers, so we govern its usage using
`inter.broker.protocol.version`. If the other broker hasn't upgraded, we
will just fallback to the old logic, which is to accept the write. This is
similar to how we
Hello Jason, thanks for the great write-up.
0. One question about the migration plan: "The new GetTransactionState API
and the new version of the transaction state message will not be used until
the inter-broker version supports it." I'm not so clear about the
implementation details here: say a
I am +1 on this :)
-Matthias
On 9/4/18 9:55 AM, Jason Gustafson wrote:
> Bump. Thanks to Magnus for noticing that I forgot to link to the KIP:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-360%3A+Improve+handling+of+unknown+producer
> .
>
> -Jason
>
> On Tue, Aug 21, 2018 at 4:37
Bump. Thanks to Magnus for noticing that I forgot to link to the KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-360%3A+Improve+handling+of+unknown+producer
.
-Jason
On Tue, Aug 21, 2018 at 4:37 PM, Jason Gustafson wrote:
> Hi All,
>
> I have a proposal to improve the
Hi All,
I have a proposal to improve the transactional/idempotent producer's
handling of the UNKNOWN_PRODUCER error, which is the result of losing
producer state following segment removal. The current behavior is both
complex and limited. Please take a look and let me know what you think.
Thanks
20 matches
Mail list logo
