| [Time] Name | Message |
|
[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/Makefile.am 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 ...
|
