Hi Stan,
I'm 100% for this activity, however I don't think we should change the
behavior of timeouts you listed in #2 - this can lead to unexpected
behavior for users who already use them. I would just deprecate them and
eventually remove.
-Val
On Mon, May 28, 2018 at 1:29 PM, Stanislav
Hi folks,
It looks like we stopped half-way with this activity. I’d like to pick it up.
All seem to agree that we should simplify the timeout settings.
Here are the specific actions I’d like to propose:
1. Promote the use of global timeouts as the best practice
*What*: update the docs to
Hi Yakov,
Do the proposed changes look good to you?
Thanks,
Alexey
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Absolutely agree.
Personally I find it particularly frustrating, that
*IgniteConfiguration.networkTimeout* and TcpDiscoverySpi.networkTime*out *are
not the same thing.
If we had a small set of timeouts with simple and clear semantics, it would
make everybody happier.
Denis
вт, 6 мар. 2018 г. в
Yakov,
1. The proposal list of parameters to deprecate:
TcpDiscoverySpi.setConnectTimeout (covered by
IgniteConfiguration.setFailureDetectionTimeout)
TcpDiscoverySpi.setReconnectCount (covered by
IgniteConfiguration.setFailureDetectionTimeout)
TcpDiscoverySpi.setSocketTimeout (covered by
Alexey, generally I agree. However, I don't understand what exactly you
suggest. Can you please list the list of parameters you want to deprecate
(1), internal logic changes (2) and updates to the javadocs/description of
the params you want to keep (3)?
--Yakov
Сlear and intuitive API is the strength of Ignite, so I am also +1 for
removing the unobvious settings.
пт, 2 мар. 2018 г. в 4:11, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> +1. Low level timeouts that we still have in discovery and communication
> are very hard to explain and I
+1. Low level timeouts that we still have in discovery and communication
are very hard to explain and I doubt there is anyone who fully understands
how they currently work. They bring a lot of complexity and almost zero
value. Let's deprecate them and leave only failureDetectionTimeout plus
other
I agree with you.
I think we could restrict usage of e.g. setConnectTimeout/setSocketTimeout
to people extending SPIs, since different implementations may need
different values.
However, for user configurations we should only expose timeouts we can
explain, everything else should have reasonable
