Return-Path: X-Original-To: apmail-river-dev-archive@www.apache.org Delivered-To: apmail-river-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C08621008E for ; Wed, 3 Jun 2015 01:17:07 +0000 (UTC) Received: (qmail 72037 invoked by uid 500); 3 Jun 2015 01:17:07 -0000 Delivered-To: apmail-river-dev-archive@river.apache.org Received: (qmail 72011 invoked by uid 500); 3 Jun 2015 01:17:07 -0000 Mailing-List: contact dev-help@river.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@river.apache.org Delivered-To: mailing list dev@river.apache.org Received: (qmail 71999 invoked by uid 99); 3 Jun 2015 01:17:07 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jun 2015 01:17:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id E4627C08D9 for ; Wed, 3 Jun 2015 01:17:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 8rFQuxBL1dJk for ; Wed, 3 Jun 2015 01:16:54 +0000 (UTC) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id CE0AC271A6 for ; Wed, 3 Jun 2015 01:16:53 +0000 (UTC) Received: by wizo1 with SMTP id o1so3754124wiz.1 for ; Tue, 02 Jun 2015 18:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rgGQNGYpyHf0KYSeqm4fVb0eYrHiFutDHAJZUXTDNcA=; b=1GOJ9Wp248ARwbFSqCvi0A1cABErfeiP0sXHVxXw4lvEVqjmaBVmwD/IQhecFsl0Ku vt8uWT/gxvTeHKzzJp6X2S8iPx98vPOs3NvHzGmDEoAkpGWdAK5POdRr4bzCDLEz0aid Xtg9OYgglebZ2hL8+imz50+o6E3WTpVWlMCZN8KCSyHZNGdSUkNzZLH3AqBrDeES1Vu2 5QzP6D3IAt7LlfoPcO/F2nJms+uJSH/sh0VudPhTrJ1u5By9VJwXqCmnC7JWTmke9TUR L9NE0YMLNK5TT9OjeZz+3hNFjuwF+hH4KXD1ezjgiIH+Ko8nhV4Jfj1Bg1orzAvSOVru 19dw== MIME-Version: 1.0 X-Received: by 10.194.24.70 with SMTP id s6mr4498522wjf.25.1433294212543; Tue, 02 Jun 2015 18:16:52 -0700 (PDT) Received: by 10.180.216.37 with HTTP; Tue, 2 Jun 2015 18:16:52 -0700 (PDT) In-Reply-To: <556DF292.7060407@acm.org> References: <18AB9DDD-7131-48A0-A419-7F9AC391EB32@stratuscom.com> <94144018-71D0-4127-9E3E-480C4CB07CFA@stratuscom.com> <8859C632-0B54-44DF-B48A-0F6C61CED3DE@stratuscom.com> <556DF292.7060407@acm.org> Date: Tue, 2 Jun 2015 21:16:52 -0400 Message-ID: Subject: Re: Clustered Jini Server? Was: Re: Mirroring to GitHub From: Palash Ray To: dev@river.apache.org Content-Type: multipart/alternative; boundary=047d7b4724d865ba6e051792d079 --047d7b4724d865ba6e051792d079 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-balancin= g 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 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 late= st > unreleased version, which I think may fix some scaling issues. If it stil= l > shows scaling problems, I want to track them down and see whether they ar= e > 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 o= f > 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 =E2=80=9Cclustered Jini server=E2=80= =9D? What >> features are you looking for, and what aspects of the application need t= o >> be clustered? This might provide fertile grounds for development. >> >> Cheers, >> >> Greg Trasuk >> >> On Jun 2, 2015, at 12:38 PM, Palash Ray 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 wrote: >>> >>>> >>>> Thanks, Jukka. And by the way, I=E2=80=99m happy to see you=E2=80=99r= e still watching >>>> River! >>>> >>>> Cheers, >>>> >>>> Greg Trasuk. >>>> >>>> On Jun 2, 2015, at 11:14 AM, Jukka Zitting >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> 2015-06-02 1:17 GMT-04:00 Greg Trasuk : >>>>> >>>>>> I notice that for some reason, the 2.1 branch shows up as current, s= o >>>>>> you >>>>>> need to switch >>>>>> to the 2.2 branch explicitly to see the latest releases. I=E2=80=99= m not sure >>>>>> how to change that. >>>>>> >>>>> >>>>> You can file an INFRA issue to get the default branch and other GitHu= b >>>>> metadata changed. >>>>> >>>>> Jukka >>>>> >>>> >>>> >>>> >> --047d7b4724d865ba6e051792d079--