Bug: basyx.aasenvironment+MongoDB stores binaries in Memory anyways (and by extension basyx.aassubmodelregitry as well i guess)

[mwly]

Hi,

I am using the components and am really happy right now with how everything is set up using MongoDB as backend.
While playing around with my deployment spinning up the containers on demand with a load balancer i noticed the binaries contained in my AASX where missing.

As it turns out when reading in the AASX file everything but the binaries, who will be retrieved with: http://localhost:8081/submodels/{submodelIdentifier}/submodel-elements/{idshortpath}/attachment
are stored in MongoDB.
When going on the hunt for my binaries i found them inMemory stored in the /tmp/ Dir of the container.

This can be shown with the response of:
http://MY-IP:8081/submodels/My-Hash/submodel-elements/DeviceManual.DocumentVersion00.DigitalFile
which returns:

{
  "modelType": "File",
  "contentType": "application/pdf",
  "value": "/tmp/basyx-temp10811326382805457916/My-Hash-DeviceManual.DocumentVersion00.DigitalFile-filename.pdf",
  "semanticId": {
    "keys": [
      {
        "type": "ConceptDescription",
        "value": "0173-1#02-ABI504#001/0173-1#01-AHF583#001"
      }
    ],
    "type": "ModelReference"
  },
  "idShort": "DigitalFile"
}

using: http://MY-IP:8081/submodels/My-Hash/submodel-elements/DeviceManual.DocumentVersion00.DigitalFile/attachment
will retrieve the file But..

This resulted in the binary missing when i rebooted the container, since /tmp will get cleaned up by the system and the AASX will not get reloaded when its ID already exists in MongoDB.
My current fix to persist the data by mounting the /tmp of basyx.aasenvironment to my filesystem as follows, but this increases the access times by 10x+ and is no longterm solution.

 aas-env:
    image: eclipsebasyx/aas-environment:2.0.0-SNAPSHOT
    container_name: AAS-POC-ENV
    volumes:
      - ./aas-env.properties:/application/application.properties
      - ./aas:/application/aas
      - ./aas-env-cache:/tmp
    ports:
        - 8081:8081
    depends_on:
        mongo:
            condition: service_healthy
        mqtt:
            condition: service_healthy
        aas-registry:
            condition: service_healthy
        sm-registry:
            condition: service_healthy

Maybe you can point me to the config option which will fix this behaviour but i believe this simply might be a bug.
Sadly my java aint good enough to make the PR but i hope this helps locate it.

This still is the best open source implementation of AAS-Infra.
Have a great week!

Edit:
I have seen there is a basyx.aasxfileserver component but i believe that is not intended to be a File/Artifact DB but a component to serve AASX files only

[aaronzi]

Hello @mwly,

Thanks for raising this issue.
We are analyzing this issue and will get back to you with the results/fix.

[FriedJannik]

Hello @mwly,
this was actually a bug.
We have fixed it in the PR mentioned above.
Please note that it will take some time to update the Docker images, there currently is no ETA for this
If you want to try it out, you can build the Docker Image yourself.

Best regards
Jannik

[mwly]

Coool <3 thank you