PASOE: sticky sessions for APSV and failover

My impression is that they need to reconnect, although I didn't put much energy in it yet.

My impression is that they need to reconnect, although I didn't put much energy in it yet.

My guess is also that progress could solve that for us and get rid of the sticky sessions without excessive effort by allowing to share the sessions in a highly available redis cluster (or something similar.)

I'm not totally happy with the behavior of our load-balancing model in PASOE either.  I don't intend to hijack your question but I just want to clarify it so I understand better.

Does "sticky" sessions simply imply that the load-balancer keeps you on the same server instance (using the cookie or the source-ip)?  Or does that imply more "advanced" functionality (... ie. the HTTP session may persisted to shared storage and another independent server instance is able to continue servicing the same HTTP session).

My understanding is that one of the load-balancing models ("tomcat load balancing") is able to provide more "advanced" functionality.

see knowledgebase.progress.com/.../how-to-configure-pasoe-for-load-balancing

I think HTTP sessions based on tomcat-load-balancing are (theoretically) able survive a fail-over to another server instance - because there is some type of shared storage that is used under-the-hood.  I'm not 100% certain about this, but that is what I've gathered.

But the other load-balancing models will certainly not allow sessions to survive a fail-over from one instance to another because the instances are totally independent and have no knowledge of one another.

So in your question, which load-balancing model are you referring to (per that KB)?  The identification of the load-balancer seems relevant, right?

Thanks,

David

PS. (Final question, I'm not familiar with the "highly available redis cluster"... is that another way of allowing server instances to provide "advanced" functionality whereby sessions can survive a fail-over from one server to another?   Is it some type of shared storage?  )

I will try to answer the original question in this thread and that may help with "hijacked" question.

1) You only need to use "sticky sessions" in load balancing if you are using 4GL or Open clients through a load balancer to PASOE. If you are using, WEB, REST, or SOAP transports you don't need "sticky sessions"

2) Our "classic" client to AppServer communication makes a request that creates a session (and therefore a cookie for sticky sessions). The next request to do the actual work must return back to same AppServer/PASOE or the client will get an error that the session cannot be found.

3) For load balancers, if sticky sessions are set and the PASOE that it was bound to goes away, the load balancer will probably send an error and the client will have to reconnect, this is outside of PASOE, and may differ between load balancers, so I can't tell you exact error.

4) As Dave has said, there is a feature in our backlog to fix this for StateFree operating modes of 4GL and Open clients, but you will have to be make it known how much you need this feature. BTW: StateAware, StateReset, and StateLess will still need sticky sessions in load balancing architectures.

David,

Above I answered how sticky sessions work, we set a cookie to be used by the load balancer (except for AWS ELB where we have to use their cookie). Tomcat load balancing will still need for sticky sessions for 4GL or Open Client to PASOE.

I have no experience with "highly available redis cluster".

Please let me know if you have further questions, Roy

