Crash when calling submodel GET API after multiple users operating the same AAS

[hiroaki-yoshii]

Overview

When multiple users access one AAS, the submodel GET API hangs due to a certain pattern of access, does not return a response, and also does not output logs. the problem is not resolved even after retrying, because a data integrity problem may be occurred .

Specifically, if you call the BaSyx AAS Repository API in the order below, no response will be returned in step 4.

1. User A calls the API to get AAS "C" and retains its contents
2. User B calls the API to add submodel "D" to AAS "C"
3. User A modifies some of the results in 1. and calls AAS "C" modification API.
4. Call API to get submodel "D" of AAS "C" This seems to be because the property .submodels in AAS GET API reponse is different from the submodel database.

Impact of this issue

Applications using BaSyx cannot be deployed in an environment with multiple users, therefore it is not possible to move from Proof of Concept to the next step.

Steps to reproduce

Environment

• BaSyx version: 1.5.1
  • backend: MongoDB
• MongoDB: 6.0.13
• Docker: 24.0.7

Docker compose settings

version: "3.9"
services:
  aas-registry:
    image: eclipsebasyx/aas-registry:1.5.1
    ports:
      - 8082:4000
    volumes:
      - "${REGISTRY_CONFIG_PATH}:/usr/share/config"
  aas-server:
    image: eclipsebasyx/aas-server:1.5.1
    ports:
      - 4001:4001
    volumes:
      - "${REPOSITORY_CONFIG_PATH}:/usr/share/config"
  mongo:
    image: mongo:6.0.13-rc0
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: pass
    ports:
      - 27017:27017

A sample procesure

