On 11 April 2010 00:17, Konstantin Kolinko <knst.koli...@gmail.com> wrote:
> 2010/4/10 Pid <p...@pidster.com>:
> > 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.
p
> 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: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
--
pidster.com
