Re: implementing use of multiple certificates on a per thread basis
sebb-2-2 wrote:
So - have you tried commenting the code again?
Yes, I have commented out that block, leaving all of the other changes I've
made intact. I just did it again to reconfirm.
Commenting out that block of code allows the tests to run as expected (e.g.
no Socket or Connect Exceptions). Unfortunately, that block of code is
needed to enable JMeter to switch certificates on a per thread basis. I've
tried to look into what the block of code does, but there is very little
info in the javadocs for javax.net
Maybe there is an alternate way of doing the same thing?
Thanks,
-Ash
sebb-2-2 wrote:
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
Re: implementing use of multiple certificates on a per thread basis
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.
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:
Re: implementing use of multiple certificates on a per thread basis
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
Re: implementing use of multiple certificates on a per thread basis
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
