Common causes of errors in the UDDI Registry

Below are a few of the common causes of errors that might be found and their suggested solutions.

• The first start of the UDDI application may take some time to complete:

  • When you start the UDDI Registry application for the first time with a new UDDI Registry database, it must perform UDDI initialization, which occurs automatically for a default UDDI node, or when requested for a customized UDDI node. UDDI initialization populates the UDDI Registry with pre-defined data and entities, and can therefore take some time to complete. This is expected behavior. Note that this only occurs on the first start, not subsequent starts, of the UDDI application.

  • If you use WSADMIN to issue a command to start the UDDI application, then depending on your TCP timeout settings, this request might time out while waiting for UDDI to complete initialization. The UDDI initialization and the starting of the UDDI application will continue unaffected by this timeout, and will complete normally.

• On Unix and Linux platforms, if using DB2, run the db2profile script before issuing the startServer.sh server1 command. This script is located within the DB2 instance home directory under sqllib and is invoked by typing:

  . /home/db2inst1/sqllib/db2profile

  Note: In the above example, notice that the '.' is followed by a single space character.

  Note: On Unix and Linux platforms the DB2 user must have a db2profile at $HOME/sqllib/db2profile

• There is a limitation concerning URL rewriting causing JavaScript syntax errors on several Web pages in the UDDI User Console. Because of this, cookies must be enabled in client browsers, the application server must have cookies enabled as the session tracking mechanism, and URL rewriting must be disabled.

• If you run the uddiDeploy.jacl with the default option, and you have not first deleted the UDDI Cloudscape database (from the databases subdirectory of your server profile) the UDDI database will not be recreated, and you will get an error message. This error can be ignored if you did not intend to replace the Cloudscape database.

• If attempting to use a remote DB2 database and you are experiencing problems attaching to the remote system, one of the possible causes might be IP addressing. You should not have this problem if the remote system is using a static IP address. If, however, the remote system is using DHCP, the two systems must be aware of each others subnet mask.For Windows, the subnet mask can be found by starting a Command Prompt and entering "ipconfig" on the remote system. On the host system, the WINS might need to be edited to add the remote subnet mask. To do this on Windows go to the following commands:

  1. START => Network and Dial-up Connections => Local Area Network Connection 2 => Internet Protocol (TCP/IP) and click on Properties

  2. Click on "Advanced".

  3. Click on the WINS tab and add the new subnet mask

  4. Move the new subnet mask to the top of the list by highlighting it and pressing the "Up" arrow until it is the top of the list of WINS addresses

  On Unix platforms, you can use ifconfig to determine the subnet mask.

• If you cannot see your UDDI node in the administrative console list of available nodes, check that the UDDI application is started on the relevant WebSphere node/server.

• If you are unable to issue UDDI requests; for example, you start the UDDI user console and get errors when trying to publish or inquire, it is possible that:

  1. the database is not currently loaded or configured. Check the output from creating the database.

  2. the database is not correctly configured. Check the JDBC provider and datasource definitions are correct. This can be validated by using the Test Connection button on the administrative console.

  3. the UDDI node is not initialized. Check the UDDI node page on the administrative console. If the entry for the node in question does not show as activated, or deactivated, try to initialize the node having set any policies or properties first.

  4. the UDDI node is currently deactivated, while UDDI runtime settings are being updated. Check the UDDI node page on the administrative console. If the entry for the node in question shows as deactivated, then wait for it to change to activated, and then retry the request.