[
https://issues.apache.org/jira/browse/JCLOUDS-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043517#comment-14043517
]
Alex Heneveld commented on JCLOUDS-615:
---------------------------------------
the issue is in the two `RetryOnRenew` classes, they check for the presence of
the string "lease renew" in them.
that is not a good idea, theoretically because these strings may be
internationalized by servers, and servers will purge their cache and so should
not be expected reliably to recognise valid expired leases, and practically,
because some impls (softlayer for one) do not return that text when an expired
lease is used.
the fix is trivial, remove the check for that string in the two instances of
the above class.
if someone needs a workaround, or would like to add live tests for jclouds
which use tokens with short-lived leases, you can find both in
https://github.com/apache/incubator-brooklyn/pull/19 as referenced in
https://issues.apache.org/jira/browse/BROOKLYN-6
> jclouds does not re-auth on Swift early-token-expiry
> ----------------------------------------------------
>
> Key: JCLOUDS-615
> URL: https://issues.apache.org/jira/browse/JCLOUDS-615
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
> Affects Versions: 1.7.4
> Environment: softlayer swift, also reported on hp swift
> Reporter: Alex Heneveld
>
> I create a blobstore against swift in the usual way. It works for a while
> but then (after many hours) it starts to return 401 Unauthorized (again for
> many hours) and then it works again.
> It appears:
> * Jclouds does not re-negotiate the token immediately if it is expired
> server-side, but it does on cache expiry (from my observations)
> * Swift can sometimes expire tokens earlier than their advertised expiration
> date (according to [1])
> Desired behaviour: I think jclouds should attempt to re-negotiate the auth
> token if it gets an unauthorized exception using apparently-valid credentials.
> I've observed this against Softlayer [2]. I have also seen this reported
> against HP [1].
> We are looking at a workaround which retries in user space, also referenced
> at [2], but fixing this in jclouds would be great.
> I also note the cache expiry time is hard-coded at 23 hours. All the swifts
> I have seen claim 24h expiry time so this is okay most of the time, but it is
> a hack and not guaranteed. The REST response includes the expiry time
> explicitly so a related improvement I notice would be to use this (minus 1m
> or so...) when setting the cache value. (But the token can still expire
> sooner than this advertised expiry time -- IOW the main bug reported here is
> independent of this cache expiry time issue.)
> [1]
> https://community.hpcloud.com/question/1477/about-authentication-token-expiration-when-using-jclouds-api-access-hpcs-object
> [2] https://issues.apache.org/jira/browse/BROOKLYN-6
--
This message was sent by Atlassian JIRA
(v6.2#6252)
