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 missed something while reading but I can't see how the end-user benefits. Faster client startup time perhaps? But then the question is how much faster? In general, I would expect Kafka client startup time to be mostly bound by the time it takes to contact the brokers. best, Colin On Fri, Apr 21, 2023, at 01:10, Radim Vansa wrote: > 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 <rva...@azul.com.invalid> wrote: >> >>> Hello, >>> >>> upon filing a PR [1] with some initial support for OpenJDK CRaC [2][3] I >>> was directed here to raise a KIP (I don't have the permissions in >>> wiki/JIRA to create the KIP page yet, though). >>> >>> In a nutshell, CRaC intends to provide a way to checkpoint (snapshot) >>> and persist a running Java application and later restore it, possibly on >>> a different computer. This can be used to significantly speed up the >>> boot process (from seconds or minutes to tens of milliseconds), live >>> replication or migration of the heated up application. This is not >>> entirely transparent to the application; the application can register >>> for notification when this is happening, and sometime has to assist with >>> that to prevent unexpected state after restore - e.g. close network >>> connections and files. >>> >>> CRaC is not integrated yet into the mainline JDK; JEP is being prepared, >>> and users are welcome to try out our builds. However even when this gets >>> into JDK we can't expect users jump onto the latest release immediately; >>> therefore we provide a facade package org.crac [4] that delegates to the >>> implementation, if it is present in the running JDK, or provides a no-op >>> implementation. >>> >>> With or without the implementation, the support for CRaC in the >>> application should be designed to have a minimal impact on performance >>> (few extra objects, some volatile reads...). On the other hand the >>> checkpoint operation itself can be non-trivial in this matter. Therefore >>> the main consideration should be about the maintenance costs - keeping a >>> small JAR in dependencies and some extra code in networking and >>> persistence. >>> >>> The support for CRaC does not have to be all-in for all components - >>> maybe it does not make sense to snapshot a Broker. My PR was for Kafka >>> Clients because the open network connections need to be handled in a web >>> application (in my case I am enabling CRaC in Quarkus Superheros [5] >>> demo). The PR does not handle all possible client-side uses; as I am not >>> familiar with Kafka I follow the whack-a-mole strategy. >>> >>> It is possible that the C/R could be handled in a different layer, e.g. >>> in Quarkus integration code. However our intent is to push the changes >>> as low in the technology stack as possible, to provide the best fanout >>> to users without duplicating maintenance efforts. Also having the >>> support higher up can be fragile and break encapsulation. >>> >>> Thank you for your consideration, I hope that you'll appreciate our >>> attempt to innovate the Java ecosystem. >>> >>> Radim Vansa >>> >>> PS: I'd appreciate if someone could give me the permissions on wiki to >>> create a proper KIP! Username: rvansa (both Confluence and JIRA). >>> >>> [1] https://github.com/apache/kafka/pull/13619 >>> >>> [2] https://wiki.openjdk.org/display/crac >>> >>> [3] https://github.com/openjdk/crac >>> >>> [4] https://github.com/CRaC/org.crac >>> >>> [5] https://quarkus.io/quarkus-workshops/super-heroes/ >>> >>> >> -- >> [image: Aiven] <https://www.aiven.io> >> >> *Josep Prat* >> Open Source Engineering Director, *Aiven* >> josep.p...@aiven.io | +491715557497 >> aiven.io <https://www.aiven.io> | <https://www.facebook.com/aivencloud> >> <https://www.linkedin.com/company/aiven/> <https://twitter.com/aiven_io> >> *Aiven Deutschland GmbH* >> Alexanderufer 3-7, 10117 Berlin >> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> Amtsgericht Charlottenburg, HRB 209739 B >>
