Technology and Community

Jim O'Neil

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


Related Topics: Apache Web Server Journal

Apache Web Server: Article

EAServer Problem Analysis & Troubleshooting

Part art, part science Part 2

Designing and implementing an n-tier or Internet application is a complex task, and issues resulting from errors in the runtime configuration or in the application code are practically inevitable. Problem analysis and troubleshooting are part art and part science. Therefore, although the techniques we'll discuss are often helpful, the sheer diversity of client and server environments precludes a single recipe for resolving all issues.

Part 1 (PBDJ, Vol. 12, issue 2) focused on problems that involve PowerBuilder and that occur from the point of connectivity all the way through an EAServer component's life cycle. Part 2 closes with a troubleshooting checklist offering potential resolutions to some of the more common error situations.

Tracing Component Execution
Now that we've gotten to the point where the actual component instance has been created, let's look at ways of troubleshooting a component instance as its various business methods execute.

Remote Debugging
PowerBuilder provides a remote debugging facility that lets you step line-by-line through a component executing on an EAServer instance anywhere on your network using PowerBuilder's familiar debugging environment on your own workstation. Remote debugging can be of aid when analyzing the execution of a single client through the application. The complexities of the n-tier environment, however, make it less useful when trying to troubleshoot an issue that occurs only when multiple clients are accessing the EAServer application.

To support remote debugging, the component must be deployed from PowerBuilder with the Supports Remote Debugging checkbox checked on the Components tab of the Properties for EAServer Component Generator dialog box in the EAServer component project painter (shown in Figure 1). Checking this property in the dialog box corresponds to setting the com.sybase.jaguar.component.pb.debug property of the component to true.

To run the remote debugger, open the PowerBuilder workspace containing the PBLs that implement the current versions of the components you want to debug. Next select the Debug option from the toolbar and the Start Remote Debugging icon on the Debug toolbar. When you press this toolbar button, PowerBuilder prompts you for the EAServer profile you want to connect to so you can debug the component remotely. After you pick the desired EAServer from the profiles list, you are prompted for the component(s) you want to debug (as shown in Figure 2). Components that aren't eligible for remote debugging are listed but aren't selectable in this dialog box.

After you pick the component(s), you can set breakpoints in your PowerScript code and use the same debugging features that you're familiar with from regular client/server apps. The major difference is that you don't run the component from the PowerBuilder debugger; you must execute an external client that accesses the component. That client application could be a PowerBuilder program running in a second instance of the PowerBuilder development environment, a Java applet that makes component calls to EAServer or even a Netscape Navigator browser session accessing Microsoft Active Server Pages (ASP) pages that invoke EAServer components via the Jaguar ActiveX proxy interface.

The internal implementation of remote debugging relies on components present in EAServer as part of the product installation. A distinct PBDebugBroker component is located in the EAServer PBDebugger package for each version of PowerBuilder components that may be deployed. These components interact with PowerBuilder's remote debugging features by opening a socket back to the machine hosting the PowerBuilder development environment. This communication channel from EAServer back to the client (namely, the PowerBuilder development environment) has connectivity implications if you try to use remote debugging through a firewall.

Tracing Method Execution
As mentioned, remote debugging is a great tool for analyzing and verifying the execution path for a single component instance, but it can be a difficult technique to use if failure is only seen when multiple component instances are active. Using tracing properties available for any component type hosted by EAServer as well as PowerBuilder's interface to the EAServer logging service, you can add information to the EAServer log to analyze application behavior further.

Tracing Flags
The following two properties are available for any type of component hosted in EAServer. Because these properties aren't exposed on the PowerBuilder EAServer component project object, you must use the All Properties tab of the Component Properties dialog box in Jaguar Manager to make modifications.

  • com.sybase.jaguar.component.debug, when set to true, records the lifecycle events of the component.
  • com.sybase.jaguar.component.trace, when set to true, shows method-invocation statistics, including the user ID of the invoker, the IP address of the client and the amount of data returned from the invocation.
PowerBuilder components also have a property called com.sybase. jaguar.component.pb.trace, but it has no impact in the currently released versions of PowerBuilder and EAServer.

A server-level property, com.sybase.jaguar.server.logspid, can also be set to true to include the Open Server process ID that's the source of each line of trace output. This is useful for identifying the output that corresponds to a specific user request because, in a multiuser scenario, output lines from the clients quickly become intermingled in the log file.

Listing 1 is an excerpt of the information recorded in the EAServer log when setting these tracing flags. From this brief example, you can quickly ascertain a number of details:

  • This is the first time this component instance was used as evidenced by the constructor event in the second line of the trace output.
  • The trace information belongs to a single request associated with process ID 15, which corresponds to the client jsmith at the IP address 65.123.23.2.
  • The getlist method of the SurfsideVideoPB/n_store component completed execution in about a second.
  • The getlist method is not overloaded in this component. You can conclude that because the function name isn't mangled (or decorated) with a suffix.
When overloaded methods are encountered, the deployment process to EAServer adds a suffix to the method name - based on the return value and argument types - to circumvent CORBA's lack of explicit support for method overloading.
  • The getlist method accepts no arguments. You can determine this by the fact that 104 bytes is the minimum number of input bytes for any PowerBuilder method call. The precise value here is subject to change because it depends on the PowerBuilder and EAServer versions used.
  • The component is stateful because there's no deactivate before the TRACE statement at the end of the method call.
You may have noticed the term container in many of the DEBUG lines. In EAServer a container is an intermediary construct that binds a specific component instance to a specific client. A component method call simply can't occur without a container. As long as a container exists, you can be sure the client is bound to the component for which the container was created. In Listing 17.7 you can see that container 361 was created for jsmith to invoke the component surfsidevideopb/n_store. Until that container is deleted (by a setComplete or setAbort issued in a subsequent method call to that component), references to this container in the trace refer to the same instance of n_store used by jsmith. So the association between the container and the client can aid in deciphering the log, especially when log entries get interspersed when multiple clients and component instances come into play.

ErrorLogging Object
Via the built-in ErrorLogging object, your PowerBuilder components can access the same EAServer logging facility that provides the tracing and debugging output just discussed. The ErrorLogging object provides a single function called Log that wraps the core EAServer API method JagLog and accepts a string of up to 1,024 characters meant be written to the EAServer log. While the JagLog method offers the option of not including the timestamp in log entries, the ErrorLogging Log function always includes it.

To access the ErrorLogging object, you use the GetContextService function in PowerBuilder. GetContextService is a function defined on the base PowerObject so it can be called from any PowerBuilder object. Generally, you initialize this object reference as a protected or private instance variable in a component's constructor event so it's available throughout your component's implementation.

By using the GetContextService function with the ContextKeyword object, you can also have a component instance access its own properties. This capability lets you include a custom property on your component, for instance, to declaratively control additional custom tracing or debug output in your component. By the way, this is the technique that the Sybase-provided implementation of Web DataWindow component (DataWindow/HTMLGenerator) uses for additional tracing capability, which you can activate by setting the custom component property com.sybase.datawindow.trace to true.

As an example, Listing 2 shows the PowerScript code necessary to instantiate the ErrorLogging object, but it does this only if the com.sybase. jaguar.component.pb.log property is set to true. (You add this property to your components via the All Properties tab of Jaguar Manager.)


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.