[Bug 60730] JSONPostProcessor does not set _ALL variable when only one match occurs

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60730

Rainer Jung  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Rainer Jung  ---
Fix will be part of version 3.2:

Author: rjung
Date: Mon Feb 13 21:31:47 2017
New Revision: 1782882

URL: http://svn.apache.org/viewvc?rev=1782882=rev
Log:
JSONPostProcessor does not set _ALL variable when only one match occurs

Bugzilla Id: 60730

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

[Bug 60729] RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

--- Comment #7 from Rainer Jung  ---
Author: rjung
Date: Mon Feb 13 21:23:23 2017
New Revision: 1782880

URL: http://svn.apache.org/viewvc?rev=1782880=rev
Log:
Add info about BZ 60729 (the Random Variable
Config Element should allow minimum==maximum)
to changes.

Modified:
jmeter/trunk/xdocs/changes.xml

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

[Bug 60714] java.nio.charset.MalformedInputException: Input length = 1

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60714

Philippe Mouawad  changed:

   What|Removed |Added

   Hardware|PC  |All
   Priority|P1  |P2
   Severity|critical|normal

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

[Bug 60664] Add a UI menu to set log level

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60664

--- Comment #3 from Woonsan Ko  ---
Created attachment 34753
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34753=edit
Log Level menu to set level to DEBUG for example

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

[Bug 58182] All Thread Groups do not start at the same time

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=58182

