JVM Argument at Runtime

[Chris F.]

Hi, forgive me if this is a simple question I'm just not very familiar with Maven.  I have a 3rd party tool that injects an agent at runtime into a load test usually via ANT.  What I would like to know is if there is a way to pass a JVM argument when the load test is called to run so that I can achieve the same functionality.  Could this be done by editing the POM.xml or would it be something I can do on each nGrinder agent machine I am using?  Thanks in advance.  

PS. Great tool

[junoyoon]

JVM Argument? You mean.. you should provide -Doption_name=option_value?

nGrinder doesn't support to add the jvm argument because there are possibility to abuse the agent.
 
Instead, you can provide this setting by just calling System.setProperty("option_name", "option_value") directly in script.


If you're using Groovy, put it in the @BeforeProcess block. If you're using Jython, put it in the global scope of the script.

Mostly it works!!

[Chris F.]

Thanks I'll give that a shot and let you know! :)

[Chris F.]

Unfortunately that doesn't really do what I need it to do.  What I am looking for is a way to inject an agent into the JUnit runtime.  I'm not sure if based on your architecture the POM is built on test execution or not.  I was thinking of using an ANT plugin and using a build.xml to accomplish this or trying the sure-fire plug-in as I know it will work with that.  

[junoyoon]

Umm.. Nope.. ngrinder doesn't execute maven structure actually.

Internally, ngrinder controller gets the dependencies from pom.xml and put them is the distribution file temp directory. Then it executes script with the retrieved dependencies by its own way.

Could you explain what kind of ant plugin you use and what it really does?

I think I can help you because I believe I'm quite experienced in all kinds of test automation job. :-)

[Chris F.]

I haven't used an ANT plug-in with Maven yet, I was using ANT to execute load tests with JMeter and had recently adopted Grinder when I found nGrinder.  The 3rd party application I am using is called Dynatrace from Compuware, you might have heard of them.  Their system comes with an Automation library that allows you to use ANT / Maven to setup test meta data information and then records the method calls, response time, etc. over time.  Here is a sample of the ANT file I was using with JMeter to run my automated load tests.  

<project name="ant-jmeter" default="StopRecording" basedir=".">

       
        <target name="init">

                <taskdef
                        name="jmeter"
                        classname="org.programmerplanet.ant.taskdefs.jmeter.JMeterTask"
                />
        <echo message="Init Completed" />
        </target>

       
        <property name="dtBaseDir" value="lib/dynaTrace" />
        <property name="dtAgentGroup" value="Load Testing" />
        <property name="dtProfile" value="LoadTesting" />

   
         <import file="lib/dynaTrace/dtTaskDefs.xml"/>
         <echo message="Import dtTaskDefs.xml" />


       
        <target name="EnableProfileAndActivateConfiguration" depends="init">
                <DtEnableProfile profileName="LoadTesting" enable="true" />
                <DtActivateConfiguration profileName="LoadTesting" configuration="Default" />
                <echo message="Enable Profile" />
               
        </target>


       
        <target name="ClearSession" depends="init,EnableProfileAndActivateConfiguration">
                <DtClearSession profileName="LoadTesting" />
                <echo message="Clear Live Session" />
        </target>


       
         <target name="StartRecording" depends="init,ClearSession">
                <DtStartRecording profileName="LoadTesting" sessionNameProperty="sessionName" sessionName="JMeter_LoadTesting" sessionDescription="Automated Load Testing" appendTimeStamp="true"  />               
        <echo message="Start Recording SessionName: ${sessionName}" /> 
        </target> 

       
        <target name="GenerateLoad" depends="StartRecording">
                <jmeter
                        jmeterhome="c:\jmeter"
                        resultlog="${basedir}/LoadTests/JMeterResults.jtl">
                                <testplans dir="${basedir}/LoadTests" includes="*.jmx"/>
                </jmeter>
        </target>

       
        <target name="StopRecording" depends="init,EnableProfileAndActivateConfiguration,ClearSession,StartRecording,GenerateLoad">
                <DtStopRecording profileName="LoadTesting" sessionNameProperty="SessionName" />               
                <echo message="Stopped Recording SessionName: ${SessionName}" />
    </target>

</project>

Any help would be appreciated :)  

Thanks

[junoyoon]

Oh.. NO...

DynaTrace might not work well with nGrinder...
I believe DynaTrace uses java agent and instrumentation technique internally. Right?
These techniques are already used by nGrinder to record the test execution so you can not replace them with Dynatrace's.

More serious obstacle here is that nGrinder dynamically interprets scripts which are sent from the controller. Therefore this might be not visible from JVM when the agent process is just being started(at the moment the Dynatrace is activated).

I don't know DynaTrace internal exactly but when I used the other profiling tools they worked like this.

But I'm wondering why you need instrumentation on the test code. You're doing some library testing not server testing?

I have not seen the users who want to profile test code yet.

[Chris F.]

The injection doesn't just monitor the test code it tracks the number of method calls, sql calls, duration of each test, duration of wait time vs service time and records the information into a data warehouse so that across builds I can setup alerts if there is a change larger than a certain percentage.  

[junoyoon]

To confirm..

Should your test target distributed to agents as well? or Is your test code just invoking the server's feature using network protocol(like HTTP)?

Depending on these.. the approach should be changed.

[Chris F.]

The dynaTrace agent should target the distributed agent, it needs to be injected at runtime.  I've been looking at some different ways to do it and I haven't any.  I'm also in contact with the company to try and come up with a solution.  

[Chris F.]

Here is a snippet from the latest e-mail I recieved From DT.  Would any of these methods work here?

"there must be some way to pass parameters to the jvm running the tests, some configuration file or other option.

Some tools honor the JAVA_OPTS environment variable, that might be an option here, as at least the groovy native launcher checks for those. You could add the agentpath parameter there.

There might be a way in Groovy to modify the jvm parameters of the spawned JUnit processes, I know that this is possible in ant, maven or IDEs. Add the agentpath parameter there."

[junoyoon]

It's not possible.. because the javaagent is already used by ngrinder process.
So there are no room for the other tool to inject their own.

Sorry.. I think it's not possible at all.

[junoyoon]

What I wonder is.. what you need is to profile the target system.. Isn't it?

I don't know your script yet. However if your script calls the target system using HTTP or other network protocol, this means that such a dynatrace stuff can be applied to the target system directly.

If your script calls the test target existing in the same process with the script, this might not be able to applied.

[Chris F.]

Thanks for the help, I didn't find a complete solution but I found one that works.  I was used to running load tests in more of a CI environment where the target was built with the tests.  Instead I have the target system running consistently and profiled and pass information on the HTTP headers. So now when CI updates I just have nGrinder scheduled to run my master suite of tests and the app is profiled.  Thanks so much for trying to help, I really appreciate the feedback.  

[junoyoon]

This issue is handled by http://jira.cubrid.org/browse/NGRINDER-639.

nGrinder 3.2.2 provides the way to configure java execution options.