* Re: relayd TCP reconnect?
[not found] <DUB123-W281E1610272EFEB7FEBDA2DD0B0@phx.gbl>
@ 2015-03-25 18:14 ` Jérémie Galarneau
[not found] ` <CA+jJMxvqgcwouaAyAEty9Ghd3hkd5N0PdFZOuR1s9j-d0RCO-A@mail.gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Jérémie Galarneau @ 2015-03-25 18:14 UTC (permalink / raw)
To: Jesper Derehag; +Cc: lttng-dev
On Wed, Mar 25, 2015 at 11:16 AM, Jesper Derehag <jderehag@hotmail.com> wrote:
> Hi All,
>
> I know the issue with relayd reconnects have been discussed earlier here:
> http://lists.lttng.org/pipermail/lttng-dev/2014-October/023650.html
>
> But has there been any further development on this?
> I would actually go as far as calling it a bug and submitting it to redmine tracker, but want to get approval here first.
>
Hi Jesper,
There has been no work done on this yet.
> I would argue that its *always* a good idea to do reconnects due to that you really dont have any end-to-end control of the TCP flow.
> Some random router might decide to spuriously drop your connection, not to mention more modern queuing disciplines which might randomly throw away packets.
>
> On automated systems, that would mean that you have to somehow automagically detect that you got a disconnect, and then externally restart the session, which seems like a very weird workaround...
>
> I would be happy to file such a issue to the tracker if people thinks its a good idea, (and depending on if I have the time I *might* look into solving it myself).
> But it might be some time away in that case..
Sure, feel free to open a ticket. We'll definitively have to look into
recovering gracefully at some point.
Jérémie
>
> Regards,
> Jesper
>
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <CA+jJMxvqgcwouaAyAEty9Ghd3hkd5N0PdFZOuR1s9j-d0RCO-A@mail.gmail.com>]
* relayd TCP reconnect?
@ 2015-03-25 15:16 Jesper Derehag
0 siblings, 0 replies; 3+ messages in thread
From: Jesper Derehag @ 2015-03-25 15:16 UTC (permalink / raw)
To: lttng-dev
Hi All,
I know the issue with relayd reconnects have been discussed earlier here:
http://lists.lttng.org/pipermail/lttng-dev/2014-October/023650.html
But has there been any further development on this?
I would actually go as far as calling it a bug and submitting it to redmine tracker, but want to get approval here first.
I would argue that its *always* a good idea to do reconnects due to that you really dont have any end-to-end control of the TCP flow.
Some random router might decide to spuriously drop your connection, not to mention more modern queuing disciplines which might randomly throw away packets.
On automated systems, that would mean that you have to somehow automagically detect that you got a disconnect, and then externally restart the session, which seems like a very weird workaround...
I would be happy to file such a issue to the tracker if people thinks its a good idea, (and depending on if I have the time I *might* look into solving it myself).
But it might be some time away in that case..
Regards,
Jesper
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-03-26 8:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <DUB123-W281E1610272EFEB7FEBDA2DD0B0@phx.gbl>
2015-03-25 18:14 ` relayd TCP reconnect? Jérémie Galarneau
[not found] ` <CA+jJMxvqgcwouaAyAEty9Ghd3hkd5N0PdFZOuR1s9j-d0RCO-A@mail.gmail.com>
[not found] ` <DUB123-W398B9D56C2EA95095578ECDD080@phx.gbl>
2015-03-26 8:21 ` FW: " Jesper Derehag
2015-03-25 15:16 Jesper Derehag
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.