I’m currently enjoying reading "Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation" and the part that caught my attention is that on managing configuration settings for applications.
What's proposed in the book is that all configuration settings are externalized and centralized in a repository of some sort, be it an LDAP directory, ESCAPE Server or somesuch and then retrieved from there.
This sounds really compelling to me as this approach can provide a number of tangible benefits, but after Googling around for a bit it seems to me that this is not exactly a widespread approach.
I know there is a Twelve-Factor App article on this subject, but it suggests using environment variables instead of a centralized repository. This approach seems to be the most commonly used one, but it feels like a dirty one compared to a repository-based solution.
So, is the central-configuration-repository approach used in any significant manner in a real world, and if not -- what are the reasons for this?
Apparently, Zookeeper is frequently used for managing config variables:
http://zookeeper.apache.org/doc/r3.3.3/recipes.html#sc_outOfTheBox
Real World Use of Zookeeper
Doozer looks interesting as well:
https://github.com/ha/doozerd
And here is RESTful wrapper over Git inspired by the same text you refer to:
http://www.andycaine.com/configuration-management-with-restful-git/
Finally, env vars may feel dirty but they are actually quite a clean approach
https://devcenter.heroku.com/articles/config-vars
Is there an article or resource on getting started with BookSleeve Redis? Thanks
These are some of the articles/links I read when getting upto speed:
http://marcgravell.blogspot.com/2011/04/async-redis-await-booksleeve.html
http://marcgravell.blogspot.com/2011/07/booksleeve-transactions-hashes-and.html
https://code.google.com/p/booksleeve/
http://redis.io/
besides that, search stackoverflow for related questions:
https://stackoverflow.com/questions/tagged/booksleeve
There is not a ton out there, you need to roll up your sleeves and dig in.
Book sleeve is just a wrapper around redis, so any data decisions really relate equally to any redis guide. http://redis.io would be a starting place. In terms of the API, the only things that should need highlighting are:
most operations are async and are exposed via the Task api; this allows a range of usage patterns including (but not limited to) the new "async"/"await" keywords
the operations are split by data type, so .Strings, .Hashes, etc
a connection is a thread-safe multiplexer and is designed to be used by multiple callers concurrently - you do not (and should not) need to use a connection scoped per caller
I am interested in what things you would want me to include in more detailed documentation. What would be useful? What is unclear? What do you need?
If you can describe what you need, I can write it :p
I want to use MassTransit bus with RabbitMQ. But I am not able to find a simple example. I am looking for example which will get me started.
What I have tried.
googled: But most the examples are using MSMQ or they using too many configuration options.
GitHub: I looked a the GitHub for MassTransit (https://github.com/MassTransit/MassTransit/tree/master/src/Samples) But the example here is heavily loaded. It's very hard to understand for beginners.
Reading docs: I have started reading docs but it will take some time before I finish it. I am hoping if someone shares a link to simple example which will get me started.
Please provide your suggestion.
Here's a simple, good pub-sub example using MassTransit and RabbitMQ both.
http://looselycoupledlabs.com/2014/06/masstransit-publish-subscribe-example/
In case the article link does not work, here's the link to the source code:
https://github.com/dprothero/MtPubSubExample
Thanks to the author of course!
MassTransit implements a lot of concepts and provides great many features with a very small surface API. There's no simple way to describe everything it does, because the problems it helps to solve are not simple, but an example can be made small.
Have a look at this sample I have for testing throughput:
https://github.com/et1975/Throughput-Test
The only "extra" that one might find unnecessary is Dependency Injection integration. You'd want one in most cases, but it does hide how certain bits interact.
Look at https://groups.google.com/forum/?fromgroups#!forum/masstransit-discuss for more help.
Cheers,
ET.
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.
as opposed to writing your own library.
We're working on a project here that will be a self-dividing server pool, if one section grows too heavy, the manager would divide it and put it on another machine as a separate process. It would also alert all connected clients this affects to connect to the new server.
I am curious about using ZeroMQ for inter-server and inter-process communication. My partner would prefer to roll his own. I'm looking to the community to answer this question.
I'm a fairly novice programmer myself and just learned about messaging queues. As i've googled and read, it seems everyone is using messaging queues for all sorts of things, but why? What makes them better than writing your own library? Why are they so common and why are there so many?
what makes them better than writing your own library?
When rolling out the first version of your app, probably nothing: your needs are well defined and you will develop a messaging system that will fit your needs: small feature list, small source code etc.
Those tools are very useful after the first release, when you actually have to extend your application and add more features to it.
Let me give you a few use cases:
your app will have to talk to a big endian machine (sparc/powerpc) from a little endian machine (x86, intel/amd). Your messaging system had some endian ordering assumption: go and fix it
you designed your app so it is not a binary protocol/messaging system and now it is very slow because you spend most of your time parsing it (the number of messages increased and parsing became a bottleneck): adapt it so it can transport binary/fixed encoding
at the beginning you had 3 machine inside a lan, no noticeable delays everything gets to every machine. your client/boss/pointy-haired-devil-boss shows up and tell you that you will install the app on WAN you do not manage - and then you start having connection failures, bad latency etc. you need to store message and retry sending them later on: go back to the code and plug this stuff in (and enjoy)
messages sent need to have replies, but not all of them: you send some parameters in and expect a spreadsheet as a result instead of just sending and acknowledges, go back to code and plug this stuff in (and enjoy.)
some messages are critical and there reception/sending needs proper backup/persistence/. Why you ask ? auditing purposes
And many other use cases that I forgot ...
You can implement it yourself, but do not spend much time doing so: you will probably replace it later on anyway.
That's very much like asking: why use a database when you can write your own?
The answer is that using a tool that has been around for a while and is well understood in lots of different use cases, pays off more and more over time and as your requirements evolve. This is especially true if more than one developer is involved in a project. Do you want to become support staff for a queueing system if you change to a new project? Using a tool prevents that from happening. It becomes someone else's problem.
Case in point: persistence. Writing a tool to store one message on disk is easy. Writing a persistor that scales and performs well and stably, in many different use cases, and is manageable, and cheap to support, is hard. If you want to see someone complaining about how hard it is then look at this: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
Anyway, I hope this helps. By all means write your own tool. Many many people have done so. Whatever solves your problem, is good.
I'm considering using ZeroMQ myself - hence I stumbled across this question.
Let's assume for the moment that you have the ability to implement a message queuing system that meets all of your requirements. Why would you adopt ZeroMQ (or other third party library) over the roll-your-own approach? Simple - cost.
Let's assume for a moment that ZeroMQ already meets all of your requirements. All that needs to be done is integrating it into your build, read some doco and then start using it. That's got to be far less effort than rolling your own. Plus, the maintenance burden has been shifted to another company. Since ZeroMQ is free, it's like you've just grown your development team to include (part of) the ZeroMQ team.
If you ran a Software Development business, then I think that you would balance the cost/risk of using third party libraries against rolling your own, and in this case, using ZeroMQ would win hands down.
Perhaps you (or rather, your partner) suffer, as so many developers do, from the "Not Invented Here" syndrome? If so, adjust your attitude and reassess the use of ZeroMQ. Personally, I much prefer the benefits of Proudly Found Elsewhere attitude. I'm hoping I can proud of finding ZeroMQ... time will tell.
EDIT: I came across this video from the ZeroMQ developers that talks about why you should use ZeroMQ.
what makes them better than writing your own library?
Message queuing systems are transactional, which is conceptually easy to use as a client, but hard to get right as an implementor, especially considering persistent queues. You might think you can get away with writing a quick messaging library, but without transactions and persistence, you'd not have the full benefits of a messaging system.
Persistence in this context means that the messaging middleware keeps unhandled messages in permanent storage (on disk) in case the server goes down; after a restart, the messages can be handled and no retransmit is necessary (the sender does not even know there was a problem). Transactional means that you can read messages from different queues and write messages to different queues in a transactional manner, meaning that either all reads and writes succeed or (if one or more fail) none succeeds. This is not really much different from the transactionality known from interfacing with databases and has the same benefits (it simplifies error handling; without transactions, you would have to assure that each individual read/write succeeds, and if one or more fail, you have to roll back those changes that did succeed).
Before writing your own library, read the 0MQ Guide here: http://zguide.zeromq.org/page:all
Chances are that you will either decide to install RabbitMQ, or else you will make your library on top of ZeroMQ since they have already done all the hard parts.
If you have a little time give it a try and roll out your own implemntation! The learnings of this excercise will convince you about the wisdom of using an already tested library.