nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

REST API call to NP8.3 works, yet the very same call to NP9.1 fails with "java.lang.IllegalStateException: Already connected"

Rafi_Cohen

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 ?

NP-9.1_REST-API_Exception.txt

Find more posts tagged with

Comments

Florent_Guillau

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.

Rafi_Cohen

[Florent Guillaume](https

Florent_Guillau

Without knowing more about what your code does or looking at comparative network traces of a 8.3 and a 9.1 request, it's hard to say. It's debugging time...

Rafi_Cohen

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