0

I am using Tile38 inside a docker container in order to perform geospatial queries. It is a Redis like server that boots up and attaches itself to a primary server and replicates the primary servers data.

The problem is that the clients connecting to the redis(like) server (using Redis libraries) don't comprehend that when the server is booting up and replicating that it is not ready to process data even though it will accept connections and respond to any request with an LOADING: Catching up to leader error. This causes tons of errors in my clients when they could have just connected to another replica in the pool and gone about their day but wont because this server is available.

I've been writing a wrapper service around Tile38 in order to handle these differences in behavior between a real Redis client and Tile38 but i'm stuck on this one.

My wrapper service knows when the server is up and ready to accept connections so my thought is to start the server up with the incoming ports blocked until its all caught up. At which point it will unblock the ports and allow incoming connections.

I've tried IPTABLES commands but they always say not authorized even when i'm executing my entrypoint service as root. Is there anything i can do to drop connections until i give the all clear?

Chris Rice
  • 728
  • 2
  • 9
  • 32
  • 1
    If (a) you're writing a "wrapper" service and (b) your clients are connecting to the wrapper, then simply don't have the wrapper open a listening socket until you've verified that Tile38 is ready to process queries (by making some sort of periodic sample query). – larsks Jun 24 '23 at 20:27
  • You've tagged this with `kubernetes`; if you're actually using Kubernetes, then the correct solution is to add a [readinessProbe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) to the Pod; as long as the readinessProbe is failing, the Pod won't receive any traffic from an associated Service. – larsks Jun 24 '23 at 20:28
  • I actually do plan on running kubernetes. Thats perfect! – Chris Rice Jun 24 '23 at 20:51
  • The wrapper isn't actually a wrapper i guess. Its a manager. It starts, monitors the log output, and handles a bunch of conditions gracefully. I guess i could to a port change and then have the manager front the main traffic too... – Chris Rice Jun 24 '23 at 20:53
  • At the very simplest, the manager could start socat to forward TCP from one port to another: https://stackoverflow.com/questions/34791674/socat-port-forwarding-for-https This doesn't require any administrator privileges. That does have the disadvantage that Tile38 will think that all requests are coming from localhost. – Nick ODell Jun 24 '23 at 20:56

0 Answers0