Currently for asynchronous subscribers, they must implement MessageReceiver ...
Current interface ...
public interface MessageReceiver {
void receiveMessage(final PubsubMessage message, final AckReplyConsumer consumer);
}
The decoupling of PubsubMessage and AckReplyConsumer for this interface provides no benefit to developers and requires another object to contain both AckReplyConsumer and PubsubMessage for easy processing, etc.
New interface ...
public interface MessageReceiver {
void receiveMessage(final PubsubMessage message);
}
AckReplyConsumer then can be retrieved from a PubsubMessage via a new method getAckReplyConsumer().
This provides a cleaner interface contract and allows a developer to dispatch the PubsubMessage to various handler methods as a single object.
An an even cleaner alternative would be to add the ack() and nack() methods to the PubsubMessage and remove the AckReplyConsumer altogether, which is the approach that spring-cloud-gcp has taken.
Currently for asynchronous subscribers, they must implement
MessageReceiver...Current interface ...
The decoupling of
PubsubMessageandAckReplyConsumerfor this interface provides no benefit to developers and requires another object to contain bothAckReplyConsumerandPubsubMessagefor easy processing, etc.New interface ...
AckReplyConsumerthen can be retrieved from aPubsubMessagevia a new methodgetAckReplyConsumer().This provides a cleaner interface contract and allows a developer to dispatch the
PubsubMessageto various handler methods as a single object.An an even cleaner alternative would be to add the
ack()andnack()methods to thePubsubMessageand remove theAckReplyConsumeraltogether, which is the approach thatspring-cloud-gcphas taken.