| [Time] Name | Message |
|
[02:08] quentusrex
|
I don't see any documentation on the wiki for subscriptions
|
|
[02:09] quentusrex
|
I see a reference to it here: http://api.zeromq.org/zmq.html 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:55] sustrik
|
Guthur: ZMQ_SUBSCRIBE/ZMQ_UNSUBSCRIBE
|
|
[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/ZMQ.java : Made Poller constants POLL{IN,OUT,ERR} into public. - http://bit.ly/eRnY5q
|
|
[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: https://github.com/imatix/zguide/blob/master/examples/Java/mtserver.java
|
|
[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)
|
