ZeroMq IRC Log

Tuesday April 12, 2011

[Time] Name	Message
[07:38] x58	It's a tad bit of a long read, but if anyone is able to help with this I'd appreciate it: https://gist.github.com/915117
[07:41] mikko	x58: you need ZMQ_LINGER
[07:41] x58	mikko: Where?
[07:41] mikko	x58: assuming exit(127) is somewhat controlled exit
[07:41] x58	No
[07:41] mikko	on the sender side
[07:41] x58	Assume that exit(127) means it crashed hard
[07:41] x58	core dump
[07:41] x58	Or a ctrl +c, or a server went down.
[07:42] mikko	ctrl + c would be sigint
[07:42] mikko	which is still controlled
[07:42] x58	Assume it is not contorled.
[07:42] x58	s/contorled/controlled/
[07:42] mikko	well, zmq_linger controls how long the messages linger in the socket when the socket has been closed
[07:42] mikko	ZMQ_LINGER = 0 is the old behaviour
[07:43] mikko	where all messages are discarded immediately
[07:43] x58	Would that be the case on the server side?
[07:43] mikko	well, to be honest i quite didn't read the full piece
[07:43] x58	I figured as much...
[07:44] x58	I understand it is a long post, but I needed that to explain what I expected and what I am trying to do.
[07:44] x58	BTW, ZMQ_LINGER wouldn't help, the message has already been sent to the remote ... so at that point ZeroMQ could shut down cleanly even with SIGINT
[07:45] x58	The REP socket has to discard the data it has received from the REQ upon the REQ closing the connection.
[07:45] x58	However that is not the case.
[07:46] mikko	and doesn't make sense either
[07:46] x58	Why not? It is a REQ/REP socket, if the REQ is gone, why bother reading it's request?
[07:47] x58	In TCP/IP if I receive a request, and the remote socket is already closed, I don't bother formulating a reponse.
[07:47] x58	If I want fire and forget I'll use PUSH/PULL.
[07:48] x58	Note, that if I remember correctly in 2.0 the remote REP socket would discard the REQ's sent data upon the REQ dropping the connection.
[07:48] x58	I will do some testing when my VM boots up.
[07:49] mikko	x58: it's possible that you are seeing the old linger semantics
[07:49] x58	mikko: So what you are saying is that on 2.0 the ZeroMQ socket wouldn't send the data from the REQ socket until the REP socket called recv()? That doesn't even make sense.
[07:50] x58	How would a poll on the REP socket know that it has data incoming then?
[07:50] guido_g	no
[07:50] mikko	no
[07:50] guido_g	:)
[07:52] x58	I'm looking at the setsockopt() page on api.zeromq.org and I don't see anything about LINGER applying to messages that are already sent.
[07:52] mikko	x58: sent where?
[07:52] mikko	sent over to network or sent to zeromq's send buffer?
[07:53] x58	Sent over the network.
[07:53] guido_g	if the message was recevied it needs to be read by the receiver
[07:53] x58	Going back to my exmaple, REQ sends out "WOOT" over the network. Before REP can retrieve the message from the ZeroMQ receive buffer REQ dies a horribl
[07:54] x58	e death.
[07:54] x58	Now in 2.0 IIRC this meant that the message the REQ sent "woot" in this case, would be discarded on the REP side as well.
[07:54] mikko	x58: it's very hard to say in which transit buffer it is at that point
[07:55] mikko	most likely linger semantics apply there if you die immediately after send
[07:55] mikko	i.e. it's still in the send buffer when you die
[07:55] mikko	the new linger semantics cause the shutdown to delay until the message has been transmitten
[07:56] mikko	with the old semantics it might or might not be sent
[07:56] x58	Okay, so lets assume it is still in the send buffer and it gets sent.
[07:56] x58	What I am saying is that the REP's recv() shouldn't fetch that message from the buffer at all.
[07:56] x58	Since a send() will fail.
[07:57] x58	What is the point of recv() data from a REQ by REP if the REQ is never going to get its request answered?
[07:58] guido_g	how should that be detected?
[07:58] x58	If I am an HTTP server, and I have an incoming queue of messages, and I am temporarily doing something else, and I accept() a connection and then immediately get an error trying to recv() on that socket I just accepted, I don't bother formulating a response and sending it back to the socket since it no longer exists.
[07:59] x58	ZeroMQ knows when a client comes and goes (it after all uses TCP/IP)
[07:59] guido_g	Ã¸mq is not http
[07:59] mikko	x58: but, see
[07:59] mikko	x58: where does the recv() error happen?
[07:59] guido_g	sure, after a read you know if a connection has been gone or not
[07:59] guido_g	repeat "after a read"
[07:59] mikko	if you are receiveing message in zeromq it means that recv() has succeeded
[08:00] guido_g	and there is also a receive buffer...
[08:01] x58	Before in my user code I call recv(), the ZeroMQ thread has already called recv() on the underlying TCP/IP socket, it also knows that before I called my recv() in my own thread that the remote client (the one that sent the data it just recv()'ed) is now gone.
[08:02] x58	What ZeroMQ can do is remove that data from its receive buffer since technically the endpoint is no longer valid.
[08:02] x58	Do you at least agree with me on that?
[08:02] guido_g	no
[08:02] x58	?
[08:03] guido_g	because it might fit your mental model of messaging it does not fit mine
[08:03] guido_g	or the that of the guys who wrote it that way
[08:05] x58	So if I have 1000 clients connect, I start doing work for client number 1, now 400 of those clients kill their connection because of some sort of timeout, or because a network cable is unplugged, I now have to go through 400 REQ packets that when I send a reply won't go anywhere since the endpoint no longer exists? If each of those 400 REQ's take a second each that is 400 seconds that I am dealing with connections that are completely useles
[08:07] mikko	sustrik: do you send the patches manually after commit?
[08:08] mikko	x58: you can implement a poll / timeout for clients
[08:08] mikko	x58: i think the biggest issue with that model is that you create affinity between TCP/IP connection and message
[08:10] x58	mikko: At this point I might as well just use TCP/IP myself because the magic of ZeroMQ doesn't work when a connection is lost ...
[08:10] x58	Instead of adding yet another ZeroMQ stream on top of my REQ/REP.
[08:15] mikko	x58: i don't really see at which point you should be signaled that underlying tcp/ip has failed
[08:15] x58	mikko: I shouldn't. ZeroMQ should discard the incoming REQ since it is "invalid" since sending a reply will fail anyway.
[08:15] x58	ZeroMQ should work its magic at that point.
[08:16] guido_g	as said, that's you point of view
[08:16] guido_g	oh, there is no question that there should be a method to check if an underlying connection has vanished
[08:16] x58	guido_g: Yes. And that makes much more sense. If you want a fire and forget, use PUSH/PULL.
[08:16] mikko	this might work ok peer to peer over really fast network
[08:16] mikko	and even then it's riddled with race conditions
[08:17] mikko	but what about when you add middle devices?
[08:17] mikko	router nodes?
[08:17] x58	Yes? What about them?
[08:17] mikko	should there be disconnection forwarding?
[08:17] mikko	client <-> streamer <-> server
[08:17] mikko	maybe it's worth chatting to sustrik about this
[08:17] mikko	but i'm bound to say that this is application level issue
[08:18] guido_g	it is
[08:18] x58	In my gist i've already possitted that. I said that if it has already been recved() and is being passed on, oh well, spend the time, but in the case of the streamer for example, it could drop 400 connections without having to bother the server with them ...
[08:18] x58	What I am writing is a least recently used queueing router.
[08:19] x58	I receive messages from the frontend, and they need to go to workers. Workers are on EC2 instances
[08:19] x58	they come and go as they please
[08:19] x58	If I have no traffic, sometimes there are 20 - 30 works that have said "send me data", but none of them are active anymore
[08:20] x58	now my message router has to blindly fire off the messages to one of them, never receive a reply, and have to fall back to timeouts and retries
[08:20] sustrik	mikko: yes, i send them manually before commit
[08:20] sustrik	if uncontroversial i commit them
[08:20] sustrik	otherwise i wait for comments/review
[08:20] x58	now if my retries are set to 3 for example, I won't get through the entire backlog of workers that no longer exist.
[08:20] x58	before my retries are up and I send a failure message back to the "frontend"
[08:21] mikko	sustrik: cool
[08:24] mikko	x58: i still think this feels like application level issue
[08:25] x58	mikko: I disagree. I've opened an issue request on github. Unless there is some way that I can be notified about the remote client having disconnected using REQ/REP doesn't feel natural anymore.
[08:25] mikko	sustrik: about dropping messages from zeromq recv buffer based on tcp/ip connections going away
[08:26] x58	sustrik: I've got my gist at https://gist.github.com/915117
[08:26] x58	BRB
[08:26] sustrik	x58 has point in that messages from particular peer can be dropped in REP socket once the peer goes away if there's no identity set be the peer
[08:26] sustrik	the replies will be dropped anyway
[08:26] sustrik	so there's no point in delivering the requests
[08:28] mikko	in some cases i might still want to do the processing
[08:28] guido_g	ack
[08:28] x58	Then use PUSH/PULL.
[08:28] x58	REQ/REP isn't fire and forget.
[08:28] mikko	i'm not talking about fire and forget
[08:28] sustrik	mikko: what's the use case?
[08:28] mikko	but fire and do the best you can
[08:29] x58	The whole point of a REQ/REP is that you send a request, and get a reply. PUSH/PULL can be a fire and do the best you can.
[08:29] x58	If you don't require a reply, then REQ/REP is the wrong socket type to use.
[08:29] x58	And with a fire and do the best you can you clearly don't.
[08:30] x58	If anything, make it a socket option.
[08:30] mikko	yes, i guess in that scenario i can use backchannel for replies
[08:30] x58	So that I can get the behaviour that seems most natural...
[08:31] x58	The onous should be on the client (and I think in ZeroMQ as well) to retry sending the last data if it has yet to recv() a reply to its REQ.
[08:32] sustrik	x58: yes, that's on the roudmap
[08:32] mikko	i summarised the ticket as well
[08:32] mikko	sustrik: where is 3.0 roadmap nowadays?
[08:33] sustrik	i have no idea :)
[08:33] x58	sustrik: better question, since it seems you are well versed in the code. Where can I modify the code to get the behavior I am expecting to use for my project?
[08:33] sustrik	the discussion was kind of inconclusive
[08:33] mikko	sustrik: you mean on the 3.0 overall ?
[08:33] sustrik	yep
[08:34] sustrik	mikko: probably we should discuss that at the conference
[08:34] sustrik	x58: what behaviour is that?
[08:34] sustrik	sorry, i haven't managed to read the whole backlog
[08:34] x58	sustrik: Dropping of the data associated with that peer if the peer goes away.
[08:34] sustrik	ah, let me see
[08:37] sustrik	have a look at zmq::session_t::detach
[08:37] sustrik	that's what gets called when connection breaks
[08:37] sustrik	you don't want the behaviour to happen in all socket types
[08:37] sustrik	so you should check for socket type
[08:38] sustrik	that's stored in options.type
[08:38] x58	Off course.
[08:38] x58	Okay, I will take a look in the next couple of days. I've got some other stuff to write first, for now I just hope I don't have too many issues with disappearing REQ's.
[08:38] x58	Thanks!
[08:39] sustrik	np
[08:39] x58	Oh, should I do my hacking on ZeroMQ2-1 or libzmq?
[08:41] ianbarber	pieterh: been looking at the zero.mq issues, seems to be the .mq DNS servers. Mediaserv may not be the best nic in the world :)
[08:41] mikko	x58: i think libzmq
[08:41] sustrik	x58: what language binding are you using?
[08:42] mikko	i think patches should be fairly easy to backport from libzmq to the other branch
[08:42] mikko	e
[08:42] x58	sustrik: I am ultimately going to be using the Python bindings, but on the roadmap for the project i need to re-write the message queue router in C++.
[08:42] mikko	s
[08:42] x58	So Python for now, C++ later.
[08:42] sustrik	the problem with libzmq (dev) is that some backward incompatible have been introduced recently
[08:42] sustrik	which breaks the bindings
[08:43] x58	Was ZMQ 2.1.x tagged?
[08:43] ianbarber	it's in a separate repos x58
[08:43] x58	Ah
[08:43] x58	sustrik: I'll hack on ZeroMQ2-1 for now, when I've got something substantial I'll work on incorporation it on libzmq.
[08:43] x58	incorporating *
[08:44] sustrik	sure
[08:44] x58	(I'm getting tired, still at work at 2:43 in the morning!)
[08:44] sustrik	yuck
[08:44] x58	Have a good night guys. I'll hang around, mostly idling, will be back to ask more questions soon I think ;-)
[08:44] mikko	sustrik: what's the plan for 2.2 ?
[08:45] mikko	if the development effort is focused on 3.0 and it's already diverging a lot from 2.1 and 2.2
[08:45] mikko	not sure where that leaves 2.2
[08:45] sustrik	ask pieter, it's his project
[08:45] mikko	i think we need to discuss about this as well
[08:45] mikko	at some point
[08:46] sustrik	yes
[08:46] sustrik	don't expect easy solutions though :)
[08:47] sustrik	the problem is there are already too much distinct and often incompatible interests to address
[08:52] ianbarber	fwiw, i kind of see 3.0 as a fork - some projects do ground up rewrites on major versions, and just after a fairly small time it's not practical to worry too much about trying to get the same patches into both systems
[08:53] mikko	ianbarber: that's fair
[08:53] mikko	but where does that leave 2.2 ?
[08:53] sustrik	ack
[08:54] sustrik	however, i still think the question is: do we want 3.0 at all?
[08:54] drbobbeaty	I'm just a little concerned that the quick move to 3.0 as somewhat stranded 2.1.x into the "legacy" camp when it's really just a few weeks old.
[08:54] ianbarber	mikko: 2.1/2.2 etc for all intents and purposes are zeromq
[08:55] drbobbeaty	sustrik: I wonder if it's even possible to know that answer with 2.1.x so new. I mean, has there even been sufficient time to see all the warts and problems in the 2.1.x -- and see that they can only be fixed by a major re-write?
[08:55] ianbarber	ZMQ3.0 needs time, to work out what is being changes, how it should work, and to really break things and rebuild them how they need to be
[08:55] mikko	ianbarber: but 3.0 is already diverging a bit
[08:55] mikko	also supplying patches gets more and more painful
[08:55] ianbarber	mikko: of course, and it should continue
[08:56] ianbarber	you need a small core of people working on 3, while the main bulk of the community builds stuff on 2 and feeds back
[08:56] mikko	not only because 2-1, 2-2 and libzmq follow different approach to contributing
[08:56] ianbarber	the reason we're having this discussion is that the move from 2.0 to 2.1 (for example) was pretty quick - the code was pretty stable, so many people were basically using trunk
[08:57] sustrik	yes, the backward incompatible changes were held back for ages
[08:57] ianbarber	i think that isn't sustainable - there has to be a stable line of branches, and trunk has to be free to go off to different places
[08:57] ianbarber	mikko: in PHP terms, it's andrei and co working on 6, while a bunch of others worked on 5.3 (but hopefully with a more positive outcome)
[08:58] sustrik	there's one more aspect to it: "product" vs. "research"
[08:58] ianbarber	yeah, definitely
[08:58] sustrik	the problem being that 0mq is the first instance of distributed messaging
[08:58] sustrik	worldwide
[08:59] sustrik	so the bleeding edge is basically research
[08:59] sustrik	which doesn't play well with "product"
[08:59] ianbarber	so, i think the only question is: is 2.x ready for taking the ongoing 'product' status? i think it is.
[09:00] sustrik	yes
[09:00] sustrik	i would say so
[09:00] sustrik	that's why i proposed reverting 3.0 changes: forget about research, focus on product
[09:01] drbobbeaty	sustrik: I agree with your stance.
[09:01] sustrik	there's a large community using 0mq and there's lot to be done to support them
[09:01] sustrik	fix the bugs, fill in the gaps in functionality, document everything
[09:02] sustrik	as for the research it can still be done in kernel implemetnation or whereever
[09:02] ianbarber	the ideal outcome, from my point of view, would be if you would be working on 3.0, maybe with a couple of others, trying stuff out, doing the research side, but also contributing to 2.x (in a lesser capacity).
[09:03] sustrik	that'll definitely happen
[09:03] mgoetzke	can somebody explain the difference between https://github.com/zeromq/libzmq and the packing projects on github ? I though they were just branches of sorts but the commits differ a bit
[09:04] ianbarber	similar thing with any contributor: for example mikko, it would be great to have to doign what you're doing for 2.x, but also being involved in helping with 3.0, but probably more 2.x than 3.x
[09:04] mikko	i would be happy if we could come up with one process for all these
[09:04] sustrik	mgoetzke: just use the packing projects, the libzmq should be considered unstable at the moment
[09:04] mgoetzke	ok thanks
[09:05] ianbarber	sustrik: it actually might be worth a note to that effect in the libzmq README
[09:05] sustrik	yup, i can do that
[09:06] ianbarber	mikko: what do you want out of the process though? because I just dont think sharing patches between the two projects is going to be realistic, they can and should diverge.
[09:07] mikko	move things back into one repo, make them branches, being able to commit patches that are uncontroversial
[09:07] mikko	have commits mailed to mailing-list
[09:08] sustrik	well, if we drop 3.0 that's where we get, right?
[09:08] sustrik	2-1 and 2-2, both maintained by a single person
[09:08] sustrik	thus easily mergeable into a single repo
[09:08] mikko	see, that's not ideal
[09:09] mikko	the single person maintainmentship(?)
[09:09] mikko	maintainership
[09:09] sustrik	hm, right
[09:10] mikko	i tried to have a discussion with pieter about this
[09:10] mikko	but there was too much beer
[09:10] sustrik	:)
[09:10] sustrik	ok, let's leave that for brussels
[09:11] mikko	i'm just saying that there is certain amount of uncontroversial patches
[09:11] mikko	and the current process makes it slightly uncomfortable
[09:11] sustrik	ack
[09:11] mikko	work on changes, commit, format-patch, mail changes, wait for merge, reset HEAD~1, pull from upstream, format patch again, apply to 2-1 and 2-2 and push
[09:12] mikko	especially when they are different repos you can't push to all of them from single local repo
[09:12] mikko	you need to have zeromq2-1 from where you can push to zeromq2-1 and zeromq2-2 from where you can push zeromq2-2
[09:12] sustrik	understood
[09:12] mikko	and all repos have all other repos as 'remotes' so that you can cherry pick changes
[09:13] mikko	for people contributing to many branches it's getting out of hand
[09:13] sustrik	yes
[09:14] sustrik	take a step back though
[09:14] sustrik	individual repos are tight to specific interests
[09:14] sustrik	whether commercial or personal
[09:14] sustrik	so, to minimise number of repos these interest should be identified
[09:14] sustrik	and dealt with
[09:15] sustrik	for example, my personal interest is research
[09:15] sustrik	i have a libzmq repo which i wanted to use for research
[09:16] sustrik	however, it turns out that people are not that enthusiastic about research and want basically what they have now, but more stable and feature complete
[09:16] mikko	see, that's where we disagree
[09:16] mikko	i don't see how your research has to happen in isolation
[09:17] mikko	there are some fixes / improvements going to 3.0 that benefits the commercial interest as well
[09:17] sustrik	i'm not saying that, i'm just saying that discussion of specific interests should happen
[09:18] sustrik	and the structure of repos should follow from that
[09:19] sustrik	then there are commercial interests
[09:19] mikko	sure, it's an important discussion to have
[09:19] sustrik	it's not your case, afaiu, as you are an consultant not a software provider
[09:20] sustrik	but others may use 0mq in different ways
[09:20] sustrik	say, adding a set of specific patches and keeping them off-tree
[09:20] sustrik	to get a "enterprise-grade distro" or whatever
[09:20] mikko	that's different from upstream-development in my opinion
[09:21] mikko	what i think is valuable is making contributing as easy and predictable as possible
[09:21] mikko	so that people are drawn into the community
[09:21] mikko	rather than alienated by red tape and process
[09:21] sustrik	yes
[09:21] mikko	well, unpredictable process
[09:21] sustrik	but that also means stabilisation of the codebase
[09:21] sustrik	so that's easy to catch up
[09:21] mikko	not necessarily
[09:22] mikko	this is how i see it:
[09:22] mikko	a user finds a bug
[09:22] mikko	debugs
[09:22] mikko	finds a solution and creates a patch
[09:23] mikko	that patch should be really easy to contribute
[09:23] mikko	we shouldn't care whether it's github pull request, patch to mailing-list etc
[09:23] mikko	we as the developers should take the pain of managing this
[09:23] mikko	to make it as easy as possible to users to contribute
[09:24] mikko	i can see that we follow a proven process (linux kernel)
[09:25] mikko	but we don't have thousands of contributors
[09:25] mikko	we got handful and our goal should be to get people working with the code
[09:25] mikko	and have them sucked in
[09:25] sustrik	otoh, if you create a new process, you are likely to mess it up
[09:25] sustrik	that could be pretty bad especially if the legal part gets wrong
[09:26] sustrik	that's what i am worried about with github pull requests: basically, out legal paperowrk is handled by a 3rd party
[09:26] sustrik	that can go out of business tomorrow
[09:27] mikko	does FSF give help on these kind of issues?
[09:28] sustrik	i think they are pretty busy and unlikely to give advise in specific cases
[09:29] sustrik	anyway, let's discuss this face-to-face
[09:30] mikko	are you going to brussels on 9th?
[09:30] ianbarber	10th
[09:30] ianbarber	is the conf, but i see your point :)
[09:30] sustrik	yes
[09:31] mikko	ianbarber: you flying or train?
[09:31] sustrik	when are you arriving/leaving, guys?
[09:31] mikko	i'm flexible
[09:31] mikko	might arrive on afternoon / evening of 9th
[09:31] sustrik	i have to spend at least one night there
[09:32] sustrik	no way to get from BTX to BXL and back in a single day
[09:32] sustrik	BTS*
[09:32] sustrik	so the question is whether it's better to stay from 9 to 10
[09:32] sustrik	or from 10 to 11
[09:32] ianbarber	i'm not staying, in and out on the 10th on the train
[09:32] sustrik	ok, i see
[09:33] ianbarber	i'm sure people will be around though
[09:33] mikko	thats like hit'n'run
[09:33] ianbarber	mikko: i'm doing 1 day of DPC this year. boom.
[09:33] mikko	thats the problem of being a popular conference speaker
[09:33] ianbarber	if i had the time, i'd stay the evening of the 10th, for more drinking and likely some good breakfast discussion/waffels
[09:33] mikko	so many commitments
[09:34] mikko	i was thinking about renting skills matter in london at some point
[09:34] mikko	and have a mini-conference
[09:34] mikko	maybe some time summer
[09:35] sustrik	why not
[09:35] ianbarber	mikko: definitely would be up for that, happy to help organise
[09:35] so_solid_moo	london \o/
[09:36] ianbarber	on that front, we should organise a london pubmeet for june
[09:36] mikko	ianbarber: my liver can't take another this soon
[09:36] mikko	:)
[09:36] ianbarber	hehe
[10:01] xs	hi, i'm randomly getting Assertion failed: new_sndbuf > old_sndbuf (mailbox.cpp:183) with pyzmq 2.1.2, any ideas?
[10:01] mikko	ianbarber: heading out, will give you a rin
[10:01] mikko	g
[10:08] sustrik	xs: increase default socket buffers on your OS
[10:12] xs	sustrik: does that require root access?
[10:12] xs	(i'm using linux_
[10:14] xs	hm. this code looks broken, from the linux manpage on tcp: "On individual connections, the socket buffer size must be set prior to the listen() or connect() calls in order to have it take effect. "
[10:15] xs	yet this code appears to be changing it after connect/listen and expecting it to have an effect
[10:20] xs
[10:37] sustrik	xs: http://www.zeromq.org/docs:tuning-zeromq
[11:33] xs	sustrik: i found that, it's not help
[11:33] xs	it seems zeromq is broken
[11:33] xs	what a waste of time this has been
[11:35] ianbarber	where are you seeing the code changing it after connect/listen?
[12:10] xs	ianbarber: zmq::mailbox_t::send in src/mailbox.cpp afaict
[12:13] xs	anyways, i give up on zeromq
[13:57] NikolaVeber	evax, there?
[13:59] evax	yes
[14:01] NikolaVeber	do you have a minute, I'm struggling with running the perf code
[14:01] NikolaVeber	I'm trying out what u suggested yesterday
[14:02] NikolaVeber	as I understood it, the remote_lat.erl for example should be run as a shell script?
[14:02] NikolaVeber	~/erlzmq2$ ./perf/remote_lat_active.erl
[14:04] NikolaVeber	returns
[14:04] NikolaVeber	escript: exception error: {function_clause,[{local,main,[[]]}]}
[14:04] NikolaVeber	in function escript:code_handler/4
[14:04] NikolaVeber	in call from erl_eval:local_func/5
[14:04] NikolaVeber	in call from escript:interpret/4
[14:04] NikolaVeber	in call from escript:start/1
[14:04] NikolaVeber	in call from init:start_it/1
[14:04] NikolaVeber	in call from init:start_em/1
[14:05] evax	you should run it with escript
[14:05] evax	escript perf/remote_lat_active.erl ...
[14:05] NikolaVeber	ok... I think I messed up the arguments
[14:06] NikolaVeber	but hold on, if I have, results are just about there :)I
[14:08] NikolaVeber	what is supposed to be running on the other part as a listener?
[14:08] NikolaVeber	I have both erl and c++ perf code on both machines ready
[14:09] evax	you should read this if you haven't yet: http://www.zeromq.org/results:perf-howto
[14:09] NikolaVeber	tx
[14:11] NikolaVeber	got it!
[14:11] NikolaVeber	are you interested in any specific parameters?
[14:19] evax	can you generate some graphs with the included python script and post them somewhere ?
[14:20] NikolaVeber	sure
[14:23] evax	you'll have to edit it to work accross machines
[14:23] evax	(just ssh on of the commands)
[14:23] evax	*one
[14:25] NikolaVeber	remotecmd = "escript perf/remote_lat"+(active and "_active" or "")+".erl" \
[14:25] NikolaVeber	" tcp://localhost:1234 "+str(msgsize)+" "+str(msgcount)
[14:25] NikolaVeber	this line?
[14:26] NikolaVeber	sorry, I get what you mean
[16:30] lazyshot	when trying to create a push socket in node.js i get: Assertion failed: rc == 0 (zmq_connecter.cpp:48)
[16:30] lazyshot	is this a known issue?
[16:31] lazyshot	or does anyone know of a solution?
[17:03] sustrik	lazyshot: what version of 0mq are you using?
[17:04] sustrik	it has something to do with address resolution
[17:04] sustrik	presumably it fails in connect or bind call
[17:15] jdroid-	One of the python examples on the docs is incorrect
[17:15] jdroid-	http://zguide.zeromq.org/py:asyncsrv
[17:15] jdroid-	(notice the init function)
[17:24] sustrik	jdroid-: send a note to the mailing list
[17:42] andy_dawson	Hi, excuse my noobness. when restarting an application I infrequently get "Error - Failed to bind the ZMQ: Address already in use" there isn't anything using zmq except this (test) applicatoin - how to I forcibly restart/release all 0mq activity?
[17:47] Toba	did you try turning it off and on again?
[17:49] andy_dawson	what are you referring to?
[17:52] andy_dawson	if I stop the app (photon php) and stop mongrel2 and kill any processes which look like thy might be related - when I try to then start the application it fails because ... Address already in use
[17:53] andy_dawson	so rather than blindly killing processes I hope there's a better way(R) :)
[17:53] tproa	use your operating system's flavor of "what process is bound to this port"?
[17:54] Toba	netstat/sockstat
[18:00] andy_dawson	netstat doesn't show anything for the port the app is trying to bind to. maybe I've managed to try and bind twice
[18:01] andy_dawson	changing the port number doesn't make any difference either.. odd
[18:01] Toba	could be the classic 'process died in an ugly way, nobody can bind to it for a bit' issue
[18:01] Toba	ok
[18:01] Toba	you're doing it wrong I think
[18:02] andy_dawson	probably. what do you mean
[18:03] lazyshot	sustrik: i'm using 2.1.4 and i have a script spawning a process that connects to the parent via tcp, i'm guessing that the socket isn't binding before the child process is created
[18:04] lazyshot	and attempting to connect
[18:06] sustrik	what address are you passing to the connect?
[18:08] lazyshot	tcp://127.0.0.1:7049
[18:09] lazyshot	which upon netstat -l it shows that it's listening on that port
[18:10] lazyshot	it's also throwing an error that the zeromq object is undefined, but that's when it still attempts to send
[18:10] lazyshot	this is in node.js, btw
[18:33] isvara	Hi. I was thinking zmq would be an excellent protocol to build upon for a chat server. My thought was that a client would connect to a REQ/REP channel to authenticate and be given a session ID (and to send events), then connect to a PUB/SUB channel and subscribe to its session ID to receive events. However, it seems that you can simply subscribe to all messages, which makes that idea invalid. What would be the correct way to do this?
[18:44] isvara	Oh. PUB/SUB is filtered on the subscriber side anyway, so that's definitely the wrong way to do it.
[19:01] eyeris	I've built the zeromq library. Now I'm getting a bunch of undefined reference errors when trying to build pyzmq. The build script suggests that I don't have the dev files installed for either python or zeromq, but I do. I've tried with the newest zeromq and pyzmq from git and the 2.1.4 packages for both.
[19:01] eyeris	Here's a paste of the errors and an ls of the files it suspects are missing: http://pastebin.ca/2045542
[19:04] isvara	Perhaps because you're compiling with 'cc', so it's not linking with the C++ libraries.
[19:05] isvara	How did you kick off the build, and what platform are you on?
[19:05] isvara	Cygwin?
[19:05] eyeris	That would make sense. That was my initial reaction too, but the build message says I need a C compiler.
[19:05] eyeris	Yes, cygwin -- I should have mentioned that
[19:06] isvara	How did you build it? (I don't know what the process is, because I used the Python package that builds it statically.)
[19:07] eyeris	./configure && make && make install
[19:07] isvara	Can you paste the output from configure?
[19:09] eyeris	Sure, here's the most recent attempt, with 2.1.4: http://pastebin.ca/2045544
[19:09] eyeris	The --enable-shared is the default, I just added it to be paranoid
[19:11] isvara	Well, it certainly detects that you have g++.
[19:12] eyeris	Yeah, the zeromq builds fine, using g++
[19:12] eyeris	It's the pyzmq C extension that fails
[19:14] isvara	Looks like it's building vers.exe that is failing.
[19:15] isvara	cc detect/vers.o -L/usr/local/lib -Wl,-R/usr/local/lib -lzmq -o detect/vers.exe
[19:15] isvara	I wonder what would happen if you added a -lc++ to that.
[19:15] isvara	Or -lstdc++ or whatever it is (it's been a while).
[19:16] eyeris	I tried to export CC=g++ (which implies linking to the C++ stdlib), which did not change anything
[19:17] eyeris	Oh, nvm, the cygwin build doesn't use CC
[19:23] sustrik	what's missing is definitely -lstdc++
[19:23] sustrik	no experience with cygwin though
[19:36] isvara	eyeris: Can you just skip it? Do you need vers.exe? Or does other stuff fail too?
[19:40] eyeris	Perhaps I could skip it. I have no idea what vers.exe does.
[19:41] eyeris	I'm still trying to figure out how to make it use stdc++ lib
[19:41] eyeris	It doesn't use CFLAGS or CXXFLAGS
[19:42] eyeris	It also complains with I pass -Xlinker
[19:46] eyeris	Part of the problem may be that what would be /usr/lib/libstdc++ on my debian system is /bin/cygstdc++ on this cygwin install
[19:52] isvara	If it was using the right driver, though (presumably g++), the driver would know what to link with implicitly.
[19:54] eyeris	Right. That's why I was trying to make it run g++, since gcc would look for libstdc++.a, given -lstdc++
[19:55] eyeris	I just noticed that my gcc and g++ packages are still v3.4
[19:55] eyeris	That's probably (part of) the problem
[20:05] isvara	Do you specifically need in Cygwin? Would a Visual Studio build or a Linux build in a VM be an option?
[20:07] eyeris	The rest of the software is built around cygwin :/