Liberty reports various read errors when deploymentType=dropins is used
Azquelt opened this issue · 3 comments
Issue Overview
Occasionally, when using deploymentType=dropins, Liberty will fail to start the application, usually citing some kind of zip file read error trying to read the application archive.
Expected Behaviour
The application should start
Current Behaviour
The application does not start
Steps To Reproduce
- Use
deploymentType=dropins - Put tests into your product CI and wait for one of the tests to fail randomly in a build eventually.
Additional Information
I suspect this is caused by liberty reading the application archive before shrinkwrap has finished writing it. I would suggest writing the application to a temp location first and then moving it into the dropins directory afterwards.
Alternatively, liberty could be changed to cope with seeing an incomplete archive in the dropins directory.
Update: although I still think the incomplete application archive could be a problem and I will still submit a pull request for it, in my case I believe the cause was that apps in dropins can be in INSTALLED state before liberty starts them but the container assumes that an app in INSTALLED state has failed to start.
Update: confirmed that both cases described above can occur and have similar symptoms. Both fixed by #21
In https://wasrtc.hursley.ibm.com:9443/jazz/web/projects/WS-CD#action=com.ibm.team.build.viewResult&id=_Vbam0H4FEeiACNpEFzHAag&tab=com.ibm.team.build.web.ui.internal.editors.result.test.TestProvider
I see:
java.lang.Exception: Errors/warnings were found in server Config12TCKServer logs:
[7/2/18 18:45:30:517 UTC] 000000d8 com.ibm.ws.webcontainer.extension W SRVE0190E: File not found: /ArquillianServletRunner
Where ArquillianServletRunner is the ContextRoot that is used to run tests.
After some more investigation, it looks like this problem was actually caused by the arquillian container seeing the app in INSTALLED state before liberty begins starting it and assumed that it had failed to start.
After further investigation, it looks like both problems can occur (liberty reading a half-written app and arquillian seeing the app in INSTALLED state before it's begun to start) and both cause similar failures