WaitForUpdatesEx() concerns

[gilesm]

Through various VMware PEX sessions and whatnot, I've been told that I need to be using WaitForUpdatesEx() where appropriate. The CheckForUpdates() and WaitForUpdates() methods are being deprecated. The problem is the following caveat:

"Don‟t invoke checkForUpdates, waitForUpdates and waitForUpdatesEx APIs concurrently in the same session. This may cause the remaining changes of a truncated update set to be discarded."

So doesn't this mean that any threads I have that use WaitForUpdatesEx() now all need to use a separate connection to vCenter? The reason being that if they share a single connection they can cause changes to be truncated in different WaitForUpdatesEx() calls. Am I wrong here or did I miss something? This kind of forces SDK users to change their architecture in a signficant way. Rather than sharing a single connection we now have to split things up or actually change our querying mechanism so that we do everything in one giant query right? Anyone else have any concerns with this caveat?

[BenN]

I took that caveat to mean "Don't invoke ... on the same session on the same PropertyCollector".

The 'version' argument in the wait/check calls makes concurrency difficult: whichever PropertyCollector you're talking to is maintaining that

version per-session. Limiting the session to one client means it doesn't have to keep track of all versions, just the most recently sent one.

When there was only one PropertyCollector, this was a major restriction, and you pretty much did have to do everything in one query

thread. With the addition of 'CreatePropertyCollector', you can partition your queries across multiple PropertyCollector objects you

create yourself. Thus, multiple wait/checks calls are possible, but still one-client-per-session-per-PropertyCollector.

I could be mistaken, though: it would be good to get confirmation from VMware on that caveat.

[gilesm]

Interesting. Thanks for the response BenN. So as long as I keep a 1 to 1 relationship of PropertyCollectors to WaitForUpdateEx() calls (within a single client session), I shouldn't encounter any truncations.

[BenN]

I think you'd avoid having truncated results discarded.

Truncation could still occur, but with one-client-per-session-per-PropertyCollector I think you're guaranteed you'll be able to get the rest of the results using the "truncated data version" described in the API:

     http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vmodl.query.PropertyCollecto...

I should re-iterate, though, that I'm speculating based on how I understand the 'version' argument. Real confirmation from VMware would be welcome.

[tos2k]

Thanks for posting that.

I was wondering/debugging that for a while now.

For me it looks like a ESXi 4.1 bug - when I am not completely wrong, that was not an issue before ESXi 4.1.

Its a pity to spend too much time on such issues... seems to me that testing routines can be improved - even at VMware 😉

Tos2k

[tos2k]

Hi!

Any experiences if this issue applies to vSphere 5 platform too?

TIA

[tos2k]

As VMware introduced CreatePropertyCollector/DestroyPropertyCollector in VimSdk 5, i think the issue does still exist.

Tos2k