* Add register persistent worker latency metrics #3671
* remove never thrown exception on Time#close()
add panel to mesh-mode-grafana.json
* remove never thrown exception on Time#close()
add panel to mesh-mode-grafana.json
* add plugin netty-socketio https://github.com/mrniko/netty-socketio
* delete create exit span interceptor.
* delete create exit span interceptor testcase.
* delete create exit span interceptor testcase.
* add constructor test unit
* change bind on random port in test case
* reverse upstream master whitespace
* resolve build_id param
* delete health check segment test case
* add ContextManager.isActive check before use activeSpan invoke
* remove unnecessary code and blank line
* Fix#3402
* Fix unecessary blankline
* Optimize rebuild logic
* Fix checkstyle fail
* Add concurrency test
* Fix text mistakes
* Optimize refresh logic && new test for return clients never change by refresh logic
* Make unit test more clearness
* Add more unit test && fix a bug
* Rename variable && format by skywalking style
* Add Light4J 1.6.x plug-in
* Add unit test for Light4J plug-in
* Add missing id to server-starter
* Remove mentions of version 1.6.x
Some local testing showed that the plugin successfully generated traces for a light4j project built with light-codegen v2.x. Therefore, there is no need for a separate plugin for v2.x and no distinction needs to be made with light4j v1.6.x.
* Update supported light4j versions
* Use ContextSnapshot to maintain trace
In a typical Light4j project, the ExceptionHandler#handleRequest is the asynchronous execution point. The flow is ExceptionHandler#handleRequest -> HttpServerExchange#dispatch -> ... -> ExceptionHandler#handleRequest. This means that handleRequest is being intercepted twice and each time a LocalSpan is created. Without handling thread propagation, the trace segment gets split up.
By saving a ContextSnapshot into the enhanced object (ExceptionHandler), we can determine if it is necessary to continue the segment.
* Update logic for span creation in trace
By default, the Light4J plugin now overrides the Undertow plugin's entry span with its own. This new entry span is created just before execution of the ExceptionHandler#handleRequest in the I/O thread. The entry span is generated here because it is considered the starting point of the Light4J handler chain.
There is now also the option to enable detailed span creation when tracing requests through Light4J. These local spans mark which middleware and business handlers are involved with handling the HTTP request to a Light4J service.
* Update skywalking version
* Update light4j version
* Fix LightInstrumentation javadoc
* Remove import violating checkstyle
This import was added from the link reference in the javadoc. The javadoc has now been changed to just reference the method name.
* Move light4j agent config property
* Sync UI
* Modify the thread pool of grpc server.
* add license header
* make param confingable
* Add sharing and Jaeger config.
* Remove grpc thread config from yml
* Refactor Persistence worker.
* 1. Provide InsertRequest and UpdateRequest interface for prepare persistence.
2. Implement the ids query for H2 metrics DAO.
* Refactor worker framework
* Use queue to receive asynchronous batch request.
* Rename the Datacarrier thread name.
* Fixed some mistake.
* New mistake.
* Change OAL generator tool to runtime.
Step 1. change project structure. API links and maven pom.
* Part of metrics class generation
* Metrcis class generated.
* Set up the basic structure of new OAL engine.
* Finish metrics generation.
* Support dispatcher generation.
* Format codes.
* Generate dispatcher all methods.
* Implement disable in hardcode.
* Clear up
* Fix compile startup.
* Update license and document of new OAL engine.
* Fix rat.
* Disable class output in default
* Copy from @kezhenxu94 's test PR, https://github.com/apache/skywalking/pull/3110
* Wait for the mount command to finish
* Set up 10 seconds deadline after gRPC client sending
* The duration of deadline contains three segments: connecting,
request and response
For blocking stub, I just set deadline before invoke service. For
bi-streaming stub, I found all of them are used as a blocking style,
that after getting streaming response client stub just close current
streaming. Base on above reality, I pick the same way as blocking one.
吴晟 Wu Sheng
Jared Tan
qiyang
mrproliu
Kdump
Yanick.xia
echooymxq
kezhenxu94
Louis Tsui
stone.wlg
Andy Ai
于玉桔
yantaowu
彭勇升 pengys
Gao Hongtao
于玉桔