servicecomb-java-chassis icon indicating copy to clipboard operation
servicecomb-java-chassis copied to clipboard

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

Results 233 servicecomb-java-chassis issues
Sort by recently updated
recently updated
newest added

SpringMVC 支持RequestMapping(/**), serviceComb 怎么支持这种全匹配的场景

retry has changed to governance module, the extensions use new api, and the documents should changed.

bug

When use @RequestMapping and do not define HttpMethod, can be default to GET. Supporting this will make SwaggerGenerator works in Spring Cloud class scan.

引用了 spring-boot-starter-websocket 但是好像并没有效果

从1.3.0 到现在 2.5.0 版本 ,业务服务原本内存是初始化是1G,MAX 4G,在高tps的冲击下,内存会逐渐增高,直到接近4g,但是如果此时中断业务,内存并不会释放。这会不会框架底层存在内存泄露的情况? 还有一个问题,版本是2.5.0,在接口响应相当慢的时候,频繁冲击业务服务,随后停止业务冲击,发现仍然业务请求打印,持续时间过长,重启服务后恢复.这是否是因为微服务内部队列存在拥塞,即使请求方终止,部分请求会遗留在服务队列中,直至运行完? @liubao68

CSE日志: `2022-03-22 20:09:43.921[UTC:20220322T120943]|transport-vert.x-eventloop-thread-2| || Unexpected error in server.cause:UnsupportedOperationException,message:null 2022-03-22 20:09:43.923[UTC:20220322T120943]|transport-vert.x-eventloop-thread-2| || http server failed. java.lang.UnsupportedOperationException: null at io.vertx.core.http.impl.NettyFileUpload.definedLength(NettyFileUpload.java:179) ~[vertx-core-4.1.5.jar:4.1.5] at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.loadDataMultipartOptimized(HttpPostMultipartRequestDecoder.java:1188) ~[netty-codec-http-4.1.72.Final.jar:4.1.72.Final] at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.getFileUpload(HttpPostMultipartRequestDecoder.java:926) ~[netty-codec-http-4.1.72.Final.jar:4.1.72.Final] at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.decodeMultipart(HttpPostMultipartRequestDecoder.java:572) ~[netty-codec-http-4.1.72.Final.jar:4.1.72.Final] at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.parseBodyMultipart(HttpPostMultipartRequestDecoder.java:463)...

在write和flush后面都有加日志,看日志打印正常,但是客户端一直没收到数据,access接口也显示发送数据大小为0

目前发现一个这样的问题,配置如下图 ![image](https://user-images.githubusercontent.com/60613511/171087894-5a2c48f8-2572-4b04-a8ab-c540e4ffde5e.png) 出现问题的环境如下,一台MAC电脑上有两个网卡,一个网卡是192.168.3.188,另一个是3.133.通过ifconfig中只能看到3.188但是对于注册中心中去绑定ip的时候使用了3.133。我尝试使用java获取ip地址的方式,确实获取到了3.133这张网卡。这看起来可能是微服务注册绑定ip有优先级的顺序,但是使用ContextUtils.getInvoncationContext的数据均是空。正常的电脑均没有这个问题。@liubao

而且 目前有一个问题是 使用 自定义错误码 返回 必须携带message 即使 message写了 null message 变成了null,能否对message支持空逻辑? ![image](https://user-images.githubusercontent.com/60613511/170471498-b8b2efab-9490-440c-bea1-0284c983384a.png)

如题, 当前框架没有做这个转换, 需要业务自己执行. 有些业务不知道 Invocation Context 在底层实现上是通过 HTTP header 传输的, 可能碰到问题不知道怎么解决. 这里加一个自动编解码功能业务会比较方便, 如果担心兼容性问题可以给这个特性加一个开关.

enhancement
need discussion