DO NOT REPLY [Bug 27863] New: - Enable Java property value/Test Plan variable coincidence

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: Is JMeterContextService.getContext() thread safe? Should it b e such?

I'm not talking about making the context itself read-only, just the getContext() method that retrieves the context according to the current thread. Each context should be accessible only to a single thread via this strategy and shouldn't need synchronization for read or write operations. I wouldn

DO NOT REPLY [Bug 27801] - HTTP Authorization does not seem to work

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: cvs commit: jakarta-jmeter eclipse.classpath

by the way, thanks for all your hard work sebastian. when I see all your contributions, it makes me think "man wish I more time to contribute a bit more." :) peter lin [EMAIL PROTECTED] wrote: sebb 2004/03/22 07:09:02 Modified: . eclipse.classpath Log: Replaced avalon-excalibur with indivi

cvs commit: jakarta-jmeter eclipse.classpath

sebb2004/03/22 07:09:02 Modified:.eclipse.classpath Log: Replaced avalon-excalibur with individual jars Revision ChangesPath 1.11 +3 -1 jakarta-jmeter/eclipse.classpath Index: eclipse.classpath =

cvs commit: jakarta-jmeter/lib avalon-excalibur-4.1.jar

sebb2004/03/22 07:07:37 Removed: lib avalon-excalibur-4.1.jar Log: Replaced avalon-excalibur with individual jars - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTE

cvs commit: jakarta-jmeter build.xml

sebb2004/03/22 07:05:56 Modified:.build.xml Log: Replace avalon-excalibur with individual excalibur jars Revision ChangesPath 1.175 +11 -6 jakarta-jmeter/build.xml Index: build.xml

cvs commit: jakarta-jmeter/lib excalibur-compatibility-1.1.jar excalibur-i18n-1.1.jar

sebb2004/03/22 06:24:48 Added: lib excalibur-compatibility-1.1.jar excalibur-i18n-1.1.jar Log: Need to delete avalon-excalibur to get rid of old version of logger, so need to add the other parts we still use Revision ChangesPath 1.1

RE: cvs commit: jakarta-jmeter/src/monitor/components/org/apache/ jmeter/monitor/util Stats.java

yeah, you're absolutely right. It is picking up the settings from the previous instance. I think the behavior is fine, just have to make sure I make a note in the user manual. I should have a basic document ready to check in tonight for "how to make a monitor test plan". peter lin "BAZLEY,

RE: Is JMeterContextService.getContext() thread safe? Should it b e such?

Forgot to say that JMeterThread initialises the context field - in the samplers at least -before starting the test run. S. -Original Message- From: BAZLEY, Sebastian Sent: 22 March 2004 13:01 To: 'JMeter Developers List' Subject: RE: Is JMeterContextService.getContext() thread safe? Should

RE: Is JMeterContextService.getContext() thread safe? Should it b e such?

Not sure it should be read-only. The context is useful (and already used?) for communicating information within a thread. I recently added a version of getContext() to AbstractTestElement that caches the context variable. The idea being that the TestElements are all cloned per thread, and so ther

[Apache JMeter Wiki] Updated: JMeterGump

Date: 2004-03-22T04:16:03 Editor: 134.32.9.89 <> Wiki: Apache JMeter Wiki Page: JMeterGump URL: http://wiki.apache.org/jakarta-jmeter/JMeterGump Updated LSD directories Change Log: -- @@ -36,10 +36,10 @

[Apache JMeter Wiki] Updated: JMeterGump

Date: 2004-03-20T03:32:21 Editor: 80.176.146.62 <> Wiki: Apache JMeter Wiki Page: JMeterGump URL: http://wiki.apache.org/jakarta-jmeter/JMeterGump Spelling! Change Log: -- @@ -22,7 +22,7 @@ * http:

[Apache JMeter Wiki] Updated: JMeterGump

Date: 2004-03-20T03:30:17 Editor: 80.176.146.62 <> Wiki: Apache JMeter Wiki Page: JMeterGump URL: http://wiki.apache.org/jakarta-jmeter/JMeterGump Fix LSD paths (changed back again) Change Log: -- @@ -2

[Apache JMeter Wiki] Updated: JMeterLinks

Date: 2004-03-19T10:17:28 Editor: 195.248.191.65 <> Wiki: Apache JMeter Wiki Page: JMeterLinks URL: http://wiki.apache.org/jakarta-jmeter/JMeterLinks no comment Change Log: -- @@ -21,3 +21,6 @@ * htt

[Apache JMeter Wiki] New: JMeterLogging

Date: 2004-03-19T05:02:09 Editor: 134.32.9.89 <> Wiki: Apache JMeter Wiki Page: JMeterLogging URL: http://wiki.apache.org/jakarta-jmeter/JMeterLogging no comment New Page: This page is intended to hold details of on the logging used by JMeter JMeter uses [http://avalon.apache.

[Apache JMeter Wiki] Updated: FrontPage

Date: 2004-03-19T04:57:58 Editor: 134.32.9.89 <> Wiki: Apache JMeter Wiki Page: FrontPage URL: http://wiki.apache.org/jakarta-jmeter/FrontPage no comment Change Log: -- @@ -24,11 +24,13 @@ == JMeter

Re: Is JMeterContextService.getContext() thread safe? Should it be such?

Dnia pon 22. marca 2004 13:30, Michael Stover napisał: > To my way of thinking, getContext() should be entirely read-only and the > initialization of thread contexts should be provided for prior to the > test beginning. That would avoid an unnecessary synchronization point. I agree. I don't know

Re: Is JMeterContextService.getContext() thread safe? Should it be such?

To my way of thinking, getContext() should be entirely read-only and the initialization of thread contexts should be provided for prior to the test beginning. That would avoid an unnecessary synchronization point. -Mike On Mon, 2004-03-22 at 03:48, Michal Kostrzewa wrote: > Strange thing, I didn

RE: cvs commit: jakarta-jmeter/src/monitor/components/org/apache/ jmeter/monitor/util Stats.java

This is true of most/all test elements - they pick up the settings from the previous instance of the kind. I suspect that's because all the Test Elements are created in the same thread, and presumably the properties used to populate the GUI hang around. S. --- [EMAIL PROTECTED] wrote: > - Ori

Re: Is JMeterContextService.getContext() thread safe? Should it be such?

Strange thing, I didn't notice your mail from wenesday, sorry :( > How would that cause a problem? The Map that holds the thread contexts > is only being read, not written to. So, many threads can ask for their > context simultaneously, this should not be a problem. Unless you can > think of a