[GitHub] [rocketmq] bigyShot opened a new issue #2992: Does rocket support STOMP protocol?
bigyShot opened a new issue #2992: URL: https://github.com/apache/rocketmq/issues/2992 Does rocket support STOMP protocol? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] drpmma commented on issue #2992: Does rocket support STOMP protocol?
drpmma commented on issue #2992: URL: https://github.com/apache/rocketmq/issues/2992#issuecomment-857615474 STOMP protocol is not supported by now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] coveralls edited a comment on pull request #2983: [RIP-22] RocketMQ Stage Message Consumer Part
coveralls edited a comment on pull request #2983: URL: https://github.com/apache/rocketmq/pull/2983#issuecomment-855214461 [](https://coveralls.io/builds/40436982) Coverage decreased (-0.8%) to 53.216% when pulling **cb5d4de41d6ca821ded474da6f544664e78d5c5f on dragon-zhang:dev_periodic_concurrent_consumer_support2** into **52348b862c0dda897764c3b51fe1436c1a5ae0fe on apache:develop**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] codecov-commenter edited a comment on pull request #2983: [RIP-22] RocketMQ Stage Message Consumer Part
codecov-commenter edited a comment on pull request #2983: URL: https://github.com/apache/rocketmq/pull/2983#issuecomment-855214479 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] coveralls edited a comment on pull request #2983: [RIP-22] RocketMQ Stage Message Consumer Part
coveralls edited a comment on pull request #2983: URL: https://github.com/apache/rocketmq/pull/2983#issuecomment-855214461 [](https://coveralls.io/builds/40437215) Coverage decreased (-0.7%) to 53.311% when pulling **cb5d4de41d6ca821ded474da6f544664e78d5c5f on dragon-zhang:dev_periodic_concurrent_consumer_support2** into **52348b862c0dda897764c3b51fe1436c1a5ae0fe on apache:develop**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] codecov-commenter edited a comment on pull request #2983: [RIP-22] RocketMQ Stage Message Consumer Part
codecov-commenter edited a comment on pull request #2983: URL: https://github.com/apache/rocketmq/pull/2983#issuecomment-855214479 # [Codecov](https://codecov.io/gh/apache/rocketmq/pull/2983?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report > Merging [#2983](https://codecov.io/gh/apache/rocketmq/pull/2983?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (cb5d4de) into [develop](https://codecov.io/gh/apache/rocketmq/commit/52348b862c0dda897764c3b51fe1436c1a5ae0fe?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (52348b8) will **increase** coverage by `0.33%`. > The diff coverage is `28.26%`. [](https://codecov.io/gh/apache/rocketmq/pull/2983?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) ```diff @@ Coverage Diff @@ ## develop#2983 +/- ## = + Coverage 47.91% 48.24% +0.33% + Complexity 4560 3702 -858 = Files552 320 -232 Lines 3662830262-6366 Branches4844 4337 -507 = - Hits 1754914599-2950 + Misses 1685713653-3204 + Partials 2010 -212 ``` | [Impacted Files](https://codecov.io/gh/apache/rocketmq/pull/2983?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...ocketmq/broker/processor/AdminBrokerProcessor.java](https://codecov.io/gh/apache/rocketmq/pull/2983/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-YnJva2VyL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9icm9rZXIvcHJvY2Vzc29yL0FkbWluQnJva2VyUHJvY2Vzc29yLmphdmE=) | `7.93% <0.00%> (-0.03%)` | :arrow_down: | | [...etmq/broker/processor/ConsumerManageProcessor.java](https://codecov.io/gh/apache/rocketmq/pull/2983/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-YnJva2VyL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9icm9rZXIvcHJvY2Vzc29yL0NvbnN1bWVyTWFuYWdlUHJvY2Vzc29yLmphdmE=) | `4.25% <0.00%> (-1.63%)` | :arrow_down: | | [...ocketmq/client/consumer/DefaultMQPushConsumer.java](https://codecov.io/gh/apache/rocketmq/pull/2983/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvY29uc3VtZXIvRGVmYXVsdE1RUHVzaENvbnN1bWVyLmphdmE=) | `53.73% <0.00%> (-0.82%)` | :arrow_down: | | [...er/listener/MessageListenerStagedConcurrently.java](https://codecov.io/gh/apache/rocketmq/pull/2983/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvY29uc3VtZXIvbGlzdGVuZXIvTWVzc2FnZUxpc3RlbmVyU3RhZ2VkQ29uY3VycmVudGx5LmphdmE=) | `0.00% <0.00%> (ø)` | | | [...g/apache/rocketmq/client/impl/MQClientAPIImpl.java](https://codecov.io/gh/apache/rocketmq/pull/2983/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvaW1wbC9NUUNsaWVudEFQSUltcGwuamF2YQ==) | `11.97% <0.00%> (-0.22%)` | :arrow_down: | | [...he/rocketmq/client/impl/consumer/ProcessQueue.java](https://codecov.io/gh/apache/rocketmq/pull/2983/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvaW1wbC9jb25zdW1lci9Qcm9jZXNzUXVldWUuamF2YQ==) | `55.41% <0.00%> (-4.59%)` | :arrow_down: | | [...cketmq/client/impl/consumer/RebalancePushImpl.java](https://codecov.io/gh/apache/rocketmq/pull/2983/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+
[GitHub] [rocketmq] coveralls edited a comment on pull request #2983: [RIP-22] RocketMQ Stage Message Consumer Part
coveralls edited a comment on pull request #2983: URL: https://github.com/apache/rocketmq/pull/2983#issuecomment-855214461 [](https://coveralls.io/builds/40437274) Coverage decreased (-0.7%) to 53.294% when pulling **cb5d4de41d6ca821ded474da6f544664e78d5c5f on dragon-zhang:dev_periodic_concurrent_consumer_support2** into **52348b862c0dda897764c3b51fe1436c1a5ae0fe on apache:develop**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-operator] shendongsd opened a new issue #74: Add nodeAffinity for nameService pod
shendongsd opened a new issue #74: URL: https://github.com/apache/rocketmq-operator/issues/74 1、users need nodeAffinity feature to determine which nodes the pods are scheduled. We can contribute those code -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-operator] shendongsd opened a new pull request #75: Add nodeAffinity for nameService pod
shendongsd opened a new pull request #75: URL: https://github.com/apache/rocketmq-operator/pull/75 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] dragon-zhang commented on issue #2937: [RIP-22] RocketMQ Stage Message
dragon-zhang commented on issue #2937: URL: https://github.com/apache/rocketmq/issues/2937#issuecomment-857688087 EN I support the definition of multi-phase policy in PR, and filter messages that do not need phase concurrency. I will update to mail and GitHub later CN 我在PR中支持了多阶段策略的定义，以及过滤不需要阶段性并发的消息，稍后我将更新到邮件和github -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: RIP23: Support gRPC protocol
+1 for this proposal. Obviously, supporting gRPC could make it easier for RocketMQ contributors to write multi-Language SDKs. Looking forward to more details of this proposal. Regards, yukon On Wed, Jun 9, 2021 at 11:10 AM Zhanhui Li wrote: > Hi, > This proposal, in general, is in the right direction that helps RocketMQ > provide full-fledged SDK for popular languages and platforms. Taking full > advantage of gRPC does save a lot of effort in terms of serialization and > RPC tiers. Obviously, this proposal also brings complexities and potential > compatibility issues. > > One of the potential issues is that gRPC does not expose Channel in the > implementation while RocketMQ processors make heavy use of it, even if both > of them are built on top of Netty 4.x. Will this an issue when reuse > existing code? > > Zhanhui Li > > On Tue, Jun 8, 2021 at 8:28 PM i yangkun wrote: > > > Background & Motivation > > What do we need to do > > > > > > * Will we add a new module? > > maybe. > > * Will we add new APIs? > > Yes. > > > > * Will we add new feature? > > Yes. > > > > > > Why should we do that > > > > > > * Are there any problems of our current project? > > > > a. Remoting module is too complicated to maintain, gRPC makes it easier > to > > establish a robust communication layer, the current remoting module would > > be simplified radically. > > > > b. gRPC has been the de-facto standard in CloudNative, service mesh would > > be easily applied if gRPC is enabled. > > > > c. The private protocol of RocketMQ depends on the FastJson, it is > > difficult to adapt for other language. > > > > On the other side, since the pop consumer has been merged, we could > > implement new SDK based on gRPC and pop, which is easier to develop and > > maintain. > > > > Chinese Version: > > > > a. Remoting 模块对于长期的维护而言过于复杂了，我们可以使用 gRPC 更轻松地建立起一个健壮的通信层，这会使得现有的 remoting > > 模块从根本上得到简化。 > > > > b. gRPC 目前已经是云原生时代的事实标准，使用 gRPC 可以使得我们天然获取一些云原生的能力，比如 Service Mesh。 > > > > c. 目前 RocketMQ 的私有协议强烈依赖 FastJson，多语言的适配将会变得困难。 > > > > > > 从另外一个角度来说，鉴于 pop 消费者已经被合并，我们可以基于 gRPC 和 pop 实现新的 SDK，新的 SDK 将会更加易于开发和维护。 > > > > Goals > > > > > > * What problem is this proposal designed to solve? > > > > Support gRPC's protocol, simplify current communication layer oof > > RocketMQ, make it easier to adapt for other language, which is not > limited > > to CPP/GO/C#/GO。 > > > > Chinese Version: > > > > 支持 gRPC 协议，简化 RocketMQ 现有的通信层，复用 gRPC 的能力，简化多语言适配成本，不限于 CPP/GO/C#/GO。 > > > > * To what degree should we solve the problem? > > This RIP must guarantee below point: > > > > 1. Compatibility: Both of gRPC and RemotingCommand should be > supported. > > 2. High performance: This implementation does not affects latency and > > throughput. > > > > > > Chinese Version: > > > > 新方案需要保证两点： > > > > 1. 兼容性：同时支持 gRPC 和 RemotingCommand 协议，不影响现有功能。 > > 2. 高性能：基于 gRPC 的实现不影响整理的延时和吞吐量。 > > > > > > Non-Goals > > > > > > * What problem is this proposal NOT designed to solve? > > Nothing specific. > > * Are there any limits of this proposal? > > Nothing specific. > > > > > > Changes > > Architecture > > > > > > Current broker processor and client. > > > > [ > > > https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142547507-128b85f5-98f4-4568-85f8-28ef32982b7c.png > > ] > > > > Proposed gRPC processor and client. > > > > [ > > > https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142552491-a7f58ac0-cd7d-4ddd-936e-fb296b667196.png > > ] > > > > Broker would provide a protocol negotiate procedure to distinguish > > RemotingCommand from gRPC protocol. two kinds or processor in broker > would > > re-use the same port to serve for RPC from different SDK. > > > > > > Chinese Version: > > > > broker 本身提供协议协商机制用于区分 RemotingCommnad 和 gRPC 协议，broker 针对 gRPC 和 > > RemotingCommand 提供不同的 processor 为各自的 SDK 服务。 > > > > Interface Design/Change > > > > > > * Method signature changes > > Nothing specific. > > * Method behavior changes > > Nothing specific. > > > > * CLI command changes > > Nothing specific. > > * Log format or content changes > > Nothing specific. > > > > > > Compatibility, Deprecation, and Migration Plan > > > > > > * Are backward and forward compatibility taken into consideration? > > > > Broker support processor of RemotingCommand and gRPC simultaneously, so > > there are one compatibility situations: > > > > If user migrates from original SDK to gRPC SDK in push mode, the > > re-balance policy should make sure that it would not cause repeated > > consumption for a lot of messages. > > > > * Are there deprecated APIs? > > Nothing specific. > > * How do we do migration? > > Nothing specific. > > > > > > Implementation Outline > > > > > > We will implement the proposed changes by 4 phases. > > > > > > Phase 1 > > > > 1. Provides gRPC protocol definition(IDL) > > > > Phase 2 > > > > 1. Implement gRPC processor of broker. > > 2. Implement protocol negotiation o
Re: RIP23: Support gRPC protocol
能否像dubbo那样，除了实现一些常用的序列化，也用SPI，让用户可以自定义序列化？ 发自我的iPhone -- Original -- From: yukon https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142547507-128b85f5-98f4-4568-85f8-28ef32982b7c.png > > ] > > > > Proposed gRPC processor and client. > > > > [ > > > https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142552491-a7f58ac0-cd7d-4ddd-936e-fb296b667196.png > > ] > > > > Broker would provide a protocol negotiate procedure to distinguish > > RemotingCommand from gRPC protocol. two kinds or processor in broker > would > > re-use the same port to serve for RPC from different SDK. > > > > > > Chinese Version: > > > > broker 本身提供协议协商机制用于区分 RemotingCommnad 和 gRPC 协议，broker 针对 gRPC 和 > > RemotingCommand 提供不同的 processor 为各自的 SDK 服务。 > > > > Interface Design/Change > > > > > > * Method signature changes > > Nothing specific. > > * Method behavior changes > > Nothing specific. > > > > * CLI command changes > > Nothing specific. > > * Log format or content changes > > Nothing specific. > > > > > > Compatibility, Deprecation, and Migration Plan > > > > > > * Are backward and forward compatibility taken into consideration? > > > > Broker support processor of RemotingCommand and gRPC simultaneously, so > > there are one compatibility situations: > > > > If user migrates from original SDK to gRPC SDK in push mode, the > > re-balance policy should make sure that it would not cause repeated > > consumption for a lot of messages. > > > > * Are there deprecated APIs? > > Nothing specific. > > * How do we do migration? > > Nothing specific. > > > > > > Implementation Outline > > > > > > We will implement the proposed changes by 4 phases. > > > > > > Phase 1 > > > > 1. Provides gRPC protocol definition(IDL) > > > > Phase 2 > > > > 1. Implement gRPC processor of broker. > > 2. Implement protocol negotiation of two kinds of protocol(gRPC and > > RemotingCommand) > > > > Phase 3 > > > > 1. Implement new JAVA and CPP native SDK based on gRPC > > > > Phase 4 > > > > 1. Implement native SDK base on gRPC for other language. > > > > > > Rejected Alternatives > > > > > > How does alternatives solve the issue you proposed? > > > > > > Thrift? not so much impact as gRPC in community. > > > > > > Pros and Cons of alternatives > > > > > > Nothing specific. > > > > Why should we reject above alternatives > > > > >
[GitHub] [rocketmq] fangzhiheng opened a new issue #2993: DLedgerCommitlogTest#testTruncateCQ 单元测试执行错误
fangzhiheng opened a new issue #2993:
URL: https://github.com/apache/rocketmq/issues/2993
```java
public void testTruncateCQ() throws Exception {
{
Test Case
}
{
Test Case
}
...
}
```
由于他们复用了一个数据目录，而在第一个测试用例执行的时候，程序依然占用着数据目录中的文件句柄，导致第二个测试用例在删除文件时失败，最终断言失败：
```java
DefaultMessageStore messageStore = createDledgerMessageStore(base, group,
"n0", peers, null, false, 0); // 此时创建了24个文件
```
```java
DefaultMessageStore messageStore = createDledgerMessageStore(base, group,
"n0", peers, null, false, 4); // 删除4个
```
执行结果如下：
```bash
java.lang.AssertionError:
Expected :20
Actual :24
...
```
操作系统：Windows 10 (Linux 无此问题)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [rocketmq] bigyShot commented on issue #2992: Does rocket support STOMP protocol?
bigyShot commented on issue #2992: URL: https://github.com/apache/rocketmq/issues/2992#issuecomment-858203500 > STOMP protocol is not supported by now. thanks -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] bigyShot closed issue #2992: Does rocket support STOMP protocol?
bigyShot closed issue #2992: URL: https://github.com/apache/rocketmq/issues/2992 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: RIP23: Support gRPC protocol
这里的一个思考是，当下多语言大家真的觉得痛吗？可以参考Dapr社区目前的多语言问题。社区的小伙伴可以发表一下自己的意见。另外，我非常担心新协议的兼容性，当下社区发展还是非常快的，全世界范围内使用的人也非常多，希望能够看到平滑过度的更细致的方案。 HTTP3是未来的方向，也是目前尖端企业在研究跟进包括落地的方向，我也希望在proposal里看到这块的想法。 p.s 这个问题可以更开放一些，所以这里我用中文来回复。非常希望听到更多的来自社区朋友的反馈。 炼龙 <1936978...@qq.com> 于2021年6月10日周四 上午6:13写道： > 能否像dubbo那样，除了实现一些常用的序列化，也用SPI，让用户可以自定义序列化？ > > > > 发自我的iPhone > > > -- Original -- > From: yukon Date: Wed,Jun 9,2021 9:48 PM > To: dev Subject: Re: RIP23: Support gRPC protocol > > > > +1 for this proposal. > > Obviously, supporting gRPC could make it easier for RocketMQ contributors > to write multi-Language SDKs. Looking forward to more details of this > proposal. > > Regards, > yukon > > On Wed, Jun 9, 2021 at 11:10 AM Zhanhui Li wrote: > > > Hi, > > This proposal, in general, is in the right direction that helps > RocketMQ > > provide full-fledged SDK for popular languages and platforms. Taking > full > > advantage of gRPC does save a lot of effort in terms of serialization > and > > RPC tiers. Obviously, this proposal also brings complexities and > potential > > compatibility issues. > > > > One of the potential issues is that gRPC does not expose Channel in > the > > implementation while RocketMQ processors make heavy use of it, even > if both > > of them are built on top of Netty 4.x. Will this an issue when > reuse > > existing code? > > > > Zhanhui Li > > > > On Tue, Jun 8, 2021 at 8:28 PM i yangkun wrote: > > > > > Background & Motivation > > > What do we need to do > > > > > > > > > * Will we add a new module? > > > maybe. > > > * Will we add new APIs? > > > Yes. > > > > > > * Will we add new feature? > > > Yes. > > > > > > > > > Why should we do that > > > > > > > > > * Are there any problems of our current > project? > > > > > > a. Remoting module is too complicated to maintain, gRPC makes it > easier > > to > > > establish a robust communication layer, the current remoting > module would > > > be simplified radically. > > > > > > b. gRPC has been the de-facto standard in CloudNative, service > mesh would > > > be easily applied if gRPC is enabled. > > > > > > c. The private protocol of RocketMQ depends on the FastJson, it > is > > > difficult to adapt for other language. > > > > > > On the other side, since the pop consumer has been merged, we > could > > > implement new SDK based on gRPC and pop, which is easier to > develop and > > > maintain. > > > > > > Chinese Version: > > > > > > a. Remoting 模块对于长期的维护而言过于复杂了，我们可以使用 gRPC 更轻松地建立起一个健壮的通信层，这会使得现有的 > remoting > > > 模块从根本上得到简化。 > > > > > > b. gRPC 目前已经是云原生时代的事实标准，使用 gRPC 可以使得我们天然获取一些云原生的能力，比如 Service > Mesh。 > > > > > > c. 目前 RocketMQ 的私有协议强烈依赖 FastJson，多语言的适配将会变得困难。 > > > > > > > > > 从另外一个角度来说，鉴于 pop 消费者已经被合并，我们可以基于 gRPC 和 pop 实现新的 SDK，新的 SDK > 将会更加易于开发和维护。 > > > > > > Goals > > > > > > > > > * What problem is this proposal designed > to solve? > > > > > > Support gRPC's protocol, simplify current communication layer oof > > > RocketMQ, make it easier to adapt for other language, which is > not > > limited > > > to CPP/GO/C#/GO。 > > > > > > Chinese Version: > > > > > > 支持 gRPC 协议，简化 RocketMQ 现有的通信层，复用 gRPC 的能力，简化多语言适配成本，不限于 > CPP/GO/C#/GO。 > > > > > > * To what degree should we solve the > problem? > > > This RIP must guarantee below point: > > > > > > 1. Compatibility: Both of gRPC and > RemotingCommand should be > > supported. > > > 2. High performance: This implementation does > not affects latency and > > > throughput. > > > > > > > > > Chinese Version: > > > > > > 新方案需要保证两点： > > > > > > 1. 兼容性：同时支持 gRPC 和 RemotingCommand 协议，不影响现有功能。 > > > 2. 高性能：基于 gRPC 的实现不影响整理的延时和吞吐量。 > > > > > > > > > Non-Goals > > > > > > > > > * What problem is this proposal NOT > designed to solve? > > > Nothing specific. > > > * Are there any limits of this proposal? > > > Nothing specific. > > > > > > > > > Changes > > > Architecture > > > > > > > > > Current broker processor and client. > > > > > > [ > > > > > > https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142547507-128b85f5-98f4-4568-85f8-28ef32982b7c.png > > > ] > > > > > > Proposed gRPC processor and client. > > > > > > [ > > > > > > https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142552491-a7f58ac0-cd7d-4ddd-936e-fb296b667196.png > > > ] > > > > > > Broker would provide a protocol negotiate procedure to > distinguish > > > RemotingCommand from gRPC protocol. two kinds or processor in > broker > > would > > > re-use the same port to serve for RPC from different SDK. > > > > > > > > > Chinese Version: > > > > > > broker 本身提供协议协商机制用于区分 RemotingCommnad 和 gRPC 协议，broker 针对 gRPC 和 > > > RemotingCommand 提供不同的 processor 为各自的 SDK 服务。 > > > > > > Interface Design/Change > > > > > > > > > * Method signature changes > > > Nothing specific. > > > * Method behavior changes > > > Nothing specific. > > > > > > * CLI command changes > > > Nothing specific. > > > * Log format or content changes > > > Nothing spe
[GitHub] [rocketmq-externals] vongosling merged pull request #724: [ISSUE #723] When the operation is successful, the dialog will close automatically
vongosling merged pull request #724: URL: https://github.com/apache/rocketmq-externals/pull/724 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-externals] vongosling closed issue #723: [rocketmq-console] When the operation is successful, the dialog will close automatically.
vongosling closed issue #723: URL: https://github.com/apache/rocketmq-externals/issues/723 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] 916669644 opened a new issue #2994: 异步发送demo里的CountDownLatch2 的减数问题
916669644 opened a new issue #2994: URL: https://github.com/apache/rocketmq/issues/2994 问题地址:https://github.com/apache/rocketmq/blob/master/docs/cn/RocketMQ_Example.md#2%E5%8F%91%E9%80%81%E5%BC%82%E6%AD%A5%E6%B6%88%E6%81%AF 这里定义了一个CountDownLatch2 但是没有发现有减数操作,看到这里用是countDownLatch.await(5, TimeUnit.SECONDS);如果初衷只是休眠5秒,我想您应该会用TimeUnit.SECONDS.sleep(5);这样更简洁明了的操作吧,所以这里大胆猜测您是为了更好的满足性能,您这里是不是缺少了减数操作呢? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] francisoliverlee merged pull request #2991: [ISSUE #2990] Add message tracing switch in sendMessage command of mqadmin
francisoliverlee merged pull request #2991: URL: https://github.com/apache/rocketmq/pull/2991 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] yuz10 closed issue #2990: Add message tracing switch in sendMessage command of mqadmin
yuz10 closed issue #2990: URL: https://github.com/apache/rocketmq/issues/2990 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] francisoliverlee commented on issue #2990: Add message tracing switch in sendMessage command of mqadmin
francisoliverlee commented on issue #2990: URL: https://github.com/apache/rocketmq/issues/2990#issuecomment-858351517 pls add some doc about how to use it. you can check it in the PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
