Hi Maksim,
> half-state is a possible situation when an Ignite node goes down or
somehow removes connection to a thin client
Half-open state is also possible when, for example, an intermediate router
is rebooted [1].
This is what we seem to have encountered with one of our customers - they
have
I suppose it is great idea, but this functionality can be hard to implement
for some platforms. I.e. sync python client or php (there is no real
multithreading for python (GIL) and php is single threaded by design). But
for async clients it is not very hard to implement. Nevertheless, this
feature
Patch is ready for review
пт, 4 февр. 2022 г. в 14:45, Ivan Daschinsky :
> https://issues.apache.org/jira/browse/IGNITE-16480 -- I've filed ticked.
>
> пт, 7 янв. 2022 г. в 23:44, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> Doesn't look like there are any objections - it's been a
Ivan,
Ideally, the check should come from both sides.
- Client periodically sends keepalive to server
- Server periodically sends keepalive to client
Feature flags will be added accordingly, so it is not necessary to
implement this in all thin clients.
On Mon, Feb 7, 2022 at 11:43 AM Ivan Daschi
Pavel, I suppose that ideally:
1. Client send in handshake flag, that it supports KEEP_ALIVE feature and
server takes it into account.
2. Each request of client can be considered as keep-alive ping.
3. Client send failure should be processed using retry policy.
4. Server should not send keep-alive
Ivan,
I suggest the following:
1. Server sends KEEP_ALIVE feature flag, which means it accepts
OP_KEEP_ALIVE empty message
2. Client sends OP_KEEP_ALIVE when the connection is idle for a
certain period of time
3. Already implemented: when ClientConnectorConfiguration#idleTimeout is
not zero, serv
Folks,
Let's vote for the issue [1], I wish this may help to solve the problem
faster.
[1] https://issues.apache.org/jira/browse/INFRA-22827
On Fri, Feb 4, 2022 at 2:31 PM Anton Vinogradov wrote:
> >> Should I add this info for the INFRA ticket?
> Please do
>
> On Fri, Feb 4, 2022 at 1:52 PM M
Hi Pavel,
Thanks for the links. Yes, I forgot that the flag of changed topology is
lazy. Also I missed that the keepAlive setting is configured on the client
side (alternatively to idleTimeout that is on the server side).
Now I understand, this feature can be helpful then. Every client can
config
> WDYT, should we add a WARN message for clients that configure
> keepAliveTimeout greater than idleTimeout on the server side?
I think we should either log a WARN, or retrieve idleTimeout from server
and configure heartbeatTimeout accordingly (e.g. divide by 2).
Thoughts?
On Mon, Feb 7, 2022 at
I believe explicit is better than implicit :) Also in case of dynamic
calculation of timeout, it can change dynamically, for example restarting a
cluster with different configuration should reconfigure clients too. Looks
complicated.
My vote for WARN + javadocs with mention of this issue.
On Mon,
>>3. Already implemented: when ClientConnectorConfiguration#idleTimeout is
not zero, server disconnects idle clients
>>
But I suppose it would be great to have:
1. If client supports keep alive, use idleTimeout
2. If not, do not use it.
But I am not sure if it is correct or not.
пн, 7 февр. 2022
Ivan, idleTimeout already exists, I don't think we should change the way it
works (or did I misunderstand you?)
Of course, enabling heartbeats means that otherwise idle clients will no
longer be disconnected by the server.
I think we should cross-link those properties in the documentation and
expl
Maksim, agree. Let's not be too clever and only log a warning.
On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn wrote:
> Ivan, idleTimeout already exists, I don't think we should change the way
> it works (or did I misunderstand you?)
>
> Of course, enabling heartbeats means that otherwise idle cli
Feature seems useful for me as it makes connection management more robust
and
predictable.
I agree with Pavel, that we should print warning when heartbeat period is
larger than
idle timeout, but I see a problem here as idle timeout is configured on
server and is not
known to clients, while heartbe
Igor,
> Maybe clients should pass this information on to the handshake.
Do you think we should log a mismatched timeout warning on the server, not
on the client?
Or should we do both?
I've updated the proposal with OP_GET_IDLE_TIMEOUT and some other details
discussed above.
On Mon, Feb 7, 2022
>> idleTimeout already exists, I don't think we should change the way it
works (or did I misunderstand you?)
If we use new approach, we can reduce this timeout. But this can affect old
clients.
Also, let's think about that sending heartbeats and interval of sending
heartbeats could be calculated
> If we use new approach, we can reduce this timeout. But this can affect
old clients.
idleTimeout is disabled by default, we are not going to change this.
> Also, let's think about that sending heartbeats and interval of sending
> heartbeats could be calculated on the server side (i.e. one third
I see potential in this feature, especially if we use something like
continuous query. Stale clients can consume a lot of resources and it is
worth kick these clients out.
пн, 7 февр. 2022 г. в 18:25, Pavel Tupitsyn :
> > If we use new approach, we can reduce this timeout. But this can affect
> o
A new feedback has been added, go to bugyard.io to see all the details...
https://bugyard.io
A new feedback has been added
"DUDS Account verification. How to reverse SHell ANY/ALL mainframes through
illegal immigration loopholes. DONE" by ianjoe83
View feedback
https://app.bugyard.io/web/
Hi, Igniters!
Hosted by GridGain Systems with the Apache Software Foundation as a
Community Partner, Ignite Summit[1] was the biggest community event in
2021[2][3]. And we will meet again on June 14, 2022, to shine the spotlight
on Apache Ignite! The idea is to share architectural best practices f
Hello,
Flag expand=false is required to support some types of subqueries.
But we can also perform decorrelation explicitly after subquery rewriting.
I've filled the ticket [1].
Thank you!
[1]: https://issues.apache.org/jira/browse/IGNITE-16493
сб, 5 февр. 2022 г. в 14:50, Chang Chen :
> Hi All
ptupitsyn commented on a change in pull request #4:
URL:
https://github.com/apache/ignite-nodejs-thin-client/pull/4#discussion_r801325319
##
File path: api_spec/index.md
##
@@ -0,0 +1,9 @@
+# Node.js Client for Apache Ignite
+
+This thin client allows your Node.js applications
22 matches
Mail list logo
