ceposta wrote > So this a little TL;DR... but I try answer some of your questions > inline...
Hi Christian, sorry, what does that mean? :-) TL, DR? ceposta wrote > If I read correctly, you have only one instance running? No.. this is > not a suitable setup for production. What happens if/when that one > instance fails? You should think about having at least a Slave broker > in warm standy. Sorry, that was misleading. I only wanted to express not to use a network of brokers. In production environment we will add a slave instance. ceposta wrote > The messages will never be consumed? > This will not work for long periods, you will run out of disk space. > Why not just store to a separate, longer-term storage? Sounds like > you're trying to use ActiveMQ for both a real-time even broker and > some kind of longer-term audit log... not a good idea. I'm aware that this is not in sense of messaging but as I stated this will be an temporary feature with purging in between. We do not want to establish more infrastructure beside the broker and like to be able to easily push back to queues. What long term alternative is able to do so? As questioned in no 3, ideally we would add an expiry date, so that archive is not growing but has quite a constant number of messages until finally deactivated. We can add this at client side as message property, but server side would be preferable. ceposta wrote >> >> 3. Is it possible to add an expiry date while forwarding to the archive >> queue/topic (Apache Camel is not in use)? >> >> 4. One open question is whether to use a single out queue (easier for >> client >> app C) and to use filtered destinations, filtering must then base on a >> application specific message property to distribute the message types to >> the >> different out-queues, is that possible? Does it perhaps perform better, >> on >> client and server side? > > Depends on how many messages and how much you're filtering...If the > producers know the partition ahead of time, then just stick with that > until it doesn't scale/work. That is not so easy to answer, but I try to do an estimated guess: 50.000 messages per day, let's 35.000 in the out-queues split QO1=20.000, QO2=10.000, QO3=4.000, QO4=1.000. Would filtering in that rough case a better way? ceposta wrote > A couple things... message groups are honored based on messages that > have been paged into memory. > > http://activemq.apache.org/message-groups.html > > If you have too little memory allocated to broker or destinations, > then messages will need to be paged in from disk (which can be > slower). That means for a requested message group some messages may be paged in memory but other non-paged messages will be read from disk but all together will be delivered to the client in the same connection or can only those messages be delivered for a message group that are already paged in memory? Thanks, Tom -- View this message in context: http://activemq.2283324.n4.nabble.com/Questions-to-broker-architecture-and-setup-memory-configuration-tp4679749p4679784.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
