bwzhang2012
bwzhang2012
@RichardHightower, as zookeeper widely used for distributed service registry, any idea for zookeeper support for service discovery officially as we knew that qbit support consul (but zookeeper seems more common)
mybatis provide simple cache integration defined in mybatis mapper xml. but it has some problem that the cache integrated sometimes is not initialized completed while the application context is loading....
@stevensouza, when I compiled the jamonapi with findbugs check, I found there're some built-in check errors found according to findbugs, so any idea on improve the source code quality as...
@knightliao，感谢提供pikaQ组件来实现分布式可靠消息（虽然还没有release)。我的问题是，是否考虑过IMDG的一些技术来达到这个手段（下述是我的一些理解，不足之处请斧正） 1. 以hazelcast为例，其提供了带事务特征的消息队列TransactionQueue，其通过两阶段方式（具体请参考https://github.com/hazelcast/hazelcast-reference-manual/blob/master/src/Transactions/Transactions.md 实现队列操作数据的完整性 2. 就MQ在事务提交过程环节中存在的回滚以及可能引发的脏数据，我的看法是如果TransactionQueue关联的事务环境（通过TransactionContext)如果能够参与当前业务数据的事务，那么应该也可以做到当其事务回滚那么MQ的事务也将回滚，能确保MQ数据不会多（即MQ的事务参与到业务事务中，后者提交成功才能确保MQ事务的提交、而两阶段方式能够确保MQ能一定将数据同步，即业务事务处理成功后） 3. MQ环节记录的消息信息（即待处理）需进行持久化，这个可否考虑berkeley db（其既为嵌入式又支持事务）来替代MYSQL 我的想法(不知是否可行）： 1. 构建围绕IMDG的集群环境，参与集群的机器均集成针对berkeley db的支持 2. 参与分布式可靠消息的应用，均通过客户端API连接到IMDG中。如果A与B系统存在分布式事务的关联，则通过1来进行知会。 3. IMDG的事务提交如transactionContext，可引入针对当前事务的支持（transactionManager)， 我个人的经验是引入hazelcastmq（内部集成了spring transaction的支持） 4. 当A系统业务处理然后再引入消息队列控制时，如1-3的内部支持可使得A系统业务OK后，产生了需要B系统进行同步处理的消息（并得到持久化)，B系统对接到集群环节中会从相关队列中提取带待同步处理的消息，处理完毕后再更新持久化消息（队列方式则决定当B成功读取消息后会从其移除掉） ——如果该环节环节突然处理失败，则重启后仍然会提取到待处理的消息 上面的考虑是考虑引入针对hazelcast等transactionManager支持（看可否不考虑AOP方式）
Hi, 用findbugs检查rpc源码的时候，有几个地方需要咨询一下： 1. AbstractClientRemoteExecutor 类中 public Object invoke(RemoteCall call)方法中 针对rpcCache的KEY处理——代码中该cache的key类型是String，但是操作前后不一致： rpcCache.put(this.genRpcCallCacheKey(request.getThreadId(), request.getIndex()), sync); --- 这里key类型是string rpcCache.remove(sync.getIndex()); ----这里key类型是int 而且貌似值不匹配啊——是否是BUG 1. 注意到一些sync处理中的sleep调用， Thread.currentThread().sleep(N)——这种可否直接Thread.sleep(N) 2. 能否提供一些性能测试的example啊，对比一下dubbo(x)等
@mpilone, long time since such project not updated yet. the latest version with hazelcast has brought in ringbuffer and reliable topic. I think it's better for hzmq brought in such...
大神好，就socket.d的应用场景有问题需指教一二（结合类似在线或IM聊天场景）： 1. 现状：当前公司在线系统（即会员与客服聊天）前后端交互主要通过HTTP协议（前端发起请求后、使用轮询方式来更新最新聊天数据——而后端服务则是私有协议、基于thrift，中间通过网关层将私有协议暴露成HTTP方式供外部调用，前后端交互通过对外域名、经网关层后转发给到后端服务）；系统迭代过程中也要支持会员与大模型聊天，当前选型是通过grpc方式对接——即在线后端服务与某grpc服务交互，而前端仍选择是轮询方式；鉴于轮询方式存在弊端且特别对人机交互不友好，故需选型类似sse或ws的协议支持 2. 困难：当前网关层承接了前后端服务的路由、但现有网关对外并不纯支持长连接方式（均以HTTP协议为准、即将私有协议发布成HTTP URI方式）而后端服务是基于私有协议并不支持类WS这种双工或SSE这种服务端推的方式，即对聊天这种交互不友好。现有解决方案则跟爱奇艺的方式近似：https://baijiahao.baidu.com/s?id=1692748005375644637&wfr=spider&for=pc 但这种方式架构则比较复杂（如后端服务要把消息发送给前端、需先发送到一个restful的服务、然后该服务将消息投递给到MQ， 然后网关节点消费该消息并与本地session匹配.......） 3. 问题： 3.1 socket.d涉及http协议： 1）Q1. 鉴于Http协议相比tcp以及ws还是有其优势的，特别是2.0/3.0，即便前端与后端使用ws等交互、http也需保留来支持兜底——因此socket.d是否需支持，考虑到socket.d的transport有netty模块，是否考虑支持http方式的接入 2）Q2. 就上述，若socket.d支持了http、但基于http协议的sse是否可支持（或者是server push）、我理解当前sse前端是一套标准的js的是否跟现有socket.d的js存在出入 3.2 socket.d涉及multi broker： 1）背景：即考虑将现网关改造成multi broker，前端与后端均类似于client方式接入到broker、而broker肯定是多台（multi broker） 2) Q1：一般前端都是通过nginx代理给到broker的，若要兼顾broker是高可用的——如何使得Nginx代理到这多台组成的集群中（而且一般当下都是域名、即只有一个serverUrl） 3）Q2：同上、如果mult broker对外就是域名本身，若是后端服务接入当调用createClusterClient的时候是否创建也是clusterSession 4) Q3：如果需要broker兼顾支持sse以及ws或者http 是否可以——...
when I run HttpTransportTest and just made simple modification to the method of testMultipleMessages() : @Test public void testMultipleMessages() throws URISyntaxException, IOException, InterruptedException { server.addEventListener("hello", String.class, (client, data, ackSender) ->...