Race condition when deleting pages in Recycle Bin

[Hilmar Bunjes]

Hi,

we have ran into some race conditions when developing the "Remove page from recycle bin" tests for the SmartAPI for Management Server.

 

We do the following:

- Delete Page

- Check if page status is "deleted"/"in recycle bin"

- Remove page from Recycle Bin

 

Unfortunately, the last case doesn't always work as expected. Although the CMS returns that the page has been deleted and is in the Recycle Bin, we cannot remove the page from the Recycle Bin in about 50% of all tests. If we add a delay of about 2 seconds it seems to work fine.

 

Does anyone have experience with this behavior? Adding a default delay into that method or just try several times wouldn't be a good solution. Does anyone have an idea to really find out if a page is in the Recycle Bin and can be removed from there?

 

Thanks,

Hilmar Bunjes

[Tim D]

Hilmar,

Not on this specific action but I've seen other developers find some RQLs trigger asynchronous functions. I can't recall if you'll have access to async queue in a programmatic means but if this is one of these without doing timeouts and retries, you'd need to interrogate that queue, find the right process check it until done then call your next RQL. Pragmatically timeouts and retries are easier, sure you can validate with via a support ticket that it uses async queues for this. If you were to delete a page linked in 50 different locations there would be more work to do so the use of the async queue on this type of function makes sense in the product.

PS: if you have KC access as a partner keep an eye on the API developments with v11.1 and up

https://knowledge.opentext.com/knowledge/cs.dll/open/29560823

[Hilmar Bunjes]

Tim,

nice to see you again :-)

Not on this specific action but I've seen other developers find some RQLs trigger asynchronous functions. I can't recall if you'll have access to async queue in a programmatic means but if this is one of these without doing timeouts and retries, you'd need to interrogate that queue, find the right process check it until done then call your next RQL. Pragmatically timeouts and retries are easier, sure you can validate with via a support ticket that it uses async queues for this. If you were to delete a page linked in 50 different locations there would be more work to do so the use of the async queue on this type of function makes sense in the product.

 

 

We have decided to use a configurable timeout for this situation. If we run into any other problems we are going to change this but currently this is fine :-)

 

PS: if you have KC access as a partner keep an eye on the API developments with v11.1 and up

https://knowledge.opentext.com/knowledge/cs.dll/open/29560823

 

 

Will do :-)

 

Best,

Hilmar 

[Hilmar Bunjes]

Tim,

 

 

Not on this specific action but I've seen other developers find some RQLs trigger asynchronous functions. I can't recall if you'll have access to async queue in a programmatic means but if this is one of these without doing timeouts and retries, you'd need to interrogate that queue, find the right process check it until done then call your next RQL. Pragmatically timeouts and retries are easier, sure you can validate with via a support ticket that it uses async queues for this. If you were to delete a page linked in 50 different locations there would be more work to do so the use of the async queue on this type of function makes sense in the product.

 

 

We have decided to use a configurable timeout for this situation. If we run into any other problems we are going to change this but currently this is fine :-)

 

 

this is the new SmartAPI version 0.9.3 that implements the timeout solution.

 

If anybody already worked with the suggestion Tim wrote above I would be happy to hear about that.

 

Best,

Hilmar