Thanks for your answer. > If there is always a response, why not send the request, and then wait for the response?
Unfortunately, that would limit my concurrent number of requests to the number of sampling threads. And I want much more. Ex: what if I want to simulate 200 concurrent requests made by 3 client threads? That's why I'm thinking about to make my request sampler not waiting for response, returning a SampleResult related to the sending of request. At the same time, I can build another SampleResult related to the response that I just start in this sampler. Then, a new "response" sampler could just wait for responses and ending the SampleResult initiated in the request sample, for instance, by sharing a Map of SampleResult as a variable between them. I've actually seen this kind of discussion in the history of the mailing-list but there has been no follow-up... Fabrice -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: samedi 20 octobre 2007 01:48 To: JMeter Users List Subject: Re: Asynchronous samplers On 19/10/2007, DELHOSTE Fabrice <[EMAIL PROTECTED]> wrote: > Hi, > > I am currently trying to design a custom sampler upon an asynchronous > request-response API and I haven't found enough detailed discussion on > that topic. JMeter does not support asynchronous working per se. > I basically want to measure the time from sending the request to its > received response. If there is always a response, why not send the request, and then wait for the response? This can be done in a single sampler. > As far as I understand, there may be a need for even-driven sampler in > the future but what's the best way to do it today? We have no plans to implement event-driven samplers. > I have first tried to add subresults on the SampleResult of each > request when receiving responses (in another thread) without success. > Tree of results were not correctly updated and I haven't found the way > to publish them as new SampleResult instead of subresult. > > So I'm thinking a bit more now :-) ... about separating completely the > request sampler from the response sampler. > > I would typically have 2 thread groups, one for request, the other for > response. > The request sampler would send its request, not waiting for anything. > The response sampler would listen for a response until some is > received (using a shared lock with the listener initiated in request > sampler), then return it as SampleResult. I would just send the request and wait for the response. Everything else would be a lot more work. > In theory, I would obtain on one side, all my request data, and on the > other side, my response data, that I would be able to correlate with > my request...and then proceed naturally with all JMeter powerful stuff > on both groups. > > Before starting, I'd like to know if this seems possible to you. > Any advice, or another way to implement? > > Thanks, > Fabrice > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
