ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Starvation in striped pool
Date Fri, 11 Oct 2019 09:45:03 GMT

I don't think there is any problem with idleConnectionTimeout, but you *should
not* use nodes which are not mutually connectible to each other anyway.

I can't really comment on the feasibility of dropping client when it can't
be reached via Communication. You can start a discussion about it on
developers list.

Ilya Kasnacheev

пт, 11 окт. 2019 г. в 11:31, maheshkr76private <maheshkr76@gmail.com>:

> >>I'm almost certain is that problem is that server node cannot open a
> connection to client node (and while it tries, it will reject connection
> attempts from client node)
> The default idleTimeout of TCP communication spi is 6 minutes. So I assume,
> after this timeout, the connection is closed and restarted probably later
> on
> a request from the client.
> So I can imagine, this issue happening, when the client and server are
> trying to re-establish the connection and your explanation makes sense.
> However, my concern still remains.  The server has plenty of timeouts in
> its
> communication SPI. Why wouldn't the server, not throw that client out of
> the
> cluster and let the client fail gracefully? This incessant pinging by
> client
> to the server is a problem in production environments.
> Currently, the only way out for me seems to be set
>  >>>    communicationSpi.setIdleConnectionTimeout(Long.MAX_VALUE);
> testing is currently and seems to be holding up for 22 hours now.
> Do you see any issues with setting idleConnectionTimeout that high?
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

View raw message