Skip navigation



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


[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.



   1. TinyBang project :  

   2. CommJ: 

   3. Multilane introduce:

   4. Multilane CommonJ Jar:


Recently I worked on one project. The purpose of that project is sending emails according the business rules. So need lots of concurrent jobs then provide the enough scalability and throughput.


It's very interesting we found two solutions:

  1. CommJ pattern but be optimized from single-lane mode to multiple-lane mode it was designed by me.
  2. Kilim: Java version Actor, with coroutine support inside.


The kilim said they can work on the million concurrent jobs with minor memory and less thread support. How about the truth?



Let's design one scenario:

The job contain the follwing steps:

1. Take map<string,string> as request

2. First get the value from the map<string,string> with the key value "KEY"

3. Second execute the subroutine with no parameter.

4. Third the subroutine will wait 200 ms and then return with string result with static value "executed".


ScenarioKilimMultiLane CommJ
  Concurrent 10000 Jobs

Memory consumption: 512M

Backend thread count: 160

Total execution time: 10072416187 ns

Memory consumption: 512M

Backend thread count: 160

Total execution time: 332489185 ns

  Concurrent 1000000 jobs

Memory consumption: 1024M

Backend thread count: 160

Total execution time: 1256589994539 ns

Memory consumption: 512M

Backend thread count: 160

Total execution time: 10244263167 ns




  • Lab env: 

       Computer: Dell Latitude E6400

       OS: Windows XP sp2

       Memory: 4G

       JDK: 1.6.1_22

  • Kilim exhaust memory a lot when the concurrent job count higher than some level.
  • MultiLane CommJ could handle million conncurrent jobs with minor memory and less threads.
  • MultiLane CommJ could handle concurrent jobs with almost linear scalability.
  • So Java could be very fast even in the very poor machine.




1. Kilim:

2. CommJ: 

3. Mulilane introduce:



I will open source the multi-lane version of commj. So please wait the future introduce.

Filter Blog

By date:
By tag: