guyinyou opened a new issue, #10031:
URL: https://github.com/apache/rocketmq/issues/10031
### Before Creating the Enhancement Request
- [x] I have confirmed that this should be classified as an enhancement
rather than a bug/feature.
### Summary
Add a PreprocessHandler interface to AllocateMappedFileService that allows
external extensions to execute custom logic before MappedFile allocation. This
enables enhancements such as observability, performance optimization, and file
reuse strategies without modifying core allocation logic.
### Motivation
Currently, the MappedFile allocation process in AllocateMappedFileService is
fixed and cannot be extended. This limits the ability to:
1. **Enhanced Observability**: Monitor and collect metrics during file
allocation (e.g., allocation latency, file size distribution)
2. **Performance Optimization**: Implement custom pre-allocation strategies,
file warming, or caching mechanisms
3. **File Reuse**: Enable recycling and reuse of existing files to reduce
I/O overhead
4. **Custom Strategies**: Apply different allocation logic based on file
paths, sizes, or other conditions
This enhancement would benefit the community by providing a clean extension
point for advanced use cases while maintaining backward compatibility.
### Describe the Solution You'd Like
Add a functional interface `PreprocessHandler` as a public inner interface
of `AllocateMappedFileService`:
ava
@FunctionalInterface
public interface PreprocessHandler {
void preprocess(String nextFilePath, String nextNextFilePath, int
fileSize);
}
Add a setPreprocessHandler(PreprocessHandler) method to allow external code
to register a preprocess handler. The handler will be invoked at the beginning
of putRequestAndReturnMappedFile() method before the actual allocation logic
executes.
Implementation details:
The handler execution is wrapped in try-catch to ensure exceptions don't
break the allocation flow
Use final variable to avoid concurrency issues
Handler is optional - if not set, behavior remains unchanged (backward
compatible)
### Describe Alternatives You've Considered
Subclassing AllocateMappedFileService: This would require exposing internal
methods and break encapsulation. The interface approach is cleaner and more
flexible.
Event-based system: Creating a full event system would be overkill for this
use case and add unnecessary complexity.
Configuration-based approach: Hard-coding specific behaviors in
configuration would be less flexible than allowing runtime extension via
interface.
Modifying core allocation logic directly: This would make the code harder to
maintain and prevent users from customizing behavior without forking the
project.
The interface-based approach provides the best balance of flexibility,
simplicity, and maintainability.
### Additional Context
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
