Develop Reference

Java RMI - Lookup Success , but method call fails - Onpremise Vs AWS

I have a java code which makes connection to a Java RMI server - lookup followed by method invocation.
Both machine are under the same firewall in onpremise and works as expected.
When my client/java moved to AWS, the RMI server is still running in on-premise.. But here in this case, it fails with below error..
Lookup success, method call failed..
Lookup for Remote Object Successful.
ErrorMessage:startupFunction : RemoteException Caught.. Connection refused to host: XXXXX ; nested exception is:
java.net.ConnectException: Connection timed out
PS : I see similiar issue in this post, but nothing seems to work in my case

You need to export your remote object on a fixed port, and open that port in your firewall.

Fixed this by adding the port used by RMI Method.. We ran the request from on-premise and in the RMI host we ran netstat and captured the port list.. This way we could figure out the port and enabled in Security group in AWS.. thanks all for your help..

HTTP transport error: java.net.SocketException: Connection reset

A client application has been built using Jdeveloper 10.1.3.2 and it is running on OC4J server. This application is sending data to external server application. It is working for quite long time without any issue. Lately a connection issue occurred and the following stack trace is generated:
com.sun.xml.ws.client.ClientTransportException: HTTP transport error: java.net.SocketException: Connection reset
at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:133)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:153)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:93)
at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy44.sendRem(Unknown Source)
After goggling I found out a good discussion about the error sockets - What's causing my java.net.SocketException: Connection reset? .One answer in this link says that the issue mostly from the client side because if it is from the server side the exception will be (SocketException reset by peer).
What I did:
I tried out to increase the socket time out for the OC4J with the help of this form How to change OC4J HTTP Timeout. What I did is I changed the propriety oracle.j2ee.http.socket.timeout to be 5000 instead of 500 (10 times longer)
But the error still there. So, any suggestion to over come this issue?
Note: I able to use telnet command for external server IP and Port and it is working fine.
-------------------------------------------------------- Update 1 --------------------------------------------------------
I increase the server clock skew where the client application is running using the following command on server start up:
-Dweblogic.wsee.security.clock.skew=72000000
-Dweblogic.wsee.security.delay.max=72000000
But no luck, problem is not resolved.
-------------------------------------------------------- Update 2 --------------------------------------------------------
I realized that the problem is not from application at all; I test the external URL using SoapUI and I got the same error Connection rest. I think this new update clreay shows that there is nothing wrong with program code. But I need to know where to go or check now. Where is the starting point now to overcome the issue. Any clue will be helpful.

As you can see from Update 2 in the question, the problem was not from the client application because same error occurred from SoapUI.
The problem was that the machine where the client application was running have low bandwidth which was not enough for APIs communication. Using simple speed test , I found out that the upload bandwidth was low comparing to minimum requirements given by server application team.
I concluded this fact by monitoring the network resource using Resource Monitor in Windows while the client application was running and by using online speed check
To solve the issue, the machine bandwidth has to be increased where the client application is running.

getting an exception with hazelcast server and client

I launched the hazelcast server with my model classes that I do not recall seeing with the sample client - the error is copied below:
Couldn't connect to discovered master! tryCount: 50
Any suggestions on troubleshooting this would be great

If using multicasting, try switching over to tcp based connections. If that does not help, try checking if there are more detailed exceptions (or perhaps add one from where the exception is being generated).
On linux, I believe you can check for multicasting permissions through ifconfig eth0 - result should give you a value for multicasting.

Cannot get remote client example application for Oracle Coherence working, can't connect to server

