If a large number of services are registered or subscribed for a High-speed Service Framework (HSF) application developed with Pandora Boot, the startup of the application is slow.
An HSF application developed with Pandora Boot sets a default time period for synchronizing addresses from Config Server for each published (service provider) or consumed (service consumer) service. The default value is 3,000 milliseconds. When a large number of services are published or consumed, each service needs to wait for address synchronization in series, which leads to slow application startup.
- Open the
application.propertiesfile of the Pandora Boot application. Modify the global default synchronization time parameter
spring.hsf.max-wait-address-time(unit: millisecond). For example,
spring.hsf.max-wait-address-time = 500
- A service consumer can also use the
addressWaitTimeparameter to separately set the address synchronization time for a service interface.
During service subscription, the thread is blocked within the time specified by this parameter to wait for address push. Otherwise, the address may not be found due to an empty address when the service is called. This parameter is required for an interface that needs to subscribe to a service when starting a consumer application. We recommend that you set the parameter to 3000 - 5000. Otherwise, the error Error code: HSF-0001 may occur when the application is started. However, when this parameter is set, the startup time of the application is prolonged.
Separately set the address push waiting time
addressWaitTimein milliseconds for a service consumer interface in an application.
- Alternatively, in the
application.propertiesapplication configuration file, separately set
spring.hsf.max-wait-address-times. <complete service interface name>=<address push waiting timefor a service interface, in milliseconds.
- If you set the spring.hsf.max-wait-address-time parameter and then restart the application,
but the startup of the application is slow, you can analyze the thread stack on the
application being started (for example, jstack <application JVM process ID> >> threaddump.txt)
and the logs in