ServiceComb/CSE常见问题处理（1812）

最新推荐文章于 2024-09-23 17:05:46 发布

原创最新推荐文章于 2024-09-23 17:05:46 发布 · 2.6w 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#cse #servicecomb

精品案例专栏收录该内容

22 篇文章

订阅专栏

本文档列举了ServiceComb/CSE在使用过程中遇到的一些常见问题，包括配置读取时机、连接关闭异常、请求超时、SSL配置、线程阻塞和异常转换等问题，提供了详细的错误分析和解决方案，帮助开发者更好地理解和处理这些问题。

一、什么时机可以使用DynamicPropertyFactory.getInstance()读取配置

如果用spring，在place holder加载之后就可以使用，加载bean的过程中就可以读。 CSE初始化，是使用place holder来初始化的。果要在更加之前读取，只能使用local configuration, 具体可以参考java-chassis的config-cc代码实现:

https://github.com/apache/servicecomb-java-chassis/blob/master/dynamic-config/config-cc/src/main/java/org/apache/servicecomb/config/client/ConfigCenterConfig.java

二、io.vertx.core.VertxException: Connection was closed 可能原因

在做超时测试的时候，发现抛出如下异常：

2018-12-06 16:12:02,005 [ERROR] invoke failed, invocation=CONSUMER rest AutoProvider.serverMvc.SayHello org.apache.servicecomb.swagger.invocation.exception.DefaultExceptionToProducerResponseConverter.convert(DefaultExceptionToProducerResponseConverter.java:35)
io.vertx.core.VertxException: Connection was closed
2018-12-06 16:12:02,005 [WARN] bizkeeper command CONSUMER rest AutoProvider.serverMvc.SayHello failed due to InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request] org.apache.servicecomb.bizkeeper.BizkeeperCommand.lambda$null$1(BizkeeperCommand.java:82)
2018-12-06 16:12:02,005 [WARN] bizkeeper execution error, info=cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:VertxException,message:Connection was closed org.apache.servicecomb.bizkeeper.BizkeeperHandler$1.onExecutionError(BizkeeperHandler.java:55)
2018-12-06 16:12:02,006 [WARN] catch error in bizkeeper:Consumer.AutoProvider.serverMvc.SayHello failed and fallback disabled. org.apache.servicecomb.bizkeeper.BizkeeperHandler.lambda$handle$0(BizkeeperHandler.java:79)

预期是客户端得到超时异常，但是实际捕获到了Connection was closed异常。

最后检查是服务端配置了如下配置项：

servicecomb.rest.server.connection.idleTimeoutInSeconds = 1

由于服务端设置了连接限制时间，关闭了连接。当处理时间超过1秒的时候，就会出现这个异常了。

三、InvocationException: code=500;msg={message=Timeout when processing the request.}

2018-12-11 13:58:53,387|ERROR|pool-2-thread-5|1zcbErzhtZP7Lv4Im9m|httpclient.CBCHttpClientUtils 484|Failed to execute http request. Exception
InvocationException: code=500;msg={message=Timeout when processing the request.}
at org.apache.servicecomb.swagger.invocation.exception.ExceptionFactory.d**ate(ExceptionFactory.java:74)
at org.apache.servicecomb.swagger.invocation.exception.ExceptionFactory.create(ExceptionFactory.java:61)
at org.apache.servicecomb.swagger.invocation.Response.create(Response.java:93)
at org.apache.servicecomb.transport.rest.client.http.DefaultHttpClientFilter.extractResponse(DefaultHttpClientFilter.java:105)
at org.apache.servicecomb.transport.rest.client.http.DefaultHttpClientFilter.afterReceiveResponse(DefaultHttpClientFilter.java:128)
at org.apache.servicecomb.transport.rest.client.http.RestClientInvocation.lambda$processResponseBody$7(RestClientInvocation.java:200)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

