Closed nsoblath closed 3 years ago
As verification, since we so far lack unit testing for network-base aspects of dripline, I pushed these changes through to dl-python, and then attempted to start two key-value stores. After the changes, the second exited properly with the expected errors:
key-value-store2_1 | 2021-07-13T23:27:29[INFO ] dripline(113) -> about to start the service
key-value-store2_1 | 2021-07-13 23:27:29 [ERROR] /library/core.cc(424): AMQP exception caught while declaring queue: (405) RESOURCE_LOCKED - cannot obtain exclusive access to locked queue 'my_store' in vhost '/'. It could be originally declared on another connection or the exclusive property value does not match that of the original declaration.
key-value-store2_1 | 2021-07-13T23:27:29[INFO ] dripline(115) -> services started, now to listen
key-value-store2_1 | [New Thread 0x7f353a4f8700 (LWP 13)]
key-value-store2_1 | [New Thread 0x7f3539cf7700 (LWP 14)]
key-value-store2_1 | [New Thread 0x7f35394f6700 (LWP 15)]
key-value-store2_1 | 2021-07-13 23:27:29 [ERROR] /library/core.cc(609): Standard exception caught: The specified consumer tag is unknown
key-value-store2_1 | 2021-07-13 23:27:29 [ERROR] brary/service.cc(440): A hard error ocurred while listening for messages for <my_store>. The channel is no longer valid
key-value-store2_1 | [Thread 0x7f3539cf7700 (LWP 14) exited]
key-value-store2_1 | [Thread 0x7f353a4f8700 (LWP 13) exited]
key-value-store2_1 | [Thread 0x7f35394f6700 (LWP 15) exited]
key-value-store2_1 | 2021-07-13 23:27:29 [ERROR] /library/core.cc(512): Fatal AMQP exception encountered while stopping consuming messages on <>: The specified consumer tag is unknown
key-value-store2_1 | [Inferior 1 (process 8) exited normally]
key-value-store2_1 | No stack.
first-mesh_key-value-store2_1 exited with code
Incidentally, I notice that the service actually continues to start itself even after the first error. This appears to be a problem in dl-python, which I'll address separately.
Curious that those jobs are still in progress, looks good by eye
They most recently restarted because I realized I hadn't propagated the changes to the examples, so I made a new commit.
Based on reports from Raphael I identified a bug in dl-cpp where Rabbitmq errors that happened while listening for messages were being ignored. These errors are generated by the
listen_on_queue()
function, and returned false from that function. But the return values were being ignored everywhere it was used. I fixed that inservice
andmonitor
.