Hello team,
We use linkerd (linkerd.io) to provide inter-pod SSL encryption in our Azure
Kubernetes cluster, as required by our organization. When we enabled linkerd
in our namespace, we observed that the ignite pods were crashing at startup,
then restarting, and succeeding in connecting with the
Hi,
The K8 IP finder does an equivalent of kubectl get endpoints
and then tries to discover the equivalent nodes based on the results.
see:
No, I don't see other ways to do this transactionally, as CQ itself is not
transactional.
Evgenii
чт, 10 сент. 2020 г. в 00:52, ssansoy :
> unfortunately the 's' on B here can't be derived from a number 0..n - e.g.
> it
> isn't a numeric id.
>
> E.g. in practice lets say:
>
> A is a "Location"
Hi! Just a reminder that we will meet this week.
Hope to see you there.
ср, 26 авг. 2020 г. в 01:26, Saikat Maitra :
> Hi Val,
>
> Thank you for scheduling the meetups. Will join and connect on Ignite 3.0
> release planning.
>
> Regards,
> Saikat
>
> On Tue, Aug 25, 2020 at 4:49 PM Valentin
Hi Denis,
updated - I'm hitting the NPE bug
(https://issues.apache.org/jira/browse/IGNITE-13431) because I'm using
Cassandra as the data store, and key persistence strategy PRIMITIVE in the
original test. When I switched to a composite key, it worked. Not when
this bug gets fixed.
-- this
Hi Denis,
Thank you for your reply.
Restarting all the nodes in the partitioned segment would work for my
usecase.
Is there a way to detect such a scenario with TCP/IP Discovery mode in
Ignite?
In my test I didn't get any EVT_NODE_SEGMENTED events, only EVT_NODE_FAILED.
So the individual
Hi, Am I right that you are using the Azure Kubernetes cluster? If yes, it’s most likely is about the k8s kube-proxy health check probe pinging all open ports including the default thin client one (port 10800). Because of that, Ignite can’t read the message correctly and the
