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

[Muneer Kolarkunnu]

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 mailto:pmoua...@apache.org; \npmoua...@apache.org> 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 mailto:abdul.kolarku...@oracle.com; \nabdul.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: HYPERLINK "mailto:dev@jmeter.apache.org; \n...@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
> mailto:rory.odonn...@oracle.com; \nrory.odonn...@oracle.com>
> 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

Re: Nightly builds are not available on https://ci.apache.org/projects/jmeter/nightlies/

[sebb]

Someone has changed the build script (again).

The CI script is expecting:

https://ci.apache.org/projects/jmeter/nightlies/r1778869/apache-jmeter-r1778869.zip

but the file is called

https://ci.apache.org/projects/jmeter/nightlies/r1778869/apache-jmeter-3.2-SNAPSHOT.zip


On 14 January 2017 at 22:50, Philippe Mouawad
 wrote:
> Hello,
> There seems to be a problem here:
>
>- LATEST link show error 404 No Such Resource
>- And previous link are from 14th december.
>
>
> Regards
>
> Philippe

Jenkins build is back to normal : JMeter-trunk #5720

[Apache Jenkins Server]

See 

Re: Release JMeter 3.2 ?

[Philippe Mouawad]

On Thu, Jan 12, 2017 at 9:02 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

>
>
> On Thu, Jan 12, 2017 at 8:55 PM, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>> Am 12.01.2017 um 20:39 schrieb Philippe Mouawad:
>>
>>> Hello,
>>> What do you think of releasing a 3.2 version ?
>>>
>> I think I said before, that I would like to release often :)
>>
>>>
>>> I see following reasons:
>>>
>>> - There is a regression (See bug 60575)
>>>
>> My fix for 60575 needs tests and review as it changes the contract of the
>> method getSendParameterValuesAsPostBody.
>>
> I reviewed it , it looks ok to me.
> I'll double check.
>
>>
>> It returned true if there were no parameters (and thus none with a name).
>> (Or if getPostBodyRaw() is true)
>>
>> After the change it returns only true when there are parameters and none
>> of those have a name. (Or if getPostBodyRaw() is true).
>>
>
>
>
>>
>> This method is used in POST and PUT as well, but I believe the change to
>> be correct in both places. too.
>>
>> - We have 9 enhancements and 12  Bug fixes
>>> - Some nice features (at least as a current user I find them
>>> interesting
>>> :-) ):
>>>- More space in UI and simpler look
>>>- Up to date Browser based on javafx
>>>
>> We might have to warn a bit more about the need for javafx (The default
>> java for SUSE Leap42.2 seems to have no javafx). Without javafx JMeter will
>> start, but the results tree view is missing.
>>
>
> I think in this case we should try to fail in a bit cleaner way
>

