3067dbd198
The main issue with eventlet.green.zmq is that libzmq as a C-library is completely monkey-patch unfriendly. So any blocking call inside the native library makes calling process stuck. We can't avoid this actually in an absolutely normal situation when a client appears earlier than listener we have all client process get stuck until listener raised. If the listener for example is also blocked awaiting for some other service to appear we have a chain of locks which may occasionally result in a dead-lock. The other situation with Notifier is quite similar. For that reason zmq-broker was restored, but now it serves as an outgoing queue on a client side. Servers remained the same dynamically port-binded. Now all clients can still use green-zmq, but presence of the broker-queue on a host guarantees that green threads will never blocked in a client because all messages will wait their listeners inside the broker queue. The broker process's modules are not monkey-patched, they make use of native threading and native zmq. Possibility to run without broker also remains. The option zmq_use_broker introduced for that reason. Closes-Bug: #1497315 Change-Id: I786b100fd6ee1cf4b99139db0ca044d358d36345
28 lines
563 B
Bash
Executable File
28 lines
563 B
Bash
Executable File
#!/bin/bash
|
|
set -e
|
|
|
|
. tools/functions.sh
|
|
|
|
DATADIR=$(mktemp -d /tmp/OSLOMSG-ZEROMQ.XXXXX)
|
|
trap "clean_exit $DATADIR" EXIT
|
|
|
|
export TRANSPORT_URL=zmq://
|
|
export ZMQ_MATCHMAKER=redis
|
|
export ZMQ_REDIS_PORT=65123
|
|
export ZMQ_IPC_DIR=${DATADIR}
|
|
|
|
cat > ${DATADIR}/zmq.conf <<EOF
|
|
[DEFAULT]
|
|
transport_url=${TRANSPORT_URL}
|
|
rpc_zmq_matchmaker=${ZMQ_MATCHMAKER}
|
|
rpc_zmq_ipc_dir=${ZMQ_IPC_DIR}
|
|
[matchmaker_redis]
|
|
port=${ZMQ_REDIS_PORT}
|
|
EOF
|
|
|
|
redis-server --port $ZMQ_REDIS_PORT &
|
|
|
|
oslo-messaging-zmq-broker --config-file ${DATADIR}/zmq.conf > ${DATADIR}/zmq-broker.log 2>&1 &
|
|
|
|
$*
|