WebSphere AdminClient connects to local managed process instead of HOST:PORT specified in properties

Question

I've experienced strange behavior of WebSphere AdminClient using RMI connector.

Having a testing web application (one servlet) deployed on WAS 7 standalone server (server name: server1), port range 20000-20050. The servlet should open an AdminClient to the WAS 6.1 standalone server (server name: server1), port range 20200-20250 using RMI connector:

Properties props = new Properties();
props.setProperty(AdminClient.CONNECTOR_HOST, "localhost");
props.setProperty(AdminClient.CONNECTOR_PORT, "20209"); // ORB, BOOTSTRAP is 20204, both behave the same
props.setProperty(AdminClient.CONNECTOR_TYPE,     AdminClient.CONNECTOR_TYPE_RMI);
props.setProperty(AdminClient.CONNECTOR_SECURITY_ENABLED, "true");
props.setProperty(AdminClient.CONNECTOR_AUTO_ACCEPT_SIGNER, "true");
props.setProperty(AdminClient.USERNAME, "someuser");
props.setProperty(AdminClient.PASSWORD, "somepassword");

AdminClient ac = AdminClientFactory.createAdminClient(props);

// locate and stop server1 
Set servers = ac.queryNames(new ObjectName("WebSphere:type=Server,name=server1,*"), null);
if(!servers.isEmpty()) {
    ObjectName server = (ObjectName) servers.iterator().next();
    if(server != null) {
        ac.invoke( server, "stop", null, null );
    }
} 

Now the problem is that such an AdminClient connects to the local (WAS 7, port range 20000-20050) process and stops it (since it has the same server name: server1).

HOST and PORT properties seem to be ignored, however SECURITY_ENABLED, USERNAME and PASSWORD are used (tested with wrong username / password). Any idea why it does not connect to the other server? I blame some local properties file that take precedence over the properties specified, but haven't found any yey (sas.client.props does not contain any host/port info). With SOAP connector it works perfectly fine.

UPDATE When the two servers are on different machines, so HOST property is different, it really connects there. The user still must exist on both machines within the same REALM. So the problem is when the two completely independent processes (one hosting the client application and the one to connect to) reside on the same host, then it connects to the local process - PORT property pointing to the other process is ignored.

Answer 1

I suspect you need the com.ibm.websphere.orb.uniqueServerName property described in the "Two servers with the same name running on the same host are being used to interoperate" section of the Application access problems topic in the knowledge center.