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.
The answer is probably in the minimalism of the actual dependency: the
API is very unlikely to change, especially if this relies only on
implementing two interface methods and calling a ~static registration.
Also there is low risk to applications that don't use it - because it
won't execute anything.
Please see the other discussion (with Divij) in this thread for the
answer on the advantage to the user. Unless all parts of the app that do
I/O cooperate, the user can't use CRaC. This won't help Kafka to do any
better on its own, but will allow using Kafka in applications that
improve deployment times using CRaC.
Radim
On 31. 05. 23 23:28, Colin McCabe 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.
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
