[GitHub] jmeter issue #254: Feature/bz60589-1 PR for review (logkit to slf4j / log4j2...

[woonsan]

Github user woonsan commented on the issue:

https://github.com/apache/jmeter/pull/254
  
I've fixed more:
- Keep the backward compatibility in the Help / En(Dis)able DEBUG logging 
menu items.
- Fixed errors in HttpMirrorServer (executed via mirror-server.sh or 
mirror-server.bat). It now uses log4j. Also, it provides log level setting 
through command line arguments (e.g, `-LDEBUG' or `-Ljmeter=DEBUG 
-Ljorphan=DEBUG'). This command line arguments for log level settings are 
provided to replace the old log level setting functionality through .properties 
file loading). It supports `-P' to set port number command line arg as well 
as the backward compatible the first port number arg (e.g, ./mirror-server.sh 
).
- Fixed a corner case when GuiLogAppender is used in log4j2.xml while 
JMeter application properties were not initialized properly.


---
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.
---

buildbot failure in on jmeter-nightly

[buildbot]

The Buildbot has detected a new failure on builder jmeter-nightly while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-nightly/builds/570

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave1_ubuntu

Build Reason: The Nightly scheduler named 'jmeterNightly' triggered this build
Build Source Stamp: [branch jmeter/trunk] HEAD
Blamelist: 

BUILD FAILED: failed shell_5

Sincerely,
 -The Buildbot

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

[Philippe Mouawad]

See:

- https://bugs.openjdk.java.net/browse/JDK-8172336



On Thursday, January 5, 2017, Philippe Mouawad 
wrote:

> 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 

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

[Philippe Mouawad]

Hello,
Thanks.
Any chance issue gets fixed as I see it's P4 .

Thank you

On Monday, January 16, 2017, Muneer Kolarkunnu 
wrote:

> Hi Philippe,
>
>
>
> Thanks for sharing standalone test case.
>
> Issue is reproducible in all platforms(Windows, Linux and Osx) with all
> JDK versions(7, 8, 9-ea).
>
> I reopened the bug, You can see the updates in here:
> https://bugs.openjdk.java.net/browse/JDK-8172336
>
>
>
> Regards,
>
> Muneer
>
>
>
> *From:* Philippe Mouawad [mailto:pmoua...@apache.org
> ]
> *Sent:* Sunday, January 15, 2017 4:33 AM
> *To:* Muneer Kolarkunnu
> *Cc:* Dalibor Topic; Balchandra Vaidya; dev@jmeter.apache.org
> ; Rory O'Donnell
> *Subject:* Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText
> leads to stuck UI
>
>
>
> Hi,
>
> Previous sample showed already very slow rendering when text contains
> spaces.
>
> Now for the text without space. Sample attached.
>
> Regards
>
>
>
> On Fri, Jan 13, 2017 at 2:20 PM, Philippe Mouawad  > wrote:
>
> Hello Muneer,
>
> Find attached  a simple program reproducing issue.
>
> I see you closed the bug
>
> Regards
>
>
>
> On Fri, Jan 6, 2017 at 2:28 PM, Muneer Kolarkunnu <
> abdul.kolarku...@oracle.com
> > wrote:
>
> Hi Philippe,
>
> Your incident has moved to JDK-8172336: https://bugs.openjdk.java.net/
> browse/JDK-8172336
>
> I tried to reproduce the issue, but I could not reproduce this issue with
> the information shared in the bug report. If you can provide a standalone
> test case, it will be great. Also, please let us know if you observe the
> same issue with JDK 8u122-ea and JDK 9-ea.
> Have you observed the same issue with other OS(Other than Mac OSX) ?
>
> 8u122-ea is available here : https://jdk8.java.net/download.html
> JDK 9-ea is available here : https://jdk9.java.net/download/
>
> Regards,
> Muneer
>
>
> -Original Message-
> From: Rory O'Donnell
> Sent: Thursday, January 05, 2017 5:22 PM
> To: dev@jmeter.apache.org
> 
> Cc: Rory O'Donnell; Dalibor Topic; Balchandra Vaidya; Muneer Kolarkunnu
> Subject: Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText
> leads to stuck UI
>
> 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
> >>> 

Re: Bug 60646 - Workbench : Save it by default

[Philippe Mouawad]

Done

On Wednesday, January 25, 2017, Antonio Gomes Rodrigues 
wrote:

> +1 to save it by default
>
> Antonio
>
> 2017-01-25 20:32 GMT+01:00 Philippe Mouawad  >:
>
> > Hello,
> > Anybody is against switching this ?
> >
> > Thank you
> > Regards
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: [ANNOUNCE] Graham Russell as new commiter on Apache JMeter

[Antonio Gomes Rodrigues]

Welcome Graham

2017-01-30 22:07 GMT+01:00 Milamber :

>
> Congrats Graham! and Welcome!
>
>
> On 30/01/2017 19:51, Philippe Mouawad wrote:
>
>> Hello All,
>>
>> The Project Management Committee (PMC) for Apache JMeter has asked Graham
>> Russell to become a committer and we are pleased to announce that he has
>> accepted.
>>
>> Being a committer allows many contributors to contribute more
>> autonomously.
>> For developers, it makes it easier to submit changes and eliminates the
>> need to have contributions reviewed via the patch submission process.
>> Whether contributions are development-related or otherwise, it is a
>> recognition of a
>> contributor's participation in the project and commitment to the project
>> and
>> the Apache Way.
>>
>> Please join me in congratulating Graham!
>>
>> We recall you that anyone willing to contribute can submit a PR at our
>> github mirror
>>
>> - https://github.com/apache/jmeter/
>>
>> Read also:
>>
>> - https://helpwanted.apache.org/
>> - http://jmeter.apache.org/building.html
>>
>>
>> Philippe M.
>> For the JMeter PMC.
>>
>>
>

[GitHub] jmeter issue #260: Manually synchronized on synchronizedMap as per docs and ...

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/260
  
Hello,
Thanks for contribution.
I am not sure we should apply this fix as I am not sure initial bug report 
was correct.
AFAIU, the propMap is never accessed concurrently although  I don't know 
why propMap is wréapped in a synchronized Map.

I am afraid that introducing this might hurt performances as it is called 
for every run of a sample .

But others analysis is welcome and particularly if anybody know why propMap 
was initially synchronized.



---
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.
---

buildbot failure in on jmeter-trunk

[buildbot]

The Buildbot has detected a new failure on builder jmeter-trunk while building 
. Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/2073

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave1_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1780966
Blamelist: pmouawad

BUILD FAILED: failed shell_3

Sincerely,
 -The Buildbot