WebSphere Enterprise Service Bus for z/OS, Version 6.2.0 Operating Systems: z/OS


Troubleshooting the Common Base Event Browser verification

There are a number of reasons why you might see an error when testing the Common Base Event Browser in a network deployment configuration:

CWLCB0020E: Common Event Infrastructure is unavailable with NameNotFoundException

The following is an example of messages that can be displayed when verifying the Common Base Event browser in the network deployment configuration for the first time.

The following is an example of messages that can be displayed in the servant log of the WebSphere® Application Server:

javax.naming.NameNotFoundException: 
Context: mkcell/nodes/mkdmnode/servers/dmgr, 
name: ejb/com/ibm/events/access/EventAccess: 
First component in name com/ibm/events/access/EventAccess not found. 
Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: 
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0

A fully qualified JNDI name is needed in the Event Data Store when CEI is configured in a network deployment configuration. To resolve this problem, specify a fully qualified JNDI name for the EventAccess EJB.

CWLCB0020E: Common Event Infrastructure is unavailable with CEIDS0035E

The following error messages can also be displayed when verifying the Common Base Event browser in the network deployment configuration for the first time:

error message: CEIDS0035E The implementation class that supports the 
configured relational database system cannot be loaded. 
Implementation class name: 
com.ibm.events.datastore.impl.Db2UniveralDriverImpl 
Relational database name: DB2 
Database version: DSN08015 
com.ibm.events.datastore.impl.DatabaseSpecificsFactory 
handleCreateException(String, String, String, Exception)

These error messages indicate a problem loading a class, but the cause is usually a problem accessing the database. Sometimes there are also some error messages with DB2® return codes like -204 that can help you diagnose the problem, but sometimes you only see the CEIDS0035E message.

Solution 1

If you find a -551 error in the FFDC file, correct the authorization failure reported there by issuing appropriate GRANT statements in DB2.

For example, you could issue GRANT ALL ON TABLE MKCELL. TO MKDBU for all of the CEI tables, views, and indexes created in the CEI databases, then restart the WebSphere Application Server. You may still however receive error message CWLCB0020E on the Common Base Event Browser and CEIDCS0035E in the servant log.

The following is an example of a different DB2 error reported in the FFDC log, and the same error reported in the servant message log:

Exception = com.ibm.db2.jcc.t2zos.y 
Source = com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.prepareStatement 
probeid = 1584 
Stack Dump = com.ibm.db2.jcc.t2zos.y: 
[IBM/DB2][T2zos/2.9.32]T2zosPreparedStatement.readPrepareDescribeOutput 
_:nativePrepareInto:1377:DB2 engine SQL error, SQLCODE = -204, SQLSTATE 
= 42704, error tokens = MKDBU.CEI_T_Common Base Event_MAP

A -204 code is resource allocation failure, that is, MKDBU.CEI_T_Common Base Event_MAP not found. We had created all the CEI tables with a schema name of MKCELL, but the failure shows that the Common Base Event Browser is attempting to access MKDBU.CEI_T_Common Base Event_MAP. The user ID MKDBU is the one in the J2C Authentication Alias being used by the event and eventcat datasources.

The problem is that the CEI component interrogates the alias associated with the datasource and uses that to issue fully qualified SQL. This means that any value you set in the currentSchema custom property on the datasources is ignored. Unfortunately, at this time CEI must be configured so that the schema of all CEI objects in DB2 is equal to the user ID in the J2C Authentication Alias used by the event and eventcat datasources.

There are two ways to resolve this problem:

Solution 2a

Drop the CEI databases, then recreate them. Then rerun the CEI DDL (which includes inserting the metadata and seeding the catalog), but specify a schema name equal to the J2C Authentication Alias user ID on all CREATE statements.

Solution 2b

Perform the following steps if you do not want to drop and recreate the CEI tables:

  1. Create a RACF® user ID equal to the schema name you are currently using.
  2. Using the WebSphere administrative console, define a new J2C Authentication Alias and set the RACF user ID with a password in that alias. Set the schema of the CEI user ID and password in the J2C alias that you create.
  3. Navigate to ResourcesJDDC Providers and set the scope depending on whether CEI was deployed in a cluster or a server:
    • If the CEI EventService application is deployed in a cluster, set the scope to the cluster.
    • If the CEI Event Server application is deployed in a server, set the scope to the server.
    Click Event_DB2ZOS_JDBC_Provider.
  4. Click Data sources under Additional properties.
  5. Click Event.
  6. Scroll down and select the new J2C Authentication Alias you created from the drop-down list box in field Component-managed authentication alias.
  7. Click OK.
  8. Navigate to the eventcat datasource and make the same change.
  9. Save your configuration changes then restart the server or cluster.

The advantage of using solution 2b rather than 2a is that the reason you experienced this problem in the first place is that you do not want to have tables in DB2 with a schema that matches the J2C Authentication Alias user ID. The CEI tables already have the schema you want to use, so it does not make sense to change the schema. When a fix is available to CEI that allows you to use the currentSchema property on the datasource, you can easily switch the datasources so that they return to using the original J2C Authentication Alias.

Of course, even with solution 2b you will be temporarily using a J2C Authentication Alias equal to the CEI schema. When there is a fix for CEI and you switch back to the original J2C Authentication Alias (the one that is not the same as the schema), you can delete the alias and the RACF user ID for the J2C Authentication Alias you created to temporarily match the CEI schema.

CWLCB0020E: Common Event Infrastructure is unavailable with CORBA NO MEMORY

In the servant log you may also see the following error:

java.rmi.RemoteException: CORBA NO_MEMORY exception

You are unlikely to experience this problem if you have just installed WebSphere ESB, but it is useful to know that you can experience memory problems if you get events with a high number specified in the Maximum number of events field.

You can resolve this problem in either of two ways:

Note: You might meet an out-of-memory exception if you have a very large CEI event, even though the number of events is not high. To resolve this problem, increase the initial heap and the maximum heap size.

reference Reference topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.zseries.doc/doc/rins_zos_cbe_browser.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).