RE: Why are HttpArguments always encoded?

2017-01-05 Thread Antony Bowesman
Wyatt,

> > However, this gets encoded, so I debugged the code and found that ALL
> > arguments created via HttpSamplerBase end up calling
> > setAlwaysEncoded(true), so the JSON body gets encoded when it's POSTed
> > and there's no nice way to prevent this.
> 
> That sounded really strange, but sure enough--  every constructor ultimately
> lowers to the one at line 131 of HTTPArgument.java!
> 
> I'd call it a bug.  Generously, a misfeature.  Evidently, it's even been a
> problem in the past, considering this definition at line 620 of
> HTTPSamplerBase.java:
> 
> public void addNonEncodedArgument(String name, String value, String
> metadata)
> 
> So in your specific case, I think you can work around it without any extra 
> code
> by just calling
> 
> sampler.addNonEncodedArgument("", body, "");

Ah yes, that I didn't see! I missed it as it has no Javadoc comments. That will 
work.

> 
> > Is this a built in limitation for some reason? It seems a rather
> > clunky solution.
> 
> You'll find a lot of weird decisions like this as you start digging into the 
> guts of
> JMeter.  Honestly?  From what I've seen, it's generally safe to assume you're
> hitting some form of legacy cruft that's lain dormant for ages because (for
> the most part ) the JMeter internal APIs were never intended for external
> consumers like you and I.  I know I would like this to change, and I think
> there's even some buy-in from the project leadership, but...
> well, that's the future not the present.

I didn't realise JMeter has been around since 1998, so I am not surprised 
there's legacy stuff around. Often the decisions are lost in time, but as you 
say, it's good to have the full git history.

> > I have a major performance test framework I am porting to Jmeter and I
> > am implementing it using Java samplers with nested Http samplers, as
> > it's the simplest way to get this across in a short period of time.
> 
> Sounds interesting.  Will you be able to talk about it publicly?

We have been using a tool called eggPlant Performance 
http://www.testplant.com/eggplant/testing-tools/eggplant-performance/

Like any tool it has its pros/cons, but it's very flexible and works reliably 
with a distribution mechanism to manage tests across many load injectors. We 
have been running 60k virtual users making 8k transactions/sec covering most of 
the business logic for the entire public facing web sites. 

I have developed a simple framework that provides real-time reporting of the 
test through logs pushed into Splunk as well as simple externally defined 
configuration that allows the test to be tweaked through some simple external 
config definitions.  

The reason for the JMeter move is the cost of eggPlant. We initially looked at 
Gatling, but that would have required a major rethink about how to do stuff, as 
it does not offer the same level of dynamic runtime changes that we currently 
support. JMeter on the other hand just allows you to make all the decisions at 
runtime and the sampler model of 

setupTest()
runTest()

Mirrors directly the eggPlant model of pre() and script(), so it's more of a 
lift-and-shift approach to the code rather than a conceptual redesign.

After wandering around the code in the debugger, it does look like some of the 
JMeter classes were never intended for public consumption, as there are some 
seemingly odd approaches. Some of those are:

- the use of a List to store headers in the HeaderManager, so when making 
multiple requests through the HttpSamplerBase, if you need to add a header for 
one request but remove it for the next, the removal via (removeHeaderNamed) has 
to iterate a list, rather than just removing from, say, a LinkedHashMap.

- The seeming inability to get the Test Plan name from the root of the test 
tree from within the sampler or to find the CookieManager instance configured 
at the top of the tree.

- The rather bizarre method 'String getResponseHeaders()' in the 
HttpSampleResult. Why would you want to get all the headers as a String rather 
than get a map of the headers. Under the covers it takes the map of headers and 
joins them together as a String separated with line feeds.

Still, I like the ease of development and ability to debug through the Apache 
sources, so whatever needs to be done can of course be done :)

Cheers
Antony



[GitHub] jmeter pull request #248: Auto stop JMeterThread when timer exceed the end t...

2017-01-05 Thread max3163
GitHub user max3163 opened a pull request:

https://github.com/apache/jmeter/pull/248

Auto stop JMeterThread when timer exceed the end time scheduler

