UDDI registry common errors
This page describes some common causes of errors that might occur when you use the UDDI registry, and their suggested solutions.
- The first start of the UDDI application might take 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 predefined data and entities, and can take time to complete. This is expected behavior, and only affects the first start of the UDDI application.
- If we use the wsadmin utility to issue a command to start the UDDI application, depending on the TCP timeout settings, this request might timeout while waiting for UDDI to complete initialization. UDDI initialization and starting the UDDI application continue complete normally; they are not affected by this timeout.
- On UNIX and Linux platforms, if we use DB2, before you issue the startServer.sh server1 command, run the db2profile script. This script is in the DB2 instance home directory under the sqllib directory. To invoke the db2profile script, type:
. /home/db2inst1/sqllib/db2profileIn the previous example, notice that the period (.) is followed by a single space character.
On UNIX and Linux platforms, the DB2 user must have a db2profile at $HOME/sqllib/db2profile
- A limitation exists about URL rewriting causing Java Scriptsyntax errors on several Web pages in the UDDI user console. Therefore, cookies must be enabled in client browsers, the appserver must have cookies enabled as the session tracking mechanism, and URL rewriting must be disabled.
- If we attempt to use a remote DB2 database and experience problems attaching to the remote system, one possible cause might be IP addressing. This problem does not occur if the remote system uses a static IP address. However, if the remote system uses Dynamic Host Configuration Protocol (DHCP), each system must be aware of the subnet mask of the other system.
(Windows) To find the subnet mask, start a command prompt and enter the following command on the remote system:
ipconfigOn the host system, we might need to edit the WINS addresses to add the remote subnet mask. To do this, use the following steps:
- Click START > Network and Dial-up Connections > Local Area Network Connection 2 > Internet Protocol (TCP/IP) , and click Properties.
- Click Advanced.
- Click the WINS tab and add the new subnet mask.
- Move the new subnet mask to the top of the list by highlighting it and pressing the up arrow until the new subnet mask is at the top of the list of WINS addresses.
(UNIX) [Linux] Use the ifconfig command to determine the subnet mask.
- If we cannot see the UDDI node in the admin console list of available nodes, check that the UDDI application is started on the relevant node and server.
- If we cannot issue UDDI requests; for example, you start the UDDI user console but errors occur when you try to publish or inquire, consider the following reasons:
- The database is not currently loaded or configured. Check the output from creating the database.
- The database is not correctly configured. Check that the JDBC provider and data source definitions are correct by clicking the Test Connection button on the admin console.
- The UDDI node is not initialized. Check the UDDI node page on the admin console. If the status of the node is not activated or deactivated, set any policies or properties, then try to initialize the node.
- The UDDI node is currently deactivated while UDDI runtime settings are updated. Check the UDDI node page on the admin console.
If the status of the node is deactivated, wait for the status to become activated, then try the request again.
- When you try to save a business entity in a UDDI registry that is running on WAS V7.0, but the registry is using a Cloudscape or Apache Derby database created using an earlier of WAS, the following error might occur:
Serious technical error has occurred while processing the request.This error occurs if a UDDI database currently uses Apache Derby V 10.2 or later and we have upgraded the servers to WAS V7.0. You must migrate the UDDI database. See Migrate a UDDI database that uses Apache Derby.
Related tasks
Use the DB2 Universal JDBC Driver to access DB2 for z/OS
Migrate a UDDI database that uses Apache Derby
UDDI registry troubleshooting