REST API call to NP8.3 works, yet the very same call to NP9.1 fails with "java.lang.IllegalStateException: Already connected"
We are upgrading NP from 8.3 to 9.1, and when I run the very same REST-API test-setup (i.e. code/machine/Java/etc) - which works fine against an NP8.3 - against an NP9.1, the call to the NP9.1 fails with “java.lang.IllegalStateException: Already connected” (see attached traces).
Please note both NP8.3 and NP9.1 reside on the same machine, and so they share the very same environment (i.e. I simply stop one and start the other in order to alternate), and in fact the same settings too.
and unless I am missing something, by elimination this is not a client issue (again - since I use the very same REST-API test-setup, including the very same code/JVM/etc), but rather a server issue.
Could anyone please advise ?
 |
Rafi Cohen
Member (305) 1 2 2 |
05/12/2017 ( History) |
Resolved the issue, which seems to be server related: we have Nuxeo (i.e. its Tomcat) configured to only accept/use 256bits ciphers; and even though I have forgotten to add the unlimited strength jurisdiction policy files required for 256bits encryption to either party (client/test-code and server/NP), NP8.3 (i.e. its 7.0.64 Tomcat) has had no issues accepting connections from the client (even though it should have declined them, given they were 128bits ciphers at the most), whereas NP9.1, with its 7.0.69 Tomcat has refused the connection (as it should):
running the client against NP9.1 with the addition of '-Djavax.net.debug=ssl' has shown
Ignoring unsupported cipher suite ...
for all the 256bits ciphers (as not available) as well as for the 128bits ciphers (as NP9.1 was set to only accept/use 256bits ciphers), followed later on by
main, WRITE: TLSv1.2 Handshake, length = 161
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT: fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, called close()
main, called closeInternal(true)
1219 [main] ERROR com.datapath.maxview.docrepoadapter.impl.RESTHelper - Batch Creation: Exception during an attempt to create a batch
javax.ws.rs.ProcessingException: Already connected
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:263)
...
and on the server/NP9.1 side, with Tomcat log level set to DEBUG (since for some reason the following is logged at DEBUG level): server.log
2017-05-15 16:30:59,527 DEBUG [http-bio-0.0.0.0-8491-exec-1] [org.apache.tomcat.util.net.JIoEndpoint] Handshake failed
java.io.IOException: SSL handshake failed. Ciper suite in SSL Session is SSL_NULL_WITH_NULL_NULL
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:291)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:304)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
p.s. funnily https://tomcat.apache.org/tomcat-7.0-doc/changelog.html does not mention this change
|
Rafi Cohen
Member (305) 1 2 2 |
05/16/2017 ( History) |
The error in your stack trace is purely client-side in your networking code. You should google for HttpURLConnection "Already connected" and review your RESTHelper code for correct behavior with respect to HTTP connections.
 |
Florent Guillaume
Member (36K) 6 8 8 |
05/12/2017 ( History) |