jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nico Kruger <>
Subject Re: Sharing sockets (file descriptors) between test samples, using jruby as a scripting language
Date Wed, 12 Oct 2011 17:06:51 GMT
On 12 October 2011 18:29, sebb <> wrote:
> On 12 October 2011 17:06, Nico Kruger <> wrote:
>> Thanks for the very helpful and quick response.
> BSF is the original scripting language API; JSR223 is the related API
> that was added to Java 5/6.
> They are fairly similar in scope, but different in API.
> They both support BeanShell and some other languages.
> There are some langauges that are only supported by one or the other.
>> Is it sufficient to say that, at the moment, the BeanShell sampler is
>> the more advanced/mature of the three?
> Not really.
> However it's older and specific to BeanShell so can use features not
> in the BSF/JSR223 APIs.
> BeanShell was added first, then BSF; JSR223 was added with the move to
> requiring Java 1.5+.
>> Are the different scripting samplers going to be unified in this
>> regard in the future?
> Unified i what regard?

What I mean is, what are the future plans with regards to the 3
different interpreted language samplers? Except for the specific
interpreter-sharing behaviour for the BeanShell sampler, there's not a
lot of differences, except as you point out in the specific languages
that are supported. BeanShell itself is supported by all 3, jRuby by
JSR223 and BSF, same for jython/javascript etc.

Are there plans in changing the behaviour of the intepreters for
JSR223 and BSF to be the same as BeanShell (so that the interpreter is
shared in the same way as with beanshell)?

What are the future plans of BSF now that JSR223 and java 1.5 is in
the mix? This seems to be the more "future-ready" of the three
(support for any language that implement JSR223 is quite a powerful

I guess I'm just basically wondering why both JSR223 and BSF are
there, seeing as the move to Java 1.5 has been made. I understand the
historical/legacy reasons, it just seems like duplicate work to
support the same 90% of languages in different places. The fact that
the behaviour of the interpreter creation also differs (at least at
the moment) was definitely a source of confusion, at least for me.
Thanks for clearing that up by the way.

>>> Or perhaps the TCP Sampler would be a more suitable base.
>> Another good idea, will I be able to access the TCP sampler from a
>> scripting sampler?
> It's the other way round; you have to implemement the appropriate API
> which is called by the sampler.
> See:

This seems to be the best way forward for us at the moment, at least
for our basic socket-testing benchmarks. Seems to fit our current
needs quite well. Back to basics :)

I really do appreciate the power of jMeter, the scripting
possibilities really are enormous. Very helpful mailing list as well
Thanks for your help.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message