Hi ,
thanks for the configs. In your config you have length=200 with the “markers”. What is the true configuration? Most importantly, how many data things you have? How many pollers with what configuration? I don’t understand how the true configuration has been modified for the thread post?
I have seen similar issue with my testing but there the queue sizes were much smaller and thus not an real issue (see explanation below).
I presume the queue is getting large due to openHAB requesting refresh on startup, when the things are introduced to the system. Basically, all the data things receive REFRESH command to the channels bound to items.
Can you provide verbose logs (see logging guide in docs), starting from openHAB startup, so I can confirm this “theory”?
The openHAB core sends REFRESH command to each of the data things. Each command translates to one modbus request, explaining the large queue size.
The queue size should decrease over time. In your case with 35ms between requests, queue of 3000 requests takes around 1.5 minutes to clear. This is quite a long time.
The poll period should not make a difference here, I think. However, if you are sending commands to modbus items (writing to modbus) within rules with fast pace, the queue can and will increase as well.
Can you observe that queue size decreases over time? Check how the number in the log message evolves using this console command `log:tail | grep ‘tasks queued’
Old binding does not have this issue since it did not support concept of REFRESH at all.
Unfortunately, I don’t have a workaround for you in this case. I appreciate if you can provide the logs and provide answer to the above points so we get a comfirmation on this. I probably need to consult the openHAB maintainers as well the best/cleanest way to solve this.
Best
Sami