4.0.4

• Twino MQ Client infrastructure re-designed, now Twino MQ is able to support all protocols as messaging queue clients. AMQP or other protocol implementations are possible (and will be planned in future versions)

• Channels are removed completely

  • Queue messages now has only queue name, there is no channel name, no content type.
  • Queue initialization is lazy, you can still subscribe to non-created (actually created but not initialized) queue like version 3
  • Queues are initialized if they are created explicitly or they are created with a push message from producer. And their status and options are decided on these operations, even queue is created with a subscription before push event.
  • If you want to initialize queue via subscription operaiton, consumers should add "Queue-Status" header to subscription message, if your subscription via IQueueConsumer implementation, QueueStatus attribute can do it automatically.

• Queue properties and options are redesigned

  • Send to only first acquirer options is removed completely, you can create that workflow with routers and bindings if you really need it
  • Tag options is removed, now there is only topic option that can be used with topic binding for router messages
  • Queues now have client limits (in version that option was for channels)
  • Queue Id is removed completely, queues now have unique names, they don't need ushort id

• Acknowledge and Response messages are combined. There was a confusing architecture in old acknowledge and response message system, developers were confused when to acknowledge or when to response. With that combine, that complexity has become clear. There is only one response message type, successful results for acknowledge and successful responses for requests, failed results are for negative acknowledge or failed responses.

• Queue auto destroy option is redesigned, now there are four type auto destroy options

  • Disabled
  • Destroy if there are no consumers
  • Destroy if there are no messages
  • Destroy if there are no consumers and there are no messages

• Requesting acknowledge and waiting for ackonwledge options are redesigned. Now there is one option for queue acknowledge operations as enum. Enum values are:

  • Acknowledge is not used
  • Queue asks for acknowledge from consumer but consume operation doesn't wait the acknowledge to send next messages
  • Queue asks for acknowledge from consumer and waits until acknowledge is received or timed out. Other queue messages waits for the operation.

• Broadcast queue status is redesigned, broadcast statuses now focus to broadcasting. Acknowledge messages are not usable on broadcast status and some delivery methods are not executed. Broadcast status queues now use less resource and they have better performance.