With this patch, the scheduler is respected and none thread continue before 
the end of the run.
It check before return the delay to wait if this delay exceeded the end 
time schedule.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/max3163/jmeter CheckTimer

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/248.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #248


commit f5340a92bac98af6b5d89938ea829980756c9ec2
Author: Chassagneux Maxime 
Date:   2017-01-05T14:18:32Z

Auto stop JMeterThread when timer exceed the end time scheduler




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] jmeter issue #241: Support variable for all JMS messages (bytes, object, ......

2017-01-05 Thread loganmzz
Github user loganmzz commented on the issue:

https://github.com/apache/jmeter/pull/241
  
I have rebase my works on trunk: d29ac213d3971942c8d98c4ef7223fed97001cfc 
(Sonar : fix squid:UselessParenthesesCheck Remove those useless parentheses) 
and replaces the simple cache API by Caffeine


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText leads to stuck UI

2017-01-05 Thread Rory O'Donnell

Thanks Philippe, we'll take a look.

Rgds,Rory


On 05/01/2017 10:30, Philippe Mouawad wrote:

Hello,
Done:9046713

Regards

On Thu, Jan 5, 2017 at 11:14 AM, Rory O'Donnell 
wrote:


Hi Philippe,

Many happy returns!

Can you log a bug and send us the Java Incident id ?

Rgds,Rory




On 05/01/2017 10:12, Philippe Mouawad wrote:


Greetings,
First best wishes for 2017.

I'd like to report what seems to be a critical bug we face in JMeter . I
noticed it under Mac OSX El Capitan.

Calling javax.swing.JEditorPane.setText() from AWT Thread with some long
text (without spaces) leads to what seems to be either a very long or
infinite loop, I made thread dumps and I have always  such (partial)
stacktrace:
"AWT-EventQueue-0" #20 prio=6 os_prio=31 tid=0x7fa7a8afc000 nid=0xf707
runnable [0x72202000]
 java.lang.Thread.State: RUNNABLE
  at sun.font.CStrike.getNativeGlyphOutline(Native Method)
  at sun.font.CStrike.getGlyphOutline(CStrike.java:215)
  at sun.font.CStrike.getGlyphOutlineBounds(CStrike.java:177)
  at
sun.font.StandardGlyphVector$GlyphStrike.getGlyphOutlineBoun
ds(StandardGlyphVector.java:1792)
  at
sun.font.StandardGlyphVector.getGlyphOutlineBounds(StandardG
lyphVector.java:1174)
  at
sun.font.StandardGlyphVector.getGlyphVisualBounds(StandardGl
yphVector.java:586)
  at
sun.font.StandardGlyphVector.getGlyphInfo(StandardGlyphVector.java:864)
  at
sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedText
SourceLabel.java:622)
  at
sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSou
rceLabel.java:548)
  at
sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedT
extSourceLabel.java:480)
  at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:330)
  at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.
java:566)
  at
java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:359)
  at
java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:440)
  at javax.swing.text.TextLayoutStrategy.sync(TextLayoutStrategy.
java:324)
  at
javax.swing.text.TextLayoutStrategy.insertUpdate(TextLayoutS
trategy.java:70)
  at javax.swing.text.FlowView.insertUpdate(FlowView.java:256)
  at javax.swing.text.View.forwardUpdateToView(View.java:1227)
  at javax.swing.text.View.forwardUpdate(View.java:1162)
  at javax.swing.text.BoxView.forwardUpdate(BoxView.java:240)
  at javax.swing.text.View.insertUpdate(View.java:710)
  at
javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(
BasicTextUI.java:1610)
  at
javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdat
e(BasicTextUI.java:1869)
  at
javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractD
ocument.java:201)
  at
javax.swing.text.AbstractDocument.handleInsertString(Abstrac
tDocument.java:748)
  at
javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
  at javax.swing.text.PlainDocument.insertString(PlainDocument.
java:130)
  at javax.swing.text.DefaultEditorKit.read(DefaultEditorKit.java:273)
  at javax.swing.JEditorPane.setText(JEditorPane.java:1416)



Is this a known bug or shall I open one ?
Thank you
Regards



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland






--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland



Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText leads to stuck UI

2017-01-05 Thread Philippe Mouawad
Hello,
Done:9046713

