Connecting to backup source multithreading

Hello (Using the JAVA SE Client 4.3.8)
I have a use case where I am connecting to a primary source and, upon connection errors, disconnect the client and switch to a backup connection. However, I ran into the problem since the ClientListeners are single threaded. If I switch to an alternate connection directly from the ClientListener like so...
onStatusChange(String status)
case DISCONNECTED:
clientHandler.switchToAlternateConnection()

Then I reconfigure the connection details of my client, remove the old listener, add a new ClientListener and then attempt to start the new connection, waiting to continue with setup until my client listener receives a status update "CONNECTED:WS-STREAMING". However, due to the single threaded nature of the listeners, my waiting thread is identical to the thread which would theoretically receive the updated status, hence it times out.

My solution was utilizing a new thread for my connection switching, i.e.
onStatusChange(String status)
case DISCONNECTED:
new Thread(clientHandler::switchToAlternateConnection) .start()

however I am wary about spawning new threads. Is this expected behaviour I am seeing and handling or am I doing something wrong? Any help would be appreciated.

What does the method switchToAlternateConnection do exactly?
Does it call a blocking operation such as wait() or similar commands?

Indeed you don’t need to block a thread in order to wait for the connected status. You can simply create a new client (or reuse the old one) and register a ClientListener.

For example:

Code:

---

void onStatusChange(String status) {
  switch (status) {
  case "DISCONNECTED":
    var newClient = new LightstreamerClient(...)
    newClient.addListener(
      void onStatusChange(status) {
        switch (status) {
        case "CONNECTED:WS-STREAMING":
          // complete the configuration
        }
      })
    newClient.connect()
  }
}

---

Since the methods of LightstreamerClient are asynchronous and reentrant, they work as expected.

Hey, thank you for your reply. Yeah, the thread is calling a blocking command because I have a timeout mechanism that gives the new client only a certain amount of time to reconnect. So its like::

ClientListener:

Code:

---

case "DISCONNECTED":
    clientHandler.switchConnection()

---

ClientHandler:

Code:

---

switchConnection():
// configure client with new connections
client.add(new ClientListener(CountDownLatch) )------> Upon receiving status "CONNECTED: WS-STREAMING" it counts down the latch
client.connect()
if (!countDownLatch.wait(timeoutTime)) {
    // throw error, couldn't connect
}

---

Since the Lightstreamer Client API is asynchronous, blocking its threads can have unexpected results.
However you can set a timeout by using a java.util.Timer (or equivalent asynchronous mechanism).
For example:

Code:

---

var client = new LightstreamerClient(...)
Timer timer = new Timer();
timer.schedule(() -> {
  if (!client.getStatus().startsWith("CONNECTED")) {
    client.disconnect();
  }
}, TIMEOUT);
client.connect();

---

Right, ok. Well thank you for your help. I think at the end of the day I can't call my switch connection startup method directly from the listener because even if I do as you suggested with a timer then the server I am connecting to uses a chain of subscriptions (i.e. one subscription relies on processing the snapshot from the previous one) so I will need the dedicated listener thread to be available while going through the subscription process to receive the updates.

Thanks!