Re: [Plastic-devs] plastic file ref

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

R Holbrey wrote:
> 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
>
>   


We've always worked on the principle that the hub shouldn't understand 
the messages, so it has no way of knowing which arguments apply to files 
that need cleaning up.
That said, we could consider having the hub offer some kind of "create 
temporary file" service, but my instinct is against it...I don't see how 
we could get it to work (and anyway, it won't fix my example SIAP 
service issue).

J