Error: org.bimserver.BimserverDatabaseException: Query stack size > 10000000

[dkurillo]

Hello!
I prepared 2 models of small size that help to get this error. Each is of size approximately 40 Kb. In order to get the error you need to create a new project and checkin. Both models can be opened in different IFC-viewers. XBim viewer shows no validation errors.

First model "beforeError1.txt" is successfully checkedin by BimServer but geometry generation takes too much time for the model of that size.
Second model "afterError1.txt" fails with "Query stack size > 10000000". Output of BimServer is in "output.txt"
Second model differs from first model only by one extra element.

afterError1.txt
beforeError1.txt
output.txt

Any ideas? What could be the reason? Where to dig?

PS. BimServer version is 1.5.183-SNAPSHOT

[dkurillo]

Oops. Made the same fix as here for IFC4 and it worked!
#1085

[hlg]

Thanks for the catch! Can you check if the error also disappears with the project you used for testing #1224? The duplication may still be there, but maybe the Query stack size stays within limits now?

[dkurillo]

Thanks for the catch! Can you check if the error also disappears with the project you used for testing #1224? The duplication may still be there, but maybe the Query stack size stays within limits now?

It's working but takes too much time to generate geometry

[dkurillo]

But finally if I add more elements it fails...

[dkurillo]

Actually this fix #1085 also didn't help. Maybe the problem is here:

"RelativePlacement": {
         "type": "IfcLocalPlacement",
         "fields": ["PlacementRelTo", "RelativePlacement"],
         "includes": [
            "RelativePlacement",
            {
              "type": "IfcAxis2Placement3D",
                  "fields": [
                     "Location",
                     "Axis",
                     "RefDirection"
                  ]
            }
         ]
      }

If I remove "RelativePlacement" from includes it's working again

[hlg]

Does it only fail and take very long for models modified through the low level interface?
Are you always getting the correct geometry generated with the "RelativePlacement" include removed?

I thought that this was necessary for recursive querying of the relative placement, but apparently this is not the case, as I figured after some tinkering with the queries. Then a query like the following should just be enough (replace OID with valid ID for testing).

{"query": {
    "type": {
      "name": "IfcDistributionPort",
      "includeAllSubTypes": true
    },
   "oid": 6817549,
   "include": "ObjectPlacement"
 },
 "defines" : {
      "ObjectPlacement": {
         "type": "IfcProduct",
         "field": "ObjectPlacement",
         "include": "RelativePlacement"
      },
      "RelativePlacement": {
         "type": "IfcLocalPlacement",
         "fields": ["PlacementRelTo", "RelativePlacement"],
         "includes":  [{
            "type": "IfcAxis2Placement3D",
            "fields": [
               "Location",
               "Axis",
               "RefDirection"
            ]
         }]
     }
  }
}

[dkurillo]

Does it only fail and take very long for models modified through the low level interface?
Are you always getting the correct geometry generated with the "RelativePlacement" include removed?

I work with models through LowLevelInterface. If I get the error I commit a model without regenerating geometry, then I export it to IFC and import it again. During the import process I get the error. So the reason not in LowLevelInterface...

[thaopham03]

@dkurillo

Hello,

I tried to reproduce the query stack >10000000 error by loading the ifc model you mentioned above to release 1.5.184 to see if I get the same error. What I did was basically run the python client while I can make a loop of 100 revisions without actually having any minor change. Just for the revisions to appear. I have the duplication issue but there is no query stack issue when i add an query.

Since I am unable to reproduce this issue, if you encounter the error again in the future, please let us know.

[hlg]

As we cannot reproduce this, we are assuming this is solved with 252850f and a6591ea (fixed duplicate inverse generation in low level interface). If you encounter it again, please reopen or create a new issue.