New to Oracle Coherence. I am trying to follow the example java remote client application in the Oracle documentation. I have two different computers each with a CentOS VM running on it. One VM is acting as the server and the other the remote client. I am trying to just run the sample TestClient integer application. I changed the configuration files so the server VM is set as the tcp-acceptor and the client looks for that remote address. The two VM's can ping each other
In the documentation when starting the cache server, why does it need the TestClient application on the classpath? Unlike the example I am not running both the server and client on the same machine, do I still need to do this? I have been starting up the cache server like so without the TestClient app on the classpath:
java -cp COHERENCE_HOME\lib\coherence.jar;PATH_TO_CLIENT -Dtangosol.coherence.cacheconfig=PATH\example-config.xml com.tangosol.net.DefaultCacheServer
On the client side I get the error:
Exception in thread "main" com.tangosol.net.messaging.ConnectionException: could not establish a connection to one of the following addresses: [128.183.208.3:9099]; make sure the "remote-addresses" configuration element contains an address and port of a running TcpAcceptor
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.peer.initiator.TcpInitiator.openConnection(TcpInitiator.CDB:121)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.peer.Initiator.ensureConnection(Initiator.CDB:11)
at com.tangosol.coherence.component.net.extend.remoteService.RemoteCacheService.openChannel(RemoteCacheService.CDB:7)
at com.tangosol.coherence.component.net.extend.RemoteService.doStart(RemoteService.CDB:11)
at com.tangosol.coherence.component.net.extend.RemoteService.start(RemoteService.CDB:5)
at com.tangosol.coherence.component.util.SafeService.startService(SafeService.CDB:53)
at com.tangosol.coherence.component.util.safeService.SafeCacheService.startService(SafeCacheService.CDB:5)
at com.tangosol.coherence.component.util.SafeService.ensureRunningService(SafeService.CDB:27)
at com.tangosol.coherence.component.util.SafeService.start(SafeService.CDB:14)
at com.tangosol.net.ExtensibleConfigurableCacheFactory.startService(ExtensibleConfigurableCacheFactory.java:681)
at com.tangosol.net.ExtensibleConfigurableCacheFactory.ensureService(ExtensibleConfigurableCacheFactory.java:599)
at com.tangosol.coherence.config.scheme.AbstractCachingScheme.realizeCache(AbstractCachingScheme.java:50)
at com.tangosol.coherence.config.scheme.AbstractBundlingScheme.realizeCache(AbstractBundlingScheme.java:31)
at com.tangosol.net.ExtensibleConfigurableCacheFactory.ensureCache(ExtensibleConfigurableCacheFactory.java:254)
at com.tangosol.net.CacheFactory.getCache(CacheFactory.java:205)
at com.tangosol.net.CacheFactory.getCache(CacheFactory.java:182)
at TestClient.main(TestClient.java:11)
On the server side the cache server runs but I get:
2014-05-20 12:26:06.168/77.693 Oracle Coherence GE 12.1.2.0.0 <Info> (thread=PacketListenerN, member=1): Scheduled senior member heartbeat is overdue; rejoining multicast group.
2014-05-20 12:26:06.185/77.710 Oracle Coherence GE 12.1.2.0.0 <Warning> (thread=PacketListenerN, member=1): MulticastUdpSocket failed to set receive buffer size to 16 packets (1MB); actual size is 11%, 1 packets (122KB). Consult your OS documentation regarding increasing the maximum socket buffer size. Proceeding with the actual value may cause sub-optimal performance.
Any help or guidance in the right direction would be super appreciated

org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 from stand-alone app

I'm connecting to the WebSphere instance from the stand-alone Java app which is quite trivial:
InitialContext initCtx = new InitialContext();
That code was working perfectly in WebSphere 7, but after updating to WebSphere 8.5 I got the following exception:
Caused by: org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 completed: No
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1276)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1457)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1164)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1423)
at com.ibm.rmi.corba.ClientDelegate.request(ClientDelegate.java:1886)
at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1379)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:458)
at com.ibm.WsnBootstrap._WsnNameServiceStub.getProperties(_WsnNameServiceStub.java:38)
at com.ibm.ws.naming.util.WsnInitCtxFactory.mergeWsnNSProperties(WsnInitCtxFactory.java:1441)
... 43 more
After research, I've fout out that IBM support page, which said to go to CSIv2 inbound and outbound settings (by me, Admin Console->Security->GlobalSecurity->RMI/IIOP security) and set the transport to SSL-Supported.
However, it didn't change anything. I've tried to change the 'Cleint certificate authentication' to Never, and Transport to TCP/IP for both CSIv2 inbound and outbound, but still without success. The error persisted until I've turned off 'Enable administrative security', which is not an option, because I need to enable 'Application Security' (the application logic depends of that).
How can I make my code working again? Everything was OK on WebSphere 7.

My research on this issue may prove useful to others;
WebSphere 8 changed the default setting of RMI/IIOP SSL security from
'supported' to 'required'. If you want a secure connection you'll need
to get the certs from the server and set Java system properties to files that specify the location of the certs;
com.ibm.CORBA.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/sas.client.props
com.ibm.SSL.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/ssl.client.props
If this doesn't work, you'll need to start debugging by setting the following System properties;
com.ibm.CORBA.Debug=true
com.ibm.CORBA.CommTrace=true
com.ibm.CORBA.Debug.Output=/tmp/corba.log
By studying this log and orb trace logs in the working directory, I found that the client failed to establish an ephemeral TCP connection to the server at "port=0". No mention of SSL in the logs! I wrote a small app to test my code running as a java console app and found that the SSL connection was successful and it worked fine. By diff'ing the logs, I found that only in the good case, the JVM was finding a local file 'orb.properties'. I then found that in my problem case, my test app was using a different JVM and my real app was using a JVM that had no 'orb.properties'. I could resolve the problem in a number of ways .. e.g. by including an orb.properties in my application and injecting the contents as System properties.

In my case switching CSIV inbound to SSL-Supported from SSL-required and restarting the server helped.

The error description
org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07
is very vague and happens under many, not directly connected circumstances.
In my case it had nothing to do with RMI/IIOP security settings, but it was a classpath problem. I was still using old version of com.ibm.ws.webservices.thinclient.
Switching to thinclient 8.5.0, as well as setting the launch JRE to standard (Oracle) JVM has fixed the problem.