2 Replies Latest reply on Jan 26, 2010 7:36 AM by rockytriton

    pub/sub design

    rockytriton
      Hi, I need some advice on how best to design a system. I want to implement pub/sub to notify users of changes to various mailboxes. These are shared mailboxes, there are about 400 of them in the system total. Some of them tend to be huge, about 20,000+ items in them. I want to have the users subscribe to that specific mailbox topic and get notifications when mails are added or removed, that way I only have to refresh the whole mailbox at startup, after that refresh it will just add/remove on the fly whenever it receives notifications through the subscription.

      The question is this, should I go with a topic for each of the 400 mailboxes, the users who share these mailboxes will subscribe to it, so there will be topics such as "/topic/sharedMBX1", "/topic/sharedMBX2", etc... Or should I go with a single topic, say "/topic/MBXUpdates" and use a message selector, so when the user creates a TopicSubscriber, it will be created with the message selector "sharedMBX2" to only get message notifications for that specific mailbox.

      I guess what it comes down to is, is it easier to manage 400 topics or just manage one single topic that gets 400 times the messages as it would if there were 400 topics?

      Thanks in advance
      -- Rocky
        • 1. Re: pub/sub design
          gaohoward

          I think it should be better using a topic for each mailbox than a single topic for all mailboxes. So you don't need a seletor anymore and adding a new mailbox or removing an existing one would be as simple as deploy/undeploy a topic.

          • 2. Re: pub/sub design
            rockytriton
            Thanks for your input.  I will be using a message selector in either case because the shared mailboxes also have members and each member can view either their own set in that mailbox or the "unassigned" set in that mailbox.  So I think that it would probably be better to go with multiple topics.  Thanks for the help.