Delete idle session automatically in CSI

Dear,

Anyone customizing 1 function to remove or delete idle session automatically?

Please share your information

Thank you so much,

  • We are having the same issue where users are consuming multiple concurrent licences in CSI (9.00.30 on premise) and appear to have left behind 1 or sometimes 2 orphaned sessions that have to be manually deleted in Session Management. This obviously becomes a problem when we exceed the number of concurrent licences.
  • Yes, same issue, and I hope that someone can resolve this issue with customizing automatically
  • We had the same issue. We paid a consulting firm to come up with a solution for us. It works, but it is far from ideal. If I can ever find some spare time, I want to rewrite it to function better but I'll try to explain what's going on as I can't give away their code. Again, this is the solution the consultants came up with:

    The Audit Log settings were tweaked such that entries are made when anyone:
    -Opens A Form
    -Runs A Report
    -Any transaction that touches the database server

    A background task on the database server is set to look at the Session Table & update an "Active User" table to see who is "active". If they reach a pre-defined 'time out', their session is deleted.

    This solution "works", but it has issues IMO:
    1. The criteria for an "Active" user is not the best. This solution is tied to things that can be done versus true active monitoring (ie: is the mouse moving in a window, keyboard activity on a form etc.)
    2. When the user session is deleted, the user has no idea their session was deleted. Example: User begins work in a form just before lunch. They leave for lunch but don't sign out & keep the form open with active work in the form. They return from lunch, continue their work, click Save & get a message their session was deleted.
    3. CSI has seriously locked up on several users when their session is deleted. So much so they either have to beat the process to death in Task Manager or completely log off their workstation to cause the program to terminate.

    I can't think of any other issues we had/have with this solution. Again, it works but it's not robust enough in my opinion. I'd wanted to write an actual set of license monitoring/management forms/tools for this very reason but I haven't found a way to manufacture time yet.

    I'll try to answer any questions anyone has in regards to a solution like this.
  • Please log this in xtreme as a change request, automated management of orphaned sessions for concurrent licensing looks like it could be a useful feature.
  • I raised a related issue on Xtreme which asked whether there was a way to restrict users logging on to CSI multiple times, not having realised that users were actually generating orphaned sessions and not having multiple sessions open at once. This was the reply:

    "We have had this asked before and unfortunately Concurrent users do not work this way and will allow users to log in as many times as they like.

    There is no way to limit a users to a single login under Concurrent licensing."

    I suppose the last sentence is pertinent to this thread because it may extend to the generation of orphaned sessions.

    Anyway I will raise another incident specifically to address the issues of orphaned session but given Stephen's reply above I wouldn't be too hopeful!

    Thanks for the replies.
  • Perhaps I'm being cynical but there is no incentive for Infor to "do something about" inactive sessions.

    I have seen this as a problem in multiple installations - including situations where users logged in and stayed logged in all day even if they were not using the system JUST IN CASE they needed it later in the day.

    At least one time I have known a company therefore increase their licenses.

    Infor is in the business of selling licenses to their software.
  • We purge any session older than 24 hours via script. Our users are instructed to log out at night, thus starting new sessions everyday.

     

    https://pastebin.com/ih1YKjW1

  • Interesting, I didn't know this was an issue with Concurrent Users.

    We have Named Users, and we simply use 2 parameters in the Process Defaults form, namely :

    • Client minutes to ping session (we set it to 10, so that client pings server every 10 minutes even when the user is not using CSI, as long as their computer is not sleeping and their network connection is still active)
    • Minutes to close orphan sessions (we set it to 60, so the session remains active even if the user closes their laptop for almost 1h for lunch or meeting or just walking across the building and switching their WiFi Acces Point ; otherwise they get and IDO connection error when they come back to CSI and thus need to restart it).

    Aren't these features available in a Concurrent licensing mode?

  • FYI: Those process default settings only impact WinStudio sessions, not the WebClient.
  • We use those as well (both set to 30 minutes) with WinStudio click-once clients. (We don't use web at all. Currently on v.8) For us this doesn't solve the problem of people opening multiple sessions on their computers or when leaving for vacation etc with computer still on. Thus we force delete connections left open longer than 24 hours.
  • As late as CSI 9.01.02, we struggled with this and there seemed to have been some bug behind the scenes in this. Either the users really were making multiple logins, or as remote users, losing VPN orphaned the connections, but I've seen a single user with 3 records in ConnectionInformation all getting "refreshed" by what I assume to be "the ping" and never getting booted. It seems like as long as the station is back online, it just refreshes all their connections no matter that they are actual client sessions or not. After power failures and that sort of thing, it was a real problem. I will say that it seems to be inconsistent though, there are times where it just runs smooth, then all the sudden we are at max again.

    I am with Steve Cena though, you really cannot control it 100% and not cause yourself even more headaches. Best you can do is gather the information and see how you need to approach it.

    I will add though, that I surely have thought about creating a unique index on the table, or a custom trigger with some code to limit how many times non-superusers or maybe specific users can login.