AXL listChange request com.cisco.ccm.gaxl.api.current.AXLError_Exception: You must have waited too long between calling this API. Cannot find the id you requested.

[matt4923]

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>

[npetrele]

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?

[dstaudt · Accepted solution]

Some additional possibilities:

• A large number of changes have occurred, and the <startChangeId> you requested is no longer in the change chache - i.e. it has 'scrolled out'/been overwritten.  I could see this also happening if CUCM memory/CPU usage was very high as well - the CNF cache may get pruned/purged depending on the CUCM performance situation.
• The system/service has been restarted, and the <startChangeId> and/or queueId you provided is not longer present in memory

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.

[matt4923]

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.

[matt4923]

Yes, the documentation supports this idea.  firstChangeId needs to be greater than my saved nextStartChangeId.

[matt4923]

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!