Re: [zeromq-dev] XSUB/XPUB proper usage
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 other stuff. On Tue, Dec 30, 2014 at 7:08 AM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: Well, it doesn't throw the exception when I comment the proxy line out. And it does when I uncomment it. That one change back to back is differentiating it. I have no idea why it's throwing, that's literally the code. It runs in a thread created in the constructor of a singleton object. On Tue, Dec 30, 2014 at 12:24 AM, Pieter Hintjens p...@imatix.com wrote: There is nothing in the proxy code that would reject a XPUB or XSUB socket. On Mon, Dec 29, 2014 at 11:50 PM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: On Mon, Dec 29, 2014 at 3:23 PM, Pieter Hintjens p...@imatix.com wrote: Either XSUB or SUB can connect to XPUB. With XSUB you have to send the subscribe / unsubscribe messages yourself. With SUB they're sent by the socket. In either case the XPUB will detect a dead (X)SUB peer and generate ubsub messages up to the API. Thank you! Now I'm having issues with socket operation on non-socket exceptions... _xpub = new zmq::socket_t(_context, ZMQ_XPUB); _xpub-bind(inproc://killpub); _xsub = new zmq::socket_t(_context, ZMQ_XSUB); _xsub-bind(inproc://killsub); zmq::proxy(_xsub, _xpub, NULL); //throws here On Mon, Dec 29, 2014 at 5:08 PM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: On Mon, Dec 29, 2014 at 11:03 AM, Pieter Hintjens p...@imatix.com wrote: On Mon, Dec 29, 2014 at 4:51 PM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: Now my questions: for xpub and xsub do you do the following: pub-setsockopt(ZMQ_SUBSCRIBE, , 0); No, this works only on SUB sockets. I meant sub-setsockopt... but now that makes me think- don't I use ZMQ_SUB to connect to ZMQ_XPUB? at all? Or does the following handle it completely: char *s = xsubscriptionprefix; s[0]='\x01'; sub-send(s); Yes. Also is there a need for unsubscription upon closure of sub? char *s=\x00; sub-send(s); Not needed at the SUB side at all; it's handled by the PUB socket. (I think, from memory.) -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] XSUB/XPUB proper usage
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, Pieter Hintjens p...@imatix.com wrote: 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 other stuff. On Tue, Dec 30, 2014 at 7:08 AM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: Well, it doesn't throw the exception when I comment the proxy line out. And it does when I uncomment it. That one change back to back is differentiating it. I have no idea why it's throwing, that's literally the code. It runs in a thread created in the constructor of a singleton object. On Tue, Dec 30, 2014 at 12:24 AM, Pieter Hintjens p...@imatix.com wrote: There is nothing in the proxy code that would reject a XPUB or XSUB socket. On Mon, Dec 29, 2014 at 11:50 PM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: On Mon, Dec 29, 2014 at 3:23 PM, Pieter Hintjens p...@imatix.com wrote: Either XSUB or SUB can connect to XPUB. With XSUB you have to send the subscribe / unsubscribe messages yourself. With SUB they're sent by the socket. In either case the XPUB will detect a dead (X)SUB peer and generate ubsub messages up to the API. Thank you! Now I'm having issues with socket operation on non-socket exceptions... _xpub = new zmq::socket_t(_context, ZMQ_XPUB); _xpub-bind(inproc://killpub); _xsub = new zmq::socket_t(_context, ZMQ_XSUB); _xsub-bind(inproc://killsub); zmq::proxy(_xsub, _xpub, NULL); //throws here On Mon, Dec 29, 2014 at 5:08 PM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: On Mon, Dec 29, 2014 at 11:03 AM, Pieter Hintjens p...@imatix.com wrote: On Mon, Dec 29, 2014 at 4:51 PM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: Now my questions: for xpub and xsub do you do the following: pub-setsockopt(ZMQ_SUBSCRIBE, , 0); No, this works only on SUB sockets. I meant sub-setsockopt... but now that makes me think- don't I use ZMQ_SUB to connect to ZMQ_XPUB? at all? Or does the following handle it completely: char *s = xsubscriptionprefix; s[0]='\x01'; sub-send(s); Yes. Also is there a need for unsubscription upon closure of sub? char *s=\x00; sub-send(s); Not needed at the SUB side at all; it's handled by the PUB socket. (I think, from memory.) -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] XSUB/XPUB proper usage
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);
}
compiled with:
g++ -std=c++11 test.cpp -lzmq -o test
On Tue, Dec 30, 2014 at 10:42 AM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
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, Pieter Hintjens p...@imatix.com wrote:
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 other stuff.
On Tue, Dec 30, 2014 at 7:08 AM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
Well, it doesn't throw the exception when I comment the proxy line out.
And
it does when I uncomment it. That one change back to back is
differentiating
it. I have no idea why it's throwing, that's literally the code. It
runs in
a thread created in the constructor of a singleton object.
On Tue, Dec 30, 2014 at 12:24 AM, Pieter Hintjens p...@imatix.com
wrote:
There is nothing in the proxy code that would reject a XPUB or XSUB
socket.
On Mon, Dec 29, 2014 at 11:50 PM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
On Mon, Dec 29, 2014 at 3:23 PM, Pieter Hintjens p...@imatix.com
wrote:
Either XSUB or SUB can connect to XPUB. With XSUB you have to send
the
subscribe / unsubscribe messages yourself. With SUB they're sent by
the socket. In either case the XPUB will detect a dead (X)SUB peer
and
generate ubsub messages up to the API.
Thank you!
Now I'm having issues with socket operation on non-socket
exceptions...
_xpub = new zmq::socket_t(_context, ZMQ_XPUB);
_xpub-bind(inproc://killpub);
_xsub = new zmq::socket_t(_context, ZMQ_XSUB);
_xsub-bind(inproc://killsub);
zmq::proxy(_xsub, _xpub, NULL); //throws here
On Mon, Dec 29, 2014 at 5:08 PM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
On Mon, Dec 29, 2014 at 11:03 AM, Pieter Hintjens p...@imatix.com
wrote:
On Mon, Dec 29, 2014 at 4:51 PM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
Now my questions: for xpub and xsub do you do the following:
pub-setsockopt(ZMQ_SUBSCRIBE, , 0);
No, this works only on SUB sockets.
I meant sub-setsockopt... but now that makes me think- don't I
use
ZMQ_SUB
to connect to ZMQ_XPUB?
at all? Or does the following handle it completely:
char *s = xsubscriptionprefix;
s[0]='\x01';
sub-send(s);
Yes.
Also is there a need for unsubscription upon closure of sub?
char *s=\x00;
sub-send(s);
Not needed at the SUB side at all; it's handled by the PUB
socket.
(I
think, from memory.)
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] XSUB/XPUB proper usage
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
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);
zmq::proxy(*xsub, *xpub, NULL);
}
compiled with:
g++ -std=c++11 test.cpp -lzmq -o test
On Tue, Dec 30, 2014 at 10:42 AM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
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, Pieter Hintjens p...@imatix.com wrote:
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 other stuff.
On Tue, Dec 30, 2014 at 7:08 AM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
Well, it doesn't throw the exception when I comment the proxy line
out. And
it does when I uncomment it. That one change back to back is
differentiating
it. I have no idea why it's throwing, that's literally the code. It
runs in
a thread created in the constructor of a singleton object.
On Tue, Dec 30, 2014 at 12:24 AM, Pieter Hintjens p...@imatix.com
wrote:
There is nothing in the proxy code that would reject a XPUB or XSUB
socket.
On Mon, Dec 29, 2014 at 11:50 PM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
On Mon, Dec 29, 2014 at 3:23 PM, Pieter Hintjens p...@imatix.com
wrote:
Either XSUB or SUB can connect to XPUB. With XSUB you have to send
the
subscribe / unsubscribe messages yourself. With SUB they're sent by
the socket. In either case the XPUB will detect a dead (X)SUB peer
and
generate ubsub messages up to the API.
Thank you!
Now I'm having issues with socket operation on non-socket
exceptions...
_xpub = new zmq::socket_t(_context, ZMQ_XPUB);
_xpub-bind(inproc://killpub);
_xsub = new zmq::socket_t(_context, ZMQ_XSUB);
_xsub-bind(inproc://killsub);
zmq::proxy(_xsub, _xpub, NULL); //throws here
On Mon, Dec 29, 2014 at 5:08 PM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
On Mon, Dec 29, 2014 at 11:03 AM, Pieter Hintjens p...@imatix.com
wrote:
On Mon, Dec 29, 2014 at 4:51 PM, Kenneth Adam Miller
kennethadammil...@gmail.com wrote:
Now my questions: for xpub and xsub do you do the following:
pub-setsockopt(ZMQ_SUBSCRIBE, , 0);
No, this works only on SUB sockets.
I meant sub-setsockopt... but now that makes me think- don't I
use
ZMQ_SUB
to connect to ZMQ_XPUB?
at all? Or does the following handle it completely:
char *s = xsubscriptionprefix;
s[0]='\x01';
sub-send(s);
Yes.
Also is there a need for unsubscription upon closure of sub?
char *s=\x00;
sub-send(s);
Not needed at the SUB side at all; it's handled by the PUB
socket.
(I
think, from memory.)
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] create a new job per HTTP request
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 immediately, i mean use a few function calls to validate the data, insert the data, and on success or failure of updating the db, return this status to the user i can do this with 3-4 lines, but i can't decide if i should just throw the request into a job scheduler ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] create a new job per HTTP request
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 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 immediately, i mean use a few function calls to validate the data, insert the data, and on success or failure of updating the db, return this status to the user i can do this with 3-4 lines, but i can't decide if i should just throw the request into a job scheduler ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
