Re: [Plastic-devs] plastic file ref

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

On Tue, 4 Jul 2006, Mark Taylor wrote:

> On Tue, 4 Jul 2006, 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... ?
>
> I don't think that makes sense, since as far as the hub knows the
> URL sent in the loadURL message is just a string.  The hub doesn't have
> enough information to work out that it's the name of a temporary file
> which needs to be deleted once it's no longer in use.  It's only
> likely to be the sending application which knows whether that's
> the case or not.
>
> To prevent this kind of confusion though, maybe there should be something
> explicit in the message definition for loadURL which says that the URL is
> only guaranteed to remain usable between when the message is sent and
> when the receiver provides the return value (or possibly some other
> policy we agree on).
>
> Mark

Wouldn't work for me either now I think about it - I'm relying on a 
persistant copy of the file somewhere. I guess it's up to me to make a 
copy, but topcat etc could get very bored waiting for replies to come 
back. If you were sending to a specific receiver, might it be possible 
to transfer ownership?

Richard