Thanks Ivan and Denis for clarifying things.
I think we are in good shape :)
Thanks,
Raymond
On Tue, Jun 30, 2020 at 10:29 AM Denis Magda wrote:
> Hi Raymond,
>
> You will not come across any internode-communication issues with your
> deployment configuration as long as the servers and
Hi Raymond,
You will not come across any internode-communication issues with your
deployment configuration as long as the servers and clients are running
withing the K8 environment.
The issue, discussed here, takes place if one of the following happens:
- The clients are deployed in K8 while
Ivan,
Currently we have no requirement to maintain all possible connections
opened. Every node can have arbitrary number of connections to every
other node (it's configurable with "connectionsPerNode" setting).
Also, we can't expect that client would magically open connection when
we need it,
Ivan,
It seems that if a server notices that an existing connection to a
client cannot be used anymore then the server can expect that the
client will establish a new one. Is it just out of current iteration
scope? Or are there still other fundamental problems?
2020-06-29 16:32 GMT+03:00, Ivan
Hi Ivan,
sure, TCP connections are lazy. So, if a connection is not already opened
then node (trying to send a message) will initiate connection opening.
It's also possible that the opened connection is spontaneously closed for
some reason. Otherwise you are right, everything is as you described.
Hi Ivan,
Sorry for a possibly naive question. As I understand we are talking
about order of establishing client-server connections. And I suppose
that in some environments (e.g. cloud) servers cannot directly
establish connections with clients. But TCP connections are
bidirectional and we still
Hi igniters, Hi Raymond,
that was a really good point. I will try to address it as much as I can.
First of all, this new mode will be configurable for now. As Val suggested,
"TcpCommunicationSpi#forceClientToServerConnections" will be a new
setting to trigger this behavior. Disabled by default.
I have just caught up with this discussion and wanted to outline a set of use
cases we have that rely on server nodes communicating with client nodes.
Firstly, I'd like to confirm my mental model of server & client nodes within
a grid (ignoring thin clients for now):
A grid contains a set of
Val,
I like your suggestion about naming, it describes the purpose of the
configuration the best.
On Tue, Jun 16, 2020 at 5:18 PM Ivan Bessonov wrote:
> Hi,
>
> I created new issue that describes CQ problem in more details: [1]
> I'm fine with experimental status and new property naming.
>
>
Hi,
I created new issue that describes CQ problem in more details: [1]
I'm fine with experimental status and new property naming.
[1] https://issues.apache.org/jira/browse/IGNITE-13156
вт, 16 июн. 2020 г. в 02:20, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> Folks,
>
> Thanks for
Folks,
Thanks for providing the detailed clarifications. Let's add the parameter,
mark the new feature as experimental, and target for making it the default
mode in Ignite 3.0.
I still don't think we can come up with a naming that is really intuitive,
but let's try to simplify it as much as
Sergey,
Thanks for the detailed explanation and for covering all corner cases.
Considering the improvement's criticality, I would continue moving in the
initial direction and add that particular configuration property.
Potentially, we can put more effort throughout an Ignite 3.0 timeframe and
Denis, Val,
Idea of prohibiting servers to open connections to clients and force
clients to always open "inverse connections" to servers looks promising. To
be clear, by "inverse connections" I mean here that server needed to
communicate with client requests client to open a connection back
Ivan,
It feels like Val is driving us in the right direction. Is there any reason
for keeping the current logic when servers can open connections to clients?
-
Denis
On Thu, May 21, 2020 at 4:48 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Ivan,
>
> Have you considered
Sorry for me being obnoxious here, but still. Mentioning ticket numbers
usually does not make a lot of sense for someone, who is outside of context
of popular/trendy tickets.
At the same time, usually contributors scan emails in the list using
subject. They decide what should go to archive and
Ivan,
Have you considered eliminating server to client connections altogether?
Or, at the very least making the "client to server only" mode the default
one?
All the suggested names are confusing and not intuitive, and I doubt we
will be able to find a good one. A server initiating a TCP
Ivan,
Considering that the setting controls the way a communication SPI
connection is open I would add the new parameter to CommunicationSpi
interface naming it as follows:
>
> CommunicationSpi.connectionInitiationMode
> {
> BIDIRECTIONAL, //both clients and servers initiate a connection
>
17 matches
Mail list logo
