As an ITransportinterface, call to each of its method with timeout specified should be expected fail after the given amount of time period. However, due to its internal implementation, timeout is only considered when NetMQ actually attempts to process a given request. This would not be much of a problem if a Message gets processed by NetMQ near immediately after being enqueued, but with insufficient number of workers, which would depend on how lively the network currently is, this completely breaks the transport's behavior, and hence, also the Swarm<T>. As the number of workers determine the throughput of a NetMQTransport, there should be a better fail-safe mechanism to discard "stale" enqueued requests instead of trying to process every call to ITransport's method.
As an
ITransport
interface
, call to each of its method withtimeout
specified should be expected fail after the given amount of time period. However, due to its internal implementation,timeout
is only considered whenNetMQ
actually attempts to process a given request. This would not be much of a problem if aMessage
gets processed byNetMQ
near immediately after being enqueued, but with insufficient number of workers, which would depend on how lively the network currently is, this completely breaks the transport's behavior, and hence, also theSwarm<T>
. As the number of workers determine the throughput of aNetMQTransport
, there should be a better fail-safe mechanism to discard "stale" enqueued requests instead of trying to process every call toITransport
's method.