jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Shetty <>
Subject Re: embedding JMeter / calling JMeter from other Java code
Date Mon, 25 Jul 2011 17:38:28 GMT
>For a response to the second half of your message
Actually it isnt clear. It is trivial to write a wrapper that spawns a
jmeter process and waits for it to complete (similar to when you run jmeter
from ANT ) . the one problem is  a distributed setup (but embedding jmeter
wouldnt solve that problem anyway). So the question is what more do you need
when you want to run jmeter from your application? (i.e. why is it important
to run it within the same process as the caller - given that now you are
reducing the number of resources that would be available to the jmeter VM)

> but how would JMeter benefit from that
It wouldnt , but Im from the use what works for your problem rather than the
one size fits all approach.


On Mon, Jul 25, 2011 at 5:05 AM, _ext van Leeuwen, Paul <> wrote:

> Apparently I am not the only person who sees the benefit of a more
> programmatic interface: I found that some other guy from some other company
> already created a feature request some time ago:
> I guess now I can only wait. If you read this thread and also want a more
> programmer-friendly JMeter API, then please consider leaving a comment on
> the issue above to make yourself heard.
> With regards to the suggestions made on this email-thread:
> @apc : it seems to me that your logic is from the point of view of JMeter.
> I am looking at other frameworks: like when running a large regression test
> set on the machine of every developer and some continues integration server
> (like Hudson). Some of these tests might use JMeter while others do not. In
> such case you just want to be able to add JMeter as a dependency on your
> project (having e.g. maven managing the details) and do something like:
> JMeter jmeter = new JMeter();
> TestResult result =;
> assertTrue(result.isSuccessfull());
> Another example is when defining a broader set of automated tests in
> FitNesse. Trying to write fixtures that call JMeter is currently quite a
> pain.
> @brian : you seem to understand what I mean and what I am trying to do.
> Indeed there are solutions existing to call JMeter in a programmatic way:
> the ant plugin you refer to assumes JMeter to be installed in a specific
> location. There is also a maven plugin that has a lot of boilerplate code to
> initialize JMeter. Both are a bit hacky and unstable on the long term: with
> newer versions they may break. That is exactly why I would hope that JMeter
> has a native API for its core (which could then be worked on from the GUI or
> from other Java code. I am not sure whether the JMeter developers would
> consider such.
> @deepak : sure I could decompile the JMeter plugin I was referring to and
> move to a JMeter alternative that is more programmers friendly (like
> HttpUnit), but how would JMeter benefit from that? Also I still find JMeter
> the best tool for our needs: from time to time we will have to record new
> test actions and the JMeter GUI is quite helpful there. Also JMeter is a
> tool that is already known to the less-technical people in the department,
> so I'd rather not switch. For a response to the second half of your message:
> please see my response to apc above.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message