[ISSUE #994]⚡️Optimize RocketmqDefaultClient code #995
Conversation
WalkthroughThe changes introduced in this pull request primarily focus on enhancing memory management and ownership semantics across various components of the RocketMQ system. Key modifications include the introduction of weak references and the use of Changes
Sequence Diagram(s)sequenceDiagram
participant BrokerRuntime
participant BrokerOuterAPI
participant MQClientAPIImpl
participant RpcClientImpl
BrokerRuntime->>BrokerOuterAPI: Register broker with weak reference
BrokerOuterAPI->>MQClientAPIImpl: Start with weak reference
MQClientAPIImpl->>RpcClientImpl: Initialize remoting client
RpcClientImpl->>RpcClientImpl: Manage lifecycle with weak reference
Assessment against linked issues
Possibly related PRs
Suggested labels
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
🚀Thanks for your contribution🎉. CodeRabbit(AI) will review your code first🔥 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #995 +/- ##
=======================================
Coverage 19.49% 19.49%
=======================================
Files 412 412
Lines 34235 34237 +2
=======================================
+ Hits 6673 6674 +1
- Misses 27562 27563 +1 ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Outside diff range and nitpick comments (6)
rocketmq-remoting/src/remoting.rs (1)
Line range hint
1-70: Summary of changes and recommendationsThe modifications to
rocketmq-remoting/src/remoting.rsintroduce a significant change to theRemotingServicetrait:
- A new import for
WeakCellWrapperhas been added.- The
startmethod signature in theRemotingServicetrait has been updated to include aWeakCellWrapper<Self>parameter.These changes aim to improve memory management and avoid potential reference cycles. However, they may have far-reaching implications across the codebase.
Recommendations:
- Thoroughly test all implementations of
RemotingServiceto ensure they comply with the new signature.- Update documentation and comments to reflect the purpose and usage of the new
WeakCellWrapper<Self>parameter.- Consider adding a migration guide or updating the changelog to inform users of this potentially breaking change.
- Review the overall architecture to ensure this change aligns with the project's design goals and doesn't introduce unnecessary complexity.
Given the significance of this change, it may be beneficial to include a brief explanation in the PR description about the motivation behind using
WeakCellWrapperand how it improves the overall design of the system.rocketmq-namesrv/src/bootstrap.rs (1)
Line range hint
1-168: Summary of changes and potential impactThe changes in this file introduce better memory management and ownership semantics for the
remoting_clientby usingArcRefCellWrapper. This allows for shared ownership and interior mutability, which can be beneficial in concurrent scenarios. The changes are consistent throughout the file.However, it's important to note that these changes might have an impact on other parts of the codebase that use
remoting_client. Ensure that all usages ofremoting_clientthroughout the project have been updated to accommodate this change, particularly in terms of how the client is accessed and modified.Consider adding documentation comments to explain the rationale behind using
ArcRefCellWrapperforremoting_client. This will help future maintainers understand the design decision and use the client correctly.rocketmq-namesrv/src/route/route_info_manager.rs (2)
84-84: Constructor updated to match new field typeThe constructor has been correctly updated to accept the new
ArcRefCellWrapper<RocketmqDefaultClient>type. This change is consistent with the struct definition update.Consider updating the documentation for this constructor to reflect the new type and explain why
ArcRefCellWrapperis used instead of a simpleArc.
77-84: Summary of changes and potential impactThe primary change in this file is the switch from
Arc<RocketmqDefaultClient>toArcRefCellWrapper<RocketmqDefaultClient>for theremoting_clientfield. This change affects both the struct definition and the constructor.Potential impacts and considerations:
- Improved flexibility in managing shared mutable state.
- Possible changes required in how
remoting_clientis accessed and used throughout the codebase.- Potential for enhanced concurrency support, depending on the implementation of
ArcRefCellWrapper.Consider the following recommendations:
- Update documentation to explain the rationale behind using
ArcRefCellWrapper.- Review the entire codebase for any places where the usage of
remoting_clientmight need to be adjusted.- If not already done, consider adding unit tests to verify that the behavior of
RouteInfoManagerremains correct with this new wrapper type.- Ensure that the performance characteristics of
ArcRefCellWrapperalign with the system's requirements, especially in high-concurrency scenarios.rocketmq-broker/src/out_api/broker_outer_api.rs (2)
60-63: Remove UnnecessarymutKeyword forclientVariableIn the constructors at lines 60-63 and 77-80, the variable
clientis declared withlet mut client, but there is no subsequent mutation ofclientafter initialization (unlessregister_rpc_hookrequires a mutable reference). Removing themutkeyword can improve code clarity by accurately reflecting the immutability ofclient.Also applies to: 77-80
116-117: Consider Strong Reference ifremoting_clientMust PersistDowngrading
remoting_clientto a weak reference in thestartmethod suggests thatremoting_clientmight be dropped elsewhere, which could lead to unexpected behavior if it becomes invalid during operation. Ifremoting_clientis essential for the broker's operation and should persist as long as theBrokerOuterAPIexists, consider maintaining a strongArcreference instead of a weak one.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (8)
- rocketmq-broker/src/broker_runtime.rs (4 hunks)
- rocketmq-broker/src/out_api/broker_outer_api.rs (6 hunks)
- rocketmq-client/src/implementation/mq_client_api_impl.rs (3 hunks)
- rocketmq-namesrv/src/bootstrap.rs (4 hunks)
- rocketmq-namesrv/src/route/route_info_manager.rs (2 hunks)
- rocketmq-remoting/src/clients/rocketmq_default_impl.rs (2 hunks)
- rocketmq-remoting/src/remoting.rs (2 hunks)
- rocketmq-remoting/src/rpc/rpc_client_impl.rs (3 hunks)
Additional comments not posted (17)
rocketmq-remoting/src/remoting.rs (1)
19-20: LGTM: New import added correctly.The import of
WeakCellWrapperfromrocketmq_commonis correctly placed and follows Rust naming conventions. This import is necessary for the changes made to thestartmethod signature in theRemotingServicetrait.rocketmq-namesrv/src/bootstrap.rs (4)
23-23: LGTM: Import of ArcRefCellWrapperThe import of
ArcRefCellWrapperis correctly added and is necessary for the changes made to theremoting_clientfield in theNameServerRuntimestruct.
146-149: LGTM: Correct initialization of remoting_client with ArcRefCellWrapperThe initialization of
remoting_clienthas been correctly updated to useArcRefCellWrapper::new(). This change is consistent with the new type in theNameServerRuntimestruct. TheRocketmqDefaultClient::new()call and its parameters remain unchanged, which is correct.
158-158: LGTM: Correct usage of remoting_client in RouteInfoManager initializationThe
remoting_clientis now correctly cloned when passed toRouteInfoManager::new(). This change is necessary and appropriate due to the newArcRefCellWrappertype. Cloning anArcRefCellWrapperis a cheap operation that only increments the reference count, allowingRouteInfoManagerto have its own reference to the client. This is good for ownership management and consistency with the new type.
53-53: Approve change to remoting_client type, verify usageThe change to use
ArcRefCellWrapper<RocketmqDefaultClient>forremoting_clientis appropriate. It allows for shared ownership and interior mutability, which can be beneficial in concurrent scenarios.Please verify that all usages of
remoting_clientthroughout the codebase have been updated to accommodate this change. Run the following script to check for potential issues:rocketmq-remoting/src/rpc/rpc_client_impl.rs (4)
20-20: LGTM: New import for improved memory managementThe addition of
ArcRefCellWrapperimport suggests an enhancement in managing shared ownership and interior mutability. This change likely aims to improve thread safety and flexibility in accessing shared resources.
Line range hint
1-465: Summary: Improved memory management and ownership semanticsThe changes in this file focus on enhancing the
RpcClientImplstruct by introducingArcRefCellWrapperfor better shared ownership and interior mutability of theremoting_client. The addition ofDefaultRemotingRequestProcessoras a type parameter toRocketmqDefaultClientsuggests a more specific configuration for request processing. These modifications align with the PR objective of optimizing the RocketmqDefaultClient code.While the changes appear to be well-implemented, it's crucial to ensure that:
- All usages of
remoting_clientthroughout the implementation properly handle the new wrapper type.- All instantiations of
RpcClientImplin the codebase have been updated to provide the correct type for theremoting_clientparameter.These changes may have a positive impact on the overall performance and thread safety of the system, particularly in scenarios involving shared access to the client across multiple threads.
52-55: LGTM: Updatednewmethod signatureThe
newmethod signature has been correctly updated to match the newremoting_clientfield type. This change ensures consistency with the struct definition.Please verify that all instantiations of
RpcClientImplin the codebase have been updated to provide the correct type for theremoting_clientparameter. Run the following script to find potential usage:#!/bin/bash # Description: Find RpcClientImpl instantiations # Test: Search for RpcClientImpl::new calls rg --type rust 'RpcClientImpl::new'
47-47: LGTM: Enhancedremoting_clientfield typeThe
remoting_clientfield now usesArcRefCellWrapper, which improves shared ownership and interior mutability. The addition ofDefaultRemotingRequestProcessortype parameter toRocketmqDefaultClientsuggests a more specific configuration for request processing.Please ensure that all accesses to
remoting_clientthroughout the implementation properly handle the new wrapper type. Run the following script to verify the usage:rocketmq-namesrv/src/route/route_info_manager.rs (2)
77-77: Improved flexibility with ArcRefCellWrapperThe change from
Arc<RocketmqDefaultClient>toArcRefCellWrapper<RocketmqDefaultClient>for theremoting_clientfield enhances flexibility in managing shared mutable state. This wrapper likely provides interior mutability, which can be beneficial for concurrent access patterns in a multi-threaded environment.
77-84: Verify compatibility of remoting_client usageThe change from
Arc<RocketmqDefaultClient>toArcRefCellWrapper<RocketmqDefaultClient>may affect howremoting_clientis used throughout the codebase.Please run the following script to check for any incompatible usages of
remoting_client:Review the output to ensure all usages are compatible with the new
ArcRefCellWrappertype. You may need to update some code to use methods provided byArcRefCellWrapperinstead ofArc.rocketmq-broker/src/broker_runtime.rs (3)
Line range hint
898-914: Approve the use of weak reference for improved memory managementThe addition of a weak reference to
self.broker_out_apiis a good practice. By usingArc::downgrade, you're preventing potential circular references and memory leaks. This change allows for better management of the lifecycle of theBrokerOuterAPIinstance, especially in asynchronous contexts.
Line range hint
1017-1033: Approve consistent application of weak reference patternThe addition of a weak reference to
self.broker_out_apiin this method is consistent with the earlier change. This demonstrates a systematic approach to improving memory management throughout the codebase. Well done on maintaining consistency in applying this pattern.
Line range hint
898-1033: Overall improvement in memory managementThe changes made in this file demonstrate a focused effort to optimize memory management, particularly in handling shared resources like
BrokerOuterAPI. The consistent use of weak references (Arc::downgrade) across different methods indicates a systematic approach to preventing circular dependencies and potential memory leaks. This refactoring enhances the robustness of the broker runtime implementation, especially in asynchronous contexts. Great job on improving the code quality and resource management!rocketmq-broker/src/out_api/broker_outer_api.rs (2)
152-152: Appropriate Use ofWeak<Self>to Avoid Strong Reference CyclesAdding
this: Weak<Self>to theregister_broker_allmethod helps prevent strong reference cycles by allowing you to hold a weak reference toself. This is a good practice to manage ownership and avoid potential memory leaks.
116-117: Verify Passing Weak Reference tostartMethodIn the
startmethod, you downgradeself.remoting_clientto a weak reference and pass it toself.remoting_client.start(wrapper).await. Ensure that thestartmethod ofRocketmqDefaultClientis designed to accept aWeakreference and that it handles scenarios where the weak reference cannot be upgraded. This is crucial to prevent potential runtime errors.You can run the following script to verify the
startmethod's signature and its handling of weak references:rocketmq-client/src/implementation/mq_client_api_impl.rs (1)
136-137:⚠️ Potential issueEnsure weak reference validity in
startmethodAt lines 136-137, you downgrade
self.remoting_clientto a weak reference and pass it toself.remoting_client.start(client).await. Ensure that thestartmethod properly checks if the weak reference is still valid before upgrading it to a strong reference. This prevents potentialNoneerrors or panics when attempting to use a dropped reference.Confirm that the
startmethod handles weak references correctly:#!/bin/bash # Description: Verify that `start` method checks for weak reference validity # Search for the `start` method implementation and look for checks on the weak reference rg --type rust 'impl.*RocketmqDefaultClient' -A 50 | rg 'fn\s+start' -A 20
| @@ -36,7 +38,7 @@ pub trait RemotingService: Send { | |||
| /// This function should initialize and start the service, making it ready to handle incoming | |||
| /// or outgoing remote procedure calls. The exact implementation details, such as opening | |||
| /// network connections or preparing internal state, are left to the implementor. | |||
| async fn start(&self); | |||
| async fn start(&self, this: WeakCellWrapper<Self>); | |||
There was a problem hiding this comment.
💡 Codebase verification
Incomplete update of start method signature across implementations.
The following implementations of RemotingService still have the old start method signature without the this: WeakCellWrapper<Self> parameter:
rocketmq-client/src/implementation/mq_client_api_impl.rs:pub async fn start(&self)rocketmq-broker/src/out_api/broker_outer_api.rs:pub async fn start(&self)
Please update these implementations to match the new method signature to ensure consistency and prevent potential breaking changes.
Analysis chain
Verify impact of start method signature change.
The modification to the start method signature in the RemotingService trait is significant:
- It introduces a new parameter
this: WeakCellWrapper<Self>, which changes how the service manages its lifecycle or self-referencing. - This change will affect all implementations of the
RemotingServicetrait and may potentially break existing code if not handled carefully.
The use of WeakCellWrapper suggests an attempt to avoid strong reference cycles, which is a good practice for memory management.
To ensure this change doesn't introduce unintended consequences:
- Verify all implementations of
RemotingServiceare updated accordingly. - Check for any potential breaking changes in dependent code.
Run the following script to identify affected implementations:
Please review the results and ensure all implementations are updated to match the new signature.
Consider documenting this change in the crate's changelog and updating any relevant documentation to reflect the new parameter and its purpose.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all implementations of RemotingService trait and their start methods
# Find RemotingService implementations
echo "RemotingService implementations:"
rg --type rust "impl.*RemotingService.*for" -g '!target/'
# Find start method implementations
echo "\nstart method implementations:"
rg --type rust "async fn start.*&self" -g '!target/'
Length of output: 788
| loop { | ||
| time::sleep(Duration::from_millis(1)).await; | ||
| client.scan_available_name_srv().await; | ||
| } | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Implement graceful shutdown for the spawned task
The spawned task runs an infinite loop without any exit condition or cancellation handling. To prevent potential resource leaks and enable proper shutdown of the service, consider implementing a mechanism to gracefully terminate the loop when the service is stopped.
| loop { | ||
| time::sleep(Duration::from_millis(1)).await; | ||
| client.scan_available_name_srv().await; | ||
| } |
There was a problem hiding this comment.
Increase sleep duration in the loop to reduce CPU usage
The loop in the spawned task sleeps for only 1 millisecond between iterations. This tight loop may lead to high CPU usage. Consider increasing the sleep duration to balance performance and resource consumption.
Apply this diff to increase the sleep duration:
loop {
- time::sleep(Duration::from_millis(1)).await;
+ time::sleep(Duration::from_secs(1)).await;
client.scan_available_name_srv().await;
}Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| loop { | |
| time::sleep(Duration::from_millis(1)).await; | |
| client.scan_available_name_srv().await; | |
| } | |
| loop { | |
| time::sleep(Duration::from_secs(1)).await; | |
| client.scan_available_name_srv().await; | |
| } |
| pub struct BrokerOuterAPI { | ||
| remoting_client: RocketmqDefaultClient, | ||
| remoting_client: ArcRefCellWrapper<RocketmqDefaultClient<DefaultRemotingRequestProcessor>>, |
There was a problem hiding this comment.
Ensure Thread Safety with ArcRefCellWrapper Usage
The change to use ArcRefCellWrapper<RocketmqDefaultClient<DefaultRemotingRequestProcessor>> for remoting_client introduces interior mutability via RefCell. In asynchronous and potentially multithreaded contexts, RefCell is not thread-safe, which can lead to runtime borrow panics if mutable borrows overlap across threads. Consider using Arc<Mutex<T>> or Arc<RwLock<T>> for thread-safe interior mutability, ensuring that access to remoting_client is properly synchronized.
| let outer_api = this.clone(); | ||
| let join_handle = tokio::spawn(async move { | ||
| outer_api | ||
| .register_broker(addr, oneway, timeout_mills, cloned_header, cloned_body) | ||
| .await | ||
| if let Some(outer_api) = outer_api.upgrade() { | ||
| outer_api | ||
| .register_broker( | ||
| addr, | ||
| oneway, | ||
| timeout_mills, | ||
| cloned_header, | ||
| cloned_body, | ||
| ) | ||
| .await | ||
| } else { | ||
| None | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add Logging for Failed Weak Reference Upgrades
In the asynchronous task within register_broker_all, if outer_api.upgrade() returns None, the code currently returns None silently. For better debuggability, consider adding a log message to indicate that the BrokerOuterAPI instance has been dropped and the weak reference could not be upgraded.
You can modify the code as follows to add an error log:
if let Some(outer_api) = outer_api.upgrade() {
outer_api
.register_broker(
addr,
oneway,
timeout_mills,
cloned_header,
cloned_body,
)
.await
} else {
+ error!("Failed to upgrade Weak reference to BrokerOuterAPI. The instance may have been dropped.");
None
}Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let outer_api = this.clone(); | |
| let join_handle = tokio::spawn(async move { | |
| outer_api | |
| .register_broker(addr, oneway, timeout_mills, cloned_header, cloned_body) | |
| .await | |
| if let Some(outer_api) = outer_api.upgrade() { | |
| outer_api | |
| .register_broker( | |
| addr, | |
| oneway, | |
| timeout_mills, | |
| cloned_header, | |
| cloned_body, | |
| ) | |
| .await | |
| } else { | |
| None | |
| } | |
| let outer_api = this.clone(); | |
| let join_handle = tokio::spawn(async move { | |
| if let Some(outer_api) = outer_api.upgrade() { | |
| outer_api | |
| .register_broker( | |
| addr, | |
| oneway, | |
| timeout_mills, | |
| cloned_header, | |
| cloned_body, | |
| ) | |
| .await | |
| } else { | |
| error!("Failed to upgrade Weak reference to BrokerOuterAPI. The instance may have been dropped."); | |
| None | |
| } |
| @@ -93,7 +93,7 @@ | |||
| } | |||
|
|
|||
| pub struct MQClientAPIImpl { | |||
| remoting_client: RocketmqDefaultClient<ClientRemotingProcessor>, | |||
| remoting_client: ArcRefCellWrapper<RocketmqDefaultClient<ClientRemotingProcessor>>, | |||
There was a problem hiding this comment.
💡 Codebase verification
Potential thread-safety issue with ArcRefCellWrapper
The ArcRefCellWrapper does not implement the Send and Sync traits. Since RefCell is inherently not thread-safe, wrapping it within an Arc using ArcRefCellWrapper does not ensure thread safety across multiple threads. This can lead to runtime borrow panics if MQClientAPIImpl is accessed concurrently.
Recommendation:
- Replace
ArcRefCellWrapperwithArc<Mutex<_>>orArc<RwLock<_>>to provide thread-safe interior mutability.
Analysis chain
Potential thread-safety issue with ArcRefCellWrapper
At line 96, the remoting_client field now uses ArcRefCellWrapper<RocketmqDefaultClient<ClientRemotingProcessor>>. The use of RefCell inside an Arc is not thread-safe because RefCell is not Sync or Send. If MQClientAPIImpl is accessed from multiple threads, this could lead to runtime borrow panics. Consider using Arc<Mutex<_>> or Arc<RwLock<_>> for thread-safe interior mutability.
Run the following script to check if ArcRefCellWrapper implements the Send and Sync traits:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if `ArcRefCellWrapper` implements `Send` and `Sync`
# Search for implementations of `Send` and `Sync` for `ArcRefCellWrapper`
rg --type rust 'impl\s+Send\s+for\s+ArcRefCellWrapper' -A 1
rg --type rust 'impl\s+Sync\s+for\s+ArcRefCellWrapper' -A 1
Length of output: 4109
Script:
#!/bin/bash
# Description: Locate the definition of `ArcRefCellWrapper` and check for `Send` and `Sync` trait implementations or bounds
# Find the file where `ArcRefCellWrapper` is defined
fd 'struct\s+ArcRefCellWrapper' --type f --exclude-dir=node_modules | head -n1 > arc_refcell_wrapper_file.txt
# If the file is found, search within it for `Send` and `Sync` implementations
FILE=$(cat arc_refcell_wrapper_file.txt)
if [ -n "$FILE" ]; then
echo "Searching for Send and Sync implementations in $FILE"
rg 'impl\s+Send\s+for\s+ArcRefCellWrapper' "$FILE" -A 2
rg 'impl\s+Sync\s+for\s+ArcRefCellWrapper' "$FILE" -A 2
# Additionally, check for trait bounds in the struct definition
rg 'struct\s+ArcRefCellWrapper.*where\s+[^{}]*\bSend\b[^{}]*\bSync\b' "$FILE"
else
echo "ArcRefCellWrapper definition not found."
fi
Length of output: 454
Script:
#!/bin/bash
# Description: Locate the definition of `ArcRefCellWrapper` and check for `Send` and `Sync` trait implementations or bounds
# Find the file where `ArcRefCellWrapper` is defined, using the correct exclude flag
fd 'struct\s+ArcRefCellWrapper' --type f --exclude '*node_modules*' | head -n1 > arc_refcell_wrapper_file.txt
# If the file is found, search within it for `Send` and `Sync` implementations
FILE=$(cat arc_refcell_wrapper_file.txt)
if [ -n "$FILE" ]; then
echo "Searching for Send and Sync implementations in $FILE"
rg 'impl\s+Send\s+for\s+ArcRefCellWrapper' "$FILE" -A 2
rg 'impl\s+Sync\s+for\s+ArcRefCellWrapper' "$FILE" -A 2
# Additionally, check for trait bounds in the struct definition
rg 'struct\s+ArcRefCellWrapper.*where\s+[^{}]*\bSend\b[^{}]*\bSync\b' "$FILE"
else
echo "ArcRefCellWrapper definition not found. Listing all occurrences of ArcRefCellWrapper for manual inspection."
rg 'ArcRefCellWrapper' --type rust
fi
Length of output: 33991
Script:
#!/bin/bash
# Description: Locate the definition of `ArcRefCellWrapper` in `rocketmq-common` and check for `Send` and `Sync` trait implementations or bounds
# Define the specific path to `rocketmq-common/src/lib.rs`
FILE="rocketmq-common/src/lib.rs"
# Check if the file exists
if [ -f "$FILE" ]; then
echo "Searching for Send and Sync implementations in $FILE"
rg 'impl\s+Send\s+for\s+ArcRefCellWrapper' "$FILE" -A 2
rg 'impl\s+Sync\s+for\s+ArcRefCellWrapper' "$FILE" -A 2
# Additionally, check for trait bounds in the struct definition
rg 'struct\s+ArcRefCellWrapper.*where\s+[^{}]*\bSend\b[^{}]*\bSync\b' "$FILE"
else
echo "$FILE not found. Please verify the path or ensure `rocketmq-common` is included in the search."
fi
Length of output: 483
Which Issue(s) This PR Fixes(Closes)
Fixes #994
Brief Description
How Did You Test This Change?
Summary by CodeRabbit
New Features
broker_out_apiandremoting_clientacross various components, improving lifecycle handling and concurrency.Bug Fixes
startmethod of theRemotingService, ensuring that operations only occur if the weak reference is valid.Documentation
ArcRefCellWrapperand weak references.