Details

    • Type: Task Task
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 3.2.1
    • Fix Version/s: 3.3.0
    • Component/s: doc
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

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

        Activity

        Hide
        Alex Tserbo
        added a comment -

        Exploring JMS API at java.sun.com

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

        Exploring JSF tree

        Show
        Alex Tserbo
        added a comment - Exploring JSF tree
        Hide
        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
        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
        Alex Tserbo
        added a comment -

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

        Show
        Alex Tserbo
        added a comment - There is no need to correct the guide (the description given there is full and correct)
        Hide
        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
        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
        Alex Tserbo
        added a comment -

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

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

        Let's keep the task open till the feature implementation

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

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

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

          People

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

            Dates

            • Due:
              Created:
              Updated:
              Resolved: