ZeroMq IRC Log

Tuesday August 31, 2010

[Time] Name	Message
[05:19] CIA-20	zeromq2: 03Martin Sustrik 07master * rf5acbb5 10/ (13 files): naming cleanup: zmq_encoder->encoder, zmq_decoder->decoder - http://bit.ly/bDJmD7
[06:53] poswald	greetings everyone! Does anyone know of a zeromq based task scheduler written in python?
[06:54] poswald	or maybe can someone explain to me if celery with zmq is a viable option?
[06:57] keffo	I looked at it, and I cant see why not?
[06:57] keffo	celery seems agnostic to the transport, so try it
[07:14] poswald	The zeromq site mentioned dropping support because of patents somewhere... let me try to find it
[07:15] poswald	oh it's on the faq http://zeromq.wikidot.com/area:faq
[07:16] poswald	"Does ÃMQ support AMQP protocol? It used to. The feature was dropped to protect ÃMQ users from infringement on AMQP-related patents."
[07:16] poswald	I assumed that Celery+ZMQ would be over AMQP protocol
[07:48] sustrik	poswald, you may want to try 0mq/amqp bridge
[07:53] poswald	I wonder if it makes sense for me to build something a little more minimal on top of zeromq rather than bridge over to amqp
[08:08] sustrik	you can try, why not
[08:12] poswald	do you know if zeroMQ has any plans for supporting persistent queues?
[08:13] pieterh	poswald: not in 0MQ core but probably one day as a layer on top
[08:43] keffo	lol, printing msg data can have funny sideeffects, such as a pcspeaker beep :)
[08:58] theICEBear	I just posted a patch to the mailing list for the select.cpp file. Now I am running into an access violation on shutdown of my sockets (and no they've been allocated on the thread closing them). Is this a known issue I can ignore until 2.1 goes out?
[09:13] sustrik	theICEBear: is that trunk?
[09:15] theICEBear	I am using 2.0.8
[09:15] sustrik	that looks like an unknown issue
[09:16] sustrik	can you please report it as a bug?
[09:16] sustrik	having a backtrace attrached would be great
[09:17] theICEBear	I will hold off a little while yet to make sure I am not the cause my self first, but I will do so when I am sure.
[09:17] sustrik	ok
[09:18] theICEBear	btw is there a D language binding for zmq, because I might find the time to do one if there isn't
[09:21] sustrik	no, there isn't
[09:21] sustrik	theICEBreat: I am looking at your patch
[09:21] sustrik	what was the original problem?
[09:22] sustrik	the both versions look semantically equivalent
[09:22] theICEBear	the STL library in MSVC comes with something called SCL a security/verification thing that complains if you use the STL in an insecure unsafe way. The old code was triggering an assert through SCL
[09:22] sustrik	aah
[09:23] sustrik	that's something that haven't been there back when i've been using it
[09:23] theICEBear	but yeah I couldn't see anything wrong with the code either. But apparently doing it.begin() + 1 is not good.
[09:23] sustrik	that's MSVC2010?
[09:23] sustrik	i see
[09:24] sustrik	msvc2008 sp1
[09:24] theICEBear	nope MSVC 2008 sp1 (MSVC 2010 is too buggy for us and its 64-bit support is wrong)
[09:24] sustrik	ok, let me apply it
[09:24] sustrik	ugh, i cannot :(
[09:24] theICEBear	what did I do wrong now?
[09:25] theICEBear	;)
[09:25] sustrik	waiting for mato to finish the check-in process
[09:25] theICEBear	aah
[09:25] sustrik	pieterh: what so you think?
[09:25] sustrik	are we going to maintain 2.0 or will we move to 2.1?
[09:26] sustrik	if the latter i can just ignore the 2.0 and simply commit it to 2.1
[09:28] mato	sustrik: it's actually about "are you willing to maintain 2.0, with the help of the community"
[09:29] sustrik	i am
[09:29] mato	sustrik: all the process i have in mind does is it forces you to make that decision, and it ensures that any fixes in 2.0.x are also propagated correctly to master
[09:30] sustrik	sure, np
[09:30] mato	sustrik: in other words, all fixes are forward-ported, but the converse is not necessarily true; that decision must be made by the person commiting the fix on a case by case basis
[09:30] sustrik	mato: yes
[09:31] mato	sustrik: sorry for not giving you more detail, but i'm still stuck on this *%^$#^# problem for a client :-(
[09:31] mato	sustrik: i guess it would be best if we sat down together at some point, went thru a bunch of 2.0.x and 2.1.x pending fixes with the process and made notes
[09:32] mato	since you asking "what does this do?" or "what do i do now" is better than me trying to anticipate those questions :)
[09:32] sustrik	depends how long it'll take to get that done
[09:32] sustrik	if a long time, let's rather forget about maintaining 2.0
[09:33] mato	take what done?
[09:33] sustrik	the process guideliones
[09:33] pieterh	sorry... was busy...
[09:33] mato	sustrik: it needs a day together at the table
[09:33] pieterh	we will maintain 2.0, of course, that's the stable version
[09:33] mato	sustrik: or even half a day
[09:34] pieterh	people are using 0MQ in production and we cannot make them choose between an unmaintained stable version and a maintained unstable version
[09:34] pieterh	they will think we're idiots :-)
[09:34] mato	sustrik: random question; have you seen any issues where a PUB socket was not getting messages even though it was connected and subscribed?
[09:35] sustrik	no
[09:35] sustrik	have you checked whether actual TCP connection exists?
[09:35] mato	yes
[09:35] mato	exists
[09:35] sustrik	good
[09:35] sustrik	do the data cross the wire?
[09:35] mato	but it seems like 0mq is not sending anything down that particular pipe
[09:36] sustrik	so it's PUB issue
[09:36] mato	yeah
[09:36] sustrik	any chance to reproduce?
[09:36] mato	not with a simple test case at the moment
[09:36] mato	but it's definitely reproducible
[09:37] sustrik	mato: you are at your place?
[09:37] mato	sustrik: yup
[09:37] sustrik	ok, let me have a look at it in person
[09:37] mato	that would be a great help :)
[09:37] mato	maybe you'll see something obvious i'm not ...
[09:38] pieterh	mato: did you already see if the SUB properly announces itself at startup?
[09:38] pieterh	to the PUB socket
[09:38] mato	no, am going to try that
[09:38] pieterh	that's pretty vital to find out
[09:39] pieterh	just printf in PUB socket when it gets identity from SUB
[09:45] mato	pieterh: That's an interesting idea, I'm curious to see how you implement it :-)
[09:45] pieterh	lol, very good
[09:45] mato	anyway, looing at what tcp_listener_t is doing is a start
[09:49] mato	sustrik: what is the process when a new TCP connection is accepted on a PUB socket?
[09:49] mato	sustrik: tcp_listener_t is obviously involved, what then?
[09:49] mato	sustrik: the last step would be pub_t::xattach_pipes?
[09:50] sustrik	let me see
[09:52] sustrik	well, it creates the zmq_init object
[09:52] sustrik	and launches it (possibly in a different i/o thread
[09:52] sustrik	you see 2 commands at the end here:
[09:52] sustrik	send_plug (init);
[09:52] sustrik	send_own (owner, init);
[09:53] sustrik	send_plug sends a command to the init object saying "start working in the context of your new I/O thread"
[09:53] sustrik	send_own is sent to the owning socket
[09:53] sustrik	(which resides in the application thread)
[09:54] sustrik	saying "you are owner of this init object; you are responsible for closing it"
[09:54] mato	what i'm seeing looks like the TCP connection is accepted, but no pipe ends up being attached on the socket
[09:54] mato	i should have 3 pipes, i only see two (pipes.size() / active == 2)
[09:54] sustrik	are there identities exchanged?
[09:55] mato	where can i trace that on the 0mq side?
[09:55] sustrik	zmq_init_t
[09:55] sustrik	zmq_init.cpp:151
[09:55] sustrik	(v2.0.8)
[09:56] sustrik	that's the point where the identity is both sent to the peer and received from the peer
[09:58] mato	what creates the zmq_init_t?
[09:58] sustrik	zmq_listener_t
[09:58] sustrik	or zmq_connecter_t
[09:58] mato	good, listener in this case
[09:58] mato	ok
[12:20] mato	sustrik: ping!
[12:20] mato	sustrik: got it
[12:20] mato	sustrik: sudden inspiration...
[12:20] mato	sustrik: the zmq code is all correct...
[12:20] mato	sustrik: but, i don't close sockets (because of blah blah....)
[12:21] mato	sustrik: so, why would a socket start to get ignored
[12:21] mato	sustrik: i added an assert to zmq::select_t to check if we're trying to add more than FD_SETSIZE sockets
[12:21] mato	sustrik: and bang....
[12:22] sustrik	mato: pong
[12:22] sustrik	aha
[12:22] sustrik	64 limit
[12:29] mato	sustrik: ok i will discuss with PH what to do... in any case, 2.0.x and 2.1 need to get that assertion in there
[12:30] mato	i will handle that
[12:30] mato	people should at least know if they're hitting that limit
[12:30] sustrik	ack
[12:30] mato	further, ZMQ should redefine FD_SETSIZE to 1024 on windows which at least makes it able to handle more than 64 sockets
[12:30] mato	i'll take care of those two fixesa
[12:31] mato	and will get you those workflow commands ASAP, but need something quick for the client now
[12:31] pieterh	2G mobile internet...
[12:31] pieterh	someone calls you, Internet dies...
[12:32] pieterh	Xitami used to set FD_SETSIZE to 1024 on Windows, since 1996 or so
[12:32] pieterh	mato: in prelude.h, it's ancient code
[12:35] keffo	pieterh, sustrik; Up for some discussion?
[12:35] keffo	I have (basically) two ideas, that would help me tremendously, open the api a bit (while retaining current functionality)
[12:36] keffo	A: Make xreq able to do what xrep does now, ie send down a known route (with supplied identities), and B; custom LB
[13:15] mikko	sustrik: i might be in london on 14th!
[13:15] sustrik	mikko: great!
[13:15] mikko	do you know roughly in which area you are going to be?
[13:16] sustrik	in the very center
[13:16] mikko	i work very close to tottenham court road tube station
[13:16] sustrik	let's see whether more people are interested
[13:17] mikko	are you coming for work or holiday?
[13:17] sustrik	work
[13:17] sustrik	i just though that quite a few people on mailing list may be located there
[13:18] sustrik	let's see
[13:41] fredix	hi
[13:41] sustrik	hi
[13:41] fredix	is there a zmq_server with zeromq 2 ?
[13:42] sustrik	no
[13:42] sustrik	where have you found reference to it?
[13:42] fredix	in tutorials http://www.zeromq.org/tutorials:_start
[13:43] sustrik	ugh, these are outdated
[13:43] sustrik	back from version 1.0
[13:43] sustrik	pieterh: why have you put these online?
[13:43] fredix	in fact I'm looking for a queue server like gearman or beanstalkd, and zeromq seems to be cute
[13:43] sustrik	depends on what you need
[13:44] sustrik	there are "mini-servers" in 0mq
[13:44] sustrik	called "devices"
[13:44] sustrik	say a stand-alone queue
[13:44] sustrik	but nothing as complex as real messaging server
[13:44] sustrik	with all the admin stuff, monitoring etc.
[13:44] fredix	I need make asynchronous job and a persistance server queu
[13:44] fredix	queue
[13:45] sustrik	sorry, no persistence
[13:45] fredix	arg
[13:45] sustrik	if you want to experiment you can use 0mq clients with RabbitMQ server
[13:45] sustrik	there's a bridge project
[13:45] sustrik	but it's not yet stable
[13:46] fredix	ok
[14:05] alfborge	sustrik: Persistant queues, does that mean that the messaging system guarantees that the message is delivered if the client succeeds in writing the message to the queue?
[14:05] alfborge	Or is there more to it?
[14:06] sustrik	"persistent queue" means that messages are written to the disk
[14:06] sustrik	and that messages are read from the disk when queue is started
[14:06] sustrik	however, there are no additional reliability guarantees
[14:07] alfborge	So the point is that you can reboot the system without loosing messages in the queue?
[14:08] sustrik	yes, that's what "persistent queue is for"
[14:08] sustrik	you can still loose messages on the wire
[14:08] sustrik	messages processed in the clients
[14:08] sustrik	etc.
[14:22] Steve-o	there is a significant performance difference between persistent messaging and guaranteed messaging, most people really don't need the latter or can get away with database light weight transaction managment
[15:00] andrewvc	cremes, I was wondering if you were around
[15:01] andrewvc	I've got a zmqmachine question I was hoping you'd answer
[15:01] cremes	yeah, but i'm at work so i have limited time; what's up?
[15:02] andrewvc	well if you don't have time to answer that's cool http://github.com/andrewvc/learn-ruby-zeromq/blob/master/003_ZMQMachine/002_a_pub_sub_example.rb#L28
[15:02] andrewvc	sleeping there is bad right, since we're in a reactor
[15:02] cremes	yes, you should never sleep
[15:02] cremes	what are you trying to accomplish with that sleep?
[15:02] andrewvc	but on_writable acts as a busy loop w/o that. Changing the poll interval doesn't seem to help
[15:02] cremes	ah, good point
[15:03] cremes	i have a little pattern that i follow when using the reactor
[15:03] andrewvc	do you just register / dereister it
[15:03] andrewvc	oh, what is it?
[15:03] cremes	let me pastie something for you... hang on a few
[15:03] andrewvc	awesome
[15:07] cremes	andrewvc: try this technique: http://gist.github.com/559166
[15:07] cremes	this is why i added register_writable/deregister_writable to the Reactor class
[15:07] cremes	i ran into that exact same problem; this technique cures it
[15:08] cremes	of course, you could write directly to the socket and not use the #on_writable callback at all if you choose
[15:08] andrewvc	cool, thanks, I'll put that in
[15:08] cremes	np
[15:08] andrewvc	hmmm, so I can just leave on_writable undefined as well?
[15:09] cremes	for certain socket types you can; for others the framework enforces it
[15:09] andrewvc	like req/rep?
[15:09] cremes	you could just stub it out like this... def on_writable(socket); @reactor.deregister_writable(socket); end
[15:09] andrewvc	oh, gotcha
[15:09] cremes	assuming you have a @reactor instance var
[15:09] andrewvc	yep, got one
[15:10] cremes	i tried to make the defaults sensible (convention over configuration) but it's still early in zmqmachine's life
[15:10] cremes	perhaps i chose the wrong defaults; feedback would be nice
[15:10] andrewvc	definitely
[15:11] cremes	ping me if you need anything more
[15:11] andrewvc	i actually hit some weird bugs with deregister last night (probably my mistake, but needing some better err handling), that I had trouble debugging at 11:30pm :), I'm going to give it a shot today, see what happens.
[15:13] andrewvc	ah, hit it just now
[15:14] andrewvc	I'll open an issue on github
[15:38] cremes	andrewvc: pushed new gems for ffi-rzmq and zmqmachine; i fixed a bunch of bugs but then forgot to run "gem push" to upload them to rubygems
[15:38] cremes	these new releases should fix that issue you reported
[15:38] andrewvc	ah, sweet, yeah hehe, events / event
[15:39] andrewvc	thanks!
[15:39] andrewvc	also, now I don't need to bundle the latest ffi-rzmq with learn-zeromq-ruby, which will be nice
[15:40] cremes	yep
[15:41] cremes	plus, there will be a new ffi gem released soon... i've been bugging the author to get one out so folks don't have to build master by hand
[15:43] andrewvc	yeah, that'll be great, it's time
[16:00] pieterh	keffo: sorry, was away for a while
[16:03] keffo	As was I, dozed off on the couch for halv an hour :)
[16:04] pieterh	the last thing I saw from your was "A: make xreq able to do what xrep does now..."
[16:16] cremes	pieterh: is your chicago visit connected to that financial firm i hooked you up with a few months back?
[16:18] pieterh	cremes: yes, probably
[16:18] pieterh	let me check if it's the same one
[16:19] pieterh	cremes: yes :-)
[16:24] cremes	cool... hopefully they'll open the talk to the public (though i know the cio so i'm sure i could come to it anyway...)
[16:26] pieterh	yeah, but I doubt they'll have a bar
[16:27] pieterh	so... i've been working on a new site for 0MQ beginners
[16:28] pieterh	it's going to be www.zeromq.com
[16:28] pieterh	so that the existing .org site can become a real community portal/map
[17:00] keffo	pieterh, Sorry, gf came home upset due to crappy boss behaviour..
[17:01] keffo	pieterh, So, having xreq capable of providing a route, the same way xrep does
[17:10] pieterh	keffo: why do you need this, what's your use case?
[17:18] keffo	To reach a specific queue, so it can nuke it's worker processes, for instance
[17:18] keffo	N queue-steps down, so to speak :)
[17:19] keffo	Also, why is there no send_to_identity()? :)
[17:20] pieterh	keffo: I guess a send-to-identity could be put into layers above the API, such as ZFL or any language binding
[17:20] pieterh	though since identity is actually a stack it's perhaps not that simple
[17:20] pieterh	you can use XREP to reach a specific node
[17:21] keffo	hum?
[17:21] pieterh	if you are willing to disassemble, reassemble the stack you can use XREP to talk to XREP
[17:21] pieterh	as far as I understand it, I've not tried this myself
[17:21] keffo	I already do that now to route back, I just dont see any reason that shouldnt work the other direction?
[17:21] pieterh	i mean, why change XREQ's behaviour when XREP is what you want...?
[17:22] pieterh	the names for XREQ and XREP don't make too much sense in fact
[17:22] pieterh	what these are, is a SEND socket and a ROUTE socket or something like that
[17:22] keffo	That doesn't make sense, I can initiate with a reply? =)
[17:23] pieterh	XREP is not really a reply (only) socket
[17:23] keffo	But I get what you mean
[17:23] pieterh	that's just its obvious use case
[17:23] pieterh	but replies are just one use case for explicitly addressed messages
[17:24] pieterh	i feel we need to find better names, as we did for push/pull
[17:24] keffo	Hum, so in theory they could be consolidated into one type, like sendrouted( route, msg )?
[17:24] pieterh	well, no
[17:24] pieterh	XREQ is exactly the same as PUSH but within the req-rep pattern
[17:25] pieterh	where as XREP is like PUSH with the addition of routing capability
[17:25] pieterh	uhm, sorry
[17:25] keffo	sure, but why cant xreq handle the routing in the same way as xrep does?
[17:25] pieterh	XREP is like PUSH+PULL together
[17:25] sustrik	:)
[17:25] pieterh	all you're asking is "please delete XREQ socket type"
[17:26] pieterh	right?
[17:26] pieterh	kurva
[17:26] pieterh	XREQ is like PUSH+PULL, XREP is like PUSH+PULL+routing
[17:26] sustrik	i think what keffo wants is goodies from 0mq without having to conform to strictly defined patterns
[17:26] keffo	Not really, I want to be able to supply a route to xreq, in the same way I do to xreq... Essentially bypassing any loadbalancing I guess
[17:27] pieterh	sustrik: is my assertion that "XREQ is like PUSH+PULL, XREP is like PUSH+PULL+routing" valid?
[17:27] sustrik	yes
[17:28] sustrik	keffo: the problem is that you don't know the route
[17:28] sustrik	the only point where you get the route is when you get a request in REP socket
[17:28] sustrik	you would have to hardcode the routes
[17:29] keffo	if I have a client that sends a message through 2-3-4 hops of queue goodness to reach a worker, I'd like to be able to traverse that same path again
[17:29] keffo	I guess this is a hack to get around the pub/sub subscriber overhead
[17:29] keffo	sustrik, I do know the route :)
[17:29] pieterh	sustrik: can you set identities explicitly, send them via another flow, and then use XREP to address them?
[17:29] keffo	Ah, you mean the route is popped off as it goes, on a return xrep?
[17:29] pieterh	keffo: yes
[17:29] pieterh	xrep pops the top address, uses it to route the rest (on send)
[17:30] pieterh	and xrep pushes the incoming address (on recv)
[17:30] sustrik	which pieterh: imo, it's like wanting to send an IP datagram through a specific path
[17:30] pieterh	yeah, it's abuse of patterns
[17:30] sustrik	in theory doable
[17:30] keffo	I already explicitly name everything, so I'd like the end worker to send back "this is me, this is how I was reached, contact me here to get status", basically
[17:30] sustrik	but not wise
[17:30] pieterh	keffo: just use XREP
[17:31] pieterh	hang on... you want to re-route a request BACK to the same worker through a series of hops...?
[17:31] keffo	Yup
[17:31] pieterh	ok...
[17:31] pieterh	so here's the problem
[17:31] pieterh	you are mixing two different flows into one
[17:31] pieterh	it won't work smoothly
[17:31] keffo	Care to elaborate, because I really dont see why not..?
[17:31] pieterh	and when it works it'll be fragile and horrid
[17:32] pieterh	OTOH you have a workload distribution abstraction
[17:32] pieterh	that routes work to workers using various algorithms
[17:32] pieterh	workers can come, go, etc.
[17:32] pieterh	that is pattern A
[17:32] keffo	yep
[17:32] pieterh	next, you have peer to peer addressing between clients and workers
[17:32] pieterh	where you want to talk to workers specifically (bribery and corruption I assume)
[17:32] pieterh	that is pattern B
[17:32] keffo	yeah, although only to queues, but that's besides the point
[17:33] pieterh	they are not the same pattern and the 0MQ Way is to use one set of sockets per pattern / per flow
[17:33] pieterh	sockets are cheap
[17:33] keffo	But I cant see a good way to reach a specific node?
[17:34] pieterh	you perhaps want a broker in the middle
[17:34] pieterh	here are some random ideas to play with...
[17:34] pieterh	send endpoints in messages and get workers to connect back onto those endpoints (using REQ/REP)
[17:35] pieterh	use broker to act as hub, turn the whole thing into boring hub / spoke architecture with a single fixed endpoint
[17:35] pieterh	construct your own message stacks via black magic and use XREP to route these
[17:37] keffo	nn
[17:37] keffo	mm
[17:37] pieterh	:-)
[17:38] keffo	I'm content to do heartbeating between local queue & worker processes (all localhost), but I'd rather be able to query status off that queue at will
[17:39] keffo	I know exactly how I reached that queue from the response, so I figured it would be a pretty decent solution if I could just supply that same route and ask about it's status whenever I want..
[17:39] keffo	(the first using pub/sub)
[17:49] pieterh	IMO if you want health monitoring, you want a specific socket flow for that
[17:56] keffo	Adding another socket flow, while the first one is completely idle, doesn't really sound like a proper solution to me :)
[17:59] pieterh	it's not about idle or not, but about using sockets in the way nature (and Sustrik) intended
[18:01] keffo	So what health monitoring system would fit then?
[18:01] keffo	I cant pub/sub across the whole system right now, and the endpoints cant connect directly to the source
[18:01] pieterh	well... what seems to be the best practice is to build a heartbeat flow separately from data and work flow
[18:01] keffo	Also, I need the ability to nuke a runaway process, for instance
[18:02] keffo	sure, an admin-channel sortof
[18:02] pieterh	i'm hoping eventually heartbeating would go into sockets as standard but that's not clear how or if
[18:02] pieterh	yup, a control/admin channel
[18:03] sustrik	yes, the heartbeating is a tricky stuff
[18:04] sustrik	if you think about it in depth, it looks like the only real use case for it is guaranteed delivery
[18:04] sustrik	which is an insolvable problem in itself
[18:04] pieterh	"unsolvable" assumes the goal is "perfectly solvable", which it isn't
[18:05] pieterh	the goal is "good enough", and that's solvable
[18:05] sustrik	unsolvable by technical means
[18:05] pieterh	i pay fedex for guaranteed delivery but packages still get lost in customs sometimes
[18:05] sustrik	yes, good analogy
[18:05] pieterh	it's solvable if you are willing to accept some failures and be able to detect and recover from them
[18:06] pieterh	which in effect solves it
[18:06] pieterh	fedex will resend
[18:06] keffo	the whole point I'm tryijng to make is, I get both of those for free with what I already have, given the ability to direct the route downwards as well as upstream
[18:06] pieterh	customs may continue to snag the packages but eventually one will get through
[18:06] pieterh	keffo: so you don't have any problem them? :-)
[18:07] pieterh	keffo: routing downwards means constructing that address stack
[18:07] pieterh	that's unavoidable
[18:07] pieterh	it's not something you can delegate to a socket and magic will happen
[18:07] pieterh	xrep only knows how to do it because the message got routed that way to start with
[18:09] pieterh	you could somehow send that address stack BACK to the client so it can use it to route downwards
[18:10] pieterh	but now if your infrastructure changes at all, you're dead
[18:10] pieterh	it's like sending email to someone and trying to specify all the intermediate servers
[18:44] ModusPwnens	hi
[18:55] ModusPwnens	does anyone know what would cause an enormous drop in performance with zeromq?
[18:56] pieterh	ModusPwnens: what OS?
[18:56] pieterh	and do you have a simple reproducible case?
[18:56] ModusPwnens	i have some code I could put on a pastebin
[18:56] ModusPwnens	and its windows 7
[18:57] ModusPwnens	this problem has afflicted me several times though. I am trying to do benchmark testing with code I have, but when I try to write it using the examples as a reference, I get a pitiful 12 messages per second
[18:57] ModusPwnens	when I essentially copy line for line the example code, I get the normal amount, which is about 600,000 messages per second
[18:57] pieterh	we've seen something similar recently
[18:58] ModusPwnens	I feel like its just user error on my part
[18:58] ModusPwnens	since I am new to zeromq
[18:58] pieterh	but it was inside a complex case and not obvious to identity
[18:58] ModusPwnens	so I must be missing something important
[18:58] pieterh	what I suggest is starting with the examples, literally
[18:58] ModusPwnens	Yeah i've combed through them
[18:58] ModusPwnens	I did the hello world example just fine
[18:58] pieterh	and then test every time you change something
[18:59] pieterh	what language?
[18:59] ModusPwnens	c++
[18:59] ModusPwnens	although I am using the c language bindings
[18:59] ModusPwnens	because that's what the examples are in
[18:59] pieterh	sure
[18:59] pieterh	well... what would I do... stupidly...
[18:59] ModusPwnens	hmm?
[19:00] pieterh	profile the code and see what it's actually doing
[19:00] pieterh	insert printf statements, capture in file
[19:00] pieterh	remove whole chunks until it works 'normally' and then see what the significant difference i
[19:00] pieterh	*is
[19:01] pieterh	finally if you get to a minimal testcase you are sure should work, but does not, report it
[19:01] ModusPwnens	well no it's not that. It works. It's just really slow.
[19:01] pieterh	sure
[19:01] pieterh	and CPU is probably really high
[19:01] pieterh	so it's doing _something_ unexpected
[19:01] pieterh	not sleeping
[19:02] pieterh	i gotta go, sorry, but i'm curious to know what the outcome is...
[19:03] ModusPwnens	Hmm. The benchtesting I am doing is to test performance with google protocol buffers. So in the loop I am encoding messages and storing them into messages, but would that really cause something as low as 12 messages per second...?
[19:03] ModusPwnens	oh ok.
[19:03] ModusPwnens	I will let you know what it was when i figure it out
[19:09] Steve-o	of course not, but you can also try #defing out the protobuf code to see if it changes performance
[19:22] CIA-20	zeromq2: 03Martin Sustrik 07master * r090e460 10/ (10 files): naming cleanup: yarray->array - http://bit.ly/cQUTl0
[23:53] ModusPwnens	hi