river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Distributed Garbage Collection & Security - InvocationConstraints
Date Mon, 20 Jun 2011 22:41:49 GMT
In my applications, I always use a higher level leasing mechanism to indicate 
the clients continued interest in the remote object.  I have a "smart proxy" 
super-class that I use to manage this.  It uses my LeaseReferenceTracker class 
to use a PhantomReference to watch the proxy lifecycle.  You can subclass this 
class as a proxy object or as an invocation handler.  The subclass can use 
getRemote() to get the real proxy instance for reflective (as an invocation 
handler) or delegate based (as a complete object implementing the service 
interface) calls.

I've just found this to work best for me.  Thus, the constraints are in the 
Subject/constraints that the Lease Object uses, and are asserted in the same 
context that the proxy methods execute in.

Gregg

On 6/20/2011 5:07 PM, Peter Jones wrote:
> On Jun 19, 2011, at 5:37 AM, Peter Firmstone wrote:
>> The easiest way to set DGC constraints would be via configuration.
>>
>> Perhaps the reason this hasn't been implemented previously is, the constraints would
apply to all services that use DGC, so if you've set Authentication and Integrity as minimal
constraints, then this would apply to all services.
>
> As mentioned offline, I'm not sure how much of this I can page into my consciousness
at the moment.
>
> Configuring the server-side constraints for DGC could probably be supported with additional
parameters to the export process (and thus set via configuration).  The bigger issue, I think,
is what client constraints to apply, and what client subject to use, when JERI's client-side
DGC system (defined within BasicObjectEndpoint) makes "dirty" and "clean" calls on behalf
of the application.  In the traditional RMI DGC model, those calls happen implicitly as remote
references appear and disappear from a JVM.  But in the JERI security model, the client application
controls the security behavior of remote calls by explicitly (with respect to the standard
JERI layers) specifying constraints and controlling the current subject.
>
> So when the system wants to make a "dirty" or "clean" call for a given remote reference
(forget batching for the moment), what constraints to apply, or what subject to use?  There
didn't seem to be an answer, without requiring the client application to interact with the
DGC system more explicitly, which would be a significant change from the RMI DGC model-- and,
I think, not something that seemed worth investing effort on at the time, especially given
that Jini services didn't seem to make use of RMI's DGC functionality in practice anyway (instead
they used higher-level leasing mechanisms to detect client "failure", and most interest was
around just being disable DGC for Jini services).
>
>> Exporter's javadoc has the following statement regarding the force parameter in unexport:
>>
>> <QUOTE>
>>
>> The |force| parameter serves to indicate whether or not the caller desires the unexport
to occur even if there are known remote calls pending or in progress to the remote object
that were made possible by this |Exporter|:
>>
>>    * If |force| is |true|, then the remote object will be forcibly
>>      unexported even if there are remote calls pending or in progress,
>>      and this method will return |true|.
>>    * If |force| is |false|, then this acts as a hint to the
>>      implementation that the remote object should not be unexported if
>>      there are known remote calls pending or in progress, and this
>>      method will either unexport the remote object and return |true| or
>>      not unexport the remote object and return |false|. If the
>>      implementation detects that there are indeed remote calls pending
>>      or in progress, then it should return |false|; otherwise, it must
>>      return |true|. If the implementation does not support being able
>>      to unexport conditionally based on knowledge of remote calls
>>      pending or in progress, then it must implement this method as if
>>      |force| were always |true|.
>>
>> If the remote object is unexported as a result of this method, then the implementation
may (and should, if possible) prevent remote calls in progress from being able to communicate
their results successfully.
>>
>> </QUOTE>
>>
>> I've updated the class Target that implements this functionality for BasicJeriExporter,
Target's unexport method now uses thread interruption to attempt to interrupt and abort in
process calls if force is specified.  Interruption has been successful with the current jeri
qa tests and can be seen in the exception output for some tests.
>
> FWIW, aborting the execution of in-progress calls, such as via thread interruption, wasn't
really the intent of that last sentence-- it was more that an implementation should feel free
(or encouraged) to prevent communicating the eventual result of such a call, when control
of the dispatching thread is returned to this layer of the system.
>
> Cheers,
>
> -- Peter
>
>


Mime
View raw message