Re: [Plastic-devs] plastic file ref

[Mark T. <m.b...@br...>]

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

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/