Method sendMessage() in NetconfStreamThread.java returns a CompletableFuture with result is null. This causes command to freeze in sendRequest() in NetconfSessionImpl.java when join() is called for the CompletableFuture futureReplay var.
The class NetconfDeviceOutputEventListenerImpl.java is not invoked in the unsuccessful executions.
Logs are attached. The problem could be related with message-ids.
If no message-id is set in the first RPC OR the message-id is set to "1", then command succeeds but only for once, all the other commands freeze.
After a frozen device-setconfiguration, also the subsequent device-configuration freeze too.
If no device-setconfiguration is used, the command device-configuration works fine for multiple executions.
Again, if after a series of device-configurations, device-setconfiguration is executed, then the 1st execution succeeds either with no message-id in the RPC OR with message-id equal to the latest used by device-configuration + 1.
It should be noted that with the patch here (https://gerrit.onosproject.org/#/c/7116/1) the command device-setconfiguration worked multiple times with fixed message-id. This also happens when sending xml through direct ssh sessions towards the device.
According to GEANT's NETCONF expert: "message-id" is used to link an RPC invocation with an RPC reply (if for instance multiple RPCs are performed without waiting for a reply). I am clueless however as to how it affects the device behavior or whether it is required by the device. If i recall correctly all the examples i have seen while studying the matter, contained the message-id field.