Sure:
IEP :
https://cwiki.apache.org/confluence/display/IGNITE/IEP-112+Thin+Client+Service+Awareness
Ticket: https://issues.apache.org/jira/browse/IGNITE-20656
On 26.10.2023 18:15, Pavel Tupitsyn wrote:
Vladimir, could you please share the new IEP link here, and also link it to
the ticket?
On Thu, Oct 26, 2023 at 1:30 PM Vladimir Steshin <vlads...@gmail.com> wrote:
Roman, hi.
Done. Thanks!
On 26.10.2023 13:25, Roman Puchkovskiy wrote:
Hi Vladimir. Sorry to intervene, but we have a clash with IEP numbers,
there is already IEP-110 in Ignite 3, it was created on August, 1:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes
Is it possible to pick another number, while your IEP is fresh?
чт, 26 окт. 2023 г. в 14:05, Vladimir Steshin <vlads...@gmail.com>:
All right. Pavel, thank you.
IEP:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110+Thin+Client+Service+Awareness
Ticket: https://issues.apache.org/jira/browse/IGNITE-20656
On 25.10.2023 11:04, Pavel Tupitsyn wrote:
Looks good to me
On Tue, Oct 24, 2023 at 1:50 PM Vladimir Steshin <vlads...@gmail.com>
wrote:
We've privately discussed with Mikhail Petrov and Alexey
Plekhanov.
To us, #2 seems OK with the exceptions that a dedicated request would
be
better for transferring the service topology. And it should be
processed
by the client instead of every service proxy.
So, the suggested solution is:
1) Bring a new feature to the thin client protocol.
2) Require the partition awareness flag enabled.
3) Obtain service topology with a dedicated request by the client and
provide it to the service proxies.
4) Initiate the topology update with: first service invocation,
cluster
topology change, some timeout (only if service is invoked).
Cons:
- Some delay of the topology obtaining. The invocation redirects
are
still possible when service migrates.
- No sign of service cancel/deploy on the client side. We have to
update by a timeout too.
- The topology is probably kept by client while it exists even if
is
not in use any more.
If the suggestion looks reasonable, I'm ready to implement, create
IEP.
On 17.10.2023 18:28, Vladimir Steshin wrote:
They barely can guarantee. If client miss service instance
node,
the request is just redirected. But I talk about the most reliable
way
to keep actual service topology. If we watch cluster topology change
event, we have to take in account cases like:
- Client request service, gets its topology
- The service is canceled and redeployed to another nodes. No cluster
topology change, no sign of it on the client side.
- Client continue service requesting and misses instance node forever
or often.
If we provide, for example, version or hash of client topology
version
in every service call request, we always get actual service topology
just by comparing on server side. Independently of why and when
service redeploys. Isn't it simple and safe?
On 17.10.2023 15:52, Pavel Tupitsyn wrote:
None of the described approaches provides 100% guarantee of hitting
the
primary node in all conditions.
And it is fine to miss a few requests. I don't see a reason to
increase
complexity trying to optimize a rare use case.
On Tue, Oct 17, 2023 at 2:49 PM<vlads...@gmail.com> wrote:
What if topology change event preceedes service redeployment and
service
mapping change? There a possibility for client to save new topology
version
before services are actually redeployed. If we rely on actual
change
of the
service mapping (redeployment), there is no such problem.
On 17.10.2023 13:44, Pavel Tupitsyn<ptupit...@apache.org> wrote:
I think if it's good enough for cache partition awareness, then
it's
good
enough for services. Topology changes are not that frequent.
On Tue, Oct 17, 2023 at 12:22 PM<vlads...@gmail.com> wrote:
Hi, Pavel.
1. Correct.
2. Yes, client watches ClientFlag.AFFINITY_TOPOLOGY_CHANGED flag
and
sends
additional ClientOperation.CLUSTER_GROUP_GET_NODE_ENDPOINTS to
get
new
cluster topology. Thus, the topology updates with some delay. We
could
watch this event somehow in the service proxy. But direct service
topology
version in the call responses should work faster if service is
being
requested. Or you think this is not significant?
On 17.10.2023 11:13, Pavel Tupitsyn<ptupit...@apache.org>
wrote:
Hi Vladimir,
1. A topology of a deployed service can change only when the
cluster
topology changes.
2. We already have a topology change flag in every server
response.
Therefore, the client can request the topology once per
service, and
refresh it when cluster topology changes, right?
On Mon, Oct 16, 2023 at 8:17 PM Vladimir Steshin<
vlads...@gmail.com
wrote:
Hi Igniters! I propose to add the /service awareness feature
to the
thin
client/. I remember a couple of users asked of it. Looks nice
to
have
and simple to implement. Similar to the partition awareness.
Reason:
A service can be deployed only on one or few nodes. Currently,
the
thin
client chooses one or a random node to invoke a service. Then,
the
service call can be always or often redirected to other server
node.
I
think we would need: - Bring a new feature to the thin client
protocol
(no protocol version change). - Require the partition awareness
flag
enabled (it creates required connections to the cluster). -
Transfer
the
service topology in the service call response (server node
/already
holds /needed service topology).
- Keep the service topology in the client service proxy. If
that is
ok,
my question is /how to update service topology on the client/?
I see the options: 1) Add a version to the service topology on
the
server node and on the client service proxy. Add actual service
topology
to the service call response if actual>client.
/Pros/: Always most actual service top. version
/Cons/: Requires holding and syncing top. version on server
nodes
only
for the thin clients.
2) Add the actual service topology to the service call response
only
if
service is not deployed on the current node. The client
invalidates
received service topology every N invocations and/or every N
seconds
(/code constants/).
/Pros/: Simple.
/Cons/: Actual topology delays. Not the best load balancing.
3) Send from client a hash for the known service nodes UUIDs in
every
service call request. Add actual service topology to the
service
call
response if the server's hash is not equal.
/Pros/: Simple. Always most actual service topology.
/Cons/: Costs some CPU sometimes.
WDYT?
