Architecture Planning, PASOE Deployment, Licensing & ProTop Behavior Clarification

[vikash]

Hi Team,


We are currently using a PAS instance to deploy our web application, and the deployment has been successful. As of now, our project is running on a single-tier architecture, but we are planning to move to a three-tier architecture where:

• One server will host the Database
• One server will host the PAS instance (Application Server)
• One server will handle the GUI (frontend layer)

We have a few questions and clarifications regarding this transition:

1. As we know we can deploy Application Layer and Database Layer Independently in PAS right ?​

I would like to understand to deploy the application layer (business logic) and the database layer independently within PASOE. Please help me to explain how this separation is achieved in configuration or deployment.

2. Business Logic in PASOE​

All the business logic will be resides entirely in PAS instance right ?

3. Load Balancing with Multiple PAS Servers​

How do we configure multiple PASOE servers behind a load balancer, all pointing to a single shared database? Is there a recommended approach or architecture to follow?

4. Licensing Requirements for Multiple PAS Instances​

If we plan to deploy multiple PAS instances on separate servers, do we need separate licenses for each instance, or can we use a single license across them?

5. GUI Request Handling with Load Balancer​

We assume that the GUI will send requests to the load balancer, which will then forward the request to one of the available PAS servers, and that PAS server will handle the request. Is this correct?

We referred to the following documentation:
Load Balancing Progress Application Server (PAS) for OpenEdge - Kemp

• What are the prerequisites and licensing requirements to implement this setup?
• Is there any official documentation available that walks through setting up load balancing for PASOE?

Also, we are aiming to implement something similar to the architecture shown in the reference image.

6. ProTop Client Connection Behavior​

We are currently using ProTop monitoring tool, and we have set maxClientConnection=1024 in the properties file. ProTop shows around 900 active client sessions, and once the connection count reaches 1024, both the application and database shut down unexpectedly.
However, when we check from the database side:

• Active connections are only around 100–120
• We have 15 WebSpeed agents and 15 AppServer agents, all in available status, none showing as busy.

Questions:

• Why is ProTop reporting such a high number of active client sessions?
• When we run the trim agent command, the client count drops drastically to 0–20. Why does this happen, and how do we ensure the connection count reflects the actual usage?

Looking forward to your guidance on:

• Proper implementation steps for load-balanced PASOE
• Licensing clarity
• Resolving the ProTop connection reporting issue

Thanks,

 

[TomBascom]

Hi Team,


We are currently using a PAS instance to deploy our web application, and the deployment has been successful. As of now, our project is running on a single-tier architecture, but we are planning to move to a three-tier architecture where:

• One server will host the Database
• One server will host the PAS instance (Application Server)
• One server will handle the GUI (frontend layer)

"Servers" do not typically make GUI requests. That would be something that, presumably, is handled on the client where the (G)UI is running.

We have a few questions and clarifications regarding this transition:

1. As we know we can deploy Application Layer and Database Layer Independently in PAS right ?​

I would like to understand to deploy the application layer (business logic) and the database layer independently within PASOE. Please help me to explain how this separation is achieved in configuration or deployment.

I don't know what you mean by that. "As we know" seems to suggest that you already know. And, yet, you are asking a question about how to do it. So I'm a bit confused.

I suppose that, maybe, what you're getting at is an idea where calls to the "application layer" turns around and makes calls to the "database layer" as needed?

I think that thinking of these as "layers" is probably a mistake. You would be better off thinking of them as groups of "services" that may call, or be called by, other services as needed.

Some services (those handling database queries and updates) require a db connection. Others do not.

The difference is whether or not there is a "-db dbname" in the [AppServer.SessMgr.*] agentStartupParam property.

2. Business Logic in PASOE​

All the business logic will be resides entirely in PAS instance right ?

Maybe.

If you write your "business logic" in such a way that it makes calls to "data access services" then you need to decide how to deploy that code. You _could_ deploy it in many ways, one of which is to package it up and access it via PASOE.

However... that very same code _could_ be run locally without PASOE being involved. It's up to you, unless you do something to lock that code into PASOE or make certain that it doesn't get copied and deployed outside of PASOE; it is not magically going to reside entirely in PASOE just because you drew a nice diagram.

(The same is true of your data access code.)

3. Load Balancing with Multiple PAS Servers​

How do we configure multiple PASOE servers behind a load balancer, all pointing to a single shared database? Is there a recommended approach or architecture to follow?

I have no idea. Someone else will have to comment on that.

I will note that at the top you mentioned a single PAS Server but now you appear to be wanting to "load balance" across multiple servers?

FWIW, you can only have a single updateable database but you _could_ use replication target databases for read-only inquiries. We have several customers who do that quite successfully. You do have a replication target in your diagram so this might be possible for you. You will need the "replication plus" product though.

4. Licensing Requirements for Multiple PAS Instances​

If we plan to deploy multiple PAS instances on separate servers, do we need separate licenses for each instance, or can we use a single license across them?

Licensing questions should be directed to Progress.

5. GUI Request Handling with Load Balancer​

We assume that the GUI will send requests to the load balancer, which will then forward the request to one of the available PAS servers, and that PAS server will handle the request. Is this correct?

We referred to the following documentation:
Load Balancing Progress Application Server (PAS) for OpenEdge - Kemp

• What are the prerequisites and licensing requirements to implement this setup?
• Is there any official documentation available that walks through setting up load balancing for PASOE?

Also, we are aiming to implement something similar to the architecture shown in the reference image.

View attachment 3307

​

Someone else will have to comment on that. But I don't see a GUI making any requests in your diagram so maybe you left something out?

6. ProTop Client Connection Behavior

