I've started getting below error while running migrateIn command both in different Gateway clusters.
Below is GMU command that I'm running and response - GatewayMigrationUtility-1.5.00-479>GatewayMigrationUtility.bat migrateIn --argFile Stage.properties --bundle XXXX.xml --test
Warning: TLS hostname verification has been disabled Warning: TLS server certificate check has been disabled Running...... Execution failed. Reason: Unable to establish trust with the Gateway. To resolve, either: ? Establish server trust and try again (more info: search "establish server trust" in the Gateway do cumentation), OR ? Re-run command with the "--trustCertificate" parameter to bypass trust requirement.
And please note the excerpt from GMU log - Apr 12, 2018 9:11:13 PM com.ca.gateway.rest.commandline.command.GatewayCommand setClientConfig WARNING: TLS hostname verification has been disabled Apr 12, 2018 9:11:13 PM com.ca.gateway.rest.commandline.command.GatewayCommand setClientConfig WARNING: TLS server certificate check has been disabled Apr 12, 2018 9:11:13 PM com.ca.gateway.rest.commandline.command.Command runCommand INFO: Running Command: migrateIn Apr 12, 2018 9:11:16 PM com.ca.gateway.rest.commandline.command.Command runCommand WARNING: Error executing command javax.ws.rs.ProcessingException: Already connected at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:236) at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:655) at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:652) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:228) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:422) at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:652) at com.ca.gateway.rest.api.GatewayManagementGatewayClient$IP10Bundle.putXml(Unknown Source) at com.ca.gateway.rest.api.resource.impl.BundleResource.importBundle(Unknown Source) at com.ca.gateway.rest.commandline.command.MigrateInCommand.a(Unknown Source) at com.ca.gateway.rest.commandline.command.MigrateInCommand.run(Unknown Source) at com.ca.gateway.rest.commandline.command.GatewayCommand.run(Unknown Source) at com.ca.gateway.rest.commandline.command.Command.runCommand(Unknown Source) at com.ca.gateway.rest.commandline.Main.main(Unknown Source) Caused by: java.lang.IllegalStateException: Already connected at sun.net.www.protocol.http.HttpURLConnection.setRequestProperty(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.setRequestProperty(Unknown Source) at org.glassfish.jersey.client.HttpUrlConnector.setOutboundHeaders(HttpUrlConnector.java:292) at org.glassfish.jersey.client.HttpUrlConnector.access$100(HttpUrlConnector.java:83) at org.glassfish.jersey.client.HttpUrlConnector$3.getOutputStream(HttpUrlConnector.java:266) at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:200) at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:194) at org.glassfish.jersey.message.internal.CommittingOutputStream.commit(CommittingOutputStream.java:262) at org.glassfish.jersey.message.internal.OutboundMessageContext.commitStream(OutboundMessageContext.java:812) at org.glassfish.jersey.client.ClientRequest.writeEntity(ClientRequest.java:526) at org.glassfish.jersey.client.HttpUrlConnector._apply(HttpUrlConnector.java:270) at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:182) at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:227) ... 14 more Thanks
The "javax.ws.rs.ProcessingException: Already connected" error is one that we has been reported by customers a number of times before with the GMU, even when using the "trustCertificate" and "trustHostname" parameters. Here are some specific examples of other issues that have been seen to cause that error to appear:
- DNS issue for resolving target gateway(resolved by adding entry to local hosts file of the machine running the GMU) - Firewall issue between GMU and gateway - gateway port 8443 restricted to traffic from a specific IP - Incorrect certificate was associated with the port in question GMU was connecting to. The "trustCertificate" option removes the need for the machine that the GMU is being run on to have the server certificate trusted in it's local store. However, the certificate presented by the gateway must still be accurate for that gateway(for example, if the cert is for 'test.ca.com', but the hostname of the gateway is 'XYZ123.ca.com', that could cause an issue)
Release: Component: APIGTW
Used hostname instead of IP address in GMU properties file to resolve the issue