[jira] [Created] (ROCKETMQ-206) Load JSON config file error if non-1byte character exists
yukon created ROCKETMQ-206:
--
Summary: Load JSON config file error if non-1byte character exists
Key: ROCKETMQ-206
URL: https://issues.apache.org/jira/browse/ROCKETMQ-206
Project: Apache RocketMQ
Issue Type: Bug
Components: rocketmq-commons
Affects Versions: 4.0.0-incubating
Reporter: yukon
Assignee: yukon
Fix For: 4.1.0-incubating
If there are some non-1byte character in consumeroffset.json or other config
files, when Broker restarted, the file contents will be ignored.
See this method, when file.length() != character number, bug triggered.
{code}
public static String file2String(final File file) {
if (file.exists()) {
char[] data = new char[(int) file.length()];
boolean result = false;
FileReader fileReader = null;
try {
fileReader = new FileReader(file);
int len = fileReader.read(data);
result = len == data.length;
} catch (IOException e) {
// e.printStackTrace();
} finally {
if (fileReader != null) {
try {
fileReader.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
if (result) {
return new String(data);
}
}
return null;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (ROCKETMQ-205) change the port of broker and restart it, but client still connect to previous port also
Eason Chen created ROCKETMQ-205: --- Summary: change the port of broker and restart it, but client still connect to previous port also Key: ROCKETMQ-205 URL: https://issues.apache.org/jira/browse/ROCKETMQ-205 Project: Apache RocketMQ Issue Type: Bug Reporter: Eason Chen Assignee: vongosling we start a broker and listen on 10911, client listen on it correctly then we change the port to 10915 and restart it client connect to 10915 correctly but still try to connect to 10911 and failed seems client did not update the broker address correctly -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ROCKETMQ-203) Support client to allocate message q in machine room nearby priority
Jaskey Lam created ROCKETMQ-203:
---
Summary: Support client to allocate message q in machine room
nearby priority
Key: ROCKETMQ-203
URL: https://issues.apache.org/jira/browse/ROCKETMQ-203
Project: Apache RocketMQ
Issue Type: New Feature
Reporter: Jaskey Lam
Assignee: vongosling
Attachments: AVLCB%1XMJ}T_YXP[OPF){T.png
As the picture shows, in multi-machine room acrtiture , the consumer may be
deployed in different IDC and so do the broker.
But the user may possiblly need to consumer message from its own IDC since it
is near and faster. But when problem occurs say all consumers in one IDC is
crashed, the messages can also be consumed by other consumers in other IDC.
This is a very important feature for many users, but currently, if the user
needs this feature, they must implement their own allocate strategy which is
not easy and error prone.
And, this feature should be be conflict to the existing allocate strategy that
means the user can still choose their better allocate strategy say AVERAGE or
AVERAGE_BY_CIRCLE, but nearby machine room will be supported easily too.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (ROCKETMQ-120) Provide a adapter for spring and spring-boot
[ https://issues.apache.org/jira/browse/ROCKETMQ-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reassigned ROCKETMQ-120: - Assignee: dongeforever Fix Version/s: 4.1.0-incubating > Provide a adapter for spring and spring-boot > > > Key: ROCKETMQ-120 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-120 > Project: Apache RocketMQ > Issue Type: Wish >Reporter: yukon >Assignee: dongeforever >Priority: Minor > Fix For: 4.1.0-incubating > > > Provider a rocketmq-spring adapter for the convenience of the spring user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-81) Add the RocketMq plugin for the Apache Spark
[ https://issues.apache.org/jira/browse/ROCKETMQ-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-81: - Fix Version/s: 4.2.0-incubating > Add the RocketMq plugin for the Apache Spark > > > Key: ROCKETMQ-81 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-81 > Project: Apache RocketMQ > Issue Type: Task > Components: rocketmq-externals >Affects Versions: 4.1.0-incubating >Reporter: Longda Feng >Assignee: Xin Wang >Priority: Minor > Fix For: 4.2.0-incubating > > > Since the Apache RocketMq 4.0 will be released in the next few days, we can > start the job of adding the RocketMq plugin for the Apache Spark. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-202) Using native transport
[ https://issues.apache.org/jira/browse/ROCKETMQ-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-202: -- Fix Version/s: 4.1.0-incubating > Using native transport > -- > > Key: ROCKETMQ-202 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-202 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-remoting >Reporter: Zhanhui Li >Assignee: Zhanhui Li >Priority: Minor > Fix For: 4.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-193) Develop rocketmq-redis-replicator component
[ https://issues.apache.org/jira/browse/ROCKETMQ-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-193: -- Fix Version/s: 4.2.0-incubating > Develop rocketmq-redis-replicator component > --- > > Key: ROCKETMQ-193 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-193 > Project: Apache RocketMQ > Issue Type: Task >Reporter: Rich Zhang >Assignee: Rich Zhang >Priority: Minor > Fix For: 4.2.0-incubating > > > Design: > Redis supplies an official replication mechanism , and slave communicates > to master with RESP protocol, so a natural way to design the > rocketmq-redis-replicator component is simulating itself as a slave, sending > commands to master and receiving datas from master timely, and then resending > to rocketmq broker. > If you are not familiar with redis replication mechanism, please learn this > section first [1]. After that, I will illustrate some key points ahead. > 1. To make slave start from the point where it left off when it reconnects, > slave and master should agree on a master runId and a replication offset. > Slave acknowledges this offset to master periodically. In other words，slave > may received duplicate commands. Along with, the rocketmq-redis-replicator > component may send duplicate messages too. A good way to minimize the > duplicate time window is reducing the "ack period" to a smaller one, such as > 100ms. > 2. If slave keeps offline for some time, it’s easy to use up backlog whose > default value is just 1M, especially for a high-traffic redis instance. > Unfortunatelly,if slave replication offset has already been covered in master > backlog, a full synchronization will have to execute, which is unacceptable > for rocketmq-redis-replicator component as a large number of messages will be > sent out intensively. > 3. When synchronizing from master fully, master will generate a new rdb > file(the rdb file format [2])，and slave will receive this file,store in disk, > and last apply to memory. This strategy makes slave reaches a consistent > state with master as soon as possible, and hardly fail. For > rocketmq-redis-replicator component, it’s also a good way to prevent > synchronizing initial rdb file from failure in halfway. > There already an open source project [3] which focuses on replicating redis > data, and provides api to handle data received [4]. The principal thoughts > are simulating itself as a slave , following official replication procedure, > communicating with master by RESP, and acking master with replication offset. > Base on this project to develop is a good idea, meanwhile some aspects should > also be enhanced and considered more robust. Here is some points: > [High Available] >Keeping the replication component's high availability is not difficult but > important, not only for providing an uninterruptible service. If component > leaves off for some time, a unacceptable full synchronization may be > triggered. >It’s also easy to reach high availability, including adopting master/slave > module, using zookeeper to coordinate and switch master/slave, storing data > onto zookeeper to keep component stateless. > [Data Loss] >Generally, data loss should be tried best to avoid. The key point is that > slave only acks replication offset to master after sending command to > rocketmq broker successfully. > [Data Stale] >It also happened when slave reconnect. Consider case below: >`time1` `time2` `time3` >set k=a set k=b set k=c >If slave left off at time3, but the latest replication offset reported to > master is only at time1, when slave reconnected, it re-apply commands “set > k=b… set k=c”. In a small time window, “k” will equal the stale “b” until > “set k=c” command is applied. So the slave offline time shorter, the better. >[Message Order] >Redis uses single thread model to keep command execute in order, because > of its high performance. Replicating data with a single thread in slave is > also fine, as it is also totally memory operation. But sending all data to > rocketmq in a global order is a good choose? Producer should have no > performance issue, but consumer may not be able to consume messages in time, > especially redis was in a high load. >Hashing “KEY” to different rocketmq queue is a good strategy. Guarantee > the same key operation route to a unique queue, to keep partial ordered, and > the downstream consumer could consume messages concurrently. Of course, some > dependency “KEY”s may need hash to a unique queue too. We should supply > configuration or api to support this individuation. >[Transaction] > Redis supports simple transaction. A transaction starts with a
[jira] [Updated] (ROCKETMQ-126) Provide a docker image for RocketMQ
[ https://issues.apache.org/jira/browse/ROCKETMQ-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-126: -- Fix Version/s: 4.1.0-incubating > Provide a docker image for RocketMQ > --- > > Key: ROCKETMQ-126 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-126 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-externals >Reporter: yukon >Assignee: Rich Zhang >Priority: Minor > Fix For: 4.1.0-incubating > > > Provide a docker image for easy deployment and management, optimize for the > latest version. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-122) Support global order messaging mechanism without hot-points problem
[ https://issues.apache.org/jira/browse/ROCKETMQ-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-122: -- Fix Version/s: 4.2.0-incubating > Support global order messaging mechanism without hot-points problem > --- > > Key: ROCKETMQ-122 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-122 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker, rocketmq-client, rocketmq-store >Reporter: yukon >Priority: Minor > Fix For: 4.2.0-incubating > > > As we know, messages in the same queue can be consumed sequentially. So we > always send the congeneric messages to the same queue to guarantee ordering, > which will cause hot-point issue. > So It's cool if we support a new global order messaging mechanism, without > hot-points problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-188) RemotingExecption is not consistent between invoke async and invoke oneway
[ https://issues.apache.org/jira/browse/ROCKETMQ-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-188: -- Fix Version/s: 4.2.0-incubating > RemotingExecption is not consistent between invoke async and invoke oneway > -- > > Key: ROCKETMQ-188 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-188 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-remoting >Reporter: Jaskey Lam >Assignee: Jaskey Lam >Priority: Minor > Fix For: 4.2.0-incubating > > > For existing invoke oneway code base, RemotingTooMuchRequestException will be > thrown only when timeout millis <0, otherwise, RemotingTimeoutException will > be thrown. > But in invokeAsync, RemotingTooMuchRequestException is always thrown no > matter what value the timeout millis , which is inconsistent. Besides, the > RemotingTimeoutException is declared in the signature but it will be never > thrown. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-66) Manage the %DLQ% Queue
[ https://issues.apache.org/jira/browse/ROCKETMQ-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-66: - Fix Version/s: 4.2.0-incubating > Manage the %DLQ% Queue > -- > > Key: ROCKETMQ-66 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-66 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker >Reporter: Jie.Tang >Assignee: yukon >Priority: Minor > Fix For: 4.2.0-incubating > > > I have a problem whether we need to change the %DLQ% Queue perm or not(from 2 > to 6.) > In 3.5.8 the %DLQ% Queue perm is 2,only writable,but I want to read it > because I want to know how many message is in the %DLQ% queue, which message > has problem and why it can't be consume . > I want to query the problem message(%DLQ% Queue Message) in > rocketMq-console,but because of the perm,I can't. > I need to change the perm from 2 to 6 before I query it. > Could you help me to solvle this? Thank you. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-79) Add one RocketMQ plugin for the Apache Storm
[ https://issues.apache.org/jira/browse/ROCKETMQ-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-79: - Fix Version/s: 4.2.0-incubating > Add one RocketMQ plugin for the Apache Storm > > > Key: ROCKETMQ-79 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-79 > Project: Apache RocketMQ > Issue Type: Task > Components: rocketmq-externals >Affects Versions: 4.1.0-incubating >Reporter: Longda Feng >Assignee: Xin Wang >Priority: Minor > Fix For: 4.2.0-incubating > > > Since the Apache RocketMq 4.0 will be released in the next few days, we can > start the job that adding the RocketMq plugin for the Apache Storm. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-82) Add the RocketMQ plugin for the Apache Flink
[ https://issues.apache.org/jira/browse/ROCKETMQ-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-82: - Fix Version/s: 4.2.0-incubating > Add the RocketMQ plugin for the Apache Flink > > > Key: ROCKETMQ-82 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-82 > Project: Apache RocketMQ > Issue Type: Task > Components: rocketmq-externals >Reporter: Longda Feng >Assignee: Xin Wang >Priority: Minor > Fix For: 4.2.0-incubating > > > Since the Apache RocketMq 4.0 will be released in the next few days, we can > start the job of adding the RocketMq plugin for the Apache Flink. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-105) Implementation of consumerOffset and maxOffset are counter-intuitive
[ https://issues.apache.org/jira/browse/ROCKETMQ-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-105: -- Fix Version/s: 4.1.0-incubating > Implementation of consumerOffset and maxOffset are counter-intuitive > > > Key: ROCKETMQ-105 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-105 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker, rocketmq-client, rocketmq-store >Affects Versions: 4.0.0-incubating >Reporter: Jaskey Lam >Assignee: yukon >Priority: Minor > Fix For: 4.1.0-incubating > > > This issue does not affect any functionalites, but it indeed is a problem for > user to understand the principle of RocketMQ. > - ConsumerOffset: > User might consider `ConsumerOffset` is the offset where consumer has > consumed. for example if CG1 have a consumer offset 100 of topicA-q1, I may > propabaly consider message with offset 100 has been cosumed. But actully, it > is not. The message with offset 100 is the next target offset to pull from. > - Max Offset > User might consider this is the offset of the latest message in a queue. But > it is not, it is indicating that next offset when new message arrived. > > If possible , any of the below two things should be taken into consideration > 1. the implementation should be changed to be closer to presentative judgment > of human > 2. rename the concept to clarify how it really implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-187) Measure the code coverage for Integration Tests
[ https://issues.apache.org/jira/browse/ROCKETMQ-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-187: -- Fix Version/s: 4.1.0-incubating > Measure the code coverage for Integration Tests > --- > > Key: ROCKETMQ-187 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-187 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.1.0-incubating > > > Now we could browse the Unit Tests and IT Tests at > https://builds.apache.org/analysis/component_measures/?id=org.apache.rocketmq%3Arocketmq-all > But the IT Test coverage is not correct. It should cover the original sources > instead of the the classes in test module. > As for as I known, the coverage report is generated by matching the > collected data(often using java agent) against a set of classes (the module > classes compiled from src/main/). you could refer to: > http://olafsblog.sysbsb.de/measuring-test-coverage-of-integration-tests-for-separated-modules-with-jacoco/ > So we could match the jacoco-it.exec to each module's source classes to get > the correct IT coverage report. > By the way, we'd better exclude the classes in the test module. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-17) Develop a client api open standard for distributed messaging service
[
https://issues.apache.org/jira/browse/ROCKETMQ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-17:
-
Fix Version/s: 4.1.0-incubating
> Develop a client api open standard for distributed messaging service
>
>
> Key: ROCKETMQ-17
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-17
> Project: Apache RocketMQ
> Issue Type: New Feature
>Affects Versions: 4.1.0-incubating
>Reporter: Xiaorui Wang
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> *Openmessaging*
> Openmessaging is a redefinition of the application of the access message
> service programming API standard. It is only API, non wire-level protocol.
> Openmessaging covers large data message processing, stream computing message
> processing, the traditional transaction model of message processing.
> Openmessaging provides API for all major programming languages, such as Java,
> dotnet, CPP, go, python, nodejs, PHP, etc..
> *openrelay*
> openrelay is a messaging service call through to simulate a API programming
> standard, because it's service provider is more like a message consumer, so
> there is no need to listen port, communication with the broker via the
> reverse proxy mode, therefore it can make two pass through the network not to
> penetrate the news network, and the use of and like the most simple service
> call.
> Openrelay only defines the programming API standard, which is also cross
> language, including Java, dotnet, CPP, go, python, nodejs, PHP, etc., which
> does not contain wire level protocols.
> *Why should provide the set of openmessaging programming API
> standard?*
> We hope to have more users to use rocketmq, these users including CPP,
> dotnet, Java and other programmers, we know that the programmer in the
> selection of a basic middleware, especially concerns one day in the future if
> there is a better product or the selected product is not good enough, how can
> not change the cable has a large number of applications on the code next,
> moving to new products. With openmessaging, at least to provide users with a
> way to regret, so there may be more users choose to use openmessaging to
> access rocketmq. Because openmessaging is a product of independent
> programming of API, we believe that the open source community there will be
> more people involved, through to other products, such as ActiveMQ, Kafka,
> RabbitMQ with openmessaging implementation, even through openmessaging and
> HBase, Hadoop, storm, integration, as long as the realization of time, may be
> able to run at all news product.
> {color:red}
> This is our original intention to design openmessaging and openrelay.
> {color}
> *RocketMQ will be the first to support openmessaging and openrelay standards*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-116) Add Operation Guide
[ https://issues.apache.org/jira/browse/ROCKETMQ-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-116: -- Fix Version/s: 4.1.0-incubating > Add Operation Guide > --- > > Key: ROCKETMQ-116 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-116 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: Zhanhui Li >Assignee: Zhanhui Li > Fix For: 4.1.0-incubating > > > When deploying Apache RocketMQ into production environment, there are a bunch > of parameters to set and options to choose from. We need documentation to > analyze each choice and parameter and benchmark data to support the analysis > in order to achieve various goals. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-130) Support depth control by topic level
[ https://issues.apache.org/jira/browse/ROCKETMQ-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-130: -- Fix Version/s: 4.2.0-incubating > Support depth control by topic level > > > Key: ROCKETMQ-130 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-130 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-broker >Reporter: Eason Chen >Assignee: vongosling > Fix For: 4.2.0-incubating > > > Faster producer topic will impact slower producer topic when they are in the > same broker, so we need depth control to limit the faster guy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-128) Support HA switch automatically
[ https://issues.apache.org/jira/browse/ROCKETMQ-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-128: -- Fix Version/s: 4.2.0-incubating > Support HA switch automatically > --- > > Key: ROCKETMQ-128 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-128 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker >Affects Versions: 4.0.0-incubating >Reporter: Eason Chen >Assignee: yukon > Fix For: 4.2.0-incubating > > > Ha is an very important feature in production , when server crash, how to > keep continuity of business is the first job. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-182) Go SDK Tracing
[ https://issues.apache.org/jira/browse/ROCKETMQ-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-182: -- Fix Version/s: 4.2.0-incubating > Go SDK Tracing > -- > > Key: ROCKETMQ-182 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-182 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-externals > Environment: Linux & Windows >Reporter: WenFeng Wang >Assignee: yukon > Labels: features > Fix For: 4.2.0-incubating > > > Go SDK for RocketMQ. > This Issue is mainly used for tracking the Go SDK design and development, if > you have any Suggestions, can also be discussed in this Issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-185) RocketMQ-MySQL design
[ https://issues.apache.org/jira/browse/ROCKETMQ-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-185: -- Fix Version/s: 4.2.0-incubating > RocketMQ-MySQL design > - > > Key: ROCKETMQ-185 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-185 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-externals >Reporter: Qun Zhao >Assignee: Qun Zhao > Fix For: 4.2.0-incubating > > > This issue is purpose to discuss about RocketMQ-MySQL design. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-78) Prepare and place Dockerfile under incubator-rocketmq/
[
https://issues.apache.org/jira/browse/ROCKETMQ-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-78:
-
Fix Version/s: 4.2.0-incubating
> Prepare and place Dockerfile under incubator-rocketmq/
> --
>
> Key: ROCKETMQ-78
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-78
> Project: Apache RocketMQ
> Issue Type: Task
> Components: rocketmq-externals
>Reporter: Roman Shtykh
>Assignee: vongosling
> Fix For: 4.2.0-incubating
>
>
> {{Dockerfile}} has to be placed under {{incubator-rocketmq/}}, probably in
> {{docker}} directory.
> See
> https://github.com/apache/ignite/tree/master/modules/docker
> https://github.com/apache/flink/tree/master/flink-contrib/docker-flink
> https://github.com/apache/hbase/tree/master/dev-support/docker
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-97) SendCallback should bring response code and extMessags in OnException
[ https://issues.apache.org/jira/browse/ROCKETMQ-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-97: - Fix Version/s: 4.1.0-incubating > SendCallback should bring response code and extMessags in OnException > - > > Key: ROCKETMQ-97 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-97 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-client >Affects Versions: 4.1.0-incubating >Reporter: Jaskey Lam >Assignee: yukon > Fix For: 4.1.0-incubating > > > For sendAsync, when excpetion occurs, the developer will have nothing to > distiguish what kind of exception it is unless read the remark or stacktrace. > Actually, for some broker problems, say service_not_availble or system_error, > the devs should do some special actions. This can be got from send in sync > way since the response will return to the caller. > But now, in async send, with no response code , we can't distinguish them. > Even more, for some situation, the queue sent to is needed , so if possible, > there should be an ext fields where collect as many message as possible to > let developer to descide their callback behavior. Which is neither exist in > sync nor async ways. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-108) Add username and password to RemotingCommand to support access control in broker
[ https://issues.apache.org/jira/browse/ROCKETMQ-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-108: -- Fix Version/s: 4.1.0-incubating > Add username and password to RemotingCommand to support access control in > broker > > > Key: ROCKETMQ-108 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-108 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-remoting >Reporter: Jaskey Lam >Assignee: vongosling > Fix For: 4.2.0-incubating > > > For now, authentication is done in RocketMQ, though broker can use hook to to > reject some requests according to IP. > But some authentications will propably need user and password. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-110) consumeConcurrentlyMaxSpan has a very limited role
[
https://issues.apache.org/jira/browse/ROCKETMQ-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-110:
--
Fix Version/s: 4.1.0-incubating
> consumeConcurrentlyMaxSpan has a very limited role
> --
>
> Key: ROCKETMQ-110
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-110
> Project: Apache RocketMQ
> Issue Type: Improvement
> Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: Jaskey Lam
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> Actually, in the current implementation of consumeConcurrentlyMaxSpan , the
> role it plays is very limited.
> In my opinion, RocketMQ hopes to solve a problem that when some messages are
> blocked( may be possibly considered as dead lock or dead loop),say message
> with offset 100 is blocked, and the rest whose offset are 101 to 2100 are
> very healthy, but in the case that if the process is killed (since it can
> not be shutdown normally if dead lock or dead loop is really happens when
> consuming), the later messages 101 to 2100 which is consumed sucessfully will
> be repeated to consume again since the consumer offset will still remains at
> 100.
> So to reduce the influence of repeated message numbers, flow control should
> be taken.
> But the current implementaion is to compare the span of last message of the
> first message to consumeConcurrentlyMaxSpan.
> In the above example, the span is 2000 and flow control may do action to make
> it pause for one cycle for 50ms, but next time when the message 2100 and the
> rest of healthy message consumed successfully , the fisrt key and the last
> key will be the same, 110, and the max span will be considered as 0, pull
> operation will continue.
> {code}
> public long getMaxSpan() {
> try {
> this.lockTreeMap.readLock().lockInterruptibly();
> try {
> if (!this.msgTreeMap.isEmpty()) {
> return this.msgTreeMap.lastKey() -
> this.msgTreeMap.firstKey();
> }
> } finally {
> this.lockTreeMap.readLock().unlock();
> }
> } catch (InterruptedException e) {
> log.error("getMaxSpan exception", e);
> }
> return 0;
> }
> {code}
> So for single message problem, consumeConcurrentlyMaxSpan will help nothing
> but in my opion this is what flow control should also takes into
> considerations.
> I suggest maxSpan should be lastConsumedOffset(does not record now) -
> firstConsumingOffset(the first key of msgTreeMap).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-48) Link to docker image not accessable . It lead to hub.docker.com
[ https://issues.apache.org/jira/browse/ROCKETMQ-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-48: - Fix Version/s: 4.1.0-incubating > Link to docker image not accessable . It lead to hub.docker.com > --- > > Key: ROCKETMQ-48 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-48 > Project: Apache RocketMQ > Issue Type: Bug > Components: build >Reporter: netroby >Assignee: Stevens Chew > Fix For: 4.1.0-incubating > > > https://registry.hub.docker.com/u/vongosl...@apache.org/rocketmq/ > The link on the project readme.md, not working. > it just lead to redirect to https://hub.docker.com > Please check -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-28) Transportation Layer Security
[ https://issues.apache.org/jira/browse/ROCKETMQ-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022394#comment-16022394 ] dongeforever commented on ROCKETMQ-28: -- Yeah. it is important to implement some security mechanism, such as ssl, sasl etc. > Transportation Layer Security > - > > Key: ROCKETMQ-28 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-28 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-remoting >Reporter: Zhanhui Li >Assignee: Stevens Chew > Fix For: 4.2.0-incubating > > > RocketMQ delivers data in clear text for now, which requires internal network > environment. As use scenarios expand, end-to-end security is in bad need. > This issue is to introduce features making RocketMQ security for various use > cases and sacrificing as few as possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-28) Transportation Layer Security
[ https://issues.apache.org/jira/browse/ROCKETMQ-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-28: - Fix Version/s: 4.2.0-incubating > Transportation Layer Security > - > > Key: ROCKETMQ-28 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-28 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-remoting >Reporter: Zhanhui Li >Assignee: Stevens Chew > Fix For: 4.2.0-incubating > > > RocketMQ delivers data in clear text for now, which requires internal network > environment. As use scenarios expand, end-to-end security is in bad need. > This issue is to introduce features making RocketMQ security for various use > cases and sacrificing as few as possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-131) Hit brief pause when delete expire file periodicity
[ https://issues.apache.org/jira/browse/ROCKETMQ-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-131: -- Fix Version/s: 4.2.0-incubating > Hit brief pause when delete expire file periodicity > --- > > Key: ROCKETMQ-131 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-131 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-store >Reporter: Eason Chen >Assignee: yukon > Fix For: 4.2.0-incubating > > > Hit brief pause when delete expire file periodicity, meanwhile producer and > consumer latency will become higher than normal -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-131) Hit brief pause when delete expire file periodicity
[ https://issues.apache.org/jira/browse/ROCKETMQ-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022392#comment-16022392 ] dongeforever commented on ROCKETMQ-131: --- More details? Such as the machine info and other system stats. > Hit brief pause when delete expire file periodicity > --- > > Key: ROCKETMQ-131 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-131 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-store >Reporter: Eason Chen >Assignee: yukon > > Hit brief pause when delete expire file periodicity, meanwhile producer and > consumer latency will become higher than normal -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-132) Support request/response invoke mode like sync RPC
[ https://issues.apache.org/jira/browse/ROCKETMQ-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022391#comment-16022391 ] dongeforever commented on ROCKETMQ-132: --- As I known, rocketmq now could send a message in a sync way. So what do you mean? > Support request/response invoke mode like sync RPC > -- > > Key: ROCKETMQ-132 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-132 > Project: Apache RocketMQ > Issue Type: Wish >Reporter: Eason Chen >Assignee: vongosling > Fix For: 4.2.0-incubating > > > Mostly business need to wait a response after send a request,just like sync > RPC -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-132) Support request/response invoke mode like sync RPC
[ https://issues.apache.org/jira/browse/ROCKETMQ-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-132: -- Fix Version/s: 4.2.0-incubating > Support request/response invoke mode like sync RPC > -- > > Key: ROCKETMQ-132 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-132 > Project: Apache RocketMQ > Issue Type: Wish >Reporter: Eason Chen >Assignee: vongosling > Fix For: 4.2.0-incubating > > > Mostly business need to wait a response after send a request,just like sync > RPC -- This message was sent by Atlassian JIRA (v6.3.15#6346)
