2 Replies Latest reply on Jul 30, 2002 10:38 AM by John Svazic

    J2EE polling distributed data

    Agustin Newbie

      Hi everyone.
      I'd like to ask you knowledgeable guys about a design issue I'm having.
      I'd like to use JBoss as an App Server in wich would reside my app. logic, and UI. I'd also use a decent RDBMS either in a standalone config or in the same JBoss cluster (first point).

      The tough part is that the app is supposed to be constantly polling many (1000 - 2000) distributed devices to get info on their status and retrieve event reports. That info would go to the DB of course. My problem is should the polling part be in the J2EE server? or in another machine more capable of having so many sockets opened at the same time?

      If it goes into a different machine, would the J2EE AS be overkill since that other machine could populate the DB directly?

      Thanks, and sorry for being so sparse in the problem definition (I don't want to bore you too much)


        • 1. Re: J2EE polling distributed data
          Agustin Newbie

          For the UI, I wanted to have two main interfaces: html (+ friends) for human consumption and some webservices (SOAP, etc.) for offering the data to external apps (instead of allowing them to tap into the DB directly)

          The number of concurrent users souldn't go much above 200 - 500.

          Thnx again,

          • 2. Re: J2EE polling distributed data
            John Svazic Newbie

            The first question you would want to ask yourself is "What parts of the J2EE API do I want to use, and why?" To get the polling interval going, I would use something like a Servlet or an MBean to do it, which would fit well with JBoss.

            Based on the UI requirements that you've mentioned here, I would still use a JBoss-based implementation. However, I might look into distributing the workload across a few dozen nodes. The problem that you might face is the large number of connections that you want to have. Depending on how much traffic you're generating, the problem might not be with the server but with the network hardware. Keep that in mind as well when you do your initial performance testing, and think about how you could split the work across a few different servers.