cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1543
Views
1
Helpful
3
Replies

async-commit-queue, one device multiple service instance

jjgrinwis
Level 1
Level 1

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


1 Accepted Solution

Accepted Solutions

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

View solution in original post

3 Replies 3

Jan Lindblad
Cisco Employee
Cisco Employee

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.

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

Remus Grobei
Level 1
Level 1

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?