Browse Prior Art Database

A method to solve multiple threads out of sync issue due to JVM Garbage Collection in HMC and cloud computing environment

IP.com Disclosure Number: IPCOM000238581D
Publication Date: 2014-Sep-04
Document File: 3 page(s) / 99K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method to solve multiple threads out of sync issue due to JVM Garbage Collection Pause times in a Hardware Management Console (HMC) and a cloud computing environment is disclosed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 01 of 3

A method to solve multiple threads out of sync issue due to JVM Garbage Collection in HMC and cloud computing environment

Disclosed is a method to solve multiple threads out of sync issue due to JVM

® Garbage Collection pause times in a Hardware

                                                      ® servers, which sends requests and retrieves responses to and from the Power servers. The current model of handling the requests and responses is, after a thread (thread A) sends the request to the server, it registers its requests in a correlation table and it waits for the server to respond. So thread A will be put into sleep state during the waiting. Another thread (thread B) which is always running, is responsible for handling all the responses coming from the server. When thread B sees a response from the server, it finds the request entry from the request table based on a correlation id and put the response in the request entry as the new value of the response property (the old value is null). After that it will get the command token and wake up the waiting thread (Thread A is waiting on that token). Thread A also gets the request entry based on the correlation id and tries to get the response data from the request entry. If the response data is not there, it will consider the operation failed. Thread A could also be awakened when its sleeping time has reached its time-out, it will also check the response data and determine if it can continue the task or should fail the task. Figure 1 illustrates this current model.

Figure 1

HMC threads run in JVM and JVM does Garbage Collection (GC) sometimes. Usually GC shouldn't affect running threads, however, it's been discovered that occasionally it does put all the threads on hold for seconds or even minutes. When GC is done, the threads will be resumed by JVM. The order of resuming threads is out of HMC's control, and if, in the above model, JVM resumes threads while thread A is sleeping, it could cause a serious problem for the HMC, because, thread A could be resumed before thread B is resumed.

When thread A is resumed by JVM, it will try to get the response data from the request entry. If thread B hasn't been resumed yet, it will not get the response it needs and will fail the operation.

In a multiple-threads environment, this could mean that lots of threads may fail because of threads execution ordering is messed up by the JVM GC. This is also a common issue in cloud computing environment, because cloud computing environment is a heavy multi-threading environment and the interactions between threads are critical to tasks.

The main idea to the solution, is that after thread A is awakened, if it's not awakened by thread B, it needs to first figure out if JVM GC has occurred. And the second is if thread A suspects itself is resumed by JVM (rather by real time-out), it needs additional sleep time. That will give thread B extra time to be resumed and to put the response in the request entry.


1) The first step is to determine if JVM GC has o...