I've added some logging to the WebService sampler, which shows the file names used.
The code is in the nightly build of Feb 15. Perhaps you could give it a try? S. On 15/02/06, sebb <[EMAIL PROTECTED]> wrote: > ThreadName alone would not work, as there may be multiple samplers per thread. > > However filename alone should surely be enough - unless the file > content changes during a run, which would not be a good idea. > > This is why I don't understand what's happening at present... > > S. > On 15/02/06, Peter Lin <[EMAIL PROTECTED]> wrote: > > :) > > > > yeah, it just uses the filename, rather than the thread name. it's probably > > easy enough to do threadName + filename, or just threadName. > > > > peter > > > > > > On 2/15/06, sebb <[EMAIL PROTECTED]> wrote: > > > > > > I had a quick look at the cache last night - I think it uses the file > > > name as the key. > > > > > > I can add some debug to the code to show which cache entry is being > > > used. That might help pin down the problem. I'll give that a go > > > tonight hopefully and create a new nightly build. > > > > > > Seems to me that the cache can be shared by all threads, so long as > > > the content of each entry does not vary. > > > > > > S. > > > On 15/02/06, Ivan Rancati <[EMAIL PROTECTED]> wrote: > > > > I'd like to help, with > > > > a) attaching a simple test plan to bug 38640 > > > > b) if needed, testing the fix before it's released. > > > > > > > > What I'd need to know for (a) is if there is some Axis web service > > > > publicly accessible over the Internet. Does not need to be very fancy > > > > > > > > > > > > > > > > > > > > > > Subject: > > > > > Re: SOAP data repeated across different Webservice samplers > > > > > From: > > > > > sebb <[EMAIL PROTECTED]> > > > > > Date: > > > > > Tue, 14 Feb 2006 14:52:42 +0000 > > > > > To: > > > > > JMeter Users List <jmeter-user@jakarta.apache.org> > > > > > > > > > > To: > > > > > JMeter Users List <jmeter-user@jakarta.apache.org> > > > > > > > > > > > > > > > I may have some time to apply fixes in a shorter time span. > > > > > > > > > > However I don't have any experience of using SOAP so I would need help > > > > > from users to provide test cases etc. > > > > > > > > > > S. > > > > > On 14/02/06, Peter Lin <[EMAIL PROTECTED]> wrote: > > > > > > > > > >> the memory cache is very simple and stupid, and was meant as a way to > > > > >> improve JMeter's ability to generate higher loads. Basically, the > > > idea was > > > > >> to send the same SOAP message as fast as possible to stress a server. > > > > >> > > > > >> thanks for filing the bug, I probably won't have time to add the > > > enhancement > > > > >> for atleast 2-3 months. > > > > >> > > > > >> peter > > > > >> > > > > >> > > > > >> On 2/14/06, Ivan Rancati <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >>> In the meantime, I found out that the problem is the "Memory Cache" > > > > >>> option in the sampler > > > > >>> I logged a P3 bug (38640) anyway, as I believe the "Memory cache" > > > > >>> should cache the Soap request only across different threads for the > > > same > > > > >>> sampler, not across all samplers. Or have I misunderstood it? > > > > >>> > > > > >>> thanks > > > > >>> Ivan > > > > >>> > > > > >>> > > > > >>> Re: SOAP data repeated across different Webservice samplers > > > > >>> > > > > >>> sebb > > > > >>> Tue, 14 Feb 2006 03:31:08 -0800 > > > > >>> > > > > >>> Sounds like a bug. > > > > >>> > > > > >>> Please can you raise a Bugzilla issue, and attach a test-case etc? > > > > >>> > > > > >>> Thanks. > > > > >>> > > > > >>> On 14/02/06, Ivan Rancati <[EMAIL PROTECTED]> wrote: > > > > >>> > > > > >>>> I have a very simple test plan for a Web Service, which looks like > > > this > > > > >>>> > > > > >>>> Thread group (1 loop - 1 thread) > > > > >>>> User defined variables (http server name and port) > > > > >>>> HTTP Authorization Manager > > > > >>>> WebService(SOAP) Request > > > > >>>> Response Assertion > > > > >>>> WebService(SOAP) Request > > > > >>>> WebService(SOAP) Request > > > > >>>> WebService(SOAP) Request > > > > >>>> View Results Tree > > > > >>>> Assertion Results > > > > >>>> > > > > >>>> For the 4 requests, server ip, port number, path and SOAP Action > > > are the > > > > >>>> same > > > > >>>> The Soap/XML-RPC data changes only in the <email> part > > > > >>>> > > > > >>>> <soapenv:Envelope > > > > >>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; < > > > > >>>> > > > > >>> http://schemas.xmlsoap.org/soap/envelope/%22>; > > > > >>> > > > > >>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; < > > > > >>>> > > > > >>> http://www.w3.org/2001/XMLSchema%22>; > > > > >>> > > > > >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; < > > > > >>>> > > > > >>> http://www.w3.org/2001/XMLSchema-instance%22>;> > > > > >>> > > > > >>>> <soapenv:Body> > > > > >>>> <ns1:findCustomerByEmail > > > > >>>> soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; < > > > > >>>> > > > > >>> http://schemas.xmlsoap.org/soap/encoding/%22>; > > > > >>> > > > > >>>> xmlns:ns1="urn://mobility-platform.de/mpcustomerdb/"> > > > > >>>> <email xsi:type="xsd:string">[EMAIL > > > PROTECTED] > > > > >>>> </email> > > > > >>>> </ns1:findCustomerByEmail> > > > > >>>> </soapenv:Body> > > > > >>>> </soapenv:Envelope> > > > > >>>> > > > > >>>> When I run the test case, the same SOAP content is sent for all the > > > 4 > > > > >>>> requests. Is this a known issue? > > > > >>>> I have verified the behaviour by running through a proxy. > > > > >>>> > > > > >>>> In general, it looks like there is something strange with the > > > WebService > > > > >>>> requests: for example, if I change the order of the requests, I > > > have to > > > > >>>> close and reopen the test plan for the change to take effect. > > > > >>>> > > > > >>>> Server is running Debian Linux, and the webservice is Axis. > > > > >>>> On the client, I am running Suse 9.3, Jmeter 2.1.1 and JDK 1.5 > > > > >>>> > > > > >>>> > > > > >>>> thanks > > > > >>>> > > > > >>>> -- > > > > >>>> Ivan Rancati > > > > >>>> SharpMind QA > > > > >>>> > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
