One More Secret About Session Management in vSphere

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.

This entry was posted in vSphere API and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • NEED HELP?


    My consulting helps clients with virtualization and cloud computing, including VMware infrastructure automation and orchestration, vSphere management APIs, and deep product integration with hypervisors. Current training offerings include vSphere APIs training, vCenter Orchestrator training, and etc. Should you, or someone you know, need these consulting services or training, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.