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
