Technology and Community

Jim O'Neil

Subscribe to Jim O'Neil: eMailAlertsEmail Alerts
Get Jim O'Neil: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

PowerBuilder: Article

EAServer Problem Analysis & Troubleshooting

Part Art, Part Science Part 1

2.  The HTTPServlet log includes information about servlet and JSP execution. This log proves valuable in determining the cause of HTTP 500 Internal Server Errors because it records Java class loading errors and JSP compilation failures. You can also set the property to true to provide additional information about servlet initialization and execution.

3.  The HTTPError log records HTTP server failures such as socket errors when writing a response to the client's HTTP port.

TDS Requests
Tabular Data Stream (TDS) is Sybase's proprietary protocol for communicating between Open Client and Open Server applications, such as Adaptive Server Enterprise. Although it's rather restrictive in its capabilities when compared to IIOP connectivity options, PowerBuilder's SYC database driver can access components in EAServer via a TDS port and the technique known as Methods as Stored Procedure (MASP).

The Ribo utility shipped with the jConnect for JDBC driver and available by free download from the Sybase web site is a convenient tool for tracing TDS traffic. We will discuss Ribo in more detail in the upcoming section on diagnosing database access issues. It's more likely that you will use the tool to investigate the interaction of EAServer connection caches with Sybase databases and gateways.

Instantiating Components
Most component instantiation failures happen because of coding errors or problems in the server environment. PowerBuilder clients (or other EAServer components making inter-component calls) usually initiate component instantiation via the Lookup or CreateInstance functions. Both methods are available on the Connection object for client access and the TransactionServer object for inter-component calls. The lower-level JaguarORB object can also be used to access EAServer and instantiate components via the base CosNaming techniques.

Establishing Server Connectivity
Error 57 can also occur as a return code from the CreateInstance or Lookup functions on the Connection object and usually indicates a coding error or failure to handle errors returned from the ConnectToServer method. Because error 57 means there's no server connection, the EAServer log file won't contain any information to help diagnose the failure.

When using the JaguarORB object in PowerBuilder to connect to the server, you first create proxies for various EAServer packages such as SessionManager and Factory. As a rule, rather than returning error codes, these methods throw exceptions when there are failures, so they should be issued in the context of TRY-CATCH blocks in your PowerScript client code.

Locating Components
Locating a component on EAServer before instantiating it involves two distinct steps. First, verify that a component with the requested name exists on one or more EAServers cataloged by the targeted naming server. If the component is found, the second step is to confirm that the component instance found does indeed implement the desired interface. The failure of either step results in EAServer reporting one of the following two exceptions:

Now let's look a little closer at the processing involved here to get a better understanding of common points of failure.

The first step toward locating a component is verifying that the named component is accessible to one of the naming server(s) specified in the Connection object's location property or in the ORBNameServiceURL property supplied when initializing the JaguarORB object.

When using COSNaming via the JaguarORB object, the component name is explicitly provided via the NameComponent structure. When using the PowerBuilder Connection object, the component name is taken directly from the Lookup function or from the CreateInstance function, if the optional component name argument is provided.

When you use the one-argument form of the CreateInstance function, PowerBuilder constructs the component name based on the default package name (specified in the application property of the Connection object), followed by a / character and then the variable type of the proxy argument. Although this sounds convenient, we recommend that you always use the two-argument form of CreateInstance for the following reasons:

  • You must always remember to change the application property of the Connection object when calling components in different packages. If the application property of the Connection object isn't specified, the Connection object will report error code 92 as shown in Table 17.3.
  • If you elected to generate proxies that are prefaced by the package name, the instantiation will fail because the variable type seen by PowerBuilder (that is, the proxy name) won't match the actual component's name.
Whatever the source of the component name, the naming server checks its list of bound objects (created at startup or refresh) to see if any of the object names match. Although the standard naming convention is package/component, if the property is explicitly set, its value is the name by which the server recognizes the component. The component's bound name doesn't have to resemble the actual package or component name as installed on the server.

So let's assume at this point that the requested component was located on at least one server and continue on to the next step.

When using the CreateInstance method, the component is narrowed to a SessionManager::Factory interface only. It assumes that the corresponding proxy used in the client application includes valid interface methods implemented by the component. Any impending failures in this regard are not made manifest until a method is invoked on the component.

When using the Lookup method, the interface specified must be the home interface of the requested EJB; otherwise, the actual lookup will succeed, but the attempt to narrow the component to that interface will fail. The client will still show an error 57 code, which may be puzzling because the component name itself could be correct.

When using the JaguarORB and the Narrow function of the PowerBuilder CORBAObj object, the interface must also be specified. A failed Narrow method at runtime may produce no error; however, it will result in aberrant application behavior. A good programming practice is to always verify the implementation of an interface via the is_a function on CORBAObj before attempting to narrow the object reference to that interface.

Common Causes of Lookup Issues
EAServer doesn't consider a lookup failure to be an error, so no information is recorded in the EAServer log for this step. Although you may see errors in the log when using the CreateInstance function, they are actually recorded when an attempt is made to instantiate the component on the target server (which we'll discuss in the next session). Some of the common causes of failure to locate components are:

  • The package containing the desired component isn't installed on the specific EAServer being targeted (or on any of the member servers in the case of a clustered environment). It's not enough for the package to be included in the EAServer repository; it must be installed in each server instance where it may be needed.
  • The package or component name was misspelled as in Figure 17.1. The package and component names aren't case-sensitive in this context.
  • The bound name of the component is something other than the default package/component format, which can be verified by examining the component's bind.naming property. This property isn't case-sensitive either.
  • When using Lookup or CosNaming (via the JaguarORB object) directly, the desired interface name isn't found, perhaps because it's misspelled. In this case, the name of the interface is case-sensitive.
Instantiating Components
A component isn't instantiated when the CreateInstance or Lookup is issued. It happens when the first method call is requested for that instance. The lookup step previously described results in a list of EAServer profiles (a server and port combination) where the requested component can be instantiated. In a clustered environment, this list likely includes multiple EAServers. The client ORB always tries to instantiate a component on the first server in the profile list, assuming that the profile list is already in an order that appropriately reflects the load-balancing technique selected for that cluster. If the instantiation fails because of a communication error (for example, the server has gone down), the request is retried transparently on the next server in the profile list returned by the naming server.

Because the list of profiles is returned to the client from the naming server, there's a change in context in the interpretation of the server locations included in those profiles. This change in context can cause instantiation failures in two common scenarios:

  • When a standalone EAServer or a server in a cluster has an active localhost listener (such as the loopback address of, that listener is returned to the client application that requests a component along with the list of profiles. If the client ORB attempts to use that localhost profile to instantiate the component, the attempt will fail because localhost is now the client machine, not the EAServer machine hosting the component. In a production environment, there's no need for localhost listeners.
  • When accessing EAServer through a firewall, the server addresses in the profile list returned to the client may be unreachable. In an internal network, the private IP addresses (namely 10.x.x.x, 172.16.x.x and 192.180.x.x as designated by the Internet Assigned Numbers Authority) are often used to identify machines running on the corporate intranet. So the EAServer naming servers in that environment use those internal addresses when creating the list of profiles that indicate where a requested component can be instantiated.

More Stories By Jim O'Neil

Jim is a Technology Evangelist for Microsoft who covers the Northeast District, namely, New England and upstate New York. He is focused on engaging with the development community in the area through user groups, code camps, BarCamps, Microsoft-sponsored events, etc., and just in general serve as ambassador for Microsoft. Since 2009, Jim has been focusing on software development scenarios using cloud computing and Windows Azure. You can follow Jim on Twitter at @jimoneil

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.