So based on this, we should document safe methods for exporting services, log a
message using fine and reference the documentation in the message.
Peter.
----- Original message -----
> Pat your comment about non final fields is interesting.
>
> Isn't it also the case that we need to safely publish an effectively
> immutable object to share it among threads? That usually means copying
> it to a thread safe collection or shared via a synchronized method,
> volatile field, or final field in another object?
>
> So we should also make sure that Jeri uses safe publication during
> export.
>
> That would allow a service that has no final fields to start threads,
> then export from within a constructor safely, provided all operations on
> non final fields happen before starting threads and exporting.
>
> All our services have final fields, so Starter is more appropriate for
> River's own services.
>
> Regards,
>
> Peter.
>
> ----- Original message -----
> > Hmm, good point, Startable, makes more sense.
> >
> > An object can be exported using Startable.
> >
> > I think we should have a policy to strongly discourage exporting from
> > constructors.
> >
> > Regards,
> >
> > Peter.
> >
> > ----- Original message -----
> > > As far as I can tell, the special properties of completing a
> > > constructor in the JLS memory model are:
> > >
> > > 1. A happens-before edge from the end of the constructor to the start
> > > of a finalizer. (17.4.5)
> > >
> > > 2. The guarantee that any thread that only sees a reference to an
> > > object after the end of the constructor will see the correctly
> > > initialized values of all final fields. (17.5)
> > >
> > > The special issue with final fields is that implementations have
> > > freedom to optimize access to final fields in ways that are not
> > > permitted for non-final fields. Strategies for thread safety that
> > > work for non-final fields do not necessarily work for final fields.
> > > The requirement for final field safety is that the constructor end
> > > before another thread accesses the newly constructed object.
> > >
> > > Calling a start() method after construction if the class implements
> > > a new interface seems to me to be harmless, backwards compatible,
> > > and useful. It enables the simplest and most direct way of
> > > preventing access to the new object by another thread during
> > > construction.
> > >
> > > The roadmap issue is whether it should be required, and if so the
> > > level of enforcement. For example, there is no reason to require it
> > > if the class does not declare any final fields.
> > >
> > > Incidentally, and as a detail, "Commission" does not immediately make
> > > me think of having a start() method that should be called after
> > > construction. If you do go this way, the name needs thought.
> > > "Startable" would be more obvious, more memorable, more likely to
> > > be found on searches, and more compatible with familiar interface
> > > names such as "Cloneable" and "Iterable".
> > >
> > > Patricia
> > >
> > >
> > > On 12/18/2013 2:18 AM, Peter wrote:
> > > > Well, now seems like a good time to have the conversation.
> > > >
> > > > Yes there are other ways, but I haven't seen one safe
> > > > implementation yet, so...
> > > >
> > > > Does someone have a better way to solve this problem, has someone
> > > > already solved this problem I'm unaware of that we can adopt, or is
> > > > there a way that's more satisfactory?
> > > >
> > > > If not, is there something objectionable with the Commission
> > > > interface and if so, how can we fix it?
> > > >
> > > > The SEVERE log message is logged by the River start package, other
> > > > containers or frameworks can choose whether or not to do so, but
> > > > I'd encourage them to do something similar, yes we can change it
> > > > to WARN.
> > > >
> > > > A much harsher option is to throw an exception during export which
> > > > breaks backward compatibility.
> > > >
> > > > Regards,
> > > >
> > > > Peter.
> > > >
> > > > ----- Original message -----
> > > > > "org.apache.river.api.util.Commission is an interface services
> > > > > should implement"
> > > > >
> > > > > If it's a SHOULD, not a MUST, chucking out a SEVERE is incorrect
> > > > > logger behaviour IMO. You could issue a WARN if you like but for
> > > > > even that I'd say you need to provide a roadmap explaining why
> > > > > the warning and what you intend to do in future and what you
> > > > > expect of service writers such as myself.
> > > > >
> > > > > Commission, at least from my point of view, is your means (maybe
> > > > > the River community's - did you ask us?) for satisfying your
> > > > > needs in respect of the JMM. As we've discussed previously,
> > > > > there are other ways too and they work and they are safe if you
> > > > > know what you're doing. Your contention was that most don't know
> > > > > what they're doing hence, presumably, Commission.
> > > > >
> > > > > So the thing is, you are seemingly on a road to asserting more
> > > > > structure (gosh, a standard?) on the way people write their
> > > > > services. If so, you'd best start flagging that honestly and
> > > > > openly via a roadmap, deprecation and such/whatever rather than
> > > > > sticking out logger messages with no clear guidance and at the
> > > > > cost of a certain amount of nuisance (no admin I know likes
> > > > > SEVERE's being logged for something which isn't critical cos
> > > > > it's noise they don't want in log files).
> > > > >
> > > > > And of course, we all know that when some entity asserts a
> > > > > standard or requirement on others for entry, they may choose not
> > > > > to enter. Does this help your community or hinder it? The answer
> > > > > to that is, it depends. On what? Have you asked or tested? How
> > > > > have you tested? What would be considered validation or lack of
> > > > > support?
> > > > >
> > > > > I am not out to flame or troll rather I want to see this
> > > > > community demonstrating good behaviour and I'm not feeling like
> > > > > what's going on around Commission (what is that big change in
> > > > > version number really saying?) is such.
> > > > >
> > > > > On 18 December 2013 08:52, Peter <j...@zeus.net.au> wrote:
> > > > >
> > > > > > Just to clarify org.apache.river.api.util.Commission is an
> > > > > > interface services should implement, I would encourage all
> > > > > > container projects to pick up the interface and make
> > > > > > suggestions for improvement if there are any issues.
> > > > > >
> > > > > > Interface Commission {
> > > > > > void start () throws Exception;
> > > > > > }
> > > > > >
> > > > > > It's called after JMM safe construction to allow the service to
> > > > > > start any threads and be exported.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Peter.
> > > > > >
> > > > > > ----- Original message -----
> > > > > > >
> > > > > > > The way that services are instantiated and setup is an
> > > > > > > implementation detail. When I think of
> > > > > > > compatibility I think of the API and the lookup methods.
> > > > > > > We think of compatibility from a client point of view.
> > > > > > > From the client point of view, using a service
> > > > > > > looks like this:
> > > > > > >
> > > > > > > - Use multicast of unicast discovery to find one or more
> > > > > > > ServiceRegistrar instances - Call lookup(…) on
> > > > > > > one or more of these instances to get a set of service
> > > > > > > candidates - Choose a candidate and prepare() it
> > > > > > > using a ProxyPreparer, to yield a usable service proxy.
> > > > > > > - Make calls on it. Ideally hang on to this
> > > > > > > proxy instance, so you can skip the discovery and lookup
> > > > > > > next time you need it. - If the call fails,
> > > > > > > repeat the lookup (and possibly discovery) til you get a
> > > > > > > proxy that works.
> > > > > > >
> > > > > > > Nowhere does the client need to know whether the service
> > > > > > > instance is started up using the “com.sun.jini.start”
> > > > > > > mechanism, your Commission interface, some other IOC
> > > > > > > container (Rio, Harvester, Seven or RiverContainer) or some
> > > > > > > unknown mechanism that starts with a static main() method.
> > > > > > >
> > > > > > > JSK2.0 was 2.0 because of the introduction of the proxy
> > > > > > > verification mechanisms, as well as JERI. Absent
> > > > > > > some new client usage mechanism, River doesn’t need to go to
> > > > > > > 3.0.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Greg.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Dec 17, 2013, at 1:58 PM, Peter <j...@zeus.net.au> wrote:
> > > > > > >
> > > > > > > > I think changing services to use safe construction
> > > > > > > > techniques is enough to cause the version jump.
> > > > > > > >
> > > > > > > > At this point I've allowed services to continue unsafe
> > > > > > > > construction practices, while logging a SEVERE warning when
> > > > > > > > the Commission interface isn't implemented, rather than
> > > > > > > > fail.
> > > > > > > >
> > > > > > > > This is a fundamental change to the way services are
> > > > > > > > written.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Peter.
> > > > > > > >
> > > > > > > > ----- Original message -----
> > > > > > > > >
> > > > > > > > > Assuming that there aren’t major incompatibilities, I
> > > > > > > > > think that would be a “minor” version change according
> > > > > > > > > to our versioning policy, so we’d be looking at the
> > > > > > > > > “2.3” branch rather than a “3.0” release.
> > > > > > > > >
> > > > > > > > > I’m still unnerved by the massive amounts of changes to
> > > > > > > > > both code and tests in the qa_refactor branch, as well as
> > > > > > > > > the apparent instability of the code, although that seems
> > > > > > > > > to be improving. In the next few weeks
> > > > > > > > > I’m going to try and setup a cross-test case, to see
> > > > > > > > > what the “2.2” tests say about the potential “2.3”
> > > > > > > > > release and vice-versa.
> > > > > > > > >
> > > > > > > > > I think what I’d really like to see is an incremental
> > > > > > > > > approach where we update limited components of the “2.2”
> > > > > > > > > branch, one at a time. Is there anything that we could
> > > > > > > > > pull out piecemeal? Maybe it
> > > > > > would
> > > > > > > > > make sense to split out the infrastructure services, like
> > > > > > > > > Reggie, Mahalo, and Outrigger into different sub-projects
> > > > > > > > > that could be updated separately?
> > > > > > > > >
> > > > > > > > > Any thoughts?
> > > > > > > > >
> > > > > > > > > Greg.
> > > > > > > > >
> > > > > > > > > On Dec 17, 2013, at 5:03 AM, Peter <j...@zeus.net.au>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > When the qa_refactor branch stabilises, I plan to merge
> > > > > > > > > > trunk and provide a beta release for client
> > > > > > > > > > compatibility testing.
> > > > > > > > > >
> > > > > > > > > > Changes made have been focused on making our code
> > > > > > > > > > thread safe, there are significant changes internally,
> > > > > > > > > > the public api remains focused on backward
> > > > > > > > > > compatibility, however it is advisable that client
> > > > > > > > > > services adopt new safe construction techniques for
> > > > > > > > > > services and implement the new Commission interface.
> > > > > > > > > >
> > > > > > > > > > What's a suitable test period for client testing?
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Peter.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > >
> >
>
