river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: River-examples project - followup
Date Mon, 13 Apr 2015 14:40:23 GMT

> On Apr 13, 2015, at 7:40 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
> 
> Some comments intertwined….
> 
> Cheers,
> 
> Greg Trasuk
> 
>>> From: greggwon@gmail.com
>>> Subject: Re: River-examples project - followup
>>> Date: Sat, 11 Apr 2015 23:50:26 -0500
>>> To: dev@river.apache.org
>>> 
> 
> …
> 
>>> 
>>> The other item would be to provide a new Jeri InvocationLayerFactory and Endpoint
which would allow a single port to be used for all inbound services.  The basic idea is that
the InvocationLayerFactory construction would provide some kind of mechanism for services
to be registered and authentication and everything would just work for multiple services on
the same endpoint.
>>> 
> 
> I could be wrong, but isn’t this already possible?  You can create multiple BasicJeriExporters
against the same ServerEndpoint (even HttpServerEndpoint if you want).   What features do
you want added to the InvocationLayerFactory?

Yes, but the wiring is a too complex of an initial learning curve.  Todays software developers
are 90% self taught, non-computer scientists.  If it doesn’t work the first time (well and
nearly every time), and takes more than 15mins to figure out, they will move on to something
else.  What we’d want to do, is make the wiring happen with annotations or simple “routing”
registrations which are much easier to look at in code, and which developers already know
how to use.

Currently, all the wiring is visible in the APIs.  It would really be nice to not have wiring
being one the first things you have to learn about.  We need to invert the learning tree so
that you first learn about registering and using a service, and that happens with a single
function call.  Next, if you need some variation, function, configuration different than the
default, you can learn how to peel back a layer and configure there.

> 
>>> Think about how HTTP routing works in most modern HTTP services.  The user might
use Annotations or something to mark the service entry points and we would then be able to
use that information to cause the InvocationLayerFactory to call out to the correct class
and method.
>>> 
>>> We really should look at creating an HTTP endpoint with the ability to use POST
as an inbound invocation that would deliver a JSON message to the function bound to that HTTP
request.  This would allow small, lightweight restful services to be created without a large
complex web server underneath it. 
>>> 
> 
> In that case, what interface would you publish to Reggie?

You would still publish an interface.  That is what will be called.  What the Endpoint and
ILF need to manage is the translation from a JSON standard message into a native invocation
path.  So, all the details of a method signature, parameters, and instance GUID would all
need to be mapped out into a JSON message.  The authentication and authorization would happen
through HTTP standards (including an SSL/TLS cert etc).

Gregg Wonderly

