Thanks GregI got the instruction to get started.RegardsBishnu
Bishnu Prasad Gautam > Subject: Re: River-examples project - followup > From: tras...@stratuscom.com > Date: Wed, 8 Apr 2015 04:12:52 -0400 > To: dev@river.apache.org > > First, retrieve the project using Subversion. The instructions to get > started are in the README.md file at the top level of the project repository. > Basically, you need to checkout the project using svn, then build the > project using Maven. > > Once the project is built, the tutorial starting point will be in > target/site/index.html > > Cheers, > > Greg Trasuk > > On Apr 8, 2015, at 3:30 AM, Bishnu Gautam <bishn...@hotmail.com> wrote: > > > > > Hi GregThanks for the link. Sorry, I could not find the tutorial about > > hello-service. Did I miss something from the link below. However, there was > > the GreeterService.java file. > > RegardsBishnu > > > > > > Bishnu Prasad Gautam > > > > > >> From: tras...@stratuscom.com > >> Subject: Re: River-examples project - followup > >> Date: Tue, 7 Apr 2015 09:45:46 -0400 > >> To: dev@river.apache.org > >> > >> > >> http://svn.apache.org/repos/asf/river/river-examples/river-examples/trunk > >> is the public svn folder. > >> > >> Cheers, > >> > >> Greg Trasuk. > >> > >> On Apr 7, 2015, at 12:13 AM, Bishnu Gautam <bishn...@hotmail.com> wrote: > >> > >>> > >>> Hi Greg > >>> Could you send me the SVN info to download the tutorials and other > >>> information that you updated. It would be great if you send me those > >>> information. > >>> RegardsBishnu > >>> > >>> Bishnu Prasad Gautam > >>> > >>> > >>>> Subject: Re: River-examples project - followup > >>>> From: tras...@stratuscom.com > >>>> Date: Mon, 6 Apr 2015 21:56:14 -0400 > >>>> To: dev@river.apache.org > >>>> > >>>> > >>>> 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 <tras...@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 <danro...@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> > >>>>> > >>>> > >>> > >> > > >
