Thanks Dennis, I will definitely explore that option. On Tue, Jun 2, 2015 at 9:37 PM, Dennis Reedy <dennis.re...@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 <paa...@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 <p...@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 <paa...@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 <tras...@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.zitt...@gmail.com> > > >>>>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk <tras...@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 > > >>>>> > > >>>> > > >>>> > > >>>> > > >> > > >
