one problem that had me stumped for a while now is how ZCS handles WaitSets (on ZCS 10.0.2 NE).
I'm trying to use the [Admin]WaitSet SOAP method with expand=true to receive a detailed list of changes since the last WaitSet call.
After a lot of tinkering, I was somewhat successful. (I may post a mini-tutorial in the near future because other forum users seemed to have issues with WaitSets too.)
In [Admin]WaitSetResponse, I receive all the needed details for changes that happend since the last call. Just as I wanted.
However, if there were several changes in an account, only the first change is reported. Later changes within the same account are not contained in the response.
Example:
1. I create a WaitSet for account foobar@myzimbra using the AdminCreateWaitSet method.
2. I call the AdminWaitSet method - no changes reported (correct).
3. foobar@myzimbra receives an email.
4. foobar@myzimbra receives a second email.
5. I call the AdminWaitSet method - I would expect to get details on both emails. But the response contains information for the first email only (the one from step 3). It looks like this:
Code: Select all
<AdminWaitSetResponse waitSet="WaitSet-6750f240-56cc-4f3d-a6bf-872271d78bbb" seq="8" xmlns="urn:zimbraAdmin">
<a id="b37671eb-9339-4946-bc70-e022bf9ce014" changeid="21501">
<mods id="2" xmlns="urn:zimbra">
<created xmlns="urn:zimbraMail">
<m t="MESSAGE" i4uid="637" f="1073742336" tn="" id="637"/>
</created>
</mods>
</a>
</AdminWaitSetResponse>
Using remote debugging (yay for open source software!), I think I tracked it down to this code in SomeAccountsWaitSet.signalDataRead():
- zimbra-SomeAccountsWaitSet.signalDataRead.png (22.48 KiB) Viewed 4457 times
Which I read as: "Only if there are no previous modifications logged for this account, add the current modification to the WaitSet".
That's because the variable mCurrentSignalledAccounts is a java.util.HashSet, so add() only returns true if the key is not yet present in the HashSet.
Thus, only one modification per account makes it into the WaitSetResponse.
That's a bummer for me. Because even though I plan on using AdminWaitSetRequest with block=1 in an endless loop, there may still be single modifications (within an account) getting lost due to race conditions.
Does anyone know if this is intentional or a bug?
The API docs describe /a/mods/created as a "list of created items", so I assume this is a bug. Because as I see it, /a/mods/created can never contain more than one item. Actually, even /a/mods can never contain more than one item.
Any thoughts on this?
Thanks!