Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
From: Gregg Wonderly <gregg@wonderly.org>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Message-Id: <FAD43C36-B346-4684-8020-43B20A56470F@wonderly.org>
Date: Tue, 9 Jun 2015 13:38:31 -0500
References: 
 <CA+BHFodq34-A5O+b8hfhqcfoji6NMxEosfHOh5WT4ofYHdfm8A@mail.gmail.com>
 <18AB9DDD-7131-48A0-A419-7F9AC391EB32@stratuscom.com>
 <CAFYjYshRNAthh_8s0xPneYDJr5dhg7VfGoM6iFWinz=kcsP3LQ@mail.gmail.com>
 <94144018-71D0-4127-9E3E-480C4CB07CFA@stratuscom.com>
 <CA+BHFocD6YjrxfCM9uXr0H-MTYPYdUjYbyijqj028afktR48EQ@mail.gmail.com>
 <8859C632-0B54-44DF-B48A-0F6C61CED3DE@stratuscom.com>
 <556DF292.7060407@acm.org>
 <CA+BHFofhuw5Hfff_=Eo=S=tPaYCQ7F5qt=-=yz40bfvVVYA8zg@mail.gmail.com>
 <CAJuA6A6J2cw0TV6z-VKmYJv8F2qiAVmZ+786qHxeM=Qaw2NHGA@mail.gmail.com>
 <CA+BHFoeKeweRL9qyFWJQ4soe4CPSxHFCJW82zfM6pn5OCQ4KNA@mail.gmail.com>
 <CADsQA7he6=t-bNZdicXQocagQcEPdsY48iiX6t-EpnaAmAWgJA@mail.gmail.com>
 <CA+BHFoc-P-tgYS_ovOtyYFCX4WdDJXgb8P_0VspKtpyJQta-qw@mail.gmail.com>
In-Reply-To: 
 <CA+BHFoc-P-tgYS_ovOtyYFCX4WdDJXgb8P_0VspKtpyJQta-qw@mail.gmail.com>
To: "dev@river.apache.org" <dev@river.apache.org>
Sender: Gregg Wonderly <gregg@wonderly.org>

Any Java spaces client spends most of its time blocked on a read/take from t=
he space which makes it a very synchronous interface.

You would put work into the space and then turn right around an make a block=
ing take in most cases.

Gregg

Sent from my iPhone

> On Jun 3, 2015, at 6:42 AM, Palash Ray <paawak@gmail.com> wrote:
>=20
> Interesting thought about using Java Spaces. However, for us, there is an
> extra maintenance of the Java Spaces server in production, which is my
> worry. Moreover, in our application, it is always a synchronous call from
> the Swing client to the Jini server. It would be a lot of effort to make
> this an asynchronous call to Java Sapces. So for our kind of application,
> this would not be suitable.
>=20
> Thanks,
> Palash.
>=20
> On Wed, Jun 3, 2015 at 1:14 AM, Simon Roberts <
> simon@dancingcloudservices.com> wrote:
>=20
>> Hard to be sure if this is a sensible comment without knowing more about
>> what you're trying to do, but the typical "load balance" in a Jini
>> environment has traditionally been a Java Spaces server, into which "jobs=
"
>> (probably simply Runnable implementations) are placed. The clustered work=

>> engines are configured to take (in a transaction) a job from the space,
>> process it, and put it back with an attribute indicating completion. On
>> putting the job back, the original take transaction is committed.
>> Therefore, if the server crashes before the job is completed, the "take"
>> evaporates, and some other work engine gets to re-take, hopefully
>> completing successfully. This model allows any number of work engines to b=
e
>> load balanced for essentially zero communication between them, and no
>> actual load balancer exists (in the sense that no active component has to=

>> keep track of the work engines). The workers take as fast at they're able=

