Sunday July 24, 2011

[Time] NameMessage
[00:38] samBiotic could anyone please give me a heads up on what sort of latency sizes one can expect from epgm?
[10:07] Guest55679 I'm currently designing the best way to use 0MQ in a cluster
[10:08] Guest55679 Two main questions: 1) Endpoint configurations 2) Connection pooling
[10:09] sustrik yes?
[10:09] Guest55679 For sure some custom implementations for these two are possible, but maybe some existing frameworks/plugins for 0MQ are present already to address these ones?
[10:11] Guest55679 So the client code will not depend upon the actual endpoint addresses, while having active pools of endpoint instances
[10:11] Guest55679 First thought - to use JNDI + Spring configurations for these needs
[10:12] sustrik pooling connections is not a good idea
[10:12] sustrik it ties individual flow into a single unit
[10:12] sustrik so, for example, if one of the flows applies backpressure
[10:13] sustrik say because the service takes some time to process requests
[10:13] sustrik it stall all the unrelated flows in the same connection
[10:13] Guest55679 But we will end up with some performance hits for establishing new connections, instead of pooling, right?
[10:15] Guest55679 OK, I see. So the socket should be opened all the time, within the application's lifetime, right? No need to establish one connection per every request-response cycle, correct?
[10:18] Guest55679 But again, let's say I have one serving endpoint, which receives the requests from a frontend layer. This frontend layer can handle up to 1000+ concurrent HTTP requests.
[10:19] Guest55679 Should I have 1000+ opened client sockets for 0MQ in this case?
[10:20] Guest55679 Or having just 1 opened socket? But in this case another queueing mechanism should be introduced between this opened socket and all those 1000+ HTTP sessions.
[10:27] Guest55679 Maybe requirement clarifications will help here:
[10:27] Guest55679 1. Replacing JMS and REST based integration of the internal tiers/component of a large web application with 0MQ
[10:30] Guest55679 2. Components should not be tied to 0MQ specifics - no endpoint configurations in the code, no socket creations/bindings
[10:30] Guest55679 So for now I've ended up with the following approach:
[10:31] Guest55679 1. Spring proxies for encapsulating all 0MQ-related invocations
[10:31] Guest55679 2. Centralized registry of endpoint configurations, which is accessable via JNDI
[10:33] pieter_hintjens Guest55679: how much of the Guide have you read?
[11:12] pieter_hintjens sustrik: people like that trying to fit 0MQ into "stick your random messaging layer here"
[11:13] pieter_hintjens I want to make a video "Why 0MQ is not Yet Another Messaging Layer"
[14:55] sustrik pieter_hintjens: great idea
[14:56] sustrik that would be useful
[14:56] sustrik if you need any help with that, just shout
[15:52] CIA-32 libzmq: 03Martin Sustrik 07master * r837451e 10/ (4 files): Remove blob_t class ...
[16:08] CIA-32 libzmq: 03Martin Sustrik 07master * r11e21d0 10/ (src/ src/ctx.hpp src/semaphore.hpp): semaphore_t class removed ...
[16:11] CIA-32 libzmq: 03Martin Sustrik 07master * r0e71b11 10/ src/ctx.hpp : Obsolete include in ctx.hpp removed ...
[16:16] CIA-32 libzmq: 03Martin Sustrik 07master * rf716b57 10/ (11 files): Only one polling mechanism is compiled ...
[16:28] CIA-32 libzmq: 03Martin Sustrik 07master * r7c1dca5 10/ (20 files): Session classes merged into a single class ...
[16:33] CIA-32 libzmq: 03Martin Sustrik 07master * r43b5b34 10/ src/pgm_sender.cpp : PGM subscription forwarding fixed ...