1 Reply Latest reply on May 3, 2007 9:29 PM by sergeysmirnov

    Tips for a4j:poll?  Web app taking up lots of CPU and memory

    zzzz8

      I'm attempting to use Ajax4JSF in my Seam / MyFaces / Facelets application. I'm trying to update certain portions of my page using the a4j:poll component. Although I was successful, I noticed that the app server (I'm using JBoss 4.0.5 GA) was using lots of CPU cycles and memory to handle the Ajax polling - at very much of an unacceptable level. I'm wondering if I'm doing something incorrectly - if anyone can provide me any tips (based on what I write below), it would really help...

      I have a typical web page (header, menu, content area). I use the Facelets templating feature heavily, so I've interspersed a few a4j:poll tags in my Facelets xhtml pages (i.e. in the header and content areas) - so for a single rendered page, there are a few a4j:poll tags (is this a bad idea?). I essentially want the page refreshed once a second (at least the designated content areas). I'm not using any of the attributes (other than reRender) on a4j:poll. Is this an issue - should I be using eventsQueue, limitOnList, a4j:region, etc.? The beans I access are conversation-scoped beans. I also have page actions for each page in which I set session scoped components that are outjected to the conversation-scoped beans (is this a bad idea - is this causing memory leaks because the page actions are called for every update?)

      I'm just starting out with Ajax4JSF, so I'm not really sure I know what I'm doing. Any help / advice would be appreciated.

        • 1. Re: Tips for a4j:poll?  Web app taking up lots of CPU and me

          Using poll component should have a practical reason for application in run-time. a4j:poll produces a regular JSF Request including session restoring and JSF lifecycle processing.

          So, the first tip:
          do not use a4j:poll (or bunch of them) just make your life as a developer easy, but future live of server software and hardware hard
          Ajax4jsf presumes that developers use chain: event - request - server action - response - update
          This guaranties there is a reason for request (event occurs) and reason to update (as soon as model changes).

          Others:
          use own form for each poll component to avoid sending extra data to the client.

          use ajaxSingle="true" for a4j:poll if you do not post any other data from the client to server during the poll request.

          limit the region for processing with < a4j region >. If ajaxSingle limits what will be sending from the client, region limits what will be processed on the server

          use as shortest scope for involved in the processing beans as possible. It does not mean session or conversation scope are not OK. Think why it is important to involve them.

          do not re-render wide zones on the view . Limit then to what might be changed as a result of this particular requests.

          use limitOnList="true" and point the to components you want to re-render explicitly.

          try to avoid crossing between -re-rendering zone between different polls and event-driven changes.