[RESULT][VOTE][LAZY] Move Jakarta Regexp to Attic
Vote result: We will move Jakarta Regexp to the Apache Attic as there were no objections to the move. I'll inform the Attic in a day or two and include a call for volunteers to complete the associated tasks for the move. Thanks to everyone for their input. -Rahul On Mon, Mar 21, 2011 at 8:00 PM, Rahul Akolkar wrote: > This is a vote to move Jakarta Regexp to the Apache Attic, based on > the outcome of the most recent discussion on the topic. > > Since Regexp may not have enough PMC members active, this vote will be > held by lazy consensus. If you object, please also provide a > reasonable explanation. > > Vote runs for a week, ending no sooner than Mar 28th, ~8:00 pm Eastern > US. Vote is being held on general@jao but is being cross-posted to > ensure we reach the full audience. Please include general@jao on any > replies. > > -Rahul > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
April board report input needed
Please provide any input for our April board report by Friday, April 15th by editing the wiki. I've added the template for April to the wiki here: http://wiki.apache.org/jakarta/JakartaBoardReport-April2011 -Rahul - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
On 7 April 2011 00:07, sebb wrote: > On 6 April 2011 23:36, Milamber wrote: >> >>> HC4 should do this automatically, I think, but there was a bug whereby >>> >> >> I have found this problem too: >> Unlike HC3, HC4 sampler works with a HTTPS website with a trusted >> certificate (verisign, thawte, etc.) but doesn't works with self-signed >> ssl certificate. >> I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal? > > No, I forgot. > That needs to be fixed so that all certificates are accepted, same as for HC3. > I'll fix that shortly. Fixed. >> Milamber >> >> >>> it did not recognise some encoding methods: >>> >>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063 >>> >>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which >>> JMeter trunk was recently updated to use). >>> >>> Can you check which version of HC4 you were using, and the >>> Content-type used by Apache 2.2? >>> >>> Milamber Le 25/11/2010 15:45, sebb a ecrit : > Just a heads up that I'm currently working on trying to combine the > HTTP implementations (Java, HttpClient3) into a single GUI, with > run-time choice of implementation. > > The rationale for this is that HttpClient 4 is now available, and it > would be good to add that, but I think we should keep HttpClient for > backwards compatibility and comparison. > > Creating another GUI/Sampler set is easy enough, but it would be > useful to be able to switch implementations easily - currently that > requires switching samplers (e.g. by editting the JMX file). > > The current plan is to allow the implementation to be specified on the > HTTP Request Defaults config screen as well as on the HTTP Request > screen. > > The code is a bit involved, because the Config settings are processed > at run-time after the test plan has been built. > [But even the Sampler GUI needs to create the sampler before it can > store the sampler settings - and the implementation can then be > changed.] > Currently I use a Sampler Proxy that dispatches to the appropriate > implementation class. > These classes have to extend an abstract class that provides the > necessary methods to interface with the Proxy test element and thus > provide access to the test element properties. > That part seems to be working OK. > > The next phase is to ensure that existing JMX files can be converted > (during load) to use the new sampler. > > The intention is to keep the existing Java and HttpClient samplers, so > that subclasses will continue to work, but not expose them in the GUI. > > I've not finally decided about the AJP sampler - it can be easily > converted, but I don't think there's much of a use case for switching > between AJP and another implementation. > > - > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
On 6 April 2011 23:11, Milamber wrote: > >>> When Web server (Apache 2.2) uses mod_deflate to compress response data, >>> the data remains compress data (in view results tree, we have the >>> compress characters and getBytes() is the compressed length) >>> >>> I thinks that must add a code section in sample() method when JMeter >>> reads response data, to decode GZip response if needs, like HC3Impl? >>> (perhaps HC4 has a specific method to do this?) >>> >> HC4 should do this automatically, I think, but there was a bug whereby >> it did not recognise some encoding methods: >> >> https://issues.apache.org/jira/browse/HTTPCLIENT-1063 >> >> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which >> JMeter trunk was recently updated to use). >> >> Can you check which version of HC4 you were using, and the >> Content-type used by Apache 2.2? >> > > I uses last JMeter with HC v4.1.1 > httpclient-4.1.1.jar > httpmime-4.1.1.jar > and > httpcore-4.1.jar > > Response headers (extract) : > Server: Apache/2.2.16 (Unix) DAV/2 > Accept-Ranges: bytes > Vary: Accept-Encoding > Content-Encoding: gzip > Content-Length: 70 > > Request Headers: > Connection: keep-alive > Accept-Encoding: gzip,deflate > > (I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue) > > Issue too with www.google.com Thanks, that was useful, though strangely google would not gzip until I added a User-Agent of Firefox. Accepting gzip was not enough. Code now fixed - HC4 does support gzip decoding, but not by default. > Milamber >> >>> Milamber >>> >>> >>> Le 25/11/2010 15:45, sebb a ecrit : >>> Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
On 6 April 2011 23:36, Milamber wrote: > >> HC4 should do this automatically, I think, but there was a bug whereby >> > > I have found this problem too: > Unlike HC3, HC4 sampler works with a HTTPS website with a trusted > certificate (verisign, thawte, etc.) but doesn't works with self-signed > ssl certificate. > I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal? No, I forgot. That needs to be fixed so that all certificates are accepted, same as for HC3. I'll fix that shortly. > Milamber > > >> it did not recognise some encoding methods: >> >> https://issues.apache.org/jira/browse/HTTPCLIENT-1063 >> >> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which >> JMeter trunk was recently updated to use). >> >> Can you check which version of HC4 you were using, and the >> Content-type used by Apache 2.2? >> >> >>> Milamber >>> >>> >>> Le 25/11/2010 15:45, sebb a ecrit : >>> Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
> HC4 should do this automatically, I think, but there was a bug whereby > I have found this problem too: Unlike HC3, HC4 sampler works with a HTTPS website with a trusted certificate (verisign, thawte, etc.) but doesn't works with self-signed ssl certificate. I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal? Milamber > it did not recognise some encoding methods: > > https://issues.apache.org/jira/browse/HTTPCLIENT-1063 > > As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which > JMeter trunk was recently updated to use). > > Can you check which version of HC4 you were using, and the > Content-type used by Apache 2.2? > > >> Milamber >> >> >> Le 25/11/2010 15:45, sebb a ecrit : >> >>> Just a heads up that I'm currently working on trying to combine the >>> HTTP implementations (Java, HttpClient3) into a single GUI, with >>> run-time choice of implementation. >>> >>> The rationale for this is that HttpClient 4 is now available, and it >>> would be good to add that, but I think we should keep HttpClient for >>> backwards compatibility and comparison. >>> >>> Creating another GUI/Sampler set is easy enough, but it would be >>> useful to be able to switch implementations easily - currently that >>> requires switching samplers (e.g. by editting the JMX file). >>> >>> The current plan is to allow the implementation to be specified on the >>> HTTP Request Defaults config screen as well as on the HTTP Request >>> screen. >>> >>> The code is a bit involved, because the Config settings are processed >>> at run-time after the test plan has been built. >>> [But even the Sampler GUI needs to create the sampler before it can >>> store the sampler settings - and the implementation can then be >>> changed.] >>> Currently I use a Sampler Proxy that dispatches to the appropriate >>> implementation class. >>> These classes have to extend an abstract class that provides the >>> necessary methods to interface with the Proxy test element and thus >>> provide access to the test element properties. >>> That part seems to be working OK. >>> >>> The next phase is to ensure that existing JMX files can be converted >>> (during load) to use the new sampler. >>> >>> The intention is to keep the existing Java and HttpClient samplers, so >>> that subclasses will continue to work, but not expose them in the GUI. >>> >>> I've not finally decided about the AJP sampler - it can be easily >>> converted, but I don't think there's much of a use case for switching >>> between AJP and another implementation. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > - > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
>> When Web server (Apache 2.2) uses mod_deflate to compress response data, >> the data remains compress data (in view results tree, we have the >> compress characters and getBytes() is the compressed length) >> >> I thinks that must add a code section in sample() method when JMeter >> reads response data, to decode GZip response if needs, like HC3Impl? >> (perhaps HC4 has a specific method to do this?) >> > HC4 should do this automatically, I think, but there was a bug whereby > it did not recognise some encoding methods: > > https://issues.apache.org/jira/browse/HTTPCLIENT-1063 > > As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which > JMeter trunk was recently updated to use). > > Can you check which version of HC4 you were using, and the > Content-type used by Apache 2.2? > I uses last JMeter with HC v4.1.1 httpclient-4.1.1.jar httpmime-4.1.1.jar and httpcore-4.1.jar Response headers (extract) : Server: Apache/2.2.16 (Unix) DAV/2 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 70 Request Headers: Connection: keep-alive Accept-Encoding: gzip,deflate (I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue) Issue too with www.google.com Milamber > >> Milamber >> >> >> Le 25/11/2010 15:45, sebb a ecrit : >> >>> Just a heads up that I'm currently working on trying to combine the >>> HTTP implementations (Java, HttpClient3) into a single GUI, with >>> run-time choice of implementation. >>> >>> The rationale for this is that HttpClient 4 is now available, and it >>> would be good to add that, but I think we should keep HttpClient for >>> backwards compatibility and comparison. >>> >>> Creating another GUI/Sampler set is easy enough, but it would be >>> useful to be able to switch implementations easily - currently that >>> requires switching samplers (e.g. by editting the JMX file). >>> >>> The current plan is to allow the implementation to be specified on the >>> HTTP Request Defaults config screen as well as on the HTTP Request >>> screen. >>> >>> The code is a bit involved, because the Config settings are processed >>> at run-time after the test plan has been built. >>> [But even the Sampler GUI needs to create the sampler before it can >>> store the sampler settings - and the implementation can then be >>> changed.] >>> Currently I use a Sampler Proxy that dispatches to the appropriate >>> implementation class. >>> These classes have to extend an abstract class that provides the >>> necessary methods to interface with the Proxy test element and thus >>> provide access to the test element properties. >>> That part seems to be working OK. >>> >>> The next phase is to ensure that existing JMX files can be converted >>> (during load) to use the new sampler. >>> >>> The intention is to keep the existing Java and HttpClient samplers, so >>> that subclasses will continue to work, but not expose them in the GUI. >>> >>> I've not finally decided about the AJP sampler - it can be easily >>> converted, but I don't think there's much of a use case for switching >>> between AJP and another implementation. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > - > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
On 3 April 2011 23:19, Milamber wrote: > Hello, > > Currently I works to add a optional property to get response size (in > bytes) by different methods: > 1/ default (responses data size (uncompressed length if gzip) > 2/ responses headers length + default (response data size) > 2/ responses headers length + content-length value (real size if gzip) > See: > https://issues.apache.org/bugzilla/show_bug.cgi?id=43363 > https://issues.apache.org/bugzilla/show_bug.cgi?id=50170 > > When I testing my future patch, I found this bug on HC4 Impl: > > When Web server (Apache 2.2) uses mod_deflate to compress response data, > the data remains compress data (in view results tree, we have the > compress characters and getBytes() is the compressed length) > > I thinks that must add a code section in sample() method when JMeter > reads response data, to decode GZip response if needs, like HC3Impl? > (perhaps HC4 has a specific method to do this?) HC4 should do this automatically, I think, but there was a bug whereby it did not recognise some encoding methods: https://issues.apache.org/jira/browse/HTTPCLIENT-1063 As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which JMeter trunk was recently updated to use). Can you check which version of HC4 you were using, and the Content-type used by Apache 2.2? > Milamber > > > Le 25/11/2010 15:45, sebb a ecrit : >> Just a heads up that I'm currently working on trying to combine the >> HTTP implementations (Java, HttpClient3) into a single GUI, with >> run-time choice of implementation. >> >> The rationale for this is that HttpClient 4 is now available, and it >> would be good to add that, but I think we should keep HttpClient for >> backwards compatibility and comparison. >> >> Creating another GUI/Sampler set is easy enough, but it would be >> useful to be able to switch implementations easily - currently that >> requires switching samplers (e.g. by editting the JMX file). >> >> The current plan is to allow the implementation to be specified on the >> HTTP Request Defaults config screen as well as on the HTTP Request >> screen. >> >> The code is a bit involved, because the Config settings are processed >> at run-time after the test plan has been built. >> [But even the Sampler GUI needs to create the sampler before it can >> store the sampler settings - and the implementation can then be >> changed.] >> Currently I use a Sampler Proxy that dispatches to the appropriate >> implementation class. >> These classes have to extend an abstract class that provides the >> necessary methods to interface with the Proxy test element and thus >> provide access to the test element properties. >> That part seems to be working OK. >> >> The next phase is to ensure that existing JMX files can be converted >> (during load) to use the new sampler. >> >> The intention is to keep the existing Java and HttpClient samplers, so >> that subclasses will continue to work, but not expose them in the GUI. >> >> I've not finally decided about the AJP sampler - it can be easily >> converted, but I don't think there's much of a use case for switching >> between AJP and another implementation. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: svn commit: r1088435 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/protocol/http/org/apache/jmeter/protocol/http/sampler/ xdocs/ xdocs/usermanual/
On 4 April 2011 20:35, Milamber wrote:
>
> [snip]
>>> +#http.getbytes.type=default
>>> +#http.getbytes.type=calculate_headers_size+default
>>> +#http.getbytes.type=calculate_headers_size+content-length_value
>>>
>> These values are a bit complicated; I'd prefer to see true/false
>> values if possible.
>>
> Ok I change this to 2 properties true/false.
+1
>>
>>> + /**
>>> + * Get Content-Length value from headers
>>> + * @param headers
>>> + * @return Content-Length value
>>> + */
>>> + public static int getHeaderContentLength(String headers) {
>>> + LinkedHashMap lhm =
>>> JMeterUtils.parseHeaders(headers);
>>> + Set> keySet = lhm.entrySet();
>>> + for (Entry entry : keySet) {
>>> + if (entry.getKey().equals(HEADER_CONTENT_LENGTH)) {
>>> + return Integer.parseInt(entry.getValue());
>>> + }
>>> + }
>>> + return 0; // Content-Length not found
>>>
>> This does not work for chunked input. It might be better to store the
>> actual response size when receiving the response, rather than trying
>> to calculate it later.
>>
>
> Ok, store in sampleresult when receiving the response. If 0 (no value),
> the response data size is used.
>
>
> With my last submission (r1088748), I try to respond to your feedback.
> Please say me if another thing to improve.
The problem of chunked responses still exists - such responses don't
have a Content-Length header.
One way round this would be to wrap the input Stream with a
org.apache.commons.io.input.CountingInputStream.
I don't think this will affect performance adversely.
Does that make sense?
-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org