Redis is something like memcached which you might know, but slightly more powerfull. It is ideal for sharing sessions, I guess you would need sharing sessions for supporting the apsv protocol (otherwise the sticky sessions wouldn't be needed). If support for it were added it would indeed allow failover to other servers, it's basically an in-memory database (with the option to persist to disk but we don't need that) that allows to share relatively small amounts of data (like session info) across processes/hosts with a very low performance penalty (compared to traditional databases that are a lot slower, in exchange for much more features that are not needed for the session info.)

For clarity: as far as I know redis is not currently supported by progress. It is also one of a number of similar solutions (but certainly a safe choice.) 

[mention:30c5058a319047d288fe606ee12c9bbe:e9ed411860ed4f2ba0265705b8793d05]  would this remove the need for sticky sessions in combination with state-free? tomcat.apache.org/.../cluster-howto.html

Or does the session actually stick to mproapsv, not just to the tomcat session?

[mention:30c5058a319047d288fe606ee12c9bbe:e9ed411860ed4f2ba0265705b8793d05]  would this remove the need for sticky sessions in combination with state-free? tomcat.apache.org/.../cluster-howto.html

Or does the session actually stick to mproapsv, not just to the tomcat session?

I'm currently busy setting up nginx as load balancer for WEB sessions, but was wondering how much APSV could benefit from this setup. When I'm done with WEBm I'll see if I can test the APSV side as well.

Just as a side step, I was surprised how easy it was to setup nginx on Docker w/ Let's Encrypt certificates. I think it took me about 20 minutes (which included finding a good site with information).

Roy, I can confirm that it is the StateFree/SessionFree connections from the .Net openclient that are the most negatively affected when an HTTP session is lost.  The sessions are easily lost when a PASOE instance behind the load-balancer is removed from service.

Our openclients that use "SessionFree" connections will all start throwing exceptions, and many will crash, depending on the error-handling in that part of the app.  The exception is often a very generic communication error and is not easily identified in code (ie its not a "SessionLostPleaseTryReconnectingException").  Interestingly, if the exception can be caught *without* crashing the app, the next attempt to use the same "SessionFree" connection will re-initialize properly and add a fresh HTTP session to the pool (which is now connected to a different PASOE instance behind the load-balancer)

As a side note, It is somewhat counter-intuitive that an operating mode called "SessionFree" is the one that has the most problems when the underlying sessions are lost. ;)

Using cluster will not fix the need for sticky sessions. They are needed at the PASOE level. The session manager at the PASOE level to be precise. We create a session at the PASOE session manager level with the first request and if the next request goes to another PASOE the session will not exist there and will be refused. Again this is for the APSV transport only.

Hi David,

thank you for confirming the load balancer works as expected!

Yes, I am a little disappointed that we did not foresee the radical changes in industry when we wrote the APSV protocol almost 20 years ago!  ;)

But in all seriousness, when we wrote the APSV protocol it was for our proprietary NameServer load balancer and the internet was still curiosity.

Again, if this is a feature you need, please get your friends together and raise the priority so we can get it done. It is out of the hands of your friendly neighborhood code-slingers in the PASOE team.

Regards, Roy

>>  please get your friends together and raise the priority

My impression is that there aren't a ton of OE friends on the ".Net openclient" side of things.  The Java openclient gets all the cool new improvements and fixes.

For now we just avoid taking PASOE instances offline during business hours since that causes problems, and gives users the impression that we don't support high availability in our load-balancer.  In reality, the problems are momentary ... but users still don't appreciate it when their apps crash or return an unintelligible communication errors.   Thanks for the tips.

I fully understand where the APSV comes from (using it since 1998). In a changing world  little revamping this transport would hurt (tip: use the http header Accept header to differrentiate between old and new:-) ). What would be a plus for the current ABL client model (including OpenClient) is a convergence of capabilities between ABL and true HTTP clients. Apart from load-balancing, OAuth2 is another example. You can't set a bearer token to the ABL call (which are http based nowaday as well) thus whatever OAuth2 solution you come up with for the WEB protocol won't work with the ABL client.

Just for the record (to avoid the idea that I'm being negative), I love where it's going with PASOE. What is offered with WEB transport w/ spring security is giving us a good story to our customers (and they like it).

btw, I meant "wouldn't hurt"...

Bronco,

We convert the OAuth2 token to Client-Principal right and it has all the claims that are part of the OAuth2 token. What other capabilities you were looking in that area ?

@david, a presentation for an hour on Let's Encrypt certificates is a bit too much I think :-) However, in conjunction with setting up an high availability constellation with nginx, Docker and PASOE would make an interesting story. Too late for a proposal for Orlando I'm afraid. I wouldn't mind exchanging ideas on this subject over there.

@irfan suppose I have a JWT obtained from an (oauth2) authorization server (this is a client action), just like for example an Angular client would. How can use it for an ABL client? You can't. You can't access a HTTP Authorization header to set it to "Bearer <token>" and let spring security do the rest (which includes converting it to a CP).

I see. Do you see use-cases for ABL Client doing OAuth2 from a batch/CHUI clients ? I would think of having this capability in ABL from the Multi-session Agent where one can take the OAuth2 token and invoke another server.

I was thinking about GUI clients (plain or ABL.NET) as well (client type doesn't really matter). Suppose you're supporting both an Angular and an ABL (GUI) client, what would be better than to be able to support one security mechanism (the Oauth2 / Spring security that is). If the ability exisis, the ABL client could be a trusted (i.e. your own) client as well as a 3rd party client. It's all depends on the whether any client is able to "inject" a Authorization Bearer token to an HTTP call.