IRC Log


Tuesday September 14, 2010

[Time] NameMessage
[08:45] pieterh sustrik: ping?
[08:45] sustrik pieterh: pong
[08:45] pieterh is there any zero copy mechanism on reading messages?
[08:45] pieterh i.e. directly into application buffers
[08:46] sustrik no, you get the buffer from 0mq
[08:46] sustrik you can then store it as long as you wish
[08:47] pieterh ok, thx
[09:04] ptrb so you can `zero-copy' the buffer data beyond the lifetime of the zmq_msg_t?
[09:10] sustrik ptrb: no, but you can keep zmq_msg_t around as long as you wish
[09:10] ptrb roger.
[09:18] pieterh ptrb: I've added a problem solver to the guide
[09:18] pieterh http://www.zeromq.com/docs:the-guide-1#toc13
[09:20] ptrb cool
[09:21] ptrb the "Yes" path on "Are you using XREP sockets?" isn't labeled :D
[09:21] pieterh thanks...!
[09:21] ptrb but that is definitely helpful
[09:21] ptrb i'm a little overwhelmed by the sheer number of different "guides" and "manuals" and whatnot on the docs page(s), though
[09:23] pieterh ptrb: yeah, standard process, lots of growth and then consolidation
[09:23] pieterh stick with www.zeromq.com for starters
[09:24] pieterh really there should only be two books, the guide and the reference manual
[09:24] ptrb sure
[09:25] ptrb there's a solid case for a quick-start (~1h) tutorial as well, I think; maybe that's like ch.1 of the guide
[09:25] pieterh yup
[09:25] pieterh plus lots of tutorials and articles from the rest of the community
[09:41] keffo pieterh, I have a concurrency issue that I cant really figure out!
[09:41] pieterh keffo: shoot
[09:41] pieterh have you checked the new problem solver?
[09:41] keffo lemme check
[09:42] keffo pieterh, Think client, double lru-queue(for outoing tasks, and for incoming results), then an additional 'regular' queue on each machine, which provides N worker processes..
[09:43] keffo pieterh, Theyre all sep. processes, no threading involved anywhere apart from zmq internals..
[09:43] pieterh ok
[09:43] pieterh what is the symptom you are seeing?
[09:44] keffo One worker, all is fine, I've done 100000 tasks back'n'forth with no problem, so the handling of data is sound.. Now if I do more than one worker processes, -sometimes- I get jumbled data, so it's clearly a concurrency issue, but I cant really tell how or where
[09:45] pieterh jumbled data = one message has corrupted data or messages are not in order?
[09:45] keffo I guess both? =)
[09:45] keffo lemme trigger it and check the logs
[09:45] pieterh ok
[09:46] keffo there we go
[09:47] keffo so this scenario has multiple worker processes, but I send out batches or bursts of tasks of different granularity.. With 1 it always works, that is, send one task, wait for that task to complete.. The problem pops up when doing more than one, say 10
[09:48] keffo which is the case now
[09:48] pieterh keffo: you still need to explain what the "problem" actually is
[09:48] pieterh what is the difference between working and non-working in terms of what you see in the logs?
[09:49] keffo well, sometimes routing info is jumbled.. I expect uuid + nil + payload, but sometimes that uuid can get very weird
[09:50] keffo and likewise the payload itself can get messed up
[09:50] pieterh ok, so your message envelopes are wrong
[09:50] keffo They would be wrong with just one message too :)
[09:50] keffo or one worker proc.
[09:50] pieterh most probably an error in your code that creates/copies envelopers
[09:50] pieterh *envelopes
[09:51] pieterh the LRU queue stuff is pretty delicate
[09:53] keffo I dont see the relevance to be honest, I can process 1M tasks properly if I wait for each message(or if I have only one worker processing them).. If there was an inherent problem in the envelope construction/usage, surely that would pop up there as well, but it has -never- happened in that scenario..
[09:54] pieterh keffo: when problem solving you don't care when it works
[09:54] pieterh if you can reproduce a problem, that's the interesting thing
[09:55] pieterh things often work by accident...
[09:55] pieterh so your workers are REQ and you're talking to them with an XREP?
[09:55] keffo yeah
[09:56] pieterh do you store the worker identity anywhere?
[09:56] keffo I can reproduce it, but with irregularities one has come to expect from multithreaded :)
[09:56] keffo yeah, all connections are known
[09:57] pieterh so the obvious thing to look at would be how you reconstruct the envelopes and where the worker addresses come from
[09:57] pieterh and that you're not using the wrong data
[09:58] pieterh you presumably have logic that is vulnerable to multiple workers sending back stuff at the same time
[09:59] pieterh maybe you're not using SNDMORE properly in the worker when sending
[09:59] pieterh so messages arrive mixed together rather than atomically
[09:59] keffo right, I dont see that being possible either, as it properly routes across 3-4 queues?
[10:00] pieterh you have assertions on everything?
[10:00] keffo think so, yeah
[10:00] pieterh so every single frame is checked? e.g. RCVMORE where expected, empty frame where expected, etc.
[10:00] keffo yes
[10:01] pieterh the only think I can think of right now is that you can send what looks like a valid envelope but it won't survive concurrency
[10:02] keffo What would cause multiple incoming multipart-messages to break symmetry with more than one sender, in a singlethreaded process?
[10:02] keffo that's what I dont get :)
[10:02] pieterh well, if they are not actually multipart messages
[10:02] pieterh lets say you send the envelope (address, null, data)
[10:03] pieterh but you by mistake use normal sends on each part
[10:03] keffo yup
[10:03] pieterh it'll be 3 messages, not 1 3-part message
[10:03] pieterh if you read that, it might look valid and work for routing
[10:03] pieterh but as soon as you have concurrency it'll stop working
[10:03] pieterh like i say, i've never tried that, but will make a test now, after coffee
[10:04] pieterh i'd expect 0MQ to reject such messages...
[10:04] keffo hmm.. I'll go over the code again! :)
[10:04] pieterh but from REQ to XREP it can't IMO
[10:06] keffo cant reject?
[10:07] sustrik keffo: can you check whether the garbled identity you see is something that may actually your application message or whether it's just real junk
[10:07] sustrik ?
[10:09] keffo It's not real junk.. Sometimes for example I get route uuid that appears to be a mix of multiple uuid's
[10:09] keffo clearly something breaks symmetry somehow
[10:09] keffo I'll lok into the route logic again though
[10:11] sustrik "mix of multiple uuid's" = junk IMO
[10:12] sustrik ok, a sanity check:
[10:12] sustrik do you use each socket exclusively from a single thread?
[10:12] keffo yeah
[10:12] sustrik what language are you using?
[10:13] keffo c++ and lua
[10:13] keffo but homebrew bindings
[10:13] sustrik any chance to test a pure c++ setup?
[10:13] keffo hehe. noo :)
[10:14] sustrik hm, lua binding is a project i know nothing about
[10:15] sustrik the bug can be there, as no such problem was yet reported for any other language
[10:15] sustrik ok, any chance of using anything other than lua?
[10:19] keffo Would take forever to rewrite
[10:19] sustrik ok
[10:19] sustrik how does the setup look like?
[10:19] sustrik which part is c++ and which is lua?
[10:20] keffo all zmq stuff is c, rest is lua.. Ie, connect/bind/send/recv(and their more-counterparts)
[10:20] sustrik you are mixing C code and lua code to use the same 0MQ socket?
[10:21] keffo Um no, I created bindings for sockets, so it's the same thing
[10:21] sustrik hm, are you saying that 0MQ is written in C while your apps are in lua?
[10:22] keffo I've extended an application with lua yeah..
[10:22] keffo lua or not is besides the point really
[10:22] keffo All zmq related code is in C++
[10:23] sustrik aha, so you are _not_ using the lua binding
[10:23] sustrik right?
[10:23] keffo I am, but not the ones from the site :)
[10:23] sustrik your own
[10:23] keffo yup
[10:24] keffo just an abstraction layer that's easier to work with on the lua side
[10:24] sustrik ack
[10:24] sustrik what's the lua's threading model?
[10:24] keffo inherently single threaded, but it has coroutines
[10:25] sustrik ok, so there's only one OS thread for each lua process, right?
[10:25] keffo yes
[10:26] sustrik no such think as garbage collection thread or similar?
[10:26] sustrik thing*
[10:26] keffo client, loadbalancer, computenode and workers are all single processes (a computenode is simply a c++ queue dev. 'owning' the worker processes)
[10:26] keffo No, not in another thread no.. Lua does incremental gc but in the same thread
[10:27] sustrik ok
[10:27] sustrik then it looks like the problem has to be in 0MQ itself
[10:27] sustrik it should be reproducible in C or C++
[10:28] sustrik can you write a simpe C/C++ test that simulates what you are doing in your app?
[10:28] sustrik messaging-wise i mean, not the business logic
[10:28] keffo hmm.. that would take a while I think..
[10:29] keffo I do think I'm to blame, not zmq, I just need a better way to debug it probably :)
[10:30] keffo It behaves as threaded concurrency issue, but being entirely single process based..
[10:30] sustrik there's an I/O thread inside 0MQ so it can be a race
[10:31] sustrik however, i can't help unless i am able to reproduce it
[10:31] keffo Well I'd be half way safe if I could reproduce it too, but it's quite rare :)
[10:31] sustrik of course, it's still possible that you are overwriting memory in your app or something like that
[10:31] sustrik have you tried to valgring your binding?
[10:31] sustrik valgrind
[10:33] keffo no valgrind in win as far as I know.. Boundschecker perhaps, but I doubt that's the problem too
[10:33] keffo Again, in a single-worker scenario, everything is flawless regardless of amount and load etc
[10:34] keffo (and none of the processes every leak anything, stays solid around 2mb mem)
[10:34] sustrik then it looks like a problem in the central dispatcher node
[10:34] keffo yeah
[10:34] keffo that's the most complicated bit too
[10:35] keffo double lru queue device basically
[10:36] sustrik well, unless you are able to provide something to reproduce the problem, you are on your own here
[10:36] keffo I know :)
[10:37] keffo more logging I guess. It would be nice to have all participants publish all the data they process, and collect that in a sub app, and then be able to "play back" everything
[10:37] ptrb that could easily become a project as complex as zmq itself
[10:37] ptrb entire companies are built on the concept of capturing/replaying network traffic
[10:37] pieterh keffo: if you can send me your code I'll see if I can spot anything
[10:38] pieterh i need the parts that read and write worker envelopes, to start with
[10:38] keffo sure hold on
[10:38] keffo wheres the pastebin?
[10:38] pieterh gist.github.com works well
[10:39] keffo But again, if the envelope code is flawed, it would be equally flawed for one worker?
[10:40] pieterh keffo: i explained how it could be flawed but still work for one worker
[10:41] keffo http://gist.github.com/578849
[10:42] pieterh keffo: i need the actual detail of sendpath, I think
[10:42] pieterh *sendmore, sorry
[10:42] keffo That is in C, hold on
[10:44] keffo http://gist.github.com/578851
[10:44] keffo send() is obviously quite similar except for the flag :)
[10:45] pieterh keffo: it looks fine
[10:46] pieterh you're sure that pairs() gives you stuff in the right order?
[10:46] pieterh so you have only one choice left, sadly
[10:46] keffo rewrite, and hope it goes away? =)
[10:47] keffo naa, there's some stupid silly thing somewhere
[10:47] pieterh well, everything goes through these functions
[10:47] pieterh so put in printf statements or whatever
[10:47] pieterh and see when it actually goes wrong
[10:47] keffo Yeah, need to find a pattern..
[10:47] pieterh pieter's rules #5 and #23 of debugging
[10:48] pieterh (a) it's never actually a race condition
[10:48] pieterh (b) you can find any bug using printfs
[10:48] keffo except the ones in printf!
[10:48] pieterh that's why C offers puts as well!
[10:49] keffo One thing I could do is rewrite the loadbalancer stuff in pure C
[10:50] pieterh keffo: there's no point rewriting unless you have found the cause of the problem
[10:50] ptrb why are your rule #5 and #23 labelled (a) and (b)??
[10:50] keffo indeed
[10:51] pieterh ptrb: lol
[10:51] keffo pieterh, That code should be rewritten though, for performance, but I agree :)
[11:37] BooTheHamster What mean error "operation cannot be accomplished in current state" in zmq_send() call?
[11:38] ptrb hey i got that yesterday! :D
[11:39] ptrb basically means you're violating some constraint of the socket
[11:39] ptrb is it ZMQ_REQ or _REP?
[11:39] BooTheHamster ZMQ_REQ
[11:39] ptrb you must call zmq_send, then zmq_recv, before you can call zmq_send again
[11:39] BooTheHamster I't a client app but run withiut server
[11:39] ptrb are you doing that?
[11:39] BooTheHamster yes
[11:39] BooTheHamster first I call zmq_send
[11:40] BooTheHamster and then zmq_recv
[11:40] ptrb on the same socket
[11:40] BooTheHamster m_MsgSock->recv(&msg_rcv, ZMQ_NOBLOCK)
[11:40] BooTheHamster yes
[11:40] ptrb noblock means you may not actually have recv'd anything
[11:40] ptrb you have to actually recv something before you can send again (I believe--maybe someone can confirm)
[11:41] BooTheHamster but i want non blocking recv
[11:41] ptrb that's fine, you just can't send again until your non-blocking recv actually gets something
[11:41] ptrb if you want to do multiple sends without getting data back, use XREQ
[11:43] BooTheHamster Thank you ptrb, XREQ helps.
[11:44] BooTheHamster A little one question ... on server side i must use XREP or REP socket?
[11:45] ptrb just depends on what behavior you can tolerate there... both will work, but REP requires you to recv, send, recv, send actual data
[11:46] ptrb `man zmq_socket' for more details
[11:50] BooTheHamster thanks
[11:52] ptrb i helped!! :D
[11:52] ptrb maybe
[11:52] guido_g and for some more ideas what to use when: http://www.zeromq.org/docs:user-guide
[12:25] cremes ptrb: you're an expert now! ;)
[13:02] pieterh cremes: I moved your xrep-xrep recipe page into the tutorials section
[13:47] Tasser why use rbzmq <=> ffi-rzmq?
[13:54] cremes Tasser: they have slightly different APIs; the ffi-rzmq more closely tracks the C api whereas rbzmq uses strings for everything
[13:55] cremes also, ffi-rzmq is more compatible with ruby runtimes (jruby, rubinius, mri)
[13:55] Tasser strings sounds like overuse of core classes
[13:55] cremes well, most people will probably convert their data to string format for send/recv under ruby because it's convenient
[13:55] Tasser that's what JSON is for :-)
[13:56] cremes but since ffi-rzmq exposes a zmq_msg_t-like structure you can pass around C structs without doing a lot of extra copying
[13:56] Tasser but I suspect you can't hardwire zmq against json
[13:56] cremes that *might* be more efficient
[13:56] cremes what do you mean by hardware? as far as i know, 0mq (and zmq) don't care what you pass on the wire
[13:56] cremes s/hardware/hardwire/
[13:57] Tasser well, for filtering in subscribe
[13:57] cremes ah, subscribe filters at the byte-level
[13:57] cremes no need to encode the subscription topic unless you want to decode it on each subscriber too
[13:59] Tasser hmm
[14:00] cremes hmm sometimes means "i don't know what you are talking about" :)
[14:58] Tasser cremes, well, so you could filter based on JSON, but that would make it bloat
[14:59] cremes Tasser: my point is that 0mq matches topics by comparing bytes
[14:59] cremes so you want it to fail as soon as possible
[15:00] cremes using a json-encoded topic means that more bytes would need to be compared to find mismatches
[15:00] cremes so subscription filtering would be slower
[15:00] cremes for example...
[15:00] cremes sock.setsockopt ZMQ::SUBSCRIBE, 'topic.string'
[15:00] cremes versus
[15:01] cremes sock.setsockopt(ZMQ::SUBSCRIBE, JSON.encode({'topic' => 'topic.string'})
[15:01] cremes honestly, i'm not even sure if that second example would ever work
[15:01] cremes since the json encoder could put things in different order while still producing valid json
[15:02] cremes just use a string for the topic and put your encoded data into a second message part
[15:02] Tasser yeah, probably the sane idea of using it.
[17:01] kleppari hello
[17:01] kleppari http://zguide.zeromq.org/ - should I need to register to view this?
[17:02] ModusPwnens Im not sure, but if you do register, let me know if you are successful. I was trying to the other day and it wouldn't work =/
[17:03] pieterh kleppari: isn't is showing? rats... :-( thanks for pointing it out
[17:03] guido_g f*ck, this is wikidot crap
[17:03] guido_g sorry
[17:03] pieterh gudio_g: default permissions on cloned site are private, I forgot
[17:03] guido_g and you need to allow cross-domain cookies
[17:03] pieterh happily it's a 10-second fix
[17:04] guido_g wikidot sucks in this regard
[17:04] pieterh guido_g: you need to not disallow the dratted things
[17:04] pieterh it's for good security reasons, unfortunately
[17:04] kleppari registered with wikidots, worked after that. I think it's a major fail to require it though :)
[17:04] pieterh kleppari: not required, it was my fault
[17:04] kleppari pieterh: np, thanks for the guide :)
[17:04] guido_g pieterh: cross-donmain cookies are for security?
[17:04] pieterh it should work for anonymous users now
[17:05] pieterh guido_g: wikidot splits off insecure stuff (file uploads) to a separate domain
[17:05] guido_g nack
[17:05] guido_g pieterh: it doesen't work
[17:05] pieterh feel free to debate with the wikidot devs, they are pretty sure of their skills in this respect
[17:05] pieterh what doesn't work?
[17:05] kleppari pieterh: works now, thanks.
[17:05] pieterh ?
[17:06] kleppari i.e., anonymous users on zguide.zeromq.org
[17:06] kleppari oh, no, sorry
[17:06] guido_g w/ the damn cookies
[17:06] pieterh guido_g: anything different than zeromq.org?
[17:07] pieterh there's nothing special about this site afaics
[17:07] Samy sustrik, ping?
[17:07] guido_g i allowed the cookies for zeromq.org and the wikidot server
[17:07] guido_g but i'm not going to do that for every new site
[17:07] pieterh ah, well, allow them for *.zeromq.org and *.zeromq.com :-)
[17:08] pieterh why do you disallow them?
[17:08] guido_g i do not allow cookies generally
[17:08] pieterh well...
[17:08] kleppari pieterh: http://bitbucket.is/zguide.zeromq.org.png
[17:08] pieterh kleppari: thanks, I'll try it...
[17:09] pieterh unfortunately interactive websites kind of need stuff like that
[17:09] guido_g viewing a page is not interactive
[17:10] kleppari sorry, screwed up file ownership. the screenshot of unauthenticated zguide.zeromq.org should be ok now.
[17:10] pieterh kleppari, hang on, 30 seconds... I'll fix it, thanks for the screenshot
[17:11] pieterh can you try to reload the site please?
[17:11] pieterh ctrl-R
[17:11] kleppari like a glove
[17:11] kleppari thanks :)
[17:11] pieterh i didn't change anything, it was already working... :-)
[17:11] pieterh since 19:03 CET
[17:12] pieterh ok, kleppari I appreciate the heads up, kind of stupid to have a Guide no-one can read... :-)
[17:12] kleppari screenshot snapped at 17:06 GMT. Weird.
[17:12] kleppari you're welcome
[17:12] guido_g http://zguide.zeromq.org/chapter:3 <- missing
[17:12] pieterh guido_g, yeah, because Sustrik pointed out that parts of it were bogus
[17:13] pieterh i'm rewriting it
[17:13] pieterh as soon as i finish my pasta and wine
[17:13] guido_g and why this intermediate page when i click in "The Guide" from zeromq.org?
[17:13] pieterh you'd rather leap to chapter 1 right away?
[17:13] guido_g yes
[17:13] pieterh i mean when you get a book, you see the cover first...
[17:14] pieterh but ok, can be done...
[17:14] guido_g the link is named "The Guide"
[17:14] pieterh Yeah, not The Guide Chapter 1 :-)
[17:14] guido_g not "promotional intermediate page w/o content"
[17:14] pieterh hey, don't mock the promotional pages...
[17:15] guido_g only if you reduce the size of the ØMQ logo drastically
[17:15] pieterh delayed gratification...
[17:15] pieterh OMG don't touch the logo, it's sacred...
[17:15] guido_g btw, too much red makes aggressive :)
[17:15] pieterh ok, the link from the sidebad should now go straight to the first chapter
[17:16] guido_g nope
[17:16] guido_g ok, i'll wait
[17:17] pieterh guido_g, when you say "nope" you mean as in "oops, I didn't reload it and HTTP doesn't yet have a autoupdate function"...?
[17:17] guido_g pieterh: no, it means "i pressed relaod like maniac but the thing didn't work"
[17:18] pieterh works for me...
[17:18] pieterh go back to www.zeromq.org
[17:18] pieterh are there more links? I fixed the one in the sidebar
[17:18] pieterh what one are you clicking on?
[17:18] guido_g i am on zeromq.org and open the link in another tab
[17:19] guido_g after reloading the page
[17:19] pieterh shrug...it's correct... you are reloading zeromq.org?
[17:19] guido_g yes
[17:20] guido_g hmmm... cdn thing maybe
[17:20] pieterh did you sacrifice a chicken to the gnomes of the Internet?
[17:20] guido_g ahhh... i constantly miss this one (eating the chicken myself)
[17:21] pieterh might be some caching somewhere your side of things
[17:21] pieterh it's correct, anyhow, just tested again
[17:21] guido_g ahhh... cdn got the update
[17:21] kleppari you might also be clicking different links?
[17:21] guido_g no
[17:22] kleppari the sidebar link points to chapter one, the other guide links point to the 'promotional' page
[17:22] guido_g so remember, it might take approx. 5 minutes til changes become vsisible
[17:22] kleppari two of them, one under most popular, other in recent site changes
[17:22] pieterh ah, kleppari, right
[17:23] kleppari but.. After a little while I like the promotional page
[17:23] pieterh well, indeed, a book deserves a cover
[17:23] pieterh bright red
[17:24] pieterh anyhow, this is always a work in progress, i like to see how people respond over time before making more changes
[17:24] kleppari I didn't get it at first though, started at zeromq.com -> hit read the manual -> clicked 'ØMQ - The guide' -> got to zguide.zeromq.org
[17:24] guido_g pieterh: you're on a laptop?
[17:25] kleppari didn't catch the differences between zguide.zeromq.org and zeromq.com right away
[17:25] pieterh guido_g, on a laptop with a 2G phone modem, eating pasta in a hotel
[17:25] guido_g it'S more about the display size
[17:25] kleppari sounds like a crap hotel :P
[17:25] pieterh kleppari, it's a pretty amazing hotel actually, an old Soviet relic
[17:26] pieterh guido_g, yes, laptop display
[17:26] guido_g pieterh: because on my 13" display the logo takes up apporx. 1/3 of the vertical space
[17:26] guido_g which is way to much, imho
[17:27] guido_g worse if i zoom in for better readability
[17:27] pieterh guido_g, yes, on mine too but it doesn't matter on the cover page, and hardly matters on the content pages since you need to scroll anyhow
[17:27] kleppari looks good on 1280x1024
[17:27] pieterh we tried using a smaller logo some time ago, people felt it wasn't nice
[17:28] kleppari pieterh: and no rj45 jack? URL? :)
[17:28] guido_g ok, i give up
[17:28] pieterh kleppari, URL? no rj45, no, wifi but it's too slow
[17:28] kleppari url of the hotel website? or is it too much of a relic?
[17:28] pieterh guido_g, do start a discussion on look and feel, but this isn't the place IMO
[17:29] pieterh guido_g, the original look was designed by a proper artist, and anything that replaces it would have to be done carefully
[17:29] pieterh kleppari, it's the Hotel Kyjev in Bratislava
[17:30] guido_g pieterh: i didn't complain about the logo, only it's size, but nevermind i'll find a solution
[17:30] pieterh guido_g, I do agree the logo is HUGE but my previous attempts to downsize it failed
[17:31] guido_g ok
[17:32] pieterh guido_g, what might work is a lighter theme for sites other than the Start Here site
[17:32] pieterh now that we have more sites, we can fine-tune them
[17:38] guido_g except for the "promo" pages the focus should be on readability