Hi Martin,
thanks for your answer. You're right. The issue is a bit more complicated
than I thought. I guess I have to think of a better solution.
Sven
2012/9/30 Martin Matula <martin.matula_at_oracle.com>
> Please see below:
>
>
> On 9/29/12 5:16 PM, Sven Jacobs wrote:
>
>> Ok, I have the following problem:
>>
>> Let's say we have two REST resources /objects and /notifications.
>> /notifications is a WebSocket resource provided by the Atmosphere framework.
>> Let's say a client POSTs to /objects to create a new resource.
>>
>> Pseudocode
>>
>> @Path("/objects")
>> class Objects {
>> @POST
>> public Response create() {
>> long rev = nextRevision();
>> SomeObject obj = new SomeObject(rev);
>> return Response.created(...).entity(**obj).build();
>> }
>> }
>>
>> nextRevision() increases the global revision number and fires an internal
>> event. The /notifications resource listens for the event and sends a
>> WebSocket message to all connected clients saying "Hey, I have a new object
>> resource with revision x".
>> The problem here is that the WebSocket notification is send before the
>> client received the response from the /objects POST request. So what I'd
>> like to do is put the code which fires the internal revision event at a
>> place where I'm certain that the client first received the POST response
>> from /objects.
>>
>
> It seems to me even the notification you are asking for might not be
> sufficient in your case. Since server can only know that it sent all the
> data, that by itself does not mean the client processed them. I.e. even if
> there was an event you could listen to, you would receive it after the data
> has been sent to the client, not necessarily after the client processed
> them - and since this is happening on different threads, in theory the
> client could still receive the websocket message earlier than it processes
> the response to the POST message from the server.
> So you may need to approach it differently anyway. E.g. by synchronizing
> these things (sending the post request and processing of the web socket
> messages) on the client side.
> Martin
>
>