Clean task issues libertyDev daemon error handler gradle #850
Comments
|
Separately, I killed all of the procs and was able to clean things manually I did not run libertyDev or libertyRun... (I may have run libertyStart) And now I'm getting this: Now, normally it will copy my Seems to me like whether or not I do the right thing in the right sequence, it should still never fail in a way that makes it impossible to even see Then I tried running a deploy, firstly ensuring there are NO current running daemons or anything that could lock, nor server up: |
|
....Okay. So that didn't work and now it doesn't want to redo this. I personally, did NOT wipe server.xml from that destination. Again, seems like it wipes it or gets it into a state and then it wants to give up and never put that server.xml file in again, and apparently it is even a requirement to check the status via So I'll try a |
|
Okay...so, in this case it was actually me being silly and server.xml in my tree was in the wrong location... However, there does seem to be some lack of grace in the error handling chain, and I have seen this pop up completely randomly requiring a Then, apparently Sorry...I wish I could provide a thorough minimal reproducible test case... But this problem does happen unreliably across configurations that otherwise normally work well most of the time. My only guess, it is probably triggered by the file locks. If you're on Linux that problem I'm sure doesn't exist, but on Windows it does. Which is fine, I just would not expect it to put my build into an unworkable state requiring a |
|
@sreich I have some thoughts on how I can make |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey,
I've got some questions regarding how the server start/stop is handled, particularly for
libertyDevand Gradle...I see that libertyRun expects to be run with --no-daemon according to docs for it, is the same true for libertyDev as well?
You can see the server
I think this is actually #827 .... But I wanted to be a bit more concise here, and probably will close the other issue in favor of this.
The issue I ran into, I suspect it may have been what I've run into with previous clean state issues...
The server script does not seem to be able to gracefully handle this (RC=23, I couldn't find documentation on this error code in your
server.bator in the docs). So that error number must be interpreted indirectly elsewhereDug further into it and found an open java proc handle to
\build\wlp\bin\tools\ws-javaagent.jarwhich was preventing me from wiping it manually. Killing them all fixed thatCan you suggest some methods for me to combat this sort of issue, or perhaps potential changes you could do on your end to help mitigate/ease this issue?
(liberty gradle 3.6.2)
The text was updated successfully, but these errors were encountered: