Removing GZIP encoding From mocked service in SOAPUI

For testing purpose, in SOAPUI I mocked an external SOAP interface feedback an expected response.

I met such an exception:  I/O error: Not in GZIP format

The reason: client doesn't require a GZIP format. The way to remove the GZIP encoding is presented as the following screen dump.

press button "on-request-script", and add in the following headers; then the response encoding will be removed.

headers = mockRequest.requestHeaders;
headers.remove("Accept-Encoding");

Threads

Concept of Thread 

The thread is a lightweight process, making good use of multiple cores and slices of CPU time, running several tasks simultaneously. 

Difference Between Process and Thread: 
Different processes cannot share a common memory space(variables and data object), but threads share variables (static and instance) and data objects.

The above leads to the major issue due to concurrent modification on shared variables and data objects, i.e. how to safeguard shared data and read them out consistently.

Defining a Task

Declaring a new runnable class by implementing a runnable interface, 

class DataSaver implements Runnable{
@override
public void run(){......}
}

Thread is allowed to be extended to run an expected task in this thread; however, this will mix the thread and task together. So this pattern is not suggested.

class UploadFile extends thread{
@override
public void run(){ .....}
}

Thread implements the Runnable interface. So a thread is runnable, which can be contained in a thread, and being put in a JVM.

 //creating a new thread instance.
Thread t = new Thread(new UploadFile());

//executing a thread
t.start();

End of Thread
When run() has been accomplished, then the thread is at the end of execution. Don't use the deprecated method stop() to stop a thread run(). 

When stopping a thread, just point the thread to null.

Thread Life Cycle

A thread life cycle contains states, i.e. NEW, RUNNABLE, TERMINATED, WAITING, TIMED-WAITING, BLOCKED, where RUNNABLE consists of two states, i.e. READY, and RUNNING. 

NEW:  a thread is created, but not started yet.

RUNNABLE:(READY or RUNNING) a thread is executed in JVM

BLOCKED: a thread is blocked and waiting for a monitor lock.

WAITING: a thread waiting for another thread to perform a particular action. 

TIMED_WAITING: a thread waiting for another to perform a particular action for a specified time.

TERMINATED: a thread's run method having been accomplished;

Thread Scheduler:
It depends upon the underlying OS. Scheduler decides when to pick up a thread and make it running in JVM, but not a developer. So a thread running may feel like randomly.

When a thread start() method is called, it moves a thread from NEW to RUNNABLE_READY. The underlying scheduler moves a thread from READY to RUNNING, vice versa. Even we set a thread as the highest priority, it won't guarantee to make it running at once. The thread scheduler may ignore the thread that having the highest priority. In some sense, threads run randomly. When a thread runs out a sliced time of CPU, the thread scheduler may suspend this thread until a next time slice available.

Thread Static Methods:
Yield(): it is not guaranteed. It makes a current thread to give up its CPU time.
Sleep(): it is guaranteed to move the current thread from RUNNING to READY for a specific period.

currentThread(): get current thread. 

Thread Instance Methods:
Join():  making invoker's thread waiting the invoked thread until it accomplishes run body, thus invoker proceed to accomplish its own. Join() throws unchecked InterruptedException.

interrupt(): making invoker to ask the invoked thread to terminate. 

Object Instance Methods:
Wait(): pause Object's execution and wait for another object, i.e. moving to the READY state
Notify(): waking up one waiting thread back to RUNNABLE.
NotifyAll(): waking up all waiting threads back to RUNNABLE.

wait(), notify, and notifyAll() must be called in a synchronized method or code block; or an IllegalMonitorStateException will be thrown.

How to Protect Data and Object Shared by Thread
Unlike the regular process, threads are lightweight processes. They share certain memory areas. When multiple threads access common data variable or objects, we need to consider how to keep their states consistent. You may protect your shared data by (1) restrict it accessible only to one thread at one moment; (2) make objects immutable  (3) declaring volatile variables.

How an object is protected? 
Using a keyword 'synchronized' to achieve an object's lock. Each Java object is associated with a monitor, which can be a lock or unlocked by a thread. And, only one thread can hold its lock. By this way, the object can be read or write by one thread, so that the data cannot be polluted.  When this thread carried out a read or write, it releases the lock. Other threads, therefore, may acquire the lock and access the data object.

In JAVA, a 'synchronized' keyword can be used to modify a method or a statement block.
A 'synchronized' instance method refers to the lock of the class instance.
A 'synchronized' static method refers to the lock of the class.
Using the 'synchronized' method may reduce performance, for several static methods share a common instance or class lock.

Or: instead of using a synchronized method, using a synchronized block within a method. It may avoid the performance issue due to the 'synchronized' method. Synchronized blocks may refer to their own instance locks. So they won't have performance issues due to sharing a common lock like using synchronized methods.

How to make an object immutable? 
An immutable data object cannot result in inconsistency, for it cannot be modified externally.
(1) making a class final, so that it cannot be extended and added extra methods to modify fields.
(2) making fields private and final, so that once it is initialized then it cannot be modified later on.
(3) removing all setters.
(4) return a cloned protected field, thus its existing value cannot be modified via its exposed reference
(5) if immutable class hold a mutable class; using a cloned copy of the class from the constructor.
(6) making methods final, thus no method can be overridden.  so that, an existing protected field cannot be modified in overriding methods.

What are volatile variables?
All writes to the volatile variables will be written back to main memory immediately.  All reads to the volatile variables will be directly read from main memory, rather than local CPU caches.

The 'Volatile' keyword has a limitation: the variable must have no dependency on its previous state. in a short, it must be atomic. For example, if the variable x = x+1, the Volatile keyword won't work. In my understanding, it works when only need to share a flag variable or just value, like a boolean variable, or a number.

What is atomicity or atomic?
We often use this term atomic.  Atomicity, it means an indivisible unit, like a transaction. it may keep data consistent. All operations on a data object or variable in the memory are carried out in an enclosed and un-interweaved process. Just like you are seating in an enclosed space alone and accomplish all your homework without any interruption.

What is a happens-before relationship? 
it means A must happens before B.

What is deadlock?
Deadlock is a situation, where Thread A is allocated resource R1; meanwhile, thread B is allocated resource R2.

In order to continue their own transaction respectively, thread A asks for R2 and simultaneously thread B asks for R1.

On such a situation, both threads will wait for each other forever.

What is Livelock?
Both thread A and thread B asking for the same lock at the same time. This is exactly like the case when we both call each other at the same via phone, so cannot make the call.