| [Time] Name | Message |
|
[07:08] jsimmons
|
is there a way to change the hwm policy of a socket? specifically change XREQ to drop on hwm rather than block?
|
|
[07:09] guido_g
|
no
|
|
[07:10] jsimmons
|
is there a reason for this inability, like my architecture being fundamentally flawed?
|
|
[07:39] sustrik
|
jsimmons: why would you want that kind of thing in the first place?
|
|
[07:45] jsimmons
|
I'm not really sure thinking about it, but something like the backlock becoming rapidly stale such that servicing old requests serves no purpose
|
|
[07:46] jsimmons
|
that's not really just an issue of hwm handling though
|
|
[07:47] jsimmons
|
backlog* too
|
|
[07:54] sustrik
|
hm, why not set low HWM then?
|
|
[07:55] sustrik
|
at the beginning
|
|
[07:59] jsimmons
|
I suppose you're right, the handling of meeting the hwm in this case only varies the age of the oldest in the queue
|
|
[07:59] jsimmons
|
s/oldest/newest
|
|
[08:01] jsimmons
|
and if you're hitting the hwm you're in trouble anyway :)
|
|
[16:33] mikko
|
good eveving
|
|
[16:33] mikko
|
hmm, such a simple thing
|
|
[16:33] mikko
|
retry: good evening
|
|
[16:33] sustrik
|
hi
|
|
[16:34] pieterh
|
hi sustrik
|
|
[16:42] sustrik
|
pieterh_L hi
|
|
[16:42] mikko
|
sustrik: the freebsd box should give you access to kqueue right?
|
|
[16:43] sustrik
|
yep
|
|
[16:43] sustrik
|
i've tried it this morning
|
|
[16:43] sustrik
|
it works
|
|
[16:44] sustrik
|
unfortunately i have to finish the article for aosabook till day after tomorrow when i'm leaving for kyiv
|
|
[16:44] mikko
|
i've been thinking about getting one of those mac minis at home
|
|
[16:45] mikko
|
and use that for builds when it's idle
|
|
[16:45] sustrik
|
if it's reproducible on freebsd
|
|
[16:45] sustrik
|
then there's no need for mac
|
|
[16:45] mikko
|
mac would be nice in the longer run
|
|
[16:45] mikko
|
as a lot of devs use macs
|
|
[16:46] sustrik
|
sure
|
|
[16:46] sustrik
|
i don't know how much a problem is adding it into the build env
|
|
[16:46] sustrik
|
you probably can't run osx on a virtual box
|
|
[16:46] mikko
|
should be relatively easy
|
|
[16:46] mikko
|
nope, i dont think virtualbox would work
|
|
[16:47] mikko
|
https://lkml.org/lkml/2011/10/6/317
|
|
[16:47] mikko
|
this was interesting regarding virtualbox
|
|
[16:47] sustrik
|
i see
|
|
[16:48] sustrik
|
seen that one :)
|
|
[16:48] sustrik
|
anyway, i'm back on tuesday next week
|
|
[16:48] sustrik
|
i can have a look at the problem on wednesday
|
|
[16:50] mikko
|
cool
|
|
[16:56] pieterh
|
sustrik: did you see https://zeromq.jira.com/browse/LIBZMQ-271?
|
|
[16:57] pieterh
|
looks like 0MQ stops receiving at some point, for unknown reasons
|
|
[16:57] mikko
|
this is the zynga one?
|
|
[16:58] mikko
|
pieterh_: openpgm should be updated before next 2.1 release
|
|
[16:58] pieterh
|
yes
|
|
[16:58] mikko
|
steven fixed the silent rules and building on solaris10 using solstudio12.2
|
|
[16:58] mikko
|
there are also some build failures related to timers on freebsd
|
|
[16:59] mikko
|
not sure if this is vmware issue or OS difference
|
|
[16:59] pieterh
|
mikko: they're not using PGM here
|
|
[16:59] mikko
|
pieterh: Assertion failed: (elapsed > 440000 && elapsed < 550000), function main, file test_timeo.cpp, line 73.
|
|
[16:59] mikko
|
this one
|
|
[17:00] mikko
|
on 3.0
|
|
[17:01] pieterh
|
more than normal, even
|
|
[17:03] mikko
|
pieterh: theres also a couple of fixes which would be nice to have in 2.1.11
|
|
[17:04] mikko
|
assuming there is a sensible fix available
|
|
[17:05] mikko
|
LIBZMQ-264 is one
|
|
[17:06] mikko
|
bbl ->
|
|
[17:25] sustrik
|
pieterh_: yes, seen it, looks like a bug
|
|
[20:01] cremes
|
as a hobby project, i am thinking of implementing a FIX engine (in Ruby)
|
|
[20:01] cremes
|
has anyone in channel ever written one before?
|
|
[20:16] sustrik
|
cremes: there was such a blog somewhere...
|
|
[20:17] cremes
|
i probably found it... some useful nuggets but whoever wrote it wasn't much of a writer :)
|
|
[22:09] Brandon_R
|
hi guys
|
|
[23:41] streamer
|
I want to open up a completely asynchronous, persistent connection between two sockets, with a queue device in between. What config should I use? I currently have a [dealer] --- [router - router] ---[ dealer] setup, but I can't make the replies get routed back properly.
|
|
[23:55] minrk
|
You can't use router-router in a queue
|
|
[23:56] minrk
|
router prepends the identity of the sender to the message, so that it knows how to route the reply
|
|
[23:57] minrk
|
but that means that the second router forwarding the message will be sending to the original sender's identity
|
|
[23:58] minrk
|
If messages definitely initiate from one side, you can use [dealer] -- [router - dealer] -- [router]
|
