You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the timer wheel implementation of delay message, we've reserved a cancellation ability: recalling scheduled messages by sending a corresponding delete message. However, we have not exposed an API to the upper layer. Some developers may construct and send a special message to achieve this, but this is not a friendly and sustainable solution because:
There is no clear API semantics.
It depends on internal implementation details and may become invalid due to system updates.
Sending and recalling are probably not in the same context, but the required information needs to be saved and depends on the details at the time of sending.
Grpc is not supported.
Therefore, the first step is to provide a user-friendly API to implement this feature.
A new rpc request and processor.
Client side API definition: recallMessage(topic, handle), recall handle from sending result is a bit like ReceiptHandle, containing information such as ID, broker, and timestamp.
Still based on time wheel, only support delay message for now, and perform limited parameter validation in the internal implementation, that is
can not accurately determine whether the message truly exists
recall may fail when it's too close to the delivery time
Regard the recall operation as a PUB operation for authorization.
Support Remoting and Grpc protocol, proxy and proxy-less mode.
Describe Alternatives You've Considered
.
Additional Context
.
The text was updated successfully, but these errors were encountered:
Is Your Feature Request Related to a Problem?
.
Describe the Solution You'd Like
As the timer wheel implementation of delay message, we've reserved a cancellation ability: recalling scheduled messages by sending a corresponding delete message. However, we have not exposed an API to the upper layer. Some developers may construct and send a special message to achieve this, but this is not a friendly and sustainable solution because:
Therefore, the first step is to provide a user-friendly API to implement this feature.
recallMessage(topic, handle)
, recall handle from sending result is a bit like ReceiptHandle, containing information such as ID, broker, and timestamp.Describe Alternatives You've Considered
.
Additional Context
.
The text was updated successfully, but these errors were encountered: