Forum Discussion

yoharaaj's avatar
yoharaaj
New Contributor
8 years ago
Solved

Receiving JVM error in jenkins when using testrunner.bat

Team, We are doing Continuous Integration with Jenkins by using SoapUI NG TestRunner. Daily 50 plus jobs are running in it. At times, we could see the below error in the job log, ------------------...
  • Radford's avatar
    8 years ago

    I have encountered this issue and raised it with SmartBear support.

     

    I only saw it when I started two instances of TestRunner.bat at exactly the same time. I thought the issue was lines 31 to 33 of TestRunner.bat (I'm using version 1.7) which is
     
    "%JAVA%" -cp "%CLASSPATH%" com.eviware.soapui.tools.JfxrtLocator > %TEMP%\jfxrtpath
    set /P JFXRTPATH= < %TEMP%\jfxrtpath
    del %TEMP%\jfxrtpath

     
    To me it appears if two independent instances of TestRunner.bat are started at the same time they are both trying to write and manipulate the same file, which would explain the initial error message you see:

     

    The process cannot access the file because it is being used by another process.
    C:\Users\...\AppData\Local\Temp\jfxrtpath

     

    The response I got was:

     

    The error you faced doesn't indicate any problem with the tool. For some reason, TestRunner's Java VM cannot just recognize the -Xmx option when you run the second instance of the runner. The option denotes the maximum heap size that can be used by the tool. Your system should have enough free RAM to start the tool's process. To avoid the situation, you can specify a hardcoded value for the Java option by following the steps below:
    - open the "C:\Program Files\SmartBear\ReadyAPI-1.7.0-m-SNAPSHOT"\bin\testrunner.bat" file in a text editor (as an Administrator);
    - locate the following lines in the file:
    rem uncomment to override memory limit
    rem set READY_XMX=4000m
    - uncomment the second line specifying a maximum heap size that is enough to run your project, e.g.
    set READY_XMX=1024m
    - save your changes.

    The setting above allocates 1 Gb of RAM for each TestRunner's Java VM. That is, your system must have at least 2 Gb of RAM to create two TestRunner instances simultaneously. You can specify another size in megabytes (e.g. set READY_XMX=768m) or gygabytes (e.g. set READY_XMX=2g).

    Please let us know if you need anymore assistance on this matter.

     

    On pointing out the details of the TestRunner.bat I then got the response:

     

    Actually, there is no issue with the batch file. The files you listed (jfxrtpath, readypermsize, readyxmx) are auxiliary. The script creates and deletes them before running TestRunner's Java VM. Therefore, all TestRunner instances aren't sharing them during the runtime. The files are created to calculate certain settings for the VM. In your case, the jfxrtpath and readypermsize files are simply empty so the fact that they are locked by one TestRunner instance doesn't affect another instance anyhow. Locking readyxmx affects the other instance, but creating a unique version of the file for each TestRunner instance may not work for you as expected. This is because of how the file's value is calculated. Basically, Ready! API and TestRunner try to allocate a half of available free memory for the -Xmx option. That is, if two TestRunner instances are run simultaneously, they potentially can consume all your free memory. Therefore, to avoid the situation, you just need to specify a hardcoded value for the -Xmx option as we mentioned before. This ensures that your TestRunner instances' memory consumption is balanced.

    I hope this helps.

     

    I ended up working around this issue by just not starting two instances of TestRunner at exactly the same time.

     

    If the above support comments do not help, you might want to raise the issue with support yourself.