To your surprises, there are two types of sessions involved in vSphere SDK:
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
- HTTP Session. It’s used to identify a client and tracked by the cookie in HTTP header. Once you login the server, all the successive requests have to carry the cookie header similar as follows
- User Session. It’s used to identify a login session of a particular user. You can use SessionManager to find out more the details of the current user and other login users from the UserSession data object. The key in the UserSession is in the same format as the HTTP session, but you should never confuse them, or use them interchangeably.
When we talk about sessions, we normally mean the user session. In some rare cases like vSphere Client plug-in, you do need to understand and use the HTTP session. We will discuss it in a moment.
Given these two sessions, you may wonder how they relate to each other. The answer is quite simple – they have one-to-one mapping.
But things become a little confusing when users get into the picture. One user, for example, can have multiple concurrent user sessions, each of which has its own session ID. That is one reason why some developers have session related performance problem even during development time. This has been discussed thoroughly in the previous blog.
Even more confusing is when the clients get in. One HTTP session can actually be shared by multiple clients either distributed or not, including vSphere clients. That is why vSphere Client plug-in can work. The vSphere Client sends a URL with HTTP session ID for the plug-in’s web application to connect back to the vCenter server just as if it were the vSphere Client itself.
Because the vCenter server does not track the source IP, all the requests from these applications are taken as from one application. So there is no limit, at least in theory, on how many clients can share one HTTP session, and they do not create extra burden on the server side as would multiple user sessions. Still, you may got problems with other things like the method waitForUpdate() of PropertyCollector, which can be confused when all ask for updates. That is why I deprecated waitForMe() method in VI Java API, which uses waitForUpdate(), in Task managed object.
Well, I hope it helps you better understand the sessions and write better applications. To receive future posts, please subscribe this feed.