Regards

On Thu, Jan 5, 2017 at 11:14 AM, Rory O'Donnell 
wrote:

> Hi Philippe,
>
> Many happy returns!
>
> Can you log a bug and send us the Java Incident id ?
>
> Rgds,Rory
>
>
>
>
> On 05/01/2017 10:12, Philippe Mouawad wrote:
>
>> Greetings,
>> First best wishes for 2017.
>>
>> I'd like to report what seems to be a critical bug we face in JMeter . I
>> noticed it under Mac OSX El Capitan.
>>
>> Calling javax.swing.JEditorPane.setText() from AWT Thread with some long
>> text (without spaces) leads to what seems to be either a very long or
>> infinite loop, I made thread dumps and I have always  such (partial)
>> stacktrace:
>> "AWT-EventQueue-0" #20 prio=6 os_prio=31 tid=0x7fa7a8afc000 nid=0xf707
>> runnable [0x72202000]
>> java.lang.Thread.State: RUNNABLE
>>  at sun.font.CStrike.getNativeGlyphOutline(Native Method)
>>  at sun.font.CStrike.getGlyphOutline(CStrike.java:215)
>>  at sun.font.CStrike.getGlyphOutlineBounds(CStrike.java:177)
>>  at
>> sun.font.StandardGlyphVector$GlyphStrike.getGlyphOutlineBoun
>> ds(StandardGlyphVector.java:1792)
>>  at
>> sun.font.StandardGlyphVector.getGlyphOutlineBounds(StandardG
>> lyphVector.java:1174)
>>  at
>> sun.font.StandardGlyphVector.getGlyphVisualBounds(StandardGl
>> yphVector.java:586)
>>  at
>> sun.font.StandardGlyphVector.getGlyphInfo(StandardGlyphVector.java:864)
>>  at
>> sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedText
>> SourceLabel.java:622)
>>  at
>> sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSou
>> rceLabel.java:548)
>>  at
>> sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedT
>> extSourceLabel.java:480)
>>  at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:330)
>>  at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.
>> java:566)
>>  at
>> java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:359)
>>  at
>> java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:440)
>>  at javax.swing.text.TextLayoutStrategy.sync(TextLayoutStrategy.
>> java:324)
>>  at
>> javax.swing.text.TextLayoutStrategy.insertUpdate(TextLayoutS
>> trategy.java:70)
>>  at javax.swing.text.FlowView.insertUpdate(FlowView.java:256)
>>  at javax.swing.text.View.forwardUpdateToView(View.java:1227)
>>  at javax.swing.text.View.forwardUpdate(View.java:1162)
>>  at javax.swing.text.BoxView.forwardUpdate(BoxView.java:240)
>>  at javax.swing.text.View.insertUpdate(View.java:710)
>>  at
>> javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(
>> BasicTextUI.java:1610)
>>  at
>> javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdat
>> e(BasicTextUI.java:1869)
>>  at
>> javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractD
>> ocument.java:201)
>>  at
>> javax.swing.text.AbstractDocument.handleInsertString(Abstrac
>> tDocument.java:748)
>>  at
>> javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
>>  at javax.swing.text.PlainDocument.insertString(PlainDocument.
>> java:130)
>>  at javax.swing.text.DefaultEditorKit.read(DefaultEditorKit.java:273)
>>  at javax.swing.JEditorPane.setText(JEditorPane.java:1416)
>> 
>>
>>
>> Is this a known bug or shall I open one ?
>> Thank you
>> Regards
>>
>>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>


-- 
Cordialement.
Philippe Mouawad.


Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText leads to stuck UI

2017-01-05 Thread Rory O'Donnell

Hi Philippe,

Many happy returns!

Can you log a bug and send us the Java Incident id ?

Rgds,Rory



On 05/01/2017 10:12, Philippe Mouawad wrote:

Greetings,
First best wishes for 2017.

I'd like to report what seems to be a critical bug we face in JMeter . I
noticed it under Mac OSX El Capitan.