这个异常发生在客户端。和客户端请求超时不同，这个异常是服务端返回的错误，代表一个请求在服务端队列里面排队超过了设置的超时时间，服务端丢弃这个请求，不再处理。可以通过servicecomb.rest.server.requestWaitInPoolTimeout设置这个排队时间，默认是30s。

但是通常30s已经是非常长的时间了，设置的太长，还会触发客户端超时等。需要做一系列其他配置。所以一般这种情况发生的时候，需要考虑优化服务端性能。如果已经达到设计的系统上限，那么可以忽略这个错误。

四、Key/certificate is mandatory for SSL

启动CSE的服务的时候，报告：Key/certificate is mandatory for SSL

报告这个错误，是因为启用ssl的情况下需要配置证书。可以参考这里https://docs.servicecomb.io/java-chassis/zh_CN/security/tls.html进行配置。

配置项里面的路径受ssl.sslCustomClass: org.apache.servicecomb.demo.DemoSSLCustom这个实现类的影响，可以定制他的实现。缺省情况从当前工作目录查找配置的文件名。

五、Thread[transport-vert.x-eventloop-thread-4,5,main] has been blocked for 30711 ms, time limit is 2000

这个错误代表evenloop线程被阻塞，超过了缺省的2000ms限制，会打印阻塞堆栈。从下面的堆栈有个核心行：

at org.apache.servicecomb.core.executor.ReactiveExecutor.execute(ReactiveExecutor.java:30)

可以看出，业务逻辑和处理链逻辑是采用reactive模式执行的。如果是edge service（网关服务），缺省就是reactive模式。当在网关出现这个错误的时候，很多时候就需要调整代码实现，将阻塞代码改为异步的方式。

如果不是网关，而是provider，缺省是线程池模式。那么出现这个错误的可能原因是在项目中错误的引入edge-core这个模块了。将这个jar包排除即可。这个包里面提供了一个配置项，会将线程池模式设置为reactive模式。

2018-12-12 15:18:48,886 [WARN] Thread Thread[transport-vert.x-eventloop-thread-4,5,main] has been blocked for 30711 ms, time limit is 2000 io.vertx.core.impl.BlockedThreadChecker$1.run(BlockedThreadChecker.java:52)

io.vertx.core.VertxException: Thread blocked

at sun.misc.Unsafe.park(Native Method)

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)

at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)

at org.apache.servicecomb.core.provider.consumer.SyncResponseExecutor.waitResponse(SyncResponseExecutor.java:53)

at org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:75)

at org.apache.servicecomb.provider.pojo.Invoker.syncInvoke(Invoker.java:161)

at org.apache.servicecomb.provider.pojo.Invoker.invoke(Invoker.java:157)

at com.sun.proxy.$Proxy30.SayHello(Unknown Source)

at com.huawei.paas.cse.demo.basicoperation.InterfaceBasicUtil.simpleInvoke(InterfaceBasicUtil.java:39)

at com.huawei.paas.cse.demo.pojo.client.ClientImpl.pojoclienttest(ClientImpl.java:28)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at org.apache.servicecomb.swagger.engine.SwaggerProducerOperation.doInvoke(SwaggerProducerOperation.java:180)

at org.apache.servicecomb.swagger.engine.SwaggerProducerOperation.syncInvoke(SwaggerProducerOperation.java:165)

at org.apache.servicecomb.swagger.engine.SwaggerProducerOperation.invoke(SwaggerProducerOperation.java:119)

at org.apache.servicecomb.core.handler.impl.ProducerOperationHandler.handle(ProducerOperationHandler.java:40)

at org.apache.servicecomb.core.Invocation.next(Invocation.java:189)

at org.apache.servicecomb.bizkeeper.BizkeeperCommand.lambda$construct$2(BizkeeperCommand.java:79)

at org.apache.servicecomb.bizkeeper.BizkeeperCommand$$Lambda$178/1809372843.call(Unknown Source)