ZeroMq IRC Log

Saturday June 5, 2010

[Time] Name	Message
[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 ZMQ.select() - http://bit.ly/bQsfwP
[05:21] CIA-17	rbzmq: 03Brian Buchanan 07master * rd11835f 10/ (rbzmq.cpp zmq.gemspec): Update for ZeroMQ 2.0.7 - http://bit.ly/bIgwVj
[05:22] CIA-17	rbzmq: 03Brian Buchanan 07master * rcb96877 10/ (4 files): Update perf tests for 2.0.7 - http://bit.ly/bKk2zC
[10:03] oleg	hello
[11:48] zeromqer	hey, i'm having some problems following first recipe on the cookbook
[11:48] zeromqer	http://dpaste.com/203476/
[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: http://dpaste.com/203484/
[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 0.0.0.0:9995
[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	127.0.0.1 ?
[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: http://dpaste.com/203497/
[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? http://dpaste.com/203498/ (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 - http://bit.ly/bWgan8
[13:11] zeromqer	sustrik: server.c http://dpaste.com/203503/ and client.c http://dpaste.com/203504/
[13:13] zeromqer	also, if i interrupt them both with gdb, i get an equivalent backtrace: http://dpaste.com/203505/
[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 0.0.0.0:9995
[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 - http://bit.ly/dlnSkU
[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 - http://bit.ly/bsSDT7
[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 :)