(I\'ve asked the same question of the jmeter-user mailing list, but I wanted to try here as well - so at the least I can update this with the answer once I find it).
I had Web Service problems similar to this with jdk 1.6.0_10.
I upgraded to 1.6.0_16 and everything worked.
Try searching your classpath (in Eclipse, I do ctrl-shift-t to do this) for SSLSocketFactory*. If you find one, set it as a property on the Security class:
In my environment, I've found the following two:
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");
or
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.websphere.ssl.protocol.SSLSocketFactory");
(or for whatever other class you find)
Similarly for ServerSocketFactory
, if you need server sockets.
Most javax.net.SocketFactory
implementations define all createSocket()
methods that have parameters as abstract. But have a createSocket()
method without parameters that looks like this:
public Socket createSocket() throws IOException {
throw new SocketException("Unconnected sockets not implemented");
}
So if you subclass the abstract javax.net.SocketFactory
you will be force to override the methods with parameter, but it's easy to miss to override the createSocket()
method without parameters. Thus the exception is thrown if your code calls createSocket()
. Simply override the method and the be done. :)
I had the same problem in my code (not related to JMeter).
My code uses a self-defined SocketFactory
. What I found out is that the class com.sun.jndi.ldap.Connection
calls some methods of the SocketFactory
using Method.invoke()
. One of the methods it tries to call is createSocket()
- without parameters.
When I added such method to my factory all worked fine.
Here is my solution (java 1.6) removing TLS_DHE_ ciphers completely, force to override the methods createSocket()
(https://gist.github.com/hoangthienan/735afb17ffd6955de95a49aa0138dbaa)
This is a hint rather than a proper answer: A cursory glance at Google results seems to suggest that the exception is usually caused by the code forcing the use of a default SSL socket factory that on purpose throws the exception when createSocket() is invoked on it. What some of the results seem to suggest is that the issue sometimes happens due to a bug in certain version in Java 6, or when the incorrect path or password is provided to the keystore.
So, I'd say, try using Java 5. Also, try pointing JMeter to a well-known site that uses proper SSL certificates. This way you could test the self-signed certificate hypothesis.