jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: FWIW

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 26 Aug 2011 18:50:50 +0200

On 08/26/2011 06:38 PM, Sergey Beryozkin wrote:
> This is a problem - API is centering around an entity which has been introduced for 20% cases and for which we have no
> particular good example.

I wonder what makes you think so?

>
> As I said, I don't see it working in practice, having a batched set of sync Invocations, one is GET, other is POST, can
> you believe it can work ?

I honestly don't have any real-life experience with this usecase in REST. But I believe it can work... Why not? In fact
I think that's what most browsers do today. They limit the threads per single domain URL (to 2 threads I guess) and then
when you fetch a page with multiple links to e.g. pictures and article summaries, only the 2 threads are used to fetch
the data[*].

So, to implement such browser one could use our Invocation API and a worker queue backed by two worker threads. The
browser would keep adding the new GET invocations to the queue and the worker threads would be invoking them and putting
the result into the response queue, from which the browser would take and process the responses.[#]


[*] You may probably know that one of the optimizations for fast page loading is to distribute the content across
mutliple servers to workaround the thread limitation imposed by browsers.

[#] Of course, that's not the only way how to implement such browser with our API.

> Thanks, Sergey
>
> On 26/08/11 17:34, Marek Potociar wrote:
>>
>>
>> On 08/26/2011 06:22 PM, Sergey Beryozkin wrote:
>>> On 26/08/11 17:19, Marek Potociar wrote:
>>>>
>>>>
>>>> On 08/26/2011 06:03 PM, Sergey Beryozkin wrote:
>>>>> In the previous revision Invocation was a 'dead' redundant entity only waiting to be dropped. It's back...
>>>>
>>>> As author, I disagree. Invocation is the encapsulation of command pattern concept. It would not be dropped.
>>>
>>> As I said in the other email, I'm fine with it staying, as long as we can come up with a more or less realistic example
>>> showing that command pattern in action, can you please think of one ? I'll +1 if yes
>>
>> Typically you would use command pattern whenever you need to execute something in batches. E.g. you are on a network
>> that experiences intermittent outages so in case of such outage you would queue the (failed) requests and then when the
>> network is up again, you would execute them using a generic invoke() API.
>>
>> Another example would be if you decided to implement a client used by a SEDA[1] stage.
>>
>> FWIW, it was originally Bill's requirement to support command pattern, so he may have a concrete real-life example.
>>
>> Marek
>>
>> [1] http://en.wikipedia.org/wiki/Staged_event-driven_architecture
>>
>>>
>>> thanks, Sergey
>>>
>>>
>>>
>>>>
>>>> Marek
>>>
>>>
>
>