Issue reading Data from Doors project
Hello Experts
We are facing a weird issue reading data from a Doors project, we have around 6 Modules with a total of around 50k items in the project.
We are using the Sodius library which is in laymen's terms java wrapper for talking to Doors.
Using this we create Java app with reads and writes to Doors which works well.
The problem was when trying to read data from a project with large amount of data Doors crashes midway.
Pls note that we read a module at a time and store all the Data on Java side of app so nothing is stored (by our app) on Doors/DXL side.
This is the screenshot of the error.
We have observed with happens when we are between 32200-32400 items.
When i say read it means we get all Requirements under a Module and all the attributes on them.
Well you might me wondering why i am posting this here instead of a Sodius forum, i feel the issue might be something to do with Doors + DXL, there might be some limitation that causes this when we exceed 32000 items read.
Sadly my DXL skill are not string enough to write a sample code to read all content and verify this.
My question here is, has anyone encountered something like this before? is there a setting i can use to increase any memory related limitations on Doors?
Thanks
One answer
Hi Sudhir,
We have a couple of reports of errors involving oleaut32.dll, but with no solid resolution in either case. Perhaps interestingly both use RPE, which also uses Java and the COM interface.
The first thing I would suggest is using the latest version of the DOORS client (9.7.2.7). the log shows you are currently using v9.7.0.1.
~32,000 is not a particularly large volume of objects, so I suspect the problem is more likely with a specific piece of data, and the code being run on it. The easiest way to determine precisely where it is fails is to add progress logging to a file i.e. dump the details of the module being opened, the object being read etc to a file using DXL Stream functionality (as documented in the DXL manual, unfortunately you will need to become familiar with it).
If the failure consistently happens at the same module/object, I would then write sample code to go straight to that data and perform the same processing. If that shows the same problem, raise a support ticket against DOORS for further investigation, including the sample code and data.
Regards,
Stuart.
Comments
Thanks for the response Stuart
I already ran some tests, like you suggested to confirm it is not the data, i.e, if i process the modules in a different order, the app still crashes around 32k irrespective of what module and what requirement it is trying to process. i will reach out to Doors support also, thanks