Re: [Plastic-devs] plastic file ref

[John T. <jon...@gm...>]

Mark Taylor wrote:
> On Tue, 4 Jul 2006, B Walshe wrote:
>
>   
>> Quoting Mark Taylor <m.b...@br...>:
>>
>>
>>     
>>> my best guess for what's happening here is that TOPCAT is writing the
>>> temporary file (in /tmp/plastic*.vot, as John says), but then deleting
>>> it before Eirik has read it.  What it does for a table broadcast/transmit is:
>>>
>>>    1. Write a VOTable representing the current state of the table to
>>>       be sent to a temporary file
>>>    2. Send the loadFromURL message
>>>    3. Wait for the response object from the hub describing which
>>>       listeners succeeded and which failed to load the table
>>>    4. Delete the temporary file
>>>
>>> So you might well see what you are seeing if you are replying to the
>>> loadFromUrl (returning a true/false error status) before you've actually
>>> consumed the temporary file.
>>>
>>> Is that what you're doing?
>>>
>>> Mark
>>>
>>>       
>> Yes, I think I might be sending the response before I load the table. I 
>> have my message handler and table loader running in separate threads.
>>     
>
> that would make sense then - hope it's not too difficult for you to 
> work round it.  There's nothing in the message definition that says 
> how persistent that URL should be, 
Maybe there should be some clarification.  It seems to me that keeping 
the table there until all the apps respond with "OK" is a reasonable 
thing to do for temporary files generated by the sender. 

I'm not sure what to do if the sending application didn't generate the 
file or if it sends the message asynchronously. 
If the sender didn't create the file it has no control over how long it 
will persist (for example, the file may have been created by a SIA 
service), and if the sender sends the message asynch it has no way of 
knowing when the file has been picked up by the receivers.

Is it good enough for us to say that the files should be considered 
temporary and loaded (or copied) "in good time", certainly before the 
receiver  responds with  "OK"?




> but I like to clear it up quite 
> soon to prevent overuse of temporary disk space.  If it's causing
> problems which are difficult to solve for you or Richard as message 
> receivers I could reconsider how TOPCAT goes about this.
>
> Mark
>
>