Sticky state for containers (?) when switching back and forth between the default and virtual file systems

Description

Still working on a good description. Here's a bes command file that shows the error:

The response should be to show the fnoc1 DDS and then two copies of the CSV file's DDS, but instead the second request (of the three) returns fnoc1's DDS.

Questions:

  • Is this a fail with the container, the container storage or the definitions?

  • Is this a real problem - the OLFS never issues requests like this? It seems we see this sticky behavior in a real running server when using the web interface, but I'm not able to reproduce that now

Environment

None

Activity

Show:
James Gallagher
January 8, 2019, 12:50 AM

The bug is here in the define command:

If no store is named in the <define> command, it searches all of the stores, in the order they were added. If two containers use the same name in different stores, the one that the define command finds will depend on the order in which the persistent stores were added to the server. That explains why differing configurations yield different results.

Fix this by making all of the code that defines stores that use the Volatile store actually use the same store (in a way that the system would work if we were storing stuff in a RDB).

Then develop a refactoring/redesign plan to address some of this issues with the complexities of the Catalog/Container/ContainerStorage/Definition commands and objects. See notes for 1/7/2019

James Gallagher
January 8, 2019, 1:01 AM
Edited

Modifying the commands we send so they delete the containers does not fix the issue:

results in the error: Unable to delete container. The container 'c1' does not exist in container storage 'catalog' because the catalog 'c1' has been made in the storage space 'RemoteResources' but the deleteContainer command was called without the space attribute and used the default space (named 'catalog'). The client does not know that the server is using different spaces for these containers, however, so it has no way of knowing that it should use the space attribute.

Changing the <deleteContainer command so it uses 'space="RemoteResources"' does fix the problem.

James Gallagher
January 8, 2019, 10:50 PM

Implemented a fix. I added a method to the BESContainerStorageList that searches all of the stores and deletes every instance of a container. This will work with the OLFS, but is not how the BES was really intended to work.

For some reason, the daemon does not work while besstandalone does.

James Gallagher
January 12, 2019, 12:26 AM
Edited

Regarding the previous comment:

Implemented a fix. I added a method to the BESContainerStorageList that searches all of the stores and deletes every instance of a container. This will work with the OLFS, but is not how the BES was really intended to work.

For some reason, the daemon does not work while besstandalone does.

This is a problem that appears to be present on OSX only, or may have to do with the libcurl version. OSX uses:

while Centos 7 (where this code works) uses:

Close this ticket and open a new report.

Assignee

James Gallagher

Reporter

James Gallagher

Labels

Fix versions

Time remaining

0m

Story Points

3

Affects versions

Epic Link

Priority

High
Configure