ServiceComb/CSE常见问题处理(1812)

Vert.x 4 学习笔记-Vert.x的基本处理单元Verticle Verticle是Vert.x的基本处理单元,Vert.x应用程序中存在着处理各种事件的处理单元,比如负责HTTP API响应请求的处理单元负责数据库存取的处理单元负责向第三方发送请求的处理单元。Verticle就是对这些功能单元的封装,Verticle可被部署,有自己的生命周期,Verticle是Vert.x中构建异步事件处理程序及相关业务逻辑的基础。/*** 获取一个Vert.x实例的引用用来发布当前的verticle/*** 通过Vert.x实例和上下文来初始化一个Verticle。 阅读详情
AI摘要

本文档列举了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)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.Observable.unsafeSubscribe(Observable.java:8666)

at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:52)

at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:36)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.Observable.unsafeSubscribe(Observable.java:8666)

at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:52)

at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:36)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)

at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)

at rx.Observable.unsafeSubscribe(Observable.java:8666)

at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:52)

at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:36)

at rx.Observable.subscribe(Observable.java:8759)

at rx.Observable.subscribe(Observable.java:8726)

at rx.Observable.subscribe(Observable.java:8619)

at org.apache.servicecomb.bizkeeper.BizkeeperHandler.handle(BizkeeperHandler.java:78)

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

at org.apache.servicecomb.qps.ProviderQpsFlowControlHandler.handle(ProviderQpsFlowControlHandler.java:49)

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

at org.apache.servicecomb.common.rest.AbstractRestInvocation.doInvoke(AbstractRestInvocation.java:205)

at org.apache.servicecomb.common.rest.AbstractRestInvocation.invoke(AbstractRestInvocation.java:178)

at org.apache.servicecomb.common.rest.AbstractRestInvocation.runOnExecutor(AbstractRestInvocation.java:162)

at org.apache.servicecomb.common.rest.AbstractRestInvocation.lambda$scheduleInvocation$0(AbstractRestInvocation.java:145)

at org.apache.servicecomb.common.rest.AbstractRestInvocation$$Lambda$170/1191009764.run(Unknown Source)

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

at org.apache.servicecomb.common.rest.AbstractRestInvocation.scheduleInvocation(AbstractRestInvocation.java:130)

at org.apache.servicecomb.common.rest.RestProducerInvocation.invoke(RestProducerInvocation.java:52)

at org.apache.servicecomb.transport.rest.vertx.VertxRestDispatcher.onRequest(VertxRestDispatcher.java:194)

at org.apache.servicecomb.transport.rest.vertx.VertxRestDispatcher$$Lambda$95/1364287458.handle(Unknown Source)

at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)

at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)

at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:133)

at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler$BHandler.doEnd(RestBodyHandler.java:248)

at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler$BHandler.end(RestBodyHandler.java:226)

at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler.lambda$handle$0(RestBodyHandler.java:86)

at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler$$Lambda$164/2001137338.handle(Unknown Source)

at io.vertx.core.http.impl.HttpServerRequestImpl.handleEnd(HttpServerRequestImpl.java:417)

at io.vertx.core.http.impl.Http1xServerConnection.handleEnd(Http1xServerConnection.java:482)

at io.vertx.core.http.impl.Http1xServerConnection.processMessage(Http1xServerConnection.java:456)

at io.vertx.core.http.impl.Http1xServerConnection.handleMessage(Http1xServerConnection.java:144)

at io.vertx.core.http.impl.HttpServerImpl$ServerHandlerWithWebSockets.handleMessage(HttpServerImpl.java:712)

at io.vertx.core.http.impl.HttpServerImpl$ServerHandlerWithWebSockets.handleMessage(HttpServerImpl.java:619)

at io.vertx.core.net.impl.VertxHandler.lambda$channelRead$1(VertxHandler.java:146)

at io.vertx.core.net.impl.VertxHandler$$Lambda$59/1535450007.run(Unknown Source)

at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)

at io.vertx.core.impl.ContextImpl$$Lambda$25/1510403823.run(Unknown Source)

at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:195)

at io.vertx.core.net.impl.VertxHandler.channelRead(VertxHandler.java:144)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)

at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)

at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)

at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)

at io.vertx.core.http.impl.Http1xOrH2CHandler.end(Http1xOrH2CHandler.java:61)

at io.vertx.core.http.impl.Http1xOrH2CHandler.channelRead(Http1xOrH2CHandler.java:38)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)

at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)

at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)

at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)

at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)

at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)

at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)

at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)

at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)

at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)

at java.lang.Thread.run(Thread.java:745)

关于网关的工作模式,以及修改工作模式的配置项的说明参考文档: https://docs.servicecomb.io/java-chassis/zh_CN/edge/by-servicecomb-sdk.html

六、使用Tomcat作为服务器,并采用CSE客户端调用,低概率出现请求失败

问题现象和场景:  服务端使用Tomcat作为服务器, 客户端使用CSE调用。在大规模并发的场景下,低概率出现请求失败

问题原因:Tomcat默认会在一定周期内(IDLE),达到一定请求数后关闭连接(active requests)关闭HTTP连接,导致请求失败。 

解决方案:

对于使用Tomcat + CSE SDK场景,使用Tomcat做HTTP协议接入的业务,临时规避方案如下(Tomcat的server.xml文件):

1、  maxKeepAliveRequests修改为-1

2、  keepAliveTimeout修改为10分钟

image.png

修改策略是:对于内部的RPC调用,尽量不要频繁的重建HTTP连接,HTTP空闲连接的回收时间配置长一些,5分钟或者10分钟,或者由CSE 消费端来控制,Tomcat服务端不用控制。

最终解决方案:CSE给Vert.X社区提问题单,在下一个CSE版本中修复连接池的BUG,即:如果消息发送时发现连接不可用,要立即失败,并按照业务的重试策略自动重试,对业务的效果就是业务不感知底层HTTP连接的关闭和自动重试,保障业务的成功率。

七、CSE如何配置多个服务中心、配置中心、监控中心地址及其常见错误

CSE支持配置多个服务中心、配置中心、监控中心地址,在一个实例故障的时候,自动切换到另外一个实例,增强了可靠性。目前有如下几种配置方法。

第一种,在microservice.yaml中指定:

cse:
  service:
    registry:
      address: http://127.0.0.1:30100,http://127.0.0.2:30100

第二种,通过JAVA参数指定

java -Dcse.service.registry.address=http://127.0.0.1:30100,http://127.0.0.2:30100 -jar Application.jar

这种方式也可以配套环境变量使用

export SC_ADDRESS=http://127.0.0.1:30100,http://127.0.0.2:30100

java -Dcse.service.registry.address=${SC_ADDRESS} -jar Application.jar

第三种,使用变量别名(Mapping)

如果用户依赖了cse-solution-service-engine这个组件,那么系统提供了默认的别名映射。

PAAS_CSE_ENDPOINT:
  - cse.service.registry.address
  - cse.config.client.serverUri
PAAS_CSE_SC_ENDPOINT:
  - cse.service.registry.address
PAAS_CSE_CC_ENDPOINT:
  - cse.config.client.serverUri

因此用户只需要设置环境变量即可

export PAAS_CSE_ENDPOINT=http://127.0.0.1:30100,http://127.0.0.2:30100

错误用法

由于archaius接口设计上的问题,下面这种用法是错误的。 会导致只有第一个地址被使用,第二个地址被忽略。

在microservice.yaml中指定:

cse:
  service:
    registry:
      address: ${SC_ADDRESS}

设置环境变量

export SC_ADDRESS=http://127.0.0.1:30100,http://127.0.0.2:30100

这种方式读取到的实际地址只有一个http://127.0.0.1:30100。因为archaius会将cse.service.registry.address解析为String类型,而SC_ADDRESS解析为List类型,在类型转换的时候,会取第一个元素。 一般的,涉及到配置的参数被当做数组进行解析,使用Place Holder的方式配置,都会出现类似问题。

参考材料: CSE配置层次和动态配置机制https://docs.servicecomb.io/java-chassis/zh_CN/general-development/config.html

八、租户链接CSE的服务中心进行服务注册发现需要授予哪些权限

租户的微服务通过AK/SK访问CSE服务。有些用户需要创建子账号访问CSE,这些用户需要分配下面的权限之一:

SvcStg Operator

SvcStg Admin

SvcStg Developer

对于服务注册发现场景,分配SvcStg Developer权限即可。 

九、Mismatched content. Msg=Cannot deserialize instance of `java.lang.String` out of START_OBJECT token

在使用CSE开发REST接口,并使用postman或者客户端调用,经常出现:

Mismatched content. Msg=Cannot deserialize instance of `java.lang.String` out of START_OBJECT token

的错误。 这个错误的含义是将HTTP body转换为 REST接口定义的参数发生的,抛出异常的是jackson API。 

2018-12-22 09:49:01.440 ERROR 3048 --- [pool-1-thread-1] o.a.s.common.rest.codec.RestCodec        : Parameter is not valid for operation cse-reporting-service.ReportingEndpoint.addAlarm. Message is cause:MismatchedInputException,message:Cannot deserialize instance of `java.lang.String` out of START_OBJECT token

 at [Source: (org.apache.servicecomb.foundation.vertx.stream.BufferInputStream); line: 1, column: 1].

2018-12-22 09:49:01.447 ERROR 3048 --- [pool-1-thread-1] o.a.s.c.rest.AbstractRestInvocation      : unknown rest exception.

org.apache.servicecomb.swagger.invocation.exception.InvocationException: InvocationException: code=400;msg=CommonExceptionData [message=Parameter is not valid.]

at org.apache.servicecomb.common.rest.codec.RestCodec.restToArgs(RestCodec.java:72) ~[common-rest-1.1.0.B030.jar:1.1.0.B030]

at org.apache.servicecomb.common.rest.filter.inner.ServerRestArgsFilter.afterReceiveRequest(ServerRestArgsFilter.java:60) ~[common-rest-1.1.0.B030.jar:1.1.0.B030]

at org.apache.servicecomb.common.rest.AbstractRestInvocation.prepareInvoke(AbstractRestInvocation.java:226) [common-rest-1.1.0.B030.jar:1.1.0.B030]

at org.apache.servicecomb.common.rest.AbstractRestInvocation.invoke(AbstractRestInvocation.java:206) [common-rest-1.1.0.B030.jar:1.1.0.B030]

at org.apache.servicecomb.common.rest.AbstractRestInvocation.runOnExecutor(AbstractRestInvocation.java:196) [common-rest-1.1.0.B030.jar:1.1.0.B030]

at org.apache.servicecomb.common.rest.AbstractRestInvocation.lambda$scheduleInvocation$0(AbstractRestInvocation.java:159) [common-rest-1.1.0.B030.jar:1.1.0.B030]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_111]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_111]

at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_111]

下面解读下这个错误:

"Cannot deserialize instance of `java.lang.String`" 表面目标类型是一个String类型; "out of START_OBJECT token"表面HTTP body的内容,是一个对象,比如

1

{"name":"bobo"}

String的json表示是需要用引号的,所以就报了上述错误。正确的传递参数应该是:

1

"This is a String Json content."

或者:

1

"{\"abcd\":\"abcd\"}"

一般来说,发生这个错误,都是因为开发人员在业务代码中手工进行了json编码,框架再次进行json编码导致

使用CSE开发,业务在输入/输出层次,应该只关注model,而不要做编解码动作

十、实现ExceptionToProducerResponseConverter注意事项

ExceptionToProducerResponseConverter会在两个环节被调用:

1. 使用RestClient发送请求,出现失败的时候;

2. 服务端在将处理过程中捕获的异常编码为HTTP body写到流之前。 

对于第一种场景,RestClient抛出的异常可能影响到后续的控制逻辑。比如重试、隔离。 重试会判断异常是否为某些特定异常,并且异常消息是否包含某些特定内容。 如果ExceptionToProducerResponseConverter将cause丢失掉了, 那么重试判断就会失效。 

所以实现的时候,尽可能保留原始异常的cause信息。 

1

return Response.createFail(new InvocationException(statusCode, reasonPhase, data, cause));

下面的方法会丢失cause:

1

return Response.createFail(new InvocationException(statusCode, reasonPhase, data));

适用于JAVA SDK 2.3.56及其以上版本

十一、InstanceCacheChecker: |instance cache not match

早期的服务中心版本存在一个bug。当实例下线的时候,revision信息没有变化,SDK感知不到实例下线。 SDK为了检测这个BUG,做了一个功能,会定时(缺省是24小时)检测服务中心的实例列表和本地列表是否一致,不一致会发送告警,用户可以手工触发重新刷新SDK缓存。 (在CSE界面操作)

2018-12-19 09:11:00.970|[Service Center Task]|ERROR|[InstanceCacheChecker.java:119]|instance cache not match. appId=AppGallerySearchService, microservice=AppGallerySearchService:AppGalleryMicroContentService.

local cache: [{"instanceId":"0fa1021ff24911e888a800163e0b0521","serviceId":"0f95a43bf24911e888a800163e0b0521","endpoints":["rest://10.1.130.140:8087"],"hostName":"ncn-hispace-govportal-1-130-140","status":"UP","properties":{},"healthCheck":{"mode":"push","port":0,"interval":30,"times":3,"ttl":120},"environment":null,"stage":null,"dataCenterInfo":{"name":"AppMarket","region":"North-China","availableZone":"JiuXianQiao"}},{"instanceId":"78aa5835035f11e9a9c100163e0b085a","serviceId":"789d2f4f035f11e9a9c100163e0b085a","endpoints":["rest://10.1.130.140:18080"],"hostName":"ncn-hispace-govportal-1-130-140","status":"UP","properties":{},"healthCheck":{"mode":"push","port":0,"interval":30,"times":3,"ttl":120},"environment":null,"stage":null,"dataCenterInfo":{"name":"AppMarket","region":"North-China","availableZone":"RunZe"}}]

remote cache: [{"instanceId":"78aa5835035f11e9a9c100163e0b085a","serviceId":"789d2f4f035f11e9a9c100163e0b085a","endpoints":["rest://10.1.130.140:18080"],"hostName":"ncn-hispace-govportal-1-130-140","status":"UP","properties":{},"healthCheck":{"mode":"push","port":0,"interval":30,"times":3,"ttl":120},"environment":null,"stage":null,"dataCenterInfo":{"name":"AppMarket","region":"North-China","availableZone":"RunZe"}}]

这个功能可以帮助用户发现一些潜在问题,但是不是根本解决方案。 如果用户自己部署了服务中心,建议及时升级到最新版本, SDK也做好定期持续升级,避免老版本的BUG对业务产生影响。 

十二、如何从头开始使用CSE搭建一个项目

有几种方式快速创建一个项目:

  1. 通过ServiceComb脚手架: http://start.servicecomb.io/

  2. 参考开发指南,下载一个示例项目: https://huaweicse.github.io/cse-java-chassis-doc/featured-topics/develop-microservice-using-cse.html

  3. 使用CSE服务生成: https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/tools

手把手教你用VCS+Verdi在Linux下仿真蜂鸟E203 RISC-V核(附波形调试技巧) 本文详细介绍了在Linux环境下使用VCS和Verdi工具链对蜂鸟E203 RISC-V核进行仿真验证的完整流程。从环境配置、工程结构解析到VCS编译优化和Verdi波形分析技巧,提供了实战性强的调试方法和性能优化策略,帮助工程师高效完成数字IC验证工作。 阅读详情

相关推荐

Topas——基于Geant4的放射治疗蒙特卡罗算法模拟工具

本文内容参考Joseph Perl 的线上会议,视频详情可见于,该视频会议内容主要介绍Topas功能、软件架构、工作流程、参数设定、物理模型、具体案例等,对TOPAS的基本入门使用方法以及使用规定作出阐述。

fy方的博客 7606

Vert.x,Core - Future

在同步编程(synchronous programming)中,当调用一个方法,方法的调用者(线程)需要一直等待,直到方法结果返回。而在异步编程(asynchronous programming)中,通过异步方法,方法的调用者不需要等待结果返回,当结果就绪时候会通知我们。Vert.x的提供的API大都是异步的,调用并不需要等结果返回。假设一个业务逻辑需要A() -> B() -> C() -> D() 这4个调用来完成,他们调用有向后顺序,后一个调用依赖前一个调用的结果。

Li_Xiang_996的博客 1013

SMPTE ST 2110 概论(三)

SMPTE ST 2110 概论(三)ST 2110-30:未压缩的PCM音频流ST 2110-31:非PCM音频传输ST 2110-40:辅助数据传输结语 ST 2110-30:未压缩的PCM音频流 鉴于音频系统是广播系统中最复杂,也是最重要的一套系统,我们先来回顾一下广电音频系统的历史。 最老式的音频都是基于模拟信号的,具有有限的动态范围,并且用连续的电压变化来描述音频。再后来就基于数字信号(...

Cidd0422的博客 1万+

java中main调用service_服务中心注册服务和服务调用问题

您好:我使用华为运服务,按照网站指导,下载sdk和服务中心,启动服务中心,然后用maven构件例子程序,构建成功,导入eclipse工具。1)启动服务中心,类型为:service-center-0.1.1-windows-amd64,运行start.bat,启动服务中心,一直滚动如下信息:2017-09-04T17:27:44.4495078+08:00 DEBUG service_center ...

weixin_36011546的博客 1095

从病毒分析到安全研究:手把手教你用OD破解加壳程序的反调试机制

本文深入探讨了如何识别并绕过加壳程序的反调试机制,特别是针对使用IsDebuggerPresent等API检测的防护手段。通过实战案例和工具链配置,详细介绍了逆向工程中的关键技巧,包括内存补丁、硬件断点定位OEP等,帮助安全研究人员有效突破软件保护技术。

tgb345678的博客 825

【异常】‘build.plugins.plugin.version‘ for org.apache.maven.plugins:maven-resources-plugin is missing

maven-compiler-plugin 插件版本信息没有指定导致了错误提示如下字面意思就是没有指定版本信息。

奶爸的编程之路,也就一周冷个三天 4602

bugfix之Parameter is not valid for operation xxx. Parameter is [req]. Processor is [body].

对比发现是没有加构造方法,加上注解@NoArgsConstructor 和。@AllArgsConstructor之后解决。

gxt19940123的博客 1969

分布式协作方案:OpenClaw多节点部署与设备互联

主从架构或对等架构服务发现与注册机制负载均衡策略选择分布式任务队列优先级调度失败重试机制WebSocket实时通信数据同步引擎冲突解决策略健康检查机制故障自动转移数据复制与恢复通过分布式部署,OpenClaw可以支撑更大规模的业务场景,提供更稳定可靠的AI助手服务。在下一篇文章中,我们将深入探讨安全与权限管理的精细化策略。

gaoxiang_120的专栏 371

Vert.x实战 Verticles:Vert.x的基本处理单元

本章包括: verticles是什么 如何写、配置以及部署一个verticles Vert.x的线程模型 如何混合【mix】Vert.x的线程以及非Vert.x线程 简单地说,verticle是Vert.x中的基本处理单元。verticle的角色是封装用于处理事件的技术功能单元【technical functional unit】,例如暴露HTTP API并响应请求、在数据库之上提供仓储接口,或向第三方系统发出请求。与其他技术(如Enterprise Java Beans【EJB】)中的组件非常相似,v

Piemon&Anokata的博客 2888

VI4302 1D dToF Sensor助力无人机定高避障:一场前所未有的飞行体验

另外,传感器因测量精度不够,产生的高度信息误差,会导致无人机无法精确定高,影响飞行稳定性和安全降落。芯视界于2022年发布的全新一代基于单光子探测技术的dToF激光雷达传感器芯片-VI4302,采用单电源低功耗系统,实现高性能测距、高稳定性,同时具备极强抗阳光能力以及兼容性等强大优势。无人机可以根据传感器提供的信息,快速调整飞行路径,避开潜在的障碍物,确保平稳的飞行。VI4302 1D dToF Sensor能够以极高的精度测量物体与无人机之间的距离,实现毫米级别的测量精度。⭐ 体型小巧,灵敏度高。

致力于lidar应用开发 626

[SV]SystemVerilog状态机实现案例

本文介绍了SystemVerilog中状态机的实现方法。首先使用枚举类型定义状态(TOP_HIB、TOP_BG、TOP_LDO、TOP_NOR),然后通过三个主要任务实现状态机:1)格式化现态寄存器处理状态转换;2)描述状态转移条件,包括计时器和稳定时间判断;3)基于当前状态和输入信号确定次态。状态机在时钟边沿或复位时更新状态,实现了从休眠到正常工作状态的转换逻辑,包含电源稳定时间检测等关键功能。

元直的博客 2022

vertx web连接超时 阻塞_Flink之基于Vertx的Mysql异步IO

导读在流计算中,如果以事件流为主,关联一些维度信息,就需要根据每个事件中的关键信息去数据库执行一次查询。正常的思路可能是通过mapFunction以阻塞的方式查询数据库,等待数据结果返回,然后执行下一个步骤。如果数据库查询时间很长,那有可能会阻塞流计算的整体流程。因此可以考虑异步的方式请求数据库,当数据返回时,该事件再继续执行下面的操作。这样提升了流计算的并发度,但是也增加了数据库的访问以及网络带...

weixin_39609170的博客 482

2、Elixir与Erlang:构建高可用系统的利器

本文介绍了Elixir与Erlang在构建高可用系统方面的优势,深入探讨了Erlang的并发机制、容错能力以及分布式特性,并结合实际应用场景展示了其在服务器端开发中的强大能力。此外,还提供了学习资源和交流平台,帮助开发者快速上手并深入实践。

grape的博客 125

Vert.x :Thread Thread[worker-pool-0,5,main] has been blocked for 129 ms, time limit is 0 ms

10月 12, 2020 9:29:51 上午 io.vertx.core.impl.BlockedThreadChecker 警告: Thread Thread[worker-pool-0,5,main] has been blocked for 129 ms, time limit is 0 ms 注意:创建线程池时时间单位默认纳秒。 /** * Like {@link #createSharedWorkerExecutor(String, int, long, TimeUnit)}..

haoranhaoshi的博客 1690

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

Apache ServiceComb 社区11月动态精选

点击蓝字关注这个神奇的公众号~Apache ServiceComb | 精选Apache ServiceComb 致力于帮助企业、用户和开发者将企业应用轻松微服务化上云,...

微服务技术与实践专栏 348

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

Clickhouse 通过JDBC方式从Oracle抽取数据,不借助任何抽数工具。顺便聊下Airbyte

Clickhouse 通过JDBC方式从Oracle抽取数据,不借助任何抽数工具。顺便聊下Airbyte。

weixin_46359306的博客 2719

ServiceComb/CSE常见问题处理(190110)

一、Tomcat重复加载war包问题 问题现象 有同事开发了一个demo服务,服务包含前端页面和ServiceComb开发的REST后端服务两部分。打成war包部署在Tomcat中,发现这个服务会在服务中心注册两个地址相同的实例。观察日志,发现Spring Context加载了两遍,并且Tomcat的webapps目录下存在一个与war包同名的目录和一个ROOT目录,两个目录中的内容是相同的。...

微服务技术与实践专栏 6851

Apache ServiceComb 社区3月动态精选

春风十里,不如你~点击蓝字,关注我们~tánɡ棠lí梨jiān煎xuě雪青鲤来时遥闻春溪声声碎嗅得手植棠梨初发轻黄蕊待小暑悄过 新梨渐垂来邀东邻女伴撷果缓缓归旧岁采得枝头...

微服务技术与实践专栏 1462

Unhandled exception. System.ArgumentException: Parameter is not valid.

该错误首先需要排查非托管资源是否得到及时的释放,例如Bitmap这些从IDisposable派生的非托管资源类对象。用using包含,或用Dispose手动释放。Unity3D环境。

AppleII的专栏 1547

CSE JAVA SDK 一个请求超时问题的定位

某业务出现一个奇怪的消息,一个接口的调用始终超时, 错误消息为: The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186, server is ...

微服务技术与实践专栏 3607

解决莫名其妙出现connection closed的错误

最近发现使用了springMVC的新项目偶尔出现connection closed,同事反映当访问同一个controller时经常出现类似错误 上回发现在使用 <context:component-scan base-package="com.controller" /> 对@cont...

weixin_33816300的博客 2万+

Vert.x初体验

Vert .x 什么是Vert .x? Vert.x框架基于事件和异步,依托于全异步Java服务器Netty,并扩展了很多其他特性,以其轻量、高性能、支持多语言开发 Hello world 创建一个简单的项目https://start.vertx.io/ 无需添加任何依赖 public class MainVerticle extends AbstractVerticle { @Override public void start(Promise<Void> startPromi

ShaoJie 383

servicecomb rpc 调用超时问题

servicecomb rpc 调用超时问题 错误日志如下: org.apache.servicecomb.swagger.invocation.exception.InvocationException: InvocationException: code=490;msg=CommonExceptionData [message=Unexpected consumer error, please check logs for details] 60cac2cafff29e45e1f86e0b at or

qq_29372275的博客 2066

java捕获http请求超时异常_Vertx HttpClientRequest - 无法捕获超时异常

我一直无法捕捉到在我的vertx HttpClientRequest中发生的异常。我在try-catch块中附上了我的连接并请求创建代码。我还添加了exceptionHandler和endHandler。但是当超时发生时,他们都没有被解雇。我收到的是以下错误消息,它将打印在控制台上。请告诉我如何捕获此异常,以便我可以使用相关信息回拨呼叫者。io.vertx.core.http.impl.HttpC...

weixin_36201438的博客 1864

关闭连接时报错

报错提示如下:attempted to use connection after closed was called,桟信息报错无法截图。 线上问题只能大概描述一下了,起因是公司自带的批处理框架单线程启动事物以后需要给另外一个函数传递一个事物的参数,但是这个事物不能更新,导致只能新起一个事物,但是在调用this.connn.closed这个方法的时候报错,目前不清楚原因,将持续记录这个问题 ...

qq_21575929的博客 768

蓝易云 - 诊断并修复SSH连接Github时遇到的“connection closed“错误。

需要从基础的网络检查做起,逐步过渡到深入的配置和服务端日志审查。如果所有步骤都未能解决问题,可能需要寻求更专业的技术支持,或者在GitHub社区寻找是否有其他开发者遇到并解决了类似的问题。解决SSH连接GitHub时遇到的"connection closed"错误,需要依次排查网络连通性、认证信息、SSH配置和服务器响应等多个可能影响连接的因素。这会显示尝试连接时发生的每个步骤的详细信息,帮助识别在哪个阶段连接关闭。如果不能ping通,可能是网络问题,检查代理设置或网络连接。如果没有添加,则使用。

高性价比服务器就选:蓝易云 499

Connection has been closed BEFORE response异常

最近我组使用的spring cloud gateway 线上偶发返回500,后台查看报错日志信息,发现有一条下面的异常: reactor.netty.channel.AbortedException: Connection has been closed BEFORE response 网上狂搜,以我以往的解决思路,欲解决问题,首先复现问题,然后再解决问题,这种最放心,若是实在无法复...

荒野哞的专栏 3万+
上一篇: 5分钟Serverless实践|构建无服务器的敏感词过滤后端系统
下一篇: ServiceComb/CSE常见问题处理(190110)
looook
博客等级 码龄20年 145粉丝 195原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值