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).
Having thought about it, something with similar behaviour to a local
JVM's gc would be appropriate, for example, if code with higher
privilege allows a reference to escape into less privileged code, the
garbage collector won't collect it until it becomes unreferenced by all
code.
So it would seem appropriate to cache the first Subject (or Subjects)
who've called methods on the remote object and use it (them) for the DGC
client Subject. Different Target's might have different Subject's, so
we could perform Subject orientated batching.
The unprivileged code, wouldn't be able to call methods that had
constraints, similar to how an object with method guards works, however
any code that holds a strong reference would prevent that object from
being garbage collected.
I think this would be useful in an internet environment, where a
developer wants to export an object and hand it as a parameter to
another service, and have it unexported automatically when no longer
required.
Cheers,
Peter.
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
