xxl-job dispatch center parse source code (RPC client request)
First, we dispatch center inside through a new interface to add a scheduled task:
In the library which will hold regular tasks appropriate information, as follows:
Now we start clicking in the dispatch center, will start calling the interface:
In the interface map, we can see that it will add a job task to the quartz, the type of task execution is RemoteHttpJobBean, now we look at this class:
Figure above we can see that the implementation will go through a trigger speed thread pool, if there is 10 times more than 500ms will start running slow thread pool in 1 minute, continue to enter XxlJobTrigger.trigger:
The code is first stored in the database query by jobId timing task information, then the failure retry mechanism and fragmentation, we skip look directly processTrigger:
The above code acquired first blocking strategy, default Serial execution serial execution, then the routing policy, taking a first default FIRST execution machine, and then the function key is the task execution timing runExecutor :
We look directly XxlJobDynamicScheduler.getExecutorBiz (address), address management here is to perform a registered ip address, as shown below:
Here instantiates a XxlRpcReferenceBean:
Here initialize a netty_http service and client 
HessianSerializer employed as a serialized, CallType.SYNC request synchronous manner, LoadBalance.ROUND load mode with polling.
Now we see the getObject method:
See here We know this is a typical dynamic proxy design approach (ps: not familiar with the dynamic proxy, you can see here in my blog this dynamic proxy vernacular parsing )
We continue to look down executorBiz.run (triggerParam), in the implementation of this method will invoke method to call processing agent class InvocationHandler in, we look directly invoke the image above method:
The previous paragraph is done if the proxy method XxlRpcGenericService invoke some special treatment, and if they are proxy class is Object will throw an exception, or is routed through routing policies to address one final request. Finally came the RPC request calling process
xxl-job RPC request calling process
First instantiate a XxlRpcRequest, there className class name (i.e. com.xxl.job.core.biz.ExecutorBiz), methodName method name (i.e., run), parameterTypes parameter type name, parameters method parameters four important attributes. We continue to see XxlRpcReferenceBean.this.client.asyncSend (finalAddress, xxlRpcRequest) will be here to call asyncSend NettyHttpClient of:
After obtaining the NettyHttpClient in getPool method, it will execute the init method, which is netty http client initialization:
Then here for NettyHttpConnectClient connected by the connection pool, which send call request method for transmitting:
The results will then get returned by NettyHttpClientHandler:
Here to return calls after obtaining the results channelRead0 method, XxlRpcResponse into XxlRpcFutureResponse, we continue to go see futureResponse.get get to see the results of the method down:
Here will be blocked only locking method call wait to get returns the result, we get to see the response method returns a result futureResponse.setResponse:
After obtaining the results returned will call notifyAll wake wait obstruction, continue xxlRpcResponse.getResult down () returns the results obtained, the dispatch center here to request the implementation is complete.
xxl-job execution parse source code (RPC server request)
Now we look at the source code to perform tasks performed by analysis:
First execute at startup instantiates XxlJobSpringExecutor class, call its start method to initialize:
Start method is called the parent class:
Here By configuring the ip, port, appName initialized XxlRpcProviderFactory, added ExecutorBizImpl execution class, continue to look down the start method:
Here the use of a daemon thread started http server of a netty, after receiving the dispatch center scheduling request, will perform channelRead0 method NettyHttpServerHandler of:
Here processing request using a thread pool, the method continues to look down process:
Here scheduling request uri not include services, we look directly this.xxlRpcProviderFactory.invokeService method:
We see it through the class name request came as serviceBean key to obtain the corresponding by xxlRpcProviderFactory.addService above (ExecutorBiz.class.getName (), null, new ExecutorBizImpl ()) This is the way we know serviceBean ExecutorBizImpl, methodName to run. By reflecting the implementation of the run method calls will go to the ExecutorBizImpl:
Code is mainly preceding paragraph may be performed by different timing task code corresponding to the script, the default is GlueTypeEnum.BEAN, newJobHandler here will put jobHandlerRepository XxlJobExecutor XxlJobSpringExecutor initialization at the time of start method:
That is, through annotation @JobHandler (value = "demoJobHandler") class of demoJobHandler
We look directly XxlJobExecutor.registJobThread method:
Here instantiates a JobThread thread to call directly to see its run method:
Here will directly execute the corresponding handler.execute, execute the method in this embodiment is DemoJobHandler of:
We continue to return to the run method ExecutorBizImpl in the last paragraph:
Which was placed in the trigger queue, returns ReturnT.SUCCESS completed execution.
Here, a xxl-job scheduled tasks to complete processing
Expansion and divergence:
The above resolved xxl-job task execution timing of a process, the core is rpc request by calling the control center effector to perform a task.
Other rpc framework is still performed in a similar manner, such as calls between our well-known dubbo service is performed by a similar manner rpc call request, but dubbo is tcp requests, as well as springcloud done by feign between each service call, the underlying dynamic is accomplished by way of a proxy + http call. We can look divergence, java basic frameworks are all rpc a similar manner, as well as thrift and the java RMI, etc., there may be some extended functionality such as load, failure retry, monitor, fusing, current limiting, demotion, Yung disaster, etc., but the core is through rpc requests to complete.
to sum up:
xxl-job underlayer is distributed to complete execution timing of each task by encapsulating quartz + rpc netty http package frame, a simple flow chart of call source as follows:
