[opensource-dev] User Story: Improved Cache

Kelly Linden kelly at lindenlab.com
Sun Sep 19 13:16:25 PDT 2010

On Sun, Sep 19, 2010 at 12:53 PM, Tateru Nino <tateru at taterunino.net> wrote:

> On 20/09/2010 3:49 AM, Oz Linden (Scott Lawrence) wrote:
> >    On 2010-09-19 10:21, Tateru Nino wrote:
> >> I believe he was referring to the fact that a UUID does not always refer
> >> to the same inworld object. There are instances where an object UUID
> >> will be used more than once.
> >
> > Those would be bugs, by definition.
> Well, it pretty much happens when a sim is down. When that happens,
> objects being instantiated in other sims may be given the same UUIDs as
> objects that are in another sim that is not presently online on the
> grid. When the sim comes back up, the clash in UUIDs is noted, and new
> UUIDs are chosen for any conflicts in that sim. It's been around for
> quite some time, and is a particular pest for someone who wants to refer
> to a server-object by UUID in - for example - an inworld or outworld
> script. Common workarounds involve using an external server for the
> object to register its current UUID to.
> That's been the case since 2005, but being a server-side issue is
> probably out-of-scope here.
> As far as textures go, I believe the way they are handled as assets is
> different to instantiated objects, and that they do not suffer from the
> same issue. Of course, if log in to more than one grid, there's no
> guarantees that a texture with a given UUID in your cache is the same
> texture that you're supposed to be getting. While the space for texture
> UUIDs is very large, they're only unique to a specific grid and clashes
> will inevitably occur over time.
> --
> Tateru Nino
> http://dwellonit.taterunino.net/
I'm not sure how what you describe could happen. There is no system in place
to detect UUID clashes, especially between different regions/sims, and
nothing that notes them and then replaces them. The way you describe it
makes it sound like there is a central service that hands out UUIDs as
needed and when a region that has been down comes back up it may have UUIDs
that have been given out that need to be corrected. That isn't how UUIDs
work - each process generates its own UUIDs as needed from an algorithm that
attempts to minimize the already slim chance of a collision.

* Rezed objects are given a new UUID (though they will still reference the
'original asset id' for some internal tracking server side)
* An object that is out in the world could be modified and will retain its
same UUID (and local ID) even though the object changes. So it is true that
an object cache based purely on UUID could show stale data - this is a
unique case for inworld objects only. Not inventory, textures, sounds,
gestures, notecards, scripts or even landmarks. All of those will have a
unique ID that never changes.
* The only way I can think of right now to force a UUID 'collision' is to
bring up a duplicate of a region so that the same region is brought up in
two places at the same time, including copying all the content. This is
something that shouldn't happen, and even if we have to we do have a system
to generate new IDs for parcels and content.

* If you have more details about UUID collisions happening, let us know. It
would definitely be a bug and we would want to look into it.

 - Kelly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100919/e448fdde/attachment.htm 

More information about the opensource-dev mailing list