1. 04 8月, 2021 2 次提交
  2. 03 8月, 2021 1 次提交
  3. 02 8月, 2021 1 次提交
  4. 30 7月, 2021 3 次提交
  5. 29 7月, 2021 5 次提交
  6. 27 7月, 2021 2 次提交
  7. 26 7月, 2021 1 次提交
  8. 25 7月, 2021 1 次提交
  9. 23 7月, 2021 2 次提交
  10. 22 7月, 2021 3 次提交
  11. 21 7月, 2021 2 次提交
  12. 20 7月, 2021 6 次提交
  13. 19 7月, 2021 2 次提交
  14. 18 7月, 2021 1 次提交
    • wuweijie@apache.org's avatar
      Remove plugins for ShardingSphere legacy and unstable versions (#7323) · 06e589fa
      wuweijie@apache.org 提交于
      Remove the following plugins due to they are legacy and unstable releases.
      1. sharding-jdbc-1.5.x-plugin
      2. sharding-sphere-4.x-rc3-plugin
      3. sharding-sphere-4.x-plugin (This is for RC1 and RC2)
      
      To people who want to use these removing versions, you still could copy the plugins from SkyWalking's 8.6.0 release to the '/plugins' folder to activate, unless SkyWalking has some core level APIs upgrade. This is very rare to happen.
      06e589fa
  15. 17 7月, 2021 3 次提交
    • Y
      fix gateway plugin async finish repeatedly when fallback configured (#5886) · aa4ee27d
      yujiaxinlong 提交于
      When there is a fallback in webflux (like a hystrix fallback or a webflux fallback method that involves visiting a new URL). This interceptor would be invoked twice, one for origin request and another for fallback request. The ServerWebExchange for these two aren't exactly the same one, but the former one is a delegate inside of the latter one, thus, they share the same attributes.
      
      The problem of the old code is that get the span from attributes within the execution of Mono would get span for the latter request twice. so just move this part of code out could solve the problem.
      
      It seems impossible to make the mono chain work like expected. So add a check about whether the best matching pattern really matches the URL. This check code is how webflux generating the best match pattern,
      aa4ee27d
    • L
      Chore: polish methods naming for Spring Kafka (#7320) · cd029df3
      Lu Jiajing 提交于
      cd029df3
    • wu-sheng's avatar
      Logically revert #6642 and partial #7153 to reduce unnecessary thread and... · a6afcac8
      wu-sheng 提交于
      Logically revert #6642 and partial #7153 to reduce unnecessary thread and concurrency process (#7318)
      
       The key logic behinds all these is, metrics persistence is fully asynchronous.
      
      * The core/maxSyncOperationNum setting(added in 8.5.0) is removed due to metrics persistence is fully asynchronous.
      * The core/syncThreads setting(added in 8.5.0) is removed due to metrics persistence is fully asynchronous.
      * Optimization: Concurrency mode of execution stage for metrics is removed(added in 8.5.0). The only concurrency of prepare stage is meaningful and kept.
      * Remove the outside preparedRequest list initialization, worker instance could always build a suitable size list in the first place (Reduce Array.copy and GC load a little).
      a6afcac8
  16. 16 7月, 2021 2 次提交
    • W
      Support envoy cluster manager metrics (#7294) · 9f3ff517
      wankai123 提交于
      9f3ff517
    • wu-sheng's avatar
      Adjust ElasticSearch index refresh period as INT(flushInterval * 2/3) (#7310) · 8df362b9
      wu-sheng 提交于
      Adjust index refresh period as INT(flushInterval * 2/3), it used to be as same as bulk flush period. At the edge case, in low traffic(traffic < bulkActions in the whole period), there is a possible case, 2 period bulks are included in one index refresh rebuild operation, which could cause version conflicts. And this case can't be fixed through core/persistentPeriod as the bulk fresh is not controlled by the persistent timer anymore.
      
      This PR should avoid the following exception in the low load case, especially when bulkActions is set larger than the number of a metric type.
      8df362b9
  17. 15 7月, 2021 3 次提交