On Fri, Apr 21, 2017 at 11:43 AM, Raghavendra G
wrote:
> Summing up various discussions I had on this,
>
> 1. Current ping frame work should measure just the responsiveness of
> network and rpc layer. This means poller threads shouldn't be winding the
> individual fops at all (as it might add del
Summing up various discussions I had on this,
1. Current ping frame work should measure just the responsiveness of
network and rpc layer. This means poller threads shouldn't be winding the
individual fops at all (as it might add delay in reading the ping
requests). Instead, they can queue the requ
Yes, the earlier a fault is detected the better.
On January 24, 2017 9:21:27 PM PST, Jeff Darcy wrote:
>> If there are no responses to be received and no requests being
>> sent to a brick, why would be a client be interested in the health of
>> server/brick?
>
>The client (code) might not, but th
> If there are no responses to be received and no requests being
> sent to a brick, why would be a client be interested in the health of
> server/brick?
The client (code) might not, but the user might want to find out and fix
the fault before the brick gets busy again.
On Tue, Jan 24, 2017 at 10:39 AM, Vijay Bellur wrote:
>
>
> On Thu, Jan 19, 2017 at 8:06 AM, Jeff Darcy wrote:
>
>> > The more relevant question would be with TCP_KEEPALIVE and
>> TCP_USER_TIMEOUT
>> > on sockets, do we really need ping-pong framework in Clients? We might
>> need
>> > that in tr
On Tue, Jan 24, 2017 at 10:39 AM, Vijay Bellur wrote:
>
>
> On Thu, Jan 19, 2017 at 8:06 AM, Jeff Darcy wrote:
>>
>> > The more relevant question would be with TCP_KEEPALIVE and
>> > TCP_USER_TIMEOUT
>> > on sockets, do we really need ping-pong framework in Clients? We might
>> > need
>> > that i
On Thu, Jan 19, 2017 at 8:06 AM, Jeff Darcy wrote:
> > The more relevant question would be with TCP_KEEPALIVE and
> TCP_USER_TIMEOUT
> > on sockets, do we really need ping-pong framework in Clients? We might
> need
> > that in transport/rdma setups, but my question is concentrating on
> > transpo
> The more relevant question would be with TCP_KEEPALIVE and TCP_USER_TIMEOUT
> on sockets, do we really need ping-pong framework in Clients? We might need
> that in transport/rdma setups, but my question is concentrating on
> transport/rdma. In other words would like to hear why do we need heart-b
On Thu, Jan 19, 2017 at 3:59 PM, Raghavendra G
wrote:
> The more relevant question would be with TCP_KEEPALIVE and
> TCP_USER_TIMEOUT on sockets, do we really need ping-pong framework in
> Clients? We might need that in transport/rdma setups, but my question is
> concentrating on transport/rdma.
The more relevant question would be with TCP_KEEPALIVE and TCP_USER_TIMEOUT
on sockets, do we really need ping-pong framework in Clients? We might need
that in transport/rdma setups, but my question is concentrating on
transport/rdma. In other words would like to hear why do we need heart-beat
mech
On Thu, Jan 19, 2017 at 1:50 PM, Mohammed Rafi K C
wrote:
> Hi,
>
> The patch for priority based ping packets [1] are ready to review. As
> Shyam mentioned in the comment on patch set 12, it doesn't solve the
> problem with network conjunction nor the disk latency. Also it won't
> priorities the
Hi,
The patch for priority based ping packets [1] are ready to review. As
Shyam mentioned in the comment on patch set 12, it doesn't solve the
problem with network conjunction nor the disk latency. Also it won't
priorities the reply of ping packets at the server end (We don't have a
straight way t
12 matches
Mail list logo
