Daniel Schierbeck created KAFKA-5617:
Summary: Update to the list of third-party clients
Key: KAFKA-5617
URL: https://issues.apache.org/jira/browse/KAFKA-5617
Project: Kafka
Issue Type
Hi Apurva,
Thanks for taking the time to reply. You make excellent points, and it
sounds like the right tradeoff. It would be great if the coordinator code
could be shared with the consumer API, hope that's actually the case.
Daniel Schierbeck
On Thu, 1 Dec 2016 at 18.34 Apurva Mehta
I don't have a lot of feedback on this, but at Zendesk we could definitely
use a standardized header system. Using ints as keys sounds tedious, but if
that's a necessary tradeoff I'd be okay with it.
On Fri, Dec 2, 2016 at 5:44 AM Todd Palino wrote:
> Come on, I’ve done at least 2 talks on this
would be reluctant to implement the transaction API in the near future, but
would love to implement the idempotency API soon. The former seems only
relevant to real stream processing frameworks, which is probably not the
best use case for ruby-kafka.
Cheers,
Daniel Schierbeck
On Thu, Dec 1, 2016 at 9:54 AM
Jiangjie: I think giving users the possibility of defining a custom policy
for handling rejections is a good idea. For instance, this will allow Kafka
to act as an event store in an Event Sourcing application. If the event(s)
are rejected by the store, the original command may need to be re-validat
[
https://issues.apache.org/jira/browse/KAFKA-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14635281#comment-14635281
]
Daniel Schierbeck commented on KAFKA-2260:
--
Where is the KIP being discusse
[
https://issues.apache.org/jira/browse/KAFKA-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585601#comment-14585601
]
Daniel Schierbeck commented on KAFKA-2260:
--
On the mailing list we discuss
intain the mapping for each write.
I'd be willing to do the coding if you think it's a good idea.
On Mon Jan 05 2015 at 2:24:00 PM Daniel Schierbeck <
daniel.schierb...@gmail.com> wrote:
> Reading your reply again, I'd like to address this:
>
> > Also, it seems l
ents for that key. If not,
it should wait a bit and try again, re-validating the input against the new
state of the world. Is that a completely hopeless idea?
On Mon Jan 05 2015 at 2:18:49 PM Daniel Schierbeck <
daniel.schierb...@gmail.com> wrote:
> Regarding the use case – some events may
recommend not using a queuing mechanism as a primary datastore - mixed
> semantics.
>
> --
> *Colin*
> +1 612 859-6129
>
>
> On Mon, Jan 5, 2015 at 4:47 AM, Daniel Schierbeck <
> daniel.schierb...@gmail.com> wrote:
>
> > I'm trying to design a system that
#x27;re not identical, fail with some OptimisticLockingFailure.
Would such a feature be completely out of scope for Kafka?
Best regards,
Daniel Schierbeck
Daniel Schierbeck created KAFKA-1827:
Summary: Optimistic Locking when Producing Messages
Key: KAFKA-1827
URL: https://issues.apache.org/jira/browse/KAFKA-1827
Project: Kafka
Issue Type
#x27;re not identical, fail with some OptimisticLockingFailure.
Would such a feature be completely out of scope for Kafka?
Best regards,
Daniel Schierbeck
#x27;re not identical, fail with some OptimisticLockingFailure.
Would such a feature be completely out of scope for Kafka?
Best regards,
Daniel Schierbeck
14 matches
Mail list logo
