@RunLLM Bookie handle is not available error code: -8

The error "Bookie handle is not available" with error code -8 indicates that a BookKeeper client or broker cannot connect to a bookie, either because the bookie is down, removed, or not running. This is represented by

BKException.Code.BookieHandleNotAvailableException

in BookKeeper and typically means the bookie is unreachable or has been decommissioned, leading to failed read or write operations on ledgers that reference it. For more details, see the BookKeeper BKException.java source. Would you like more detail on troubleshooting or handling this error? Sources: - BookKeeper BKException.java source 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM cursorLedger is set to -1

When

cursorLedger

is set to -1, it means the cursor does not currently have an associated ledger for persisting its state. This typically happens when the cursor is first created or after closing and before a new ledger is assigned for metadata persistence. The value -1 is used as a sentinel to indicate "no ledger" or "uninitialized" state, as seen in the ManagedCursorImpl source code. Would you like more detail on when and why this value changes? Sources: - ManagedCursorImpl.java 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM more details

When a Pulsar subscription cursor is created or after it closes its current metadata ledger, the

cursorLedger

field is set to -1. This value acts as a sentinel, indicating that there is no active ledger for persisting the cursor's state (such as mark-delete position and properties). The cursor remains in this "NoLedger" state until an acknowledgment or other operation triggers the creation of a new ledger for metadata persistence. For example, in the ManagedCursorImpl.java, during recovery or initialization, if no cursor ledger exists, the code sets

cursorLedger = -1L

. The cursor ledger is only created when necessary (e.g., on the first message acknowledgment), which improves performance and resource usage, especially when there are many topics and subscriptions. This lazy creation is described in this PR. The transition of

cursorLedger

from -1 to a valid ledger ID occurs when the cursor needs to persist its state (such as after an ack). At that point, a new ledger is created, and the cursor's metadata is written to it. If the cursor is closed or the ledger is deleted,

cursorLedger

is reset to -1, and the process repeats as needed. Sources: - ManagedCursorImpl.java - PR: Create the cursor ledger lazily to improve the subscribe performance 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM On a working cluster the cursor ledger is set to -1

On a working Pulsar cluster, if a cursor's

cursorLedger

is set to -1, it means the cursor currently does not have an active ledger for persisting its state. This is normal if the cursor has not yet acknowledged any messages or if the previous cursor ledger was closed and a new one has not been created yet. The cursor will create a new ledger when it needs to persist state, such as after an acknowledgment, as described in ManagedCursorImpl.java and this PR. Would you like more detail on how this affects message consumption or recovery? Sources: - ManagedCursorImpl.java - PR: Create the cursor ledger lazily to improve the subscribe performance 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM Would you like more detail on how this affects message consumption or recovery?

If

cursorLedger

is -1, message consumption is not affected—consumers can still read messages as usual. However, the cursor's state (such as mark-delete position) is not persisted to BookKeeper until an acknowledgment occurs, at which point a new ledger is created. This lazy creation reduces resource usage and speeds up subscription creation, but if a broker crashes before the first ack, the cursor state may not be fully durable and could revert to the last persisted state in ZooKeeper or the initial position, as described in PR 16389. For recovery, if no cursor ledger exists (

cursorLedger = -1

), the broker will recover the cursor's position from ZooKeeper metadata, which may not include the latest unacknowledged messages if no ack has been persisted yet. Once a new ledger is created and state is persisted, future recoveries will use the ledger for more accurate restoration. Sources: - PR: Create the cursor ledger lazily to improve the subscribe performance 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM how to recovery form cursorledger -1

To recover from a

cursorLedger

value of -1, Pulsar will restore the cursor's state from ZooKeeper metadata, specifically from the last mark-delete position stored there. This is the default recovery path when no cursor ledger exists, as shown in ManagedCursorImpl.java. The cursor will resume from the last known mark-delete position, and a new cursor ledger will be created automatically when the next acknowledgment occurs. Would you like more detail on the recovery process or how to trigger ledger creation? Sources: - ManagedCursorImpl.java 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM how to trigger ledger creation

A new cursor ledger is created automatically when the consumer acknowledges a message on the subscription. This acknowledgment triggers the persistence of the cursor state, which in turn creates a new ledger if

cursorLedger

is -1, as described in ManagedCursorImpl.java and PR 16389. Would you like more detail on the acknowledgment process or code examples? Sources: - ManagedCursorImpl.java - PR: Create the cursor ledger lazily to improve the subscribe performance 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.