Grokbase Groups Cayenne dev May 2008
FAQ
Hello.
On 14. mai. 2008, at 00.46, Andrus Adamchik wrote:

(2) Setup server-to-client event push. I did that in the past with a
always-on XMPP connection in parallel with the main HTTPS data
channel (I know it worked for object updates... it needs to be
extended to cache groups invalidation). For a long time I wanted to
investigate Jetty Continuations (and more generally, queuing events
on the server for each live client, and letting client frequently
poll for events). This would allow to reuse the main ROP connection,
but this needs to be developed yet.
It looks like the thing Jetty are doing with Continuations will be
standardized in Servlet 3.0

http://blogs.webtide.com:80/gregw/2008/04/28/1209355449829.html

Regards,
- Tore.

Search Discussions

  • Andrus Adamchik at May 14, 2008 at 9:43 pm
    I just took a glance at the early draft of JSR-315 (and looks like
    Jetty 7 early releases already have this API built in).

    I *hope* we can emulate a persistent connection with that, using a
    protocol similar to this:

    1. Client sends a "give me events" request in the beginning of the
    session (separate from data requests), and reads everything that comes
    back.
    2. Server suspends the request thread, and keeps it suspended until
    the client quits.
    3. When an event arrives on the server, it is written to response and
    response.flushBuffer() is called (I guess we'll need to resume the
    request to do that and then suspend it again ... I hope multi-suspend
    is supported ? Or can we flush without resuming?)

    Of course all that is pluggable via an EventBridge implementation, so
    given the time and motivation we can download Jetty 7 and start
    playing with it right away.

    Andrus

    On May 14, 2008, at 4:42 PM, Tore Halset wrote:
    Hello.
    On 14. mai. 2008, at 00.46, Andrus Adamchik wrote:

    (2) Setup server-to-client event push. I did that in the past with
    a always-on XMPP connection in parallel with the main HTTPS data
    channel (I know it worked for object updates... it needs to be
    extended to cache groups invalidation). For a long time I wanted to
    investigate Jetty Continuations (and more generally, queuing events
    on the server for each live client, and letting client frequently
    poll for events). This would allow to reuse the main ROP
    connection, but this needs to be developed yet.
    It looks like the thing Jetty are doing with Continuations will be
    standardized in Servlet 3.0

    http://blogs.webtide.com:80/gregw/2008/04/28/1209355449829.html

    Regards,
    - Tore.
  • Aristedes Maniatis at May 15, 2008 at 9:27 am

    On 15/05/2008, at 7:43 AM, Andrus Adamchik wrote:

    1. Client sends a "give me events" request in the beginning of the
    session (separate from data requests), and reads everything that
    comes back.

    Three thoughts:

    1. Is your idea to have one queue per client, or a single queue with
    some sort of sequence numbering so a client can grab events later than
    a particular timestamp/sequence?

    2. Even without continuations the basic idea could still work if the
    client received these events attached to query results. So every time
    a client performs a query (or executes a special polling request)
    these events are received. Not quite so real-time, but possibly useful
    in many circumstances.

    3. Are the events here just refresh query cache events, or are we
    talking about 'invalidate record id 1234 from entity Artist' messages?
    Possibly that will generate too much traffic since the server will not
    know which clients have those entities already cached and will have to
    propagate all invalidate messages to all clients. I'm still a little
    hazy about whether the server has a copy of the same contexts as the
    client does, so perhaps it does know which records the client is
    holding, but I'm not sure how SHARED_CACHE impacts that.


    Ari



    -------------------------->
    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
  • Andrus Adamchik at May 15, 2008 at 2:06 pm
    On May 15, 2008, at 5:26 AM, Aristedes Maniatis wrote:
    On 15/05/2008, at 7:43 AM, Andrus Adamchik wrote:

    1. Client sends a "give me events" request in the beginning of the
    session (separate from data requests), and reads everything that
    comes back.

    Three thoughts:

    1. Is your idea to have one queue per client, or a single queue with
    some sort of sequence numbering so a client can grab events later
    than a particular timestamp/sequence?
    As the events will be dispatched immediately (there will be no client
    polling), the only queue involved is the local EventManager queue.
    There is a single one per DataDomain and it is shared by all server
    contexts.
    2. Even without continuations the basic idea could still work if the
    client received these events attached to query results. So every
    time a client performs a query (or executes a special polling
    request) these events are received. Not quite so real-time, but
    possibly useful in many circumstances.
    Yeah - that's another possible mechanism. The mechanics of it will be
    different. Unlike continuations approach, this will require a "delayed
    client queue".
    3. Are the events here just refresh query cache events, or are we
    talking about 'invalidate record id 1234 from entity Artist'
    messages? Possibly that will generate too much traffic since the
    server will not know which clients have those entities already
    cached and will have to propagate all invalidate messages to all
    clients.
    Both types of events... (I guess each type can be suppressed or
    enabled via configuration). I forgot to mention one thing though - we
    already have per-object events (since Cayenne 1.1), but there is no
    query cache events (any such events are specific to an implementation
    of the QueryCache, and are not a part of Cayenne). So that's something
    that we need to design.

    I'm still a little hazy about whether the server has a copy of the
    same contexts as the client does, so perhaps it does know which
    records the client is holding
    Yes - the server contains "peer" contexts of all client contexts,
    stored in HttpSession. Their state is almost the same as client's, the
    only difference being objects loaded during callbacks execution.

    Andrus

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedMay 14, '08 at 8:43p
activeMay 15, '08 at 2:06p
posts4
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase