4 Replies Latest reply on Jul 2, 2012 4:07 PM by jtahlborn

    Implementing a simple message queue

    946216
      Hi,

      My project requires a messgae queue to be implemented which is exposed to outer world for dropping messages.I evaluated various free message queue/message bus options available like MSMQ, ActiveMQ,RabitMQ,ZeroMQ etc but found them either a overkill for my application or lacking the required performance or having a very high learning curve.

      So I am building my own message queue. The last area which is to be architected is queue pop area. I need to know as which one of these two is the best optimised way of taking out message from queue:-

      1) The consumers should register themselves with queue by imlementing a callback.When any message comes in queue, queue will invoke there specific method along with message.(This will take out processing thing from consumer from consumer but puts the burden on queue as queue has to wait until consumer uses the message and thread of queue becomes free for sending next message). I think, this is one way recommended in Java JMS specifications, though i am not sure.

      2) The consumers should register themselves with queue by imlementing a callback.When any message comes in queue, queue will just intimate the consumer with no thread blocking on the queue side. It is consumers duty to then take out the message from queue.

      I am not sure which one is best optimised and industry wide implemented in various commmercial/open source offerings.

      Please suggest

      Cheers

      TicArch
        • 1. Re: Implementing a simple message queue
          r035198x
          Are you sure that your implementation is going to beat HornetQ? http://planet.jboss.org/post/8_2_million_messages_second_with_specjms
          • 2. Re: Implementing a simple message queue
            946216
            I want to implement my own messgae bus because I have to a small understandable code which can be supported by me team easiliy in future.
            Can you please comments on my requirements and alternatives available to me to guide me which one to be adopted in which circumstances with its advantages and drawbacks.

            Cheers
            Tic

            Edited by: user13655125 on Jul 2, 2012 5:33 AM
            • 3. Re: Implementing a simple message queue
              gimbal2
              The advice you'll be given here is to use an existing queue implementation (and I too would recommend HornetQ). Yes it will mean digging through the manual and spending perhaps a week experimenting with different setups and test programs, but in the end you'll have something robust working that you can then in the future apply in almost no time.

              If you must roll your own for whatever reasons then fine - but then you're on your own from start to finish, including the consequences you'll have to bare because of your (IMO: poor) choice. Step 1: what does setting up your own message queue entail? Its a client/server architecture, so that is already a big hint what pile of books you should be ordering right now.
              • 4. Re: Implementing a simple message queue
                jtahlborn
                user13655125 wrote:
                I want to implement my own messgae bus because I have to a small understandable code which can be supported by me team easiliy in future.
                i'm pretty sure you are wrong about this unless your implementation is very trivial. why are you most likely wrong?:

                1. if you use jms (a java standard), then your client code will be very maintainable and understandable by anyone with jms experience (and if they don't have experience, they can find it documentation easily)

                2. many pre-existing implementations will also have good documentation (since they are an existing product). this will make it easier for your team to support/maintain the server side.

                For your implementation, both the client and server code will be custom. now, there may be reasons to do this in some situations, but unless your requirements are dramatically far from what existing jms providers offer, i seriously doubt your custom implementation will be easier to support or maintain.