For some reason the milliseconds portion of the %S timestamp is using a
comma for decimals separator, despite 'locale' saying we're set to (US)
English. /tableflip
Actually some logging was already there, just the logger had never been
set up properly, but then I decided to make the format of this message
more useful.
This is to be used during migration, running on the old host so as to
forward all messages to the new Gateway.
The destination is hard-coded in `LIVE_GATEWAY_URL`.
* Use the "make an explicit Bottle() and use it" change.
* Use app.route with OPTIONS in method= list.
* Remove extraneous setting of Access-Control-Allow-Origin header.
This fixes the problem I was having (on two separate machines, Debian
stretch and Debian buster) with the Gateway not actually sending
messages out port 8500 to the Relay and Monitor.
Something about the '@thing' syntax, or using bare 'run()' must be
interfering with zmq.green. The latter ends up thinking there are no
active/matching sockets to send to[0], despite the sockets definitely
being there (complete with TCP 3-way handshake visible on tcpdump
output).
With the problem:
* no network traffic was observed on port 8500.
* A test sender.send(...) just before the bottle run() call
*did* send the message. A similar test at the start of the
@post('/upload/') function did not succeed.
[0] - I ended up putting debug prints in both python-zmq and the zeromq
'libzmq' libraries, building the Debian packages and installing those
versions. I also ended up using 'gdb' on the process. The end result
of this was to find that the _matching variable (a count of matching
sockets I think) was empty deep in libzmq, when it should be counting
sockets to send to.
This was specifically in zeromq3-4.3.1/src/dist.cpp, in the
void zmq::dist_t::distribute (msg_t *msg_) function. The immediate:
if (_matching == 0) {
test was true. I didn't manage to track down which bit of libzmq code
should have been setting _matching before I 'recursed back up' the call
chain to investigate other things.
