12-10-2020 12:21 PM
My program has been pulling changes (AXL listChange) from my customers CUCM for a few weeks successfully. All of the sudden the CUCM started returning:
com.cisco.ccm.gaxl.api.current.AXLError_Exception: You must have waited too long between calling this API. Cannot find the id you requested.
Can't find any documentation on this and I can't recreate this in any of my sandbox environments. Something has changed in their environment but I don't have any idea what I need to account for.
Any ideas or help with this error is appreciated!
Matt
Example request:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/11.5">
<soapenv:Header/>
<soapenv:Body>
<ns:listChange >
<startChangeId queueId='LY8geVZg'>11</startChangeId>
<objectList>
<object>Phone</object>
</objectList>
</ns:listChange>
</soapenv:Body>
</soapenv:Envelope>
Solved! Go to Solution.
12-10-2020 01:00 PM
Some additional possibilities:
I think in any/all of these cases (including Nick's above), the likely recovery is to start 'fresh', i.e. submit a <listChange> requests without a queueId to retrieve all available changes as when your app started. If this happens frequently and you can determine it's due to a large number of changes occurring, you may want to increase the frequency for polling <listChange> to ensure your app is keeping up.
12-10-2020 12:50 PM
It looks like either your queueid expired, or if you're re-using JSESSIONID, then that expired. I'm pretty sure it's the queueid that expired. You can simply start a new request and get a fresh queueid.
I wouldn't know why it expired without more information. Perhaps your customer restarted the server, or did something else to trigger a reset of the queueid?
12-10-2020 01:00 PM
Some additional possibilities:
I think in any/all of these cases (including Nick's above), the likely recovery is to start 'fresh', i.e. submit a <listChange> requests without a queueId to retrieve all available changes as when your app started. If this happens frequently and you can determine it's due to a large number of changes occurring, you may want to increase the frequency for polling <listChange> to ensure your app is keeping up.
12-10-2020 01:30 PM
This make a lot of sense!! Thank you!
With this new knowledge, I've never found a use for the <firstChangeId> parameter. In the sandbox labs this is pretty much always 1 but I have noticed in production environments that this is often a lot higher. When there are a large number of changes does this <firstChangeId> parameter increment and identify the beginning of the cached range? I'm wondering if I need to trigger a refresh of the changed data if my <startChangeId> is actually lower than the <firstChangeId> I get back.
12-10-2020 02:25 PM
Yes, the documentation supports this idea. firstChangeId needs to be greater than my saved nextStartChangeId.
12-10-2020 01:12 PM
Thank you for the response. There isn't much documentation on the queueId returned from the listChange call but it seems as though it shouldn't expire as you say, it's suppose to persist. The only time it actually changes is when the AXL Service itself is restarted. Sending a different queueId to the listChange call returns a totally different error message.
If you can point me to or provide me with any documentation regarding the queueId, (aside from https://developer.cisco.com/docs/axl/#!axl-developer-guide/details ) I'd be much appreciated.
I'll investigate further into the JSESSIONID expiration. Thanks again for the response!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide