You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature request: Priming for powertools-tracing #2004
Java CRaC can be used to prime an application by implementing beforeCheckpoint() and afterRestore() hooks in selected classes. When used with AWS Snapstart, the beforeCheckpoint() hook runs before the memory snapshot is taken. This behavior can be leveraged to further reduce restore durations by pre-loading classes and calling commonly used code to incorporate this into the memory snapshot.
Class-preloading / automatic priming: Based on a statically generated classesloaded.txt file, loads classes used at runtime into memory
Invoke priming: Execute commonly used code e.g. to initialize all reflectively access objects, warm up caches, TCP connection pools etc. Common examples include performing "dry" AWS SDK calls (not impacting production resources) or performing JSON serialization/deserialization.
The goal of this issue is to implementing priming techniques for the powertools-tracing module.
Solution/User Experience
Implement priming based on Priming Documentation (feel free to update documentation and suggest improvements):
I'd be happy to help implement priming support for the powertools-tracing module. I've reviewed the priming documentation and the reference implementation in powertools-metrics, and I have a good understanding of what needs to be done.
My proposed implementation approach:
Add Maven profile to powertools-tracing/pom.xml for generating the classes loaded file (similar to the generate-classesloaded-file profile in powertools-metrics)
Generate and clean up the classesloaded.txt file by:
Running tests with the VM argument -Xlog:class+load=info:classesloaded.txt
Processing the file to extract only the fully qualified class names
Moving it to src/main/resources/
Implement CRaC Resource interface in TracingUtils class (as the main entry point for the tracing module) by:
Adding CRaC dependency and imports
Registering with Core.getGlobalContext() in a static block
Implementing beforeCheckpoint() to call ClassPreLoader.preloadClasses()
Adding any tracing-specific initialization (like initializing X-Ray components)
Test the implementation to ensure it works correctly with SnapStart
I notice that TracingUtils is the main utility class that users interact with, making it a suitable candidate for CRaC integration, similar to how MetricsFactory is used in the metrics module.
Would you like me to proceed with this implementation? I can start with creating a PR that follows the same pattern as the metrics module implementation.
Also, are there any specific tracing-related initializations you'd recommend including in the beforeCheckpoint() hook beyond the standard class preloading?
Thanks for creating this issue and making it accessible to new contributors! 🚀
thanks for your detailed implementation plan. I think it makes sense to include the Priming logic in TracingUtils. Just a note: It is possible to use only @Tracing annotation and since this is an AspectJ aspect it does not trigger the CRaC hooks if it calls TracingUtils transitively. We need to update the documentation with guidance that the user needs to reference TracingUtils directly in their code to trigger SnapStart priming.
We did the same thing for ValidationConfig in this PR: #2081.
Regarding what to prime:
Class pre-loading
Invoke priming of AWS SDK. You can prime the X-RAY SDK by performing some dummy calls but need to make sure that no traces are persisted in X-RAY which will incur a cost to the user. Ideally you can make some requests that do not have any persistent side-effects.
Let me know if you have any questions. Should I assign the issue to you to work on it?
Thanks for the feedback and clarifications! I understand the important point about users needing to reference TracingUtils directly to trigger SnapStart priming, and I'll make sure to update the documentation accordingly.
I'm ready to work on this implementation following the patterns established in the metrics module and the ValidationConfig approach from PR #2081. I'll focus on:
Class pre-loading via TracingUtils
Invoke priming of X-Ray SDK with dummy calls that don't persist traces
Proper documentation updates about direct TracingUtils usage
Please assign this issue to me and I'll get started on the implementation.
@phipag can you please have a look at my PR. I have made the changes to the best of my understanding, so it would be great if you could suggest any more changes if needed.
Activity
dcabib commentedon Aug 29, 2025
Hi @phipag! 👋
I'd be happy to help implement priming support for the
powertools-tracingmodule. I've reviewed the priming documentation and the reference implementation inpowertools-metrics, and I have a good understanding of what needs to be done.My proposed implementation approach:
Add Maven profile to
powertools-tracing/pom.xmlfor generating the classes loaded file (similar to thegenerate-classesloaded-fileprofile in powertools-metrics)Generate and clean up the classesloaded.txt file by:
-Xlog:class+load=info:classesloaded.txtsrc/main/resources/Implement CRaC Resource interface in
TracingUtilsclass (as the main entry point for the tracing module) by:Core.getGlobalContext()in a static blockbeforeCheckpoint()to callClassPreLoader.preloadClasses()Test the implementation to ensure it works correctly with SnapStart
I notice that
TracingUtilsis the main utility class that users interact with, making it a suitable candidate for CRaC integration, similar to howMetricsFactoryis used in the metrics module.Would you like me to proceed with this implementation? I can start with creating a PR that follows the same pattern as the metrics module implementation.
Also, are there any specific tracing-related initializations you'd recommend including in the
beforeCheckpoint()hook beyond the standard class preloading?Thanks for creating this issue and making it accessible to new contributors! 🚀
phipag commentedon Sep 1, 2025
Hey @dcabib,
thanks for your detailed implementation plan. I think it makes sense to include the Priming logic in
TracingUtils. Just a note: It is possible to use only@Tracingannotation and since this is an AspectJ aspect it does not trigger the CRaC hooks if it callsTracingUtilstransitively. We need to update the documentation with guidance that the user needs to referenceTracingUtilsdirectly in their code to trigger SnapStart priming.We did the same thing for
ValidationConfigin this PR: #2081.Regarding what to prime:
Let me know if you have any questions. Should I assign the issue to you to work on it?
dcabib commentedon Sep 1, 2025
Hi @phipag!
Thanks for the feedback and clarifications! I understand the important point about users needing to reference TracingUtils directly to trigger SnapStart priming, and I'll make sure to update the documentation accordingly.
I'm ready to work on this implementation following the patterns established in the metrics module and the ValidationConfig approach from PR #2081. I'll focus on:
Please assign this issue to me and I'll get started on the implementation.
Thanks!
phipag commentedon Sep 1, 2025
That's awesome @dcabib. I assigned the issue to you 🚀
feat: Support CRaC priming for powertools-tracing and powertools-seri…
feat: Support CRaC priming for powertools-tracing
feat: Support CRaC priming for powertools-tracing
phipag commentedon Sep 29, 2025
This issue is in the backlog again and open for contribution.
Attyuttam commentedon Nov 25, 2025
Hi, I would like to pick this up
Attyuttam commentedon Dec 22, 2025
@phipag can you please have a look at my PR. I have made the changes to the best of my understanding, so it would be great if you could suggest any more changes if needed.
phipag commentedon Dec 22, 2025
Thanks @Attyuttam, let's continue the conversation in the PR.
Attyuttam commentedon Jan 19, 2026
@phipag i think we can close this issue as it has been addressed in this PR: #2345
phipag commentedon Jan 19, 2026
You are right @Attyuttam, I missed this! Thanks!