Package org.acemq.amqp.api

Interface ClaimCheckStore

All Known Implementing Classes:
FilesystemClaimCheckStore, InMemoryClaimCheckStore
public interface ClaimCheckStore
Where a payload too large for a broker actually goes.

Three methods, so a store backed by S3, Azure Blob Storage, a filesystem or a database table is a small class. Nothing here knows about messaging: the store holds bytes under a key and hands them back, and the codec is what turns that into a claim check on the wire.

Retention is the part that goes wrong

The store and the queue have different lifetimes, and nothing enforces a relationship between them. A message replayed a month later carries a key, and if the store expired that key the replay produces a message nobody can read — worse than a lost message, because it looks like a message and fails deep inside a consumer rather than visibly.

So the store's retention must exceed every retention that could bring a message back: queue TTLs, dead-letter queues, and however long somebody might sit on a message before replaying it by hand. When in doubt, longer.

Implementation Requirements:
implementations must be safe for use by several threads, because one is shared by every publisher and consumer on a connection.

  • Method Summary

    Modifier and Type
    Method
    Description
    void
    delete(String key)
    Removes a payload.
    Optional<byte[]>
    get(String key)
    Redeems a claim check.
    String
    put(byte[] content)
    Stores a payload.

  • Method Details

    • put

      String put(byte[] content)
      Stores a payload.
      Parameters:
      content - the bytes
      Returns:
      the key the message will carry, which must be unique for the life of the store

    • get

      Optional<byte[]> get(String key)
      Redeems a claim check.
      Parameters:
      key - what the message carried
      Returns:
      the payload, or empty when the store no longer holds it — which is retention having expired underneath a message that outlived it

    • delete

      void delete(String key)
      Removes a payload.

      Not called by the codec. Deleting on read would break the second consumer of the same message, and deleting on acknowledgement would break a replay — so when a payload may be removed is a retention decision, and retention decisions belong to whoever owns the data.

      Parameters:
      key - what to remove