Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] RemoteService + Context

Hi Franky,

On 10/27/2010 6:25 AM, Franky Bridelance wrote:
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 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 any'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.


[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

Back to the top