I am looking for fanout and fanin at different levels of my verilog design. I went through the yosys + arachne-pnr manuals/commands but could not find a relavant command to find fanout/fanin. Can you please help?
Related
I'm using RabbitMQ as message broker in first time and now I have a question about when to declare queues and exchanges using rabbit's own management tool and when to do it in the code of the software? In my opinion is that it is much better to create queues and exchanges using the management tool, because it's a centralized place to add new or remove useless queues without the need to modify the actual software. I am asking some advice and opinions.
Thank you.
The short answer is: whatever works best for you.
I've worked with message brokers that required external tools for defining the topology (exchanges, queues, bindings, etc) and with RabbitMQ that allows me to define them at runtime, as needed.
I don't think either scenario is "the right way". Rather, it depends entirely on your situation.
Personally, I see a lot of value in letting my software define the topology at runtime with RabbitMQ. But there are still times when it gets frustrating because I often end up duplicating my definitions between producers and consumers.
But then, moving from development to production is easier when the software itself defines the topology. No need to pre-configure things before moving code to production.
It's all tradeoffs.
Try it however you're comfortable. Then try it the other way. See what happens, and learn which you prefer and when. Just remember that you don't have to do one or the other. You can do both if you want.
Can we migrate from IBM MQ to Rabbit MQ ? Is this possible?
Are there any dependencies.What are the factors that we need to look at.
That's like asking can you migrate from Java to c++. Both things do the same thing but are different by structure (at least).
You can do it of course, but I wouldn't call it migrating, but setting up new. They are both message queue brokers and you could keep some concepts (architecturally looking) but the whole "physical" infrastructure would needed to be set up from scratch.
You need to re-look at the current messaging design pattern and re-design it for RabbitMQ. And design the roll-out strategy. Secondly all the producers and consumers need to be re-written. You need to take into consideration how much effort the producer and consumer applications need to migrate to the new messaging system and secondly Messaging Format also slightly different here in RabbitMQ. So you need to take various aspect into consideration before migrating.
We use rabbitmq in production and really happy with it. we are planning to use rabbitmq fanout feature, but would like to understand the internals.
Here are my questions:
1. When a message is fan'ed out to multiple queues, is the message copied to different queues rather than just the reference?
2. if the entire message is duplicated on all the fan'ed out queues, Is there a way to make it efficient?
Thank you,
-Bala
To store AMQP message content, RabbitMQ uses "binaries" which are a particular type in Erlang.
The Erlang VM only copies those binaries if they are small enough (the limit is 64 bytes if I remember correctly), otherwise, it uses reference counting. There is a chapter in the Erlang documentation about how binaries are implemented. Paragraphe 4.1 should be of interest to you.
I am very much new to activemq. I was trying to use activemq broker for subscribe/publish messages. But as for lack of experience I have no idea how to do it or if its really possible to do it. I googled a lot but unfortunately there is no suitable example for this type of functionality. So I was hoping may be someone here can put some light on it. Can any one here can give me some example of how to do it? or may be some link to online documentation. I have already tried apache activemq broker documentation. But it was not helpful, or may be I dont have that much experience to take help from it.
What you are interested in is done using topics. The reason that you haven't necessarily seen a description of it on the ActiveMQ site is that it's a foundational thing that is assumed that readers know about.
If you are looking at an introduction into messaging using Java, the best place is Oracle's JMS tutorial. Afterwards take a look at the code in the examples directory of an ActiveMQ installation. Alternatively, ActiveMQ in Action is a great book to get you heading in the right direction.
If you are using a language other than Java, ActiveMQ supports the STOMP protocol for which there are a large number of implementations in various languages.
Hope that helps.
I'm looking for articles and references that give an overview of 'queueing' (I'm probably not even using the right term here). I'm hoping for an introductory styled guide through a world of Redis, RabbitMQ, Celery, Kombu, and whatever other components exist that I haven't read about yet, and how they fit together.
My problem is I need to queue up background tasks for issued by my Django website, and every blog and article I read recommend different solutions.
Lots of options available to you, and your choice will likely come down to personal preference and what dependencies you feel comfortable installing.
I'll give a vote for Redis. I evaluated RabbitMQ, ActiveMQ, HornetQ, and Redis and found Redis to offer the best mix of ease of installation, simplicity, and performance.
It's technically not a message queue, but the push/pop primitives for the list types provide atomic queue-like operations, so it can effectively be used as a queue. It has worked well for us.
One python specific project on top of Redis you might look at:
http://richardhenry.github.com/hotqueue/tutorial.html
Very simple. But again, all the other options, like Celery, are viable too.
RabbitMQ has a good introduction here: http://www.rabbitmq.com/getstarted.html There's examples in Python, even.
HornetQ has a very good documentation, and it's simple to install.
You can find the documentation at www.hornetq.org, and you would have several examples available with the distribution.