Ray

可以打开accesslog日志，看看server端实际处理时间是否超时。 如果server业务处理没有超时的话，可以再看看client端和server端的异常日志，看看有没有什么可疑的异常，例如编解码异常、序列化异常等，一般编解码异常在请求上的表现也是超时

@Redliver 这个是client请求server时主动建立的链接，client发送请求和server返回response都是通过这个channel。一般出现这种情况的原因是client因为超时等原因主动关闭了链接，导致server发送reponse时失败

@Redliver 看日志信息，是client端断开链接时，server端没有正常断开链接，可以抓包看一下tcp断链过程有没有什么问题

只有使用hessian2序列化方式才能传递异常栈，其他序列化不支持。 transExceptionStack这个参数默认是true，只有不想传递异常栈时才需要设置为false。

暂时没有这个计划。 关于异常栈是否应传递到client侧，我们内部也讨论过很多次，最后的结论是client侧只需要关注异常类型，不需要关注造成异常的（未知的）原因，出现异常应联系服务提供方进行排查；server侧应关注未知异常，并根据对应的异常栈排查问题 如果一定要传输异常栈可以实现自定义filter把异常栈使用string方式放在request的attachment中。

如果client和server是运行在一个jvm中，可以考虑使用[injvm](https://github.com/weibocom/motan/wiki/zh_userguide#本地调用)协议，injvm协议是对象调用，不会走网络协议栈。 - server侧在配置中增加injvm协议配置，并且在service中同时导出injvm协议和motan/motan2协议 ```xml ``` - client侧增加injvm配置，可以通过placeholder占位符来指定要加载的protocol，比如指定实际使用的`used_protocol`值为`motan_injvm`或者`motan2_protocol` ```xml ```

最新版是增加了motan2协议，主要针对跨语言服务交互。原来的协议、功能都没有改变，只要配置不变，不会有兼容问题。 client和server按各自的节奏升级就行

motan可以通过[filter扩展](https://github.com/weibocom/motan/wiki/zh_developguide#扩展机制)实现熔断机制，目前还没有针对sentinel、hystrix的官方扩展，欢迎PR～

1、motan提供了打印分步耗时的trace日志的机制，不过需要你自己在程序中打开、关闭开关来控制。开关名：`MotanConstants.REQUEST_TRACK_LOG_SWITCHER` 打开trace日志后性能可能会略受影响，建议临时打开使用，使用完后关闭开关。 2、如果单机整体有几百个链接还好，一般不会有什么问题。如果一个server端提供的service有几十个，也可以考虑适当合并一下，减少单机导出的service数量。 如果是client端整体依赖了几十service的话，没有什么问题。可以考虑对qps低的service配置链接数，例如minClientConnection=1,maxClientConnection=3。 对于传输数据较大的service，可以考虑使用motan2协议导出服务，并设置mingzSize来开启gzip压缩。mingzSize是开启压缩的阈值，单位是byte。一般5k以上的数据都会有非常明显的压缩效果。

1W线程对8核的cpu来说还是太勉强了:) server端这些service是公用端口了吗？如果不同service的protocol配置相同的话，可以把不同的service按重要程度划分为几个端口，相同端口的service配置上shareChannel=true可以共享端口，一个端口上导出的serivce共用一个线程池