You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Nico Kruger <ni...@gmail.com> on 2011/10/12 17:03:59 UTC
Sharing sockets (file descriptors) between test samples, using jruby
as a scripting language
Hi there
I have a small sample test file, with one thread group (one thread),
looped a number of times (10 at the moment). with one BSF group,
configured to run a ruby script.
Everything surrounding the classpath has been configured, jmeter is
finding the jruby JARs, the jruby libraries and my own java code.
Now as far as I understand, the JMeterVariables object (which seems to
be exposed as $vars in the jruby environment), is shared between
successive samples inside a thread group. I understand that each
thread group runs in its own copy of the interpetrer, but as far as I
understand successive samples within a thread group share an
interpreter of the chosen language. Thus you can use this object to
share variables between test samples. Now this seems fine for sharing
simple numbers/strings - but what I want to do, is share a socket
instance between successive test samples, and this seems to break
somewhere, or I am misunderstanding.
Basically, I have the one thread group, looping 10 times. Inside, a
BSF group, running the following jruby script:
require 'socket'
if $vars.getObject("s") == nil
s = TCPSocket.open("localhost", 6663)
$vars.putObject("s",s)
end
begin
socket = $vars.getObject("s")
socket.send([1,2,3,4])
rescue => e
puts "Error"
puts e.message
end
I can see it working the first time, but after that, it fails with an exception:
Bad file descriptor.
The output I get is basically this (note, I am running through the
chronos maven plugin here):
[INFO] Success
....
[INFO] Error
[INFO] Bad file descriptor - Bad file descriptor
....
[INFO] Error
[INFO] Bad file descriptor - Bad file descriptor
etc.
Should I not be using the $vars object to share something like this?
Is the interpreter in fact getting recreated? What am I
misunderstanding?
Thanks for any help, enlightenment, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Sharing sockets (file descriptors) between test samples, using
jruby as a scripting language
Posted by sebb <se...@gmail.com>.
On 12 October 2011 18:06, Nico Kruger <ni...@gmail.com> wrote:
> On 12 October 2011 18:29, sebb <se...@gmail.com> wrote:
>> On 12 October 2011 17:06, Nico Kruger <ni...@gmail.com> 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)?
No plans at present, but it would probably be sensible to optionally
share interpreters, either for a specific sampler (across loops) or a
thread.
> 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
> thing)
BSF is likely to continue to be needed for some languages.
It might not get as much attention as JSR223, but I see no reason to drop it.
> 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.
Yes, that needs documenting.
> 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:
>>
>> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#TCP_Sampler
>>
>
> 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: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Sharing sockets (file descriptors) between test samples, using
jruby as a scripting language
Posted by Nico Kruger <ni...@gmail.com>.
On 12 October 2011 18:29, sebb <se...@gmail.com> wrote:
> On 12 October 2011 17:06, Nico Kruger <ni...@gmail.com> 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
thing)
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:
>
> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#TCP_Sampler
>
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: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Sharing sockets (file descriptors) between test samples, using
jruby as a scripting language
Posted by sebb <se...@gmail.com>.
On 12 October 2011 17:06, Nico Kruger <ni...@gmail.com> wrote:
> Thanks for the very helpful and quick response.
>
>
>
> On 12 October 2011 17:30, sebb <se...@gmail.com> wrote:
>> On 12 October 2011 16:03, Nico Kruger <ni...@gmail.com> wrote:
>>> Hi there
>>> ...SNIP....
>>
>> No, the BSF samples currently each use their own BSF Manager and
>> interpreter - it is not currently shared.
>>
>> Same for JSR223 currently.
>>
>> It's only the BeanShell sampler that re-uses the interpreter.
>>
>
> Could you perhaps elaborate on the difference betweens JSR223 and BSF?
> What are the advantages/disadvantages of each, because functionally
> they look pretty similair for the untrained eye. In fact, I was
> definitely confused about the differences between the three - I was
> under the impression that BeanShell is just a different "language" you
> choose inside the BSF sampler.
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?
>>
>> Work-rounds:
>> - use BeanShell
>
> I would like it if we could get away with jRuby instead of switching
> to BeanShell. We have a lot of already existing jRuby code that
> excercises the system from the outside which we use in cucumber-jvm
> for example that I would like to re-use.
>
>> - create and manage the interpreter yourself - if you use the
>> interpreter to create an interpreter rather than a socket, it may be
>> possible to invoke the saved interpreter.
>>
>
> Interesting idea, will have a look at this.
>
>> 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:
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#TCP_Sampler
>
> Again, thanks for your insights.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Sharing sockets (file descriptors) between test samples, using
jruby as a scripting language
Posted by Nico Kruger <ni...@gmail.com>.
Thanks for the very helpful and quick response.
On 12 October 2011 17:30, sebb <se...@gmail.com> wrote:
> On 12 October 2011 16:03, Nico Kruger <ni...@gmail.com> wrote:
>> Hi there
>> ...SNIP....
>
> No, the BSF samples currently each use their own BSF Manager and
> interpreter - it is not currently shared.
>
> Same for JSR223 currently.
>
> It's only the BeanShell sampler that re-uses the interpreter.
>
Could you perhaps elaborate on the difference betweens JSR223 and BSF?
What are the advantages/disadvantages of each, because functionally
they look pretty similair for the untrained eye. In fact, I was
definitely confused about the differences between the three - I was
under the impression that BeanShell is just a different "language" you
choose inside the BSF sampler.
Is it sufficient to say that, at the moment, the BeanShell sampler is
the more advanced/mature of the three?
Are the different scripting samplers going to be unified in this
regard in the future?
>
> Work-rounds:
> - use BeanShell
I would like it if we could get away with jRuby instead of switching
to BeanShell. We have a lot of already existing jRuby code that
excercises the system from the outside which we use in cucumber-jvm
for example that I would like to re-use.
> - create and manage the interpreter yourself - if you use the
> interpreter to create an interpreter rather than a socket, it may be
> possible to invoke the saved interpreter.
>
Interesting idea, will have a look at this.
> 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?
Again, thanks for your insights.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Sharing sockets (file descriptors) between test samples, using
jruby as a scripting language
Posted by sebb <se...@gmail.com>.
On 12 October 2011 16:03, Nico Kruger <ni...@gmail.com> wrote:
> Hi there
>
> I have a small sample test file, with one thread group (one thread),
> looped a number of times (10 at the moment). with one BSF group,
> configured to run a ruby script.
>
> Everything surrounding the classpath has been configured, jmeter is
> finding the jruby JARs, the jruby libraries and my own java code.
>
> Now as far as I understand, the JMeterVariables object (which seems to
> be exposed as $vars in the jruby environment), is shared between
> successive samples inside a thread group.
Yes, all samplers in the thread group have access to the same vars -
that's how ${variables} work.
> I understand that each
> thread group runs in its own copy of the interpetrer, but as far as I
> understand successive samples within a thread group share an
> interpreter of the chosen language.
No, the BSF samples currently each use their own BSF Manager and
interpreter - it is not currently shared.
Same for JSR223 currently.
It's only the BeanShell sampler that re-uses the interpreter.
> Thus you can use this object to
> share variables between test samples. Now this seems fine for sharing
> simple numbers/strings - but what I want to do, is share a socket
> instance between successive test samples, and this seems to break
> somewhere, or I am misunderstanding.
Interpreters are not shared, see above.
> Basically, I have the one thread group, looping 10 times. Inside, a
> BSF group, running the following jruby script:
>
> require 'socket'
>
> if $vars.getObject("s") == nil
> s = TCPSocket.open("localhost", 6663)
> $vars.putObject("s",s)
> end
>
> begin
> socket = $vars.getObject("s")
> socket.send([1,2,3,4])
> rescue => e
> puts "Error"
> puts e.message
> end
>
> I can see it working the first time, but after that, it fails with an exception:
>
> Bad file descriptor.
>
> The output I get is basically this (note, I am running through the
> chronos maven plugin here):
> [INFO] Success
> ....
> [INFO] Error
> [INFO] Bad file descriptor - Bad file descriptor
> ....
> [INFO] Error
> [INFO] Bad file descriptor - Bad file descriptor
>
> etc.
>
> Should I not be using the $vars object to share something like this?
> Is the interpreter in fact getting recreated?
Yes.
> What am I misunderstanding?
Just that.
> Thanks for any help, enlightenment, etc.
Work-rounds:
- use BeanShell
- create and manage the interpreter yourself - if you use the
interpreter to create an interpreter rather than a socket, it may be
possible to invoke the saved interpreter.
Or perhaps the TCP Sampler would be a more suitable base.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org