On Dec 12, 2007, at 2:08 AM, Sahoo wrote:
> Reply inline...
>
> Ken Cavanaugh wrote:
>> Charlie or Harsha may want to chime in here, but basically we use
>> a temporary selector thread to
>> read "hot" connections. It turns out to be really expensive to
>> keep adding/remove SelectionKeys
>> to the selector, so once we receive a message, we dedicate a
>> thread to handling reads on that
>> socket until there is no data, and no expected data (that is, no
>> partially read message). But note that
>> requests of different priorities will currently arrive on the same
>> socket (although this could be avoided with
>> the new connection cache implementation that I wrote, which is not
>> yet integrated with the ORB.
>> The new connection cache allows multiple connections to the same
>> endpoint, and also allows
>> the connection cache to be modified with a Handler that controls
>> which cached connection is
>> used for a request).
>>
>> I don't recall exactly where the temporary worker threads come
>> from, but probably either the
>> Grizzly or CORBA thread pools. We'll need to look at this further.
>>
>> One of the things that we need to look at is bounding the number
>> of temporary selector threads.
>> This would basically mean that we would go back to handling
>> request in the usual way, paying
>> the SelectionKey overhead when we run out of threads. We could
>> simply create a small
>> threadpool reserved just for this purpose, independent of the
>> prioritization scheme.
>>
>>
> Having an intermediate thread pool to read the bytes, decode the
> priority bits, and enqueue the request as per prioritization scheme
> is exactly what we are looking for. If this needs to be done in
> Grizzly so that it can be used for both http and iiop traffic, then
> better.
>>>> Yes. We want to have a request interceptor set the thread pool
>>>> ID to use in the GIOP header of the request message.
>>>> Then the server code will read the encoded ID and use it to
>>>> enqueue the message on the correct thread pool.
>>> The same question as before. Which thread in Grizzly would be
>>> responsible for reading the GIOP header and decoding the priority
>>> bits?
>>
>> Harsha/Charlie should fill in the details here.
> waiting...
>>
>>
>> I think the current ORB and the Grizzly integration do roughly the
>> same thing. We've
>> been beating up Grizzly a fair bit to get it to work properly with
>> IIOP.
> Is there a Grizzly version of ORB available? Is it in corba-dev trunk?
Not yet. We plan to put it back into the V3 ORB early next year.
>>>>
>>>> Also, do we still want to keep the old request partitioning
>>>> scheme around? We could view this new scheme
>>>> as simply an extension of the old scheme, which statically
>>>> assigned EJBs to pool at EJB creation time. You can do
>>>> whatever you like so long as the ids are in the 0 to 63 range.
>>>> This may also be a reason to implement role to ID mapping,
>>>> so that the two features can co-exist more easily.
>>> No, we can't support both the schemes in the same runtime, as
>>> that would violate our priority invariance.
>>
>> Please explain this further.
> The invariance is described in the one-pager. It is a simple rule:
> /"at say time T, if there are two concurrent resource requests, the
> higher
> priority resource request wins, or in other words, if a (n-1) priority
> request can be satisfied, a (n) priority request can and will be
> serviced as against the (n-1) request."/
Do you want to implement some kind of fairness guarantee, or is it
acceptable for
high priority requests to block all lower priority requests for long
periods of time?
>
> To implement it, we need to have control over all the worker
> threads in the system. If we have a dedicated thread pool for some
> EJB, then that does not fit into our priority model very well.
That should be fine.
>> As far as the ORB is concerned, I'll provide you with the
>> mechanism of
>> tagging the request, and the server side support to act on it. The
>> rest is up to you.
> +1
>>
>>>>
>>>> Is there any need to make per-method priority decisions? This
>>>> again is a mapping table question in the same
>>>> general framework.
>>> Yes, we plan to support this as well.
>>>
>>
>> OK, we need to talk about that. Tagging methods is tricky due to
>> IDL name mangling rules.
> Why can't this be done using the same kind of encoding done by the
> client side interceptor based on the mapping information passed
> from the server?
>
We can, but the name of the operation on the wire is determined from
the method name
and parameter types by some rather complicated rules. Those names
will need to be placed in
the mapping table in the service context. There is an interface for
getting the information,
so this is pretty easy to handle.
Ken.