Tuesday November 23, 2010

[Time] NameMessage
[02:08] quentusrex I don't see any documentation on the wiki for subscriptions
[02:09] quentusrex I see a reference to it here: but no page about it.
[03:08] josh What service does the context provide?
[03:08] josh Working on a wrapper and just wondering if there's a practical way to elide the context creation
[04:52] quentusrex Anyone know if there is work on a server side subscription for the pub/sub ?
[04:52] quentusrex so that bandwidth usage is reduced?
[06:54] sustrik josh: context holds all the global variables
[06:55] sustrik if your language supports a native mechanism for a libraries to hold two separate sets of global variables when a library is initialised twice, use that instead of contexts
[06:56] sustrik quantusrex: there have been couple of threads about server-side subscriptions ("subscription forwarding") on the mailing list
[06:56] sustrik check the archives
[07:04] travlr how's master running for others? I'm getting an assert failure now with send(..).
[07:10] travlr oops, i mean zmq_send(...)
[07:11] sustrik travlr: mostly it works ok
[07:11] sustrik what's the assert?
[07:13] travlr i'm using zhelpers.h which raises an assert with the return from the call to zmq_send(...)
[07:13] travlr up to date master
[07:13] sustrik what assert?
[07:14] travlr Assertion `!rc' failed
[07:14] sustrik probably a bug in zhelpers.h
[07:14] travlr hmm, ok. i'll lose it.. thanks.
[07:15] sustrik the thing is 0MQ returns an error
[07:15] sustrik which is ok
[07:15] sustrik it doesn't fail or something
[07:15] travlr right let me see what the call actually returns then..
[07:15] sustrik ack
[07:15] travlr thanks again
[07:48] Guthur sustrik, ping
[07:49] sustrik pong
[07:49] Guthur Did you see that ticket raised regarding ruleset serialization in clrzmq]
[07:50] Guthur I was just going to tell him briefly it's not a clrzmq issue, sound ok?
[07:50] Guthur and close the ticket
[07:50] sustrik no point in doing other people's homework, just point him to the guide
[07:50] sustrik and close the ticket
[07:51] Guthur ack
[07:51] travlr martin, the assert was somehow my mistake.. sorry for disturbing you for nothing.. it seems
[07:55] sustrik ok
[09:17] mikko good morning
[09:48] sustrik morning
[11:38] migmir hello everyone
[14:45] Guthur I want to request a limited stream of data, what would be decent strategy?
[14:46] Guthur The scenario is that multiple client will come along and request a stream of data for a period of time then stop
[14:46] Guthur sorry stream is not really the right description
[14:47] Guthur it will be a set of updates at non-deterministic intervals
[14:51] lantins REQ/REP? guess it would depend on what kind of interval your looking at
[14:56] sustrik or simply close the socket when you don't want to receive more updates
[14:59] CIA-20 jzmq: 03Gonzalo Diethelm 07master * r431fb23 10/ src/org/zeromq/ : Made Poller constants POLL{IN,OUT,ERR} into public. -
[15:07] Guthur I will investigate those options, really need to prototype I suppose
[17:28] Guthur is there a nice way to make the last message on a publisher persistent
[17:28] Guthur So that if a subscriber comes along later it will receive that last message
[17:31] sustrik Guthur: what you want is last value cache afaiu
[17:32] sustrik it has to be built on top of 0mq
[17:33] Guthur sustrik: I was thinking might have to be
[17:34] Guthur would one just publish every tick
[17:34] Guthur ie some arbitrary time interval
[17:35] sustrik in that case most subscribers would get the same message multiple times
[17:35] sustrik every second or so, depending on the interval
[17:35] sustrik i would probably go for using 2 sockets
[17:35] Guthur umm yeah, then I would need a timestamp or something
[17:36] Guthur yeah 2 sockets was my other thought
[17:36] sustrik PUB/SUB for bradcasting the feed
[17:36] sustrik REQ/REP for asking for a last snapshot
[17:36] Guthur ok, cheers sustrik
[17:38] Guthur back in a bit
[18:40] Guthur sustrik, With the discussion earlier can the pub/sub and req/rep, both go through the same port?
[18:41] sustrik no, you cannot bind two sockets to the same port
[18:54] Guthur wishful thinking
[19:46] tupshin1 what do I need to get device support in java? I built the bluig forg of jzmq, but I get an unsatisfiedlinkerror for ZMQ$Device.construct
[19:46] tupshin1 s/forg/fork/
[20:01] tupshin1 alternatively, is there a good way of implementing a multi-threaded java zmq server that doesn't use device? as opposed to this one:
[20:04] tupshin1 scenario is that i'm looking to build a multi-threaded java daemon that is able to listen for messages from many different processes, and respond to whichever process sent it a message. can't seem to find a good/working jzmq pattern for this.
[20:08] tupshin1 bah...nm. mismatch between my jzmq jar and libs. got it. :)
[21:31] josh So, I'm working on a completely managed build of zmq (compiled with very small changes using MS C++/CLI)
[21:31] josh Has anyone messed with doing something like this yet? I don't want to repeat someone elses work...
[21:48] tupshin1 is IPC generally the fastest way to use zeromq to pass messages between processes on linux? (php and java in this case)