[GitHub] [rocketmq] zhouxinyu commented on a change in pull request #3987: [RIP-37] Add new APIs for producer
zhouxinyu commented on a change in pull request #3987:
URL: https://github.com/apache/rocketmq/pull/3987#discussion_r828802965
##
File path: apis/src/main/java/org/apache/rocketmq/apis/producer/Producer.java
##
@@ -0,0 +1,102 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.rocketmq.apis.producer;
+
+import com.google.common.util.concurrent.Service;
+import java.util.List;
+import java.util.concurrent.CompletableFuture;
+import java.io.Closeable;
+import org.apache.rocketmq.apis.exception.ClientException;
+import org.apache.rocketmq.apis.message.Message;
+
+/**
+ * Producer is a thread-safe rocketmq client which is used to publish messages.
+ *
+ * On account of network timeout or other reasons, rocketmq producer only
promised the at-least-once semantics.
+ * For producer, at-least-once semantics means potentially attempts are made
at sending it, messages may be
+ * duplicated but not lost.
+ */
+public interface Producer extends Closeable {
+/**
+ * Sends a message synchronously.
+ *
+ * This method does not return until it gets the definitive result.
+ *
+ * @param message message to send.
+ */
+SendReceipt send(Message message) throws ClientException;
+
+/**
+ * Sends a transactional message synchronously.
+ *
+ * @param message message to send.
+ * @param transaction transaction to bind.
+ * @return the message id assigned to the appointed message.
+ */
+SendReceipt send(Message message, Transaction transaction) throws
ClientException;
+
+/**
+ * Sends a message asynchronously.
+ *
+ * This method returns immediately, the result is included in the
{@link CompletableFuture};
+ *
+ * @param message message to send.
+ * @return a future that indicates the result.
+ */
+CompletableFuture sendAsync(Message message);
+
+/**
+ * Sends batch messages synchronously.
+ *
+ * This method does not return until it gets the definitive result.
+ *
+ * All messages to send should have the same topic.
+ *
+ * @param messages batch messages to send.
+ * @return collection indicates the message id assigned to the appointed
message, which keep the same order
+ * messages collection.
+ */
+List send(List messages) throws ClientException;
+
+/**
+ * Begins a transaction.
+ *
+ * For example:
+ *
+ * {@code
+ * Transaction transaction = producer.beginTransaction();
+ * MessageView messageView1 = producer.send(message1, transaction);
+ * MessageView messageView2 = producer.send(message2, transaction);
Review comment:
Return SendReceipt
--
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.
To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [rocketmq-client-cpp] ifplusor commented on issue #409: Inconsistent directory structure Help!!
ifplusor commented on issue #409: URL: https://github.com/apache/rocketmq-client-cpp/issues/409#issuecomment-1070308125 @shencw You need to use below command ```bash sudo cp rocketmq-client-cpp/include/c/* /usr/local/include/rocketmq ``` instead of ```bash sudo cp rocketmq-client-cpp/include/* /usr/local/include/rocketmq ``` -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] coveralls commented on pull request #3989: #fix replace UNKNOW with UNKNOWN in LocalTransactionState enum
coveralls commented on pull request #3989: URL: https://github.com/apache/rocketmq/pull/3989#issuecomment-1070013963 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-mqtt] tianliuliu commented on issue #35: Practice sharing
tianliuliu commented on issue #35: URL: https://github.com/apache/rocketmq-mqtt/issues/35#issuecomment-106171 > We use the same approach for communication between applications and services but not by a gateway we use a mqtt client to send message from rocketmq to mqtt broker by a gateway seem to reduce number of communication between mqtt-client and mqtt-broker consume rocketmq and then use mqtt client send to mqtt broker? Can you express it more clearly, I don't know if I understand it right? -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] codecov-commenter commented on pull request #3989: #fix replace UNKNOW with UNKNOWN in LocalTransactionState enum
codecov-commenter commented on pull request #3989: URL: https://github.com/apache/rocketmq/pull/3989#issuecomment-1069972274 # [Codecov](https://codecov.io/gh/apache/rocketmq/pull/3989?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 [#3989](https://codecov.io/gh/apache/rocketmq/pull/3989?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (27bcee7) into [develop](https://codecov.io/gh/apache/rocketmq/commit/03c5a3d171eb8667a7d13409d45723005c4c22f5?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (03c5a3d) will **decrease** coverage by `0.20%`. > The diff coverage is `33.33%`. ```diff @@ Coverage Diff @@ ## develop#3989 +/- ## = - Coverage 47.95% 47.75% -0.21% + Complexity 5004 4973 -31 = Files633 633 Lines 4252042525 +5 Branches5571 5573 +2 = - Hits 2039120306 -85 - Misses 1963319715 +82 - Partials2496 2504 +8 ``` | [Impacted Files](https://codecov.io/gh/apache/rocketmq/pull/3989?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...g/apache/rocketmq/client/impl/MQClientAPIImpl.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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==) | `13.86% <0.00%> (ø)` | | | [...lient/impl/consumer/DefaultMQPullConsumerImpl.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvaW1wbC9jb25zdW1lci9EZWZhdWx0TVFQdWxsQ29uc3VtZXJJbXBsLmphdmE=) | `29.76% <0.00%> (ø)` | | | [.../apache/rocketmq/common/protocol/ResponseCode.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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-Y29tbW9uL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jb21tb24vcHJvdG9jb2wvUmVzcG9uc2VDb2RlLmphdmE=) | `0.00% <ø> (ø)` | | | [...mq/client/impl/producer/DefaultMQProducerImpl.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvaW1wbC9wcm9kdWNlci9EZWZhdWx0TVFQcm9kdWNlckltcGwuamF2YQ==) | `44.96% <33.33%> (-0.25%)` | :arrow_down: | | [...ocketmq/client/producer/LocalTransactionState.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvcHJvZHVjZXIvTG9jYWxUcmFuc2FjdGlvblN0YXRlLmphdmE=) | `100.00% <100.00%> (ø)` | | | [...rg/apache/rocketmq/common/stats/StatsSnapshot.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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-Y29tbW9uL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jb21tb24vc3RhdHMvU3RhdHNTbmFwc2hvdC5qYXZh) | `84.61% <0.00%> (-15.39%)` | :arrow_down: | | [.../org/apache/rocketmq/store/PutMessageSpinLock.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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-c3RvcmUvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3JvY2tldG1xL3N0b3JlL1B1dE1lc3NhZ2VTcGluTG9jay5qYXZh) | `85.71% <0.00%> (-14.29%)` | :arrow_down: | | [.../apache/rocketmq/common/stats/MomentStatsItem.java](https://codecov.io/gh/apache/rocketmq/pull/3989/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-Y29tbW9uL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jb21tb24vc3RhdHMvTW9tZW50U3RhdHNJdGVtLmphdmE=) | `38.09% <0.00%> (-9.53%)` | :ar
[GitHub] [rocketmq-client-go] hnlq715 opened a new issue #790: bug: some data race found in rocketmq-client-go
hnlq715 opened a new issue #790: URL: https://github.com/apache/rocketmq-client-go/issues/790 Running go test with race in ci, and find some data race in rocketmq-client-go ``` == WARNING: DATA RACE Write at 0x00c0002035f8 by goroutine 90: github.com/emirpasic/gods/trees/redblacktree.(*Tree).Remove() /home/runner/go/pkg/mod/github.com/emirpasic/gods@v1.12.0/trees/redblacktree/redblacktree.go:145 +0x256 github.com/emirpasic/gods/maps/treemap.(*Map).Remove() /home/runner/go/pkg/mod/github.com/emirpasic/gods@v1.12.0/maps/treemap/treemap.go:62 +0x294 github.com/apache/rocketmq-client-go/v2/consumer.(*processQueue).removeMessage() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/process_queue.go:198 +0x205 github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).consumeMessageCurrently.func1() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:1040 +0xaf7 github.com/apache/rocketmq-client-go/v2/primitive.WithRecover() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/primitive/base.go:99 +0x5a Previous read at 0x00c0002035f8 by goroutine 103: github.com/emirpasic/gods/trees/redblacktree.(*Tree).Size() /home/runner/go/pkg/mod/github.com/emirpasic/gods@v1.12.0/trees/redblacktree/redblacktree.go:155 +0x424 github.com/emirpasic/gods/maps/treemap.(*Map).Size() /home/runner/go/pkg/mod/github.com/emirpasic/gods@v1.12.0/maps/treemap/treemap.go:72 +0x3f6 github.com/apache/rocketmq-client-go/v2/consumer.(*processQueue).putMessage() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/process_queue.go:121 +0x3cb github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).pullMessage() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:757 +0x3971 github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).Start.func1.1.1() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:165 +0x44 Goroutine 90 (running) created at: github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).consumeMessageCurrently() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:974 +0xe4 github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).consumeMessageCurrently-fm() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:959 +0x5e github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).pullMessage.func1() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:533 +0x118 github.com/apache/rocketmq-client-go/v2/primitive.WithRecover() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/primitive/base.go:99 +0x5a Goroutine 103 (running) created at: github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).Start.func1.1() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:164 +0x70 == == WARNING: DATA RACE Read at 0x00c00028a6c8 by goroutine 103: github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).pullMessage() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:5[84](https://github.com/douyu/jupiter/runs/5579931547?check_suite_focus=true#step:10:84) +0x22d9 github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).Start.func1.1.1() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:165 +0x44 Previous write at 0x00c00028a6c8 by goroutine 90: sync/atomic.AddInt64() /opt/hostedtoolcache/go/1.16.14/x64/src/runtime/race_amd64.s:300 +0xb github.com/apache/rocketmq-client-go/v2/consumer.(*processQueue).removeMessage() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/process_queue.go:200 +0x2cc github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).consumeMessageCurrently.func1() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/consumer/push_consumer.go:1040 +0xaf7 github.com/apache/rocketmq-client-go/v2/primitive.WithRecover() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go/v2@v2.1.1-rc2/primitive/base.go:99 +0x5a Goroutine 103 (running) created at: github.com/apache/rocketmq-client-go/v2/consumer.(*pushConsumer).Start.func1.1() /home/runner/go/pkg/mod/github.com/apache/rocketmq-client-go
[GitHub] [rocketmq] ni-ze commented on issue #3991: same brokerName in diffrent cluster
ni-ze commented on issue #3991: URL: https://github.com/apache/rocketmq/issues/3991#issuecomment-1069828909 If the two clusters are not related, use different namesrv is better. Otherwise, a different broker name is recommended. -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-operator] caigy commented on issue #76: the nameservice in master and slave
caigy commented on issue #76: URL: https://github.com/apache/rocketmq-operator/issues/76#issuecomment-1069825463 1. Could you provide the log of operator at that time? 2. Did this problem occur in your initial deployment, or after scaling? -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] ni-ze commented on pull request #3989: #fix replace UNKNOW with UNKNOWN in LocalTransactionState enum
ni-ze commented on pull request #3989: URL: https://github.com/apache/rocketmq/pull/3989#issuecomment-1069824370 ResponseCode,MQClientAPIImpl,DefaultMQPullConsumerImpl also need to be corrected. -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] Oliverwqcwrw closed issue #3990: Add a private constructor to hide the implicit public one for (AclConstants.class)
Oliverwqcwrw closed issue #3990: URL: https://github.com/apache/rocketmq/issues/3990 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] zhaohai1299002788 opened a new pull request #3995: [ISSUE #3991] fix broker duplicate name
zhaohai1299002788 opened a new pull request #3995: URL: https://github.com/apache/rocketmq/pull/3995 Fix https://github.com/apache/rocketmq/issues/3991 Fix broker duplicate name -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] zhaohai1299002788 closed pull request #3994: [ISSUE #3991] Fix broker duplicate name
zhaohai1299002788 closed pull request #3994: URL: https://github.com/apache/rocketmq/pull/3994 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] zhaohai1299002788 opened a new pull request #3994: [ISSUE ##3991] Fix broker duplicate name
zhaohai1299002788 opened a new pull request #3994: URL: https://github.com/apache/rocketmq/pull/3994 Fix broker duplicate name -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-mqtt] dongbaibai opened a new issue #35: Practice sharing
dongbaibai opened a new issue #35: URL: https://github.com/apache/rocketmq-mqtt/issues/35 We use the same approach for communication between applications and services but not by a gateway we use a mqtt client to send message from rocketmq to mqtt broker by a gateway seem to reduce number of communication between mqtt-client and mqtt-broker -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-operator] caigy commented on issue #93: load subscriptionGroup.json syntax error, expect {
caigy commented on issue #93: URL: https://github.com/apache/rocketmq-operator/issues/93#issuecomment-1069142132 It seems that it may be resolved by #82 , could you have a try? -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
?????? [DISCUSS] RIP-35 queue service framework(QSF)
Thanks Reply:) QSF is a step further than rocketmq-spring. Using QSF, users can get the most intuitive experience that is almost identical to that of local method calls; moreover, QSF reserves a good extension capability, which can easily provide features such as idempotent, eventual consistency and flow control and so on. For a simple usage example of QSF, please see the discussion above :) -- -- ??: "dev" https://github.com/apache/rocketmq-spring yukon https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg > > > > > > > > > > > > > > RIP 35 queue service framework(QSF) > > > > Status > > > > ?? Current State: Proposed > > > > ?? Authors: booom( booom (jason) ?? GitHub) > > > > ?? Shepherds: yukon( zhouxinyu (yukon) ?? GitHub) > > > > ?? Mailing List discussion: dev@rocketmq.apache.org > > > > ?? Pull Request: > > > > ?? Released: > > > > Background & Motivation > > > > What do we need to do > > > > ?? Will we add a new module? Yes. > > > > ?? Will we add new APIs? No. > > > > ?? Will we add new feature? Yes. > > > > Why should we do that > > > > ?? Are there any problems of our current project? > > > > The current mq client API is intrusive, to send message or consume > > message, we should code to manage the mq infrastructure, and mixed it up > > with our business logic codes. > > > > ?? What can we benefit proposed changes? > > > > 1. Encapsulate mq client API to support method invoking style usage. > > > > 2. The encapsulation is easily extensible, to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > 3. Isolate the mq client manage code and the business logic code, to > > help mq users improve their systems?? maintainability. > > > > Goals > > > > ?? What problem is this proposal designed to solve? > > > > Unobtrusive mq client usage, and easily extensible to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > ?? To what degree should we solve the problem? > > > > 100%. > > > > Non-Goals > > > > ?? What problem is this proposal NOT designed to solve? > > > > 1. Add new features to classics mq client. > > > > 2. Affect compatibility. > > > > ?? Are there any limits of this proposal? > > > > Only QSF(queue service framework) users will benefit. > > > > Changes > > > > Architecture > > > > To simplify a process, we need to consider what information is essential > > and must be provided by users to execute this process? How to properly > > organize this information so that it is most user-friendly? > > > > > > Along this thinking path, we have extracted the necessary parameters for > > mq calls and organized them into the java annotations @QSFConsumer and > > @QSFProvider. After that, through the extension support of spring > container > > in each stage of bean life cycle, we can process @QSFConsumer > @QSFProvider > > annotation in BeanPostProcessor, extract method invocation information to > > method invocation information object MethodInvokeInfo and send it out, > and > > locate it through MethodInvokeInfo at the message receiving endpoint. The > > bean where the call is made, the method where it is located, the > parameters > > used, and then the method is called by reflection. > > > > > > > > > > > > Interface Design/Change > > > > ?? Method signature changes > > > > ?? method name > > > > ?? parameter list > > > > ?? return value > > > > Nothing. > > > > ?? Method behavior changes > > > > Nothing. > > > > ?? CLI command changes > > > > Nothing. > > > > ?? Log format or content changes > > > > Nothing. > > > > Compatibility, Deprecation, and Migration Plan > > > > ?? Are backward and forward compatibility taken into > > consideration? > > > > Yes. > > > > ?? Are there deprecated APIs? > > > > Nothing. > > > > ?? How do we do migration? > > > > Upgrade normally, no additional migration required. > > > > Implementation Outline > > > > We will implement the proposed changes by 1 phase. (QSF is implemented > and > > works well in our project) > > > > Phase 1 > > > > > > Complete the QSF mq client encapsulation. > > > > > > > > Complete the QSF idempotency support > > > > > > Rejected Alternatives > > > > There are no other alternatives. > > > > > > > > > > > > > > > > --
?????? [DISCUSS] RIP-35 queue service framework(QSF)
sure:)
Taking a real business system (label system) as an example, when
a label object is changed in the label system, an event
notification needs to be initiated to inform the label search system
of the change information, so that the label search system can update
the search index.
This is a classic weak dependency that requires message decoupling. Using the
classic solution, we need to write code to manage the mq infrastructure,
assemble change objects, and send change messages on the message sender side;
on the message receiver side, we also need to write code to parse the change
objects and process the change messages. If you need features like extactly
once consuming, it's even more cumbersome, and inevitably couples
infrastructure management code and business code.
With QSF, we only need to declare the business interface and implement business
logic, and annotate the interface implementation class with @QSFProvider, and
annotate @QSFConsumer at the interface reference. A mq-based cross-system
asynchronous call can be done like a local method call, like this:
// LabelService.java
public interface LabelService {
void labelModified(LabelInfoDTO labelDTO);
}
// LabelServiceImpl.java
@QSFProvider(topic = "topic_label", consumerId = "cid_topic_label", tags =
"label_modified")
@Slf4j
public class LabelServiceImpl implements LabelService {
@Override
public void labelModified(LabelInfoDTO labelDTO) {
//business logic
}
}
//LabelManager.java
@QSFConsumer(topic = "topic_label", tag = "label_modified")
private LabelService labelService;
public boolean updateLable(LabelInfoDTO labelDTO){
// main process:update label logic
...
...
// edge process:inform label modified
labelService.labelModified(labelDTO);
}
-- --
??:
"dev"
https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg
>
>
>
>
>
>
> RIP 35 queue service framework(QSF)
>
> Status
>
> ?? Current
State: Proposed
>
> ?? Authors:
booom( booom (jason) ?? GitHub)
>
> ?? Shepherds:
yukon( zhouxinyu (yukon) ?? GitHub)
>
> ?? Mailing List
discussion: dev@rocketmq.apache.org
>
> ?? Pull Request:
>
> ??
Released:
>
> Background & Motivation
>
> What do we need to do
>
> ?? Will we add a
new module? Yes.
>
> ?? Will we add
new APIs? No.
>
> ?? Will we add
new feature? Yes.
>
> Why should we do that
>
> ?? Are there any
problems of our current project?
>
> The current mq client API is intrusive, to send message or consume
> message, we should code to manage the mq infrastructure, and mixed it up
> with our business logic codes.
>
> ?? What can we
benefit proposed changes?
>
> 1. Encapsulate mq client API to support
method invoking style usage.
>
> 2. The encapsulation is easily extensible,
to support
> idempotence/eventually consistent/ fluid control extensions and so on.
>
> 3. Isolate the mq client manage code and the
business logic code, to
> help mq users improve their systems?? maintainability.
>
> Goals
>
> ?? What problem
is this proposal designed to solve?
>
> Unobtrusive mq client usage, and easily extensible to support
> idempotence/eventually consistent/ fluid control extensions and so on.
>
> ?? To what
degree should we solve the problem?
>
> 100%.
>
> Non-Goals
>
> ?? What problem
is this proposal NOT designed to solve?
>
> 1. Add new features to classics mq client.
>
> 2. Affect compatibility.
>
> ?? Are there any
limits of this proposal?
>
> Only QSF(queue service framework) users will benefit.
>
> Changes
>
> Architecture
>
> To simplify a process, we need to consider what information is essential
> and must be provided by users to execute this process? How to properly
> organize this information so that it is most user-friendly?
>
>
> Along this thinking path, we have extracted the necessary parameters for
> mq calls and organized them into the java annotations @QSFConsumer and
> @QSFProvider. After that, through the extension support of spring container
> in each stage of bean life cycle, we can process @QSFConsumer @QSFProvider
> annotation in BeanPostProcessor, extract method invocation information to
> method invocation information object MethodInvokeInfo and send it out, and
> locate it through MethodInvokeInfo at the message receiving endpoint. The
> bean where the call is made, the method where it is located, the parameters
> used, and then the method is called by reflection.
>
>
>
>
>
> Interface Design/Change
>
> ?? Method
signature ch
Re: [DISCUSS] RIP-35 queue service framework(QSF)
Nice to see this proposal of yours, but it seems a bit like what rocketmq-spring[1] does, so can you elaborate on the difference between QSF and rocketmq-spring? [1]https://github.com/apache/rocketmq-spring yukon 于2022年3月16日周三 20:23写道： > Could you please provide some demos to show how we use > QSFProducer/Consumer? > > On Wed, Mar 16, 2022 at 6:49 PM Jason.Chen wrote: > > > I am sorry that the RIP mail format is incorrect, and i write a > > well-formed google doc version here: > > > > > > > https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg > > > > > > > > > > > > > > RIP 35 queue service framework(QSF) > > > > Status > > > > ● Current State: Proposed > > > > ● Authors: booom( booom (jason) · GitHub) > > > > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub) > > > > ● Mailing List discussion: dev@rocketmq.apache.org > > > > ● Pull Request: > > > > ● Released: > > > > Background & Motivation > > > > What do we need to do > > > > ● Will we add a new module? Yes. > > > > ● Will we add new APIs? No. > > > > ● Will we add new feature? Yes. > > > > Why should we do that > > > > ● Are there any problems of our current project? > > > > The current mq client API is intrusive, to send message or consume > > message, we should code to manage the mq infrastructure, and mixed it up > > with our business logic codes. > > > > ● What can we benefit proposed changes? > > > > 1. Encapsulate mq client API to support method invoking style usage. > > > > 2. The encapsulation is easily extensible, to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > 3. Isolate the mq client manage code and the business logic code, to > > help mq users improve their systems’ maintainability. > > > > Goals > > > > ● What problem is this proposal designed to solve? > > > > Unobtrusive mq client usage, and easily extensible to support > > idempotence/eventually consistent/ fluid control extensions and so on. > > > > ● To what degree should we solve the problem? > > > > 100%. > > > > Non-Goals > > > > ● What problem is this proposal NOT designed to solve? > > > > 1. Add new features to classics mq client. > > > > 2. Affect compatibility. > > > > ● Are there any limits of this proposal? > > > > Only QSF(queue service framework) users will benefit. > > > > Changes > > > > Architecture > > > > To simplify a process, we need to consider what information is essential > > and must be provided by users to execute this process? How to properly > > organize this information so that it is most user-friendly? > > > > > > Along this thinking path, we have extracted the necessary parameters for > > mq calls and organized them into the java annotations @QSFConsumer and > > @QSFProvider. After that, through the extension support of spring > container > > in each stage of bean life cycle, we can process @QSFConsumer > @QSFProvider > > annotation in BeanPostProcessor, extract method invocation information to > > method invocation information object MethodInvokeInfo and send it out, > and > > locate it through MethodInvokeInfo at the message receiving endpoint. The > > bean where the call is made, the method where it is located, the > parameters > > used, and then the method is called by reflection. > > > > > > > > > > > > Interface Design/Change > > > > ● Method signature changes > > > > ○ method name > > > > ○ parameter list > > > > ○ return value > > > > Nothing. > > > > ● Method behavior changes > > > > Nothing. > > > > ● CLI command changes > > > > Nothing. > > > > ● Log format or content changes > > > > Nothing. > > > > Compatibility, Deprecation, and Migration Plan > > > > ● Are backward and forward compatibility taken into > > consideration? > > > > Yes. > > > > ● Are there deprecated APIs? > > > > Nothing. > > > > ● How do we do migration? > > > > Upgrade normally, no additional migration required. > > > > Implementation Outline > > > > We will implement the proposed changes by 1 phase. (QSF is implemented > and > > works well in our project) > > > > Phase 1 > > > > > > Complete the QSF mq client encapsulation. > > > > > > > > Complete the QSF idempotency support > > > > > > Rejected Alternatives > > > > There are no other alternatives. > > > > > > > > > > > > > > > > -- 原始邮件 -- > > 发件人: > > "Jason.Chen" > > < > > chenhua...@foxmail.com>; > > 发送时间: 2022年3月16日(星期三) 中午12:55 > > 收件人: "dev" > > > 主题: [DISCUSS] RIP-35 queue service framework(QSF) > > > > > > > > > > > > > > > > Status > > > > ● Current State: Proposed > > > > ● Authors: booom( booom (jason) · GitHub) > > >
Re: [DISCUSS] RIP-35 queue service framework(QSF)
Could you please provide some demos to show how we use QSFProducer/Consumer? On Wed, Mar 16, 2022 at 6:49 PM Jason.Chen wrote: > I am sorry that the RIP mail format is incorrect, and i write a > well-formed google doc version here: > > > https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg > > > > > > > RIP 35 queue service framework(QSF) > > Status > > ● Current State: Proposed > > ● Authors: booom( booom (jason) · GitHub) > > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub) > > ● Mailing List discussion: dev@rocketmq.apache.org > > ● Pull Request: > > ● Released: > > Background & Motivation > > What do we need to do > > ● Will we add a new module? Yes. > > ● Will we add new APIs? No. > > ● Will we add new feature? Yes. > > Why should we do that > > ● Are there any problems of our current project? > > The current mq client API is intrusive, to send message or consume > message, we should code to manage the mq infrastructure, and mixed it up > with our business logic codes. > > ● What can we benefit proposed changes? > > 1. Encapsulate mq client API to support method invoking style usage. > > 2. The encapsulation is easily extensible, to support > idempotence/eventually consistent/ fluid control extensions and so on. > > 3. Isolate the mq client manage code and the business logic code, to > help mq users improve their systems’ maintainability. > > Goals > > ● What problem is this proposal designed to solve? > > Unobtrusive mq client usage, and easily extensible to support > idempotence/eventually consistent/ fluid control extensions and so on. > > ● To what degree should we solve the problem? > > 100%. > > Non-Goals > > ● What problem is this proposal NOT designed to solve? > > 1. Add new features to classics mq client. > > 2. Affect compatibility. > > ● Are there any limits of this proposal? > > Only QSF(queue service framework) users will benefit. > > Changes > > Architecture > > To simplify a process, we need to consider what information is essential > and must be provided by users to execute this process? How to properly > organize this information so that it is most user-friendly? > > > Along this thinking path, we have extracted the necessary parameters for > mq calls and organized them into the java annotations @QSFConsumer and > @QSFProvider. After that, through the extension support of spring container > in each stage of bean life cycle, we can process @QSFConsumer @QSFProvider > annotation in BeanPostProcessor, extract method invocation information to > method invocation information object MethodInvokeInfo and send it out, and > locate it through MethodInvokeInfo at the message receiving endpoint. The > bean where the call is made, the method where it is located, the parameters > used, and then the method is called by reflection. > > > > > > Interface Design/Change > > ● Method signature changes > > ○ method name > > ○ parameter list > > ○ return value > > Nothing. > > ● Method behavior changes > > Nothing. > > ● CLI command changes > > Nothing. > > ● Log format or content changes > > Nothing. > > Compatibility, Deprecation, and Migration Plan > > ● Are backward and forward compatibility taken into > consideration? > > Yes. > > ● Are there deprecated APIs? > > Nothing. > > ● How do we do migration? > > Upgrade normally, no additional migration required. > > Implementation Outline > > We will implement the proposed changes by 1 phase. (QSF is implemented and > works well in our project) > > Phase 1 > > > Complete the QSF mq client encapsulation. > > > > Complete the QSF idempotency support > > > Rejected Alternatives > > There are no other alternatives. > > > > > > > > -- 原始邮件 -- > 发件人: > "Jason.Chen" > < > chenhua...@foxmail.com>; > 发送时间: 2022年3月16日(星期三) 中午12:55 > 收件人: "dev" > 主题: [DISCUSS] RIP-35 queue service framework(QSF) > > > > > > > > Status > > ● Current State: Proposed > > ● Authors: booom( booom (jason) · GitHub) > > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub) > > ● Mailing List discussion: > dev@rocketmq.apache.org > > ● Pull Request: > > ● Released: > Background & Motivation > > What do we need to do > > ● Will we add a new module? Yes. > > ● Will we add new APIs? No. > > ● Will we add new feature? Yes. > > Why should we do that > > ● Are there any problems of our current project? > > The current mq client API is intrusive, to send message or consume > message, we should code to manage the mq infrastructure, and mixed it up > with our business logic codes. > > ● What can we benefit propos
[ANNOUNCE] Release Apache RocketMQ 5.0.0-ALPHA RC2
Hello RocketMQ Community, The Apache RocketMQ team would like to announce the release of Apache RocketMQ 5.0.0-alpha. More details regarding Apache RocketMQ can be found at: https://rocketmq.apache.org/dowloading/releases/ The release artifacts can be downloaded here: https://dist.apache.org/repos/dist/dev/rocketmq/5.0.0-ALPHA-rc2/rocketmq-all-5.0.0-ALPHA-source-release.zip https://dist.apache.org/repos/dist/dev/rocketmq/5.0.0-ALPHA-rc2/rocketmq-all-5.0.0-ALPHA-bin-release.zip The release notes can be found here: https://rocketmq.apache.org/release_notes/release-notes-5.0.0-ALPHA/ The artifacts have been signed with Key : EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the keys file: https://dist.apache.org/repos/dist/dev/rocketmq/KEYS Thanks, The Apache RocketMQ Team
[GitHub] [rocketmq-client-go] shencw edited a comment on issue #485: Error: send message with sync failed
shencw edited a comment on issue #485: URL: https://github.com/apache/rocketmq-client-go/issues/485#issuecomment-1069047401 > 直接换成公网地址试一试就好了，阿里云不能通过账号登陆直接去连接内网的tcp，除非都是一个内网的服务器 我现在也遇到了这个问题，但是我的配置设置的也是公网，却还是提示失败。。 WARN[0049] send message error, error is: send message with sync failed -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-client-go] shencw commented on issue #485: Error: send message with sync failed
shencw commented on issue #485: URL: https://github.com/apache/rocketmq-client-go/issues/485#issuecomment-1069047401 > 直接换成公网地址试一试就好了，阿里云不能通过账号登陆直接去连接内网的tcp，除非都是一个内网的服务器 我现在也遇到了这个问题，但是我的配置设置的也是内网，却还是提示失败。。 WARN[0049] send message error, error is: send message with sync failed -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-client-cpp] shencw commented on issue #409: Inconsistent directory structure Help!!
shencw commented on issue #409: URL: https://github.com/apache/rocketmq-client-cpp/issues/409#issuecomment-1069018098 i use https://github.com/apache/rocketmq-client-go/tree/v1.2.4 version A lot of files can't be found 😭 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
??????[DISCUSS] RIP-35 queue service framework(QSF)
I am sorry that the RIP mail format is incorrect, and i write a well-formed google doc version here: https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg RIP 35 queue service framework(QSF) Status ?? Current State: Proposed ?? Authors: booom( booom (jason) ?? GitHub) ?? Shepherds: yukon( zhouxinyu (yukon) ?? GitHub) ?? Mailing List discussion: dev@rocketmq.apache.org ?? Pull Request: ?? Released: Background & Motivation What do we need to do ?? Will we add a new module? Yes. ?? Will we add new APIs? No. ?? Will we add new feature? Yes. Why should we do that ?? Are there any problems of our current project? The current mq client API is intrusive, to send message or consume message, we should code to manage the mq infrastructure, and mixed it up with our business logic codes. ?? What can we benefit proposed changes? 1. Encapsulate mq client API to support method invoking style usage. 2. The encapsulation is easily extensible, to support idempotence/eventually consistent/ fluid control extensions and so on. 3. Isolate the mq client manage code and the business logic code, to help mq users improve their systems?? maintainability. Goals ?? What problem is this proposal designed to solve? Unobtrusive mq client usage, and easily extensible to support idempotence/eventually consistent/ fluid control extensions and so on. ?? To what degree should we solve the problem? 100%. Non-Goals ?? What problem is this proposal NOT designed to solve? 1. Add new features to classics mq client. 2. Affect compatibility. ?? Are there any limits of this proposal? Only QSF(queue service framework) users will benefit. Changes Architecture To simplify a process, we need to consider what information is essential and must be provided by users to execute this process? How to properly organize this information so that it is most user-friendly? Along this thinking path, we have extracted the necessary parameters for mq calls and organized them into the java annotations @QSFConsumer and @QSFProvider. After that, through the extension support of spring container in each stage of bean life cycle, we can process @QSFConsumer @QSFProvider annotation in BeanPostProcessor, extract method invocation information to method invocation information object MethodInvokeInfo and send it out, and locate it through MethodInvokeInfo at the message receiving endpoint. The bean where the call is made, the method where it is located, the parameters used, and then the method is called by reflection. Interface Design/Change ?? Method signature changes ?? method name ?? parameter list ?? return value Nothing. ?? Method behavior changes Nothing. ?? CLI command changes Nothing. ?? Log format or content changes Nothing. Compatibility, Deprecation, and Migration Plan ?? Are backward and forward compatibility taken into consideration? Yes. ?? Are there deprecated APIs? Nothing. ?? How do we do migration? Upgrade normally, no additional migration required. Implementation Outline We will implement the proposed changes by 1 phase. (QSF is implemented and works well in our project) Phase 1 Complete the QSF mq client encapsulation. Complete the QSF idempotency support Rejected Alternatives There are no other alternatives. -- -- ??: "Jason.Chen"
[GitHub] [rocketmq] codecov-commenter edited a comment on pull request #3965: [ISSUE #3968]RemotingCommand `decodeCommandCustomHeader` optimized.
codecov-commenter edited a comment on pull request #3965: URL: https://github.com/apache/rocketmq/pull/3965#issuecomment-1065877726 # [Codecov](https://codecov.io/gh/apache/rocketmq/pull/3965?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 [#3965](https://codecov.io/gh/apache/rocketmq/pull/3965?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (b91a52e) into [develop](https://codecov.io/gh/apache/rocketmq/commit/40d950578643775000ba29a33afdc3d8746cb8b6?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (40d9505) will **increase** coverage by `0.20%`. > The diff coverage is `70.58%`. ```diff @@ Coverage Diff @@ ## develop#3965 +/- ## = + Coverage 47.68% 47.88% +0.20% - Complexity 4972 5000 +28 = Files633 633 Lines 4257942510 -69 Branches5589 5574 -15 = + Hits 2030520358 +53 + Misses 1976419651 -113 + Partials2510 2501 -9 ``` | [Impacted Files](https://codecov.io/gh/apache/rocketmq/pull/3965?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...he/rocketmq/remoting/protocol/RemotingCommand.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-cmVtb3Rpbmcvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3JvY2tldG1xL3JlbW90aW5nL3Byb3RvY29sL1JlbW90aW5nQ29tbWFuZC5qYXZh) | `77.25% <70.58%> (-1.38%)` | :arrow_down: | | [...ava/org/apache/rocketmq/filter/util/BitsArray.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-ZmlsdGVyL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9maWx0ZXIvdXRpbC9CaXRzQXJyYXkuamF2YQ==) | `59.82% <0.00%> (-2.57%)` | :arrow_down: | | [...a/org/apache/rocketmq/filter/util/BloomFilter.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-ZmlsdGVyL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9maWx0ZXIvdXRpbC9CbG9vbUZpbHRlci5qYXZh) | `59.13% <0.00%> (-2.16%)` | :arrow_down: | | [...mq/client/impl/consumer/RebalanceLitePullImpl.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvaW1wbC9jb25zdW1lci9SZWJhbGFuY2VMaXRlUHVsbEltcGwuamF2YQ==) | `72.05% <0.00%> (-1.48%)` | :arrow_down: | | [...e/rocketmq/client/impl/consumer/RebalanceImpl.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvaW1wbC9jb25zdW1lci9SZWJhbGFuY2VJbXBsLmphdmE=) | `43.75% <0.00%> (-0.79%)` | :arrow_down: | | [...etmq/client/latency/LatencyFaultToleranceImpl.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvbGF0ZW5jeS9MYXRlbmN5RmF1bHRUb2xlcmFuY2VJbXBsLmphdmE=) | `49.35% <0.00%> (-0.65%)` | :arrow_down: | | [...ent/impl/consumer/DefaultLitePullConsumerImpl.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-Y2xpZW50L3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS9yb2NrZXRtcS9jbGllbnQvaW1wbC9jb25zdW1lci9EZWZhdWx0TGl0ZVB1bGxDb25zdW1lckltcGwuamF2YQ==) | `68.79% <0.00%> (-0.52%)` | :arrow_down: | | [...che/rocketmq/acl/plain/PlainPermissionManager.java](https://codecov.io/gh/apache/rocketmq/pull/3965/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-YWNsL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZ
[GitHub] [rocketmq] coveralls edited a comment on pull request #3965: [ISSUE #3968]RemotingCommand `decodeCommandCustomHeader` optimized.
coveralls edited a comment on pull request #3965: URL: https://github.com/apache/rocketmq/pull/3965#issuecomment-1065878738 [](https://coveralls.io/builds/47412872) Coverage increased (+0.2%) to 51.934% when pulling **b91a52ebb8061310a3f8e67aa80e3e7d5908ccc5 on WJL:optimize_remoting_command_decode** into **40d950578643775000ba29a33afdc3d8746cb8b6 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-mqtt] ShannonDing merged pull request #34: [ISSUE #33] some thread safety problems
ShannonDing merged pull request #34: URL: https://github.com/apache/rocketmq-mqtt/pull/34 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-mqtt] ShannonDing closed issue #33: Fix some thread safety problems
ShannonDing closed issue #33: URL: https://github.com/apache/rocketmq-mqtt/issues/33 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-mqtt] ShannonDing merged pull request #30: [ISSUE #29] Remove redundant code in NotifyManager.java
ShannonDing merged pull request #30: URL: https://github.com/apache/rocketmq-mqtt/pull/30 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq-mqtt] ShannonDing closed issue #29: remove redundant ’defaultMQProducer.start();‘ in NotifyManager.java
ShannonDing closed issue #29: URL: https://github.com/apache/rocketmq-mqtt/issues/29 -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] panzhi33 edited a comment on issue #3991: same brokerName in diffrent cluster
panzhi33 edited a comment on issue #3991: URL: https://github.com/apache/rocketmq/issues/3991#issuecomment-1068873150 would you like to submit a PR to fix it ? -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [rocketmq] panzhi33 commented on issue #3991: same brokerName in diffrent cluster
panzhi33 commented on issue #3991: URL: https://github.com/apache/rocketmq/issues/3991#issuecomment-1068873150 would you like to submit a PR to polish it ? -- 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. To unsubscribe, e-mail: dev-unsubscr...@rocketmq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
