Support for persistent messages

[behrad]

Can persistent option be added here https://github.com/senecajs/seneca-amqp-transport/blob/develop/lib/client/publisher.js#L31 to support for durable micro-service messaging?

That would be very nice, since I've not seen any other seneca plugin to support that. Does any?

[nfantone]

@behrad Not a bad idea at all. Many thanks for the suggestion.

Will work on it now and keep you posted!

[nfantone]

@behrad Would you like to try the feature out before releasing? Here: #96

Let me know about your feedback.

[behrad]

Great to hear from you. I'll give it a try 👍

it suddenly came to my mind, for persistent messages to work, queue should not be exclusive if I'm right.
Is queue's exclusive-ness configurable, as documentation states otherwise.

another question, have you got any number performance wise? pub/sec? consume/sec?

[nfantone]

@behrad Thank you very much, indeed.

Is queue's exclusive-ness configurable, as documentation states otherwise.

Queues' declaration parameters are completely configurable. "exclusive": true is the default value, but you may change that by supplying a client.queues.optionsor listener.queues.options argument via .use() or .client()/.listen() methods.

{
      // ...
      "queues": {
        "prefix": "seneca.act",
        "separator": ".",
        "options": {
          "autoDelete": true,
          "exclusive": true, // <-- This is what you are interested in
          "arguments": {
            "x-dead-letter-exchange": "seneca.dlx",
            "x-message-ttl": 10000
          }
        }
      }
}

another question, have you got any number performance wise? pub/sec? consume/sec?

Those greatly depend on your specs and your broker's current load/capacity. They are not hard to come by: run a few of the /examples and produce some numbers. They'll serve as a hint, but will be largely artificial, mind you. I know it's a no-brainer, but best way would be to run it in your production env and crunch the actual values.

[nfantone]

@behrad So, did you get a chance to try the PR? Or shall I merge regardless?

[nfantone]

Added in v2.2.0.

[behrad]

so busy these days @nfantone
What about I test the merged release, and let you know if any issues?

[behrad]

👍 thank you man

[behrad]

I tested 2.2.0 @nfantone and it looks great, however I've two main concerns:

1. Seneca client'a act is timed out when consumer is not running (the message will persist and be consumed by seneca listener later). In this case, can we increase act timeout to hours? minutes? to have a complete REQ/REP model?
   Related to the above, let me ask a general Senecajs question:
   Can seneca support a non req/rep model? like workers or pub/sub, ...? I mean a case where act is not looking for a reply callback.

2. I benchmarked a Seneca mesh act as around 20ms in on the loopback address.
   and Seneca amqp is around 45ms. Numbers look poor to me. Am i missing something?

[nfantone]

@behrad For point number one, please take a look at this issue.

Regarding your second point, I'm not familiar with seneca-mesh but, from what I saw, it's using HTTP as its default transport. Running HTTP on local LAN would beat queuing messages in an AMQP broker any day. Plus, persistence messages and queues with confirms are particularly slow in RabbitMQ (see this also).