1. A User gets a AAS (ID: https//example.com/aas/0).
   API operation: GET /aasServer/shells/https%2F%2Fexample.com%2Faas%2F0

response json

```json { "conceptDictionary": [], "identification": { "idType": "Custom", "id": "https//example.com/aas/0" }, "idShort": "test", "dataSpecification": [], "modelType": { "name": "AssetAdministrationShell" }, "asset": { "identification": { "idType": "Custom", "id": "https//example.com/asset/0" }, "idShort": "test_asset0", "kind": "Instance", "dataSpecification": [], "modelType": { "name": "Asset" }, "embeddedDataSpecifications": [] }, "embeddedDataSpecifications": [], "views": [], "submodels": [] } ```

2. A User add a Submodel (idShort: test_sm1) to a AAS (ID: https//example.com/aas/0).
   API operation: PUT /aasServer/shells/https%2F%2Fexample.com%2Faas%2F0/aas/submodels/test_sm1

request json

```json { "parent": { "keys": [ { "idType": "Custom", "type": "AssetAdministrationShell", "value": "https//example.com/aas/0", "local": true } ] }, "identification": { "idType": "Custom", "id": "https//example.com/submodel/1" }, "idShort": "test_sm1", "kind": "Instance", "dataSpecification": [], "modelType": { "name": "Submodel" }, "embeddedDataSpecifications": [], "submodelElements": [ { "parent": { "keys": [ { "idType": "Custom", "type": "Submodel", "value": "https//example.com/submodel/1", "local": true } ] }, "identification": { "idType": "Custom", "id": "https//example.com/submodelelement/0" }, "idShort": "test_element0", "kind": "Instance", "valueType": "integer", "modelType": { "name": "Property" }, "value": 12347 } ] } ```

3. A User change a AAS's idShort property (ID: https//example.com/aas/0) based on procesure 1. But, submodels property is empty because of calling AAS GET API before calling Submodel PUT API.
   API operation: PUT /aasServer/shells/https%2F%2Fexample.com%2Faas%2F0

request json

```json { "conceptDictionary": [], "identification": { "idType": "Custom", "id": "https//example.com/aas/0" }, "idShort": "hoge", "dataSpecification": [], "modelType": { "name": "AssetAdministrationShell" }, "asset": { "identification": { "idType": "Custom", "id": "https//example.com/asset/0" }, "idShort": "test_asset0", "kind": "Instance", "dataSpecification": [], "modelType": { "name": "Asset" }, "embeddedDataSpecifications": [] }, "embeddedDataSpecifications": [], "views": [], "submodels": [] } ```

4. User cannot access a submodel (idShort: test_sm1) data.
   API Operation: GET /aasServer/shells/https%2F%2Fexample.com%2Faas%2F0/aas/submodels/test_sm1/submodel

[FrankSchnicke]

Thanks a lot for pointing out this issue. Can you also provide the configuration files used in your setup?

Is there any reason why you are still using the 1.X Components of BaSyx? With the update of the meta model & REST API by the IDTA to V3, they are becoming obsolete.

The new components conforming to the newest specifications by IDTA can be found here: https://github.com/eclipse-basyx/basyx-java-server-sdk

[hiroaki-yoshii]

The configs of aas registry and aas server are as follows:

• aas registry
  registry.properties

registry.backend=MongoDB

registry.id=aas-registry

registry.authorization=Disabled

registry.taggedDirectory=Disabled

context.properties

``` contextPath=/registry contextHostname=localhost contextPort=4000 accessControlAllowOrigin=* ```

mongodb.properties

``` dbname=admin dbconnectionstring=mongodb://root:pass@mongo.local:27017/ dbcollectionRegistry=registry ```

• aas server
  aas.properties

aas.backend=MongoDB

aas.source=

aas.id=aas-server.local

aas.aasxUpload=Enabled

registry.path=http://aas-registry.local:4000/registry/

aas.authorization=Disabled

aas.delegation=Enabled

context.properties

``` contextPath=/aasServer contextHostname=aas-server.local contextPort=4001 accessControlAllowOrigin=* ```

mongodb.properties

``` dbname=admin dbconnectionstring=mongodb://root:pass@mongo.local:27017/ dbcollectionAAS=assetadministrationshells dbcollectionSubmodels=submodels dbcollectionRegistry=registry ```

I would like to migrate to V3 in the future, but I am hesitant to do now due to the following reasons:

• Lack of backward compatibility for some features, such as the absence of an API for uploading aasx files.
• Concerning the Docker image, only tags under development are available such as 2.0.0-SNAPSHOT. Therefore, in my understanding, a stable version has not been released yet.

[FrankSchnicke]

We will take a look based on your configuration and come back to you.

In regard to the migration:

• Backward Compatibility: We're adding this API at the moment, the PR will be merged most likely this week. Is there anything else that you're missing?
• Stable Version: We plan on releasing the very first milestone release this month. Thus, there would be a stable release.

[mdanish98]

Hi @hiroaki-yoshii ,

We tried to reproduce the issue based on the configurations and steps you provided, but we couldn't reproduce it at our end.

• Is the issue occurring always or sometimes?
• Please provide additional information such as logs of the AAS Server and AAS Registry.

[hiroaki-yoshii]

@mdanish98

Sorry, the json content in step 3(calling Submodel PUT API) of the process is incorrect. Please replace request json with the following json and perform steps 1 to 4 again.

request json

```json { "conceptDictionary": [], "identification": { "idType": "Custom", "id": "https//example.com/aas/0" }, "idShort": "test", "dataSpecification": [], "modelType": { "name": "AssetAdministrationShell" }, "asset": { "identification": { "idType": "Custom", "id": "https//example.com/asset/0" }, "idShort": "test_asset0", "kind": "Instance", "dataSpecification": [], "modelType": { "name": "Asset" }, "embeddedDataSpecifications": [] }, "embeddedDataSpecifications": [], "views": [], "submodels": [ { "keys": [ { "idType": "Custom", "type": "Submodel", "value": "https//example.com/submodel/0", "local": true } ] } ] } ```

[mdanish98]

Thanks for providing the updated requested body. We are analyzing it again, and we will get back to you with the analysis.