[Introduction]

After long term preparation and discussion within my team. We finally release the beta version of multi-lane commonj library.

The project name with tinybang and the link is http://code.google.com/p/tinybang/

[History and Context]

How you handle concurrent request in java? Most of the anwser will be: Thread, Thread Pool.

But Thread, Thread Pool was native api and no any abstraction. So make you application is hard to understand and maintain. So bea, ibm and other groups join toghter define one standard and naming that with CommonJ. The CommonJ especially define one structure how to deal with async-job processing abstraction.

Main Concept:

Default standard:

• WorkManager

        The main class define the interface could receive the concurrent job request.

• Scheduler

        The class could handle the concurrent job lifecycle. You can imagine that was simlar with process scheduler in the OS design.   

• Work

        Request composition class. So it's main containing the request parameters and other useful information.

• WorkEntry

        The encapsulator class contain work, workeventlistener, etc.

• WorkExecutor

        The dispatch class, it will directly talking with the backend async processing engine most was thread pool.

• Queue

        Using the FIFO structure to store the concurrent job requests.

• Pipe

        Could contain multiple types of queue, that mainly depends on how granularity you want to control the job lifecyle. For examples: pending, ready,  pause, etc.

• WorkEvent

        Define the information want to notify outside the status of the job request

• WorkEventListener

        Define the interface can be plugged into and can be awaring of the status of job request.

• Anync Processing (Thread Pool)

        The underlying language provide the async processing machanism. We leverage with java concurrent library ThreadPoolExecutor.

Extension standard:

• Router

       If contain the logic for commonj define how to pickup pipe from multiple pipes.

                                                   Figure 1:    CommonJ

The standard was just a bunch of interfaces not detail implementation. And most implementor just simply implement the logics and binding with thread pool. So from scalability and throughput both cannot meet large amount concurrent job requirements.

And current most company meet the large amount concurrent job handling issues, because java thread creation has limition and distributed computing contain the complexity. So how would we do?

The possible answer could be "MultiLane CommonJ"

[Follow up]

Next blog we will explain the internal for the multi-lane commonJ library. Please wait for that.

[Reference]

   1. TinyBang project : http://code.google.com/p/tinybang/  

   2. CommJ: http://commonj.myfoo.de/ 

   3. Multilane introduce: http://www.1024cores.net/home/scalable-architecture/multilane

   4. Multilane CommonJ Jar: http://code.google.com/p/tinybang/source/browse/tags/tinybang-0.0.1/jar/multilanecommonj/multilanecommonj.jar