You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2018/04/19 11:50:20 UTC

[Bug 62315] New: "Save response to a file" Component - seems not be thread safe

https://bz.apache.org/bugzilla/show_bug.cgi?id=62315

            Bug ID: 62315
           Summary: "Save response to a file" Component - seems not be
                    thread safe
           Product: JMeter
           Version: 4.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: Main
          Assignee: issues@jmeter.apache.org
          Reporter: imarkovic@emisia.net
  Target Milestone: ---

We have recently moved from using JMeter 3.1 to 4.0. In one particular
scenario, we are saving server response (file content) to a zip file, and this
is done by 50 users concurrently. In next step we are uploading that file back
to the server.

Each user has its own path (variable) that consists of username and thread
number. 
Eg:
~/downloads/user1/thread5/file.zip

The problem is that some other users are taking other ones paths only when
saving file.
Eg:

user1 has variable ${path} = ~/downloads/user1/thread5/file.zip
user2 has variable ${path} = ~/downloads/user2/thread8/file.zip

user1 saves file to its own directory, and user2 instead of saving to its own
saves to user1 directory.

When they try to do upload, both are looking at the right variable - user1
finds the file, and user 2 doesn't, because he saved file at user1 location
(path in which his variable points is empty).

With this, I am almost sure that only "Save response to a file" is misbehaving.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 62315] "Save response to a file" Component - seems not to be thread safe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62315

--- Comment #4 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
The component is thread safe it is just that its properties are interpreted on
first call and not for every thread.

Nothing forbids your use case since the file name can be obtained in Variable
Name property and will be unique by thread.

if you think there is a behavioral change since 3.1, then please provide a test
case showing difference in behavior.

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 62315] "Save response to a file" Component - seems not to be thread safe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62315

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|PC                          |All
           Severity|blocker                     |normal

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 62315] "Save response to a file" Component - seems not to be thread safe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62315

Ivan Markovic <im...@emisia.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|"Save response to a file"   |"Save response to a file"
                   |Component - seems not be    |Component - seems not to be
                   |thread safe                 |thread safe

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 62315] "Save response to a file" Component - seems not to be thread safe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62315

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #2 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Author: pmouawad
Date: Fri Apr 20 15:16:36 2018
New Revision: 1829662

URL: http://svn.apache.org/viewvc?rev=1829662&view=rev
Log:
Bug 62315 - "Save response to a file" Component - seems not to be thread safe
Clarify documentation of ResultSaver
Bugzilla Id: 62315

Modified:
    jmeter/trunk/xdocs/usermanual/component_reference.xml

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 62315] "Save response to a file" Component - seems not to be thread safe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62315

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |p.mouawad@ubik-ingenierie.c
                   |                            |om

--- Comment #1 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Hello,
I think your issue is due to a misunderstanding of the component due to
documentation that should be improved.

Indeed, this component is shared across threads, and the "filename prefix" is
evaluated only once, so if you use threadnumber or username as variables in
this filename, it won't work as expected. 

I'll clarify documentation on this.

Regards

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 62315] "Save response to a file" Component - seems not to be thread safe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62315

--- Comment #3 from Ivan Markovic <im...@emisia.net> ---
If what are you saying is true, it's pretty big thing. Load testing of download
may be crucial, and asserting just response data cannot be suffice. Users must
be able to check file itself...

On the other hand, we have ran our tests hundreds of times on 3.1 (and prior)
and never had any issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.