Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved Halt {close} does not release session

  1. How-to
0
Votes
Undo
  1. mike S
    mike S
  2. PowerServer
  3. Tuesday, 9 August 2022 12:14 PM UTC

Powerserver 2022 (i assume PS 2021 has the same problem?)

"If an installable cloud application is closed by the halt {CLOSE} method, the session occupied by an installable cloud app cannot be released properly. You will have to restart PowerServer to release the user sessions."

 

 

Are there any workarounds for this bug in powerserver?  restarting powerserver is not a reasonable workaround.

 

It seems to me that if i do a halt close that should still run the close event in powerserver.  Then in the close event, can't i simply call the KILL session api to kill my own session?  Would that work (clear out the user session)?  I would not want any error message about the session being killed since the kill session would be the last thing to run

IIS Powerserver 2021/2022 CloudInstaller HTTP Erro...
PowerServer WebAPI - trial license expired, now de...
Responses (2)
Francisco Martinez @Appeon
Francisco Martinez @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 9 August 2022 13:27 PM UTC
  2. PowerServer
  3. # 1

Hi Mike,

As long as you can obtain the current session's ID, I'm sure that's perfectly fine. Another workaround I can thing of from the top of my head is adjusting the Session Timeout value of the WebAPIs to a small value, and then in the application create a Timer object that keeps performing a simple SQL query (for example select 1), this would be the keep-alive. This way, when the application is HALTed, the session times out on its own.

I feel like this is a bit more cumbersome than your idea, so maybe you can submit an enhancement request for the HALT operation to end the PowerServer session

Hope this helps.

Regards,
Francisco

Comment
mike S
  1. mike S
  2. Tuesday, 9 August 2022 14:05 PM UTC
Is this still a problem? I tried to repro the problem - in my PB idle event i call a halt close after 30 minutes. the application did close, and the session was also gone! i have session timeout set to 3600 in the application config table. Is the session timeout from the table actually used? (this is PS2022 beta). I guess it is possible that PS did not use that timeout value and used one defined somewhere else?



Also, i always do a halt close in my application close event. When i close my powserver app, the session is removed immediately even though halt close is called in the application close event. So the halt close itself didn't keep the session around.



I would think this is something that is fairly high priority as this bug directly benefits appeon (forces more sessions to be purchased), and so it makes appeon not look good. so maybe it was already fixed?
  1. Helpful
Logan Liu @Appeon
  1. Logan Liu @Appeon
  2. Wednesday, 10 August 2022 05:17 AM UTC
Hi Mike,

A session starts when the user sends a request to load the application and ends 1) if the user closes the application (e.g.: Halt, Halt Close, or Exception) or 2) has not sent any requests to the server during the "session timeout" period.

Your Session timeout setting can only take effect if a user doesn't do any database-related operations during 3600s by default.

Regards, Logan



  1. Helpful
mike S
  1. mike S
  2. Wednesday, 10 August 2022 12:53 PM UTC
Ok, works like i thought it did and same as PS 2020. In PS 2020 we get a lot more sessions that don't close properly and that timeout handles removing them.

  1. Helpful
There are no comments made yet.
Logan Liu @Appeon
Logan Liu @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 10 August 2022 03:38 AM UTC
  2. PowerServer
  3. # 2

Hi Mike,

This is a known issue in 2022 Beta (build 1716), so we added it to the documentation: https://docs.appeon.com/pb/release_bulletin_for_pb/Build-1716-Known-Issues.html

We have fixed this bug, so you can verify it in Build 1810 and later that we sent you separately. This bug will also be fixed in PB 2022 GA.

Regards,
Logan

Comment
mike S
  1. mike S
  2. Wednesday, 10 August 2022 12:48 PM UTC
Ah, ok. I believe it was fixed in 1716 as I spent time trying to reproduce it.



I wish the notes had said that it was expected to be fixed, (and updated on the website that it was) as i spent a fair bit of time trying to figure out a work around.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.