Psyllid does not handle set_condition messages

nsoblath commented 6 years ago

dripline::hub:: __do_handle_set_condition_request() needs to be reimplemented in request_receiver.

laroque commented 6 years ago

proposal: a configuration top-level key in the psyllid config file set_condition_actions which is a mapping of condition ID values onto batch-actions. In the event that a set_condition is received for which there is an entry, create a batch executor (configure the existing one?) and run it on the actions set.

updated with some details from Noah:

batch_executor should have a scarab::concurrent_queue where XDataType is a param_node (each being an action description); the batch_actions array in the psyllid config file gets pushed into the queue when psyllid starts up, there’d be some method which wraps concurrent_queue::push that lets us add an action or a param_array of actions to the queue; and the execute method of batch_executor would have some infinite loop that processes the next action in the queue whenever it isn’t empty.

it would then be a configuration file writing exercise to add support for any set_condition cases psyllid needs to support.

Also

move the current execute() into something named process_queue() which gets called at the same point, and on each pass through the new infinite loop in execute()

Noah:

we can move the batch_executor.join() to after the if( ! make_connection) block that way we won’t get held up waiting for it to quit and it’ll get canceled by this->cancel() request_receiver will need to be given a pointer to batch_executor

Ben:

is it bad that each will have a pointer to the other?

Noah:

we make them weak_ptrs, and we should be good to go

laroque commented 6 years ago

Next update, for myself more than anything....

psyllid config file

The following should be valid in a psyllid config file:

on-startup:
    - some
    - list
    - at
    -startup
batch-commands:
    hard-abort:
        - steps
        - to
        - hard
        - abort
    soft-abort:
        - steps
        - to
        - soft
        - abort
    build-mask:
        - steps
        - to build the mask

Batch_executor

Update to store a param_node of batch-commands. It starts with a default set coded into server_config and updates with the config file (upserting config file into defaults).
Add a method to do_batch_command(); which places the corresponding param_array of actions into the batch_executor queue.
In some method (the constructor?), register commands to call the above method (each registered cmd has a different arg to the above specifying a name from the node)

server_config

update server config with the following initial content
```
batch-commands:
hard-abort:
    - steps
    - to stop NOW
set-conditions:
10: <valid-cmd-without-args>
12: <another-such>
```
request_receiver

implement the set_condition handler override in request_receiver to properly decode the above param_node and call the corresponding top-level cmd

validation log & docs

should have new feature & testing details should carefully document the newly available commands and syntax

nsoblath commented 6 years ago

Some extensions to Ben's comments:

batch_executor

do_batch_command's signature should be dripline::reply_info( const std::string&, const dripline::request_ptr_t, dripline::reply_package& ), where the first argument will be the batch-command name.
The commands will need to be registered with request_receiver using something like this:
```
t_req_rec->register_cmd_handler( t_cmd_name, std::bind( &batch_executor::handle_batch_command, this, t_cmd_name, _1, _2 ) );
```
t_cmd_name in the above is a std::string assumed to contain the desired command name. For its second use in the above we may need to do something more tricky than just putting in the variable name.
Since all commands are specified in the config, we can do the registration of handlers in the constructor where that config is received.

request_receiver You didn't say it explicitly, so I'll just mention that the RR needs to also hold the map of the integer key values to the commands that should be called.

project8 / psyllid