I am observing this with JSON RPC, but this will show up across any other mounted data resource. JSON RPC simply allows me to monitor what is coming out of ODL across a mount point.

Can you add more detail?

Some backhground:

JSONRPC tranlates transactions originating from MDSAL more or less 1:1. So for each attempted operation in the SAL layer across the data broker there is a visible operation across JSON RPC.

If we attempt PUT to http://127.0.0.1:8181/rests/data/jsonrpc:config/configured-endpoints=openswitch-1/yang-ext:mount/ietf-interfaces:interfaces/interface=e101-001-0 with the following body:

{"interface":

}

We get the following transaction sequence:

1. Read. This simply should not be happening. PUT means "do as I say", why is it reading at all?

{{INFO:root:> {"jsonrpc":"2.0","id":1,"method":"read","params":["config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[

]}}]}}}
INFO:root:< {"jsonrpc": "2.0", "id": 1, "result": {"dell-interface:duplex": "full", "dell-interface:auto-negotiation": false, "base-if-phy:npu-id": 0, "name": "e101-001-0", "dell-interface:mode": "MODE_NONE", "dell-interface:speed": "0MBPS", "base-if-common:if-index": 3, "base-if-phy:port-id": 25, "enabled": false, "dell-interface:phys-address": "90:b1:1c:f4:ef:a0", "base-if-phy:phy-media": "AR_POPTICS_UNKNOWN", "base-if-phy:tagging-mode": "HYBRID", "base-if-phy:learn-mode": "HW", "dell-interface:fec": "off", "type": "iana-if-type:ethernetCsmacd", "dell-interface:oui": 6976381, "dell-interface:mtu": 1532}}

2. Allocate a read-write transaction
INFO:root:> {"jsonrpc":"2.0","id":1,"method":"txid"}
INFO:root:< {"jsonrpc": "2.0", "id": 1, "result": "9da95d65-fac2-41bc-aec4-c0b063f52015"}

3. Merge of an empty object. As far as meaningless churning this is probably exemplary - this is a clear NOOP.

INFO:root:> {"jsonrpc":"2.0","id":2,"method":"merge","params":["9da95d65-fac2-41bc-aec4-c0b063f52015","config","openswitch-1",{"ietf-interfaces:interfaces":{}},{}]}
INFO:root:< {"jsonrpc": "2.0", "id": 2, "result": null}

4.  The actual put - this should have been No 2. 1 and 3 should have never been executed.

INFO:root:> {"jsonrpc":"2.0","id":3,"method":"put","params":["9da95d65-fac2-41bc-aec4-c0b063f52015","config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[

]}},{"name":"e101-001-0","enabled":true,"dell-interface:mode":"MODE_L2","dell-interface:speed":"100MBPS","base-if-phy:learn-mode":"HW"}]}
INFO:root:< {"jsonrpc": "2.0", "id": 3, "result": null}

5. Commit transaction.
INFO:root:> {"jsonrpc":"2.0","id":4,"method":"commit","params":["9da95d65-fac2-41bc-aec4-c0b063f52015"]}INFO:root:< {"jsonrpc": "2.0", "id": 4, "result": true}

POST is even "better".

This is an trace of a POST to http://127.0.0.1:8181/restconf/config/jsonrpc:config/configured-endpoints/openswitch-1/yang-ext:mount/ietf-interfaces:interfaces/

{"interface":

}

1 First operation is exists() - that is correct behavior, so far so good

{{INFO:root:> {"jsonrpc":"2.0","id":1,"method":"exists","params":["config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[

]}}]}}}INFO:root:< {"jsonrpc": "2.0", "id": 1, "result": false}

2. Second is allocate read-write transaction
INFO:root:> {"jsonrpc":"2.0","id":2,"method":"txid"}
INFO:root:< {"jsonrpc": "2.0", "id": 2, "result": "cd6ba031-5840-4f34-885c-bb0d1ba2f5da"}

{{3. After that ODL goes off the deep end for a while - not one. Two meaningless churn merges of an empty object }}
INFO:root:> {"jsonrpc":"2.0","id":3,"method":"merge","params":["cd6ba031-5840-4f34-885c-bb0d1ba2f5da","config","openswitch-1",{"ietf-interfaces:interfaces":{}},{}]}
INFO:root:< {"jsonrpc": "2.0", "id": 3, "result": null}
INFO:root:> {"jsonrpc":"2.0","id":4,"method":"merge","params":["cd6ba031-5840-4f34-885c-bb0d1ba2f5da","config","openswitch-1",{"ietf-interfaces:interfaces":{}},{}]}
INFO:root:< {"jsonrpc": "2.0", "id": 4, "result": null}

4. This is sort-a correct. I would have expected to see merge() here. However, because the item does not exist, put and merge yield the same result.
{{INFO:root:> {"jsonrpc":"2.0","id":5,"method":"put","params":["cd6ba031-5840-4f34-885c-bb0d1ba2f5da","config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[

]}},{"name":"br200","base-if-vlan:id":200,"enabled":true,"dell-interface:untagged-ports":["e101-002-0","e101-001-0"],"type":"iana-if-type:l2vlan"}]}}}
INFO:root:< {"jsonrpc": "2.0", "id": 5, "result": null}

5. Finally - commit transaction
INFO:root:> {"jsonrpc":"2.0","id":6,"method":"commit","params":["cd6ba031-5840-4f34-885c-bb0d1ba2f5da"]}INFO:root:< {"jsonrpc": "2.0", "id": 6, "result": true}

In both cases JSON RPC is the "messenger" - it simply shows what is coming out of MDSAL courtesy of Restconf translating an HTTP request. I would not expect MDSAL to breed requests or modify them in-transit so my suspicion is with restconf codec having some FSM issues.

It looks like the merge is to ensure the parents exist via TransactionUtil.ensureParentsByMerge. This is necessary for at least the MD_SAL data store - it may not be for all mount point implementations but the restconf front-end doesn't know the difference. Is this behavior specific to the 8040 impl? I believe the draft02 impl should do the same thing.

Also it doesn't create a separate transaction to do the parent merges - it creates one transaction to do all the operations.

Is this really an issue for jsonrpc?

aivanov any thoughts on last comment from tpantelis?

This was discussed as a part of several other discussions related to JSON RPC, database options for mdsal backends, etc.

It is not an 8040 implementation bug and it will sort itself on its own as mdsal develops to include various alternative backends.

You can close it.