Tuesday April 12, 2011

[Time] NameMessage
[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:
[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 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
[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 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 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:
[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:
[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-
[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://
[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:
[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:
[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 :/