Hi Divij,
I think that your understanding is correct. The rest of replies inline...
On 30. 05. 23 15:31, Divij Vaidya wrote:
Caution: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
Hi Colin,
yes, with the draft status this is kind of chicken-egg problem - we'd
like to collect feedback and round the edges in implementation before it
lands in JDK and for that a support in common frameworks/libraries is
necessary. But I understand the reluctance to a non-finalized feature.
Hmm. This isn't something I say very often, but it might be a bit too early for
a KIP about this. Support hasn't even landed in any version of Java yet. How do
we know that it will look simlar to the draft proposal when and if it does land?
Also, what is the advantage to the user? Maybe I
Thank you for mentioning the use case.
I will try to summarize what you mentioned above in my own words to ensure
that I have understood this correctly.
There are practical use cases where the user application has a dependency
on Kafka producer and requires very quick cold starts. In such cases,
Hi Divij,
I have prototyped this using Quarkus Superheroes [1], a demo application
consisting of several microservices that communicate with each other
using both HTTP and Kafka. I wanted to add the ability to transparently
checkpoint and restore this application - while the regular startup
Hey Radim
After reading the KIP, I am still not sure about the motivation for this
change. The bottleneck in starting a producer on Kafka is setup of the
network connection with the broker (since it performs SSL + AuthN). From
what I understand, checkpoint and restore is not going to help with
Thank you, Divij. I'll give it more time and remind the list in that
timeframe, then.
Radim
On 11. 05. 23 13:47, Divij Vaidya wrote:
Caution: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
Hey Radim
One of the reasons for the slowdown is preparation of upcoming releases
(the community is currently in code freeze/resolve release blockers mode)
and preparation for Kafka Summit next week. I would suggest giving another
2-3 weeks for folks to chime in. I would personally visit this KIP
Hello all,
it seems that this KIP did not sparkle much interest, not sure if people
just don't care or whether there are any objections against the
proposal. What should be the next step, I don't think it has been
discussed enough to proceed with voting.
Cheers,
Radim
On 27. 04. 23 8:39,
Thank you for those questions, as I've mentioned, my knowledge of Kafka
is quite limited so these are the things that need careful thinking!
Comments inline.
On 26. 04. 23 16:28, Mickael Maison wrote:
Hi Radim,
Thanks for the KIP! CRaC is an interesting project and it could be a
useful
Hi Radim,
Thanks for the KIP! CRaC is an interesting project and it could be a
useful feature in Kafka clients.
The KIP is pretty vague in terms of the expected behavior of clients
when checkpointing and restoring. For example:
1. A consumer may have pre-fetched records in memory. When it is
Hi all,
I haven't seen much reactions on this proposal. Is there any general
policy regarding dependencies, or a prior decision that would hint on this?
Thanks!
Radim
On 21. 04. 23 10:10, Radim Vansa wrote:
Caution: This email originated from outside of the organization. Do
not click
Thank you,
now to be tracked as KIP-921:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-921%3A+OpenJDK+CRaC+support
Radim
On 20. 04. 23 15:26, Josep Prat wrote:
Hi Radim,
You should have now permissions to create a KIP.
Best,
On Thu, Apr 20, 2023 at 2:22 PM Radim Vansa wrote:
13 matches
Mail list logo
