river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Clustered Jini Server? Was: Re: Mirroring to GitHub
Date Tue, 09 Jun 2015 18:35:29 GMT
One of the primary issues with trying to scale join applications is all of the locking and
blocking through the security subsystems.  Peter's work in this area should be a tremendously
visible performance boost for any app which has a high call load, such as data processing.

Gregg

Sent from my iPhone

> On Jun 2, 2015, at 8:37 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
> 
> Hi Palash,
> 
> 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.
> 
> HTH
> 
> Dennis
> 
> 
>> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray <paawak@gmail.com> wrote:
>> 
>> Excellent. May be we can help each other here.
>> 
>> Let me start by giving some more context around the problem.
>> 
>> *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.
>> 
>> 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.
>> 
>> 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.
>> 
>> I was doing a proof of concept using the Jini infrasctrure itself. These
>> were my thoughts:
>> 
>> *Option 1*
>> 
>> https://github.com/paawak/blog/tree/master/code/jini/unsecure/load-balancing
>> 
>> 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.
>> 
>> There are multiple reggie involved for load balancing. The following
>> convention is followed:
>> 
>> 1. The reggie for load balancer is at 6670
>> 2. The reggie for the actual jini servers are at 5561, 5562, 5563, etc.
>> 
>> When the load-balancer recieves a request from client, it does the
>> look-up at the appropriate jini-server and returns the remote service.
>> 
>> *Option 2*
>> https://github.com/paawak/jini-in-a-war
>> 
>> 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.
>> 
>> 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.
>> 
>> Thanks,
>> Palash.
>> 
>> 
>> 
>> 
>> 
>>> On Tue, Jun 2, 2015 at 2:14 PM, Patricia Shanahan <pats@acm.org> wrote:
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Patricia
>>> 
>>> 
>>>> On 6/2/2015 10:24 AM, Greg Trasuk wrote:
>>>> 
>>>> 
>>>> Palash:
>>>> 
>>>> Could you expand on your need for a “clustered Jini server”?  What
>>>> features are you looking for, and what aspects of the application need
>> to
>>>> be clustered?  This might provide fertile grounds for development.
>>>> 
>>>> Cheers,
>>>> 
>>>> Greg Trasuk
>>>> 
>>>>> On Jun 2, 2015, at 12:38 PM, Palash Ray <paawak@gmail.com> wrote:
>>>>> 
>>>>> Hi Greg, Patricia,
>>>>> 
>>>>> Really happy to see:
>>>>> https://github.com/trasukg/river-container
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 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.
>>>>> 
>>>>> To that end I was playing around the code a bit. I have some ideas
>>>>> which I can discuss with this group later.
>>>>> 
>>>>> 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
>>>>> 
>>>>> Also, I keep blogging about Jini with whatever little understanding I
>>>>> have:
>>>>> http://palashray.com/java/jini/
>>>>> 
>>>>> In the coming days, I look forward to contributing to the river
>> project.
>>>>> 
>>>>> Thanks,
>>>>> Palash.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 6/2/15, Greg Trasuk <trasukg@stratuscom.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Thanks, Jukka.  And by the way, I’m happy to see you’re still
watching
>>>>>> River!
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Greg Trasuk.
>>>>>> 
>>>>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting <jukka.zitting@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <trasukg@stratuscom.com>:
>>>>>>> 
>>>>>>>> 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’m not
>> sure
>>>>>>>> how to change that.
>>>>>>> 
>>>>>>> You can file an INFRA issue to get the default branch and other
>> GitHub
>>>>>>> metadata changed.
>>>>>>> 
>>>>>>> Jukka
>> 

Mime
View raw message