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
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.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:
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?
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)
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)
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.
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:
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
The text was updated successfully, but these errors were encountered: