CODEWITHSUNDEEP
exceptionwebspherecorba
Nathaniel Mills
Nathaniel Mills

Reputation: 321

What to consider with CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 error

BLUF: An exception I received attempting to connect a stand alone client to the Extreme Scale cache housed in WebSphere was somewhat misleading, so I've provided the solution here.

I successfully installed WebSphere Extreme Scale (WXS) v8.5 in WebSphere Application Server (WAS) v8.5 (note: do not attempt to do so simultaneously in the Installation Manager or files will be missing -- install them separately). I also was successful installing both a client and server EAR so I could use REST services to the client that in turn would connect to the server to access the cache. However, when I tried to run a stand alone client from the java command line (or from within Eclipse), I was getting exceptions like:

java.lang.Throwable: 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:1272)
...
Caused by: java.lang.Throwable: connect: Address is invalid on local machine, or port is not valid on remote machine
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:381)

when calling connect on the ObjectGridManager:

_client = _ogManager.connect(hostport, null, clientObjectGridURL);

The first thing to check is that the host and port numbers are correct in the objectGridClient.properties file (e.g., the port number would match the BOOTSTRAP port in the application server's ports list). In my case, this was correct. Using netstat -an |grep to see if there is someone listening to the port, or telnet to the host port.

The next thing to check is that firewalls are not getting in the way of the connection to the port. There is a callback to the client from the server as well so you'd want to check that this isn't creating a problem. In my case, this was not an issue.

Upvotes: 1

Views: 8478

Answers (2)

Peter Wippermann
Peter Wippermann

Reputation: 4579

Always double check that your stub classes are really in place and available in the deployment. Sounds easy, but that was the problem I had...

So the reasons for this error may be diverse.

Upvotes: 0

Nathaniel Mills
Nathaniel Mills

Reputation: 321

What did turn out to be the problem was I had configured WAS with general security turned on so the admin console required a user id and password. However, when I made the call for the ObjectGridManager to connect, I was passing a null as the second parameter instead of passing the proper ClientSecurityConfiguration object. Evidently, if you have secured WAS then external clients attempting to connect to the cache housed in WAS need to provide security information to validate they are allowed to connect.

I chose to turn off WAS security using the admin console / Security / Global Security and unchecking the Enable Administrative security. This allowed me to continue testing by passing null, and to defer turning on security and adding the appropriate security configuration settings and providing the proper object in the connect call until we were ready to test in a shared environment (my development environment was self contained on my laptop that was not connected to a public network).

I have included this explanation with hopes others searching for a solution to this problem can find it here as I was unsuccessful finding this alternative explained.

Upvotes: 7

Related Questions