[
https://issues.apache.org/jira/browse/KAFKA-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Koshy updated KAFKA-353:
-----------------------------
Attachment: kafka-353_v3.patch
Thanks for catch-21 :) Fixed that - (note that requiredAcks cannot be 0 in
isSatisfied.)
For 22, turned out to be due to inconsistent default values for the producer
config. Test passes now.
Re: Jay's comment. It is true that the requests that collectSatisfied returns
will not go through expiration (by virtue of the satisfied guard). The issue is
that the client needs to be aware that the call to expire and checkSatisfied
can be simultaneous and so may need to synchronize on data structures that
their implementations may access. So we can either synchronize on the purgatory
or clearly document this. Personally, I'm leaning toward fixing it in purgatory
because:
- if checkSatisfied is called (and it will return true), it seems we should
consider the deadline to have been met (although this is not clear cut) so
expiration should not proceed.
- it makes the purgatory a little harder to use as the client needs to be aware
of the race condition.
> tie producer-side ack with high watermark and progress of replicas
> ------------------------------------------------------------------
>
> Key: KAFKA-353
> URL: https://issues.apache.org/jira/browse/KAFKA-353
> Project: Kafka
> Issue Type: Sub-task
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Joel Koshy
> Attachments: kafka-353_v1.patch, kafka-353_v2.patch,
> kafka-353_v2_to_v3.patch, kafka-353_v3.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
