HI Christophe,

What I find strange is that the logout times are earlier than the login times.  Any chance there are different Alliance environments connected to the same database profile or the servers in the same environment have different timezone/time configured somehow?  Those logout times are appearing as UTC it seems as they are always two earlier than the next login.

Normally, the application will disconnect a user based on session timer setting in the global.xml.  But this would also be indicated as session timeout in the c_session_log so I don’t think that is it.

There are no other settings that impact this area.  I think you should log a ticket for this to the support group.

for the logout for me it is stored in UTC where as  the login is stored in the user or our VM timezone which is in UTC+2.

i will log a ticket

Are sticky sessions enabled on the load balancer?  Can you try increasing the time on those to see if it helps?

Reid the customer is using an azure application gateway 1 the cookie based affinity is enable. Do you have an example of a configuration on azure applicaiton gateway i can compare to the customer configuration ?

Unfortunately I do not, hopefully we have some Azure experts on here that can assist...

HI Christophe,

Coming back to you on the situation with the logout time being in UTC.  It appears this was a problem reported earlier and fixed in V15.1 HF9. Per R&D:

I just checked the code and found this already reported and fixed as part of ASAP IL2009280004. For version 15SP1 it was for HF9. After the fix c_session_log.logout_time value populated by APP server machine as DateTime.Now( ).

Would you confirm which HF version is deployed for your customer so we know the exact version of the software? And the base version of the Astea Browser Publisher as shown in the Catalog - Help screen?

However this is not the root cause of the issue for the disconnections.  R&D has spotted something which they are investigating that causes disconnection. I will let you know what is found once they have further analyzed.

Hi Phil,

I'm answering for Christophe. Here is customer’s version deployed 

Thank you, Laurence.  I am providing this information to the resources in R&D looking into this.

Phil

Hi Phil, could you confirm me that when we have Azure application gateway (or load balancer) once a user opened a session for example on VM1 all the queries should be routed on this VM1 and not on the other one which is part of the Azure Application gateway or the loadbalancer ? 

thanks

Hi Christophe,

If you are asking how it should be working, yes there should be a set up such that requests coming from the same session ID should be routed back to the same VM server.  In a normal load balancer this may be called Affinity.

How your configuration is working, I would not begin to guess but based on the symptoms, I suspect it is not routing the same session back to the same VM.

To illustrate, the Alliance application has its own session ID (say A) for within the application and IIS has its own session id (say .  When a request comes, the connection comes in as A + B to be the unique session to the server.  However, if the load balancer sends the request to a different server, that A + B is not recognized as B was not on the second server.  But the application does recognize A and the IIS on the second server created another IIS session (say C) to the request and is presented as A + C to Alliance which then thinks you are logging in via another location (technically you are) so it closes the existing session and creates a new one.

More than this, I can’t really advise but do review your gateway setup so that connections are always routed to the same server once they have been established.

Hi Phil thanks for our feedback i wanted first to now what was the std behavior. What i can observed is that all the request trough Astea Publisher for example search on a QBE are sent to the same back end application server and all the requests that open the website for example open a service order, customer center record are sent to to the same application sever which can be different from the Astea publisher site perhaps this is that which is causing the issue 

Hi Christophe,

I would need to check on the expected behavior as I would think all requests from the Astea Browser would be sent to the same server… the QBE are also web pages on the application servers.

Hi Christophe,

I have received further clarification from R&D about the session management:

First, as far I know AsteaPublisher machine is in use ONLY during the install/update processing when the client is installing/updating Astea Browser WPF application.

Once installed successfully Astea Browser is using DIFFERENT URL to run the business. It’s typically load balancer URL, when behind the load balancer is the APP servers farm:

• in use by office users
• in use by mobile users
• in use by internal batch processing

Just to confirm about the Session management. We’re are not using IIS session. We’re using Astea SessionID which stored in DB (ap_session_log table) and replicated on demand on each APP server. So, if the first (Login) request performed by APP-1 it stored in memory of APP-1 and saved in DB.

If the second request received by APP-2 when the session is still not in memory – the session loaded from DB first to the memory of APP-2 and request is continuing the execution.

Each request like QBE, Open Module or any other type of request can be redirected by load balancer randomly or by sophisticated logic to ANY machine!

Just FYI. The different story is AFTER the end user Open the module! Once open the module each request (stateful request) must to return to the same machine. And this is not because of SessionID, but because of StateID!

Take look some simple flow example.

• QBE – random server.
• Retrieve Service Order – random server, but a side an actually Service Order data client received also encrypted APP server name.
• Open Customer lookup to change the customer or Node whatever – random server.
• Save after changed customer – dedicated server.
• Close – dedicated server.
• Retrieve again – random server.