You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Joseph Laudadio (JIRA)" <ji...@apache.org> on 2015/04/06 19:51:12 UTC

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

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

Joseph Laudadio commented on JCLOUDS-615:
-----------------------------------------

As of today, I have seen this issue re-occur with 1.9.0. 

> 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.3, 1.8.1
>         Environment: softlayer swift, also reported on hp swift
>            Reporter: Alex Heneveld
>              Labels: swift
>
> 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.3.4#6332)