Solved

V15.1back office users disconnected

  • 24 August 2023
  • 13 replies
  • 115 views
C
Rank
Userlevel 4
Badge +10

HI our customer is using V15.1 in high availability , we have 3 VM  in the environment.

What can been observed is that several times a day some users are disconnected by the system  with in the c_session_log table the error  “Logging in from different computer(vm3XXX)(UTC: 08/22/2023 09:38:00.033)(w3wp,8792)(PROD)”

whereas the user is using the same desktop. for example on the line 3 below  the user has been disconnected at 08:30 UTC (10h30 french time)   and on line 2 reconnected at 10h30 french time. it looks like the login of line 3  was against on VM3 and on the line on line  VM1. 

is there some settings to avoid this issues ? what could cause this ?

 

icon

Best answer by Phil Seifert 7 September 2023, 11:29

View original

13 replies

Phil Seifert
Rank
Userlevel 7
Badge +21

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.

 

C
Rank
Userlevel 4
Badge +10

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

Reid Gilbert
Rank
Userlevel 7
Badge +15

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

C
Rank
Userlevel 4
Badge +10

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 ?

Reid Gilbert
Rank
Userlevel 7
Badge +15

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

Phil Seifert
Rank
Userlevel 7
Badge +21

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?

Example where to find the Base Version of Publisher

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.

 

L
Rank
Userlevel 3
Badge +9

Hi Phil,

 

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

 

Phil Seifert
Rank
Userlevel 7
Badge +21

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

Phil

 

C
Rank
Userlevel 4
Badge +10

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

Phil Seifert
Rank
Userlevel 7
Badge +21

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 B).  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.

C
Rank
Userlevel 4
Badge +10

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 

Phil Seifert
Rank
Userlevel 7
Badge +21

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.

 

Phil Seifert
Rank
Userlevel 7
Badge +21

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.

 

Reply


Terms & ConditionsCookie settings