> I need to do some more tests, as it may turn out that this still does not > give enough control over connection re-use.
It's the same with the Apache Commons HTTPClient - it automatically reuses connections. Which, when you're simulating multiple users is really the wrong thing to do. Ideally, you'd want connections re-used by thread. I assume the only way we'll get this in JMeter is to take the commons code and modify it to JMeter's needs. -Mike > > Sebastian > -----Original Message----- > From: Scott Eade [mailto:[EMAIL PROTECTED] > Sent: 02 April 2003 07:31 > To: JMeter Developers List > Subject: Re: Persistent connections - what implementation to use? > > > From what I have seen on the [EMAIL PROTECTED] mailing list it is not possible > to use LGPL libraries as runtime dependencies in ASF licensed projects. I > am pretty sure there is a licensing mailing list for discussing these kinds > of issues (licensing at jakarta dot apache dot org). > > Cheers, > > Scott > -- > Scott Eade > Backstage Technologies Pty. Ltd. > http://www.backstagetech.com.au > .Mac Chat/AIM: seade at mac dot com > > > On 2/04/2003 3:59 AM, "BAZLEY, Sebastian" > <[EMAIL PROTECTED]> wrote: > > > Thanks. > > > > The Innovation version is one I found when looking for details on how > > HttpUrlConnection works. > > > > <quote> > > The whole thing is free, and licenced under the GNU Lesser General Public > > License (LGPL) (note that this is not the same as the GPL). > > </quote> > > > > I guess that means it could be used with JMeter ... I intend to give it a > > try anyway for our purposes. > > > > I can try and fix the SSL code so that it does not stomp on the setting. > > I'm not sure I'll be able to test it properly, but I'll try and do it in a > > way that does not affect the existing usage. > > > > S. > > -----Original Message----- > > From: Mike Stover [mailto:[EMAIL PROTECTED] > > Sent: 01 April 2003 17:09 > > To: JMeter Developers List > > Subject: Re: Persistent connections - what implementation to use? > > > > > > We once took a look at the jakarta commons http client. It looks good, > but > > not > > significantly different from Sun's implementation. I've never heard of > the > > innovation > > one - what kind of license does it have? > > > > I don't know why the SSLManager does the things it does - that's one of > the > > bits I > > didn't write. Feel free to fix it if you're inclined... > > > > -Mike > > > > On 1 Apr 2003 at 16:40, BAZLEY, Sebastian wrote: > > > >> We are using JMeter to test a Tomcat servlet application, and would like > > to > >> be able to test using persistent connections. > >> > >> [The clients would normally connect/login once, and then re-use the same > >> connection for subsequent requests.] > >> > >> However, there are one or two problems with doing this, not least the use > > of > >> the default Sun implementation of HttpURLConnection, which is not > >> particularly well-suited to connection re-use. > >> > >> There are a couple of alternatives that look feasible: > >> > >> HTTPClient 0.3-3 http://www.innovation.ch/java/HTTPClient/ > >> HttpClient 2.0alpha3 > > http://jakarta.apache.org/commons/httpclient/index.html > >> > >> The former seems to be a lot simpler to use, as far as I can tell. > >> > >> Just wondering if anyone else has looked at this before I go any further? > >> > >> == > >> > >> Also, does anyone know why the System property > > "java.protocol.handler.pkgs" > >> is set by SSLManager.java and SSLManagerCommand.java? > >> > >> This currently precludes the use of HTTPClient 0.3-3 as a plug-in > >> replacement for the basic Sun implementation. > >> > >> -- > >> The opinions expressed herein are my own, and are not necessarily > endorsed > >> by my employer ... > [snip sigbloat] > > > _________________________________________________________ > This email is confidential and intended solely for the use of the > individual to whom it is addressed. Any views or opinions presented are > solely those of the author and do not necessarily represent those of > SchlumbergerSema. > If you are not the intended recipient, be advised that you have received > this email in error and that any use, dissemination, forwarding, printing, > or copying of this email is strictly prohibited. > > If you have received this email in error please notify the > SchlumbergerSema Helpdesk by telephone on +44 (0) 121 627 5600. > _________________________________________________________ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
