Problem shutting Zowe 33 down

[colinpaicemq]

Describe the bug
A clear and concise description of what the bug is.

I shutdown Zowe 33

I get

13:53:22.77 COLIN 00000290 P ZOWE33
13:53:22.78 STC04212 00000090 +ZWEL0008I stopping components
13:53:25.85 STC04212 00000090 +ZWEL0002I component apiml stopped
13:53:26.40 STC04212 00000090 +ZWEL0022I Zowe Launcher stopped

13:53:29.68 00000281 IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=0054.
13:53:31.49 COLIN 00000290 D A,L
13:53:31.50 COLIN 00000090 CNZ4105I 13.53.31 DISPLAY ACTIVITY 799
...
799 00000090 ZOWE33I ZOWE33I ZWESIS01 NSW SO ZOWE335 *OMVSEX ZWESVUSR OWT AO
799 00000090 ZWE33AG STEP1 ZWESVUSR IN AO IBMUSER9 STEP1 IBMUSER OWT AO
799 00000090 COLIN IN IBMUSER OWT O

Which eventually ends..... This I could tolerate... but I got in the ZW33AG output

ZWEAGW1:SpringApplicationShutdownHook:67174498 [35mZWESVUSR [0;39m
[36mERROR [0;39m ((c.n.e.r.PeerAwareInstanceRegistryImpl)) Cannot
shutdown ReplicaAwareInstanceRegistry

java.lang.NullPointerException: Cannot invoke
"com.netflix.eureka.cluster.PeerEurekaNodes.shutdown()"
because "this.peerEurekaNodes" is null

at com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl.shutdown(PeerAwareInstanceRegistryImpl.java:177)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:586)
at org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:316
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:249)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:798
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.jav
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:14
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.ja
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:1
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1219)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1180)
at org.springframework.boot.web.reactive.context.ReactiveWebServerApplicationContext.doClose(ReactiveWebServerApplicationCo
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:1126)
at org.springframework.boot.SpringApplicationShutdownHook.closeAndWait(SpringApplicationShutdownHook.java:147)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at org.springframework.boot.SpringApplicationShutdownHook.run(SpringApplicationShutdownHook.java:116)
at java.base/java.lang.Thread.run(Thread.java:1595)

Which looks more of a problem... and may explain why the ZWE33AG didnt shutdown quicker.

[pavel-jares-bcm]

This is a bug in the transitive dependency (Eureka). It could happened during the shutdowning of Eureka. It is trying to close a resource that was even not created. It has no impact to the application, just generates this log message. As you can see in the source code (link bellow) the exception is catch, logged and then not propagated. It means the delay is really short (writting the log message is the most complicated part).

The class PeerAwareInstanceRegistryImpl is used internaly, therefor it is very complicated to override the method. Also fix this issue in the original source code is complicated for its maintaing. I guess, only one possible solution is to hide/ignore this message (e.g. by a TurboFilter).

The source that generates the message:
https://github.com/Netflix/eureka/blob/015400c60d3dc730c3fc4871e9b586d3805cce0d/eureka-core/src/main/java/com/netflix/eureka/registry/PeerAwareInstanceRegistryImpl.java#L175-L179

[balhar-jakub]

@pj892031 This sounds like another support argument for forking the Eureka and take it under ourselves and improve on some of the behaviors there.