[
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_v2.patch
Here is v2 - changes from v1:
- Rebased.
- Addressed all the "minor" comments.
- Using NonFollowerId (alias of DefaultReplicaId) instead of -1
- For request timing: added the duration computation to the Response
class and removed all the default -1.
- Added handling for requiredAcks < 0
- To deal with the race condition that Jay raised, did an explicit update
after adding to the produceRequestPurgatory.
- Removed the proactive update to produceRequestPurgatory on a leader
change. This facilitated moving the ProduceRequestPurgatory and
DelayedProduce back to KafkaApis where they belong.
- I'm still doing the isLocal check in the isSatisfied method because we get
it for free and NotLeaderForPartitionCode is more accurate than giving a
timeout error code. We can discuss whether to remove this altogether or
not.
- One thing v1 did not handle was negative timeouts which should be
interpreted as forever, so I converted -ve values to Long.MaxValue. In
doing this I hit what I thought was a bug in DelayQueue but turned out to
be an overflow issue with DelayedItem - added checks for this.
Also, Jun asked about a race condition on partitionStatus - although
isSatisfied cannot be called simultaneously on the same DelayedProduce, I
think there is a race condition between expire/checkSatisfied in the
requestPurgatory. I can switch to a ConcurrentHashMap for the
partitionStatus map, but I think this is an issue in the RequestPurgatory.
I think it should be easy to fix, but wanted to call it out first to see if
I'm incorrect:
- An incoming request triggers checkSatisfied on a DelayedItem
- During checkSatisfied the DelayedItem expires and the expiration loop
calls expire().
- There is a satisfied guard on the DelayedItem but that is checked only
after expire() and after checkSatisfied() so it is possible for both
checkSatisfied and expire to be called and it doesn't seem to make sense
to allow both - it's one or the other.
> 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
>
>
--
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
