Re: [ecf-dev] RemoteService + Context

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Franky,

On 10/27/2010 6:25 AM, Franky Bridelance wrote:
> Hi,
> That's quite similar to what I'm doing. That's the reason why I 
> started the discussion about how to add authorization on remote 
> service calls via the proposed IRemoteServiceCallPolicy interface. The 
> discussion about this matter is on hold for some time due to the ECF 
> 3.4 release. Maybe we can start the discussion again once 3.4 has been 
> released?

Yes, of course.  My apologies for letting it go a little stale.  I'm not 
sure if I've made this clear before now, but there were some changes and 
additions to RegistrySharedObject for ECF 3.4 (making some more methods 
protected rather than private), which should allow more/more easy 
customization for adding authorization.

So, to continue the discussion a little bit...Franky said:

>What happens with the thread in which the remote call is done (in 
RegistrySharedObject.executeRequest method)?

On the service host (i.e. the receiver of handleCallRequest), the 
sequence is (now...i.e. in 3.4 RegistrySharedObject.handleCallRequest) 
is as follows:

line 1476:  call getRequestExecutor().  This (private) method returns an 
IExecutor [1].   If the requestExecutor is null/not initialized, 
getRequestExecutor then calls
line 1385 createRequestExecutor() (protected).  This method creates an 
IExecutor.  There are currently several types of IExecutor...one based 
upon individual java threads, another based upon the Equinox Jobs API 
(the current default)...I would like one based upon Java5 concurrent 
API...or some other thread pool tech...but haven't had the time to do 
that...in any event...it's quite possible to create new types of 
IExecutor and have have custom behavior for executor.execute, which is 
ultimately called on line 1448 to execute the remote call asynchronously 
(that's the semantics of IExecutor.execute(...)).

Why did I describe this above?  Mostly because it's the IExecutor 
implementation that determines the answer to Franky's question about 
what happens with the thread after the remove call is done...and the 
answer is that the different IExecutor implementations do different 
things.  I.e. the ThreadsExecutor just ends the thread created for the 
request execution, the jobs executor adds the thread back to the 
available pool...other implementations can do other things.

Scott

[1] IExecutor is from org.eclipse.equinox.concurrent bundle.  I'm the 
original author of org.eclipse.equinox.concurrent content, and I 
contributed it to Equinox.  BTW, I'm trying to get the Equinox team to 
graduate the org.eclipse.equinox.concurrent bundle out of incubation, 
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=309247