Session management is a very important part of vSphere management, especially when scalability is involved. I’ve blogged about this in my previous posts (1, 2). If you haven’t read them yet, it’s high time to do so.
In this article, I am going to share with you a new finding while helping a development team. By default, an idle session is terminated by vSphere server after 30 minutes. The team found that it’s not totally true. They use several types of sessions for different purposes. Two of the sessions remain live even after the 30 minute default while others are gone.
The initial question we asked ourselves was, “what are the differences of the two from others?” Because all the sessions are using the same username, it’s not easy to tell which is which, therefore hard to track the logic behind the two ever-lasting sessions. A little more discussion with the team uncovered that there are two sessions that are different from all others in that they call waitForUpdate() method for pushing changes from server to client.
In the push mode, the server thread gets into corresponding function/method call. It cannot return unless there are new changes per PropertyFilter objects that specify monitoring points. It’s a reasonable argument that the server should know of inactivity of 30 minutes and terminate the session. But in reality, I guess the server side thread may not be able to count time because it’s still within the method call.
Note that the problem wouldn’t be there if a logout is called, which I highly recommend in top 10 best practices using vSphere API. Basically you don’t want to leave doubts to the server side which works most but not all of the times.
Well, sometimes you don’t have full control and the unexpected does happen, for example, your client application shuts down unexpectedly. In that case, if you can avoid push mode, you should be fine; otherwise, you got to manually terminate remaining sessions.