I've run into the "SOAP session count limit reached" issue, during testing my code against an ESX server. I believe this is due to the number pieces of test equipment hitting the ESX server at the same time. Unfortunately, I'm not getting a useful response back from the server (ok, makes sense, since it's not going to send out any new soap connections). However, I'd love to document this maximum, and where one could modify the settings if need be. So, this leads me to my question:
What is the maximum number of simultaneous SOAP sessions?
How would one modify that number? Is such a modification common use?
Thanks,
J
Hi jaherr-raritan,
Did you ever get a solution to your "SOAP session count limit reached" ? I am getting the same problem (http://communities.vmware.com/message/1019551), and am completely out of ideas.
Many thanks,
Sean
Unfortunately, no. I've not seen any conf files that would match that sort of thing. We did have some older test boxes running code that was not closing SOAP connections. Once they were cleaned up, this issue went away.
J
Hi J,
Thanks for the info. I'll see if I can find any rogue applications...
Did anyone found solution to this problem.
I am having the same problem.
Thanks
Hi,
There is a limit to SDK sessions, default of 100, configurable as
in vpxd.cfg. But if you hit this limit you will get an HTTP 503 Service Unavailable error.
If the number of sessions are more then the default configuration value you will get 503 error. It's not being recommended by VMware to modify the default values in configuration.
Thanks
Niket
Hi Niketh,
Thanks for the info. Infact I had the same issue. I want to increase the sessions so can I do as below?
<soap>
<!-- Minutes before idle sessions time out -->
<sessionTimeout>30</sessionTimeout>
<!-- Maximum number of open sessions -->
<maxSessionCount>500</maxSessionCount>
</soap>
This I got from VMware KB? Pls confrim and thanks in advance.
Regards
Jithin
Just a quick note -
Every session does create additional overhead on the vCenter server. This can impact performance. As a result, a best practice recommendation is to reduce the number of vCenter API sessions when possible.
You can do this by re-using sessions from your application. This may or may not be simple depending on your need for property collection filters, however, you can spin up multiple property collector instances in the same session.
Orchestrator can also be useful in this regard since it can be configured to use a single, unified session for all it's caching against targeted vCenters. If you have workflow type logic in your automation, this may be another way to reduce your session overheard against your vCenter server.
If it's performance related data collection, you could look at StatsFeeder on VMware Labs (fling) - http://labs.vmware.com/flings/statsfeeder