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/01/22 22:18:34 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=14288241#comment-14288241 ]
Joseph Laudadio commented on JCLOUDS-615:
-----------------------------------------
I'm seeing this issue with 1.8.0. https://issues.apache.org/jira/browse/JCLOUDS-589 says it's fixed in 1.8.0 so it would seem the fix for 589 didn't address this entirely.
> 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)