On 12 April 2010 11:25, Pid * <p...@pidster.com> wrote:
> 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.
>
I almost made sense there, thread "Context.xml being deleted".
> 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
>
--
--
pidster.com