>> to do work, but no faster, so they don't get overloaded. You can bring
>> workers up, and shut them down, with zero reconfiguration.
>>=20
>> Cheers,
>> Simon
>>=20
>>=20
>>> On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray <paawak@gmail.com> wrote:
>>>=20
>>> Thanks Dennis, I will definitely explore that option.
>>>=20
>>> On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <dennis.reedy@gmail.com>
>>> wrote:
>>>=20
>>>> Hi Palash,
>>>>=20
>>>> Using reggie as a load balancer does not make the most sense, what you
>>> may
>>>> want to consider to to maintain a collection of discovered services and=

>>>> simply round robin across them. You might want to start looking at the
>>>> ServiceDiscoveryManager and the LookupCache for this.
>>>>=20
>>>> HTH
>>>>=20
>>>> Dennis
>>>>=20
>>>>=20
>>>>> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <paawak@gmail.com> wrote:
>>>>>=20
>>>>> Excellent. May be we can help each other here.
>>>>>=20
>>>>> Let me start by giving some more context around the problem.
>>>>>=20
>>>>> *Problem*
>>>>> Our middle tier that is a Jini-based rmi server. We have a Swing
>> client
>>>>> that connects to it. In the middle tier, we have lot of processing
>>> logic:
>>>>> fetch something from the database, do some calculation intensive
>>>>> processing, write the results back to the database.
>>>>>=20
>>>>> Of late there has been a huge increase of the loads: the no. of Swing
>>>>> clients has increased, as has the bulk of the data to be processed.
>> It
>>>> has
>>>>> come to a point, where our production server, which is a single
>>> machine,
>>>> is
>>>>> creaking under the load.
>>>>>=20
>>>>> So, we have decided to cluster it. We are planning to have at least 3
>>> or
>>>> 4
>>>>> Jini servers and a load balancer to spread out the load evenly.
>>>>>=20
>>>>> I was doing a proof of concept using the Jini infrasctrure itself.
>>> These
>>>>> were my thoughts:
>>>>>=20
>>>>> *Option 1*
>> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balanc=
ing
>>>>>=20
>>>>> The load balancing architecture here is very very simple. There is a
>>>>> single load balancer with its own reggie running at 6670. This is the
>>>>> primary contact point for all clients.
>>>>>=20
>>>>> There are multiple reggie involved for load balancing. The following
>>>>> convention is followed:
>>>>>=20
>>>>> 1. The reggie for load balancer is at 6670
>>>>> 2. The reggie for the actual jini servers are at 5561, 5562, 5563,
>> etc.
>>>>>=20
>>>>> When the load-balancer recieves a request from client, it does the
>>>>> look-up at the appropriate jini-server and returns the remote
>> service.
>>>>>=20
>>>>> *Option 2*
>>>>> https://github.com/paawak/jini-in-a-war
>>>>>=20
>>>>> I figured that if we can embed the Jini in a Tomcat and then
>> clustering
>>>> the
>>>>> Tomcat would be very easy. But this is still work in progress, and
>>> there
>>>>> are lot of details that I need to figure out.
>>>>>=20
>>>>> Please let me know if the above makes sense or is around the same
>>> things
>>>>> that interest you. I would like to have a out of the box Jini
>> solution
>>>>> that *just
>>>>> works*. And I am happy to code for any solution that you guys think
>>>> should
>>>>> be the way forward.
>>>>>=20
>>>>> Thanks,
>>>>> Palash.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pats@acm.org>
>>> wrote:
>>>>>=20
>>>>>> Also, if there is any chance the bottleneck is in River, I would be
>>>> very,
>>>>>> very interested in constructing a benchmark based on your workload
>>> that
>>>>>> demonstrates the scaling problem. I would like to run it against
>> the
>>>>> latest
>>>>>> unreleased version, which I think may fix some scaling issues. If
>> it
>>>>> still
>>>>>> shows scaling problems, I want to track them down and see whether
>>> they
>>>>> are
>>>>>> fixable without clustering.
>>>>>>=20
>>>>>> My most recent professional background, before retiring, was as a
>>>>>> performance architect working on multiprocessor servers for Cray
>>>> Research
>>>>>> and Sun Microsystems. When I first got involved in River I was
>>> thinking
>>>>> of
>>>>>> doing some performance analysis and improvement, one of my favorite
>>>>> games,
>>>>>> but could not find a suitable benchmark, or an actual user with a
>>>> scaling
>>>>>> problem.
>>>>>>=20
>>>>>> Patricia
>>>>>>=20
>>>>>>=20
>>>>>>> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>> Palash:
>>>>>>>=20
>>>>>>> Could you expand on your need for a =E2=80=9Cclustered Jini server=E2=
=80=9D?  What
>>>>>>> features are you looking for, and what aspects of the application
>>> need
>>>>> to
>>>>>>> be clustered?  This might provide fertile grounds for development.
>>>>>>>=20
>>>>>>> Cheers,
>>>>>>>=20
>>>>>>> Greg Trasuk
>>>>>>>=20
>>>>>>> On Jun 2, 2015, at 12:38 PM, Palash Ray <paawak@gmail.com>
>> wrote:
>>>>>>>>=20
>>>>>>>> Hi Greg, Patricia,
>>>>>>>>=20
>>>>>>>> Really happy to see:
>>>>>>>> https://github.com/trasukg/river-container
>>>>>>>>=20
>>>>>>>> I think we are off in the right direction. I have been using
>> river
>>>> for
>>>>>>>> almost 2 years now, but only recently started taking an interest
>> in
>>>>>>>> the code that makes it tick.
>>>>>>>>=20
>>>>>>>> Our organisation is facing some scalability issues with Jini of
>>> late,
>>>>>>>> well, I am not blaming Jini here, its just that we need a
>> clustered
>>>>>>>> Jini server.
>>>>>>>>=20
>>>>>>>> To that end I was playing around the code a bit. I have some
>> ideas
>>>>>>>> which I can discuss with this group later.
>>>>>>>>=20
>>>>>>>> I have created a small proof of concept of embedding Jini in a
>> war
>>>> and
>>>>>>>> running it in a webserver:
>>>>>>>> https://github.com/paawak/jini-in-a-war
>>>>>>>>=20
>>>>>>>> Also, I keep blogging about Jini with whatever little
>>> understanding I
>>>>>>>> have:
>>>>>>>> http://palashray.com/java/jini/
>>>>>>>>=20
>>>>>>>> In the coming days, I look forward to contributing to the river
>>>>> project.
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>> Palash.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On 6/2/15, Greg Trasuk <trasukg@stratuscom.com> wrote:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Thanks, Jukka.  And by the way, I=E2=80=99m happy to see you=E2=80=
=99re still
>>>> watching
>>>>>>>>> River!
>>>>>>>>>=20
>>>>>>>>> Cheers,
>>>>>>>>>=20
>>>>>>>>> Greg Trasuk.
>>>>>>>>>=20
>>>>>>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <
>>>> jukka.zitting@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>> Hi,
>>>>>>>>>>=20
>>>>>>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <trasukg@stratuscom.com
>>> :
>>>>>>>>>>=20
>>>>>>>>>>> I notice that for some reason, the 2.1 branch shows up as
>>> current,
>>>>> so
>>>>>>>>>>> you
>>>>>>>>>>> need to switch
>>>>>>>>>>> to the 2.2 branch explicitly to see the latest releases.  I=E2=80=
=99m
>>> not
>>>>> sure
>>>>>>>>>>> how to change that.
>>>>>>>>>>=20
>>>>>>>>>> You can file an INFRA issue to get the default branch and other
>>>>> GitHub
>>>>>>>>>> metadata changed.
>>>>>>>>>>=20
>>>>>>>>>> Jukka
>>=20
>>=20
>>=20
>> --
>> Simon Roberts
>> (303) 249 3613
>>=20