Supporting PAS for OpenEdge: Sitting Down with Progress Experts

The Progress OpenEdge team recently hosted a webinar on Supporting PAS for OpenEdge with Progress experts Roy Ellis and Dan Mitchell. The webinar will provide basic knowledge of PAS for OpenEdge and some tools to help you support and debug issues. Here is a recap of some of the key topics that were covered.

Understand the Architecture

Before you start debugging the Progress Application Server for OpenEdge (PAS for OpenEdge), it's essential to grasp its architecture. This understanding is not just a technical formality; it’s a critical step that enhances the effectiveness and efficiency of your debugging efforts. Knowing how PAS for OpenEdge is structured helps you pinpoint issues more accurately and resolve them faster, minimizing downtime and supporting smoother operations.

The Classic AppServer requires multiple processes and an adapter to serve web pages. In contrast, PAS for OpenEdge functions as a web server, reducing the number of processes and simplifying operations. It runs as a web application in Tomcat and uses a new multi-session agent supporting multiple ABL applications.

Next, you will need to understand the roundtrip of a request through PAS for OpenEdge. This begins with the client connection, where clients connect via HTTP or HTTPS. The Tomcat web server manages all incoming requests, and Spring Authentication handles user authentication, defaulting to anonymous if not specified. The session manager then processes these requests and sends them to the agent, which uses worker threads to find an available ABL session and execute the requests. Finally, the response is sent back through the session manager to Tomcat and then to the client.

Debugging and Fixing Issues

Debugging Problems

Always start debugging problems by reviewing the log files. Knowing which log file relates to each part of the roundtrip process is essential and is demonstrated in the graphic below. You can find detailed log file information further down.

Fix Common Problems

The most common problem when applications are migrated from Classic to PAS for OpenEdge is application memory leaks. The ABLObjects tracking feature finds memory leaks for you, but making application code changes can take a long time, so you need a way to reclaim system memory while you fix memory leaks.

To keep your application running, or to fix any misbehaving multi-session agent, stopping the agent is your best course of action. Always start a new agent first using the OEMANAGER APIs and send a “stop” command to the misbehaving agent. New requests will be sent to the new agent while the misbehaving agent will continue to process current requests. When requests are completed, the misbehaving agent will terminate, and system resources will be returned.

NOTE: DO NOT KILL the multi-session agent, always STOP it using the OEMANAGER APIs.

Tips and Tricks

For effective debugging, always collect comprehensive logs from the logs directory and database. Check the openedge.properties file for important configuration details. Look for protrace or core files in the work or logs directory for additional debugging information. Inquire about recent changes, as even minor updates can cause significant issues. Finally, understand whether the system setup is on one box or multiple, and if load balancing is used, to better diagnose and resolve issues.

Diagnostic Tools for PAS for OpenEdge

There are many diagnostic tools for PAS for OpenEdge. We will cover oemanager REST APIs, oejmx command line calls, oemanager scripting and the HealthScanner in a future webinar and blog.

Log files are the cornerstone of debugging, and since PAS for OpenEdge differs from the classic AppServer, it has its own set of log files. Log files are your first line of defense when diagnosing issues in PAS for OpenEdge. Here are the key log files you should be familiar with:

• Tomcat Logs:
• catalina.out or catalina.date.log: These logs provide information on Tomcat startup issues, Java errors and other critical events. Look here for out-of-memory errors, stuck valves (long-running processes) and startup/shutdown statuses.
• Local Host Access File: This log records all requests to Tomcat or PAS for OpenEdge, including the request source, request type and response time. It’s crucial for tracking the flow of requests and identifying performance bottlenecks. Look for return codes (200 for success, 400 for security issues, 500 for application failures) and request IDs to trace requests through the system.
• OpenEdge Specific Logs:
• Session Manager Logs: oepas1.date.log: This log is similar to the old ubroker.log and contains messages from the session manager, such as session availability and state errors. Errors here often indicate issues that originated elsewhere, so use this log to guide further investigation.
• Agent Logs: oepas.agent.date.log: This log provides details on application-level activities, including database connections and other operations previously logged by the classic agent or server logs.

By understanding and effectively utilizing these diagnostic tools, you can troubleshoot and resolve issues in PAS for OpenEdge more efficiently. Remember, thorough log analysis is key to identifying the root cause of problems and maintaining smooth operations.

Essential Steps for Debugging PAS for OpenEdge Issues

A systematic approach is crucial for debugging PAS for OpenEdge. Here’s a concise guide:

• Collect All Log Files: Gather all relevant logs from the logs directory and database logs for comprehensive analysis.
• Check the openedge.properties File: Provides info on agents and log file locations.
• Look for Protrace or Core Files: Found in the work or logs directory, these contain valuable ABL stack information.
• Ask About Recent Changes: Inquire about recent system patches or updates.
• Understand the Configuration: Know if everything is on one box or spread across multiple—and if load balancing is used.
• Identify the Operating Environment: Determine if the setup is on-premises, cloud-based or hybrid.
• Check System Logs: Look for out-of-memory processes if agents disappear without messages.
• Monitor System Resources: Gather data on memory, swap and disk I/O to identify performance issues.
• Stop, Don’t Kill Agents: Properly stop problematic agents to avoid database disruptions.
• Use Client-Server Connections: Prevent database crashes by using client-server connections, even locally.
• Test from the Command Line: Helps determine if issues are with tools or PAS for OpenEdge itself.
• Clean Log Files: Use pasman or tcman clean to manage log files.
• Set Up Monitoring: Implement monitoring with OpenEdge Management, third-party tools or custom scripts.
• Use Load Balancing: Provides additional capabilities and easier failover handling.

Following these steps helps maintain a stable and efficient PAS for OpenEdge environment.

Sound interesting? Watch the webinar recording.