Calling javax.swing.JEditorPane.setText() from AWT Thread with some long
text (without spaces) leads to what seems to be either a very long or
infinite loop, I made thread dumps and I have always  such (partial)
stacktrace:
"AWT-EventQueue-0" #20 prio=6 os_prio=31 tid=0x7fa7a8afc000 nid=0xf707
runnable [0x72202000]
java.lang.Thread.State: RUNNABLE
 at sun.font.CStrike.getNativeGlyphOutline(Native Method)
 at sun.font.CStrike.getGlyphOutline(CStrike.java:215)
 at sun.font.CStrike.getGlyphOutlineBounds(CStrike.java:177)
 at
sun.font.StandardGlyphVector$GlyphStrike.getGlyphOutlineBounds(StandardGlyphVector.java:1792)
 at
sun.font.StandardGlyphVector.getGlyphOutlineBounds(StandardGlyphVector.java:1174)
 at
sun.font.StandardGlyphVector.getGlyphVisualBounds(StandardGlyphVector.java:586)
 at
sun.font.StandardGlyphVector.getGlyphInfo(StandardGlyphVector.java:864)
 at
sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:622)
 at
sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:548)
 at
sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:480)
 at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:330)
 at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:566)
 at
java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:359)
 at
java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:440)
 at javax.swing.text.TextLayoutStrategy.sync(TextLayoutStrategy.java:324)
 at
javax.swing.text.TextLayoutStrategy.insertUpdate(TextLayoutStrategy.java:70)
 at javax.swing.text.FlowView.insertUpdate(FlowView.java:256)
 at javax.swing.text.View.forwardUpdateToView(View.java:1227)
 at javax.swing.text.View.forwardUpdate(View.java:1162)
 at javax.swing.text.BoxView.forwardUpdate(BoxView.java:240)
 at javax.swing.text.View.insertUpdate(View.java:710)
 at
javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1610)
 at
javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1869)
 at
javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201)
 at
javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:748)
 at
javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
 at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
 at javax.swing.text.DefaultEditorKit.read(DefaultEditorKit.java:273)
 at javax.swing.JEditorPane.setText(JEditorPane.java:1416)



Is this a known bug or shall I open one ?
Thank you
Regards



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland



Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText leads to stuck UI

2017-01-05 Thread Philippe Mouawad
Greetings,
First best wishes for 2017.

I'd like to report what seems to be a critical bug we face in JMeter . I
noticed it under Mac OSX El Capitan.

Calling javax.swing.JEditorPane.setText() from AWT Thread with some long
text (without spaces) leads to what seems to be either a very long or
infinite loop, I made thread dumps and I have always  such (partial)
stacktrace:
"AWT-EventQueue-0" #20 prio=6 os_prio=31 tid=0x7fa7a8afc000 nid=0xf707
runnable [0x72202000]
   java.lang.Thread.State: RUNNABLE
at sun.font.CStrike.getNativeGlyphOutline(Native Method)
at sun.font.CStrike.getGlyphOutline(CStrike.java:215)
at sun.font.CStrike.getGlyphOutlineBounds(CStrike.java:177)
at
sun.font.StandardGlyphVector$GlyphStrike.getGlyphOutlineBounds(StandardGlyphVector.java:1792)
at
sun.font.StandardGlyphVector.getGlyphOutlineBounds(StandardGlyphVector.java:1174)
at
sun.font.StandardGlyphVector.getGlyphVisualBounds(StandardGlyphVector.java:586)
at
sun.font.StandardGlyphVector.getGlyphInfo(StandardGlyphVector.java:864)
at
sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:622)
at
sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:548)
at
sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:480)
at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:330)
at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:566)
at
java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:359)
at
java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:440)
at javax.swing.text.TextLayoutStrategy.sync(TextLayoutStrategy.java:324)
at
javax.swing.text.TextLayoutStrategy.insertUpdate(TextLayoutStrategy.java:70)
at javax.swing.text.FlowView.insertUpdate(FlowView.java:256)
at javax.swing.text.View.forwardUpdateToView(View.java:1227)
at javax.swing.text.View.forwardUpdate(View.java:1162)
at javax.swing.text.BoxView.forwardUpdate(BoxView.java:240)
at javax.swing.text.View.insertUpdate(View.java:710)
at
javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1610)
at
javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1869)
at
javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201)
at
javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:748)
at
javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
at javax.swing.text.DefaultEditorKit.read(DefaultEditorKit.java:273)
at javax.swing.JEditorPane.setText(JEditorPane.java:1416)



