I'm trying to automate my builds and do multiple builds from one machine. I 'm trying to use the instructions in the red book for command line interface and jacl scripts. When I try to connect to the deployment manager using: wsadmin -conntype SOAP -host <myhost> -port <myport> I'm getting the following error: WASX7023E: Error creating "SOAP" connection to host "myhost"; exception info rmation: com.ibm.websphere.management.exception.ConnectorNotAvailableExcepti on
Im sure the server/port are right Im sure the deployment manager service is running Im sure all the proper ports are open
If all other conditions are true, you likely have not added the WebSphere node on the build machine to the Deployment Manager cell. I hope this is a test environment cell. You do not want build machines in a production cell.
The build box is not connected through a node, this is something I'm planning on doing later. I have been trying to run the wsadmin from one of the app servers just to test if I can do this, and later will add the node to my build box. And yes this is a test environment. Even when I am on the machine with the Deployment manager service, If I try to connect using SOAP it fails to connect, which I find is really odd.
Joined: Jun 10, 2002
The first case is understandable, because you are trying to connect from a node that is not part of the administrative domain. The later case (can't connect from the DM node) is indeed confusing.
First verify that the ports are what you think they are: a. from the admin console (usually http://yourhostname:9060/admin) verify the ports by going to System administration-->Deployment manager->ports. Take note of the BOOTSTRAP_ADDRESS (default is 9809) and SOAP_CONNECTOR_ADDRESS (default is 8879). If the SOAP_CONNECTOR_ADDRESS is not the same number as you thought, our problem is solved! If it is what you thought, perform the following tests: Try the following, on the DM machine. a. cd $WAS_HOME/profiles/Dmgr01/bin (assuming that is your DM's profile name). b. wsadmin with no parameters, if the SOAP port is 8879. If that is not the port, then add -port <your port> c. also try to connect via RMI: wsadmin -conntype RMI -port 9809 (or whatever your BOOTSTRAP_ADDRESS port is).
The only explanation I can conceive for failure to connect from deployment manager is that the port number is wrong. However, If you are trying to connect from an application profile on the same machine as DM, then that node must not have been added to the administrative domain (via addNode.sh). This would be similar to failure to connect from your build machine.
Ok the port I was using for SOAP was correct, but it still isn't working. However, the RMI method was successful. Forgive my ignorance, but what is the difference between the two? Is one better than the other. Could SOAP be disabled on my machine for some reason?
Joined: Jun 10, 2002
Is it possible that the port number specified for SOAP communication is actually being used by some other service on the DM machine? With Deployment Manager stopped, execute the command: netstat -a, then look for your port (e.g. 8879). If DM is on a UNIX system you can pipe the output to grep: netstat -a | grep Your_Port_Number. If you see an entry for the port, some other service is using that number.
If you are specifying the connection type and port number it shouldn't matter, but look in $WAS_HOME/profiles/Your_DM_Profile/properties/wsadmin.properties and make sure com.ibm.ws.scripting.connectionType=SOAP and com.ibm.ws.scripting.port=Your_Port_Number (e.g. 8879). Make sure com.ibm.ws.scripting.host=localhost or it may be OK if it is Your_DM_Host_name. I'm not sure if these values get changed on install if you don't use the default port numbers. Again, I'm not sure if these values are going to matter if you specify -conntype and -port parameters on wsadmin.
Look in $WAS_HOME/profiles/Your_DM_Profile/logs/wsadmin.traceout and see if there is any useful information that can pinpoint the source of the problem.
SOAP is an HTTP request/response protocol. RMI/IIOP is the same protocol used with EJBs. Notifications are faster with RMI because objects are created and connected, whereas SOAP is a connectionless protocol. However, most shops use SOAP (because it is HTTP traffic) so they don't have to deal with firewall issues.
Ok, there is a new issue. When I was able to connect through RMI, I was connecting from the machine that the Deployment manager was on. I'm trying to connect now from my build box to run my ant scripts, and the username and password I supplied from the actual machine aren't working. Is there some network portion of the username I'm missing? Here is the error I got:
[5/24/05 10:39:26:812 EDT] 7d57d989 WsnInitCtxFac W NMSV0602E: Naming Service unavailable. A communications error occurred. [5/24/05 10:39:26:812 EDT] 7d57d989 SecurityServe E SECJ0252E: Error getting remote security server. The exception is javax.naming.CommunicationException: Could not obtain an initial context due to a communication failure. Since no provider URL was specified, the default provider URL of "corbaloc:iiop:email@example.com:2809/NameService" was used. Make sure that any bootstrap address information in the URL is correct and that the target name server is running. Possible causes other than an incorrect bootstrap address or unavailable name server include the network environment and workstation network configuration. Root exception is org.omg.CORBA.COMM_FAILURE: WRITE_ERROR_SEND_1 vmcid: 0x49421000 minor code: 50 completed: No
Joined: Jun 10, 2002
Your latest error has nothing to do with user name and password; the wsadmin program was unable to find the DM naming service because: 1. the DM is not running. 2. the provider used is incorrect (wrong host name or wrong port).
wsadmin could not find the name server so it defaulted to your local application server name server. Is the IP address in the stack trace your build machine IP address? Port 2809 is an application server bootstrap port.
Execute: wsadmin.sh -conntype RMI -host YOURHOSTNAME -port 9809 (or YOUR RMI port number)
If you can not ping YOURHOSTNAME, then substitute the DM machine's IP address.
That global security is enabled is new information. Make sure the user you are using is defined in WebSphere as a console user (System administration-->Console settings-->Console users).
What is going on with the SOAP access? No other service is using the same port number as DM SOAP? Does wsadmin.traceout give you any useful information?
Your latest error has nothing to do with user name and password; the wsadmin program was unable to find the DM naming service because: 1. the DM is not running. The DM is running....not on the build box, but there shouldnt be one running from there.
2. the provider used is incorrect (wrong host name or wrong port). The hostname and port are correct. When I run wsadmin -conntype RMI -host ipaddr -port 9809 on the machine with the deployment manager, it connects using the user/pass
wsadmin could not find the name server so it defaulted to your local application server name server. Is the IP address in the stack trace your build machine IP address? Port 2809 is an application server bootstrap port. Yes, the IP address in the stacktrace is my build box. Is it a problem that my build box and the deployment manager are on different networks? Is that why it can't find the name server?
Execute: wsadmin.sh -conntype RMI -host YOURHOSTNAME -port 9809 (or YOUR RMI port number) When I execute this on the machine with the deployment manager (my appserver), It prompts a login. I enter the user/pass and it lets me into the wsadmin command prompt using the deployment manager. When I run this on my build box, it gets to the login prompt, and here is where it won't accept my user/pass.
If you can not ping YOURHOSTNAME, then substitute the DM machine's IP address. I have been using the ip address. From the build box, I am able to successfully telnet into the 9809 and 8879 ports on the app server containing the dmngr.
That global security is enabled is new information. Make sure the user you are using is defined in WebSphere as a console user (System administration-->Console settings-->Console users). Global security was not enabled, but the user was not present on the Console users...there weren't any. I added the user I was trying to log in as in the console users and restarted the deployment manager. I am still getting the same problem.
What is going on with the SOAP access? No other service is using the same port number as DM SOAP? Does wsadmin.traceout give you any useful information? As for the SOAP connection: I tested to see if anything else is using port 8879, and nothing is using it. I made sure the machine is listening on that port, and it is. Here is the error made in the trace file when I run the command wsadmin -conntype SOAP -host deplyomentIP -port 8879 on the app server with the deployment manager:
7062c228 AbstractShell A WASX7326I: Loaded properties file /D:/WebSphere/DeploymentManager/properties/wsadmin.properties 7062c228 AbstractShell A WASX7093I: Issuing message: WASX7023E: Error creating SOAP connection to host DeploymentManagerIP; exception information: com.ibm.websphere.management.exception.ConnectorNotAvailableException