servicecomb-java-chassis
servicecomb-java-chassis copied to clipboard
apache
ServiceComb Java Chassis is a Software Development Kit (SDK) for rapid development of microservices in Java, providing service registration, service discovery, dynamic routing, and service management...
针对这个@RpcReference失效的bean进行debug定位，发现初始化，执行到applyBeanPostProcessorsBeforeInitialization时，对应的RpcReferenceProcessor还没有被registerBeanPostProcessors注册上，能否提高一点RpcReferenceProcessor注册的优先级，比如实现PriorityOrdered接口，确保RpcReferenceProcessor更早一点注册，避免时序问题导致部分@RpcReference失效。
## 问题场景 同一个REST接口类中有类名相同而包名不同的两个参数类型, 生成的契约在`definitions`字段里只会呈现其中一个类的信息. 根因`Swagger`对象的`definitions`参数是一个`LinkedHashMap`类型. 而对于 Java 对象类型的参数, Java-Chassis是依赖Swagger的工具类生成`io.swagger.models.ModelImpl`模型信息的, 根据`ModelImpl#getName`作为key保存到`definitions` map中. 这里的`ModelImpl#getName`默认返回的是参数类型的简单类名, 因此同名不同包的类在这个`definitions` map中相互覆盖, 最终只有一个类型的信息留在 `definitions` 里面. ## 规避手段 在参数类型信息上可以打上`io.swagger.annotations.ApiModel`注解, 如 ```java @ApiModel(value = "personAnother") public class Person { //...
##【SCB-2372】 ## 触发场景 servicecomb 会在调用之初为服务创建配置类，大量调用未注册的服务, 由于服务未注册，每次调用都会去创建类，一定数量之后会导致metaspace oom
当服务端为外置tomcat的时候报 org.apache.tomcat.util.http.fileupload.impl.InvalidContentTypeException: the request doesn't contain a multipart/form-data or multipart/mixed stream, content type header is application/x-www-form-urlencoded
**背景** 我们的微服务基于女娲框架开发，在启动时CSE加载完成后会调用一些微服务间CSE接口，用以初始化缓存  最近我们注意到，在开发环境和测试环境，启动时有大约5%的概率出现servicecomb相关的数组越界异常，导致部分内部接口调用失败。 完整错误栈位于底部，似乎是CSE在初始化被调用接口时失败了，但是看不出来具体是什么原因。由于这一问题是概率出现的，且最近一个月内仅有3~5天遇到，当天会有大概50%的概率在启动时遇到此错误，所以感觉跟配置项无关。 **产品** Nuwa 3.0.8.103 （Nuwa-CSE插件）ServiceComb Java-Chassis 1.3.6 **错误栈** ``` 2021-12-02 10:13:58.763 [main] ERROR - [MicroserviceVersions.java:safeSetInstances:182] - [] - Failed to setInstances, appId=MapOpenService, microserviceName=MapOpenService:MapOpenKitAccessService. java.lang.IndexOutOfBoundsException: Index: 5,...
健康检查接口频繁出现Response is closed报错，当前服务没有对外提供服务，只有一个健康检查接口，怀疑是服务端连接长时间没有接收到请求后主动断开连接导致，当前健康检查接口10s调用一次 
日志中出现类似错误比较常见，有些场景属于配置错误，有些场景属于性能问题，有些场景属于无法彻底解决的问题。这个 issue 主要帮助更好的定位和分析类似问题。 类似问题通过 label 做了标记： [查看](https://github.com/apache/servicecomb-java-chassis/issues?q=is%3Aissue+label%3Aconnection%26timeout+) # 原理性介绍和定位技巧相关文章 [快速失败和重试](https://servicecomb.apache.org/references/java-chassis/zh_CN/references-handlers/fail-retry.html) : 介绍了随机故障发生的原理，以及在超时时间设置很短（需要快速失败的）的场景下的方案建议。 [性能问题分析和调优](https://servicecomb.apache.org/references/java-chassis/zh_CN/featured-topics/performance.html): 这类问题一般伴随性能问题发生。 介绍了如何分析性能问题，以及如何收集性能问题有关的日志。 # 关于 HTTP 连接 [TCP和HTTP连接的一些原理性介绍](https://blog.csdn.net/vikeyyyy/article/details/80760804) 微服务内部采用HTTP连接的情况下， 一般会复用连接，如果一个连接长时间不使用，则会回收。 常见的配置项有： | 配置项 | 含义 | | --...
Java Chassis可以使用Spring MVC的方式定义REST接口。Java Chassis仅仅使用了Spring MVC的部分annotation，以保持用户的开发习惯和降低代码迁移过程中改动工作量。Java Chassis的REST实现，是完全不同于Spring MVC的，它不依赖于Spring MVC的实现，很多Spring MVC提供的功能也不支持。 Spring MVC的主要工作场景是使用Servlet，即 `org.springframework.web.servlet.DispatcherServlet` 。 而Java Chassis的实现并不依赖于HTTP协议，它可以工作于传统的Servlet模式下，也可以工作在非Servlet模式下。在处理HTTP请求的时候，也容易给开发者带来一些理解上的困难。 Spring MVC一般都会搭配Spring、Spring Boot使用。 Java Chassis并不完全依赖于Spring、Spring Boot，但是大部分用户仍然会在Spring Boot场景下使用Java Chassis，从业务使用的角度，这些是完全可以的，但是和REST框架存在交互的部分，比如类似Spring Security等组件，仍然会存在一些差异。 这个案例帮助 Spring MVC的开发者更好的理解Java Chassis的RPC框架，避免一些常见的错误。 参考材料： 1....
升级到2.6.0之后，通过edge文件下载功能出现异常导致文件内容不完整，请求通过edge转发到下层Rest服务，直接调用Rest服务返回的文件是好的，但是通过edge调用之后文件内容不完整，具体表现是图片花屏、excel打不开；把edge回退到2.2版本就恢复正常了