Done through bug  60583
Still, not fully satisfied with solution as we catch a NoClassDefFoundError
(I'll send a mail on this)



   - Or in response assertion
>>>- Replace feature (partial)+ counting
>>>
>>> Maybe we can integrate before next release:
>>>
>>> - PR-247
>>>
>>
If somebody can take it into account. I'm pausing for now.



> - PR-246
>>>
>> Done with some changes.
We can improve in the future by:

   - Using HttpComponents HttpAsyncClient
   - Make some properties configurable


- PR-245
>>>
>> Done with some changes

> - PR-237
>>>
>> Done

>
>>> And upgrade some dependencies:
>>>
>>> - jodd which has a lot of perf enhancements that we use in JMeter
>>> (for
>>> resources extractions)
>>> - httpcomponents
>>> - maybe more
>>>
>> Done

I'd also like to commit :

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


I would like to link  the converted pdf tutorials and maybe do a bit of
>> minor tweaks to the look and feel of the web pages (less shadows).
>>
>> Should the sect-num number of the tutorials be continued from those in
>> the usermanual section?
>>
>
> I think so.
>
>
>>> Besides, we did a lot of code changes related to sonar, let's release it.
>>>
>>> A last good thing is that we start to release more often.
>>>
>> +1
>>
>> Felix
>>
>>>
>>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Build failed in Jenkins: JMeter-trunk #5719

[Apache Jenkins Server]

See 

Changes:

[pmouawad] Bug 60591 - BackendListener : Add a time boxed sampling 
Based on PR 237  from by Logan Mauzaize (logan.mauzaize at gmail.com) and
Maxime Chassagneux (maxime.chassagneux at gmail.com).

Changes in PR:
- Add documentation in properties_reference.xml
- Make some fields static

This closes #237
Bugzilla Id: 60591

[pmouawad] Bug 60590 - BackendListener : Add Influxdb BackendListenerClient 
implementation to JMeter
svn:eol
Bugzilla Id: 60590

[pmouawad] Bug 60590 - BackendListener : Add Influxdb BackendListenerClient 
implementation to JMeter
Partly Based on PR 246  from by Logan Mauzaize (logan.mauzaize at gmail.com) and
Maxime Chassagneux (maxime.chassagneux at gmail.com).

Fixed following issues in PR:
- Reinit httpRequest
- Fix issue with broken NaN comparison which led to missing 
- Improve InfluxDB Annotations
- Use StringBuilder
- Init StringBuilder capacity
- Add documentation

This closes #246
Bugzilla Id: 60590

--
[...truncated 4261 lines...]
[sonar:sonar] Resource not found: 
org.apache.jmeter.assertions.MD5HexAssertionTest
[sonar:sonar] Resource not found: 
org.apache.jmeter.protocol.http.util.TestHTTPArgument
[sonar:sonar] Resource not found: 
org.apache.jmeter.protocol.http.sampler.PackageTest
[sonar:sonar] Resource not found: org.apache.jmeter.services.TestFileServer
[sonar:sonar] Resource not found: org.apache.jmeter.extractor.TestXPathExtractor
[sonar:sonar] Resource not found: org.apache.jmeter.samplers.TestSampleResult
[sonar:sonar] Resource not found: 
org.apache.jmeter.threads.TestJMeterContextService
[sonar:sonar] Resource not found: 
org.apache.jmeter.functions.StringFromFileFunctionTest
[sonar:sonar] Resource not found: org.apache.jmeter.control.TestWhileController
[sonar:sonar] Sensor SurefireSensor (done) | time=85ms
[sonar:sonar] Sensor JaCoCoSensor
[sonar:sonar] Analysing 

[sonar:sonar] No information about coverage per test.
[sonar:sonar] Sensor JaCoCoSensor (done) | time=1465ms
[sonar:sonar] Sensor JaCoCoOverallSensor
[sonar:sonar] Analysing 

[sonar:sonar] Analysing 

[sonar:sonar] No information about coverage per test.
[sonar:sonar] Sensor JaCoCoOverallSensor (done) | time=1117ms
[sonar:sonar] Sensor SCM Sensor
[sonar:sonar] Sensor SCM Sensor (done) | time=2ms
[sonar:sonar] Sensor Zero Coverage Sensor
[sonar:sonar] Sensor Zero Coverage Sensor (done) | time=3ms
[sonar:sonar] Sensor Code Colorizer Sensor
[sonar:sonar] Sensor Code Colorizer Sensor (done) | time=1ms
[sonar:sonar] Sensor CPD Block Indexer
[sonar:sonar] JavaCpdBlockIndexer is used for java
[sonar:sonar] Sensor CPD Block Indexer (done) | time=41ms
[sonar:sonar] -  Scan native
[sonar:sonar] Language is forced to java
[sonar:sonar] Base dir: 
[sonar:sonar] Working dir: 

[sonar:sonar] Source paths: src/protocol/native
[sonar:sonar] Source encoding: ISO-8859-1, default locale: en_US
[sonar:sonar] Index files
[sonar:sonar] 2 files indexed
[sonar:sonar] Quality profile for java: Sonar way
[sonar:sonar] JaCoCoItSensor: JaCoCo IT report not found: 

[sonar:sonar] Sensor JavaSquidSensor
[sonar:sonar] Configured Java source version (sonar.java.source): none
[sonar:sonar] JavaClasspath initialization...
[sonar:sonar] JavaClasspath initialization done: 320 ms
[sonar:sonar] JavaTestClasspath initialization...
[sonar:sonar] JavaTestClasspath initialization done: 2 ms
[sonar:sonar] Java Main Files AST scan...
[sonar:sonar] 2 source files to be analyzed
[sonar:sonar] Java Main Files AST scan done: 502 ms
[sonar:sonar] 2/2 source files have been analyzed
[sonar:sonar] Java bytecode scan...
[sonar:sonar] Java bytecode scan done: 18 ms
[sonar:sonar] Java Test Files AST scan...
[sonar:sonar] 0 source files to be analyzed
[sonar:sonar] Java Test Files AST scan done: 1 ms
[sonar:sonar] Package design analysis...
[sonar:sonar] 0/0 source files have been analyzed
[sonar:sonar] Package design analysis done: 1 ms
[sonar:sonar] Sensor JavaSquidSensor (done) | time=860ms
[sonar:sonar] Sensor Lines Sensor
[sonar:sonar] Sensor Lines Sensor (done) | time=0ms
[sonar:sonar] Sensor SurefireSensor
[sonar:sonar] parsing 

[sonar:sonar] Resource not found: org.apache.jmeter.util.JSR223TestElementTest
[sonar:sonar] Resource not found: 
org.apache.jmeter.assertions.XMLSchemaAssertionTest
[sonar:sonar] Resource not found: org.apache.jmeter.save.TestSaveService
[sonar:sonar] Resource not found: 

[GitHub] jmeter pull request #237: Adds a time boxed sampling for backend listeners

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #246: Add Influxdb backend to JMeter

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: [GitHub] jmeter issue #241: Support variable for all JMS messages (bytes, object, ......

[Maxime Chassagneux]

Hi,

I thought we have already did it. I will look at this tomorrow and share
result with you.



2017-01-15 15:00 GMT+01:00 pmouawad :

> Github user pmouawad commented on the issue:
>
> https://github.com/apache/jmeter/pull/241
>
> Hello,
> Before merging this one , I'd like to be sure it does not introduce
> performance degradation.
>
> Did you have time to make a micro benchmark ?
> Thank you
>
>
> ---
> 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: Want to help with migrating from Apache LogKit to SLF4J

[Woonsan Ko]

On Mon, Jan 9, 2017 at 1:29 PM, Woonsan Ko  wrote:
> On Fri, Jan 6, 2017 at 3:23 PM, Philippe Mouawad
>  wrote:
>> On Wednesday, January 4, 2017, sebb  wrote:
>>
>>> On 3 January 2017 at 20:59, Woonsan Ko >
>>> wrote:
>>> > On Tue, Jan 3, 2017 at 2:32 PM, Felix Schumacher
>>> > > wrote:
>>> >> Am 02.01.2017 um 21:31 schrieb Philippe Mouawad:
>>> >>>
>>> >>> On Monday, January 2, 2017, Woonsan Ko >> > wrote:
>>> >>>
>>>  Hi,
>>> 
>>>  I'd like to help with migrating from Apache LogKit to SLF4J [1], and
>>>  so I've been reading the current logging implementation with logkit,
>>>  avalon-framework and excalibur-logger.
>>> >>>
>>> >>> Thanks for your proposal
>>> >>
>>> >> +1
>>> >>>
>>> >>>
>>>   From my understanding, maybe we can take the following approach:
>>>  - Since SLF4J API doesn't provide a logging implementation or binding
>>>  by itself, we need to choose one at least such as log4j2 [2] or
>>>  logback. [3] IMHO, log4j2 binding provided by Apache Logging services
>>>  project could be a good default binding option.
>>> >>>
>>> >>>
>>> >>> +1
>>> >>
>>> >> Well, I would start with what we have, which is a working binding for
>>> SLF4J.
>>> >
>>> > It seems more important to migrate each logger usages to use slf4j
>>> > logger in each class than replacing logging framework in the first
>>> > step. So, we can keep the current logkit binding in the first step.
>>> > That prioritization makes sense to me.
>>> >
>>> >>>
>>> >>>
>>>  - By the default binding such as log4j2, I mean JMeter should be
>>>  bundled with log4j2 library and its binding library as well as a
>>>  default configuration file (e.g, log4j2.xml), by default. It seems
>>>  neater to separate the logging configuration file from
>>>  jmeter.properties with simply following its default auto-resolving
>>>  conventions such as log4j2.xml [4] or logback.xml [5] to me.
>>> >>>
>>> >>> +1
>>> >>
>>> >> I am +-0 to any decision right now.
>>> >
>>> > This can be revisited with separate ticket after the first step done.
>>> >
>>> >>>
>>> >>>
>>>  - It seems like each Logger instance is created as a static member by
>>>  `LoggingManager.getLoggerForXXX()' method(s). I suppose all of those
>>>  should be replaced by simply using slf4j logger factory as done in
>>>  AbstractSampleConsumer.java.
>>> >>>
>>> >>> Yes
>>> >>>
>>>  - It might be even better if each logging line is more optimized by
>>>  taking advantage of slf4j logging methods (e.g, message format
>>>  arguments and throwable argument).
>>> >>>
>>> >>> Yes
>>> >>
>>> >> Plus, if we use formatted messages with arguments, the need for if
>>> >> (log-is-enabled) statements might be gone for simple cases.
>>> >
>>> > Yes.
>>> >
>>> >>
>>> >>>
>>>  - After all migrated, the old logkit and some other related unused
>>>  libraries should be gone.
>>> >>>
>>> >>>
>>> >>> A possible option to avoid breaking too many existing third party
>>> plugins
>>> >>> would be to embed in source code current logkit logger factory and
>>> logger
>>> >>> so that it delegates to slf4j.
>>> >>> We would drop avalon, logkit and  excalibur jars.
>>> >
>>> > Good point. This can be revisited in the later step.
>>> >
>>> >>>
>>> >>>
>>> >>>
>>>  Am I in the right track? Any advice or thoughts?
>>> >>>
>>> >>>
>>> >>> please wait for other team members to answer before starting code.
>>> >>> Give a week .
>>> >>
>>> >> I would start slowly and contribute drop by drop first, to see if you
>>> are
>>> >> going in the right direction.
>>> >
>>> > You're right.
>>> > Maybe we can split the steps (with separate bz tickets) like the
>>> > following (ordered by priority):
>>> > Step 1: Replace logkit loggers with slf4j ones with keeping the
>>> > current logkit binding solution.
>>> > Step 2: Optimize logging statements. e.g, message format args,
>>> > throwable args, unnecessary if-enabled-logging in simple ones, etc.
>
> I've created two tickets for the Step 1 and 2:
> - https://bz.apache.org/bugzilla/show_bug.cgi?id=60564
> - https://bz.apache.org/bugzilla/show_bug.cgi?id=60565
>
> Each looks straightforward. I'd create separate PRs for each bz ticket.
> But, there's one thing tricky: some classes have public constructor or
> methods requiring logkit Logger, such as:
> - o.a.jmeter.engine.ClientJMeterEngine.tidyRMI(Logger)
> - o.a.jmeter.util.BeanShellInterpreter.BeanShellInterpreter(String, Logger)
> - o.a.jmeter.protocol.jms.Utils.close(MessageConsumer, Logger)
> - o.a.jmeter.protocol.jms.Utils.close(Session, Logger)
> - o.a.jmeter.protocol.jms.Utils.close(Connection, Logger)
> - o.a.jmeter.protocol.jms.Utils.close(MessageProducer, Logger)
>
> I think we have the following options for those:
> (a) Don't change those for backward 

[GitHub] jmeter issue #250: Feature/bz60564 (1)

[woonsan]

Github user woonsan commented on the issue:

https://github.com/apache/jmeter/pull/250
  
@pmouawad I've created a new bugzilla ticket with goals and comparison 
between current logging related features and new feature proposal:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=60589
I'll also log this ticket to ML thread.
I'll try to create a PR with my solution idea accordingly in several days.

Cheers,

Woonsan


---
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 #246: Add Influxdb backend to JMeter

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/246
  
Hi Mark,
Good to know. 
Are you using Apache HttpAsyncClient or something else ? 
Do you agree with my proposals ?
Thanks 


---
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 #246: Add Influxdb backend to JMeter

[mtomlins]

Github user mtomlins commented on the issue:

https://github.com/apache/jmeter/pull/246
  
I use an AsyncHTTP thread pool to send to InfluxDB from a custom listener.

Works very well.

Sent from my iPhone

> On Jan 15, 2017, at 10:33 AM, Philippe M  wrote:
> 
> Hello,
> Thanks for contribution.
> I have few remarks on implementation:
> 
> You intentionally don't set timestamp. I am not sure it's a good idea as 
if any delay occurs sending to InfluxDB, measurement will be wrong, and there 
is another reason, see next remark
> I think HttpAsyncClient 
(https://hc.apache.org/httpcomponents-asyncclient-dev/quickstart.html) might be 
a good use case here as we don't care about responses and we don't want to 
block too much, so we could use it here. But in this case we would need to add 
timestamp.
> I think you should allow some configuration for technical things like 
timeouts. InfluxdbMetricsSender#setup should have a more flexible parameter 
like Map to allow passing more parameters
> Also would it be possible to provide:
> 
> A Simple Test plan using the component
> If possible some documentation
> I have already made some changes to PR, I could commit it as is and mark 
component as Alpha, we could distribute with next release and improve it either 
before or later.
> @Team what do you think ?
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 



---
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 #246: Add Influxdb backend to JMeter

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/246
  
Hello,
Thanks for contribution.
I have few remarks on implementation:
- You intentionally don't set timestamp. I am not sure it's a good idea as 
if any delay occurs sending to InfluxDB, measurement will be wrong, and there 
is another reason, see next remark
- I think HttpAsyncClient 
(https://hc.apache.org/httpcomponents-asyncclient-dev/quickstart.html) might be 
a good use case here as we don't care about responses and we don't want to 
block too much, so we could use it here. But in this case we would need to add 
timestamp.
- I think you should allow some configuration for technical things like 
timeouts. InfluxdbMetricsSender#setup should have a more flexible parameter 
like Map to allow passing more parameters

Also would it be possible to provide:
- A Simple Test plan using the component
- If possible some documentation

I have already made some changes to PR, I could commit it as is and mark 
component as Alpha, we could distribute with next release and improve it either 
before or later. 
@Team what do you think ?



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

PR for Bug 55258

[Philippe Mouawad]

Hello,
Shall we merge :
https://github.com/apache/jmeter/pull/227

Regards
Philippe

[GitHub] jmeter pull request #249: Docs 2.5.1

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Nightly builds are not available on https://ci.apache.org/projects/jmeter/nightlies/

[Felix Schumacher]

Am Samstag, den 14.01.2017, 23:50 +0100 schrieb Philippe Mouawad:
> Hello,
> There seems to be a problem here:
> 
>    - LATEST link show error 404 No Such Resource
>    - And previous link are from 14th december.

The status of the builds can be found at https://ci.apache.org/builders
/jmeter-nightly 

They look good to me. The upload step has no log, but even the old ones
had no logs, so that seems not to be a problem.

No clue,
 Felix

> 
> 
> Regards
> 
> Philippe