BIMserver icon indicating copy to clipboard operation
BIMserver copied to clipboard

Unable to checkin IFC-file :: class java.util.ArrayList cannot be cast to class java.lang.Long

Open motjokk opened this issue 2 years ago • 16 comments

Error occurs when checking in a specific file on bimserver 1.5.182.

2022-08-24 09:33:20,529 INFO [pool-1-thread-7] o.b.d.b.BerkeleyKeyValueStore [BerkeleyKeyValueStore.java:615] writes: 59000000, 688 ms sync 2022-08-24 09:33:25,654 ERROR [pool-1-thread-7] o.b.l.LongAction [LongAction.java:196] [null] [process.ifc] class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap') org.bimserver.shared.exceptions.UserException: [process.ifc] class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap')

I can share the file by request..

motjokk avatar Aug 24 '22 08:08 motjokk

If you are sure that the file is valid, please write an email to [email protected]. I will provide you with a private upload link. If the file is small, you can of course just attach it to the email.

hlg avatar Aug 24 '22 22:08 hlg

Thanks for sharing the file. I could isolate the issue, but have not yet fully solved it. The reason is an IfcIndexedPolyCurve with a style attached via IfcStyledItem. The representation item (curve) does not reference the style, but vice versa via the attribute IfcStyledItem.Item. First, all entities are processed and saved to the database on the fly. Here, the curve is first saved to the database without complaint. Then, inverses are resolved and saved to the DB as well. Thus, in the second step the curve's inverse attribute IfcIndexedPolyCurve.StyledByItem is set to the style and the curve is saved again (overwritten). That is the point where the attribute IfcIndexedPolyCurve.Segments fails to save - although it must have been saved properly before. The methods used by DatabaseSession.save and DatabaseSession.saveOverwrite are largely the same - they both call VirtualObject.write eventually. I have yet to find the difference that makes the failure. Will keep investigating.

Here are two sample files and the full stacktrace:

org.bimserver.shared.exceptions.UserException: [bs-1268-2.ifc] class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap')
        at org.bimserver.database.actions.StreamingCheckinDatabaseAction.execute(StreamingCheckinDatabaseAction.java:412)
        at org.bimserver.database.actions.StreamingCheckinDatabaseAction.execute(StreamingCheckinDatabaseAction.java:84)
        at org.bimserver.database.DatabaseSession.executeAndCommitAction(DatabaseSession.java:775)
        at org.bimserver.database.DatabaseSession.executeAndCommitAction(DatabaseSession.java:752)
        at org.bimserver.longaction.LongStreamingCheckinAction.execute(LongStreamingCheckinAction.java:73)
        at org.bimserver.longaction.LongActionManager$1.run(LongActionManager.java:55)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassCastException: class java.util.ArrayList cannot be cast to class java.lang.Long (java.util.ArrayList and java.lang.Long are in module java.base of loader 'bootstrap')
        at org.bimserver.shared.HashMapVirtualObject.writePrimitiveValue(HashMapVirtualObject.java:450)
        at org.bimserver.shared.HashMapVirtualObject.writeWrappedValue(HashMapVirtualObject.java:308)
        at org.bimserver.shared.HashMapVirtualObject.writeList(HashMapVirtualObject.java:383)
        at org.bimserver.shared.HashMapVirtualObject.write(HashMapVirtualObject.java:241)
        at org.bimserver.database.DatabaseSession.saveOverwrite(DatabaseSession.java:2336)
        at org.bimserver.shared.HashMapVirtualObject.saveOverwrite(HashMapVirtualObject.java:631)
        at org.bimserver.database.actions.GenericCheckinDatabaseAction.fixInverses(GenericCheckinDatabaseAction.java:423)
        at org.bimserver.database.actions.StreamingCheckinDatabaseAction.execute(StreamingCheckinDatabaseAction.java:217)
        ... 10 common frames omitted

hlg avatar Aug 29 '22 21:08 hlg

Update: the difference is that first round of VirtualObject.save() is called on ByteBufferVirtualObject, second round on HashMapVirtualObject. The latter does not respect the multiplicity of the wrapped value. This is quite an edge case. There are only three types IfcLineIndex, IfcArcIndex and IfcComplexNumber with similar model constructions. And they only become problematic when used as attributes types where sibling inverse attributes are becoming effective.

Edit: There are also IfcCompoundPlaneAngleMeasure and IfcPropertySetDefinitionSet.

hlg avatar Aug 29 '22 22:08 hlg

Here is a sample for IfcComplexNumber: bs-1268-3.ifc.txt. This fails already during deserialzation. After the deserializer error is fixed, it may expose the same issues as described here.

hlg avatar Aug 30 '22 07:08 hlg

I sendt you a new export from Archicad. This was exported without footprint geometry and it loads without problems. I can not see any obvious changes to the file, except it`s now 75 mb.

motjokk avatar Aug 30 '22 07:08 motjokk

I sendt you a new export from Archicad. This was exported without footprint geometry and it loads without problems. I can not see any obvious changes to the file, except it`s now 75 mb. This is a ok workaround for our use case.

motjokk avatar Aug 30 '22 07:08 motjokk

Touchpad accident there..

motjokk avatar Aug 30 '22 07:08 motjokk

The issue is rooted in styled curves which are only contained in footprint geometry. In that case, we have lines with color and thickness specified. Without footprint geometry, styles are only applied to 3D representation items, which may be constructed of curves, but the styling is applied to the 3D items instead of the curves.

The increase in file size may be due to additional changes in export settings like switching from design to reference view.

hlg avatar Aug 30 '22 07:08 hlg

Thank you very much for looking into the issue!

motjokk avatar Aug 31 '22 16:08 motjokk

Hi,

It is now (1.5.184) possible to checkin files with the feature you mention above. I do however get an empty result when requesting a download, querying IfcApplication (in this case).

motjokk avatar Mar 13 '23 10:03 motjokk

It is now (1.5.184) possible to checkin files with the feature you mention above.

How is that possible? I had not committed the fixes because they are still unfinished. Are you sure these very features are present in your file at hand? Or are you looking at a different issue?

hlg avatar Mar 13 '23 14:03 hlg

I`m not sure if this is the same issue. I sendt you the file in question.

motjokk avatar Mar 14 '23 11:03 motjokk

This was a mistake on my part. Sorry for the inconvenience!

motjokk avatar Apr 22 '23 08:04 motjokk

I have the same issue. Is there any commit, in which is the issue fixed, please?

krepsjan avatar Jul 17 '23 13:07 krepsjan

Unfortunately, I have half a solution, but nothing ready to commit yet.

hlg avatar Jul 17 '23 15:07 hlg

And is there any way I could help with the solution?

krepsjan avatar Jul 18 '23 09:07 krepsjan