-
Notifications
You must be signed in to change notification settings - Fork 93
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
SVT: Application keeps on restarting in Dev mode without making any changes to the app #1755
Comments
The prev errors were on Eclipse.
|
Could be related to #699? Although Rumana did say she did not see the same behavior from the command line. Need to try and recreate from the cmd line ourselves to see. |
Update about command line. I just retried, and I see the same behavior from the command line as well. The issue is where I run the
However - if I run within the project AcmeWebEjbEar |
I've been experimenting with the CargoTracker Jakarta sample: https://github.com/eclipse-ee4j/cargotracker/ There seems to be a similar "thrashing" behavior where the app continually restarts upon update. I accounted for the issue: #699 by building a local snapshot and hard-coding disabling the initial compile (the one we do AFTER the compile mojo runs). While this simplified the initial startup, I still experienced the same thing after later making an update once the app had been up and started. There seems to be something app-related in play here. The cargo tracker uses EJB persistent timers and its JPA runs a startup script... not sure if either of those are related. |
@rumanaHaque can you please try to recreate with this trace:
I saw something similar w/ the cargotracker app...there I suspect it is some failures related to messaging & MDB init causing the thrashing..combined with the fact that restarting some of these messaging components forces an app recycle. I'm not too familiar with this from the runtime perspective.. so possibly we'd need a couple rounds of tracing to get to the bottom of this. Thank you ! |
I added the server trace string as you mentioned in my server.xml file- I did an mvn clean, and started my server using the Liberty Tools dashboard. These are the logs for the server after I started, and it also has the console.txt file where I tried to capture most of the console output. I also got the server dump as you requested - by running this command.
Here is the server dump. |
It looks to me like the |
Hi @scottkurz - Yes - sorry I had put the trace string in a diff server.xml in my workspace. And the server dump again. |
Discussed this more in DXDI call today: https://github.com/orgs/OpenLiberty/projects/23/views/3?pane=issue&itemId=50131096 I'm going to share some sketched out, incomplete thoughts here, though this doesn't even include detailed analysis of the captured trace, just some guesses based on a preliminary look at the logs captured back in Dec. THOUGHTSI wonder if this issue raises a weakness with the design assumption that we don't need an mbean notification on app update, (like we used in WDT/LDT). This would potentially allow us to do a single app restart rather than multiple ones. That said, I wouldn't think the app would just keep restarting if this were the core issue. I'd think it'd eventually settle down...but this is just a guess. Looking into it a bit, it seems WDT builds a set of changed files and invokes the FileNotificationMBean passing this set, after which the Liberty runtime then (re)starts the app. I also wonder if bumping up the polling rate could reduce the chance for this kind of situation. E.g. if we switched from 500ms to 5s would the mbean not be as important?
CONCLUSIONThat's all for now, I'm not asking anyone to rerun anything, just sharing some of my own notes on the subject here. |
We encountered the same problem with our apps going through several restarts at the initial liberty:dev execution (@scottkurz please note that Rumana does not speak of continually restarting but instead says "It goes through this cycle a couple of times before the application is finally available"). I took the suggestion from your previous comment and experimented with the applicationMonitor pollingRate. Setting it to more than what is required for the application startup time plus all the module's 'source compilation was successful/tests compilation was successful' calls indeed prevents the multiple restarts. This however will make the liberty:dev experience a lot less responsive to code changes. The mbean notification mechanism would be my preferred solution, but perhaps an extra one letter command to restart the application is an easy to implement alternative. Ofcourse, getting rid of the initial compile calls as described in #699 would also help. |
@m-schutte-ohra-nl, though I don't have any further updates on this issue, I just wanted to thank you for sharing your experience here. |
@scottkurz This is still a real problem for us, can we expect progress to be made on this issue ? |
Hi @rumanaHaque The fix is included in the snapshot 3.11.3-SNAPSHOT. Please see the doc here for how to use a snapshot. |
@m-schutte-ohra-nl Please let us know if the fix provided in the snapshot release helps with your issue. The fix mainly avoids recompiling when the compile was already successful (issue #699). There may be more changes needed to completely fix this issue though. So any feedback you can provide would be valuable. Thank you. |
The test did not succeed. When using version 3.11.3-SNAPSHOT of the maven liberty plugin we get compilation errors because the generated JAXB and OpenAPI code is not found during compilation. See: liberty-log.txt |
The attached file contains the output using both 3.11.2 and 3.11.3-SNAPSHOT. Please check the output starting at line 43.
From: Cheryl King ***@***.***>
Sent: Thursday, 13 February 2025 16:13
To: OpenLiberty/ci.maven ***@***.***>
Cc: Schutte, M.A.R.O. (Marcel) ***@***.***>; Mention ***@***.***>
Subject: Re: [OpenLiberty/ci.maven] SVT: Application keeps on restarting in Dev mode without making any changes to the app (Issue #1755)
@m-schutte-ohra-nl<https://github.com/m-schutte-ohra-nl> Are you sure the snapshot was used? I see liberty:3.11.2:dev at the top of that log file.
—
Reply to this email directly, view it on GitHub<#1755 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5GDJR2NGRBNL6FN4E225GT2PSY7LAVCNFSM6AAAAABLIJ4O4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJWHEYTCOBUGI>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
[cherylking]cherylking left a comment (OpenLiberty/ci.maven#1755)<#1755 (comment)>
@m-schutte-ohra-nl<https://github.com/m-schutte-ohra-nl> Are you sure the snapshot was used? I see liberty:3.11.2:dev at the top of that log file.
—
Reply to this email directly, view it on GitHub<#1755 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5GDJR2NGRBNL6FN4E225GT2PSY7LAVCNFSM6AAAAABLIJ4O4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJWHEYTCOBUGI>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
…______________________________________________________________________ Deze e-mail en alle daarbij meegezonden bijlagen zijn uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. NN Group N.V. (KvK Den Haag 52387534) en haar dochtermaatschappijen sluiten iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. This e-mail and any attachment sent with it are intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). NN Group N.V. (KvK Den Haag 52387534) and its subsidiaries rule out any and every liability resulting from any electronic transmission.
|
Hi @m-schutte-ohra-nl |
Hi @arunvenmany-ibm, |
Thanks @jvdsandt . I see from the sample in: https://github.com/jvdsandt/liberty-test1 I haven't gotten a clear enough picture to summarize or maybe to recreate exactly, but I believe switching to |
Hi @scottkurz I checked out the sample project and run "mvn compile liberty:dev" together and the project is working fine. Attaching screen recording for reference Screen.Recording.2025-02-28.at.9.51.47.AM.movAttaching the execution logs for both individual and combined executions compile_log_3.11.3.log combined_compile_dev_log_3.11.3.log What I could understand is that when we use separate maven sessions, maven compiler plugin is unable to get the correct configurations for wsimport Here you can see that when executing separately, wsimport sourceRoot is not part of compile configurations. Due to this, source is being recompiled and imported java files are being removed Whereas, when we combine the commands, its taking up wsimport directory and no change in wsimport java files I think we should revert as we cannot always make sure that the customer uses same maven session for all goals CC:- @cherylking |
Hi @m-schutte-ohra-nl @jvdsandt We have removed the changes related to default-compile and a new snapshot has been generated |
Hi @rumanaHaque I have tested on acme-ee11 and acme-ee10 branch and now multiple restart is not happening Attaching before and after logs. Please test and confirm from your end |
We did a retest with our original project and now the server starts up correctly and there are no more multiple restarts. So, it's looking good from our side! |
I retried this with the latest version of acme-ee10, and I don't see the restarts any more. There are no restarts and I also see these messages in the 3.11.3_SNAPSHOT.
|
Just to document where we are right now: with 3.11.3 the problem is solved for the initial startup. However, when we do a code change after this, it remains. Could you please consider the earlier suggestion of introducing a new one letter command for liberty:dev to restart the application(s) by means of an mbean call? Combined with updateTrigger="mbean" this would provide a workable solution for us. |
I have the ACME application - that I imported in my workspace and start using the Start menu of the Liberty Dashboard.
After starting the application - I see that the app was started, but it keeps on restarting and updating, even though I do not make any changes to my application or the configuration.
c:\eclipse-workspace\acme-ee10\acme-ee\AcmeWebEjbEar>mvn liberty:dev
I get some of the following output:
However, if I use the Liberty Tools to do the same thing - I see that the app doesn't start, and immediately, and it keeps on restarting
It goes through this cycle a couple of times before the application is finally available. During these times - if I try to access the app url - I get Context Root not found.
Finally - when I see this message:
then the app is finally stable and I can access the app url.
The text was updated successfully, but these errors were encountered: