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.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 >>
