tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pid *" <>
Subject Re: Patch suggestion
Date Sun, 11 Apr 2010 13:56:22 GMT
On 11 April 2010 00:17, Konstantin Kolinko <> wrote:

> 2010/4/10 Pid <>:
> > In lieu of of a Bugzilla enhancement (and hoping that I have the right
> end
> > of the stick).
> >
> If I guess your intention correctly,
> you want to prevent deployment of a war file that is still open for
> writing?

Yes. I should have been more explicit. The patch was prompted by a message
to the User list a little while ago.
The user uploaded a .war directly to the webapps directory and was surprised
to discover Tomcat throwing exceptions when it tried to deploy the
incomplete file.

> If that is the case, then asking for modification time probably will
> not work. The file properties in the file system are usually not
> updated that frequently. Though that might differ between OSes. Also,
> if the file is being transmitted over network, the update frequency
> depends on how fast is the connection that is used to upload the file.
> As far as I remember my experience, I think that a file that is still
> being written can be detected by asking its length. Such files can be
> listed by shell to be of length 0.
> Needs more research and some summary across OSes though.

I will test Linux, OSX.

> At least, if the war file is of length 0 it can be safely skipped for
> obvious reasons.
> >                try {
> >                    Thread.sleep(500);
> >                }
> I do not like unconditionally sleeping for every file. 20 wars = 10
> seconds to sleep, even if none of them is going to be deployed

Fair enough.  If the file size detectably zero, then calling continue would
be sufficient to prevent the attempt at deploying the war. I think it would
be good to log a warning here too.


> Time could be compared against the interval between autoDeploy cycle
> runs, if it is enabled, but there are also explicit calls from the
> manager web application that must not be broken.
> The above is from my mind/memory. I have not researched it for this case.
> Best regards,
> Konstantin Kolinko
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message