Unexpected calls to custom ArResolver _CreateDefaultContextForAsset for uriSchemes list longer than 1

Community USD
,
1

Hi,

I have a query around the calling of _CreateDefaultContextForAsset by the resolver.cpp implementation and how it is mapping scheme to resolver.

I’ve recently noticed some unexpected behaviour from our in-house Usd asset resolver. It’s a uri scheme based resolver with perhaps the unusual difference that is has multiple schema registered for it in the pluginInfo.json file. E.g.

“uriShemes”: [“aaa”, “bbb”, “ccc”]

If CreateDefaultContextForAsset is called E.g.

ctx = pxr.Ar.GetResolver().CreateDefaultContextForAsset(url)

then our implementation’s _CreateDefaultContextForAsset is called as many times as the length of the uriSchemes list with the same url. I’ve been testing this with 23.11 but I don’t think the implementation has changed significantly in newer versions.

I realise that the docs say the following:

Note that this means this method may be called with asset paths that are not associated with this resolver. For example, this method may be called on a URI/IRI resolver with a non-URI/IRI asset path. This is to support cases where the asset at assetPath references other assets with URI/IRI schemes that differ from the URI/IRI scheme (if any) in assetPath.

but it’s called multiple times for the same uri.

The implementation of _InitializeURIResolvers creates a map of scheme against resolver causing our implementation to appear multiple times. Many parts of resolver.cpp iterates this map thereby introducing unnecessary calls to not just the method in question but others (e.g. GetCurrentContext, RefreshContext).

The problem for our implementation is that without an already bound context it can be forced to do a lot of work when called. We can introduce some temporary thread specific cache to avoid duplicate work within some limited time frame but it seems reasonable for any custom implementation to only be called once for any uri.

Would be interesting to get people’s thoughts. Do we just need to work around this behaviour or
does the current behaviour for resolvers with multiple registered schema seem problematic ?

Jonathan

2

Hi @JStroudBrahma , we agree that’s unnecessary and undesirable! Would you please file an Issue on this, and we’d also be interested in a PR that changes those iterations into iterating over unique resolvers rather than schemes.

Cheers,
–spiff

3

Thanks @spiff. I’ll report an issue. Might be some time before I can get around to crafting a PR though.

Jonathan