[
https://issues.apache.org/jira/browse/TUBEMQ-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guocheng Zhang updated TUBEMQ-109:
----------------------------------
Description:
Remarks: I originally wanted to put the improvement items on cwiki to create an
RFC for discussion. I found that I could not create it during the operation. I
am not sure what the reason is. so create it on Jira first, then discuss, and
then implement it.
To summarize the recent analysis of the implementation of TubeMQ RPC, I think
we need to adjust the following content of TubeMQ RPC to make the system more
powerful:
1. The header of each RPC packet should consist of the length of the entire
packet, not the number of multiple lists, which can be used to identify illegal
packets and allocate memory resources in advance;
2. The message returned by the exception should not carry the exception class
to the recipient of the response, but should be provided to the client through
the error code and error information;
3. The structure of the response message of this method needs to be improved,
the success field should be deleted, and errors should be distinguished by
unique error codes. Use clear error codes to clearly mark specific error
details so that SDK users can get the exact cause of the error and find clear
error handling suggestions based on the documentation;
4. Each method in RPC should carry version information, so that different
versions can correspond to different decoding schemes
5. If the subsequent RPC still uses PB for coding and decoding, you need to use
maven-shade-plugin to cover PB and Netty. Otherwise, the jar package released
can easily form a version conflict with the corresponding dependency package of
the business
was:
Remarks: I originally wanted to put the improvement items on cwiki to create an
RFC for discussion. I found that I could not create it during the operation. I
am not sure what the reason is. so create it on Jira first, then discuss, and
then implement it.
To summarize the recent analysis of the implementation of TubeMQ RPC, I think
we need to adjust the following content of TubeMQ RPC to make the system more
powerful:
1. The header field of each rpc message should contain the length of the entire
message, rather than the number of multiple lists, which can solve the rapid
judgment of illegal messages and pre-allocate the memory resources of the
message;
2. The message returned by the exception should not carry the exception class
to the recipient of the response, but should be provided to the client through
the error code and error information;
3. The structure of the response message of this method needs to be improved,
the success field should be deleted, and errors should be distinguished by
unique error codes. Use clear error codes to clearly mark specific error
details so that SDK users can get the exact cause of the error and find clear
error handling suggestions based on the documentation;
4. Each method in RPC should carry version information, so that different
versions can correspond to different decoding schemes
5. If the subsequent RPC still uses PB for coding and decoding, you need to use
maven-shade-plugin to cover PB and Netty. Otherwise, the jar package released
can easily form a version conflict with the corresponding dependency package of
the business
> Optimize RPC
> ------------
>
> Key: TUBEMQ-109
> URL: https://issues.apache.org/jira/browse/TUBEMQ-109
> Project: Apache TubeMQ
> Issue Type: Task
> Reporter: Guocheng Zhang
> Priority: Major
> Labels: features, performance
>
> Remarks: I originally wanted to put the improvement items on cwiki to create
> an RFC for discussion. I found that I could not create it during the
> operation. I am not sure what the reason is. so create it on Jira first, then
> discuss, and then implement it.
>
> To summarize the recent analysis of the implementation of TubeMQ RPC, I think
> we need to adjust the following content of TubeMQ RPC to make the system more
> powerful:
> 1. The header of each RPC packet should consist of the length of the entire
> packet, not the number of multiple lists, which can be used to identify
> illegal packets and allocate memory resources in advance;
> 2. The message returned by the exception should not carry the exception class
> to the recipient of the response, but should be provided to the client
> through the error code and error information;
> 3. The structure of the response message of this method needs to be improved,
> the success field should be deleted, and errors should be distinguished by
> unique error codes. Use clear error codes to clearly mark specific error
> details so that SDK users can get the exact cause of the error and find clear
> error handling suggestions based on the documentation;
> 4. Each method in RPC should carry version information, so that different
> versions can correspond to different decoding schemes
> 5. If the subsequent RPC still uses PB for coding and decoding, you need to
> use maven-shade-plugin to cover PB and Netty. Otherwise, the jar package
> released can easily form a version conflict with the corresponding dependency
> package of the business
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
