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 <[email protected]>
> > > >
> > > > To:
> > > > JMeter Users List <[email protected]>
> > > >
> > > >
> > > > 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]

Reply via email to