When/how many messages should be persisted on a daily basis? Is it
reasonable to persist all messages, considering the amounts I
specified above?
JMS persistence doesn't replace a database, it should be considered a short-lived buffer between producers and consumers of data. that said, the volume/size of messages you mention won't tax the persistence adapters on any modern JMS system (configured properly anyways) and can be used to buffer messages for extended durations as necessary (just use a reliable message store architecture)
I know that persisting will decrease performance, perhaps by a lot.
But, by not persisting, a lot of RAM is being used. What would some of
you recommend?
in my experience, enabling message persistence isn't a significant performance hit and is almost always done to guarantee messages. for most applications, the processes upstream (producers) or downstream (consumers) end up being the bottlenecks (especially database I/O)...not JMS persistence stores
Also, I know that there is a lot of information online regarding
ActiveMQ (JMS) vs RabbitMQ (AMQP). I have done a ton of research and
testing. It seems like either implementation would fit my needs.
Considering the information that I provided above (file sizes and # of
messages), can anyone point out a reason(s) to use a particular vendor
that I may have missed?
I have successfully used ActiveMQ on many projects for both low and high volume messaging. I'd recommend using it along with a routing engine like Apache Camel to streamline integration and complex routing patterns
It's not related to docker, or the location of the broker at all.
It looks like you have some spurious "" around your queue name...
reply-code=404, reply-text=NOT_FOUND - no queue '"incoming"' in vhost '/'
(Note the " within the ').
What is in this property ep.service.baseline.listen.rabbitq.name ?
Also, this won't work...
Queue queue = new Queue("${ep.service.baseline.listen.rabbitq.name}", true, false, false, null);
You can't use property placeholders there. That will create a queue named ${ep.service.baseline.listen.rabbitq.name} - rabbit is very liberal with its naming rules.
You would need to use...
@Value("${ep.service.baseline.listen.rabbitq.name}")
private String queueName;
@Bean
public Queue incomingQueue() {
Queue queue = new Queue(this.queueName, true, false, false, null);
return queue;
}
DEBUG logging is always your friend; you will see all the queue declarations logged.
Best Answer
RabbitMQ is an AMQP broker, while ActiveMQ is a JMS one. I suggest you read the AMQP wikipedia article to get an idea of the concepts used in AMQP, which are different than the ones you're familiar in JMS. One of the main difference is that in AMQP a producer sends to an exchange without knowing the actual message distribution strategy while in JMS the producer targets either a queue or a topic (thus being aware of the type of message routing in place). So it's hard to tell what's done better or worse, as the semantics are very different between JMS and AMQP.
RabbitMQ's queues and exchanges are all configured via the AMQP protocol so a client library allows you to configure all your destinations and their behavior. ActiveMQ requires specific destination configuration because the JMS spec doesn't cover any of the administration side of things. Besides that, RabbitMQ's system configuration is Erlang-esque, while ActiveMQ is usually configured in XML. So you'll have to get used to the {tuple} and <> lovely syntax. RabbitMQ is usually installed with OS packages, while ActiveMQ distributions are archives you drop anywhere (or Maven deps you embed into something else).
Very well :) See Spring AMQP.