[Time] Name | Message |
[00:01] believa
|
What tag/branch to use of the zeromq github repository to get the same source as the v2.0 stable release on the zeromq website?
|
[00:03] believa
|
actually - should be the v2.0.10 tag I'm guessing.
|
[00:14] tokyodan
|
Trying to install in Ubuntu 10.04 LTS server. I followed all the instructions. did './configure'. Then when I execute 'make' I get 'No targets specified and no makefile found'. What is wrong?
|
[00:14] tokyodan
|
all the LINUX dependencies have also been installed.
|
[00:17] bpl29
|
My make check is failing on OS X. It's failing on test_shutdown_stress
|
[00:19] bpl29
|
I'm reading there is an assertion error in mailbox.cpp, and in fact it's commented in the source to say that this assertion should never fail.
|
[00:20] tokyodan
|
bp129 doesn't seem to be much help forthcoming here.
|
[00:21] bpl29
|
right, I'm wondering if people have actually installed on OS X.
|
[00:21] bpl29
|
There is a developer thread about this particular error, but it's dated
|
[00:22] bpl29
|
https://github.com/zeromq/zeromq2/issues#issue/161
|
[00:22] bpl29
|
Perhaps someone has gotten about this.
|
[00:22] Guthur
|
bpl29, I know someone was running on OSX today
|
[00:23] Guthur
|
and indeed I have a user of clrzmq2 who runs on OSX
|
[00:23] tokyodan
|
bp129 I'm trying on Ubuntu 10.04 server now with not much luck. I'm afraid to install on my Snow Leopard machine right now.
|
[00:23] Guthur
|
I don't use it myself so I can't really help
|
[00:23] Guthur
|
tokyodan, zeromq built fine on ubuntu 10.04 for me recently
|
[00:23] tokyodan
|
thanks bp129
|
[00:23] Guthur
|
which version are you using
|
[00:24] Guthur
|
I wasn't running server mind you
|
[00:25] bpl29
|
I just downloaded from git
|
[00:25] tokyodan
|
What causes make to error out with ''No targets specified and no makefile found' ?
|
[00:25] tokyodan
|
Guthur Did you just type 'make' with no arguments?
|
[00:25] Guthur
|
you ran autogen first, right>
|
[00:26] Guthur
|
?
|
[00:26] tokyodan
|
autogen> no. Didn't see that explained anywhere.
|
[00:26] Guthur
|
I think I ran autogen first then configure then make
|
[00:27] tokyodan
|
what does autogen do? And does it take arguments?
|
[00:27] Guthur
|
I think it should try to automatically detect settings for you platform
|
[00:27] tokyodan
|
I'm using the latest version of OMQ 2.1 (rc2)
|
[00:28] tokyodan
|
I thought that's what ./configure also did.
|
[00:28] tokyodan
|
did you run autogen on OS X or Ubuntu?
|
[00:28] Guthur
|
Ubuntu
|
[00:29] Guthur
|
you are right though
|
[00:29] Guthur
|
configure should do it
|
[00:29] tokyodan
|
Yeah. frome its output that's what it looked like it was doing.
|
[00:30] Guthur
|
my make fu is pretty weak tbh
|
[00:30] tokyodan
|
Seems like it should have created a makefile of something too, but didnt. although I got Makefile.am and Makefile.in
|
[00:31] Guthur
|
i'm just downloading fresh here to check
|
[00:33] Guthur
|
you must have ran autogen at some point
|
[00:33] Guthur
|
I have no ./configure in a fresh download
|
[00:34] Guthur
|
tokyodan, the configure completes ok?
|
[00:35] cremes
|
if you get a mailbox assertion on OSX, you need to do some kernel tuning
|
[00:35] cremes
|
search the zeromq.org site for the 'tuning guide'
|
[00:35] Seta00
|
anyone here using clrzmq2?
|
[00:35] cremes
|
it has an entry on how to expand the socket buffers used by the kernel
|
[00:35] Guthur
|
Seta00, I do
|
[00:36] Guthur
|
Seta00, any issues?
|
[00:36] cremes
|
bpl29: look at the tuning guide
|
[00:36] Seta00
|
Guthur, it seems you can't detect EAGAIN when using NOBLOCK on a recv call.
|
[00:36] Seta00
|
so I guess I'll have to use polling?
|
[00:37] bpl29
|
cremes: where is the tuning guide located?
|
[00:38] Guthur
|
Seta00, if there is no msg the method just silently returns
|
[00:38] cremes
|
not sure... try the search box
|
[00:38] Seta00
|
bpl29, http://www.zeromq.org/docs:tuning-zeromq
|
[00:38] bpl29
|
thanks Seta00
|
[00:38] cremes
|
bpl29: that's it! ^^
|
[00:38] bpl29
|
thank you both
|
[00:38] cremes
|
on osx the default buffers are all too tiny :(
|
[00:38] Seta00
|
bpl29, for future reference: Guthur, yeah but silently returning doesn't
|
[00:38] Seta00
|
oops
|
[00:38] Seta00
|
wrong ctrl-v
|
[00:38] Seta00
|
http://www.zeromq.org/docs:_start
|
[00:39] Seta00
|
Guthur, so I should check the output buffer?
|
[00:39] cremes
|
bpl29: btw, i run on osx all the time; once you get some tuning out of the way 0mq works really nicely on it
|
[00:39] Guthur
|
Seta00, the return byte array will be null
|
[00:40] bpl29
|
Okay, great. I'll give it a shot.
|
[00:40] Guthur
|
Seta00, I didn't feel it was right to throw an exception for it
|
[00:41] Seta00
|
what how did I miss that
|
[00:41] Guthur
|
it should be the only time you receive a null msg
|
[00:41] Guthur
|
and empty message being byte[0]
|
[00:41] Seta00
|
yeah, I see it now
|
[00:41] Guthur
|
Seta00, cool, does that behaviour seem sane to you
|
[00:41] mkent
|
Noob question: If you have zeromq set to queue to disk, is there any API for monitoring the disk queue?
|
[00:42] Guthur
|
I'm always looking for feedback
|
[00:42] Seta00
|
Guthur, yes it does.
|
[00:42] Seta00
|
my current zmq code is ridiculous, so I'm doing some refactoring :)
|
[00:43] tokyodan
|
Guthur the ./configure completed with 'error: unable to find a working c++ compiler'.
|
[00:43] Guthur
|
tokyodan, yeah that would be a show stopper, hehe
|
[00:44] Seta00
|
tokyodan, sudo apt-get install build-essential g++
|
[00:44] tokyodan
|
I thought Ubuntu would have a C++ compiler built in.
|
[00:44] Seta00
|
:P
|
[00:44] Seta00
|
tokyodan, only comes with a C compiler
|
[00:44] tokyodan
|
thanks Seta00
|
[00:44] Seta00
|
yw
|
[00:45] Guthur
|
Seta00, if you ever have any issues with clrzmq2 you can usually catch me around here, or raise an issue on github, which I'll try to get asap
|
[00:45] Seta00
|
Guthur, awesome, I'll keep that in mind
|
[00:46] Guthur
|
I'd really like to clean up some of the API, but I'm waiting until ZMQ 3.0
|
[00:48] Guthur
|
Seta00, Are you targetting Mono perchance?
|
[00:49] Seta00
|
Guthur, yes
|
[00:50] Guthur
|
make sure to grab the most recent version of clrzmq2
|
[00:50] Guthur
|
I found a signalling issue in relation to the Mono GC
|
[00:50] tokyodan
|
Guthur & Seta00 Thanks you guys. You got me through 'make'. It's running right now.
|
[00:50] Guthur
|
you may have seen it on the mailing list recently
|
[00:50] Seta00
|
nice :)
|
[00:50] Guthur
|
tokyodan, cool, happy coding
|
[00:51] Guthur
|
Seta00, basically signals generated by the Mono GC can cause the syscalls to return EINTR which would throw an exception in clrzmq2
|
[00:52] Guthur
|
the workaround I decided on was to reenter the call for all signals bar sigint and sigterm, which would instead exit the program
|
[00:53] Guthur
|
this mainly effected long running syscalls like those used in poll
|
[00:53] Guthur
|
obviously it was only an issue on POSIX platforms
|
[00:53] tokyodan
|
'make' finished with no errors. yeah!
|
[00:56] tokyodan
|
Well it seems to have installed OK. Now for trying it out. Still have to get the Lua part though.
|
[02:06] tokyodan
|
I installed the Lua binding on Ubuntu 10.04 server. But when I do: require 'zmq' I get module zmq not found. Seems like make is not putting the files into the proper Lua directories. How do I cure this outside of creating all kinds of symlinks.
|
[03:39] tokyodan
|
This doesn't work with Lua
|
[03:39] tokyodan
|
I followed this video: http://www.youtube.com/watch?v=_JCBphyciAs&feature=player_embedded
|
[03:41] tokyodan
|
And unlink in the video the send("Hello") command returns before I even start up the receiving end.
|
[03:41] tokyodan
|
I start up the recv loop on the receiving side and it just sits there blocking and waiting for input
|
[03:47] michelp
|
last night i was musing on the "supercomputer" descriptions in the guide
|
[03:48] michelp
|
having recently read "The Connection Machine" by D. Hillis it made me think that 0mq would make an excellent interconnect mechanism for various SIMD topologies
|
[03:50] michelp
|
the guide basically spells out how to do those topologies with a control channel to issue "instructions". in conjunction with something like NumPy it would be an excellent platform for distributed computing
|
[03:50] michelp
|
anyway, just musing over dinner on the subject ;)
|
[03:53] tokyodan
|
Does the latest version on OMQ work with Lua 5.1.4?
|
[03:54] tokyodan
|
on Ubuntu 10.04 LTS Server?
|
[03:56] michelp
|
tokyodan, I don't use Lua so can't help you specifically, but have you looked at "The Missing Message Problem Solver" at http://zguide.zeromq.org/page:all ?
|
[03:56] michelp
|
it might help you diagnose the problem
|
[04:04] tokyodan
|
michelp thanks!
|
[04:05] michelp
|
sure np
|
[04:06] tokyodan
|
I see that UP/DOWNSTREAM and replaced by PULL/PUSH. Is that correct? I've see examples with PUB/SUB?
|
[04:10] cremes
|
tokyodan: yes, the UP/DOWNSTREAM names were replaced by PUSH/PULL
|
[04:10] cremes
|
PUB/SUB has not changed nor are there any plans to change it
|
[04:25] tokyodan
|
is there a difference between PUSH
|
[04:25] tokyodan
|
PULL and PUB/SUB?
|
[04:26] cremes
|
tokyodan: yes, they are quite different
|
[04:27] cremes
|
in PUB/SUB, any messages sent via PUB are broadcast to *all* subscribers simultaneously
|
[04:27] cremes
|
in PUSH/PULL, messages send via PUSH are delivered round-robin to all connected PULL sockets
|
[04:27] cremes
|
if you haven't read the guide yet, please do so
|
[04:28] cremes
|
there are lots of examples and quite a bit of text explaining this
|
[04:28] cremes
|
see the channel topic for a link to the guide
|
[04:28] tokyodan
|
That's what I'm going to do. Thanks.
|
[04:28] tokyodan
|
I already got it printed out. I was just jumping in, installing, and trying the examples.
|
[04:33] cremes
|
tokyodan: that's the best way to figure it out
|
[07:38] sustrik
|
mikko: hi, are you there?
|
[09:53] pieterh
|
sustrik: ping
|
[09:53] sustrik
|
pong
|
[09:53] pieterh
|
I'm sending the OpenPGM patches to the list
|
[09:53] sustrik
|
great
|
[09:54] sustrik
|
how was the meetup?
|
[09:54] pieterh
|
this covers the changes Mikko made but also include the tarballs, so they're large
|
[09:54] pieterh
|
the meetup was excellent, but too many people
|
[09:54] pieterh
|
:-)
|
[09:54] sustrik
|
i can update the tarball myself
|
[09:54] sustrik
|
no need to include it into the patch
|
[09:54] pieterh
|
I can't make a patch without the tarball, it's in one commit
|
[09:54] sustrik
|
ok
|
[09:54] sustrik
|
np
|
[09:54] sustrik
|
too many?
|
[09:54] pieterh
|
yeah, twenty or twenty five
|
[09:55] pieterh
|
impossible to speak to everyone
|
[09:55] sustrik
|
oh my, not enough chairs?
|
[09:55] pieterh
|
we found space, Mikko and Ian organized it very well
|
[09:56] pieterh
|
i'm testing that Steve's patches apply, will let you know
|
[09:57] sustrik
|
i can do that
|
[09:57] sustrik
|
no problem
|
[09:58] pieterh
|
ok, they apply cleanly
|
[09:58] sustrik
|
thx
|
[09:59] pieterh
|
these changes are more complex than normal because they include the tarballs
|
[09:59] pieterh
|
Mikko wants to make the build system pull the tarballs down dynamically afiau
|
[09:59] pieterh
|
that would be neat
|
[09:59] sustrik
|
in the past the tarballs were updated out of normal process
|
[10:00] sustrik
|
ie. not via mailing list
|
[10:00] pieterh
|
yeah
|
[10:00] pieterh
|
this was because I used a pull request from Mikko's git
|
[10:00] sustrik
|
as for automatic update, how would it know when to update?
|
[10:00] sustrik
|
each new version?
|
[10:01] pieterh
|
hmm, at install time?
|
[10:01] sustrik
|
ah, that way
|
[10:01] pieterh
|
since 0MQ now builds with any version of OpenPGM
|
[10:02] pieterh
|
all you need to do is say, "please build 0MQ with OpenPGM vx.y.z" and it would pull and unpack that tarball
|
[10:02] pieterh
|
something like that, presumably with defaults
|
[10:02] sustrik
|
i see
|
[10:02] pieterh
|
this is possible because OpenPGM now has full autotooling, so 0MQ can be much more naive about it
|
[10:02] sustrik
|
is steve ready to freeze the API?
|
[10:03] pieterh
|
Steve...?
|
[10:03] sustrik
|
mc coy
|
[10:03] pieterh
|
I meant, "Steve... ping...?"
|
[10:03] sustrik
|
if not, the auto-upload could break
|
[10:03] pieterh
|
yes
|
[10:03] pieterh
|
this is speculation, anyhow, but Mikko and Steve already did amazing work on the integration
|
[10:04] pieterh
|
so I assume they'd get this working properly
|
[10:05] sustrik
|
ok, let me apply the patch
|
[10:23] sustrik
|
pieterh_1: you should consult the build system maintainers before committing build-related patches imo
|
[10:24] sustrik
|
mikko presumably, in this case
|
[10:24] pieterh_1
|
you mean Steve's patches...
|
[10:24] pieterh_1
|
right
|
[10:24] sustrik
|
yes
|
[10:24] pieterh_1
|
I'll ask Mikko to review them, good idea
|
[12:04] Guthur
|
pieterh, with peering3 what sort of output should I expect?
|
[12:20] Guthur
|
oh nvm, working now
|
[12:30] s0undt3ch
|
hello ppl
|
[12:30] s0undt3ch
|
can a publisher know where a connection is comming from?
|
[12:30] s0undt3ch
|
ie, so I can auth/deny a subscription?
|
[12:35] sustrik
|
no
|
[13:45] stimpie
|
Iam getting unstable performance using jzmq on windows, 1,000,000 x 128B messages gets 300K/s. 10,000,000 x 128B messages gets 20K/s
|
[13:46] stimpie
|
it looks like this is caused by the sender, using a c sender and a java receiver gets a stable 300K/s
|
[13:47] sustrik
|
it must be java binding issue then
|
[13:47] sustrik
|
try reporting it on jzmq's bug tracker
|
[13:47] sustrik
|
or on the mailing list
|
[13:49] stimpie
|
ok I will try to create a simple reproducible scenario. (or just provide the results to my boss, saying we shouldn't use windows ;-)
|
[13:49] fred86
|
When using pub/sub sockets that stay open for a long time (without any activity), I find that after a while (maybe 1+ hours later), the client-side stops receiving messages (however when I open a new client, the new client can receive messages). Do the sockets reconnect automatically if there's a short network outage? What could the problem be? Thanks.
|
[13:50] cremes
|
stimpie: does this example use PUB/SUB?
|
[13:50] cremes
|
stimpie: if so, your publisher could be overrunning the subscriber; in that case the publisher will queue the messages in memory
|
[13:50] cremes
|
which could lead to a slowdown if your box doesn't have enough RAM
|
[13:51] stimpie
|
cremes, yes its a PUB/SUB and memory usages skyrockets
|
[13:51] cremes
|
stimpie: then it is queueing in memory
|
[13:51] cremes
|
does the machine running the publisher have enough RAM or is it swapping to disk?
|
[13:52] stimpie
|
its starts swapping at some point
|
[13:52] cremes
|
ok, then you have your answer as to why it gets slower
|
[13:52] stimpie
|
but why doesnt this occur with a c version?
|
[13:52] cremes
|
which part was in C?
|
[13:53] stimpie
|
I had a sender and receiver in c and in java
|
[13:53] cremes
|
c -> c, no problem?
|
[13:53] cremes
|
c -> java, slow?
|
[13:53] cremes
|
how about java -> c, does that work?
|
[13:53] stimpie
|
c->java is ok
|
[13:53] stimpie
|
java -> c, is slow
|
[13:54] cremes
|
so which combo produces this slowdown?
|
[13:54] stimpie
|
java -> java is slow and java -> c is slow
|
[13:54] stimpie
|
c-> c, c -> java are fine
|
[13:54] cremes
|
interesting...
|
[13:55] cremes
|
java -> c being slow doesn't make any sense; that could certainly be a bug
|
[13:55] cremes
|
does the memory usage of the publisher sky-rocket in that combination?
|
[13:56] stimpie
|
yes
|
[13:56] cremes
|
weird... yes, open a ticket with all of these details including the code
|
[13:57] stimpie
|
I was thinking that maybe java uses some object overhead on each messages causing it to use more memory and start swaping sooner then the c versions
|
[13:59] sustrik
|
fred86: yes, there's automatic reconnection
|
[14:00] fred86
|
hmm, okay. Then this problem is a bit bizarre. the layout is a chatroom-like server (where the server does some processing before publishing a message). if there isn't any activity for a while, I find that the clients stop getting messages from the server.. (but they can still send messages..and I can see the server processing everything fine). and if I open new clients, they will be able to receive messages. do you have any idea wh
|
[14:01] sustrik
|
no,sorry, try to make a minimal reproducible test case and i'll have a look
|
[14:02] sustrik
|
stimpie: jave uses gc
|
[14:02] sustrik
|
java
|
[14:02] sustrik
|
which could mean that object deallocation is delayed
|
[14:03] sustrik
|
in that case each message would be stored in memory twice
|
[14:03] sustrik
|
once in 0mq buffer
|
[14:03] sustrik
|
second time in form of gargage on java heap
|
[14:05] stimpie
|
I will do some more test to see if it really is only a memory issue.
|
[14:43] gambi
|
how do I return a message via XREQ in a stream callback? on one side i've got this zmqstream and a on_recv() callback and on the other side a regular socket which does the send() (that works) and the recv() (which doesn't)
|
[14:43] gambi
|
XREQ/XREP
|
[14:44] gambi
|
unfortunately I'm not sure how else do explain this, sorry :(
|
[14:48] gambi
|
basically I'm trying to send build something closely related to this: https://github.com/zeromq/pyzmq/blob/master/examples/heartbeat/heart.py but I'd like to have some processing done before it returns the message to the server.
|
[14:49] gambi
|
sorry for the random words that mix into my sentences ... I guess I'm already quite tired ;)
|
[14:50] guido_g
|
simply send the message back
|
[14:52] guido_g
|
gambi: see http://zeromq.github.com/pyzmq/eventloop.html#send
|
[14:55] gambi
|
guido_g: oh, great thanks for that! i'll try that right away. :)
|
[14:56] guido_g
|
one should try the products documentation *before* using the product...
|
[14:56] gambi
|
guido_g: oh, c'mon ... I've been reading the docs for hours ... ;)
|
[14:56] guido_g
|
sure
|
[15:21] xs
|
suppose the rep side of a reqrep dies after the req side has sent it's request. then the rep side recovers. shouldn't the req side re-send its request? this doesn't seem to be happening for me (i'm using multipart messages if that changes things)
|
[15:26] cremes
|
xs: no, 0mq doesn't auto-resend anything
|
[15:26] cremes
|
you would need to timeout the send and retry yourself
|
[15:27] cremes
|
to do so you have two choices and both use zmq_poll()
|
[15:27] cremes
|
1. close the REQ socket, reopen it and resend
|
[15:27] cremes
|
2. use an XREQ socket (this doesn't enforce the strict req/rep/req/rep message pattern) and resend upon timeout
|
[15:27] cremes
|
does that make sense to you?
|
[15:28] xs
|
i think so. thanks.
|
[15:28] xs
|
am i correct in thinking i just have to timeout?
|
[15:28] xs
|
there's no way for me to determine that an endpoint has disappeared and reconnected
|
[15:28] Guthur
|
ch4 for of the guide covers reliability
|
[15:28] Guthur
|
It might have some useful patterns
|
[15:29] cremes
|
xs: correct, there is no way to determine that an endpoint has bounced
|
[15:29] xs
|
ok, thanks, i'll take a look.. i had just assumed 0mq would do this for me. sorry for the noise
|
[15:29] cremes
|
chapter4 of the guide is a good suggestion
|
[16:15] stimpie
|
A follow up on my java -> c performance issues, when limiting the send rate I could push my message rate to a ~300K/s, going above that results in swapping. So cause is memory and not a bug in the java wrapper
|
[16:16] stimpie
|
Still need to figure out how to handle such an overload in production but thats a different subject
|
[16:20] sustrik
|
use hwm/swap
|
[16:29] Guthur
|
pieterh, when simulating a server crash with lazy pirate client/server, should the client be generating...
|
[16:29] Guthur
|
Bad file descriptor
|
[16:29] Guthur
|
nbytes != -1 (mailbox.cpp:242)
|
[16:34] Guthur
|
oh sorry nvm, my mistake
|
[16:59] michelp
|
my coworkers have returned from pycon, it's hard to know if what they are saying about 0mq is FUD they acquired from someone else or not
|
[16:59] michelp
|
for example, they are saying in the PUB/SUB case that the subscriber is guaranteed to drop the first message always, all the time
|
[17:00] michelp
|
is that true? i remember seeing something about it in ch 1 but lost track of the problem in my reading of the guide
|
[17:09] sustrik
|
no, it's not true
|
[17:10] michelp
|
it seems to be a meme that has dug in hard from pycon. sigh
|
[17:10] ianbarber
|
it's because if you right a bit of test code, and start publishing and subscribing at the same time, you'll likely push a bunch of messages before the subscriber is finished connecting
|
[17:11] ianbarber
|
this is a common new-to-0mq issue
|
[17:13] michelp
|
I suspect this is the part of the guide that has formed the meme: "Even if you start a subscriber, wait a while, and then start the publisher, the subscriber will always miss the first messages that the publisher sends."
|
[17:14] michelp
|
they read that far, and stop, and don't go on to read the solution
|
[17:14] michelp
|
Perhaps the very next sentence should be something along the lines of "Keep reading and we'll explain how to do it right" or something like that
|
[17:17] michelp
|
i think the fact that the sentence is bolded also make it stick in someone's mind more so than all the other information there. anyway, it's unfortunate that it seems like these wrong impressions have spread through such a big community so quickly.
|
[17:17] michelp
|
maybe we need an anti-FUD faq
|
[17:18] kdj
|
Yeah, thats too bad. I haven't seen anything like that in my testing.
|
[18:45] Guthur
|
pieterh, ping?
|
[19:08] Guthur
|
private_meta, you about
|
[20:21] mikko
|
hi
|
[20:25] Guthur
|
hey mikko
|
[20:25] Guthur
|
I see the meet up at London was a success
|
[20:25] Guthur
|
you were there, correct?
|
[20:26] mikko
|
yes
|
[20:26] mikko
|
i will never drink beer again
|
[20:28] Guthur
|
stick to coffee, it actually can improve productivity, instead of the opposite, hehe
|
[20:28] Guthur
|
some nice topics though
|
[20:29] Guthur
|
the JMS is an interesting one
|
[20:29] Guthur
|
Just had this situation at work recently, not really related to 0MQ, more that someone wanted to interact with JMS outside of Java
|
[20:30] Guthur
|
I suggested a thin Java wrapper and 0MQ as the glue
|
[20:35] Guthur
|
mikko, did you implement any of the examples in ch4 perchance?
|
[20:42] mikko
|
Guthur: nope
|
[20:45] mikko
|
JMS came from Java guys at the meetup
|
[20:45] mikko
|
they said that Java market is a lot easier to penetrate with JMS compatible messaging
|
[20:48] Guthur
|
yeah they're probably right
|
[20:49] Guthur
|
I think sustrik suggestion is the sanest one
|
[20:49] Guthur
|
but probably not enough for the Java community, they like everything to be fully in the Java ecosystem
|
[20:53] Guthur
|
it'd be an interesting project actually
|
[20:57] dahankzter
|
I dont know, just a bridge would go a long way
|
[20:57] dahankzter
|
that way old IBM MQ's can be used in conjunction with nw =MQ stuff
|
[20:58] dahankzter
|
s/nw/new
|
[21:02] Guthur
|
yeah, I'm probably being a little cynical
|
[21:05] dahankzter
|
no, not really. its very much so but just being able to connect your new cool stuff woth the old expensive monster could go a long way
|
[21:20] sustrik
|
the nice thing about the bridge is that it's cheap
|
[21:20] sustrik
|
can be done in couple of days, i would say
|
[21:23] dahankzter
|
perhaps the problem is vendor specific protocols?
|
[21:23] dahankzter
|
jms does not define any such for the wire at least
|
[21:26] dahankzter
|
I think AMQP would be a nice place to start
|
[21:30] dahankzter
|
i think you know lots of this though :) iMatix is mentioned on the AMQP site
|
[21:48] sustrik
|
dhankzter: you can bridge basically any protocol or API that provides PUB/SUB and/or REQ/REP semantics
|
[21:49] sustrik
|
as for AMQP there's 0mq/RabbitMQ bridge
|
[21:52] dahankzter
|
yes sure. i was just thinking from my perspective where normally there is a big proprietary thing eg MQ as "standard". I would not be allowed to pull in an extra middleware thing like RabbitMQ as well as my new code+zeromq. the convincing the management factor is not negligible unfortunately.
|
[22:14] advant
|
How does zeromq guarantee message persistence and delivery without a database? Or does it use something like hypersonic in-memory database?
|
[22:25] dahankzter
|
it doesn't
|
[22:29] cremes
|
advant___: it doesn't guarantee either of those things; what led you to think that?
|
[22:36] advant
|
oh i dunno, I guess that would be part of a broker anyways
|