If you use the RegionScopedBlobStore and don't call the getBlobStore()
method, just use the ones that require the region parameter, the "implicit
region supplier" should not be called and you shouldn't see the warning.

I don't know if that supplier is invoked in other parts of the swift code,
though, so I can't tell 100% that this will remove the warning :)

On Apr 18, 2017 5:55 PM, "Ryan Shoemaker" <ryan.shoema...@enterprisedb.com>
wrote:

> Thanks Ignasi.  So, it sounds like if I specify a region in our code, then
> these warnings will go away. Would I have to use
> RegionScopedBlobStoreContext?
>
> --Ryan
>
> On Apr16 5:39 AM, Ignasi Barrera wrote:
>
>> Hi Ryan,
>>
>> The warning you're getting is particular to OpenStack. jclouds
>> provides several internal classes to provide the existing regions,
>> region ids, their corresponding URIs, etc. A group of those classes is
>> what we call the "implicit" location suppliers, that just return the
>> information of one location (region, szone, whatever), that will be
>> used if the user does not specify a region when interacting with the
>> cloud provider.
>>
>> Those implicit location suppliers are always initialized, and the
>> default implementation looks for a region that has the same URI as the
>> provider endpoint. In the case of OpenStack, the endpoint is always
>> the Keystone endpoint, and that default logic does not "fit well",
>> thus the warning you get. It just says that there is no better way to
>> determine a "default/fallback" region than picking the first one.
>>
>> To be more specific, jclouds loads a Map of known region ids to
>> endpoints, and then looking for the default region, it inspects that
>> map and looks for the endpoint configured when creating the context.
>> In the case of OpenStack, that map is built by inspecting the Service
>> Catalog returned by Keystone, so the right endpoint for the service
>> (swift, nova, etc) is configured for each region. That is done by
>> using a custom implementation of the supplier that builds the
>> mentioned map. You can read the implementation used for Keystone here
>> [1]. I hope reading it will make more sense and show why you get he
>> values you get in the map.
>>
>> Regarding that "FOO" key. It is just a convenience use of a Guava
>> cache. There is an utility method to memoize a Supplier for a given
>> amount of time, and short-circuiting any AuthenticationException to
>> avoid having the supplier call the provider APIs when we already know
>> authentication will fail (and this preventing potential account
>> locks). The implementation of that supplier internally uses a Cache to
>> deal with concurrency. It will actually hold just one value (the
>> memoized one), and completely ignore any key (FOO) that is provided
>> when client code asks for the cached value. I couldn't say why the
>> Guava's LoadingCache is used instead of manually implementing the
>> locking, or why the "Suppliers.memoizeWithExpiration" isn't used
>> instead, which is thread-safe too.
>>
>>
>>
>> HTH!
>>
>> I.
>>
>>
>> [1] https://github.com/jclouds/jclouds/blob/master/apis/openstac
>> k-keystone/src/main/java/org/jclouds/openstack/keystone/v2_
>> 0/suppliers/LocationIdToURIFromAccessForTypeAndVersion.java
>>
>> On 14 April 2017 at 00:28, Ryan Shoemaker
>> <ryan.shoema...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> I've been seeing this warning pop out of my code for awhile and have
>>> finally
>>> gotten around to investigating it:
>>>
>>> org.jclouds.location.suppliers.implicit.GetRegionIdMatchingP
>>> roviderURIOrNull|_ThreadID=10;_ThreadName=Thread-2;|failed
>>> to find key for value http://keystone.domainname.com:5000/v2.0 in
>>> {uk=http://swift.domainname.com:8080/v1/AUTH_813b8f3ec69a460
>>> caf6efc2ea32bafb8};
>>> choosing first: uk
>>>
>>> Why is there a mismatch between the uri and what's in the map?  The uri
>>> is
>>> pointing to our keystone service and the map contains our swift service.
>>> The actual log message appears to be coming from:
>>>
>>> org.jclouds.suppliers.SupplyKeyMatchingValueOrNull.get()
>>>
>>> As I was debugging this, I noticed this code on the stack:
>>>
>>> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAut
>>> horizationExceptionSupplier.get()
>>> (line 150)
>>>
>>> @Override
>>> public T get() {
>>>     try {
>>>        return cache.get("FOO").orNull();
>>>     } catch (UncheckedExecutionException e) {
>>>        throw propagate(e.getCause());
>>>     } catch (ExecutionException e) {
>>>        throw propagate(e.getCause());
>>>     }
>>> }
>>>
>>> What's going on with that key name? Here's the calling code in my app -
>>> we
>>> have a method to get the storage context:
>>>
>>> public BlobStoreContext getStorageContext(@Nullable String tenant) {
>>>      String providerOrApi = ProviderFactory.getSupportedProviderFromId(
>>>          user.getServiceProvider()).getObjectStorageProvider();
>>>      Properties overrides = new Properties();
>>>      overrides.setProperty(KeystoneProperties.CREDENTIAL_TYPE,
>>> CredentialTypes.PASSWORD_CREDENTIALS);
>>>
>>>      ContextBuilder builder = ContextBuilder.newBuilder(providerOrApi)
>>>          .credentials(tenant + ":" + serviceLogin, servicePassword)
>>>          .endpoint(identityServiceEndpoint)
>>>          .modules(ImmutableSet.of(new JDKLoggingModule(), new
>>> JschSshClientModule()))
>>>          .overrides(overrides);
>>>
>>>      return builder.buildView(BlobStoreContext.class);
>>> }
>>>
>>> And then code grabs the context and calls getBlobStore() on it - this is
>>> what causes the warning to be printed:
>>>
>>> BlobStoreContext storageContext = getStorageContext(firstTenant);
>>> if (storageContext != null) {
>>>      BlobStore blobStore = storageContext.getBlobStore();
>>>      etc...
>>>
>>> We're running jclouds 2.0.0 on OpenStack.  Despite the warning,
>>> everything
>>> appears to work fine. Thanks! --Ryan
>>>
>>
>

Reply via email to