Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the routine "Class-Path attribute cleared for ..." expensive? (omit verification?) #889

Open
in-fke opened this issue Dec 1, 2022 · 1 comment

Comments

@in-fke
Copy link

in-fke commented Dec 1, 2022

I wonder if "clearing" the Class-Path attribute is expensive in some way? (re-reading the jar file)

Going by this PR there seems to be a re-read of the jar file?
c7a6c2e
here is the current source for better readability.
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/core/src/main/java/net/sourceforge/jnlp/runtime/CachedJarFileCallback.java#L87

The reason why this occurred to me was that start of our OSGI application is rather slow.
Our Eclipse Applications consists of 317 Bundles.
Grepping for "Class-Path attribute cleared for" in the stage2 log (OpenWebStart) gives us a count of 695 occurences.
Routine for extracting that log (Bash under Cygwin)

grep 'Class-Path attribute cleared for ' $(ls -rt $(cygpath 'C:\Users\NNN\.config\icedtea-web\log\')*stage2.log | tail -1) | sed -e 's/.*Class-Path attribute cleared for \(.*\)/\1/' | sort

shows us, that - probably due to OSGI or Eclipse mechanics - each bundle is "touched" at least twice this way, which would give us 634 occurrences. The remaining multiple occurrences come from bundles, which probably have special OSGI awareness.

  • org.apache.logging.log4j.api 36 times, see Logging Separation
  • org.apache.xerces 30 times - haven't looked into that
  • org.glassfish.jersey.core.jersey-common 3 times

To not just "cling" the only log output I have (from CachedJarFileCallback.java) I tried to activate some OSGI logging but could not manage.

Anyway, I was wondering if it would be worth "boosting" that routine, e.g. the "retrieve()" method could cache that "returnFile" ?
This would only be worth it, I guess, if we measure the timings of:

  • CTOR for JarFile
  • timing of getManifest()

Another means could be opening the Jar file (in this case) without verification?
public JarFile(File file, boolean verify, int mode)

Or who is the caller of retrieve() and would the expect the Jar to be verified?

Alternatively, leave on verification but cache the result of retrieve() ? Not sure how cacheJarFile() works though (does not remove the Class-Path entry?).

Is removing the Class-Path entry still necessary at all?

related: spring-projects/spring-framework#9371

@in-fke
Copy link
Author

in-fke commented Dec 1, 2022

Come to think of it, if you ever wonder how one could run in the "could not find mapping for ..." and cacheJarFile() case, I had one:
karakun/OpenWebStart#385 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant