[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[ https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164204#comment-17164204 ] Aleksey Plekhanov commented on IGNITE-12438: Cherrry-picked to 2.9 > Extend communication protocol to establish client-server connection > --- > > Key: IGNITE-12438 > URL: https://issues.apache.org/jira/browse/IGNITE-12438 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Recently there was quite a lot of questions related to thick clients > connectivity issues when the clients are deployed in a k8s pod [1]. The > general issue here is clients reporting network address which are not > reachable from server nodes. At the same time, the clients can connect to > server nodes. > An idea of how to fix this is as follows: > * Make sure that think clients discovery SPI always maintains a connection > to a server node (this should be already implemented) > * (Optionally) detect when a client has only one-way connectivity with the > server nodes. This part should be investigated. We need this to avoid server > nodes attempt to connect to a client and send communication request to the > client node faster > * When a server attempts to establish a connection with a client, check if > client is unreachable or the previous connection attempt failed. If so, send > a discovery message to the client to force a client-server connection. In > this case, server will be able to send the original message via the newly > established connection. > [1] > https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[ https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155208#comment-17155208 ] Aleksey Plekhanov commented on IGNITE-12438: [~agoncharuk], "Fix version" for this ticket is 2.9, but the patch is not cherry-picked to 2.9 branch. Do you have plans to cherry-pick it? > Extend communication protocol to establish client-server connection > --- > > Key: IGNITE-12438 > URL: https://issues.apache.org/jira/browse/IGNITE-12438 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > Recently there was quite a lot of questions related to thick clients > connectivity issues when the clients are deployed in a k8s pod [1]. The > general issue here is clients reporting network address which are not > reachable from server nodes. At the same time, the clients can connect to > server nodes. > An idea of how to fix this is as follows: > * Make sure that think clients discovery SPI always maintains a connection > to a server node (this should be already implemented) > * (Optionally) detect when a client has only one-way connectivity with the > server nodes. This part should be investigated. We need this to avoid server > nodes attempt to connect to a client and send communication request to the > client node faster > * When a server attempts to establish a connection with a client, check if > client is unreachable or the previous connection attempt failed. If so, send > a discovery message to the client to force a client-server connection. In > this case, server will be able to send the original message via the newly > established connection. > [1] > https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[ https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154610#comment-17154610 ] Alexey Goncharuk commented on IGNITE-12438: --- Merged to master. > Extend communication protocol to establish client-server connection > --- > > Key: IGNITE-12438 > URL: https://issues.apache.org/jira/browse/IGNITE-12438 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > Recently there was quite a lot of questions related to thick clients > connectivity issues when the clients are deployed in a k8s pod [1]. The > general issue here is clients reporting network address which are not > reachable from server nodes. At the same time, the clients can connect to > server nodes. > An idea of how to fix this is as follows: > * Make sure that think clients discovery SPI always maintains a connection > to a server node (this should be already implemented) > * (Optionally) detect when a client has only one-way connectivity with the > server nodes. This part should be investigated. We need this to avoid server > nodes attempt to connect to a client and send communication request to the > client node faster > * When a server attempts to establish a connection with a client, check if > client is unreachable or the previous connection attempt failed. If so, send > a discovery message to the client to force a client-server connection. In > this case, server will be able to send the original message via the newly > established connection. > [1] > https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[
https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154389#comment-17154389
]
Ignite TC Bot commented on IGNITE-12438:
{panel:title=Branch: [pull/7639/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7639/head] Base: [master] : New Tests
(15)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}SPI{color} [tests 6]
* {color:#013220}IgniteSpiTestSuite:
GridTcpCommunicationInverseConnectionEstablishingTest.testClientSkipsInverseConnectionResponse
- PASSED{color}
* {color:#013220}IgniteSpiTestSuite:
GridTcpCommunicationInverseConnectionEstablishingTest.testUnreachableClientInVirtualizedEnvironment
- PASSED{color}
* {color:#013220}IgniteSpiTestSuite:
GridTcpCommunicationInverseConnectionEstablishingTest.testClientWithUnresolvableHostInStandAloneEnvironment
- PASSED{color}
* {color:#013220}IgniteSpiTestSuite:
GridTcpCommunicationInverseConnectionEstablishingTest.testClientReconnectDuringInverseConnection
- PASSED{color}
* {color:#013220}IgniteSpiTestSuite:
GridTcpCommunicationInverseConnectionEstablishingTest.testClientWithUnresolvableHostInVirtualizedEnvironment
- PASSED{color}
* {color:#013220}IgniteSpiTestSuite:
GridTcpCommunicationInverseConnectionEstablishingTest.testUnreachableClientInStandAloneEnvironment
- PASSED{color}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=5b6358e2371-985c5ba9-ec90-4eb7-847a-e30b8fd39f28, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=67fc01f6-9ff5-41d3-bd57-02601835372d, topVer=0, nodeId8=67fc01f6,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594213349041]],
val2=AffinityTopologyVersion [topVer=4920988174019263936, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=5b6358e2371-985c5ba9-ec90-4eb7-847a-e30b8fd39f28, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=67fc01f6-9ff5-41d3-bd57-02601835372d, topVer=0, nodeId8=67fc01f6,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594213349041]],
val2=AffinityTopologyVersion [topVer=4920988174019263936, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b4c13c60-8074-4299-938a-9223d0d8e82c, topVer=0,
nodeId8=f2e421ba, msg=, type=NODE_JOINED, tstamp=1594213349041],
val2=AffinityTopologyVersion [topVer=-9093954929986358400, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b4c13c60-8074-4299-938a-9223d0d8e82c, topVer=0,
nodeId8=f2e421ba, msg=, type=NODE_JOINED, tstamp=1594213349041],
val2=AffinityTopologyVersion [topVer=-9093954929986358400, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=b17df8e2371-b6790362-a7d9-457e-ab95-1bb25562a9b7, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=0a4e0b71-a10e-4470-9662-1a0209621de6, topVer=0, nodeId8=0a4e0b71,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594213405163]],
val2=AffinityTopologyVersion [topVer=3754191324757738430, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=1e17a88e-6bca-4a4c-b5ad-d70eb2045e4b, topVer=0,
nodeId8=52ece4c4, msg=, type=NODE_JOINED, tstamp=1594213405163],
val2=AffinityTopologyVersion [topVer=1476063837119227615, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=1e17a88e-6bca-4a4c-b5ad-d70eb2045e4b, topVer=0,
nodeId8=52ece4c4, msg=, type=NODE_JOINED, tstamp=1594213405163],
val2=AffinityTopologyVersion [topVer=1476063837119227615, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=b17df8e2371-b6790362-a7d9-457e-ab95-1bb25562a9b7, reqs=SingletonList
[ServiceUndeploymentRequest []]],
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[ https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150989#comment-17150989 ] Sergey Chugunov commented on IGNITE-12438: -- [~ibessonov], I reviewed your changes, they look good to me. Do we have a fresh green visa for the latest version of code? When visa is obtained we'll be ready to merge the patch to master branch. Thanks! > Extend communication protocol to establish client-server connection > --- > > Key: IGNITE-12438 > URL: https://issues.apache.org/jira/browse/IGNITE-12438 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Recently there was quite a lot of questions related to thick clients > connectivity issues when the clients are deployed in a k8s pod [1]. The > general issue here is clients reporting network address which are not > reachable from server nodes. At the same time, the clients can connect to > server nodes. > An idea of how to fix this is as follows: > * Make sure that think clients discovery SPI always maintains a connection > to a server node (this should be already implemented) > * (Optionally) detect when a client has only one-way connectivity with the > server nodes. This part should be investigated. We need this to avoid server > nodes attempt to connect to a client and send communication request to the > client node faster > * When a server attempts to establish a connection with a client, check if > client is unreachable or the previous connection attempt failed. If so, send > a discovery message to the client to force a client-server connection. In > this case, server will be able to send the original message via the newly > established connection. > [1] > https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[ https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108388#comment-17108388 ] Denis A. Magda commented on IGNITE-12438: - Ivan, thank you! As this task's description suggests, a server will try to connect to a client anyway through communication SPI before requesting the client (via a discovery message) to establish a connection with the server instead. It means that the client should create a server socket even for EnvironmentType.VIRTUALIZED. At least that was my understanding. The issue described in [IGNITE-13013|https://issues.apache.org/jira/browse/IGNITE-13013] is about the cases when the server must not even try to connect to the client and the client must not open the server socket. Actually, that's the case for this bullet item of this ticket_ (Optionally) detect when a client has only one-way connectivity with the server nodes. This part should be investigated. We need this to avoid server nodes attempt to connect to a client and send communication request to the client node faster_ I'll leave it up to you, you can close IGNITE-13013 and fix the issue as part of this task. Or you can IGNITE-13013 as a sub-task and track those cases separately. > Extend communication protocol to establish client-server connection > --- > > Key: IGNITE-12438 > URL: https://issues.apache.org/jira/browse/IGNITE-12438 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Recently there was quite a lot of questions related to thick clients > connectivity issues when the clients are deployed in a k8s pod [1]. The > general issue here is clients reporting network address which are not > reachable from server nodes. At the same time, the clients can connect to > server nodes. > An idea of how to fix this is as follows: > * Make sure that think clients discovery SPI always maintains a connection > to a server node (this should be already implemented) > * (Optionally) detect when a client has only one-way connectivity with the > server nodes. This part should be investigated. We need this to avoid server > nodes attempt to connect to a client and send communication request to the > client node faster > * When a server attempts to establish a connection with a client, check if > client is unreachable or the previous connection attempt failed. If so, send > a discovery message to the client to force a client-server connection. In > this case, server will be able to send the original message via the newly > established connection. > [1] > https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[ https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107988#comment-17107988 ] Ivan Bessonov commented on IGNITE-12438: Hi [~dmagda], I'll start the discussion soon. Feature is in experimental state in the code because it's still not clear how good this concept will be. BTW, IGNITE-13013 isn't too clear for me - is it any different from the current task? Both require the same thing - providing the ability to have one-way connection from clients to servers, right? > Extend communication protocol to establish client-server connection > --- > > Key: IGNITE-12438 > URL: https://issues.apache.org/jira/browse/IGNITE-12438 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Recently there was quite a lot of questions related to thick clients > connectivity issues when the clients are deployed in a k8s pod [1]. The > general issue here is clients reporting network address which are not > reachable from server nodes. At the same time, the clients can connect to > server nodes. > An idea of how to fix this is as follows: > * Make sure that think clients discovery SPI always maintains a connection > to a server node (this should be already implemented) > * (Optionally) detect when a client has only one-way connectivity with the > server nodes. This part should be investigated. We need this to avoid server > nodes attempt to connect to a client and send communication request to the > client node faster > * When a server attempts to establish a connection with a client, check if > client is unreachable or the previous connection attempt failed. If so, send > a discovery message to the client to force a client-server connection. In > this case, server will be able to send the original message via the newly > established connection. > [1] > https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[
https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107941#comment-17107941
]
Denis A. Magda commented on IGNITE-12438:
-
[~ibessonov], could you please start a discussion on the dev list to discuss
this new API? I'm not sure that 'VIRTUALIZED' is the best name for the feature.
Let's quickly brainstorm with a broader community.
{code:java}
public enum EnvironmentType {
/** Default value. */
STANDALONE,
/** */
VIRTUALIZED;
}
{code}
Also, I see that the feature is planned to be released in the experimental
mode. What needs to be done to make it available in the GA state?
> Extend communication protocol to establish client-server connection
> ---
>
> Key: IGNITE-12438
> URL: https://issues.apache.org/jira/browse/IGNITE-12438
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recently there was quite a lot of questions related to thick clients
> connectivity issues when the clients are deployed in a k8s pod [1]. The
> general issue here is clients reporting network address which are not
> reachable from server nodes. At the same time, the clients can connect to
> server nodes.
> An idea of how to fix this is as follows:
> * Make sure that think clients discovery SPI always maintains a connection
> to a server node (this should be already implemented)
> * (Optionally) detect when a client has only one-way connectivity with the
> server nodes. This part should be investigated. We need this to avoid server
> nodes attempt to connect to a client and send communication request to the
> client node faster
> * When a server attempts to establish a connection with a client, check if
> client is unreachable or the previous connection attempt failed. If so, send
> a discovery message to the client to force a client-server connection. In
> this case, server will be able to send the original message via the newly
> established connection.
> [1]
> https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[
https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079232#comment-17079232
]
Ignite TC Bot commented on IGNITE-12438:
{panel:title=Branch: [pull/7639/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5201750buildTypeId=IgniteTests24Java8_RunAll]
> Extend communication protocol to establish client-server connection
> ---
>
> Key: IGNITE-12438
> URL: https://issues.apache.org/jira/browse/IGNITE-12438
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Recently there was quite a lot of questions related to thick clients
> connectivity issues when the clients are deployed in a k8s pod [1]. The
> general issue here is clients reporting network address which are not
> reachable from server nodes. At the same time, the clients can connect to
> server nodes.
> An idea of how to fix this is as follows:
> * Make sure that think clients discovery SPI always maintains a connection
> to a server node (this should be already implemented)
> * (Optionally) detect when a client has only one-way connectivity with the
> server nodes. This part should be investigated. We need this to avoid server
> nodes attempt to connect to a client and send communication request to the
> client node faster
> * When a server attempts to establish a connection with a client, check if
> client is unreachable or the previous connection attempt failed. If so, send
> a discovery message to the client to force a client-server connection. In
> this case, server will be able to send the original message via the newly
> established connection.
> [1]
> https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
