I'm not challenging your issue, just looking at the code, which
doesn't check the socket types. Any chance you can open things up to
see where the exception is coming from? Or, replace either of the
socket types with another and see if that changes things. I'd
investigate, except I'm deep into
Didn't think you were, was just explaining my reasoning. Thank you!
I'll do my best to create a workable, minimal reproduction of the issue.
In the meantime on my end, I just put it in a thread that sits in a loop
reading from XSUB and sending that to XPUB
On Tue, Dec 30, 2014 at 3:36 AM,
This triggers it:
//test.cpp
#include zmq.hpp
int main(void) {
zmq::context_t ctxt{1};
zmq::socket_t * xpub = new zmq::socket_t{ctxt, ZMQ_XPUB};
xpub-bind(inproc://pub);
zmq::socket_t * xsub = new zmq::socket_t{ctxt, ZMQ_XSUB};
xsub-bind(inproc://sub);
zmq::proxy(xsub, xpub, NULL);
}
Need to de-reference the pointers; the prototype given for the zmq wrapper
is void * for all parameters... so it doesn't differentiate at compile time.
On Tue, Dec 30, 2014 at 11:42 AM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
This triggers it:
//test.cpp
#include zmq.hpp
if it's a request for a page, maybe that page should be cached by the
web server and served
but what if it's something like a POST request
does it make sense for an app to create a new job for each http POST
request on a certain endpoint or should the endpoint process the
request immediately?
by
The Mongrel2 web server works this way. It converts HTTP requests into
ZeroMQ messages that handlers can process asynchronously. I'd say it's a
legitimate approach. :)
On Tue, Dec 30, 2014, at 12:24 PM, sam pendleton wrote:
if it's a request for a page, maybe that page should be cached by the
