On Tue, May 4, 2010 at 10:38 AM, Hiranya Jayathilaka <[email protected]>wrote:
> > > On Tue, May 4, 2010 at 9:57 AM, Rajika Kumarasiri <[email protected]> wrote: > >> >> >> On Mon, May 3, 2010 at 9:45 PM, Hiranya Jayathilaka <[email protected] >> > wrote: >> >>> Rajika, >>> >>> On Mon, May 3, 2010 at 5:30 PM, Rajika Kumarasiri <[email protected]>wrote: >>> >>>> >>>> >>>> On Mon, May 3, 2010 at 4:42 PM, Hiranya Jayathilaka < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Mon, May 3, 2010 at 4:24 PM, Rajika Kumarasiri <[email protected]>wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, May 3, 2010 at 4:15 PM, Hiranya Jayathilaka < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Rajika, >>>>>>> >>>>>>> On Mon, May 3, 2010 at 3:44 PM, Rajika Kumarasiri >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> I'd like to hear your feedback before I provide you with a patch for >>>>>>>> the issue[1]. First it's an important improvement to vfs-transport. >>>>>>>> I think we can fix the problem by introducing an optional parameter >>>>>>>> for the vfs transport , "transport.vfs.TempFileName". >>>>>>> >>>>>>> >>>>>>> Why does the user has to specify this? >>>>>>> >>>>>> No, it should be an indicator ( a boolean) which suggest to use a temp >>>>>> file or not. >>>>>> >>>>> >>>>> Why? Writing to a temp file and then moving the file to the appropriate >>>>> place is the safest approach for handling file uploads. >>>>> >>>> >>>> Currently when uploading a file using the vfs transport sender it'll use >>>> the provided file name (as a part of the url) as the file name at the ftp >>>> server. As you can see this has a problem if one on the ftp server side >>>> starts to process the file at the same time since the file is not fully >>>> transferred. >>>> To avoid this we'll use a temporary file(if the user need a one) at the >>>> ftp server for uploading the file, once uploading is completed we can move >>>> that temp file to the original one. >>>> >>> >>> IMO this has to be the default behavior. Almost all the time user does >>> not have any control over how and when the receiving application reads files >>> from the file system. So there is always a chance that the receiving >>> application may try to read from a file while Synapse is writing to it. So >>> Synapse should always anticipate this scenario and it should always do the >>> right thing, which is to write the content to a temp file and then move it >>> to the correct location. >>> >>> For instance we might run into this problem with Synapse itself. Imagine >>> we have two Synapse instances. One is writing files to a given directory and >>> the other instance is polling on that directory. Without the above described >>> approach the second Synapse instance may pick up a half done file. >>> >>> If you really need to make this configurable, I would still say make this >>> the default behavior and provide a way to turn it off if required. >>> >> >> I am not sure if we need to make this the default behaviour since this has >> some performance implications. >> > > We'll wait for other's opinion on this. BTW with a single user specified > temp file name how are you going to support concurrent file uploads to the > same location? > As I told earlier it's not the file name but a boolean flag which indicate to use a temp file. The name of the temp file actually a java temp file. Rajika -- http://rajikak.blogspot.com/