We are currently using ProTop monitoring tool, and we have set maxClientConnection=1024 in the properties file. ProTop shows around 900 active client sessions, and once the connection count reaches 1024, both the application and database shut down unexpectedly.

Surely there are some log file messages explaining why the db and the application shutdown? Sharing those would go a long ways towards identifying the root cause.

However, when we check from the database side:

What does "from the database side" mean? Are you using some particular tool for that? What are the specific sources of these different numbers?

• Active connections are only around 100–120
• We have 15 WebSpeed agents and 15 AppServer agents, all in available status, none showing as busy.

What is an "active connection"? Where are you sourcing that number from? What tooling is showing you "available status"?

Agents <> client sessions.

The PAS agent is multi-session:

Progress Documentation

docs.progress.com

Questions:

• Why is ProTop reporting such a high number of active client sessions?

Probably because there are a lot of active client sessions.

• When we run the trim agent command, the client count drops drastically to 0–20. Why does this happen,

That is kind of the point of trimming agents. Did you expect something different to happen?

• and how do we ensure the connection count reflects the actual usage?

I'm not seeing why you think that it does not reflect actual usage.

Looking forward to your guidance on:

• Proper implementation steps for load-balanced PASOE
• Licensing clarity
• Resolving the ProTop connection reporting issue

Thanks,

 

[Rob Fitzpatrick]

When requesting guidance about OpenEdge, please specify your platform and OpenEdge release.

 

[peterjudge]

3. Load Balancing with Multiple PAS Servers​

How do we configure multiple PASOE servers behind a load balancer, all pointing to a single shared database? Is there a recommended approach or architecture to follow?

You can take a look at Progress Documentation for some examples.

Your description is a little confusing: you mention GUI clients and a web application. What are the client types involved here? GUI? Web? Both? (there's no wrong answer here but it does influence the PASOE and load balancer configuration).

If you are dealing with GUI (or other APSV) clients you MUST use sticky sessions in the load-balancer or you will be highly unlikely to have any success connecting to a PAS instance.

Typically this is done using the JSESSIONID cookie, although I have also seen the persistence maintained by the client IP (not really recommended IMO). The doc linked above also talks about this.

If you are dealing with WEB clients, then the load balancer set up becomes less complex.

Note that there are load balancers like F5 that are not documented in detail but which are in relatively-common use in front of PASOE instances. As a rule of thumb, other than the APSV clients, it's just a Tomcat instance as far as the load balancers are concerned, and so you casn follow the load balancer's recommendations/best practices.

You are also going to start using networked DB connections. A typical deployment could be a DB server on host01, and (let's say) 3 PASOE instances on host02-04. The PAS instances connect to the DB server on host01 using something like -H host01.example.com -S xxxx connection parameters. The load balancer connects to hosts 02, 03 and 04. The clients connect to the load balancer.

 

[peterjudge]

Can a moderator move this thread into the appropriate forum? I feel like we're beyond Chit Chat ...

 

[vikash]

Hello Team,

I'm very grateful for all of your responses.

When requesting guidance about OpenEdge, please specify your platform and OpenEdge release.

Linux and Release 12.8 we are using

Your description is a little confusing: you mention GUI clients and a web application. What are the client types involved here? GUI? Web? Both? (there's no wrong answer here but it does influence the PASOE and load balancer configuration).

both

Surely there are some log file messages explaining why the db and the application shutdown? Sharing those would go a long ways towards identifying the root cause.

ERROR: connection refused : maximum number of client connections has been reached. (8558) Client disconnected : (8534)

What does "from the database side" mean? Are you using some particular tool for that? What are the specific sources of these different numbers?

No, I'm not using a particular tool. I mean, when we check Promon, we see very few database connections.

What is an "active connection"? Where are you sourcing that number from? What tooling is showing you "available status"?

When checking active database connections via Promon or proshut db_name -C list, we observe only 100-120 users connected to the database.

Probably because there are a lot of active client sessions.

For the past 20 days, we've seen a considerable spike in active client connections in the Protop tool. How can we diagnose and resolve this?

That is kind of the point of trimming agents. Did you expect something different to happen?

I agree with you I'm also expecting the same, but I'm pointing out that even after we run the trim, the number of active client connections quickly rises again. This means we'd have to run the trim every 2,3 or 4 hours.

Thanks

 

[Rob Fitzpatrick]

Error 8558 is not about the database; it is about connections to the App Server. Read here:
https://community.progress.com/s/article/P114311

When discussing client/server, remember that these words don't mean the same thing in all situations. It is important to be specific and to provide context. For example, you might have a simple client/server application that is architected like this:
ABL client ---> OpenEdge RDBMS 4GL server
In this context, it is clear: the ABL client is the "client" in "client/server" and the database 4GL server is the "server" in "client/server".

But what about this application:
ABL client ---> OpenEdge App Server ---> OpenEdge RDBMS 4GL server
What is a client and what is a server?
That is the wrong question. There are two connections here, so there are two relationships:

• the ABL client is a client and its server is the App Server
• the App Server is also a client of the database
• note:
  • the ABL client is not a database client in this case
  • the App Server is both a client and a server, depending on the context (the connection being discussed)
  • the number of ABL client connections may not, and probably doesn't, match the number of App Server connections to the database. That is part of the point of an App Server; they are many-to-one.

There are many other designs out there as well, including designs where an App Server (or WebSpeed, or PASOE) doesn't connect to a database at all, or it is transient (connects occasionally and disconnects), or it connects to multiple databases. It is all a function of how the application is designed and written.

Your post above confuses "active connections" (connections to an App Server) with database connections. You have noted that you are hitting a limit on one while the other shows a relatively small count, which doesn't seem surprising to me. The problem you need to correct is on the App Server side.