Progress OpenEdge Replication is commonly used to maintain synchronized data between databases in production environments. When replication is functioning normally, the Replication Server and Replication Agent communicate continuously to transfer and process replication data.

One status that requires attention is:

Connecting to Agent(s)

This status indicates that the Replication Server is running but is attempting to establish communication with one or more Replication Agents.

This article explains how to troubleshoot this condition systematically and how to validate that replication has returned to a healthy state.

Understanding the Replication Components

A basic Progress OpenEdge replication environment consists of several components:

Primary Database  -> Replication Agent

rpagent  -> Replication Server

rpserver -> Target Database

Each component has a different responsibility.

The Replication Agent captures replication information from the database and communicates with the Replication Server.

The Replication Server manages the replication process and communicates with the target environment.

Because these components depend on each other, checking only one process is not sufficient when troubleshooting replication.

Recognizing the Problem

The first indication is usually the Replication Server status.

A healthy server should report:

Server is: In Normal Processing

An unhealthy or incomplete connection may instead show:

Connecting to Agent(s)

The important distinction is that the Replication Server process may still be running even though replication itself is not operating normally.

Therefore, process-level validation and replication-level validation should both be performed.

1. Check the Replication Server Process

Start by checking whether the rpserver process is running:

ps -ef | grep rpserver

If the process is not present, the Replication Server itself may have stopped.

If the process is present, continue with the replication status checks.

A running process does not necessarily mean that replication is healthy.

2. Check the Replication Server Status

Progress provides the dsrutil utility for monitoring replication.

For example:

dsrutil acc -C monitor

For other databases, use the corresponding database name:

dsrutil annex -C monitor

dsrutil gfa -C monitor

Review the server status carefully.

Healthy state

Server is: In Normal Processing

Problematic state

Connecting to Agent(s)

If the server remains in Connecting to Agent(s), the next step is to investigate the Replication Agent.

3. Check the Replication Agent

Verify that the rpagent process is running:

ps -ef | grep rpagent

If the Replication Agent is not running, the Replication Server cannot establish the required communication.

If the Agent is running, its internal state should also be checked rather than assuming that the process is healthy.

4. Monitor the Replication Agent

Use the Progress replication monitor for the relevant database:

dsrutil acc -C monitor

The same check can be performed for:

dsrutil annex -C monitor

and:

dsrutil gfa -C monitor

The Agent should be in its expected normal state.

This distinction is important:

Process exists

      ≠

Replication is healthy

A process can remain active while the replication component is unable to communicate correctly.

5. Check the Database

Replication depends on the underlying database being available.

Before restarting replication components, verify that the associated database is running correctly.

Check the relevant database processes and review the database logs for:

• Startup failures
• Connection errors
• Resource problems
• Unexpected shutdowns
• Database recovery messages
• Replication-related errors

If the database itself is unavailable, restarting the Replication Server will not resolve the underlying problem.

6. Check Replication and Database Logs

Logs are one of the most useful sources of information when replication is unable to connect.

Look for messages related to:

• Agent connection failures
• Server connection failures
• Communication errors
• Authentication or configuration problems
• Database availability
• Unexpected disconnects
• Previous replication failures

The objective is to determine why the Server is waiting for the Agent instead of simply restarting the processes.

7. Check Network Connectivity When Applicable

If the Replication Server and Agent communicate across hosts, network connectivity should also be verified.

Useful checks include:

ping <hostname>

and, where appropriate:

nc -vz <hostname> <port>

A network problem, blocked port, DNS issue, or incorrect hostname can prevent the Server and Agent from communicating.

Network checks are especially important when the replication components are located on different servers.

8. Review Configuration

If both processes are running and network connectivity is available, review the replication configuration.

Check for:

• Incorrect hostnames
• Incorrect ports
• Invalid connection parameters
• Configuration changes
• Environment-variable differences
• Database-specific replication settings

Configuration changes are particularly important to investigate if the problem began immediately after a server, database, network, or application change.

9. Restart the Replication Server When Required

Once the underlying conditions have been checked, a replication restart may be appropriate.

For example:

dsrutil acc -C restart server

For another database:

dsrutil annex -C restart server

Or:

dsrutil gfa -C restart server

The exact restart procedure should follow the environment’s operational and change-management procedures, particularly in Production.

A restart should be treated as a recovery action—not as the first troubleshooting step.

10. Monitor the Server After Restart

After the restart, run the monitor again:

dsrutil acc -C monitor

The status should transition away from:

Connecting to Agent(s)

and eventually report:

Server is: In Normal Processing

This is one of the key indicators that the Replication Server has successfully established communication with its Agent.

11. Validate the Replication Agent

The Agent should also be checked after recovery.

The expected state should indicate that the Agent is operating normally.

Both sides should be validated:

Replication Server

        |

        | Communication

        v

Replication Agent

Server → Normal Processing

Agent  → Normal

Checking only the Server is not enough.

12. Validate All Databases

In an environment containing multiple replicated databases, the validation should be repeated for each database.

For example:

dsrutil acc -C monitor

dsrutil annex -C monitor

dsrutil gfa -C monitor

Each database should be reviewed independently because one database can experience a replication problem while the others continue operating normally.