Alex Heneveld created JCLOUDS-615:
-------------------------------------
Summary: 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)
