CLI interface for the consumer

[fancywriter]

See no reason why do I need SBT to actually use it. Some people may want to use it and they don't have anything like SBT or Scala SDK or even JDK preinstalled. I assume they have JRE.

Expected behaviour:

To have ability to build executable jar and to provide configuration from command line. Something like

java -jar rabbit-consumer.jar --ip 127.0.0.1 --port 5672 ... 

Actual behaviour:

Have to modify source, run SBT and invoke Scala code directly.

What do you think?

[rodoherty1]

Great suggestion! You're absolutely right! Even I would find that more useful than starting up sbt in order to use it.

[fancywriter]

Oh, realising that it duplicates (not in 100%) the existing #32
Easier to do altogether.

[fancywriter]

@rodoherty1 @ainulhabib I have reviewed implementation once again and now I don't understand the real use case for this tool. And it actually stops me from finishing my improvements. Could you explain it to me?
Architecture of RabbitMQ is the following: we have exchanges, queues and bindings (based on routing key). Producer can write message to the exchange, router can route it from this exchange based on bindings based on routing key which is sent together with the message.

I see that application creates it's own queue (based on configuration file, but would be better to use random name) and binds existing exchange to this queue, read all messages and unbinds and delete the queue.

This doesn't really make sense to me because if I understand RabbitMQ correctly, all messages which come to the rabbitMQ are already routed and stored in queues... and I can read them from there only once (to consume). If I create special queue, I have to wait for some time so producers can write something... so may be this application has to be interactive? We start it (it creates queue and bindings) and wait for some time, than stop it (by timeout or manually), it finishes, releases all resources, deletes queue, bindings and close connections.

Am I right?

[rodoherty1]

An excellent question!

This was the first project we opensourced. We opensourced this tool because we needed something meaningless to prove out our process for opensourcing.

RabbitConsumer began life in 2016 as a simplistic sbt-driven tool. It helped me read large messages that were sent to an Exchange.

Over time, I removed some hardcoded configuration info and added a simple configuration management mechanism.

So, "what is the usecase for the RabbitConsumer" ...

I occasionally need to capture messages which are sent to a RabbitExchange and write them to a local file.

There are two features that I like:

1. My output file is updated when I run R.read("myConf"). This allows me to control when the file is updated and therfore prevents accidental flooding of the file.
2. The output file is always valid json.

One aspect that I do not like is that it is built on an old build of scalaz stream. I'm sure there are nicer libraries available today.

I would welcome any changes at all to the codebase as long as I can still use this tool to capture messages sent to a RabbitExchange in a file which is valid json.