EventHorizon.RocketMQ.Remoting 0.6.1

Behavior

• Align classic orderly PULL retry lifecycle with the official Apache RocketMQ Java rocketmq-all-5.5.0 release.
• Add OrderlyMaxReconsumeTimes, defaulting to -1 for effectively unlimited local orderly reconsumes. 0 publishes after the initial failure; a positive value permits that many local reconsumes.
• Expose the zero-based mutable RemotingMessageView.ReconsumeTimes used by Java orderly consumption while preserving the immutable one-based Broker DeliveryAttempt.
• At finite exhaustion, publish to %RETRY%<group> through internal producer semantics with origin, retry, reconsume, maximum, delay, flag, and body metadata. The Broker performs the DLQ redirect when the supplied count exceeds the maximum.
• Retry terminal publication up to three immediate wire sends, select an alternate Broker when possible, and fall back to the default topic route when the retry-topic route is missing or unwritable. A failed publication retains the message and offset for another local attempt.
• Record the terminal retry-topic publication as one logical reject settlement operation without changing concurrent PULL, POP, or MessageGroup behavior.

Compatibility

This patch adds protocol-specific public members and changes the default orderly retry budget from the previous finite client limit to the released Java unlimited sentinel. Configure OrderlyMaxReconsumeTimes explicitly when finite orderly exhaustion and Broker DLQ routing are required.

Validation

• Audited against the official stable Java rocketmq-all-5.5.0 tag; released Go v2.1.2 was used only as secondary corroboration.
• PR and merged-main CI passed formatting, build, 638 Remoting unit tests, 27 compatibility tests, runtime validation, Codecov, and all single-/multi-Broker Docker integration suites.
• Focused live DLQ coverage fails the initial delivery and one retry before verifying Broker-routed DLQ progression.

Full change: PR #28

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Remoting/0.6.1

EventHorizon.RocketMQ.Remoting 0.6.0

Behavior

• Add RemotingPushConsumeContext.SuspendCurrentQueueDuration for orderly PULL consumption, matching Apache RocketMQ Java rocketmq-all-5.5.0.
• Add RemotingPushConsumerOptions.OrderlySuspendDuration, defaulting to one second. Effective orderly suspension is limited to 10 milliseconds through 30 seconds.
• An orderly retry pauses only its current physical queue. Other assigned queues continue, and stopping the consumer cancels the local wait promptly.
• Preserve a duration override assigned before a handler throws, then retry the same orderly message with that duration.
• At the configured terminal attempt, both clustered and broadcasting orderly consumers send the message back to DLQ. The offset advances only after send-back succeeds; settlement failure retains the message and offset for another local attempt.
• Concurrent broadcasting, concurrent PULL, MessageGroup FIFO, and POP retain their separate released-Java semantics.

Validation

• Rechecked the official rocketmq-all-5.5.0 GitHub release as non-draft and non-prerelease; stable Go v2.1.2 was used only as secondary Remoting corroboration.
• PR CI passed formatting, build, all unit and .NET 8 checks, Codecov, and all four single-/multi-Broker Docker integration suites.
• Focused live Remoting coverage verifies explicit negative DLQ, concurrent and MessageGroup retry exhaustion, and clustered/broadcasting orderly retry exhaustion. Retry-exhaustion cases fail the initial attempt and one retry before DLQ progression.

The remaining orderly retry-budget and attempt-visibility difference from released Java is tracked in #25.

Full change: PR #27

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Remoting/0.6.0

EventHorizon.RocketMQ.Grpc 0.4.1

Behavior

• Align completion-RPC retry lifetime with the official Apache RocketMQ Java java-5.2.1 release.
• Retry every failed acknowledgement, retry/NACK, invisibility change, suspension, and client dead-letter forwarding wire operation at a fixed one-second interval until it succeeds, the caller cancels, or the owning Consumer stops.
• Treat INVALID_RECEIPT_HANDLE as terminal for acknowledgement and invisibility changes, where the same stale receipt cannot settle the message. Dead-letter forwarding continues retrying that status in line with Java.
• Give every wire attempt its own settlement Activity and metric so extended Proxy failures remain observable.
• Keep a FIFO successor blocked while completion retry is active, then release it after a terminal completion failure while leaving the failed message unsettled for possible redelivery.
• Tie pending completion retries to Consumer lifecycle cancellation so shutdown does not leave unbounded background work.

Validation

• Audited against the official stable Java java-5.2.1 tag.
• PR and merged-main CI passed formatting, build, 232 gRPC unit tests, 27 compatibility tests, runtime validation, Codecov, and all single-/multi-Broker Docker integration suites.
• Focused live DLQ coverage verifies regular Push and LitePush FIFO/non-FIFO progression with an initial failure and one retry before DLQ.

