[jira] [Closed] (ROCKETMQ-25) Query Msg by key: Possible concurrent access to LinkedList
[ https://issues.apache.org/jira/browse/ROCKETMQ-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhanhui Li closed ROCKETMQ-25. -- Resolution: Fixed > Query Msg by key: Possible concurrent access to LinkedList > -- > > Key: ROCKETMQ-25 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-25 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client, rocketmq-tools >Affects Versions: 4.0.0-incubating > Environment: All >Reporter: Zhanhui Li >Assignee: Xiaorui Wang >Priority: Minor > Fix For: 4.0.0-incubating > > Original Estimate: 1h > Remaining Estimate: 1h > > As queries are delivered to all brokers asynchronously, callbacks may be > executed simultaneously, which results in concurrent access to LinkedList, a > thread-unsafe container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ROCKETMQ-25) Query Msg by key: Possible concurrent access to LinkedList
[ https://issues.apache.org/jira/browse/ROCKETMQ-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15797418#comment-15797418 ] ASF subversion and git services commented on ROCKETMQ-25: - Commit b421d48c476e74a8c7bb8129979df1dc0cb5a5a5 in incubator-rocketmq's branch refs/heads/master from [~lizhanhui] [ https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=b421d48 ] Fix https://issues.apache.org/jira/browse/ROCKETMQ-25 > Query Msg by key: Possible concurrent access to LinkedList > -- > > Key: ROCKETMQ-25 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-25 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client, rocketmq-tools >Affects Versions: 4.0.0-incubating > Environment: All >Reporter: Zhanhui Li >Assignee: Xiaorui Wang >Priority: Minor > Fix For: 4.0.0-incubating > > Original Estimate: 1h > Remaining Estimate: 1h > > As queries are delivered to all brokers asynchronously, callbacks may be > executed simultaneously, which results in concurrent access to LinkedList, a > thread-unsafe container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ROCKETMQ-25) Query Msg by key: Possible concurrent access to LinkedList
[ https://issues.apache.org/jira/browse/ROCKETMQ-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15797389#comment-15797389 ] Zhanhui Li edited comment on ROCKETMQ-25 at 1/4/17 7:18 AM: Unit tests is not viable for this scenario as tools like Mockito cannot mock objects and apply multi-threads at the same time. see https://github.com/mockito/mockito/wiki/FAQ section "Is Mockito thread-safe?" Here I would use code analysis. when querying message by message key, the command executor needs to query multiple brokers. See MQAdminImpl#288 On query result returns, callbacks are executed. When results return concurrently, multiple threads from Netty executor pool will concurrently access thread-unsafe container LinkedList. This would brings about exception complaining concurrent-modification. was (Author: lizhanhui): Unit tests is not viable for this scenario as tools like Mockito cannot mock objects and apply multi-threads at the same time. see https://github.com/mockito/mockito/wiki/FAQ section "Is Mockito thread-safe?" Here I would use code analysis. when querying message by message key, the command executor needs to query multiple brokers. On query result returns, callbacks are executed. When results return concurrently, multiple threads from netty executor pool will concurrently access thread-unsafe container LinkedList. This would brings about exception complaining concurrent-modification. > Query Msg by key: Possible concurrent access to LinkedList > -- > > Key: ROCKETMQ-25 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-25 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client, rocketmq-tools >Affects Versions: 4.0.0-incubating > Environment: All >Reporter: Zhanhui Li >Assignee: Xiaorui Wang >Priority: Minor > Fix For: 4.0.0-incubating > > Original Estimate: 1h > Remaining Estimate: 1h > > As queries are delivered to all brokers asynchronously, callbacks may be > executed simultaneously, which results in concurrent access to LinkedList, a > thread-unsafe container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ROCKETMQ-25) Query Msg by key: Possible concurrent access to LinkedList
[ https://issues.apache.org/jira/browse/ROCKETMQ-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15797389#comment-15797389 ] Zhanhui Li commented on ROCKETMQ-25: Unit tests is not viable for this scenario as tools like Mockito cannot mock objects and apply multi-threads at the same time. see https://github.com/mockito/mockito/wiki/FAQ section "Is Mockito thread-safe?" Here I would use code analysis. when querying message by message key, the command executor needs to query multiple brokers. On query result returns, callbacks are executed. When results return concurrently, multiple threads from netty executor pool will concurrently access thread-unsafe container LinkedList. This would brings about exception complaining concurrent-modification. > Query Msg by key: Possible concurrent access to LinkedList > -- > > Key: ROCKETMQ-25 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-25 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client, rocketmq-tools >Affects Versions: 4.0.0-incubating > Environment: All >Reporter: Zhanhui Li >Assignee: Xiaorui Wang >Priority: Minor > Fix For: 4.0.0-incubating > > Original Estimate: 1h > Remaining Estimate: 1h > > As queries are delivered to all brokers asynchronously, callbacks may be > executed simultaneously, which results in concurrent access to LinkedList, a > thread-unsafe container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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
]
Xiaorui Wang updated ROCKETMQ-17:
-
Description:
*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 & openrelay standards*
was:
*Openmessaging*
Openmessaging is a redefinition of the application of the access message
service programming API standard. It is only API, non line 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 & openrelay standards*
> 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:
[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
]
Xiaorui Wang updated ROCKETMQ-17:
-
Description:
*Openmessaging*
Openmessaging is a redefinition of the application of the access message
service programming API standard. It is only API, non line 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 & openrelay standards*
was:
*Openmessaging*
Openmessaging is a redefinition of the application of the access message
service programming API standard. It is only API, non line 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.`
{color}
*RocketMQ will be the first to support openmessaging & openrelay standards*
> 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
>
[jira] [Created] (ROCKETMQ-28) Transportation Layer Security
Zhanhui Li created ROCKETMQ-28: -- Summary: 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: vongosling 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.4#6332)
[jira] [Commented] (ROCKETMQ-5) Avoid creating directories in UtilAll#getDiskPartitionSpaceUsedPercent()
[
https://issues.apache.org/jira/browse/ROCKETMQ-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15794632#comment-15794632
]
ASF GitHub Bot commented on ROCKETMQ-5:
---
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-rocketmq/pull/23
> Avoid creating directories in UtilAll#getDiskPartitionSpaceUsedPercent()
>
>
> Key: ROCKETMQ-5
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-5
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Since {{UtilAll#getDiskPartitionSpaceUsedPercent()}} is a diagnostic method,
> rather than creating a directory if it is not found, produce an error log
> that the directory is supposed to exist and return {{-1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ROCKETMQ-5) Avoid creating directories in UtilAll#getDiskPartitionSpaceUsedPercent()
[
https://issues.apache.org/jira/browse/ROCKETMQ-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15794631#comment-15794631
]
ASF subversion and git services commented on ROCKETMQ-5:
Commit 9cb0a0cd46cf91b324b7c6c66d7479d21073d6f6 in incubator-rocketmq's branch
refs/heads/master from shroman
[ https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=9cb0a0c ]
[ROCKETMQ-5] Avoid creating directories in
UtilAll#getDiskPartitionSpaceUsedPercent(), closes apache/incubator-rocketmq#23
> Avoid creating directories in UtilAll#getDiskPartitionSpaceUsedPercent()
>
>
> Key: ROCKETMQ-5
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-5
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Since {{UtilAll#getDiskPartitionSpaceUsedPercent()}} is a diagnostic method,
> rather than creating a directory if it is not found, produce an error log
> that the directory is supposed to exist and return {{-1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel=15794528#comment-15794528 ] ASF subversion and git services commented on ROCKETMQ-17: - Commit 159804d9123b780e7a3aaf019127f460b0e88b18 in incubator-rocketmq's branch refs/heads/spec from [~vintagewang] [ https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=159804d ] [ROCKETMQ-17] Develop a vendor-neutral open standard for distributed messaging: refactor producer ASF JIRA: https://issues.apache.org/jira/browse/ROCKETMQ-17 > 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 > > We named this new feature openmessaging & openrelay. >* openmessaging is a new, open distributed messaging client-api standard > for distributed application. >* openrelay is a client-api standard for using messaging to simulate > service invocations that can penetrate firewalls in complex network > environments > This standard can better cover the field of distributed message programming, > large data message programming, flow computing message programming, etc. > RocketMQ will be the first to support openmessaging & openrelay standards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel=15794530#comment-15794530 ] ASF subversion and git services commented on ROCKETMQ-17: - Commit c25253a7873faaa55a2ff81799db71bab8c35c76 in incubator-rocketmq's branch refs/heads/spec from [~vintagewang] [ https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=c25253a ] [ROCKETMQ-17] Develop a vendor-neutral open standard for distributed messaging: set BytesMessage.setbody method, and return BytesMessage ASF JIRA: https://issues.apache.org/jira/browse/ROCKETMQ-17 > 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 > > We named this new feature openmessaging & openrelay. >* openmessaging is a new, open distributed messaging client-api standard > for distributed application. >* openrelay is a client-api standard for using messaging to simulate > service invocations that can penetrate firewalls in complex network > environments > This standard can better cover the field of distributed message programming, > large data message programming, flow computing message programming, etc. > RocketMQ will be the first to support openmessaging & openrelay standards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel=15794533#comment-15794533 ] ASF subversion and git services commented on ROCKETMQ-17: - Commit 08ab1ae264ab9d6943d99372eb6034e98afd22a8 in incubator-rocketmq's branch refs/heads/spec from [~vintagewang] [ https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=08ab1ae ] [ROCKETMQ-17] openmessaging: refactor BytesMessage ASF JIRA: https://issues.apache.org/jira/browse/ROCKETMQ-17 > 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 > > We named this new feature openmessaging & openrelay. >* openmessaging is a new, open distributed messaging client-api standard > for distributed application. >* openrelay is a client-api standard for using messaging to simulate > service invocations that can penetrate firewalls in complex network > environments > This standard can better cover the field of distributed message programming, > large data message programming, flow computing message programming, etc. > RocketMQ will be the first to support openmessaging & openrelay standards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel=15794525#comment-15794525 ] ASF subversion and git services commented on ROCKETMQ-17: - Commit 86f4e26171935ed92c0341c56fa60e4033aa40af in incubator-rocketmq's branch refs/heads/spec from [~vintagewang] [ https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=86f4e26 ] [ROCKETMQ-17] Develop a vendor-neutral open standard for distributed messaging: Add the asynchronous send message mechanism ASF JIRA: https://issues.apache.org/jira/browse/ROCKETMQ-17 > 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 > > We named this new feature openmessaging & openrelay. >* openmessaging is a new, open distributed messaging client-api standard > for distributed application. >* openrelay is a client-api standard for using messaging to simulate > service invocations that can penetrate firewalls in complex network > environments > This standard can better cover the field of distributed message programming, > large data message programming, flow computing message programming, etc. > RocketMQ will be the first to support openmessaging & openrelay standards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ROCKETMQ-19) Thread-unsafe in MQAdminImpl#queryMessage
[ https://issues.apache.org/jira/browse/ROCKETMQ-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15794501#comment-15794501 ] ASF GitHub Bot commented on ROCKETMQ-19: Github user Zhang-Ke commented on the issue: https://github.com/apache/incubator-rocketmq/pull/17 Duplicated with [https://github.com/apache/incubator-rocketmq/pull/22]PR #22 (url) > Thread-unsafe in MQAdminImpl#queryMessage > - > > Key: ROCKETMQ-19 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-19 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client >Affects Versions: 4.0.0-incubating >Reporter: ZhangKe >Assignee: Xiaorui Wang > Fix For: 4.0.0-incubating > > > LinkedList.add() is not thread-safe, so it must be synchronized externally > when using concurrently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
