ZeroMq IRC Log

Wednesday May 25, 2011

[Time] Name	Message
[07:13] jond	sustrik: ping
[07:15] sustrik	jond: hi
[07:17] jond	sustrik: there seems to be quite a lot of mentions of mis-designed 'features' lately coupled with the fact that they cannot be changed due to compatibiliy issues
[07:18] sustrik	yes, that's always the case with maturing product
[07:18] sustrik	you can't correct mistakes you've made in the past
[07:18] jond	are these collected on the wiki anywhere? it seems a pity some of the problems cannot be overcome, especially as alternatives seem better
[07:19] sustrik	well, if people are using some feature that is theoretically "bad"
[07:19] sustrik	you can't remove it without hurting the users
[07:20] sustrik	no, they are not collected anywhere
[07:21] jond	yes but part of that was the speed in which some usage examples where produced and shown to work and only later did the problems become evident....
[07:22] sustrik	yes, but that's unavoidable afaics
[07:22] sustrik	unless you want to work in seclusion until the product is perfect
[07:24] jond	i see maybe i'll ask a question on the list as it seems plain wrong to have entered a cul-de-sac
[07:24] sustrik	think of it this way:
[07:24] sustrik	every product has a lifecycle
[07:25] sustrik	it starts as an experiment
[07:25] sustrik	proprietary software is not released at this stage, open source is
[07:25] sustrik	there's almost noone using it anyway
[07:25] sustrik	so the developers are free to improve it any way they want
[07:25] sustrik	later on the product matures
[07:26] sustrik	it's used by many people
[07:26] sustrik	it can't be changed in substantial way
[07:26] sustrik	the development focuses rather on stabilisation
[07:26] sustrik	and adding fancy features
[07:26] sustrik	finally, the product grows old and is superseded by better products
[07:27] sustrik	c'est la vie
[07:29] jond	that's all true, but even in the commercial world, customers are forced to upgrade versions by vendors after a period of time.
[07:29] jond	any how gotta head off now, cyl
[07:30] sustrik	cyl
[07:59] th	asd
[08:01] th	that was unintentional.
[08:05] sustrik	:)
[08:33] CIA-31	libzmq: 03Martin Sustrik 07bidi-pipes * r87a6490 10/ (5 files): All pipe termination code moved to pipe_t ...
[13:26] cods	Hi. Does it make sense to have a node with a ROUTER socket, with different peers using each a DEALER socket? I see that usually ROUTER/DEALER pair are used as intermediate for REP/REQ. Not all my message need a reply.
[13:27] cods	technically I can do that, but I was just wondering if it was ok :)
[13:28] cods	the point is to have a server and various client always connected (with ipc:// sockets) and have messages exchanged between the server and one of the client (in either way) with or without a reply (either fire-and-forget or req-rep style)
[14:26] private_meta	ARGH... this is pissing me off... I'm using the Majordomo stuff to send a message, a string serialized object, and one method deeper all it sends is garbage
[14:29] mikko	which language?
[14:30] private_meta	c++
[14:30] private_meta	as always
[14:30] mikko	are you using zero copy messages?
[14:31] private_meta	no, i don't think so
[14:32] private_meta	If nothing was changed after I added the majordomo example, I'm using it as it's put in the guide
[14:32] private_meta	which works normally for normal messages
[14:32] mikko	what serialisation are you using?
[14:32] mikko	boost?
[14:33] private_meta	yeah
[14:33] mikko	can you pastebin the relevant code?
[14:33] private_meta	Not really
[14:33] private_meta	Ok, let me rephrase
[14:34] private_meta	the relevant code would contain about 15-20 c++ classes
[14:34] mikko	maybe it's a memory management error?
[14:34] mikko	have you tried valgrinding?
[14:35] private_meta	no I haven't
[14:35] private_meta	the thing is... I'm using boost serialization. If I output that string
[14:36] private_meta	or put it into a std::string
[14:36] private_meta	and then print it
[14:36] private_meta	all is well
[14:36] private_meta	as soon as I feed it into a zmsg
[14:36] private_meta	the entire message content is reduced to garbage
[14:37] private_meta	argh, takes so friggin long to compile
[14:49] private_meta	hmm... the problems seem to start when the amount of letters in the string is larger than 120
[14:49] private_meta	erm
[14:49] private_meta	maybe 128
[14:49] private_meta	let me check some more
[14:52] private_meta	Yup, message garbling starts at string length of 128
[15:00] private_meta	mikko: I don't really know how to use valgrind there either... it#s meant to be a continuous program, but using valgrind with my program quits the program immediately with an execption
[15:06] private_meta	ah ok, would work now
[15:10] mikko	private_meta: do you memcpy the c_str() to the message?
[15:18] private_meta	mikko: of course
[15:22] ASY	is there a way to check if the socket is connected? i have req/rep, do connect, send and then blocking recv() hangs me because I am not actually connected to anything. just wondering if there is a way to specifically check if the socket is connected. I can (with difficulties) go around this with poll(), but a connection check would be best in my case.
[15:23] private_meta	ASY: I was told that the only way to check if there is connectivity is to implement Heartbeat messages
[15:42] ASY	ic
[16:02] mikko	ASY: what are the difficulties with poll () ?
[16:19] staylor	with the changes to the high level apis in 3.0 where can I find project information for the c++ bindings or will they be merged with the libzapi?
[16:28] sustrik	staylor: i'll make a separate project
[16:33] staylor	ah excellent thanks
[16:36] sustrik	staylor: looking at the C++ binding
[16:36] sustrik	i would say it should work more or less as is
[16:37] sustrik	are you having any specific problems?
[16:48] sustrik	staylor: the project is on gitbub now:
[16:48] sustrik	https://github.com/zeromq/cppzmq
[16:49] anddam	hello
[16:56] staylor	sustrik, no problems no, I was just looking to post an addition for it to work with boost::asio
[20:26] brianjarita	hey all ... I was wondering how do you generate a server_id like 82209006-86FF-4982-B5EA-D1E29E55D481
[20:26] brianjarita	is there a tool with 0mq that does that?
[20:47] sustrik	there's libbuid linked to 0m
[20:47] sustrik	0mq
[20:47] brianjarita	so do I just run that?
[20:48] brianjarita	like i am building a new server config for mongrel2 and I'm wondering what to put where the server_id goes
[20:49] brianjarita	do I just make up a number for the server?
[20:50] brianjarita	I have main = Server( uuid =" ???? "
[20:50] brianjarita	i'm wondering how to get the id that goes in there
[20:50] sustrik	google for UUID
[20:50] brianjarita	k
[20:51] brianjarita	so your uuid is not unique to 0mq right?
[20:52] brianjarita	according to http://en.wikipedia.org/wiki/Universally_unique_identifier its just a number
[20:53] brianjarita	never mind ... I answered my own question .... I put a number there and it "just worked"
[20:53] brianjarita	thanks
[21:25] Gambit--	hi guys - can anyone tell me how to interface zmq with an existing epoll loop?
[21:29] Toba	not to be nuts, but will another thread kill you dead
[21:30] cremes	Gambit--: you'll have to create a wrapper function that calls epoll() for your regular sockets
[21:31] cremes	and zmq_poll() for your 0mq sockets
[21:31] cremes	OR
[21:31] cremes	i think you can get a file descriptor via getsockopt(ZM_FD) and register it with epoll()
[21:36] Gambit--	huh.
[21:38] cods	Why HWM cannot be set to 0? (0 actually mean infinite) Wouldn't it be useful to not queue anything sometimes?
[21:39] Gambit--	ZM_FD is not supported on 2.0.7
[21:39] Gambit--	(alas).
[21:39] Gambit--	Toba, was that addressed to me?
[21:39] Gambit--	cremes, also, I don't see how you're supposed to call epoll() and zmq_poll() simultaneously :)
[21:40] Gambit--	I'm not sure if ZMQ_FD really does what I think it does, since it seems to be socket specific and not 0mq specific - any reason why I couldn't use the epoll fd that 0mq is using directly?
[21:42] Toba	it does do what you think it does
[21:42] Gambit--	s/I think it does/I want it to do/ :)
[21:42] Toba	because just because the socket that zeromq is using for its socket
[21:43] Toba	does NOT mean that the zmq socket has something ofr you
[21:43] Toba	it could be partially recv'd
[21:43] Gambit--	you misunderstand
[21:43] Gambit--	I would use triggering on the 0mq epoll fd to indicate that I needed to call zmq_poll
[21:43] Toba	that's needlessly hacky
[21:43] Gambit--	possibly.
[21:44] Toba	and I'm pretty sure doing that would not be supported and future versions could break it, but I could be wrong I suppose
[21:44] Gambit--	A little cleaner, tbh.
[21:44] Toba	what's wrong with making zmq_pollitems for the fds from your other loop and using a big pollset for it
[21:44] Gambit--	it depends on how close the zmq_socket's are to the original epoll call.
[21:44] Toba	shrug, i've got stuff to do and I think i've told you everything I know on this issue :)
[21:44] Gambit--	It's usually a maintenance headache to keep all these different lists of the same objects in sync with eachothers.
[21:45] Gambit--	that's fine :)
[21:45] Gambit--	Thank you for your thoughts!
[21:45] Gambit--	Too bad I can't rev to 2.1 right now, alas.
[21:48] cremes	Gambit--: you'll need to be on at least 2.1 to make it feasible to use regular and 0mq sockets together with epoll
[21:48] cremes	also, you might want to search the mailing list archives for this topic; it was covered a lot
[21:49] cremes	in the runup to the 2.1 release
[21:49] Gambit--	nods
[21:49] Gambit--	We're locked into 2.0.7 for this release anyways, so I guess it's fairly moot.
[22:13] CIA-31	jzmq: 03Cliff Evans 07master * rd3c996d 10/ (src/org/zeromq/ZMQ.java test/src/org/zeromq/ZMQTest.java): Added version methods to ZMQ.java. ...
[22:13] CIA-31	jzmq: 03Gonzalo Diethelm 07master * r0a4ba02 10/ (src/org/zeromq/ZMQ.java test/src/org/zeromq/ZMQTest.java): Merge pull request #48 from mipper/master ...