Uploaded image for project: 'RichFaces'
  1. RichFaces
  2. RF-4109

a4j:push and timeout attribute

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 3.2.1
    • Fix Version/s: 3.3.0
    • Component/s: doc
    • Labels:
      None

      Description

      help the user with this post - http://jboss.com/index.html?module=bb&op=viewtopic&t=140365
      correct the guide if necessary

        Gliffy Diagrams

          Activity

          Hide
          atsebro Alex Tserbo added a comment -

          Exploring JMS API at java.sun.com

          Show
          atsebro Alex Tserbo added a comment - Exploring JMS API at java.sun.com
          Hide
          atsebro Alex Tserbo added a comment -

          Exploring JSF tree

          Show
          atsebro Alex Tserbo added a comment - Exploring JSF tree
          Hide
          atsebro Alex Tserbo added a comment -

          The post was commented. Below is the original text:

          "Hi, digitalseraphim !

          This is not a bug and guide's description is correct. The reason is in the request type ( ilya_shaikovsky was right).

          Here is how the stuff works:

          a) <a4j:push> sends HEAD-requests, that check for messages about an event;
          b) if there is no message in the queue (no event), HEAD-responses come back with nothing to be processed ("empty" responds);
          c) if there is a message (event exists), then HEAD-response comes back with Ajax-Push-Status "READY" (use FireBug plug-in for Firefox to explore that);
          d) the response with "READY" status triggers POST-request, that works trough full JSF lifecycle, and POST-response bring back new information to be rendered;
          e) this POST-request/response considered as "normal" in ilya's post; so, "timeout" time spreads exactly to this type of request, that's it!

          P.S.: In your example all the requests/responses are "empty". So, "timeout" was not used. Time from 0 (connection opened) to 58 (empty response, connection closed) is in milliseconds; it is insignificantly time, that had been taken to proceed an "empty" request/response.

          Regards,
          docteam
          "

          Show
          atsebro Alex Tserbo added a comment - The post was commented. Below is the original text: "Hi, digitalseraphim ! This is not a bug and guide's description is correct. The reason is in the request type ( ilya_shaikovsky was right). Here is how the stuff works: a) <a4j:push> sends HEAD-requests, that check for messages about an event; b) if there is no message in the queue (no event), HEAD-responses come back with nothing to be processed ("empty" responds); c) if there is a message (event exists), then HEAD-response comes back with Ajax-Push-Status "READY" (use FireBug plug-in for Firefox to explore that); d) the response with "READY" status triggers POST-request, that works trough full JSF lifecycle, and POST-response bring back new information to be rendered; e) this POST-request/response considered as "normal" in ilya's post; so, "timeout" time spreads exactly to this type of request, that's it! P.S.: In your example all the requests/responses are "empty". So, "timeout" was not used. Time from 0 (connection opened) to 58 (empty response, connection closed) is in milliseconds; it is insignificantly time, that had been taken to proceed an "empty" request/response. Regards, docteam "
          Hide
          atsebro Alex Tserbo added a comment -

          There is no need to correct the guide (the description given there is full and correct)

          Show
          atsebro Alex Tserbo added a comment - There is no need to correct the guide (the description given there is full and correct)
          Hide
          atsebro Alex Tserbo added a comment -

          Task is reopened because there is actually inconsistence in the documentation.

          The description touches permanent connection while it has been not implemented yet. The description in guide is corrected. The post has been added to the forum topic.

          Show
          atsebro Alex Tserbo added a comment - Task is reopened because there is actually inconsistence in the documentation. The description touches permanent connection while it has been not implemented yet. The description in guide is corrected. The post has been added to the forum topic.
          Hide
          atsebro Alex Tserbo added a comment -

          Short description of permanent connection should be added after the feature is implemented.

          Show
          atsebro Alex Tserbo added a comment - Short description of permanent connection should be added after the feature is implemented.
          Hide
          artdaw Gleb Galkin added a comment -

          Let's keep the task open till the feature implementation

          Show
          artdaw Gleb Galkin added a comment - Let's keep the task open till the feature implementation
          Hide
          smukhina Svetlana Mukhina added a comment -

          guide is corrected, information about feature that isn't implemented is deleted.

          Show
          smukhina Svetlana Mukhina added a comment - guide is corrected, information about feature that isn't implemented is deleted.

            People

            • Assignee:
              atsebro Alex Tserbo
              Reporter:
              smukhina Svetlana Mukhina
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Development