'show' hangs up if performed before an 'action' ends

Core Engine and APIs
1

Hello,

I am seeing an odd behavior when I try to run a ‘show’ command while an action, whose action callback answered CONFD_DELAYED_RESPONSE to ConfD, is still running.

my yang is something like this:

augment “mypath” {
_ container mycontainer {_
_ leaf1_
_ leaf2_
_ …_
_ }_
}

augment “mypath” {
_ tailf:action myaction;_
}

I open one ConfD session and execute:

mypath myaction

This action takes a while, so it responds with CONFD_DELAYED_RESPONSE and another software handles the request.

I open another session and while the action is still running I type:

show mypath mycontainer

When the action finishes, the software responsible for its execution notifies the software that communicates with confD and the later responds with confd_action_delayed_reply_error or confd_action_delayed_reply_ok depending on the action result. Then, the show does not print anything, it gets hung up. After the timeout expires I get the following errors:

Error: internal error
Error: internal error
Error: failed to re-allocate session: internal error

I use only one thread for the software to handle requests from confd. The show might also return DELAYED_RESPONSE for the requests.

I would expect that after the action finishes, the show would start exhibiting information.

Does anybody knows what could it be?

2

The classic issue is to use the same socket for the applications, here the data provider and the action. One socket each to avoid mixing requests and replies.

3

Thanks for the response. On ConfD documentation it is stated that using a single thread, one control socket and one worker socket would be enough for the application to never hang longer than it takes to execute a invocation of get_elem, validate or action. That’s why I thought that this should work.

4

I agree there is a need for the one worker socket per worker best practice to be clarified as it is a common issue.

You can use one single or two (one per worker) control sockets here, and if you use just one your application must then be able to map between the worker socket registered for action callbacks and the one used for data provider callbacks.

5

I was able to solve the problem. In my application there was an maapi socket opened at the beginning of it. This was the socket used in maapi_cli_printf calls to answer for action delayed responses.

The problem was that when one confd session was waiting for this delayed response, the other session would start a new transaction (show command). And on the init callback of this transaction the maapi socket was being used in an maapi_attach call to attach it to the show transaction.

My solution was to open a new socket when calling maapi_cli_printf for action delayed responses.