Philippe Mouawad  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Philippe Mouawad  ---
(In reply to Stuart Kenworthy from comment #3)
> Do we have any movement on this bug? My test rig is currently suffering
> heavily from this bug and
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58183 which is impacting my
> ability to run multiple thread groups in a planned amount of time.

Did you try setting delay to something high enough so that all threads are
created ?
What is your use case exactly ?
Thanks

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

[Bug 60664] Add a UI menu to set log level

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60664

--- Comment #4 from Woonsan Ko  ---
Created attachment 34754
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34754=edit
Logs showing DEBUG level after changing it to DEBUG (from INFO, the default
level) as an example

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

[Bug 60729] RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

--- Comment #6 from Rainer Jung  ---
> Hi Rainer, 
> Can't this fix break existing test plans ? I don't think so but you've
> investigated it more than me.
> Maybe a note in incompatible changes would be useful in this case.
> Thanks for patch and fix.

Behavior before that change: when minimum==maximum you got an error in the log,
but the test plan proceeded without the defined variable being set to any
value.

So yes, it can break plans and I will add a note, but I think just not setting
the variable when minimum==maximum is wrong. Thus the fix.

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

[Bug 60730] New: JSONPostProcessor does not set _ALL variable when only one match occurs

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60730

Bug ID: 60730
   Summary: JSONPostProcessor does not set _ALL variable when only
one match occurs
   Product: JMeter
   Version: 3.1
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Main
  Assignee: issues@jmeter.apache.org
  Reporter: rainer.j...@kippdata.de
  Target Milestone: ---

The JSONPostProcessor does not set the _ALL variable when only one match
occurs. The following patch fixes this:

Index:
src/components/org/apache/jmeter/extractor/json/jsonpath/JSONPostProcessor.java
===
---
src/components/org/apache/jmeter/extractor/json/jsonpath/JSONPostProcessor.java
(revision 1782848)
+++
src/components/org/apache/jmeter/extractor/json/jsonpath/JSONPostProcessor.java
(working copy)
@@ -163,7 +163,7 @@
 String suffix = (matchNumber < 0) ? "_1" : "";
 placeObjectIntoVars(vars, currentRefName + suffix,
extractedValues, 0);
 if (matchNumber < 0 && getComputeConcatenation())
{
-vars.put(currentRefName + ALL_SUFFIX,
vars.get(currentRefName));
+vars.put(currentRefName + ALL_SUFFIX,
vars.get(currentRefName + suffix));
 }
 }
 if (matchNumber != 0) {

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

[Bug 60729] RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

--- Comment #5 from UbikLoadPack support  ---
(In reply to Rainer Jung from comment #4)
> Will be part of version 3.2:
> 
> Author: rjung
> Date: Mon Feb 13 20:07:52 2017
> New Revision: 1782848
> 
> URL: http://svn.apache.org/viewvc?rev=1782848=rev
> Log:
> Allow minimum == maximum in Random Variable Config Element.
> 
> Bugzilla Id: 60729
> 
> Modified:
>
> jmeter/trunk/src/components/org/apache/jmeter/config/RandomVariableConfig.
> java

Hi Rainer, 
Can't this fix break existing test plans ? I don't think so but you've
investigated it more than me.
Maybe a note in incompatible changes would be useful in this case.
Thanks for patch and fix.

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

[Bug 60729] RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

Rainer Jung  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Rainer Jung  ---
Will be part of version 3.2:

Author: rjung
Date: Mon Feb 13 20:07:52 2017
New Revision: 1782848

URL: http://svn.apache.org/viewvc?rev=1782848=rev
Log:
Allow minimum == maximum in Random Variable Config Element.

Bugzilla Id: 60729

Modified:
   
jmeter/trunk/src/components/org/apache/jmeter/config/RandomVariableConfig.java

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

[Bug 60729] RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

--- Comment #3 from Rainer Jung  ---
Actzually these do not need changing. range comes from rangeL which was set to
rangeL=maximum-minimum+1, so for minimum==maximum range is and should be 1. So
comparing against 0 (which is used as a special marker value) is fine.

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

[Bug 60729] RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

--- Comment #2 from Rainer Jung  ---
Thanks. I'm in the middle of preparing tests. I'll include the fixes fpor the
other two comparisons.

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

[Bug 60729] RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

--- Comment #1 from Vladimir Sitnikov  ---
Have you tried that patch?

It looks other uses of range should be corrected as well:
https://github.com/vlsi/jmeter/blob/7ebfa083afd0b4e2be069b2a8a654bc33fe761cf/src/components/org/apache/jmeter/config/RandomVariableConfig.java#L99-L99
and
https://github.com/vlsi/jmeter/blob/7ebfa083afd0b4e2be069b2a8a654bc33fe761cf/src/components/org/apache/jmeter/config/RandomVariableConfig.java#L121.

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

[Bug 60729] New: RandomVariableConfig should allow minimum==maximum

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60729

Bug ID: 60729
   Summary: RandomVariableConfig should allow minimum==maximum
   Product: JMeter
   Version: 3.1
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Main
  Assignee: issues@jmeter.apache.org
  Reporter: rainer.j...@kippdata.de
  Target Milestone: ---

Currently RandomVariableConfig checks for maximum > minimum and complains
otherwise. I have a situation where I create random values using
RandomVariableConfig in some given range and sometimes I need that range to be
exactly one number.

E.g. the random value could be the number of products you want to buy but for a
simple base test you always want only one product. I retrieve minimum and
maximum from JMeter variables and it would be trivial to set both to "1" to get
that behavior.

Unfortunately RandomVariableConfig only accepts minimum < maximum, not minimum
== maximum. Note that the Random math still works for minimum == maximum,
because range = maximum - minimum + 1 would be 1 and we would generate minimum
+ randGen.nextInt(range) = minimum + randGen.nextInt(1) = minimum + 0 = minimum
(== maximum), which would be the expected result.

The docs do not mention the condition on minimum and maximum, so there's no
docs change involved.

I'm going to apply the following (trivial) patch unless someone opposes:

Index: components/org/apache/jmeter/config/RandomVariableConfig.java
===
--- components/org/apache/jmeter/config/RandomVariableConfig.java  
(revision 1782826)
+++ components/org/apache/jmeter/config/RandomVariableConfig.java  
(working copy)
@@ -91,8 +91,8 @@
 final String maxAsString = getMaximumValue();
 long maximum = NumberUtils.toLong(maxAsString);
 long rangeL=maximum-minimum+1; // This can overflow
-if (minimum >= maximum){
-log.error("maximum({}) must be > minimum({})", maxAsString,
minAsString);
+if (minimum > maximum){
+log.error("maximum({}) must be >= minimum({})", maxAsString,
minAsString);
 range=0;// This is used as an error indicator
 return;
 }

Regards,

Rainer

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

[Bug 60714] java.nio.charset.MalformedInputException: Input length = 1

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60714

--- Comment #3 from UbikLoadPack support  ---
(In reply to Frederic Girard from comment #2)
> Latest nightly (r1782718) fails to start with the following message :
> 
> An error occurred: class org.apache.log4j.spi.NOPLogger overrides final
> method getEffectiveLevel.()Lorg/apache/log4j/Level

Hi,
Are you sure you don't have incompatible 3rd party plugins ?
Can you attach jmeter.log ?
Thanks

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

[Bug 60714] java.nio.charset.MalformedInputException: Input length = 1

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60714

--- Comment #2 from Frederic Girard  ---
Latest nightly (r1782718) fails to start with the following message :

An error occurred: class org.apache.log4j.spi.NOPLogger overrides final method
getEffectiveLevel.()Lorg/apache/log4j/Level

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

[Bug 58182] All Thread Groups do not start at the same time

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=58182

--- Comment #3 from Stuart Kenworthy  ---
Do we have any movement on this bug? My test rig is currently suffering heavily
from this bug and https://bz.apache.org/bugzilla/show_bug.cgi?id=58183 which is
impacting my ability to run multiple thread groups in a planned amount of time.

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

[Bug 58183] Threads continue to build post ramp up time.

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=58183

--- Comment #2 from Stuart Kenworthy  ---
Do we have any movement on this bug? My test rig is currently suffering heavily
from this bug and https://bz.apache.org/bugzilla/show_bug.cgi?id=58182 which is
impacting my ability to run multiple thread groups in a planned amount of time.

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

[Bug 60727] Drop commons-httpclient-3.1 and related elements

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60727

UbikLoadPack support  changed:

   What|Removed |Added

 Depends on||59038


Referenced Bugs:

https://bz.apache.org/bugzilla/show_bug.cgi?id=59038
[Bug 59038] Deprecate HTTPClient 3.1 related elements
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60727] New: Drop commons-httpclient-3.1 and related elements

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60727

Bug ID: 60727
   Summary: Drop commons-httpclient-3.1 and related elements
   Product: JMeter
   Version: 3.1
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: HTTP
  Assignee: issues@jmeter.apache.org
  Reporter: supp...@ubikloadpack.com
  Target Milestone: ---

Related to Bug 59038 and dev mailing list discussion:
"Drop Commons-HttpClient 3.1"
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201512.mbox/%3CCAH9fUpZ8WMA9MBZZ8vwG%3DjCH-HhaAi8TPSMSfQ6NKcESky%2BD5Q%40mail.gmail.com%3E

Drop:

   - HTTPHC3Impl
   - SoapSampler
   - HTTPSampler2 used by SoapSampler
   - HC3CookieHandler
   - HttpHC3Impl
   - LoopbackHttpClientSocketFactory
   - SlowHttpClientSocketFactory

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

[Bug 60687] Make GUI more responsive when it gets a lot of events

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60687

--- Comment #16 from Vladimir Sitnikov  ---
Felix> Could you be a bit more specific here?

For instance,
1) Things like "model.insertRow" do require to be executed on the AWT thread.
I'm not sure how hard it could break, however accessing UI thread on the hot
path is bad.

2) Table rendering code (that is run on the UI thread) accesses computed values
without any synchronization. This might result in word tearing, stale values,
unexpected division by zero, etc.


Felix> Right. Get swing out of the path and be happy.

This kind of change would likely to heal 1 above, however it might look like a
"complete rewrite of the relevant listener code".

Even if we move swing calls out of hot path, we would still need some fast way
to aggregate values.
For instance, "Total" row could be computed "on UI refresh" to avoid global
synchronization of all the threads.

>From one point of view this might look like a over engineering, on the other
hand, that might be reused for "non-gui console mode" listeners.

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

[Bug 59038] Deprecate HTTPClient 3.1 related elements

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=59038

UbikLoadPack support  changed:

   What|Removed |Added

 Blocks||60727


Referenced Bugs:

https://bz.apache.org/bugzilla/show_bug.cgi?id=60727
[Bug 60727] Drop commons-httpclient-3.1 and related elements
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60727] Drop commons-httpclient-3.1 and related elements

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60727

