river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: SourceAliveRemoteEvent Part II
Date Fri, 08 Jun 2007 08:14:18 GMT
Bob Scheifler wrote:
> Mark Brouwer wrote:
>>   SourceAliveRemoteEvent extends RemoteEvent
>>   SourceAliveNotificationTime implements InvocationConstraint
>>
>> You obtain the ServiceRegistrar proxy and prepare it with constraints
>> including a SourceAliveNotificationTime with a time-out or 30 seconds.
>>
>> You registering for receiving ServiceEvents through the
>> RemoteEventListener passed in with ServiceRegistrar.notify().
> 
> One thing that bothers me is the use of constraints to pass
> what seem to be method arguments.  It seems that this constraint
> is only applicable to the event registration method, and it
> isn't altering the communication semantics, it's being used as
> a way to pass extra arguments without altering the method signature.
> Both aspects feel outside the bounds of how I think constraints were
> originally intended to be used.  There isn't a bright line drawn,
> but from the constraint package javadoc: "At each remote call through
> a proxy, the proxy implementation is responsible for using communication
> mechanisms that satisfy the client's constraints."
> 
> I'm curious if you share any concerns here?

Yes I've had my concerns here and I agree we are on a slippery slope
given the way constraints are specified.

No doubt you can remember we've had our fair share of discussions over
the years with regard to the applicability of constraints for
controlling QoS aspects at the proxy level (working over multiple remote
method invocation, etc.) among other things.

I think there was also a discussion with JavaSpace05.contents of how to
control e.g. whether the MatchSet should be populated asynchronous or
when done in batches what the batch size should be (AFAIK none of the
JavaSpace05 implementation provide any QoS constraints in this area).

I tend to think an invocation constraint its influence should be allowed
to things that are a direct consequence of the remote method invocation.
In this case the event notifications caused by the event registration.
Although I agree the usage in the field of constraints is likely limited
(which is also due to that it is hard to work with them) and therefore
people are not likely to design them I have 2 others [1] in the pipeline
now that I have the tools and ability to work with them [2].

For me constraints have a similarity with the usage of Configuration to
many of the constructors of the utility classes, it can cater for
aspects that otherwise have to be represented by arguments that might
not be applicable to each and every implementation and to cater for
things not foreseen at design time.

So yes I'm concerned with some of the QoS constraints I've been thinking
of the past years given the current language, but less concerned about
whether it really incorrect. Maybe the language should be relaxed or
altered, although I have no idea of a better way to describe it.

One question for you, do you think the
com.sun.jini.discovery.MulticastMaxPacketSize constraint used for
controlling the size of the buffers used to receive incoming multicast
request and announcement packets is within the bounds of the semantics
for constraints?


[1] one constraint I have is to control whether logging to a logging
service must take place in a synchronous versus asynchronous way, see
http://www.cheiron.org/utils/release/v0.2/api/org/cheiron/logging/SynchronousLogging.html
. Another one I plan to work on some day is an experiment with batching
remote events for the inverted event model, allowing the backend to
batch all remote events in a window of x ms.

[2] as part of the security work for Seven I had the need for creating
BasicMethodConstraints by adding constraints to an existing set of
BasicMethodConstraints and this utility class I recently moved into
Cheiron Utils, see
http://www.cheiron.org/utils/release/v0.2/api/org/cheiron/util/ConstraintsUtils.html
. Together with the fact that currently ~100% of the implementations of
MethodConstraints returned by RemoteMethodControl.getConstraints() are
of the type BasicMethodConstraints you have a proper tool for constraint
manipulation with which you can create other nice utility
methods/classes. As an example see
http://www.cheiron.org/utils/release/v0.2/api/org/cheiron/util/logging/LogUtils.html#setSynchronousRemoteLogging(org.cheiron.logging.RemoteLogger,%20boolean)
-- 
Mark


Mime
View raw message