zyxdSTU
zyxdSTU
对于这个模型，有没有开源源码？？
> 1. 可以强制走接口级先饶过 > 2. setProtocol 方法会在 [Fix wildcard match #10256](https://github.com/apache/dubbo/pull/10256) 中修复 > 3. hessian 协议兼容版 jar 会在[Add rpc and serialization implmentations dubbo-spi-extensions#125](https://github.com/apache/dubbo-spi-extensions/pull/125) 中提供 目前强制走接口级别，会出现consumer 订阅不了hessian协议服务的问题。所以还是等修复把。
> 能再具体说下出现的场景吗，看起来是直接telnet了端口，然后写数据，不是通过服务端回传的 1、provider提供一个数据查询服务 RpcResult executeQuerySQL(String dataSourceKey, String sql, Class clazz, Boolean returnHeader， 返回的数据大小可能大于8M 所以在Dubbo配置文件中，设置了payload为100M, 、 2、consumer在调用provider服务的时候，接收的数据大小超过8M后，抛出异常 `NettyChannel [channel=[id: 0x4b4524e3, L:/10.11.33.60:49760 - R:/10.11.33.60:20881]], url: dubbo://10.11.33.60:20881/org.apache.dubbo.metadata.MetadataService?codec=dubbo&dubbo=2.0.2&group=datacenter-api-local-asda&heartbeat=60000&port=20881&protocol=dubbo&release=3.0.1&side=consumer&timeout=5000&version=1.0.0 at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received(HeaderExchangeHandler.java:184) at org.apache.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:51) at org.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:57)...
@AlbumenJ 我怀疑服务端回传的数据，被客户端截断了，导致不能正确处理，client端相关代码，和报出来的错误。 ``` java @Override public void received(Channel channel, Object message) throws RemotingException { final ExchangeChannel exchangeChannel = HeaderExchangeChannel.getOrAddChannel(channel); if (message instanceof Request) { // handle request. Request request =...
功能的话，主要是请求数据库表中的多行数据。 ```java RpcResult executeQuerySQL(String dataSourceKey, String sql, Class clazz, Boolean returnHeader); ```
> 这么大的payload为啥要通过rpc方式？会不会是序列化时间过长的原因？或者上传一个简单demo我们复现一下？ demo有点难，我又找到了点蛛丝马迹，payload失效了？ 为什么是MetaDataService, 而不是GPDataService(provider提供的服务） ERROR org.apache.dubbo.remoting.exchange.codec.ExchangeCodec - [DUBBO] Data length too large: 11361246, max payload: 8388608, channel: NettyChannel [channel=[id: 0x7f457c68, L:/10.11.33.60:50972 - R:/10.11.33.60:20881]], dubbo version: 3.0.1, current host: 10.11.33.60...
> 我这边本地没有复现出问题，出现是 `org.apache.dubbo.metadata.MetadataService` 的原因是取的 channel 的 url，这个默认只存第一个发布的 url，由于 `org.apache.dubbo.metadata.MetadataService` 是第一个发布的服务，所以日志写的是这个。 方便把客户端和服务端分机器部署看下吗，看下这个日志报错是在哪一侧抛出来的，是服务端抛的异常只是在消费端打印还是本身就是消费端异常。 我肯定消费端异常
作者的代码中 有没有 测试CONLL2003的数据的部分？？ 计算出 F1值， recall, precise 还是单纯得标记一段文本用于测试