Hp

上面描述可能有点不太准确。 如下图，如果我自定义的BaseMapper是含有泛型信息，然后在生成的时候我选择了这个为baseClass。  这时候不会将对应的AdminRole传给BaseMapper（还有一种可能就是，需要传上去的泛型不是当前entity）。 

嗯，就是你自定义的一个父类，tk.mapper是可以的

关于粘性服务调用的一点建议。 从终端上来的数据有时会被分拆成数份进行传输，如希望能够实现对这一批数据定向的进行服务调用，是否可以考虑在Broker中增加根据某一特定的标识进行路由的缓存，后续相同标识的请求将直接调用缓存中的服务接口；并提供清除当前标识缓存的标识，在这批数据结束时得以清除路由的缓存。 对比现有使用sticky标识来标识的方案，此来可以实现数据和操作的一致性，同时又有一定的负载能力，而且数据的负载不会被绑定到某一个应用上，而是比接口层面更细粒度的控制。 这也可以很好的满足@pc859107393 需求的场景，只要让缓存的标识和当前应用相关，与具体的业务数据无关即可，但此并非用于解决性能的瓶颈问题。同时可以添加关于时间的控制，在读写空闲一定时间后自动清除缓存的标识，从而释放服务调用的粘性。 因为同一批的数据一般会存在相同的唯一标识以及类似于“结束帧”的标识，感觉这个方案有一定的可行性。 问题是无法很好的和@RSocketService结合起来，或者是结合@ServiceMapping，增加一个规则匹配，用以解析入参的值。目前我这边正在考虑实现的方案，或者您那边有没有更好的建议，后续有结果了会提交代码，到时候麻烦看看是否合理。

请问这个问题还有后续么，我这边也遇到相同的问题，也是传输图片分片数据，然后断开了。目前的链路是这样的provider->broker->consumer，三者部署在同一台服务器上。但是很奇怪的是，provider应用没有断开，consumer应用反而断开了。其次，consumer应用断开后，虽然报了RST-500407，但是却并没有重连操作，Broker的服务端和客户端的版本均是1.1.2。

> @hupeiD 我是自己实现了直连，轻松解决问题。 我这边要动态的分配到不同的节点，所以没法用p2p去实现。

> > 请问这个问题还有后续么，我这边也遇到相同的问题，也是传输图片分片数据，然后断开了。目前的链路是这样的provider->broker->consumer，三者部署在同一台服务器上。但是很奇怪的是，provider应用没有断开，consumer应用反而断开了。其次，consumer应用断开后，虽然报了RST-500407，但是却并没有重连操作，Broker的服务端和客户端的版本均是1.1.2。 > > 这个经常出现还是偶发的？ 能重现吗？ 是必现的，我简单说一下场景，希望可以帮助你分析。 现在将provider、broker和consumer部署在不同服务器上，产生的图片分片数据，通过provider经由broker转发给consumer，监控流量，大概在15Mb/s~20Mb/s左右，consumer就断开连接了。consumer应用仍在运行，但是与Broker已断连，有不断打印心跳超时的日志，但是无重连日志，期间检测到consumer的CPU使用率暴涨到96%左右，具体哪个线程还需要分析。

@linux-china 图片大小其实只有5KB左右，并发请求不到400。是用request/response发送的，按我理解，经过broker的话，request/stream和request/response似乎区别不是很大。 也考虑过保存到中心存储，但是由于实时性要求高，所以并不是第一方案。由于网络是内部搭建的，网络资源上倒是还好。关于RSocket的16M的大小限制，这点我确实不太清楚，方便的话能说一下具体的情况么，或者这是可以调整的。如果无法调整，那可能要考虑中心存储或者其他方案了。 样例其实比较简单，就是consumer提供一个接口上传图片，对同一组图片做二次处理，然后到存储就是了。demo如果需要，我花点时间稍晚点再上传。：)

基本能确定是因为用户线程使用不当，长时间压测导致的消息堆积，使Netty的工作线程阻塞，最后引发心跳超时。 看源码，应该是没有另外指定线程池的，那client和server的通信另外指定线程池会不会更好呢？

那想问下，1.1.5版本是否兼容jdk11呢，还是Broker Server得用jdk17，客户端则无所谓

配置文件里，rsocket.brokers如果不是采用逗号分割的字符串格式，好像就会报这个错，具体原因没深究