On 11 April 2010 14:56, Pid * <p...@pidster.com> wrote:
>
> 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.
>
I suspect that the thread on the Users list "" is in the same category as
the problem I describe.
> 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.
>
When uploading a war of 5Mb to an RHL linux server, a simple class which
monitors (every 100ms) the size of the file reports the current file size
changing as the bytes arrive in chunks of 16k, the file size remains the
same for 5-8 runs of the loop either before enough packets have arrived, or
the file system updates.
Which means waiting for maybe 1000ms to see a change, which isn't ideal as
KK points out.
p
> 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
>
--
--
pidster.com
