[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] RemoteService + Context
|
Hi Scott,
No problem for the late reply, I know you're quite busy with ECF 3.4 release ;-).
Thanks for the answer. I'll have a look at the latest changes, but my first impression (without looking at the code) is that the extensibility of createRequestExecutor can be used to perform the security context clean up (on thread local) that is needed in my use case. If this is the case I will come up with a full example to share with the community.
Franky
2010/10/27 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?
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
