Enhancement
Major
Detail
Bugfix
Detail
#26484
In-app template for grid and tables: Function "Verifier for use as list item" does not get component model
#26885
Constraints on declarative forms with arguments from a container reference lead to errors for new elements
#26922
With generated subject classes, a default provider of an attribute in a non-structure class does not get a create context
Bugfix
When the application is started, a lock is requested to prevent multiple nodes from starting at the same time in cluster operation and performing initialization work at the same time.
Currently the timeout for this lock is configured inconsistently. The timeout for the lock is 30min, but the startup waits only 10min to get the lock. If a startup fails and a lock remains in the database, the next and next but one startup will surely fail as well.
Improvement
The waiting time for a startup lock must be at least as long as the timeout for the lock. It may be useful to configure the wait time longer than the lock timeout if multiple cluster nodes are starting.
Cf. tl:StartStopListenerConfig, tl:ConfiguredLockService
Test
- To reproduce the problem in the development environment the settings in /com.top_logic/src/main/webapp/WEB-INF/conf/devel-ephemeral-locks.config.xml must be commented out (otherwise the application will not have persistent locks).
- Start application and kill it during the startup process.
- Restart the application.
- The application must produce log messages of the type Could not lock startup token sleeping 10 sec.
- After 10min the application must start (new lock timeout for the startup token).