https://github.com/itv/bucky

A lightweight Scala AMQP client
https://github.com/itv/bucky

amqp messaging scala

Last synced: 20 days ago
JSON representation

A lightweight Scala AMQP client

• Host: GitHub
• URL: https://github.com/itv/bucky
• Owner: ITV
• License: other
• Created: 2016-04-01T16:13:09.000Z (over 8 years ago)
• Default Branch: master
• Last Pushed: 2024-07-11T07:55:40.000Z (4 months ago)
• Last Synced: 2024-07-11T15:06:32.035Z (4 months ago)
• Topics: amqp, messaging, scala
• Language: Scala
• Homepage: https://io.itv.com/bucky
• Size: 1.21 MB
• Stars: 11
• Watchers: 44
• Forks: 10
• Open Issues: 4
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
![Cats Friendly Badge](https://typelevel.org/cats/img/cats-badge-tiny.png) 

(under construction: [v1 docs](https://github.com/ITV/bucky/tree/v1.4.5), [v2 docs](https://io.itv.com/bucky/))

    

# Migrating to 2.0.0-M28 and above

Version 2.0.0-M28 introduced a change to default all dead letter exchanges to be Fanout by default. Previously these were Direct.

The reason for this change is due to an issue when multiple queues are bound to the same routing key on the same exchange and vice versa.

When a handler dead letters a message it will be lost into the Ether as the broker can't work out where to send it.

To upgrade:

 - The signature of `requeueDeclarations` has changed. Try to use the new default dlx exchange type where possible.

 - If changing the dlx type, delete the `.requeue`, `.dlx` and `.redeliver` exchanges manually before deploying your newly upgraded service.

 If you don't do this, the service will fail to start complaining about mismatching Exchange types.

If you really must continue using a Direct exchange:

 - If using Wiring, use `setDeadLetterExchangeType = ExchangeType.Direct`

 - If using requeueDeclarations, you will need to pass in `dlxType=Direct`.

# Migrating to 2.0.0-M30 and above

Version 2.0.0-M30 introduced a change to the `Wiring` module where, if a requeue policy is being explicitly set, the `retryAfter` value is

passed into the `x-message-ttl` parameter of the requeue queue, which previously defaulted to 5 minutes. 

This means that the `retryAfter` value being declared will be respected.

In this scenario, as the queue policy is being changed, it may need to the requeue queue to be manually deleted so that the application can recreate it. The application may fail to start up otherwise.

# Releasing a new version

1. Merge your change into master

2. perform an `sbt release` setting the new version when prompted

3. Release in sonatype