I looked through:
git log upstream/2.2.x blobstore/
git log upstream/2.2.x apis/filesystem/
But there are only a few changes and I do not believe that these commits
could cause your symptoms. You could try bisecting to be sure. Given
that my suggested race condition is so easy to fix I would try that
though and in any case it would help the project.
On Fri, Jan 08, 2021 at 05:49:17PM -0000, John Calcote wrote:
> Hi Andrew,
>
> Your theory about another client deleting the file cannot be correct. This is
> an integration test where a single test is running - the container is created
> in /tmp/<some-random-directory>/test-container. The test creates the test
> container in the setup method, uploads several files, manipulates some data,
> and then deletes the entire container in the teardown method.
>
> This is the very first file added, and the test-container itself was created
> milliseconds earlier. There are no other clients running at this time. If you
> look back at the log snippet I pasted, you'll see that the log line
>
> 2021-01-07 20:03:43.576,7964896094167857 {} DEBUG o.j.b.c.LocalBlobStore
> [cloud-normalpri-0] Put blob with key [byHashV1/0001000000000010000020
> B3A2D81C390E0531DBCF0DEC082C4CA96D26F26AA9A26A26E80B5F00FA9F48E3 ] to
> container [test-container]
>
> which is logged by jclouds filesystem impl is logged four times in a row
> (because jclouds is retrying under the covers for us, as we use Payload style
> payloads, which are retriable). Only the last error is logged ultimately, but
> it's clear this error is happening at least four times in quick succession
> before jclouds gives up and throws the exception (which we log).
>
> Just prior to this log line, jclouds logs the creation of the container and
> the test-container directory.
>
> We upgraded from 2.2.0 to 2.2.1 recently and this started happening. The test
> has been in place for years, without seeing this issue. Suddenly, after
> upgrading, it starts happening.
>
> Thanks,
> John
--
Andrew Gaul
http://gaul.org/
