Re: [Plastic-devs] plastic file ref

[R H. <ric...@co...>]

On Tue, 4 Jul 2006, 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, 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
>

apologies, since I wandered off to something else for a while... haven't 
tested it but I'm sure this is the same (threading issue) for me. It 
occurs to me though that unless all apps check all returning messages to a 
general broadcast, this could be messy. Perhaps file cleaning might be 
better placed in the hub... ?

Richard