This release closes the remaining stable-Java retry differences tracked in #25.

Full change: PR #28

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Grpc/0.4.1

EventHorizon.RocketMQ.Grpc 0.4.0

Behavior

• Add the released Java java-5.2.1 duration-carrying consume result. ConsumeResult is now a sealed record with Success, Failure, and Suspend(TimeSpan); suspend durations must be at least 50 milliseconds.
• Keep non-FIFO retry/DLQ progression service-owned for both regular Push and LitePush. Regular Push normalizes Suspend to Failure; non-FIFO LitePush ignores the requested Suspend duration and uses the same retry-policy NACK path as Failure.
• Keep FIFO Failure progression client-owned for regular Push and LitePush: retry the handler locally, then attempt DLQ forwarding after the effective attempt limit.
• FIFO LitePush applies Suspend(duration) through ChangeInvisibleDuration with suspend=true and suspends unprocessed same-LiteTopic siblings from the current receive batch without invoking them.
• Preserve FIFO when optional grouping metadata is absent by using the authoritative subscription setting and a physical-queue fallback key.
• Record retry-policy settlement as nack and FIFO caller-duration suspension as suspend. Failed completion remains unresolved and can be redelivered.

Compatibility

This is an intentional pre-1.0 breaking API change. ConsumeResult is no longer an enum. Existing returns of ConsumeResult.Success and ConsumeResult.Failure remain straightforward, but enum switches and APIs that require an enum must be updated for the sealed-record result shape.

Validation

• Rechecked the official java-5.2.1 GitHub release as non-draft and non-prerelease and audited LitePushConsumerImpl, ProcessQueueImpl, and FifoConsumeService at that tag.
• PR CI passed formatting, build, all unit and .NET 8 checks, Codecov, and all four single-/multi-Broker Docker integration suites.
• Focused live coverage verifies regular FIFO/non-FIFO DLQ, Lite FIFO/non-FIFO DLQ, and FIFO Lite Suspend timing and receipt replacement. Retry-exhaustion cases fail the initial attempt and one retry before DLQ progression.

Two remaining intentional differences from released Java are tracked in #25, including the bounded completion-RPC retry lifetime.

Full change: PR #27

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Grpc/0.4.0

EventHorizon.RocketMQ.Remoting 0.5.0

Behavior

• Align broker-assigned POP failure settlement with Apache RocketMQ Java rocketmq-all-5.5.0.
• A negative RemotingPushConsumeContext.DelayLevelWhenNextConsume is now normalized to POP retry level 0; POP changes message invisibility and no longer performs classic direct-DLQ send-back followed by receipt ACK.
• Internal PULL behavior is unchanged: a negative delay remains an explicit direct-DLQ request, and retry-policy exhaustion still sends the message to DLQ.
• POP maximum-attempt handling remains Java-compatible and age-based: defer while the message is too young, then ACK after the terminal age threshold, without implicit DLQ forwarding.

Validation

• Added live Remoting DLQ coverage for concurrent PULL, MessageGroup, and orderly consumption. Retry-policy cases invoke the handler twice: the initial failure, one retry, then DLQ.
• Added live gRPC FIFO Push, non-FIFO Push, and LitePush DLQ coverage with the same one-retry boundary. No new gRPC package is published by this release.
• PR CI passed format/build, all unit and .NET 8 checks, Codecov, and all four single-/multi-Broker Docker integration suites.

Compatibility

The primary released references are Java Remoting rocketmq-all-5.5.0 and Java gRPC java-5.2.1; released Go clients v2.1.2 and golang/v5.1.2 are secondary comparisons.

This is a pre-1.0 behavior change for applications that used a negative delay to force direct DLQ while the internal Push assignment selected POP. Such POP deliveries now follow the official Java retry path. The remaining released-Java SUSPEND differences are tracked in #25.

Full change: PR #26

EventHorizon.RocketMQ.Remoting 0.4.0

Breaking change

• Removes the public ConsumeResult.DeadLetter member.
• To request direct dead-lettering from a concurrent non-FIFO Remoting handler, set RemotingPushConsumeContext.DelayLevelWhenNextConsume to a negative value and return ConsumeResult.Retry.
• Code compiled against 0.3.x that returns ConsumeResult.DeadLetter must be updated before upgrading.

Consumer behavior

• Aligns the public Remoting consume-result contract with the official Apache RocketMQ Java and classic Go concurrent-consumer APIs: Success or Retry only.
• Preserves classic PULL direct dead-lettering through a negative delay level.
• Preserves the explicit POP direct-dead-letter extension: the client forwards the message and ACKs the POP receipt only after forwarding succeeds.
• Keeps MessageGroup FIFO and orderly retries locally serialized until success or MaxDeliveryAttempts; their handlers do not use the concurrent consume context.
• Keeps handler exceptions on the normal retry path rather than introducing a separate dead-letter result.
• Updates protocol documentation, XML API documentation, samples, telemetry descriptions, compatibility tests, and live Broker coverage.

