Configuration calculation takes too long and causes config XML files not to save

[RPRoberts]

Prerequisitives

• Eclipse Version: 4.12 (used both platform and committers bundles found on release page)
• FeatureIDE-Version: 3.6
• Operating system: Windows 10
• Java runtime used to run eclipse: jre1.8.0_221
• FeatureIDE Composer: Add text here (optional, leave blank if not needed)
• Git branch/Commit-ID: Add text here (optional, leave blank if not needed)
• Java compiler used to build the FeatureIDE plugin: Add text here (optional, leave blank if not needed)

Issue description

While using the configuration editor, the plugin runs the calculation for validity checks and number of the remaining option permutations every time you check a box in the configuration. I've used task manager to see that checking a single box when using a model with 25+ features will cause my CPU to spike to 100% and stay there until the calculation is done (15+ seconds in some cases early on when 100k+ combinations are possible still). During this time, if I try to save the config XML file and close the XML (or move to another config tab), the changes I just made were lost. Is it possible to move calculations to be a manual option to avoid this behavior on lower end machines?

[RPRoberts]

I just tried the same feature model in the 3.5.5 platform bundle release and it calculates almost instantly. I've attached my default feature model that I used for the testing below that shows the differences between 3.5.5 and 3.6.0.

Steps to reproduce:

1. open config "default.xml"
2. On "Configuration" tab, check "NewFeature1" under the "Base" feature
   2a. 3.5.5 will show "valid, more than 3166 possible configurations"
   2b. 3.6.0 will show "valid, more than 525447 possible configurations"

test1.zip

[tthuem]

Thanks @RPRoberts for reporting this critical bug. It sounds as if the timeout for calculating the number of remaining, valid configuration has increased accidentially from milliseconds to seconds.

@PaulWestphal @subaro Who of you can work on this issue?

[jsprey]

@tthuem Your assumption was right. The problem was the timeout. Instead of setTimeoutMs() setTimeout() was used that receives the timeout in seconds. Should be fixed with the following commit. I also created a test to verify the timeout of the solver.

[jsprey]

2fd07a0