Sometimes IFC objects are cloned without any reason

[dkurillo]

I noticed, that BIMvie.ws always duplicates objects in the tree if there is more than one revision:

There can be even more duplications. Usually more revisions leads to more clones. I thought that it was BIMvie.ws bug, but now I got the same behaviour in ClientIfcModel:

Model looks fine, there are no clones. But in rare cases when I init new ClientIfcModel and query something I get objects multiplied like on the screenshot above. There are 3 clones of ifcRelNests objects and inside 2 clones of ifcPorts in each nest...

Any suggestions?

[hlg]

Did you create the revision through low level interface? Then this may be related to or even a duplicate of #1115.

[dkurillo]

Did you create the revision through low level interface? Then this may be related to or even a duplicate of #1115.

Nope. I call model.commit()

[hlg]

ClientIfcModel.commit? That uses the low level interface under the hood.

BIMserver/BimServerClientLib/src/org/bimserver/client/ClientIfcModel.java

Lines 287 to 291 in 9c9d474

	public long commit(String comment) throws ServerException, UserException, PublicInterfaceNotFoundException {
	if (tid == -1) {
	throw new UserException("No transaction was started");
	}
	return bimServerClient.getLowLevelInterface().commitTransaction(tid, comment, true);

[dkurillo]

Yes I see... Is there any other method to commit the model?

[hlg]

If you want to make low level modifications to a model in your BIMserver client - then no. The alternative to low level modifications is check-in of a whole serialized model created external to the BIMserver client, but I believe that is not what you are after.

[dkurillo]

If you want to make low level modifications to a model in your BIMserver client - then no. The alternative to low level modifications is check-in of a whole serialized model created external to the BIMserver client, but I believe that is not what you are after.

It seems that I got another bug related to this issue. Starting from some point I receive this error from the server side: Query stack size > 10000000, probably a bug, please report

I debugged server side a little. This is what I see in HashMapVirtualObject in StreamingGeometryGenerator before failing to exception:

IfcLocalPlacement 1550517826
	RelativePlacement: 4344317463
	ReferencedByPlacements: [1550583362, 1550583362, 1550583362, 1550583362, 1550583362]
	PlacementRelTo: 1550452290
	PlacesObject: [54264770, 54264770, 54264770, 54264770, 54264770]

Again: the same object ids. I made 5 commits and I see 5 duplicates. And it seems that StreamingGeometryGenerator does work for same objects and starting from some critical point exceeds MAX_STACK_SIZE.
This is a severe problem... Is it possible to overcome this?

[dkurillo]

What could be the reason for this error? Circular dependencies?

[hlg]

It could be in many places. That's what I considered in #1115:

I don't understand whether this issue is triggered in the serializer or in the database layer and if the latter whether on storage or on access.

Looking at your report now, it's probably not in the serializer, but happens somewhere before. I think the bug is either in the way how the query is processed or in the way how the low level changes are written. I don't think it is a circular thing, because then it would not stop after the exact number of revisions. It's likely some thing that's accidentally done or not done for every revision, even though it should not or should be done, like add or remove an oid from some temporary list or similar.

I agree that this is a main issue to be solved in order for the low level interface to be effectively used and I would classify it high priority.

[hlg]

This should be solved with the latest commits. I have tested for the initial issue, but had not reproduced the query stack size issue yet. I guess it needs testing with a sufficiently large model, complex query and a couple of low level changes committed.