Crashing on max licenses reached

Kinetic ERP
21

Support says, The average distinct Kinetic userIDs that had an ACTIVE DefaultUser session during the work week was 191.

Meanwhile we only captured licenses going over 100 one time (103). So there is a massive disconnect somewhere . . .

2 Likes
22

That setting appears to be completely ignored in the browser. I can create as many sessions as Iā€™d like. Session id is stored in local storage so it can be shared between browser tabs, but not different browsers/Incognio/InPrivate. Most users wonā€™t create multiple sessions like that though.

2 Likes
23

Most of our users do . . . they switch companies all day long and as more of them start to use the browser this is how they are doing it.

1 Like
24

Strange, we have many people switching companies all day long, and they normally only have one session. Are they using the smart client and browser at the same time?

25

Some of them are, yes.

26

In those cases there would be two licenses consumed, but I wouldnā€™t think that would account for the significant difference you are seeing

I may be wrong but I donā€™t think this has anything to do with multi-company

27

I donā€™t think so either. There is something fundamental I am missing here.

28

I can confirm that is the case.

1 Like
29

Seems to only be that way in the client.

1 Like
30

Take it easy :rofl:

3 Likes
31

@aosemwengie1, were you ever able to find a resolution for this issue (or has it kept happening)? We experienced the exact same thing twice yesterday after never having problems in the past.

32

Nope. They gave us some trial licenses to keep us from hitting max but those are expiring next week. In the intervening months they argued with us about whether or not the issue exists but took no steps to do anything that might resolve the problem. I have put extensive logging in place (capturing every session every 10 minutes) so that the next time it happens I will be able to prove it.

2 Likes
33

Thanks, it seems bonkers to me that reaching a license limit could crash the server. Iā€™m working with support right now but this whole thing just seems really strange. I could see it making sense if there was some other system event (db server crash, network interruption, etcā€¦), users are kicked out of the system and those sessions are still consuming licenses. When users try to log back in, we could meet our limit pretty quickly. Hard to prove though without having access to the servers though.

If I find any other information, Iā€™ll be sure to add it.

2 Likes
34

I heard back from support, and they confirmed it was infrastructure related. Basically, a self-recovery process in AKS needed to recreate the pods and as a result dropped all active sessions. As clients tried to reconnect, more licenses were consumed on top of the stale sessions that were still hanging around. Once the stale sessions were released, the license issue resolved. You can reference CS0005076175 if needed. Iā€™m not sure what is in place for long-term corrective action of the actual root cause.

1 Like
35

This was posed as a theory to me as well but by the time I convinced anybody to try to research the crashes (it happened to us 3 times before the trial licenses were assigned), they said they had lost the logging history that would have confirmed the theory.

1 Like