FAQ

On Oct 5, 2006, at 23:15, Andrus Adamchik wrote:

I thought we might also provide an alternative event mechanism via
Jetty continuations (essentially a variation of polling the
webapp ... so the client doesn't have to be Jetty-specific),
simplifying the deployment significantly by removing XMPP server
from the picture.

http://docs.codehaus.org/display/JETTY/Continuations

I didn't have time to look deeply into that, but this seems very
promising as a default mechanism.
This looks indeed very interesting. I guess we could create a
ClientMessage implementation that asks the server for events. Any
request would wait until at least one event are ready to be sent to
the client. I do not know if it is possible to loop and wait for the
next request or if the client would then have to send a new request.
Anyone know how this works? If the client need to send another
request, events can be lost..

I do however have problems seeing how this can be a default mechanism
for non-Continuations servlet containers. The client could poll the
server, say, every 10 s. The non-Continuations servlet container
would have to remember all events for the last 10 s and figure out
which to send to polling clients. Not very nice.

Anyone digged into this one?

- Tore.

Search Discussions

  • Aristedes Maniatis at Nov 14, 2006 at 11:58 pm

    On 15/11/2006, at 10:07 AM, Tore Halset wrote:

    I do however have problems seeing how this can be a default
    mechanism for non-Continuations servlet containers. The client
    could poll the server, say, every 10 s. The non-Continuations
    servlet container would have to remember all events for the last 10
    s and figure out which to send to polling clients. Not very nice.
    Each event can be given a monotonically increasing sequence number.
    Each client then has a reference to the last event number it received
    and sends that in its poll request. The server responds with all
    events greater than that number. Alternatively this could be done
    with a timestamp as long as we always use the server's timestamp as a
    reference point.

    The only problem here is that the server needs to have a reference to
    each connected client and the last event it collected. It would then
    be able to purge from memory all events which have been collected by
    all clients. Otherwise there needs to be a time-to-live for all
    events which causes them to be purged from the server.


    Ari Maniatis



    -------------------------->
    ish
    http://www.ish.com.au
    Level 1, 30 Wilson Street Newtown 2042 Australia
    phone +61 2 9550 5001 fax +61 2 9550 4001
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedNov 14, '06 at 11:07p
activeNov 14, '06 at 11:58p
posts2
users2
websitecayenne.apache.org

2 users in discussion

Aristedes Maniatis: 1 post Tore Halset: 1 post

People

Translate

site design / logo © 2022 Grokbase