Known differences

Duration-carrying Suspend behavior and the remaining Java/Go settlement differences are tracked in #25:

#25

Package

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Remoting/0.4.0

EventHorizon.RocketMQ.Remoting 0.3.1

Fixes

• Aligns Broker-assigned classic POP terminal retry handling with Apache RocketMQ Java: after MaxDeliveryAttempts, retry uses message age to select the next POP invisibility delay and ACKs only after the age exceeds the four-hour terminal threshold.
• Prevents normal POP retries at the delivery limit from being implicitly forwarded to the dead-letter queue. Explicit ConsumeResult.DeadLetter and negative delay requests remain supported.
• Documents clustering retry-topic behavior: the consumer automatically subscribes to %RETRY%{consumerGroup}, advertises it in heartbeats, and consumes Broker assignments in PULL mode.
• Expands unit and live Broker coverage for age-based retry, terminal ACK, and the absence of reject/send-back operations.

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Remoting/0.3.1

EventHorizon.RocketMQ.Remoting 0.3.0

Highlights

• Consolidates classic PULL and POP receive engines behind IRemotingPushConsumer. Queue assignment and receive mode are now modeled separately: client assignment uses PULL, while Broker assignment follows each server-returned PULL or POP assignment.
• Adds RemotingPushQueueAssignmentMode and the QueueAssignmentMode option. Client remains the default; applications keep the same Push handler when Broker assignment selects POP.
• Reorganizes the Consumer implementation around explicit coordination, assignment, receive, processing, settlement, offset, and lifecycle ownership.
• Fixes Broker-assigned retry coordination, current-Broker resolution for POP settlement, orderly queue unlock during shutdown, LitePull shutdown positions, and Push receiver shutdown ownership.
• Expands live coverage for PULL/POP workflows, multiple Brokers, multiple NameServers, failover, cross-process coordination, retries, blocked queues, and persistence.
• Documents the fixed Remoting POP invisibility deadline: unlike gRPC Push, classic Remoting Push does not automatically renew an active POP receipt.

Breaking changes

• Removes the standalone public IRemotingPopConsumer API. Configure Broker queue assignment on IRemotingPushConsumer; the Broker selects PULL or POP for each assignment.
• Removes the low-level public IRemotingPullConsumer API. Use IRemotingLitePullConsumer for application-driven polling or IRemotingPushConsumer for callback-driven consumption.
• Replaces the previous Push assignment option with RemotingPushQueueAssignmentMode and RemotingPushConsumerOptions.QueueAssignmentMode.
• Moves LitePull types to the EventHorizon.RocketMQ.Remoting.Consumer.LitePull namespace.

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Remoting/0.3.0

EventHorizon.RocketMQ.Grpc 0.3.0

Feature release aligning the RocketMQ 5 gRPC consumer model with the Apache Java client.

• Push and LitePush now rely on Proxy-managed AutoRenew receipt renewal instead of running a duplicate client timer.
• Consumption handlers now return ConsumeResult.Success or ConsumeResult.Failure, matching the official Java API.
• SimpleConsumer no longer exposes direct dead-letter forwarding; retry and DLQ progression remain service-owned, with FIFO forwarding kept internal.
• The LitePush public namespace moves from EventHorizon.RocketMQ.Grpc.Consumer.Lite to .Consumer.LitePush.
• OpenTelemetry distinguishes explicit SimpleConsumer lease renewal (renew) from Push retry scheduling (nack).

Breaking changes: replace ConsumeResult.Retry with Failure, remove ConsumeResult.DeadLetter and IGrpcSimpleConsumer.ForwardToDeadLetterQueueAsync, and update LitePush namespace imports.

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Grpc/0.3.0

EventHorizon.RocketMQ.Remoting 0.2.0

Feature release for the protocol-specific Apache RocketMQ classic Remoting client.

• Register multiple independently configured Consumers under one AddRocketMQRemoting registration with group-safe physical-client sharing.
• Add Broker-notification Rebalance coordination, same-group connection isolation, heartbeat ownership, and cross-process integration coverage.
• LitePull now unregisters Broker membership immediately when AssignAsync([]) clears a manual assignment.
• 0.2.0 intentionally removes delegate-based MessageHandler options and non-generic Push registration. Migrate handlers to typed DI implementations of IRemotingPushMessageHandler; use Scoped when application dependencies are scoped.

NuGet: https://www.nuget.org/packages/EventHorizon.RocketMQ.Remoting/0.2.0