9 Replies Latest reply on Dec 14, 2008 5:09 AM by Noel O'Connor

    Number of topic subscribers

    Noel O'Connor Novice

      Hi,
      I'm working on a hight load web project where the design dictates that there is a JMS consumer consuming of a single topic for each logged in user. When the user logs out the consumer is discarded. Each consumer is not durable.

      Considering that there could be 100's if not 1000's of users I think that this approach could have performance issues. Does JBM scale to this level or is the whole approach misguided ?

      thanks
      Noel

        • 1. Re: Number of topic subscribers
          Clebert Suconic Master

          You shouldn't have any problems with that on JBoss Messaging 1.4.

          I just ran a quick test where I had thousand subscribers and it ran without any problems.

          When i say you shouldn't have any problems, I'm assuming you are designing your application well and you have considered resource usage on the server (max Openfiles set for the number of clients you will have, enough I/O and enough memory on the server and JVM).

          If your consumers are local to the server, you should probably avoid ObjectMessage as Serialization will aways be something expensive (but that should be ok if your consumers are distributed. On the server side an ObjectMessage is just a ByteArray, but on the client that is using ObjectINputStream and if you have all the clients on the same server that will use more CPU power.

          (Those recommendations will apply to any system you choose.. not just JBM)

          • 2. Re: Number of topic subscribers
            Noel O'Connor Novice

            Hi Clebert,
            Thanks for the info, however I forgot to mention that each subscriber will have a selector to only pull down messages that its interested in.
            I know that selectors have a more substantial performance impact than subs with no selectors. Thanks for the tip on the openFiles.

            I understand that all of this is based on app design and server tuning I was just concerned that the designers are treating the JMS subscribers as a kind of lightweight thread (for lack of a better description).
            I'd rather move them into using a lot less JMS resources and having more application threads to process the messages.

            thanks for your help
            Noel

            • 3. Re: Number of topic subscribers
              Clebert Suconic Master

               

              that each subscriber will have a selector to only pull down messages that its interested in.


              I don't see a problem with the selector, as long as you are not doing something like "userID=yourUser" on the selector on which case it would be a terrible design IMO where you should in fact use multiple queues (0ne for each user). (a temporary queue maybe)

              • 4. Re: Number of topic subscribers
                Noel O'Connor Novice

                Yes, they intend to use a selector to pull a message off the queue based on UserID.
                Thanks for confirming my doubts on this approach.

                regards
                Noel

                • 5. Re: Number of topic subscribers
                  Clebert Suconic Master

                  Yes.. never use that style of selector to filter user data.. That's a terrible anti-pattern. (this is true for any messaging style software you are ever going to use).

                  It seems like temporary queues, would be the best approach for you, maybe the QueueRequestor approach.

                  • 6. Re: Number of topic subscribers
                    Tim Fox Master

                    I'm not sure I agree with Clebert here.

                    Using multiple selectors on a single *queue* is generally considered an anti-pattern. This is because when a message is consumed the entire queue needs to be scanned to see if one matches.

                    However, using selectors on a *topic* is NOT considered an anti-pattern. Why? This is because the topic subscription will only accept messages that match the selector, therefore you know at consumption time that the subscription only contains matching messages and you don't need to scan anything.

                    This means selectors on a topic does not have the performance problems associated with selectors on queues.

                    Noelo - If you can explain your use case in more detail, that would be helpful.

                    • 7. Re: Number of topic subscribers
                      Clebert Suconic Master

                       

                      "timfox" wrote:

                      However, using selectors on a *topic* is NOT considered an anti-pattern. Why? This is because the topic subscription will only accept messages that match the selector, therefore you know at consumption time that the subscription only contains matching messages and you don't need to scan anything.


                      The anti-pattern I'm referring is using selectors to filter Users of a main topic. It would be better to use temporary queues IMO.

                      • 8. Re: Number of topic subscribers
                        Noel O'Connor Novice

                        The component I'm working on is required to process events sent from other parts of the system. Each of these event are generated by a user and contain a userid. These events are placed on a JMS topic which is read and the event data processed by my component.

                        For each user there will be an instance of my component and this instance will be subscribed to the JMS topic with a selector selecting any messages which matches the user id for that component.

                        Considering that there could be 1000's of concurrent users and therefore 1000's of JMS topic subscribers (plus selectors) I thought that this could be a performance pit fall. Also each component instance will sit on its own thread so I think that this approach is even less scalable.

                        I really appreciate your help and insight in this.....

                        regards and thanks
                        Noel

                        • 9. Re: Number of topic subscribers
                          Noel O'Connor Novice

                          Hi Tim, Clebert,
                          Any further comments/suggestions on this matter and the correct approach to take..

                          ta
                          Noel