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
