Auto-reloading .jar fails #1106
Comments
|
I wouldn't expect this to work really, and it doesn't seem like you did either. Is it a feature request? |
|
Ah, forgot to add the actual question: is there a way to disable this reloading behaviour or is it something that |
|
Good question. I doubt there's much we can do. Did you try running a simple (non-Boot launched) jar and see if that would ever work? Also interesting to know would be if it works with a Boot jar that isn't a webapp I guess. Switching it off might be possible if it is an artifact of the Boot classloader (hence the answers to the questions above might be interesting). |
|
I tried Dropwizard's example app and it doesn't seem to even attempt to reload the .jar file, it serves the old contents after the file is overwritten. This suggests it's something that Boot does explicitly, right? I could try with a non-web Boot app, but I've already used up all my investigation time for this issue for today, will do this later this week as it's not a stopper for me (...yet!). Thanks for quick reaction. |
|
The exception is most probably caused by the ground moving underneath the feet of the fat jar support. We have a somewhat unique implementation where we scan the contents of the nested JARs and work out where within the actual file the contents of an entry begins. When you read a file or class from a nested JAR we actually seek to the relevant position in the file and read the contents. This allows us to have fat jars that look nice (i.e. all the classes from the nested aren't repackaged) and that don't need to unpack things to temporary directories. When the jar is repackaged, the positions of the nested jars changes but the previously calculated index is not updated. Hence the ZLIB input stream exceptions. One option would be for us to check the timestamp and size of the JAR whenever an entry is read to see if we need to reindex. I'm not too keen to add this additional logic, especially as most users seem to be running using |
|
Is it possible to put a write lock on the jar while the app is running? |
wilkinsona
removed
the
status: waiting-for-feedback
|
Was this issue resolve? Last February, 2014 I attemted to used the maven jar plugin but did not work. Just today, I am thinking I can employ this again in our application because this feature is really neat. Unfortunately, I get same error I had a year ago. java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy |
|
I think you can probably see that the issue is still open. I don't really know what you mean by "this feature" though. What did you do and what happened and what did you think might happen? |
|
I meant the jarlauncher is really neat because makes our application deployment into production simpler. BTW, the only thing that I observed is the one jar is deplyed in a network folder. After the application been running for several minutes, the error above comes out. |
|
I have not tried yet to deploy it in a local folder. I will try later and see if the error will still come out. |
|
BTW, the only thing that I observed is the one jar is deplyed in a network folder. After the application been running for several minutes, the error above comes out.
If you're not replacing the jar while the application is running, you're
having a different issue.
Sounds like the jar is on a different machine than where the application
is running. This kind of scenario has been notorious for causing
problems, so the usual "best practice" advice is: Don't do that, keep
the jars locally on the machine where it's supposed to run.
|
|
I have had issues on Amazon Linux where spring boot seemingly sporadically tries to re-load the jar and subsequently fails. I haven't been able to figure out what is triggering the re-loads, the mtime of the jar and temp folders seemed unchanged. Perhaps files are touched by some sort of scanner in a way which isn't immediately obvious. Anyway, for these cases it would be great to be able to disable the auto-reloading with a flag. |
|
Which case is responsible for reloading of the JAR on the fly? My application which is based on spring-boot 1.2.3 had been working fine for a couple of days when this exception was thrown, suddenly. My observations:
|
|
Reminds me of #4968 |
|
Network storage again? |
|
I'm having a very similiar issue to that described by @MarcinMiotk. We have a spring-boot (1.3.0.RELEASE) worker running on production, which collapses randomly, after having run for many hours (sometimes even days), without any trouble. The application is deployed on a virtual machine, started with At some point, various application threads start to throw: Exception in thread "pastillGenerationTaskExecutor-1" java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:121)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:440)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:396)
at ch.qos.logback.classic.Logger.error(Logger.java:555)
at pl.dreamlab.bigdata.clickpastiller.aggregation.pastills.FileBasedPastillsFactory.createFileForPastill(FileBasedPastillsFactory.java:70)
at pl.dreamlab.bigdata.clickpastiller.aggregation.pastills.FileBasedPastillsFactory.create(FileBasedPastillsFactory.java:47)
at pl.dreamlab.bigdata.clickpastiller.aggregation.PastillGeneratingWorker.initializePastillIFNoneActive(PastillGeneratingWorker.java:62)
at pl.dreamlab.bigdata.clickpastiller.aggregation.PastillGeneratingWorker.run(PastillGeneratingWorker.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxy
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at org.springframework.boot.loader.LaunchedURLClassLoader.doLoadClass(LaunchedURLClassLoader.java:166)
at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:130)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 11 moreand the worker dies eventually. This seems like a very serious issue. @dsyer @snicoll @atorstling @toolforger @philwebb Do you see any fix or a possible workaround? Since, we are deploying it onto a virtual machine (managed via proxmox), there isn't really any "local storage" available to us. |
|
I did some digging into the root cause of this particular exception. It happened, when a call to |
|
@turu The same temporary network issue is likely to also be the cause of You may be able to work around the problem by aggressively loading classes when the application first starts. This will cache them in memory making your application less vulnerable to temporary network problems that make the file system inaccessible. |
|
I just started seeing this running locally after running for awhile. I have a couple IntelliJ windows running spring boot apps as WARs in non-embedded tomcat. Everything is fine then one app or the other starts failing with this. |
|
seeing the same thing in a grails 3.1.6 app on a 12" macbook pro and jenkins but not on a 15" using gradle 2.13 seems awfully suspicious |
|
its almost as if something packaging the war file is not properly flushing it before closing |
|
We started seeing this Sometimes but not always the error would be proceeded by
|
philwebb
added
for: stackoverflow
|
I think #6683 may have been the root cause of this and has been fixed in 1.3.8 |
snicoll
added
status: duplicate
|
Still here, with 1.5.6. Using a ZIP layout, with execute: true. |
|
@ebuildy If that's the case, can you please open a new issue and provide a sample that reproduces the problem? |
|
Same issue, seemingly randomly, during spring batch jobs on spring boot 2.0.0M3. |
|
@jbrant could you please have considered the comment just above yours before commenting? |
Looks like the .jar file auto-reloads which was kind of surprising to me, especially since it doesn't seem to be handled very well - ugly zip-related exception in the log.
Steps to reproduce:
mvn package, go totarget/and run:java -jar demo-0.0.1-SNAPSHOT.jarlocalhost:8080(by "works" I mean that it serves the error 404, but that's not the point here)target/do anmvn packageagain - the original .jar file will get overwrittenIn my applicatiton this makes the application stop responding, but this simplified example still happily serves the 404 - hopefully you won't need an example app that shows it. The stack trace is also slightly different:
Example app also fails with Jetty, the stacktrace doesn't mention zip though:
The text was updated successfully, but these errors were encountered: