Resolve spinlock issue in AcceptorExecutor thread

[larosek]

I ran into an issue where an AcceptorExecutor thread would not shutdown and was using 100% cpu. This thread shutdown will happen when a PeerEurekaNode is removed from the list of nodes.

Here is a snippet of the thread dump:

"TaskAcceptor-target_ec2-xx-xx-xx-xxx.compute-1.amazonaws.com" - Thread t@47
   java.lang.Thread.State: RUNNABLE
	at com.netflix.eureka.util.batcher.AcceptorExecutor$AcceptorRunner.drainInputQueues(AcceptorExecutor.java:234)
	at com.netflix.eureka.util.batcher.AcceptorExecutor$AcceptorRunner.run(AcceptorExecutor.java:189)
	at java.base@11.0.7/java.lang.Thread.run(Thread.java:834)
   Locked ownable synchronizers:
	- None

You can see in the heap dump screenshot below that shutdown was properly called and received by the thread. Also, you will notice that all 3 queues (reprocessQueue, acceptorQueue and pendingTasks) are empty, causing the drainInputQueues while loop to get stuck.

If you were to be unlucky, when shutdown was called, you could fall into a condition where nothing was added to the pendingTasks queue and both reprocess and acceptor queue would stay empty since the executor was shutdown.

I did a quick and dirty unit test locally to reproduce the issue, but since this is a timing issue, the test would sometime pass without the fix in position. Of course, when the fix was there I was not able to make the test fail. Because of that, I decided not to add the unit test since it was not very robust. Let me know if you have an idea on how to elegantly test this! Thanks!

[troshko111]

Yeah the way it is today is a while(true) loop which does not have an exit condition when the shutdown is set but pending is empty, so the outer loop never gets a chance to check and exit. Thanks for the PR!