> 
>>> I think that this would make Jini on Raspberry Pi particularly alluring.
>>> 
>>> Gregg Wonderly
>>> 
>>> 
>>>> On Apr 8, 2015, at 9:12 PM, Patricia Shanahan <pats@acm.org> wrote:
>>>> 
>>>> Maybe it would be possible to put one or more of the richer functions in
an example? That would let us get practical experience before committing to an API change.
>>>> 
>>>> Patricia
>>>> 
>>>> On 4/8/2015 6:47 PM, Gregg Wonderly wrote:
>>>>> I think that it could be beneficial, to provide code examples, in
>>>>> some form that do the two different things that are possible to make
>>>>> this less visible.  First, show the reader how to use an exit hook in
>>>>> the tutorial to see the service registration disappear.  Second, show
>>>>> them how to use the lease timeout value to make the change happen
>>>>> automatically for the case of a network split or network card or
>>>>> computer failure that would keep the exit hook from ever generating
>>>>> network traffic to cancel the lease.
>>>>> 
>>>>> I still feel that we actually need new APIs that operate at a bit
>>>>> higher level and provide all of these things as parameters to richer
>>>>> functions.
>>>>> 
>>>>> Gregg Wonderly
>>>>> 
>>>>>> On Apr 6, 2015, at 8:56 PM, Greg Trasuk <trasukg@stratuscom.com>
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi all:
>>>>>> 
>>>>>> I updated the tutorial to include the discussion below in the
>>>>>> “hello-service” module.  ‘svn up’ should bring it down to
your
>>>>>> local machine.  I haven’t yet integrated Patricia’s formatting
>>>>>> suggestions, mainly because I have to dig in to Maven’s site
>>>>>> command a bit to include the correct css, but I’ll do that before
>>>>>> we release.
>>>>>> 
>>>>>> Any feedback is greatly appreciated.
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Greg Trasuk
>>>>>> 
>>>>>> On Apr 6, 2015, at 3:30 PM, Greg Trasuk <trasukg@stratuscom.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Hi Dan:
>>>>>>> 
>>>>>>> Thanks for the great feedback.
>>>>>>> 
>>>>>>> I’m pretty sure you already know this, Dan, since you’re
a
>>>>>>> long-time Jini user, but let me explain for the newer folks and
>>>>>>> the archives.  This is a case where what you’re seeing is the
>>>>>>> expected behaviour.  When the service registers itself with
>>>>>>> Reggie, it takes out a lease on the registration. That lease
is
>>>>>>> usually renewed periodically by the service’s JoinManager (that
>>>>>>> isn’t quite the whole story, but it’ll do for now).  When
you
>>>>>>> kill the service unexpectedly with ctrl-c, the service doesn’t
>>>>>>> de-register itself, however the lease eventually runs out (now
>>>>>>> that it’s not being renewed by the service) and then the
>>>>>>> registration expires, allowing Reggie to reclaim its resources
>>>>>>> and notify any registrar listeners.
>>>>>>> 
>>>>>>> It would be possible to register a vm shutdown hook to
>>>>>>> de-register the service before the vm exits, but in this case
I
>>>>>>> think it’s actually better to leave it out, since it demonstrates
>>>>>>> nicely that a dead  service (or at least a dead JoinManager)
>>>>>>> eventually gets dropped from the registrar.
>>>>>>> 
>>>>>>> You said the duplicate service instances “worked”, in that
you
>>>>>>> can show info and browse the service, but of course, you’re
>>>>>>> really just looking at the information that’s in the registry
-
>>>>>>> the registrar and service browser don’t actually contact the
>>>>>>> service.  Reggie has no knowledge of the “liveness” of the
>>>>>>> service, and doesn’t attempt to do any “health check”.
>>>>>>> 
>>>>>>> In fact, it’s a common misconception that if the service renews
>>>>>>> the lease, it must be “live”.  This turns out to be false
for
>>>>>>> many reasons.  (1) The service could have delegated its lease
>>>>>>> renewals to a different service.  (2) There’s no guarantee
that
>>>>>>> failure of the actual service thread would also cause failure
of
>>>>>>> the lease renewal thread, even if they are in the same process
>>>>>>> (embedded programmers might recognize this as being similar to
>>>>>>> the “resetting the watchdog in a timer-triggered interrupt
>>>>>>> service routine” problem).  (3) Even if there were a health
check
>>>>>>> task, the service could fail in the instant just after the health
>>>>>>> check.  The most a health check, monitor or heartbeat can do
is
>>>>>>> place a limit on how long it takes to find out a service has
>>>>>>> failed.  The only way to say with certainty that a service
>>>>>>> “works” is to attempt to use it.
>>>>>>> 
>>>>>>> The lease is purely for the convenience of the registrar (or
>>>>>>> generically, the service granting the lease).  If ever the lease
>>>>>>> is not renewed, the landlord can go ahead and reclaim whatever
>>>>>>> resources were dedicated to the lease.  In the case of Reggie,
if
>>>>>>> the lease isn’t renewed, Reggie drops the registration.  So
>>>>>>> there’s little risk of “stuck registrations”.  And since
the
>>>>>>> lease can be renewed, there’s no need for any kind of extended
>>>>>>> default timeout.
>>>>>>> 
>>>>>>> So, I think I’ll put most of the above explanation into the
>>>>>>> tutorial, unless anyone has other thoughts.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Greg Trasuk
>>>>>>> 
>>>>>>> On Apr 6, 2015, at 1:42 PM, Dan Rollo <danrollo@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi Greg,
>>>>>>>> 
>>>>>>>> I finally took some time to try this out. It really looks
great
>>>>>>>> to me!
>>>>>>>> 
>>>>>>>> I noticed one minor thing that I thought might confuse users:
>>>>>>>> While going through tutorial steps, I decided to stop (via
>>>>>>>> cntrl+c) are restart the hello-service a couple times. This
>>>>>>>> resulted in the service being shown multiple times in the
>>>>>>>> service browser (screenshot attached). It appeared all the
>>>>>>>> duplicate instances in the browser “worked” (I could
“show
>>>>>>>> info” and “browse service” on all of them). Eventually,
the
>>>>>>>> duplicate registrations “cleaned up” and I was left with
just
>>>>>>>> one. I’m not sure how best to avoid confusion about this
>>>>>>>> situation. Would more doc about “why”/“how” that
works just
>>>>>>>> complicate things? Is there any sort of “force lease check”
to
>>>>>>>> do in the browser that could clear up the duplicates sooner?
>>>>>>>> (And if so, would that be worth noting in the tutorial?).
So
>>>>>>>> basically, not sure this is a “problem”, but thought
I’d ask…
>>>>>>>> 
>>>>>>>> Thanks! Dan
>>>>>>>> 
>>>>>>>> <revier-examples-RepeatedService.png>
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 		 	   		  
> 


Mime
View raw message