Announcement Announcement Module
Collapse
No announcement yet.
Notification component in a clustered environment Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Notification component in a clustered environment

    Hi All,

    This requirement is not directly related to Spring. As there are many experts of various technologies in this forum and i didn't know where else to turn to, i thought i would post this question here.

    We've a requirement that our server runs in a clustered environment. Any time notification (email/pager/jms msg/others) needs to be sent, we need to make sure that duplicate notficiations are not sent by more than one servers. For example, let's consider that there are two servers ES1 and ES2 and each has it's own notification component. When a ticket gets escalated to person X or when a priority ticket is created, notification needs to be sent to all users who have registred for notification preference to get notified IF THEY've LOGGED IN when a priority ticket is created. If each of our servers ES1 and ES2 has it's own notification component, how will server ES1 know who are the users that have logged-in through ES2????

    In this case shouldn't it be a good idea to have a separate notification server that runs outside ES1 and ES2??? In this case, how will ES1/ES2 knows who is it's notification server without much of hardcoded configuration???


    Also, if we want to add a new server ES3 dynamically, how would it know who is the notification server without going through much of configuration? Would it be better if the notification periodically sends a broadcast message to various ESX servers of it's availability???


    Could someone please share your thoughts on this?


    Thanks for any input in advance!

  • #2
    Re: Notification component in a clustered environment

    Originally posted by spring04
    Hi All,
    In this case shouldn't it be a good idea to have a separate notification server that runs outside ES1 and ES2???
    This is what I had in mind also.

    In this case, how will ES1/ES2 knows who is it's notification server without much of hardcoded configuration???
    Can`t you register the notification server with JNDI?

    Also, if we want to add a new server ES3 dynamically, how would it know who is the notification server without going through much of configuration?
    It could look op the message server in JNDI.

    Btw: I have not much practical experience with these problems (mostly reading).

    Comment


    • #3
      Thanks Alarmnummer for your prompt response.

      Does anyone have experience with similar requirement?

      Thanks again!

      Comment


      • #4
        Hi,

        Here is how I would do it: I would keep the listener registrations (who wants to receive what and how it wants to receive it) in the database. This listener table gets updated accordingly when users login/logout. The cost of updating this table is realtively low, as the users don't login/logout too often. When some server in the cluster needs to send a notification, it does not need to be aware of the fact that there other servers in the cluster. It just calls its local notification component which reads from the database who and how it needs to be notified and sends the notifications (email, sms, etc.). If sending the messages takes some time, then you might want to call the notification component asynchronoulsy.

        Comment


        • #5
          Originally posted by croco
          Hi,

          Here is how I would do it: I would keep the listener registrations (who wants to receive what and how it wants to receive it) in the database. This listener table gets updated accordingly when users login/logout. The cost of updating this table is realtively low, as the users don't login/logout too often. When some server in the cluster needs to send a notification, it does not need to be aware of the fact that there other servers in the cluster. It just calls its local notification component which reads from the database who and how it needs to be notified and sends the notifications (email, sms, etc.). If sending the messages takes some time, then you might want to call the notification component asynchronoulsy.
          I don`t understand why you want to use the database. For every piece of information a clients wants to be notified, you could create a (jms) topic and every client (that logs in) can register itself. As soon as something happens (the priority ticket for example) all clients will be notified that a 'priority ticket' has occured.

          This is standard JMS functionality. So I don`t see the need to use a db and to create an additional notification mechanism.

          So.. I would use a JMS server. Register it with JNDI (so locations aren`t hardcoded). The clients can access the JMS server by JNDI. Clients can register themself as listeners for a piece of information (they create a topic they listen to). And events can be fired (on that topic) if something occurs, and all clients will be notified.

          Comment


          • #6
            Hi,
            Your solution looks better than mine, you are right. Working a lot with a database you tend to think they are the golden hammer

            Comment

            Working...
            X