On 08/09/2009, ashie127 <ashie...@optonline.net> wrote:
>
> Thanks for the reply, sebb.
>
>
>
> sebb-2-2 wrote:
> >
> > Are you sure that nothing else has changed?
> > Does the test still work if you revert to 2.3.4?
> >
>
>
> Yes, I am positive nothing else has changed in terms of code and in terms of
> environment. The tests work fine when I revert to 2.3.4, and I have run the
> tests nightly using 2.3.4 with consistent results.
>
> One thing I should note is that the tests are run in non-GUI, distributed
> mode using 2 servers: 1 being dedicated for just instances of jmeter-server,
> while the other server has both jmeter clients and servers running (I know
> this is not the best way to do this, but due to network constraints, this is
> what has come to be. AND don't forget this setup works fine with the
> unmodified 2.3.4 ). Also, 3 tests are run simultaneously, with each test
> representing a different user of our system.
>
> So in total:
> server #1: 3 instances of jmeter-server, 3 instances of jmeter client in
> non-GUI mode
> server #2: 3 instances of jmeter-server
>
> Lastly, I want to point out what I feel is the culprit in the changes I've
> made. In JsseSSLManager, there was a block of code that was commented out,
> and I uncommented it to add it back in:
>
> ###########################################################
>
> public void setContext(HttpURLConnection conn) {
> if (conn instanceof HttpsURLConnection) {
> /*
> * No point doing this on a per-connection basis, as there is currently no
> way to configure it.
> * So we leave it to the defaults set up in the SSL Context
> *
> */
> try
> {
> HttpsURLConnection secureConn = (HttpsURLConnection) conn;
>
> secureConn.setSSLSocketFactory(this.getContext().getSocketFactory());
> }
> catch(Exception e)
> {
> System.out.println("SOMETHING I PUT IN BROKE THIS!");
> System.out.println(e);
> }
>
> ###########################################################
>
> Without this block of code, JMeter will switch certificates every time a
> test is started, but what I needed was for JMeter to switch certificates
> every time a thread is started. With this block of code, JMeter does just
> that. I feel this is the culprit because it is the only change I made that
> would have a major impact on the functionality of the software, EVEN when
> not using PKI.
>
> Let me know if anyone has any ideas on what is happening and/or how to solve
> this.
So - have you tried commenting the code again?
> Thanks again,
> -Ash
>
>
>
> sebb-2-2 wrote:
> >
> > On 02/09/2009, ashie127 <ashie...@optonline.net> wrote:
> >>
> >> Hello All,
> >>
> >> I am reposting here as I posted this in
> >>
> >>
> http://www.nabble.com/multiple-user-certs-in-single-jmeter-test--td11034523.html
> >> JMeter-User earlier today, but I feel it belongs to JMeter-Dev.
> >>
> >> I would like to have each thread of a test use a different certificate
> >> from
> >> a bunch of certificates stored in a single Java Keystore (JKS).
> >>
> >> I've made changes to some of the classes in org.apache.jmeter.util
> >> (under
> >> src/core) of Jmeter 2.3.4 r785646. The changes are messy and quick
> >> fixes
> >> for sure, but allow me to do what I suggested above. If you have a
> >> keystore
> >> with 1000 certificates, Jmeter will pick a different one for each thread
> >> in
> >> a round-robin fashion starting from the first certificate. If you have
> >> more
> >> threads than certificates, Jmeter will restart from the beginning of the
> >> keystore when the last certificate is reached.
> >
> > OK, understood.
> >
> >> My problem is that tests that ran fine before using the unmodified
> >> version
> >> of Jmeter 2.3.4 r785646 now have a decent percentage of ConnectException
> >> (578/86400) errors and a very small percentage of SocketException errors
> >> (1/86400), EVEN when not using PKI at all. The tests have about 1000
> >> active
> >> threads at any time.
> >>
> >> SocketException:
> >> rc="Non HTTP response code: java.net.SocketException" rm="Non HTTP
> >> response
> >> message: Connection reset"
> >>
> >> ConnectException:
> >> rc="Non HTTP response code: java.net.ConnectException" rm="Non HTTP
> >> response
> >> message: Connection timed out"
> >
> > Are you sure that nothing else has changed?
> > Does the test still work if you revert to 2.3.4?
> >
> >> I've attached the files I've changed (at least I believe this is all of
> >> them). I was wondering if anyone has any idea what I am doing wrong,
> >> considering I've given up on doing it myself after about a week of
> >> debugging.
> >>
> >> Thanks in advance,
> >> -Ash
> >>
> >> P.S. - My apologies for the repost.
> >>
> >> P.P.S. - On second thought, I should have gave patches instead, but I've
> >> already uploaded the files. If you would like patches instead, please
> >> let
> >> me know.
> >>
> >> http://www.nabble.com/file/p25260933/JsseSSLManager.java
> >> JsseSSLManager.java
> >> http://www.nabble.com/file/p25260933/SSLManager.java SSLManager.java
> >> http://www.nabble.com/file/p25260933/JmeterKeyStore.java
> >> JmeterKeyStore.java
> >> http://www.nabble.com/file/p25260933/DefaultKeyStore.java
> >> DefaultKeyStore.java
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/implementing-use-of-multiple-certificates-on-a-per-thread-basis-tp25263354p25263354.html
> >> Sent from the JMeter - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
> >
> >
> >
>
>
> --
> View this message in context:
> http://www.nabble.com/implementing-use-of-multiple-certificates-on-a-per-thread-basis-tp25263354p25351216.html
>
> Sent from the JMeter - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
