[jira] [Commented] (JCLOUDS-615) jclouds does not re-auth on Swift early-token-expiry

["Alex Heneveld (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCLOUDS-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043355#comment-14043355 ] 

Alex Heneveld commented on JCLOUDS-615:
---------------------------------------

i have just found `RetryOnRenew` which looks like it should solve this very issue, but for some reason seems not to be

> 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)