Adam Scarborough wrote:
Adam Scarborough wrote:
Hi
I was wondering if anyone can help
We have an issue with with tomcat7 deploying wars on server2k8 which is
quite perplexing:
Essentially the normal and desired procedure is that we build a new set of
wars (usingjenkins) which are then moved to an output directory, this
change in the output directory is detected by puppet, which then overwrites
the war file in the tomcat webapps folder and restarts the tomcat7 service
(we have hot deployment disabled and deployonstartup enabled) On startup
tomcat unpacks the war files to the folder inside the webapps directory. This
happens 95% of the time.
However
We noticed an issue occasionally that the new version of the webapp
would not be deployed after starting tomcat. At this point we noticed some
access denied errors (sometimes) when the deployment failed. At this point
we thought this may be due to windows file locking behaviour, At this point
we enabled antiResourceLocking in the hopes that these would go away -
They did however we still have a seemingly separate issue where webapps
deploy into the temp folder,and the log reports successful deployment with
no errors. However the version in the webappsfolder is not updated and the
previous version of the webapp is brought up by tomcat. We havebeen
unable to locate anything in the logs which might tell us what is going on.
Any help would be appreciated
Just a little question to describe the issue further : are all of the above
local
directories on that server, or are there network shares involved ?
Puppet pulls the war files from a remote location (successfully). After this
point all files are under c:\tomcat7\ (c:\tomcat7\webapps and c:\tomcat7\temp)
Ok, that would seem to exclude what I'm saying below, which was the reason why
I was asking.
Over a long time, I have noticed that in some ill-defined circumstances the very first
access to a Windows network "share" is unsuccesful, while all accesses after that succeed
without further problems. I suspect that this may be due sometimes to some Windows "name
resolution" which fails within some time limit. I have never gone to the bottom of it,
but it is such a real occurrence that I have taken the habit, in critical software, to
make a first dummy access which can fail or not (and is ignored), followed by the real one
that counts and which then always works (or not, but then there is a real problem).
But again, that seems to be excluded here, so back to the original issue..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
