Hello,
I'm encountering a strange problem... I developed a Java program that executes specifics DXL scripts on the Doors database (v9.6.1). The java program is executed from Doors (in red) with good parameters, then java runs another Doors instance (blue) with Dxl scripts. So basically, the execution flow is as shown in the following screenshot.
Goal : The blue Doors instance executed from Java generates .xml files (can takes long time in function of project's size), then when it is done the Java program create .html report according to .xml files. Finally the html report created by the Java program is opened in the first Doors instance (in red)
Problem : Until yesterday everything was good. Then I executed in on a bigger project and the first Doors instance crashed just after the second Doors instance has finished to run scripts from Java. Even if the first Doors instance crashed, the Java program continue and generate the Html report. As the first Doors instance (red) crashed, the html report is not displayed..
I can not find why the first doors instance crash... For information, the crash is not due to Dxl error or Java error because all files that are expected are generated (also because if I execute the Java program with exactly the same arguments but directly from a command line, it works). Also, if I run it on a smaller project it works.
Any ideas ?
Joooris - Fri Apr 28 05:24:51 EDT 2017 |
Re: Doors Crash - Can't find why Well let me tell you from experience - when DOORS crashes it is 99% because of a DXL error. It may or may not happen inside your DXL script, it may or may not be caused by your special DXL script (it can also be caused by some DXL inside the modules). But you can be sure, that it is caused by DXL. That being said, another issue can be COM. I assume you call a System Shell Process (Java) from the top level DOORS and you launch the lower level DOORS as a DOORS batch job from Java? Or do you use COM for any access to a DOORS client? If you say the "first" instance of the DOORS client crashes, can you post the code on how you launch the java process? Regards, Mathias |
Re: Doors Crash - Can't find why Hello Mathias, Many thanks for your answer ! I am 200% sure that this is not caused by our DXL Scripts. If I execute them directly from doors (tools / Edit DXL) => no error (even on a HUGE project) But same script being executed (on 2nd Doors instance in blue) from our Java app will cause a crash of the first instance in red AT THE END OF ALL DXL EXECUTION (it means DXL went well because all files that should have been generated are generated). But it occurs on big project only... This is the dxl code used to run the Java program.
string cmdLine = "java -jar "jarClient" -doors \"/"name(projectCurrent)"\" \""databaseServer"\" "arguments""
int returnCode = win32SystemWait_(cmdLine, msg, -1)
Then inside the java source code, we call a new Doors program (because we need a special user with admin right on everything projects, and the user who is running the tool may not have enough right) in a new process as below (this is how the 2nd instance in blue is created) :
String command = "doors.exe -u \""+ DOORS_USER +"\" -P \""+DOORS_PASSWORD+"\" -d \""+ doors_db +"\" -b \""+ dxlScriptTempFile +"\" -l "+TMP_FOLDER+"/doorsLog1.log -W "
ProcessBuilder pb = new ProcessBuilder(command);
Thanks in advance !! |
Re: Doors Crash - Can't find why Joooris - Fri Apr 28 11:52:04 EDT 2017 Hello Mathias, Many thanks for your answer ! I am 200% sure that this is not caused by our DXL Scripts. If I execute them directly from doors (tools / Edit DXL) => no error (even on a HUGE project) But same script being executed (on 2nd Doors instance in blue) from our Java app will cause a crash of the first instance in red AT THE END OF ALL DXL EXECUTION (it means DXL went well because all files that should have been generated are generated). But it occurs on big project only... This is the dxl code used to run the Java program.
string cmdLine = "java -jar "jarClient" -doors \"/"name(projectCurrent)"\" \""databaseServer"\" "arguments""
int returnCode = win32SystemWait_(cmdLine, msg, -1)
Then inside the java source code, we call a new Doors program (because we need a special user with admin right on everything projects, and the user who is running the tool may not have enough right) in a new process as below (this is how the 2nd instance in blue is created) :
String command = "doors.exe -u \""+ DOORS_USER +"\" -P \""+DOORS_PASSWORD+"\" -d \""+ doors_db +"\" -b \""+ dxlScriptTempFile +"\" -l "+TMP_FOLDER+"/doorsLog1.log -W "
ProcessBuilder pb = new ProcessBuilder(command);
Thanks in advance !! I will believe you only that the error is not created from DXL when you do the following: - replace your whole DXL code in the first instance by only the code to run the java program (the two lines you have above) - replace your whole DXL code for the second DOORS instance by: print "Hello" and see if the error still occurs. If you then tell me, that your DOORS still crashes, then I will believe you it is not caused by DXL. I really can see nothing wrong about your code. Since you launch separate processes, there should be no interference. So if the red DOORS instance crashes, there can only be two reasons for it: 1. starting the java process makes the DOORS process unstable. This is against every observation I made in the past. Starting another process has never crashed my DOORS. 2. Something else inside the DXL you have crashes the interpreter. (3. Something external influences your first DOORS instance and makes it crash) So please: a) Try to reduce the DXL code of the red instance to the minimum (only the two lines above with hardcoded values) step by step and see if you can make the error go away. b) try to come up with an error log / crash dump of the red DOORS process, so we can get a hint on what is wrong (ACCESS VIOLATION, etc.) Regards, Mathias |
Re: Doors Crash - Can't find why Mathias Mamsch - Sat Apr 29 05:04:13 EDT 2017 I will believe you only that the error is not created from DXL when you do the following: - replace your whole DXL code in the first instance by only the code to run the java program (the two lines you have above) - replace your whole DXL code for the second DOORS instance by: print "Hello" and see if the error still occurs. If you then tell me, that your DOORS still crashes, then I will believe you it is not caused by DXL. I really can see nothing wrong about your code. Since you launch separate processes, there should be no interference. So if the red DOORS instance crashes, there can only be two reasons for it: 1. starting the java process makes the DOORS process unstable. This is against every observation I made in the past. Starting another process has never crashed my DOORS. 2. Something else inside the DXL you have crashes the interpreter. (3. Something external influences your first DOORS instance and makes it crash) So please: a) Try to reduce the DXL code of the red instance to the minimum (only the two lines above with hardcoded values) step by step and see if you can make the error go away. b) try to come up with an error log / crash dump of the red DOORS process, so we can get a hint on what is wrong (ACCESS VIOLATION, etc.) Regards, Mathias Hi ! Haha. It will work for sure. As I said it crashes only on huge project. But we will completely rework our tool (big or small project we run the same dxl script)
I have raised a ticket to Ibm and they told me that running 2 Doors instances on the same computer makes Doors unstable, and they were pretty surprised that it has worked so far ! They advised us to use a webservice, this is what we are going to do (more precisely we will run a Jenkins job to run the Java program on an other computer).
Thanks again ! (I will let you know if it really solves our problem) |
Re: Doors Crash - Can't find why Joooris - Tue May 02 03:34:40 EDT 2017 Hi ! Haha. It will work for sure. As I said it crashes only on huge project. But we will completely rework our tool (big or small project we run the same dxl script)
I have raised a ticket to Ibm and they told me that running 2 Doors instances on the same computer makes Doors unstable, and they were pretty surprised that it has worked so far ! They advised us to use a webservice, this is what we are going to do (more precisely we will run a Jenkins job to run the Java program on an other computer).
Thanks again ! (I will let you know if it really solves our problem) I did not experience problems with two running DOORS instances on the same computer. I have successfully implemented a parallelization framework that will launch 8 or more DOORS instances on the same computer and I never experienced ANY crashes. There are only problems I am aware of 1. when the same user tries to login exactly at the same time, then one login may fail even though correct credentials were supplied. 2. If the DOORS instances use the same temporary file folder they will overwrite their temp files, which could be of cause a source for crashes. You need to give each DOORS instance a separate temp folder using the -F command switch. Apart from that the explanation that 2 instances of DOORS will make DOORS unstable does not explain, why it would not crash on small projects. I would not go too fast with rewriting everything until you know what exactly the problem is. Did IBM actually analyze the crashdumps and found the cause of the problem to be parallelization? Regards, Mathias
|
Re: Doors Crash - Can't find why Mathias Mamsch - Tue May 02 07:00:30 EDT 2017 I did not experience problems with two running DOORS instances on the same computer. I have successfully implemented a parallelization framework that will launch 8 or more DOORS instances on the same computer and I never experienced ANY crashes. There are only problems I am aware of 1. when the same user tries to login exactly at the same time, then one login may fail even though correct credentials were supplied. 2. If the DOORS instances use the same temporary file folder they will overwrite their temp files, which could be of cause a source for crashes. You need to give each DOORS instance a separate temp folder using the -F command switch. Apart from that the explanation that 2 instances of DOORS will make DOORS unstable does not explain, why it would not crash on small projects. I would not go too fast with rewriting everything until you know what exactly the problem is. Did IBM actually analyze the crashdumps and found the cause of the problem to be parallelization? Regards, Mathias
Hi Mathias,
We use a special user for the second Doors instance.
Ibm also told me that. I'm going to try by specifying a temporary file for the second Doors instance (now you told me you have launched at least 8 Doors instance In addition, they clearly replied that running two Doors instance is not supported, so they didn't analyze the crashdump.. |
Re: Doors Crash - Can't find why Hi, I tried to change the temporary folder of the second Doors instance, but I still had the crash on big project But today it is working. We were using :
win32SystemWait_(cmdLine, msg, -1)
With such code, the first Doors instance was waiting for the executed process to end. This led to a crash of the 1st Doors instance (only for big project) as explained before. The benefits to wait was that the DXL displayed the generated html file when computation was done .
I tried then to run it but without waiting : win32SystemWait_(cmdLine, msg, 0). No more crash. As the first Doors instance is not freezed, there is no more crash ! But the DXL could not know when the execution was done, so we are now displaying a message directly from the Java program. BUT (again), graphical user interface are not displayed when using ''win32SystemWait_", so I tried with "system()" and it works like a charm. So I'm now using :
system(cmdLine)
Thanks for your help and your reactivity !
|