In the previous implementation, the hub could receive commands from both the HttpCtl server and via a signal. The command is the same type, transmitted over the hub.Commands channel. In the same way, the server answered on a unique channel (hub.Responses). This might lead to a situation where two command issuers (say a signal sent to the circologd process and a command on the control socket) might receive the answer meant for the other issuer and viceversa.
The current solution, as suggested here in the case number 3, is for the command issuer to create a new channel for each command issued and to send it to the hub along with the command itself. The hub should then send the answer through the provided channel.
In the previous implementation, the hub could receive commands from both the HttpCtl server and via a signal. The command is the same type, transmitted over the `hub.Commands` channel. In the same way, the server answered on a unique channel (`hub.Responses`). This might lead to a situation where two command issuers (say a signal sent to the `circologd` process and a command on the control socket) might receive the answer meant for the other issuer and viceversa.
The current solution, as suggested [here](https://stackoverflow.com/questions/27236827/idiomatic-way-to-make-a-request-response-communication-using-channels) in the case number 3, is for the command issuer to create a new channel for each command issued and to send it to the `hub` along with the command itself. The `hub` should then send the answer through the provided channel.
You should see in the circologd output toggling again after waitTime.
As agreed, I also implemented the `-wait-time` switch for `circologctl` (also server side). Now the _self-toggling_ functionality works.
To test it, either run
```sh
$ circologctl pause -wait-time 10s
```
or
```sh
$ curl --unix-socket /tmp/circolog-ctl.sock http://./pause/toggle -s -d "waitTime=10s"
```
(the `http://.` part is mandatory for curl).
You should see in the `circologd` output `toggling again` after `waitTime`.
In the previous implementation, the hub could receive commands from both the HttpCtl server and via a signal. The command is the same type, transmitted over the
hub.Commands
channel. In the same way, the server answered on a unique channel (hub.Responses
). This might lead to a situation where two command issuers (say a signal sent to thecircologd
process and a command on the control socket) might receive the answer meant for the other issuer and viceversa.The current solution, as suggested here in the case number 3, is for the command issuer to create a new channel for each command issued and to send it to the
hub
along with the command itself. Thehub
should then send the answer through the provided channel.As agreed, I also implemented the
-wait-time
switch forcircologctl
(also server side). Now the self-toggling functionality works.To test it, either run
or
(the
http://.
part is mandatory for curl).You should see in the
circologd
outputtoggling again
afterwaitTime
.Merged