You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Zohar Amir <da...@hotmail.com> on 2005/07/21 08:16:18 UTC
TCP session
Hi,
I need to emulate a client's behavior with Jemeter. The client connects to
the server via TCP. The connection is set up on login and kept throughout
the session, where transactions are exchanged with the server.
Any way of doing his with Jmeter? I probably need to open a TCP socket on
startup and use this same socket for all transactions. I also need a thread
listening on the socket for incoming transactions.
Thanks,
Zohar.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by sebb <se...@gmail.com>.
On 21/07/05, srikanth peddireddy <sr...@yahoo.co.in> wrote:
>
>
> Hi Sebb,
>
> can you please answer some more questions on this topic. I gave some of my
> assumptions and dopubts below your response
>
> >>The current TCP Sampler creates a new socket for each sampler
> >>occurrence in each thread. I do plan to add re-usable sockets to the
> >>TCP Sampler, but that probably won't be for a few weeks.
>
> First I planned to extend the TCPsampler by myself and though of a design
> like this :
> There will be a specialized TcpSampler(for discussion lets call it
> SharedTcpSampler) . Instances of this SharedTcpSampler will be used for all
> the TCP requests that we want to make to a server over a single
> connection/socket.
> This SharedTcpSampler will have a property called "sharedSocketReference"
> which will be something like a reference name that we give to a global
> counter inorder to use it else where in testplan.
> Each SharedTcpSampler will first try to get the socket instance by
> searching for it in a Global NameSpace (Iam yet to know what this Global
> Name Space would be in Jmeter context) by giving the "sharedSocketReference"
> value that user will configure in testplan.
>
> If this search is successful,( ie some other SharedTcpSampler in the
> testplan has already created a socket connection and registered it under
> this name), then it will send its "Text To send" (inherited from TcpSampler)
> over that socket and reads back the response.
>
> If this search fails , which will be the case with first SharedTcpSampler in
> the testplan , it will create a new socket and register it in a Global
> NameSpace under the name specified in "sharedSocketReference" and continues
> using it for implmenting the protocol
>
> So in this solution, all the SharedTcpSamplers in a testplan with same value
> given in their "sharedSocketReference" property will share a single socket
> connection. Hence I think it will serve the purpose.
You need also to consider how to handle socket errors - if one sampler
detects a problem, it may need to close the socket and delete the
reference.
And the socket ought to be closed at the end of a test run (not
essential if you only run a test once and then exit JMeter).
>
> But I know that inorder to implement this I need to know the architecture of
> Jmeter and different components of it in detail. I was unable to study this
> any further as I was tied to some other work. :-(
> Sebb, can you please tell me whether this design fits the bill. If yes
> please direct me towards some resources thru which I can quickly learn about
> architecture and components of Jemter and implement this.
> Iam planning to do this as soon as possible. :-)
See above
>
> >>One way to re-use the same socket might to have only a single sampler,
> >>and vary the content of the request using a function call to read it
> >>from a file.
>
> can you elAborate on this or tell me about the resources where I can find
> details.
Read the Manual (Functions), JMeter FAQ and the extending JMeter
documents in the xdocs/extending directory in CVS.
> >>However, I've not tried this.
>
>
> ==
>
> >>Note that the TCPSampler class is the one that creates the socket. The
> >>TCPClientImpl class uses the socket to implement the protocol.
>
> >>The current protocol sends the string as is, and reads bytes until the
> >>EOL byte is seen. EOL can be defined by the property tcp.eolByte.
>
> In my application all server responses end with a "5".
> We achive this by appending (char)5 at the end to the String to be sent .
>
> like String txtTosend = "some data "+(char)5
>
> stream.write(txtTosend.getBytes());
>
>
> So now can I give 5 for tcp.eolByte so that Jmeter reads entire response
> string/data ???
So long as "5" does not appear anywhere else in the data, yes.
Otherwise you'll need to create your own TCPClientImpl class.
>
> ==
>
> >>JMeter is built around the assumption of a request/response sample.
>
> >>There's currently no provision for reading from a socket without
> >>previously writing to it, but that would be trivial to add - I may
> >>well add that to the nightly code shortly. Or indeed it may already
> >>work if you provide an empty string.
>
> >>But the test plan would have to include samplers for each expected
> >>server response.
>
> >>If a single client request results in a known number of responses, or
> >>there is some other way of telling that the server has finished
> >>responding to the original request, then the TCPClientImpl read()
> >>method could implement this.
>
> can you eloborate on this or tell me about the resources where I can find
> details.
> S.
See above. Also have a look at the source for the classes I mentioned.
> >
>
>
> Regards
>
> Srikanth.P
>
> Disclaimer
> ------------------------------------------------------------------------------------
> This e-mail message may contain confidential, proprietary
> or legally privileged information. It should not be used by
> anyone who is not the original intended recipient. If you
> have erroneously received this message, please delete it
> immediately and notify the sender.
>
> The views, opinions, conclusions and other information
> expressed in this electronic mail are those of the
> individual sender and not endorsed by SDG Software
> Technologies Pvt. Ltd. unless otherwise indicated by an
> authorised representative independent of this message.
>
> Before opening any attachment please check them for viruses
> and defects. SDG Software Technologies Pvt. Ltd. shall not
> accept responsibility for any loss or damage arising from
> the use of this email or attachment(s).
> -------------------------------------------------------------------------------------
>
> ________________________________
> How much free photo storage do you get? Store your friends n family photos
> for FREE with Yahoo! Photos.
> http://in.photos.yahoo.com ________________________________
> How much free photo storage do you get? Store your friends n family photos
> for FREE with Yahoo! Photos.
> http://in.photos.yahoo.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by sebb <se...@gmail.com>.
On 22/07/05, srikanth peddireddy <sr...@yahoo.co.in> wrote:
> hmm , I am happy that my naive question about extending TcpSampler has triggerd this kind of a discussion. Its good to be part of such discussion (though I understood very few things in it) where Jmter stalwarts are discussing its internals.
>
> sebb your statement which says
>
> "It seems the TCP Sampler already re-uses connections within a thread. "
>
> essentially means that a single socket is shared across all TcpSamplers and there is no need for me to extend it in the way i planned.
Yes.
> If that is the case, its fantastic (hurray Jmeter solved my problem yet again and that too with out writing single line of code)
>
Well, it solves that particular problem.
You may still need to create your own version of TCPClientImpl if the
protocol it implements is not suitable. But that should be fairly
simple for someone with even a little experience of writing Java.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by srikanth peddireddy <sr...@yahoo.co.in>.
hmm , I am happy that my naive question about extending TcpSampler has triggerd this kind of a discussion. Its good to be part of such discussion (though I understood very few things in it) where Jmter stalwarts are discussing its internals.
sebb your statement which says
"It seems the TCP Sampler already re-uses connections within a thread. "
essentially means that a single socket is shared across all TcpSamplers and there is no need for me to extend it in the way i planned.
If that is the case, its fantastic (hurray Jmeter solved my problem yet again and that too with out writing single line of code)
Hope some day I will get a chance to work on jmeter internals and contribite to the this great open source movement
with regards
Srikanth.P
sebb <se...@gmail.com> wrote:
Thanks again - that would be SearchByClass.
I see now that JMeterThread already uses that to find the Listeners,
so it could also use it find the new interface, and use that to call
the threadStarted and threadFinished methods. Might get a chance to
commit that later tonight.
S.
On 21/07/05, Michael Stover wrote:
> There is a tree traverser that knows how to search for all objects of a
> certain type. So, that provides a very convenient way to find all the
> ThreadListeners.
>
> -Mike
>
> On Thu, 2005-07-21 at 16:44 +0100, sebb wrote:
> > Oops, that's my fault - I implemented it over a year ago, and promptly
> > forgot about it ...
> >
> > Obviously I thought it was useful at the time, but I did not consider
> > the effect on test startup/shutdown.
> >
> > Looking at it again now, I suppose the cloneTree method could check
> > for the appropriate interface and save the appropriate objects in a
> > collection associated with the thread, and use that collection to
> > invoke the threadStarted/Finished methods.
> >
> > Simply changing the existing code to check if the interface was
> > implemented before calling the method would probably just increase the
> > work done.
> >
> > S.
> > On 21/07/05, Michael Stover wrote:
> > > Well, I was a little surprised to discover this method is a part of
> > > every TestElement. That seems like overkill, and maybe it would be more
> > > appropriate for it to be a separate interface that any element can
> > > implement. If every Test Element object instance in a test has to have
> > > it's "threadFinished()" method called, I can see that slowing down test
> > > shutdown on large tests.
> > >
> > > -Mike
> > >
> > > On Thu, 2005-07-21 at 15:44 +0100, sebb wrote:
> > > > That's a lot simpler - don't know how I managed to miss that one.
> > > >
> > > > S.
> > > > On 21/07/05, Michael Stover wrote:
> > > > > On Thu, 2005-07-21 at 15:17 +0100, sebb wrote:
> > > > > > On 21/07/05, Michael Stover wrote:
> > > > > > > JMeter has a global namespace and thread-specific namespaces. Seems to
> > > > > > > me you would want to store your socket in the thread-specific namespace,
> > > > > > > and any TCP Sampler can retrieve it from there. Each one should also be
> > > > > > > able to create a new one if it does not yet exist, and at test end, the
> > > > > > > sampler should make sure to clean it out (implement TestListener).
> > > > > >
> > > > > > If I recall correctly, the TestListener testEnded() method is called
> > > > > > from a single, different thread - and only one instance is called. The
> > > > > > existing TCP sampler uses a private static Set to keep track of these.
> > > > >
> > > > > That's a good point. Instead, each element can override the
> > > > > threadFinished() method of TestElement to do this sort of cleanup.
> > > > >
> > > > > -Mike
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------
Free antispam, antivirus and 1GB to save all your messages
Only in Yahoo! Mail: http://in.mail.yahoo.com
Re: TCP session
Posted by sebb <se...@gmail.com>.
Thanks again - that would be SearchByClass.
I see now that JMeterThread already uses that to find the Listeners,
so it could also use it find the new interface, and use that to call
the threadStarted and threadFinished methods. Might get a chance to
commit that later tonight.
S.
On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> There is a tree traverser that knows how to search for all objects of a
> certain type. So, that provides a very convenient way to find all the
> ThreadListeners.
>
> -Mike
>
> On Thu, 2005-07-21 at 16:44 +0100, sebb wrote:
> > Oops, that's my fault - I implemented it over a year ago, and promptly
> > forgot about it ...
> >
> > Obviously I thought it was useful at the time, but I did not consider
> > the effect on test startup/shutdown.
> >
> > Looking at it again now, I suppose the cloneTree method could check
> > for the appropriate interface and save the appropriate objects in a
> > collection associated with the thread, and use that collection to
> > invoke the threadStarted/Finished methods.
> >
> > Simply changing the existing code to check if the interface was
> > implemented before calling the method would probably just increase the
> > work done.
> >
> > S.
> > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > Well, I was a little surprised to discover this method is a part of
> > > every TestElement. That seems like overkill, and maybe it would be more
> > > appropriate for it to be a separate interface that any element can
> > > implement. If every Test Element object instance in a test has to have
> > > it's "threadFinished()" method called, I can see that slowing down test
> > > shutdown on large tests.
> > >
> > > -Mike
> > >
> > > On Thu, 2005-07-21 at 15:44 +0100, sebb wrote:
> > > > That's a lot simpler - don't know how I managed to miss that one.
> > > >
> > > > S.
> > > > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > > > On Thu, 2005-07-21 at 15:17 +0100, sebb wrote:
> > > > > > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > JMeter has a global namespace and thread-specific namespaces. Seems to
> > > > > > > me you would want to store your socket in the thread-specific namespace,
> > > > > > > and any TCP Sampler can retrieve it from there. Each one should also be
> > > > > > > able to create a new one if it does not yet exist, and at test end, the
> > > > > > > sampler should make sure to clean it out (implement TestListener).
> > > > > >
> > > > > > If I recall correctly, the TestListener testEnded() method is called
> > > > > > from a single, different thread - and only one instance is called. The
> > > > > > existing TCP sampler uses a private static Set to keep track of these.
> > > > >
> > > > > That's a good point. Instead, each element can override the
> > > > > threadFinished() method of TestElement to do this sort of cleanup.
> > > > >
> > > > > -Mike
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> 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: TCP session
Posted by Michael Stover <ms...@apache.org>.
There is a tree traverser that knows how to search for all objects of a
certain type. So, that provides a very convenient way to find all the
ThreadListeners.
-Mike
On Thu, 2005-07-21 at 16:44 +0100, sebb wrote:
> Oops, that's my fault - I implemented it over a year ago, and promptly
> forgot about it ...
>
> Obviously I thought it was useful at the time, but I did not consider
> the effect on test startup/shutdown.
>
> Looking at it again now, I suppose the cloneTree method could check
> for the appropriate interface and save the appropriate objects in a
> collection associated with the thread, and use that collection to
> invoke the threadStarted/Finished methods.
>
> Simply changing the existing code to check if the interface was
> implemented before calling the method would probably just increase the
> work done.
>
> S.
> On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > Well, I was a little surprised to discover this method is a part of
> > every TestElement. That seems like overkill, and maybe it would be more
> > appropriate for it to be a separate interface that any element can
> > implement. If every Test Element object instance in a test has to have
> > it's "threadFinished()" method called, I can see that slowing down test
> > shutdown on large tests.
> >
> > -Mike
> >
> > On Thu, 2005-07-21 at 15:44 +0100, sebb wrote:
> > > That's a lot simpler - don't know how I managed to miss that one.
> > >
> > > S.
> > > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > > On Thu, 2005-07-21 at 15:17 +0100, sebb wrote:
> > > > > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > JMeter has a global namespace and thread-specific namespaces. Seems to
> > > > > > me you would want to store your socket in the thread-specific namespace,
> > > > > > and any TCP Sampler can retrieve it from there. Each one should also be
> > > > > > able to create a new one if it does not yet exist, and at test end, the
> > > > > > sampler should make sure to clean it out (implement TestListener).
> > > > >
> > > > > If I recall correctly, the TestListener testEnded() method is called
> > > > > from a single, different thread - and only one instance is called. The
> > > > > existing TCP sampler uses a private static Set to keep track of these.
> > > >
> > > > That's a good point. Instead, each element can override the
> > > > threadFinished() method of TestElement to do this sort of cleanup.
> > > >
> > > > -Mike
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by sebb <se...@gmail.com>.
Oops, that's my fault - I implemented it over a year ago, and promptly
forgot about it ...
Obviously I thought it was useful at the time, but I did not consider
the effect on test startup/shutdown.
Looking at it again now, I suppose the cloneTree method could check
for the appropriate interface and save the appropriate objects in a
collection associated with the thread, and use that collection to
invoke the threadStarted/Finished methods.
Simply changing the existing code to check if the interface was
implemented before calling the method would probably just increase the
work done.
S.
On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> Well, I was a little surprised to discover this method is a part of
> every TestElement. That seems like overkill, and maybe it would be more
> appropriate for it to be a separate interface that any element can
> implement. If every Test Element object instance in a test has to have
> it's "threadFinished()" method called, I can see that slowing down test
> shutdown on large tests.
>
> -Mike
>
> On Thu, 2005-07-21 at 15:44 +0100, sebb wrote:
> > That's a lot simpler - don't know how I managed to miss that one.
> >
> > S.
> > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > On Thu, 2005-07-21 at 15:17 +0100, sebb wrote:
> > > > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > > > JMeter has a global namespace and thread-specific namespaces. Seems to
> > > > > me you would want to store your socket in the thread-specific namespace,
> > > > > and any TCP Sampler can retrieve it from there. Each one should also be
> > > > > able to create a new one if it does not yet exist, and at test end, the
> > > > > sampler should make sure to clean it out (implement TestListener).
> > > >
> > > > If I recall correctly, the TestListener testEnded() method is called
> > > > from a single, different thread - and only one instance is called. The
> > > > existing TCP sampler uses a private static Set to keep track of these.
> > >
> > > That's a good point. Instead, each element can override the
> > > threadFinished() method of TestElement to do this sort of cleanup.
> > >
> > > -Mike
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> 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: TCP session
Posted by Michael Stover <ms...@apache.org>.
Well, I was a little surprised to discover this method is a part of
every TestElement. That seems like overkill, and maybe it would be more
appropriate for it to be a separate interface that any element can
implement. If every Test Element object instance in a test has to have
it's "threadFinished()" method called, I can see that slowing down test
shutdown on large tests.
-Mike
On Thu, 2005-07-21 at 15:44 +0100, sebb wrote:
> That's a lot simpler - don't know how I managed to miss that one.
>
> S.
> On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > On Thu, 2005-07-21 at 15:17 +0100, sebb wrote:
> > > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > > JMeter has a global namespace and thread-specific namespaces. Seems to
> > > > me you would want to store your socket in the thread-specific namespace,
> > > > and any TCP Sampler can retrieve it from there. Each one should also be
> > > > able to create a new one if it does not yet exist, and at test end, the
> > > > sampler should make sure to clean it out (implement TestListener).
> > >
> > > If I recall correctly, the TestListener testEnded() method is called
> > > from a single, different thread - and only one instance is called. The
> > > existing TCP sampler uses a private static Set to keep track of these.
> >
> > That's a good point. Instead, each element can override the
> > threadFinished() method of TestElement to do this sort of cleanup.
> >
> > -Mike
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by sebb <se...@gmail.com>.
That's a lot simpler - don't know how I managed to miss that one.
S.
On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> On Thu, 2005-07-21 at 15:17 +0100, sebb wrote:
> > On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > > JMeter has a global namespace and thread-specific namespaces. Seems to
> > > me you would want to store your socket in the thread-specific namespace,
> > > and any TCP Sampler can retrieve it from there. Each one should also be
> > > able to create a new one if it does not yet exist, and at test end, the
> > > sampler should make sure to clean it out (implement TestListener).
> >
> > If I recall correctly, the TestListener testEnded() method is called
> > from a single, different thread - and only one instance is called. The
> > existing TCP sampler uses a private static Set to keep track of these.
>
> That's a good point. Instead, each element can override the
> threadFinished() method of TestElement to do this sort of cleanup.
>
> -Mike
>
>
> ---------------------------------------------------------------------
> 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: TCP session
Posted by Michael Stover <ms...@apache.org>.
On Thu, 2005-07-21 at 15:17 +0100, sebb wrote:
> On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> > JMeter has a global namespace and thread-specific namespaces. Seems to
> > me you would want to store your socket in the thread-specific namespace,
> > and any TCP Sampler can retrieve it from there. Each one should also be
> > able to create a new one if it does not yet exist, and at test end, the
> > sampler should make sure to clean it out (implement TestListener).
>
> If I recall correctly, the TestListener testEnded() method is called
> from a single, different thread - and only one instance is called. The
> existing TCP sampler uses a private static Set to keep track of these.
That's a good point. Instead, each element can override the
threadFinished() method of TestElement to do this sort of cleanup.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by sebb <se...@gmail.com>.
On 21/07/05, Michael Stover <ms...@apache.org> wrote:
> JMeter has a global namespace and thread-specific namespaces. Seems to
> me you would want to store your socket in the thread-specific namespace,
> and any TCP Sampler can retrieve it from there. Each one should also be
> able to create a new one if it does not yet exist, and at test end, the
> sampler should make sure to clean it out (implement TestListener).
If I recall correctly, the TestListener testEnded() method is called
from a single, different thread - and only one instance is called. The
existing TCP sampler uses a private static Set to keep track of these.
In fact, when I now look at the TCPSampler code, it seems it already
implements per-thread sockets!
I'd forgotten that had already been done ... sorry about that.
Try turning on debug logging for the sampler and you should see when
the socket is re-used.
However, the protocol class may still need to be updated to handle the
end of the server response correctly.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by Michael Stover <ms...@apache.org>.
JMeter has a global namespace and thread-specific namespaces. Seems to
me you would want to store your socket in the thread-specific namespace,
and any TCP Sampler can retrieve it from there. Each one should also be
able to create a new one if it does not yet exist, and at test end, the
sampler should make sure to clean it out (implement TestListener).
To access the thread-specific storage area:
JMeterContextService.getContext().getVariables().putObject
("sharedSocketReference",sharedSocket);
and
JMeterContextService.getContext().getVariables.getObject
("sharedSocketReference")
Calling these methods guarantees you are only talking to the current
thread's storage space.
-Mike
On Thu, 2005-07-21 at 13:22 +0100, srikanth peddireddy wrote:
> Hi Sebb,
>
> can you please answer some more questions on this topic. I gave some of my assumptions and dopubts below your response
>
> >>The current TCP Sampler creates a new socket for each sampler
> >>occurrence in each thread. I do plan to add re-usable sockets to the
> >>TCP Sampler, but that probably won't be for a few weeks.
>
> First I planned to extend the TCPsampler by myself and though of a design like this :
> There will be a specialized TcpSampler(for discussion lets call it SharedTcpSampler) . Instances of this SharedTcpSampler will be used for all the TCP requests that we want to make to a server over a single connection/socket.
> This SharedTcpSampler will have a property called "sharedSocketReference" which will be something like a reference name that we give to a global counter inorder to use it else where in testplan.
> Each SharedTcpSampler will first try to get the socket instance by searching for it in a Global NameSpace (Iam yet to know what this Global Name Space would be in Jmeter context) by giving the "sharedSocketReference" value that user will configure in testplan.
>
> If this search is successful,( ie some other SharedTcpSampler in the testplan has already created a socket connection and registered it under this name), then it will send its "Text To send" (inherited from TcpSampler) over that socket and reads back the response.
>
> If this search fails , which will be the case with first SharedTcpSampler in the testplan , it will create a new socket and register it in a Global NameSpace under the name specified in "sharedSocketReference" and continues using it for implmenting the protocol
>
> So in this solution, all the SharedTcpSamplers in a testplan with same value given in their "sharedSocketReference" property will share a single socket connection. Hence I think it will serve the purpose.
>
> But I know that inorder to implement this I need to know the architecture of Jmeter and different components of it in detail. I was unable to study this any further as I was tied to some other work. :-(
> Sebb, can you please tell me whether this design fits the bill. If yes please direct me towards some resources thru which I can quickly learn about architecture and components of Jemter and implement this.
> Iam planning to do this as soon as possible. :-)
>
> >>One way to re-use the same socket might to have only a single sampler,
> >>and vary the content of the request using a function call to read it
> >>from a file.
>
> can you eloborate on this or tell me about the resources where I can find details.
>
> >>However, I've not tried this.
>
>
> ==
>
> >>Note that the TCPSampler class is the one that creates the socket. The
> >>TCPClientImpl class uses the socket to implement the protocol.
>
> >>The current protocol sends the string as is, and reads bytes until the
> >>EOL byte is seen. EOL can be defined by the property tcp.eolByte.
>
> In my application all server responses end with a "5".
> We achive this by appending (char)5 at the end to the String to be sent .
>
> like String txtTosend = "some data "+(char)5
>
> stream.write(txtTosend.getBytes());
>
>
> So now can I give 5 for tcp.eolByte so that Jmeter reads entire response string/data ???
>
>
> ==
>
> >>JMeter is built around the assumption of a request/response sample.
>
> >>There's currently no provision for reading from a socket without
> >>previously writing to it, but that would be trivial to add - I may
> >>well add that to the nightly code shortly. Or indeed it may already
> >>work if you provide an empty string.
>
> >>But the test plan would have to include samplers for each expected
> >>server response.
>
> >>If a single client request results in a known number of responses, or
> >>there is some other way of telling that the server has finished
> >>responding to the original request, then the TCPClientImpl read()
> >>method could implement this.
>
> can you eloborate on this or tell me about the resources where I can find details.
> S.
> >
>
>
> Regards
>
> Srikanth.P
>
>
> Disclaimer
> ------------------------------------------------------------------------------------
> This e-mail message may contain confidential, proprietary
> or legally privileged information. It should not be used by
> anyone who is not the original intended recipient. If you
> have erroneously received this message, please delete it
> immediately and notify the sender.
>
> The views, opinions, conclusions and other information
> expressed in this electronic mail are those of the
> individual sender and not endorsed by SDG Software
> Technologies Pvt. Ltd. unless otherwise indicated by an
> authorised representative independent of this message.
>
> Before opening any attachment please check them for viruses
> and defects. SDG Software Technologies Pvt. Ltd. shall not
> accept responsibility for any loss or damage arising from
> the use of this email or attachment(s).
> -------------------------------------------------------------------------------------
>
> ---------------------------------
> How much free photo storage do you get? Store your friends n family photos for FREE with Yahoo! Photos.
> http://in.photos.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: TCP session
Posted by srikanth peddireddy <sr...@yahoo.co.in>.
Hi Sebb,
can you please answer some more questions on this topic. I gave some of my assumptions and dopubts below your response
>>The current TCP Sampler creates a new socket for each sampler
>>occurrence in each thread. I do plan to add re-usable sockets to the
>>TCP Sampler, but that probably won't be for a few weeks.
First I planned to extend the TCPsampler by myself and though of a design like this :
There will be a specialized TcpSampler(for discussion lets call it SharedTcpSampler) . Instances of this SharedTcpSampler will be used for all the TCP requests that we want to make to a server over a single connection/socket.
This SharedTcpSampler will have a property called "sharedSocketReference" which will be something like a reference name that we give to a global counter inorder to use it else where in testplan.
Each SharedTcpSampler will first try to get the socket instance by searching for it in a Global NameSpace (Iam yet to know what this Global Name Space would be in Jmeter context) by giving the "sharedSocketReference" value that user will configure in testplan.
If this search is successful,( ie some other SharedTcpSampler in the testplan has already created a socket connection and registered it under this name), then it will send its "Text To send" (inherited from TcpSampler) over that socket and reads back the response.
If this search fails , which will be the case with first SharedTcpSampler in the testplan , it will create a new socket and register it in a Global NameSpace under the name specified in "sharedSocketReference" and continues using it for implmenting the protocol
So in this solution, all the SharedTcpSamplers in a testplan with same value given in their "sharedSocketReference" property will share a single socket connection. Hence I think it will serve the purpose.
But I know that inorder to implement this I need to know the architecture of Jmeter and different components of it in detail. I was unable to study this any further as I was tied to some other work. :-(
Sebb, can you please tell me whether this design fits the bill. If yes please direct me towards some resources thru which I can quickly learn about architecture and components of Jemter and implement this.
Iam planning to do this as soon as possible. :-)
>>One way to re-use the same socket might to have only a single sampler,
>>and vary the content of the request using a function call to read it
>>from a file.
can you eloborate on this or tell me about the resources where I can find details.
>>However, I've not tried this.
==
>>Note that the TCPSampler class is the one that creates the socket. The
>>TCPClientImpl class uses the socket to implement the protocol.
>>The current protocol sends the string as is, and reads bytes until the
>>EOL byte is seen. EOL can be defined by the property tcp.eolByte.
In my application all server responses end with a "5".
We achive this by appending (char)5 at the end to the String to be sent .
like String txtTosend = "some data "+(char)5
stream.write(txtTosend.getBytes());
So now can I give 5 for tcp.eolByte so that Jmeter reads entire response string/data ???
==
>>JMeter is built around the assumption of a request/response sample.
>>There's currently no provision for reading from a socket without
>>previously writing to it, but that would be trivial to add - I may
>>well add that to the nightly code shortly. Or indeed it may already
>>work if you provide an empty string.
>>But the test plan would have to include samplers for each expected
>>server response.
>>If a single client request results in a known number of responses, or
>>there is some other way of telling that the server has finished
>>responding to the original request, then the TCPClientImpl read()
>>method could implement this.
can you eloborate on this or tell me about the resources where I can find details.
S.
>
Regards
Srikanth.P
Disclaimer
------------------------------------------------------------------------------------
This e-mail message may contain confidential, proprietary
or legally privileged information. It should not be used by
anyone who is not the original intended recipient. If you
have erroneously received this message, please delete it
immediately and notify the sender.
The views, opinions, conclusions and other information
expressed in this electronic mail are those of the
individual sender and not endorsed by SDG Software
Technologies Pvt. Ltd. unless otherwise indicated by an
authorised representative independent of this message.
Before opening any attachment please check them for viruses
and defects. SDG Software Technologies Pvt. Ltd. shall not
accept responsibility for any loss or damage arising from
the use of this email or attachment(s).
-------------------------------------------------------------------------------------
---------------------------------
How much free photo storage do you get? Store your friends n family photos for FREE with Yahoo! Photos.
http://in.photos.yahoo.com
Re: TCP session
Posted by sebb <se...@gmail.com>.
The current TCP Sampler creates a new socket for each sampler
occurrence in each thread. I do plan to add re-usable sockets to the
TCP Sampler, but that probably won't be for a few weeks.
One way to re-use the same socket might to have only a single sampler,
and vary the content of the request using a function call to read it
from a file.
However, I've not tried this.
==
Note that the TCPSampler class is the one that creates the socket. The
TCPClientImpl class uses the socket to implement the protocol.
The current protocol sends the string as is, and reads bytes until the
EOL byte is seen. EOL can be defined by the property tcp.eolByte.
==
JMeter is built around the assumption of a request/response sample.
There's currently no provision for reading from a socket without
previously writing to it, but that would be trivial to add - I may
well add that to the nightly code shortly. Or indeed it may already
work if you provide an empty string.
But the test plan would have to include samplers for each expected
server response.
If a single client request results in a known number of responses, or
there is some other way of telling that the server has finished
responding to the original request, then the TCPClientImpl read()
method could implement this.
S.
On 21/07/05, Zohar Amir <da...@hotmail.com> wrote:
> Thanks, but I think I did not explain myself clear enough.
> The session is set up by opening a TCP connection and sending a login
> request. From that point on, all transactions (both from the server and from
> the client) are sent on that same connection (=same socket). I suspect
> Jmeter was build with HTTP in mind and a symmetrical protocol (e.g., TCP)
> challenges its design.
> Any help on this please?
>
> ----- Original Message -----
> From: "Christian Baumgartner" <ch...@tiscover.com>
> To: "'JMeter Users List'" <jm...@jakarta.apache.org>
> Sent: Thursday, July 21, 2005 9:27 AM
> Subject: AW: TCP session
>
>
> Maybe you want to use the URL REWRITE MODIFIER that stores the session ID
> and replaces it in every request. (if you use session id in you r URL.. Else
> there is the posibility to use the cookie manager that fetches the cookies,
> and you can use them as normal variables for assertions ..
>
> Maybe you specify in more detail how the session is set up, what method is
> used (think it is a session).
>
>
> -----Ursprüngliche Nachricht-----
> Von: Zohar Amir [mailto:david_fire4@hotmail.com]
> Gesendet: Donnerstag, 21. Juli 2005 07:16
> An: jmeter-user@jakarta.apache.org
> Betreff: TCP session
>
>
> Hi,
> I need to emulate a client's behavior with Jemeter. The client connects to
> the server via TCP. The connection is set up on login and kept throughout
> the session, where transactions are exchanged with the server. Any way of
> doing his with Jmeter? I probably need to open a TCP socket on
> startup and use this same socket for all transactions. I also need a thread
> listening on the socket for incoming transactions.
> Thanks,
> Zohar.
>
> ---------------------------------------------------------------------
> 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
>
>
> ---------------------------------------------------------------------
> 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: TCP session
Posted by Zohar Amir <da...@hotmail.com>.
Thanks, but I think I did not explain myself clear enough.
The session is set up by opening a TCP connection and sending a login
request. From that point on, all transactions (both from the server and from
the client) are sent on that same connection (=same socket). I suspect
Jmeter was build with HTTP in mind and a symmetrical protocol (e.g., TCP)
challenges its design.
Any help on this please?
----- Original Message -----
From: "Christian Baumgartner" <ch...@tiscover.com>
To: "'JMeter Users List'" <jm...@jakarta.apache.org>
Sent: Thursday, July 21, 2005 9:27 AM
Subject: AW: TCP session
Maybe you want to use the URL REWRITE MODIFIER that stores the session ID
and replaces it in every request. (if you use session id in you r URL.. Else
there is the posibility to use the cookie manager that fetches the cookies,
and you can use them as normal variables for assertions ..
Maybe you specify in more detail how the session is set up, what method is
used (think it is a session).
-----Ursprüngliche Nachricht-----
Von: Zohar Amir [mailto:david_fire4@hotmail.com]
Gesendet: Donnerstag, 21. Juli 2005 07:16
An: jmeter-user@jakarta.apache.org
Betreff: TCP session
Hi,
I need to emulate a client's behavior with Jemeter. The client connects to
the server via TCP. The connection is set up on login and kept throughout
the session, where transactions are exchanged with the server. Any way of
doing his with Jmeter? I probably need to open a TCP socket on
startup and use this same socket for all transactions. I also need a thread
listening on the socket for incoming transactions.
Thanks,
Zohar.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: AW: TCP session
Posted by srikanth peddireddy <sr...@yahoo.co.in>.
i think Zohar is not talking about HTTP sessions.
he wants to test a scenario where number of clients connect to a server via a TCP connection (socket) and keep on doing some action over that socket connection(like requesting some data) and server will respond with some other data.
I too need to test a similar scenario. we can use TCP sampler but it creates a new TCP connection for each request sent to server.So it is not useful as-it-is.
I was advised to develop my TcpClientImpl . Though I designed some sort of solution for it, i cant persuade the issue due to time constraints.
Any new inputs or help will be appreciated.
regards
Srikanth.P
Christian Baumgartner <ch...@tiscover.com> wrote:
Maybe you want to use the URL REWRITE MODIFIER that stores the session ID
and replaces it in every request. (if you use session id in you r URL.. Else
there is the posibility to use the cookie manager that fetches the cookies,
and you can use them as normal variables for assertions ..
Maybe you specify in more detail how the session is set up, what method is
used (think it is a session).
-----Ursprüngliche Nachricht-----
Von: Zohar Amir [mailto:david_fire4@hotmail.com]
Gesendet: Donnerstag, 21. Juli 2005 07:16
An: jmeter-user@jakarta.apache.org
Betreff: TCP session
Hi,
I need to emulate a client's behavior with Jemeter. The client connects to
the server via TCP. The connection is set up on login and kept throughout
the session, where transactions are exchanged with the server. Any way of
doing his with Jmeter? I probably need to open a TCP socket on
startup and use this same socket for all transactions. I also need a thread
listening on the socket for incoming transactions.
Thanks,
Zohar.
---------------------------------------------------------------------
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
---------------------------------
Free antispam, antivirus and 1GB to save all your messages
Only in Yahoo! Mail: http://in.mail.yahoo.com
AW: TCP session
Posted by Christian Baumgartner <ch...@tiscover.com>.
Maybe you want to use the URL REWRITE MODIFIER that stores the session ID
and replaces it in every request. (if you use session id in you r URL.. Else
there is the posibility to use the cookie manager that fetches the cookies,
and you can use them as normal variables for assertions ..
Maybe you specify in more detail how the session is set up, what method is
used (think it is a session).
-----Ursprüngliche Nachricht-----
Von: Zohar Amir [mailto:david_fire4@hotmail.com]
Gesendet: Donnerstag, 21. Juli 2005 07:16
An: jmeter-user@jakarta.apache.org
Betreff: TCP session
Hi,
I need to emulate a client's behavior with Jemeter. The client connects to
the server via TCP. The connection is set up on login and kept throughout
the session, where transactions are exchanged with the server. Any way of
doing his with Jmeter? I probably need to open a TCP socket on
startup and use this same socket for all transactions. I also need a thread
listening on the socket for incoming transactions.
Thanks,
Zohar.
---------------------------------------------------------------------
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