| [Time] Name | Message |
|
[01:16] ssi
|
hrm, I think I have a pattern I can use along the lines of pieterh's credit-based flow control
|
|
[01:16] ssi
|
if instead of PUSH/PULL sockets between nodes, I use DEALER/DEALER
|
|
[01:17] ssi
|
the nodes can generate tokens based on child worker ready state
|
|
[01:17] ssi
|
and send the tokens out the dealer, upstream
|
|
[01:17] ssi
|
since they're dealers, they oughta load balance between upstream nodes
|
|
[01:17] ssi
|
so if a node has 10 ready workers, it'll generate 10 tokens and distribute them between the upstream nodes
|
|
[01:18] ssi
|
and then the upstream nodes can redeem them to send messages downstream
|
|
[01:18] ssi
|
(I realize I'm probabyl talking to nobody, but this is as good a scratchpad as any)
|
|
[01:18] ssi
|
the tokens can have a timestamp so they expire
|
|
[01:18] ssi
|
that way if some upstream node gets a handful of tokens and locks up or drops offline, they'll expire eventually and the node can generate more to send out
|
|
[01:19] ssi
|
when an upstream node sends a message downstream, it'll include the token as the first message part
|
|
[01:20] ssi
|
node will only accept incoming messages with a valid, unused token
|
|
[01:23] jebil
|
Is it still unsafe to use ZeroMQ on the internet? I heard reports that it was actually possible to crash it if invalid input is given on the outward facing port.
|
|
[04:36] ssi
|
wow
|
|
[04:36] ssi
|
I took something beautiful and destroyed it.
|
|
[04:36] ssi
|
:(
|
|
[04:37] michelp
|
<revison control system> --revert
|
|
[04:37] michelp
|
ssi, don't give up ;)
|
|
[04:38] michelp
|
you might be closer than you think
|
|
[04:38] michelp
|
sometimes my best code looks like my worst, then i do a slight change...
|
|
[06:30] ssi
|
heheh
|
|
[06:30] ssi
|
well I implemented this crazy ridiculously complex flow control concept
|
|
[06:31] ssi
|
using all DEALER/DEALER sockets to replace my PUSH/PULL
|
|
[06:31] ssi
|
and it looks like it ought to work, except it fails with:
|
|
[06:31] ssi
|
Assertion failed: inpipe_ && outpipe_ (xreq.cpp:43)
|
|
[06:31] ssi
|
and I can't track down why
|
|
[07:59] CIA-76
|
libzmq: 03Martin Sustrik 07master * re895607 10/ src/tcp_connecter.cpp : ENETUNREACH is a valid error from connect ...
|
|
[07:59] mikko
|
ssi: can you isolate reproducable part ?
|
|
[08:00] mikko
|
ssi: small reproducable code would help a lot
|
|
[08:00] sustrik
|
+ 0mq version number
|
|
[08:01] mikko
|
do we have different versions in jira already?
|
|
[08:02] sustrik
|
no idea
|
|
[08:02] sustrik
|
let me check
|
|
[08:02] mikko
|
yes we do
|
|
[08:02] sustrik
|
#
|
|
[08:02] sustrik
|
Affects Version/s: 2.1.7
|
|
[08:02] mikko
|
nice
|
|
[08:03] mikko
|
jira is so much more pleasant than github issue tracker
|
|
[08:03] sustrik
|
yep, it have changed a lot during last two years though
|
|
[08:04] sustrik
|
i'm still not fully accustomed to it
|
|
[18:21] ssi
|
I simplified and now I have a working pattern... mostly
|
|
[19:47] ssi
|
argh of course this pattern's misbehaving now
|
|
[20:53] ssi
|
on to pattern #4!
|
|
[21:17] ssi
|
pattern 4 looks like a winner
|
|
[23:24] dhawth
|
I'm having problems getting a java program to run using jzmq, on mac os X, and the error is java.lang.UnsatisfiedLinkError: no jzmq in java.library.path. I know it's loading the zmq.jar because the backtrace includes org.zeromq.ZMQ.<clinit>(ZMQ.java:34), which is the System.loadLibrary line for libjzmq
|
|
[23:25] dhawth
|
I've played around with LD_LIBRARY_PATH and java.library.path, and I can prove that java.library.path is correctly set to ~/zmq/lib which is where libjzmq.* are
|
|
[23:25] dhawth
|
I'm pretty sure the versions match up between jzmq and zeromq, they're both 2.1.0
|
|
[23:26] dhawth
|
the git url i used to fetch zeromq is https://github.com/zeromq/zeromq2-1.git
|
|
[23:26] dhawth
|
can someone please help me figure this out
|
