Saturday June 5, 2010

[Time] NameMessage
[03:07] jugg I'm getting a Segmentation fault from within the first time I call zmq::poll, I haven't put it through a debugger yet...
[03:08] jugg is pollitem_t[n].socket expecting a socket pointer?
[03:09] jugg hmm, apparently not, nevermind.
[04:52] CIA-17 rbzmq: 03Brian Buchanan 07master * ra5e4d99 10/ rbzmq.cpp : fix some type-checking bugs in -
[05:21] CIA-17 rbzmq: 03Brian Buchanan 07master * rd11835f 10/ (rbzmq.cpp zmq.gemspec): Update for ZeroMQ 2.0.7 -
[05:22] CIA-17 rbzmq: 03Brian Buchanan 07master * rcb96877 10/ (4 files): Update perf tests for 2.0.7 -
[10:03] oleg hello
[11:48] zeromqer hey, i'm having some problems following first recipe on the cookbook
[11:48] zeromqer
[11:49] zeromqer compiles, and starts up and creates two threads, but doesn't seem to respond to anything
[11:50] zeromqer also the first fprint doesn't print when i include zmq_recv later on
[12:06] jugg zeromqer: what version of zeromq are you using?
[12:10] zeromqer jugg: master from the git repo right now
[12:10] zeromqer had to change the zmq_inits to use just a single parameter from the pastie
[12:12] jugg can you paste the REQ handler code?
[12:18] zeromqer jugg: here's the updated code for both:
[12:20] jugg does this actually work: zmq_connect(s, "tcp://*:9555");
[12:21] mikko zmq_connect(s, "tcp://*:9555");
[12:21] mikko i dont think it does
[12:21] mikko try specifying ip
[12:21] mikko does *:9995 bind ok?
[12:21] jugg there is an assert after binding
[12:21] mikko i would imagine that it is
[12:22] zeromqer yeah, the assert gives no issues
[12:22] zeromqer mikko: but i did just try specifying my ip and still no luck
[12:23] jugg ?
[12:23] zeromqer jugg: yeah, both that and my eth0 ip
[12:23] mikko and no firewall in between?
[12:23] zeromqer same computer :P
[12:23] mikko eth0 might still be firewalled
[12:24] jugg nothing else jumps out, try "inproc://test" instead.
[12:24] zeromqer oh, good point. but yeah, no firewall on my machine
[12:24] zeromqer ah, hm.. good idea
[12:26] zeromqer jugg: assert fails on the client when i use "inproc://test", anything special i should be doing?
[12:27] mikko try icp:///tmp/test.sock instead
[12:27] mikko i had some problems with inproc some time ago as well
[12:28] zeromqer opps, yeah, i was running them as separate processes anyway... switching to ipc
[12:30] zeromqer mikko: and now the server bind assert fails... (using "icp:///tmp/test.sock")
[12:31] zeromqer does zmq_bind set any error messages?
[12:33] mikko use zmq_strerror
[12:35] zeromqer ha, "Error occurred during zmq_init(): Protocol not supported"
[12:37] zeromqer any chance i configured zmq wrong?
[12:40] sustrik ipc
[12:40] sustrik not icp
[12:44] mikko sorry
[12:44] mikko my typo
[12:50] zeromqer mikko: ha, well it survived past both of us! thanks sustrik
[12:50] zeromqer anyway... server runs, client immediately segfaults
[12:51] zeromqer here's a backtrace:
[12:51] sustrik zeromqer: what are you doing?
[12:52] sustrik looks like you are passing invalid message to recv function
[12:52] zeromqer hm..
[12:54] zeromqer sustrik: sweet, i commented out that section and got some communication between server and client
[12:57] zeromqer does anything look really wrong in section? (last two stanzas are what i commented out)
[13:00] sustrik you don't initialise the message
[13:00] sustrik zmq_msg_init (&response);
[13:06] zeromqer sustrik: argh.. initialized now, and all working, thanks
[13:07] zeromqer my only issue is that the now working code over ipc still does nothing over tcp
[13:07] sustrik show us your test prog
[13:11] CIA-17 jzmq: 03Martin Sustrik 07master * r1a16589 10/ (7 files in 3 dirs): updated to match 0MQ/2.0.7 -
[13:11] zeromqer sustrik: server.c and client.c
[13:13] zeromqer also, if i interrupt them both with gdb, i get an equivalent backtrace:
[13:13] sustrik zeromqer: you are connecting both sides
[13:13] sustrik server should bind
[13:14] zeromqer what? srsly?
[13:14] zeromqer typo, brb
[13:14] sustrik jugg: are you still there?
[13:14] sustrik what assert?
[13:15] zeromqer works great now!
[13:15] sustrik :)
[13:15] zeromqer thanks so much guys
[13:15] zeromqer sorry if i was a pain, i'm a bit in unfamiliar territory...
[13:16] sustrik you are welcome
[13:16] jugg sustrik: yes, the assert in the code example that was pasted.
[13:17] sustrik i'm lost
[13:17] sustrik are _you_ seeing the assert?
[13:17] sustrik or is it zeromqer's assert?
[13:18] sustrik <mikko> does *:9995 bind ok?
[13:18] sustrik <jugg> there is an assert after binding
[13:18] sustrik <mikko> i would imagine that it is
[13:18] sustrik <zeromqer> yeah, the assert gives no issues
[13:19] sustrik is it the one we just solved or something unrelated
[13:19] sustrik ?
[13:24] jugg sustrik: I was simply stating that if the binding failed, zeromqer would see an assert. I never ran that code.
[13:24] sustrik ah, ok
[13:24] sustrik sorry for confusion
[13:24] jugg np
[13:25] jugg nice work with the latest round of updates. Things appear to be working well... the documentation updates are great. I should have waited a couple of weeks to start learning. :P
[13:28] zeromqer sustrik: jugg: *:9995 works as well btw, it was all my fault from the beginning :P
[13:31] sustrik :)
[14:05] CIA-17 clrzmq: 03Martin Sustrik 07master * rf8bfa69 10/ (5 files in 5 dirs): updated to match 0MQ/2.0.7 -
[16:57] versificateur I want to have a server that send message to a list of clients
[16:58] versificateur but the problem is that client/ server should work without blocking
[16:59] versificateur when a client send a REQ
[16:59] versificateur it should be able to send another REQ without leavaing an exception
[17:00] versificateur due to fact that server can take some times to reply the client
[17:00] versificateur mikko: do you follow me??
[17:06] mikko i do
[17:07] mikko but as far as a i know req/rep pattern works in that kind of sequence
[17:07] mikko request/reply/request/reply etc
[17:09] versificateur so no possibility to request/request/send/send ...
[17:09] mikko what kind of use case is this?
[17:09] mikko does the server do a lot of processing with the data?
[17:11] versificateur now if you do a request you have to wait for an reply before sending another request (in REP/REQ pattern)
[17:12] mikko that's how i've understood req/rep pattern
[17:13] versificateur but I need to send as much as request I want whitout blocking by waiting the reply
[17:13] mikko i might be wrong in this as well
[17:13] versificateur like the PAIR/PAIR pattern
[17:14] versificateur but the PAIR/PAIR only accept to connections
[17:14] versificateur two connections
[17:16] mikko hmm
[17:16] mikko the way i would probably do it is:
[17:16] mikko server uses req/rep pattern and also publisher
[17:16] mikko client sends request, server replies immediately with id-number or uuid
[17:17] mikko server processes the data in background and PUBLISHes the result in a topic
[17:17] mikko the client is subscribed to the topic and receives the reply async
[17:17] mikko when ever the server is ready to give it
[17:17] mikko makes sense?
[17:19] versificateur yes...
[17:19] versificateur it's a way to resolve the problem
[17:20] mikko i gotta go to the gym
[17:20] mikko i'll be back in about 1.5 hours
[17:21] versificateur thanks for your help and see you later...
[17:36] CIA-17 rbzmq: 03Brian Buchanan 07master * r998a64a 10/ rbzmq.cpp : fix zmq_send() and zmq_recv() for Ruby 1.9 -
[17:49] sustrik versificateur: is the server sending replies?
[17:49] versificateur sustrik: yes
[17:50] sustrik if so, you can use XREQ socket on the client side
[17:50] versificateur but asynchrously
[17:50] sustrik it's like REQ but does not force you to wait for answer
[17:50] sustrik REP side is OK as is for you?
[17:52] versificateur so XREP allow to send reply without wait for request?
[17:53] sustrik yes
[17:53] sustrik you should be aware that during the request transmission ID of the sender is sticked to the request
[17:54] sustrik when using REQ/REP, 0MQ manages it for you transparently
[17:54] sustrik with XREP/XREQ you have to manage it by hand
[17:54] sustrik so when you send message X on the xreq side
[17:54] sustrik you'll get a two-part message on the xrep side
[17:55] sustrik first part is the ID of the client that send the request (opaque binary BLOB)
[17:55] sustrik second part is X
[17:55] sustrik when you want to send the reply
[17:55] sustrik you have to stick the client ID in the front of your reply
[17:56] sustrik so you send a two-part messahe, ID + reply itself
[17:56] sustrik makes sense?
[17:56] versificateur yes
[17:57] versificateur is there some code examples??
[17:57] sustrik hm, not really
[17:58] sustrik you may ask on the mailing list, presumably someone is already using it in that way
[17:58] versificateur okay
[17:58] versificateur does the jzmq support it? (in the 2.06 version)
[17:59] sustrik i think getsockopt is still missing
[17:59] sustrik it's needed to find out whether message consists of single or multiple parts
[18:00] sustrik just implement it if needed, it should be easy
[18:01] versificateur okay... it's the RECV_MORE method?
[18:02] sustrik in C it's getsockopt (s, ZMQ_RCVMORE, &more, &more_size);
[18:02] sustrik in java you can either implement generic getsockopt method
[18:03] sustrik or special getRcvMore ()
[18:03] versificateur okay
[20:33] versificateur mikko: sustrik give me all information
[20:33] versificateur sustrik: are you there?
[20:34] sustrik versificateur: yes
[20:34] sustrik what's up?
[20:34] versificateur i want to know if java binding support device ZMQ_QUEUE?
[20:35] sustrik you mean an in-process device?
[20:35] versificateur yes
[20:35] versificateur like your multithreaded example
[20:36] sustrik the zmq_device method is not exposed via java binding
[20:36] sustrik you would have to add that as well
[20:38] versificateur a look to jzmq could help?
[20:38] sustrik i mean you would have to expose the zmq_device function via jzmq
[20:38] sustrik it's few lines of code afaict
[20:39] sustrik have a look at how other functions are wrapped and do it in similar manner
[20:41] versificateur i'll try and send you back the result for approval
[20:42] sustrik great, that'll make life easier for all the java users of 0mq :)