Upgrade to 4.5.2 and fix commited yesterday evening On Sunday, January 31, 2016, Philippe Mouawad <[email protected]> wrote:
> Thanks Vladimir. > > @Felix, with http-client-4.5.2 and this line uncommented: > // FIXME when 4.5.2 is released, see > https://issues.apache.org/jira/browse/HTTPCORE-397 > ((AbstractHttpClient) > httpClient).setReuseStrategy(DefaultClientConnectionReuseStrategy.INSTANCE); > > I don't reproduce the Connect Timeout issue due to keep alive. > Note this is the version I am testing and that face the issue. So there is > another problem. > > Regards > Philippe > > On Sun, Jan 31, 2016 at 8:58 PM, Vladimir Sitnikov < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> JFR confirms the issue is not related with GC/locking/excessive >> processing. >> >> I wonder if tcp dump/wireshark would help to analyze the difference. >> >> Findings so far: >> 1) >> org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser#getEmbeddedResourceURLs >> is converting response bytes to String (see [1]). >> It is better to use SampleResult#getResponseDataAsString since the >> latter would cache the string, thus eliminate repeated utf-8 decoding. >> >> 2) In 3.0 >> org.apache.jmeter.protocol.http.control.HC4CookieHandler#getCookiesForUrl >> is a little bit more involved since cookieSpec.match delegates to >> org.apache.http.impl.cookie.DefaultCookieSpec.match(Cookie, >> CookieOrigin) -> CookieSpecBase.match -> >> PublicSuffixDomainFilter.match ->... >> In 2.14 it is much simpler. >> In 3.0, DefaultCookieSpec.match accounts for 3% of all cpu time. >> >> I do not see how those issues could result in "connect timeout" though. >> >> [1]: >> https://github.com/apache/jmeter/blob/9a1b9a02c7593553cb6047bddcfbccb79ec72fc9/src/protocol/http/org/apache/jmeter/protocol/http/parser/LagartoBasedHtmlParser.java#L210 >> >> Vladimir >> > > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
