Feature: Reuse publish configuration rather than rebuilding constantly

[LordMike]

I've got a few setups running and messaging, and so far I'm liking RawRabbit.. It makes sense now :).

I'm a little bit worried about the fluent construction of options on every publish operation (I assume Request and other operations are similar). I know from past experience that constructing and calling a delegate / Func/Action produces garbage in memory that needs to be collected at some point. If I were to send thousands of messages, I would perform thousands of these operations that essentially produce the same configuration in the end (same queue, same exchange, same whatever ..).

Is it possible to re-use the produced configuration after the fluent setup?

If it were possible to produce the configuration object up front (using the fluent DSL), I could then provide this configuration object back to the operations (an overload to the current method), and avoid re-running the same configuration code again and again.

[pardahlman]

Hi, @LordMike - thanks for reaching out. Not sure if your on 1.x or 2.x, but there are a few options available for you:

• Register custom INamingConventions and update default topology features in RawRabbitConfiguration. This should be enough if have a consistent naming schema and preferences for topology features
• Use the attribute plugin that lets you set attributes for each message.
• If you're on 2.x, you could look at the configuration middlewares - all they do is apply the fluent configuration language and add a configuration object that will be reused throughout the execution. It should be possible to create this object outside of RawRabbit and pass it to the execution context when calling PublishAsync (and other methods).

Hope this helps!

[LordMike]

I'm running 2.x, and in my case I'll have somewhere around 1.500 queues with the same object types - so naming conventions and the likes won't work that way around - for return data, it might work though. I'll look at configuration middlewares.

In my current design, I need the 1.500 queues as I want to let each of my workers take one item from each queue, concurrently - but at most one item at a time from a given queue (they're 1.500 different services that each impose rate limits)

[pardahlman]

I believe that you can achieve round-robin worker distribution using one queue with multiple consumers (a scenario that RawRabbit supports out of the box). Not sure if that helps in your scenario, but just wanted to let you know.