On Mon, Nov 12, 2012 at 11:35 AM, Stefan de Konink wrote:
> The first step to a solution is probably documenting that there is a
> use case were reconnection doesn't work. For this we need better
> experimentation which I am committing to.
Yes, great.
> Sadly 'simple' is also not so simple, we
Hi Pieter,
On Mon, 12 Nov 2012, Pieter Hintjens wrote:
> You are probably right, and it could well be that a reboot simply
> isn't reported by TCP as a network failure, except after a session
> timeout (30 minutes by default).
Even after a day, some of the remote subscribers didn't come back.
O
On Mon, Nov 12, 2012 at 10:47 AM, Stefan de Konink wrote:
> I think you are over estimating the 'firewall' concept I mentioned. It is
> just a system with policy drop, and allow from a few sources, on the same
> server as the pubsub is running. But I'll strip the firewall from the
> problem and g
On Mon, 12 Nov 2012, Pieter Hintjens wrote:
> Can you try with a subscriber inside the firewall? It does sound like
> the firewall simply isn't recognizing that the server has "gone", so
> keeps the connection to the subscriber open, which then has no reason
> to reconnect.
I think you are over e
On Mon, Nov 12, 2012 at 8:59 AM, Stefan de Konink wrote:
> I just dit a normal "reboot" - and I doubt the iptables based firewall
> is currently a blocker here.
Can you try with a subscriber inside the firewall? It does sound like
the firewall simply isn't recognizing that the server has "gone",
On 11/12/12 00:40, Pieter Hintjens wrote:
> I suspect the firewall is behaving differently on a server shutdown
> (which closes the socket cleanly) and a reboot (which does not).
I just dit a normal "reboot" - and I doubt the iptables based firewall
is currently a blocker here.
> As Kevin points
On Mon, Nov 12, 2012 at 12:31 AM, Stefan de Konink wrote:
> No, the publisher is at a static (public) IP adress, none of the
> subscribers either on ZeroMQ2 nor ZeroMQ3 were succesful reconnected
> after reboot. One subscriber even reported: "I see it is still waiting
> for data." While at our si
On Mon, Nov 12, 2012 at 12:44 AM, Benjamin Henrion wrote:
> For those who read french:
> http://linuxfr.org/users/krunch/journaux/zeromq-et-les-mangoustes
Ah, the joys of free software, and 'experts' who respond to code they
don't like by complaining rather than, perhaps, sending a patch.
-Piet
I've only just come across this, after using clrzmq in the past.
A couple of things needed updating (which you've probably already done,
bearing in mind your post is nearly a year old):-
All socket types can either Bind() or Connect().
You limit some of your sockets to doing one or the other,
a
For those who read french:
http://linuxfr.org/users/krunch/journaux/zeromq-et-les-mangoustes
--
Benjamin Henrion
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Ins
On 11/11/12 07:39, Pieter Hintjens wrote:
> The subscriber should reconnect no matter what the problem is at the
> publisher side. But perhaps the publisher is changing IP address and
> you're somehow passing its IP address in order to do the original
> connect?
No, the publisher is at a static (p
11 matches
Mail list logo
