02-09-2018 09:48 AM - edited 03-01-2019 04:05 AM
Hi,
I'm doing some tests with a couple of REST calls to provision several instances of a service on a device.
When not using the async commit queue, all working fine.
But with the option async-commit-queue, first service REST call is fine but second service we're getting an error:
"Commit failed because commit queue item 1518197981496 has an overlapping service or device modification.",
Should the async-commit-queue option not place the request on the queue for this device and just commit them one-by-one to the device?
Regards,
John Grinwis
Solved! Go to Solution.
02-12-2018 09:08 AM
The "unsafe" option did the trick:
admin@ncs> show configuration devices global-settings commit-queue
error-recovery {
mode unsafe;
}
After setting it to "unsafe" we can dump the a-sync request in NSO and off it goes:
admin@ncs> show devices commit-queue
KILO
BYTES WAITING TRANSIENT IS
ID TAG AGE STATUS SIZE DEVICES FOR ERRORS COMPLETED ATOMIC NAME REASON NODE ID
-------------------------------------------------------------------------------------------------------------------
1518455025571 - 8 executing 1 [ CE1 ] - - - true
1518455026352 - 7 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455027109 - 6 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455027862 - 6 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455028523 - 5 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455029234 - 4 executing 1 [ CE2 ] - - - true
1518455029928 - 3 executing 1 [ CE3 ] - - - true
1518455030597 - 3 executing 1 [ CE4 ] - - - true
1518455031395 - 2 blocked 1 [ CE1 ] [ CE1 ] - - true
02-12-2018 06:31 AM
There are a few gotchas with async commit queues. One of them is that there is a mechanism called "automatic error recovery" (which isn't what you think) which is enabled by default. When it is on, you get the message you mention whenever a client issues a change requests that overlaps in any way with any previous change request that is still waiting to be sent out. This is usually not what you want. So despite the dangerous sounding (stupid) name, I recommend that you go from "automatic" mode to:
/ncs:devices/global-settings/commit-queue/error-recovery/manual
"manual" in this case will make commits work as most people are used to with NSO, i.e. transactions and everything as usual. Stupid names of these modes.
02-12-2018 09:08 AM
The "unsafe" option did the trick:
admin@ncs> show configuration devices global-settings commit-queue
error-recovery {
mode unsafe;
}
After setting it to "unsafe" we can dump the a-sync request in NSO and off it goes:
admin@ncs> show devices commit-queue
KILO
BYTES WAITING TRANSIENT IS
ID TAG AGE STATUS SIZE DEVICES FOR ERRORS COMPLETED ATOMIC NAME REASON NODE ID
-------------------------------------------------------------------------------------------------------------------
1518455025571 - 8 executing 1 [ CE1 ] - - - true
1518455026352 - 7 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455027109 - 6 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455027862 - 6 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455028523 - 5 blocked 1 [ CE1 ] [ CE1 ] - - true
1518455029234 - 4 executing 1 [ CE2 ] - - - true
1518455029928 - 3 executing 1 [ CE3 ] - - - true
1518455030597 - 3 executing 1 [ CE4 ] - - - true
1518455031395 - 2 blocked 1 [ CE1 ] [ CE1 ] - - true
09-07-2022 08:58 AM - edited 09-08-2022 10:26 AM
Having same problem on 5.8.3
Here is the configuration of the commit-queues:
devices global-settings commit-queue enabled-by-default true
devices global-settings commit-queue async
devices global-settings commit-queue atomic false
devices global-settings commit-queue retry-attempts unlimited
devices global-settings commit-queue check-integrity false
devices global-settings commit-queue error-option rollback-on-error
devices global-settings out-of-sync-commit-behaviour accept
None of the workarounds above seem to exists anymore
@Jan Lindblad any ideas?
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