apurtell commented on PR #2144:
URL: https://github.com/apache/phoenix/pull/2144#issuecomment-2899326434
To aid in your review I asked Gemini to summarize this patch:
**Summary of Changes in PHOENIX-7567**
1. **`ReplicationLog` Class (New):**
* **Singleton Pattern:** Implements a singleton pattern (`get` method)
to manage a single `ReplicationLog` instance per server.
* **Configuration:** Reads various configuration parameters related to
log rotation (time, size), HDFS URLs (standby, fallback), sharding, ring buffer
size, and sync timeouts.
* **FileSystem Initialization:** Initializes `FileSystem` objects for
both standby and fallback HDFS URLs. Creates the necessary base directories if
they don't exist.
* **Sharding:** Implements logic to create sharded subdirectories
under the main log directory. The shard is determined by a hash of the server
name and the current timestamp to distribute logs.
* **Log Rotation:**
* Manages the current `LogFileWriter` instance.
* Implements `shouldRotate()` to check time and size-based
rotation triggers.
* Implements `rotateLog()` to close the current writer and open a
new one. This method is reentrant lock protected.
* Uses a `ScheduledExecutorService` (`rotationExecutor`) to
periodically check for time-based rotation via `LogRotationTask`.
* **Disruptor Integration:**
* Initializes an LMAX Disruptor (`disruptor` and `ringBuffer`)
with a configurable ring buffer size, using `ProducerType.MULTI` and
`YieldingWaitStrategy`.
* Defines an inner `LogEvent` class to represent data and sync
operations in the ring buffer.
* Defines an inner `LogEventHandler` to process events from the
Disruptor. This handler is responsible for:
* Getting the current `LogFileWriter`.
* Handling writer rotation: If the writer's generation has
changed (indicating a rotation), it replays the `currentBatch` of in-flight
appends to the new writer.
* Appending data events to the writer and adding them to
`currentBatch`.
* Processing sync events by calling `writer.sync()`, clearing
`currentBatch`, and completing the associated `CompletableFuture`.
* Basic retry logic for `append` and `sync` operations: if an
`IOException` occurs, it forces a log rotation and retries the operation on the
new writer up to `maxRetries`.
* Defines an inner `LogExceptionHandler` to handle critical errors
in the Disruptor lifecycle by calling `closeOnError()`.
* **`append()` Method:** Publishes a data event (mutation) to the
Disruptor's ring buffer. This method is non-blocking unless the ring buffer is
full.
* **`sync()` Method:** Publishes a sync event to the Disruptor's ring
buffer and blocks (using `CompletableFuture.get()`) until the `LogEventHandler`
processes this event and completes the future. Implements a timeout for the
sync operation.
* **`close()` and `closeOnError()` Methods:** Handle graceful shutdown
and error-induced shutdown of the Disruptor and writers.
* **Replication Mode:** Introduces a `ReplicationMode` enum (SYNC,
STORE_AND_FORWARD, SYNC_AND_FORWARD) and a `currentMode` field, though the
store-and-forward logic is not yet implemented (marked as TODO).
* **Dependencies:** Adds `com.lmax:disruptor` as a dependency in
`phoenix-core-server/pom.xml`.
2. **`LogFileWriter` Class (Modified):**
* Adds a `generation` field (long) and corresponding getter/setter.
This generation number is incremented by `ReplicationLog` each time a new
writer is created (during rotation or initialization). The `LogEventHandler`
uses this to detect if the writer it holds is stale due to a rotation.
3. **New Package:** Introduces `org.apache.phoenix.replication` package.
**Alignment with the Design Document**
* **Replication Log Writer (High-Level):** The `ReplicationLog` class is
the high-level "Replication Log Writer" component. It orchestrates log
creation, rotation, and the asynchronous writing of records via the Disruptor.
* **LMAX Disruptor:** The design explicitly mentions leveraging the LMAX
Disruptor for its ring buffer implementation to decouple producers from the
writer and handle batching. This is directly implemented.
* **Log File Management (Rotation):** The time-based and size-based log
rotation mechanisms are implemented as described.
* **Synchronous Writes (Foundation):** The `append()` method itself is
fast (publishes to ring buffer), but the `sync()` method provides the
synchronous guarantee by blocking until the `LogEventHandler` confirms the
underlying `LogFileWriter` has synced. This is the core of the "synchronous
replication" part.
* **Error Handling (Initial):** The `LogEventHandler` includes basic retry
logic for `append` and `sync` by attempting to roll the writer. The
`LogExceptionHandler` provides a mechanism to shut down on critical Disruptor
errors.
* **Replication Mode (Placeholder):** The `ReplicationMode` enum and
`currentMode` field are introduced, laying the groundwork for future
implementation of store-and-forward logic.
* **Sharding:** The sharding mechanism based on server name and timestamp
hash is implemented for distributing log files.
**How this Diff Builds Upon PHOENIX-7565.**
* PHOENIX-7565 focused on the *format* of the log files (headers, blocks,
trailers, records) and the low-level I/O classes (`LogFileFormatWriter/Reader`,
`LogFileCodec`, stream adapters).
* PHOENIX-7567 builds *on top* of that by creating the `ReplicationLog`
class, which is the *manager* or *orchestrator* that uses the `LogFileWriter`
(and by extension, the format writer and codec) to actually write data.
* It introduces the asynchronous processing pipeline using LMAX Disruptor,
which was a key part of the "Replication Log Writer" component's internal
design for high throughput and low latency appends.
* It implements the logic for log rotation, which is essential for
managing log file lifecycle.
* It provides the `sync()` mechanism that gives the synchronous guarantee
to the callers (e.g., the coprocessor hooks).
--
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]