Is this a known bug or shall I open one ?
Thank you
Regards


GUI stuck using nightly build and Java 8 u 112 on Mac osx El Capitan

2017-01-05 Thread Philippe Mouawad
Hello,
I've noticed recently  that GUI get stuck when clicking in View Results
Tree on a SampleResult using default Text renderer.

I made some thread dumps and sun.font.CStrike seems to  always be involved,
anybody facing same issue ? It looks like a Java bug no ?:
"AWT-EventQueue-0" #20 prio=6 os_prio=31 tid=0x7fa7a8afc000 nid=0xf707
runnable [0x72202000]
   java.lang.Thread.State: RUNNABLE
at sun.font.CStrike.getNativeGlyphOutline(Native Method)
at sun.font.CStrike.getGlyphOutline(CStrike.java:215)
at sun.font.CStrike.getGlyphOutlineBounds(CStrike.java:177)
at
sun.font.StandardGlyphVector$GlyphStrike.getGlyphOutlineBounds(StandardGlyphVector.java:1792)
at
sun.font.StandardGlyphVector.getGlyphOutlineBounds(StandardGlyphVector.java:1174)
at
sun.font.StandardGlyphVector.getGlyphVisualBounds(StandardGlyphVector.java:586)
at
sun.font.StandardGlyphVector.getGlyphInfo(StandardGlyphVector.java:864)
at
sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:622)
at
sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:548)
at
sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:480)
at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:330)
at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:566)
at
java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:359)
at
java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:440)
at javax.swing.text.TextLayoutStrategy.sync(TextLayoutStrategy.java:324)
at
javax.swing.text.TextLayoutStrategy.insertUpdate(TextLayoutStrategy.java:70)
at javax.swing.text.FlowView.insertUpdate(FlowView.java:256)
at javax.swing.text.View.forwardUpdateToView(View.java:1227)
at javax.swing.text.View.forwardUpdate(View.java:1162)
at javax.swing.text.BoxView.forwardUpdate(BoxView.java:240)
at javax.swing.text.View.insertUpdate(View.java:710)
at
javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1610)
at
javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1869)
at
javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201)
at
javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:748)
at
javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
at javax.swing.text.DefaultEditorKit.read(DefaultEditorKit.java:273)
at javax.swing.JEditorPane.setText(JEditorPane.java:1416)
at
org.apache.jmeter.visualizers.RenderAsText.showTextResponse(RenderAsText.java:36)
at
org.apache.jmeter.visualizers.RenderAsText.renderResult(RenderAsText.java:31)
at
org.apache.jmeter.visualizers.ViewResultsFullVisualizer.valueChanged(ViewResultsFullVisualizer.java:270)
at javax.swing.JTree.fireValueChanged(JTree.java:2927)
at
javax.swing.JTree$TreeSelectionRedirector.valueChanged(JTree.java:3391)
at
javax.swing.tree.DefaultTreeSelectionModel.fireValueChanged(DefaultTreeSelectionModel.java:635)
at
javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange(DefaultTreeSelectionModel.java:1093)
at
javax.swing.tree.DefaultTreeSelectionModel.setSelectionPaths(DefaultTreeSelectionModel.java:294)
at
javax.swing.tree.DefaultTreeSelectionModel.setSelectionPath(DefaultTreeSelectionModel.java:188)
at javax.swing.JTree.setSelectionPath(JTree.java:1634)
at
javax.swing.plaf.basic.BasicTreeUI.selectPathForEvent(BasicTreeUI.java:2393)
at
javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(BasicTreeUI.java:3609)
at
javax.swing.plaf.basic.BasicTreeUI$Handler.mousePressed(BasicTreeUI.java:3548)
at java.awt.Component.processMouseEvent(Component.java:6530)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6298)
at java.awt.Container.processEvent(Container.java:2236)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2294)
at java.awt.Component.dispatchEvent(Component.java:4711)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4522)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
at java.awt.Container.dispatchEventImpl(Container.java:2280)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$JavaSecurityAccessI