Preparation for 2.5M2

I understand, the problem is my system is critical and I can’t keep it broken for long.
I will copy everything to another machine and try again. I will report about it later.

Issue to be fixed before 2.5M2 :

3 Likes

The problem with the startup of the Z-Wave binding is now solved in snapshot 1650, even if the Z-Wave binding is still missing a reconnection feature.

3 Likes

Good to hear.
The other Z-Wave issue seems to have been there even before M1 and the migration script for the new rule engine is in development (testers welcome!).
Hope we’re getting there :grinning: [compare tracking]

2 Likes

The addons build seem to fail for three days now. https://ci.openhab.org/job/PR-openHAB2-Addons/

@lsiepel That is only for PRs so no need to worry
The relevant build is the sandbox which has been all green. Yesterday it was red. But looking into the logfiles it seems that the build has just lost a connection at some place, so I guess/hope it will return to green tomorrow.

The heal problem is new unfortunately. I will try to look at this soon but am still fighting with the IDE on a daily basis and I am away next week.

1 Like

Are you still having this issue? If so, can you try changing the number of quartz scheduler threads? In runtime/etc/quartz.properties, increase the value of this parameter, then restart openHAB. Change the 2 to something greater, maybe 10.

org.quartz.threadPool.threadCount = 2

I use this version: 2.5.0.201907230434 and I do not have any problem with network heal. Mutch better than it was in 2.4.0.

I’ve had that setting changed for some time now. My thread settings are set in services/runtime.cfg. I modify the following:

org.eclipse.smarthome.threadpool:thingHandler
org.eclipse.smarthome.threadpool:discovery
org.eclipse.smarthome.threadpool:safeCall
org.eclipse.smarthome.threadpool:ruleEngine
org.eclipse.smarthome.threadpool:org.quartz.threadPool.threadCount

org.eclipse.smarthome.webclient:minThreadsShared
org.eclipse.smarthome.webclient:maxThreadsShared
org.eclipse.smarthome.webclient:minThreadsCustom
org.eclipse.smarthome.webclient:maxThreadsCustom

org.jupnp:threadPoolSize
org.jupnp:asyncThreadPoolSize

org.apache.felix.eventadmin.impl.EventAdmin:org.apache.felix.eventadmin.ThreadPoolSize
org.apache.felix.eventadmin.impl.EventAdmin:org.apache.felix.eventadmin.AsyncToSyncThreadRatio

The only question I’ve ever had is if there is an upper limit on the number of threads that can be allocated.

I’m not fully convinced that setting org.eclipse.smarthome.threadpool:org.quartz.threadPool.threadCount in runtime.cfg has an effect. How are you determining that quartz is actually using the increased size of the thread pool from runtime.cfg?

Also see my analysis starting here. I definitely can reproduce sequential rule execution behavior using cron triggers.

To resolve the issue, I first tried changing runtime.cfg. I didn’t restart after making the change, as that generally is not necessary when changing runtime.cfg (of course, this specific setting may be an exception). When that didn’t work, I changed quartz.properties, and it had the desired effect.

1 Like

I verified it through the karaf console. “config:list | grep quartz” shows the setting as changed.

Ok. That will show that the setting has changed. But, it doesn’t necessarily prove that the quartz scheduler is actually picking up and using that setting.

Could you humor me and try changing quartz.properties (followed by a restart)? It will help rule in or out that the issue I found is the cause of the issue you’re having. Of course, the root cause of your issue could be something completely different.

I’ll adjust it in quartz.properties and report back. It is somewhat concerning if this doesn’t apply the configuration.

Thanks!

Totally agree!

Ok, ya got me. Why did that matter?

I ran 4 tests. One on defaults. One on each config method. And one both for good measure. It seems that each one fixed a different thing. Having both (configured identical) seems to actually work the best. So, why?

Short answer. I don’t know.

I can find anywhere in the code that deals with the config parameter you’re setting in runtime.cfg. Not saying it’s not there. I just can’t find it.

I’m much more confident in the parameter in quartz.properties, which is why I suggested that you change it. :wink:

I have no explanation for this. I need to ping @Kai to see how he’d like to handle it. At a minimum, I’d suggest increasing the threadCount in quartz.properties. Oddly, the test case for that component used a threadCount of 10, yet it’s set to 2 in the distribution. :confused:

In any event, I’m glad that helped get your issue sorted out.

1 Like

Then let me say that it’s not there.

I have no explanation for this. I need to ping @Kai to see how he’d like to handle it.

I do not have any explanation why changing a non-existent parameter could make any difference.

At a minimum, I’d suggest increasing the threadCount in quartz.properties .

I’ve created https://github.com/openhab/openhab-distro/pull/952, but note that this has been 2 since the beginning, so we cannot be talking about a regression since M1 here.

Looking at https://github.com/openhab/openhab-distro/projects/2, it seems that everything is sorted out - excellent!

I’ll be offline the next two days (no Internet at all), so I’d suggest that we schedule the M2 build for Wednesday. If anyone has another blocking issue, please speak up until then!

6 Likes

I’m sorry, at first I was a little underwhelmed at reading this… then I thought about it…
OpenHAB 2.5M2 build… Wednesday
yes YES
:+1:
Great job everyone getting the build running again!!!
Great job Scott with this thread and tracking all the issues in preparation for this
great to see the milestones kicking off again and hopefully they will be coming on a regular schedule moving forward

1 Like

Do we have any idea how many milestones before release?
I know, users always want more. We are behind “schedule”, though.