UDDI registry troubleshooting
Common errors that can occur when using the UDDI registry include database and data source errors, JavaScript syntax errors on pages in the UDDI user console, a UDDI node not appearing in the administrative console list of available nodes, and not being able to issue UDDI requests.
During UDDI registry use, messages to report events or errors might be issued. Use these messages first to resolve any problems. For further assistance, review the following list of troubleshooting tips.
For more details about a problem, enable trace for UDDI. We can enable or disable trace using the administrative console. The component for the UDDI registry is com.ibm.uddi. We can enable trace for the UDDI registry at several levels of granularity. For example, to enable all UDDI registry tracing, specify the following:
com.ibm.uddi.*=allThe following list contains some problems that might occur when we set up or use the UDDI registry, and suggested solutions.
Tasks
- The first startup of the UDDI application might take time to complete.
- When we start the UDDI registry application for the first time with a new UDDI registry database, it must complete 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 affects only the first startup of the UDDI application.
- If we use the wsadmin utility to issue a command to start the UDDI application, depending on your TCP timeout settings, this request might time out while it waits for UDDI to complete initialization. UDDI initialization and starting the UDDI application continue to complete normally; they are not affected by this timeout.
- (UNIX) On UNIX and Linux platforms, if we use DB2, before we 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 the following. Notice that a single space character follows the period (.).
. /home/db2inst1/sqllib/db2profileOn UNIX and Linux platforms, the DB2 user must have a db2profile at $HOME/sqllib/db2profile
- JavaScript syntax errors might occur on several web pages in the UDDI user console. This problem is caused by a limitation about URL rewriting. To avoid this limitation, 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.
- For a remote DB2 database, if attaching to the remote system causes problems, one possible cause might be IP addressing. This situation does not occur when 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 on the remote system:
ipconfigOn the host system, we might need to edit the WINS addresses to add the remote subnet mask. 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 beginning of the list by highlighting it and pressing the up arrow until the new subnet mask is at the beginning of the list of WINS addresses.
(UNIX) (Linux) Use the ifconfig command to determine the subnet mask.
- The UDDI node is not in the list of available nodes on the administrative console. Check that the UDDI application is started on the relevant node and server.
- We cannot issue UDDI requests, for example, we start the UDDI user console but errors occur when we 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 Test Connection on the administrative console.
- The UDDI node is not initialized. Check the UDDI node page on the administrative 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 administrative console. If the status of the node is deactivated, wait for the status to become activated, then try the request again.
- There are problems with your DB2 setup. In particular, check that the DB2 bind utility has run and that a TEMP database is defined in the DB2 location. See the topic about using the DB2 Universal JDBC Driver to access DB2 for z/OS .
- Ensure that when defining the data source, we specify the location name for the database name, rather than the database name that you supplied to the createddl.sh script (see the topic about creating a DB2 for z/OS database for the UDDI registry). For example, specify LOC1, not UDDI30.
- When we try to save a business entity in a UDDI registry that runs on WebSphere Application Server v7.0 or later, but the registry uses an Apache Derby database that was created using an earlier version of the product, 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 Version 10.2 or later and we have upgraded the servers to WAS v7.0 or later. We must migrate the UDDI database. See the topic about migrating a UDDI database that uses Apache Derby.
What to do next
If we have not resolved our problem, see the problem determination information on the WAS support web page.
Work with trace Use the DB2 Universal JDBC Driver to access DB2 for z/OS (ZOS) Create a DB2 for z/OS database for the UDDI registry Migrate a UDDI database that uses Apache Derby UDDI Utility Tools limitations and resolutions WAS Support