--- Comment #1 from UbikLoadPack support  ---
Created attachment 34751
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34751=edit
Patch implementing feature

Hello,
Working on patch we saw that the Test Unit for Cache Manager and Java Impl was
in fact partly using HTTPClient 3.1.

Regards

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

[Bug 60727] Drop commons-httpclient-3.1 and related elements

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60727

UbikLoadPack support  changed:

   What|Removed |Added

  Attachment #34751|0   |1
is obsolete||

--- Comment #2 from UbikLoadPack support  ---
Created attachment 34752
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34752=edit
Patch implementing feature

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

[Bug 60687] Make GUI more responsive when it gets a lot of events

2017-02-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60687

--- Comment #15 from Felix Schumacher  ---
(In reply to Vladimir Sitnikov from comment #14)
> I think SummaryReport uses unsafe approach of updating ObjectTableModel in
> the sampling threads.

Could you be a bit more specific here? I think the only problem we have is
visibility, as the swing thread locks on lock and the other threads on lock and
rows. So I think of it as a kind of eventual visibility.

> 
> Does it make sense to decouple stats collection from stat visualization?

That was my first thought, but it would introduce another thread. We could drop
the row locks, though.

> 
> If I get it right, we should avoid using swing.* as a stat
> collection/aggregation facility.
> Otherwise we have to use Swing.invokeLater on the hot path.

Right. Get swing out of the path and be happy.

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