jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Gaul (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCLOUDS-615) jclouds does not re-auth on Swift early-token-expiry
Date Mon, 26 Oct 2015 03:42:28 GMT

     [ https://issues.apache.org/jira/browse/JCLOUDS-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Andrew Gaul updated JCLOUDS-615:

We have removed the legacy "swift" provider.  Please test the modern "openstack-swift" provider
which includes many fixes and enhancements and open a new issue if your problem persists.

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

View raw message