Binding thing handler thread locking on Jetty client stop

I developed a binding for my Hayward pool controller. After running for a day or two it really starts to bog down. It has a polling event that queries a cloud server every 12 seconds using Jetty. What I’m finding is that the jetty httpclient.stop command is locking up the thread even with a try/catch statement. Openhab then starts using additional thinghandler threads to handle the polling, all of which lock up and wait on the first locked thread since the polling routine is synchronous. I’m working on getting this code up to GitHub and ready for review, but was hoping somebody might have run across this in the past.

HaywardBridgeHandler.java:1244 is the client.stop() command.

private void stopHttpClient(HttpClient client) {
if (client != null) {
client.getAuthenticationStore().clearAuthentications();
client.getAuthenticationStore().clearAuthenticationResults();
if (client.isStarted()) {
try {
client.stop();
} catch (Exception e) {
logger.error(“Could not stop HttpClient”, e);
}
}
}
}

“OH-thingHandler-2” Id=240 in RUNNABLE
at org.eclipse.jetty.util.component.ContainerLifeCycle.getBean(ContainerLifeCycle.java:588)
at org.eclipse.jetty.client.HttpDestination.doStop(HttpDestination.java:118)
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:93)
- locked java.lang.Object@3fe7c2
at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:180)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:201)
at org.eclipse.jetty.client.HttpClient.doStop(HttpClient.java:268)
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:93)
- locked java.lang.Object@d85cd3
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.stopHttpClient(HaywardBridgeHandler.java:1244)
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.httpXmlResponse(HaywardBridgeHandler.java:1176)
- locked org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler@19756bb
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.getTelemetryData(HaywardBridgeHandler.java:552)
- locked org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler@19756bb
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.lambda$0(HaywardBridgeHandler.java:944)
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler$$Lambda$479/20738068.run(Unknown Source)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

###############################################################################
############### openhab #####################################################
###############################################################################

Ip = 10.0.5.183

Release = Raspbian GNU/Linux 10 (buster)

Kernel = Linux 4.19.97-v7l+

Platform = Raspberry Pi 4 Model B Rev 1.1

Uptime = 8 day(s). 20:40:42

CPU Usage = 25.06% avg over 4 cpu(s) (4 core(s) x 1 socket(s))

CPU Load = 1m: 0.95, 5m: 1.04, 15m: 1.05

Memory = Free: 2.50GB (65%), Used: 1.35GB (35%), Total: 3.86GB

Swap = Free: 0.09GB (100%), Used: 0.00GB (0%), Total: 0.09GB

Root = Free: 22.33GB (80%), Used: 5.53GB (20%), Total: 29.07GB

Updates = 12 apt updates available.

Sessions = 1 session(s)

Processes = 124 running processes of 32768 maximum processes

###############################################################################

It’s been a while since I messed with the Jetty client, but as I recall you shouldn’t need to call stop() very often. You should probably just be calling start() when the binding initializes and stop() when it is shutting down. If you can make use of the shared Jetty instance, you may not even need to do that.

I’d you use the common httpclient as provided by openHAB httpClientFactory.getCommonHttpClient() you should neither call start or stop.

P.s. please use code markers, like ``` before and after code blocks/stacktraces