| Re: [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC |
|
Still, it's questionable how many resources users are actually handling outside the application server's control , but for now, I can follow your definition of customer value at a conceptual level. Thank you for the explanation. -Kenji Kazumura From: Gerrit Grunwald <ggrunwald@xxxxxxxx>
Hi Kenji, Ok here you go, let's assume your application is using microservices and you need to scale those services from time to time depending on the load. If your app is running
on a Jakarta EE based app server, the startup time of your service might be within 5-10 seconds. This is not really great if you would like to serve your customers as quickly as possible. In such a scenario startup time is king and the shorter the better.
With CRaC you can bring the startup down to 1 second and even below (which is the reason why other frameworks like SpringBoot, Micronaut and Helidon also support CRaC). In short everywhere you need a fast startup of your application CRaC can help. The idea is to have two options to create checkpoints, the first option is to let the app server automatically create the checkpoint directly after it was started and
right before the application code will loaded. This could already save up to 80% of the startup time depending on the application size. In this case the user doesn't have to do anything because the application code isn't even loaded at that point. The second option would be a manual checkpoint that is triggered by the user from the outside of the JVM by using jcmd. In this case you as a user can decide when to
create the checkpoint of the application. You might ask yourself why does this make sense? Well if you have an application that takes some time to warm up, you first can warm it up in your CI/CD pipeline and then create the checkpoint. In production you restore
it from this checkpoint and the application will continue running from there within 1 second. The second option might need some changes in the code but will give you the fastest possible startup to a completely warmed up application. To your last point...this is exactly why CRaC needs to be implemented by the application server. In case the application server supports CRaC, it can take care of closing
and re-opening resources like JDBC connections. And to make sure everything is implemented in a compatible way, a Jakarta EE specification for CRaC makes sense. I hope that helped you in understanding the project better. Kind regards, Gerrit Von: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx>
im Auftrag von Kenji Kazumura (Fujitsu) via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Thanks for response. Could you provide realistic use cases or practical examples that make it clear what value this specification would offer users,
based on the following assumptions? * The problem this specification is trying to solve is startup time. * Most of the startup time is the time spent starting and initializing the application server. * User applications also use resources such as JDBC connections, but those are usually managed by the application server. -Kenji Kazumura From: Gerrit Grunwald <ggrunwald@xxxxxxxx>
Hi there, let me try to answer your questions...
I hope this helps to better understand the idea behind the JakartaEE CRaC specification. Kind regards, Gerrit Von: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx>
im Auftrag von Kenji Kazumura (Fujitsu) via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
I also have a few questions, which I submitted to GitLab (https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/work_items/1399#note_8631094),
but I move them to this thread. [Original questions submitted to GitLab] (1) Please explain the differences and relationship between this project and the OpenJDK CRaC project (https://openjdk.org/projects/crac/). (2) Please explain why this must be the Jakarta EE specification rather than the Java SE specification. (3) Regarding the background, please clarify exactly how many
“Many of” refers to. (4) Please explain why the Patent License must be an Implementation Patent License. (5) This specification seems to be used by application server vendors. Please explain what benefits standardizing this specification would offer
to users of Jakarta EE. Ivar gave me an answer (https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/work_items/1399#note_8636375), but I still didn't quite understand the benefits of standardization for end users. I understand that using CRIU allows application server vendors to provide values to users.
However, it seems to me that this is dependent on the vendor's implementation.
If there is a requirement for users to interact with CRIU directly from their programs,
I'm not clear the reason that it would be better to define that in Jakarta EE rather than in the Java SE or JDK specifications. -Kenji Kazumura From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx>
On Behalf Of David Blevins via jakarta.ee-spec To be clear, I'm not making a point but asking questions. I have no formed opinion on where or how. Just questions at this point. If we are imaging creating API classes, we should create a spec. If we only intend on producing requirements and tests, maybe going the route platform requirements plus requirements in individual specs is more apt.
That said, there still might be reasons for a spec -- would just want to identify them first. Either way, the need for the work is clear and we're on board with a CRaC requirement in Jakarta EE. The most ideal outcome is that we're all required to run all TCK tests for all specs on a CRaC snapshot. -David
|