From user-return-12234-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Aug 20 23:23:05 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 41090 invoked from network); 20 Aug 2010 23:23:05 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Aug 2010 23:23:05 -0000 Received: (qmail 28500 invoked by uid 500); 20 Aug 2010 23:23:04 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 28415 invoked by uid 500); 20 Aug 2010 23:23:03 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 28407 invoked by uid 99); 20 Aug 2010 23:23:03 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Aug 2010 23:23:03 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.215.180] (HELO mail-ey0-f180.google.com) (209.85.215.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Aug 2010 23:22:42 +0000 Received: by eya25 with SMTP id 25so3200809eya.11 for ; Fri, 20 Aug 2010 16:22:21 -0700 (PDT) Received: by 10.213.17.147 with SMTP id s19mr2086655eba.31.1282346541507; Fri, 20 Aug 2010 16:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.53.6 with HTTP; Fri, 20 Aug 2010 16:21:51 -0700 (PDT) In-Reply-To: References: <06E3A41A-4425-4C85-80BF-325F9342FC80@jbrisbin.com> From: Kenny Stone Date: Fri, 20 Aug 2010 18:21:51 -0500 Message-ID: Subject: Re: Scala view server? To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0015174bee0015e514048e4992a1 X-Virus-Checked: Checked by ClamAV on apache.org --0015174bee0015e514048e4992a1 Content-Type: text/plain; charset=ISO-8859-1 Couldn't you leverage the hovercraft API with JInterface pretty easily? I'm not sure why you would want to use the JVM when you have a perfectly capable erlang vm. Could you explain your use case to me? I'm curious. -- Kenny Stone Connamara Systems, LLC On Fri, Aug 20, 2010 at 2:15 PM, Paul Davis wrote: > On Fri, Aug 20, 2010 at 3:05 PM, Jon Brisbin wrote: > > > > On Aug 20, 2010, at 1:42 PM, Paul Davis wrote: > > > >> During a view build, a single process is used. Between two builds, > >> different processes may be used. If two builds are occurring > >> simultaneously, they will use two separate OS level processes. The > >> add_fun will re-add the function each time it starts a view build. The > >> reset command should remove references to installed functions. > >> > >> I think you could be right in that it'd be hard to integrate a JVM for > >> view processes because of its memory footprint in some situations with > >> lots of simultaneous view builds. I was going through and refactoring > >> some of that code to behave a bit more nicely which would provide the > >> ability for you to do something with JInterface semi easily (i've > >> never worked with it directly, but the couch side would be easier than > >> it is currently). > >> > >> No idea if/when I'll finish that work though. I hit a stumbling block > >> with performance not improving much with the various optimizations I > >> had so I have to go back and do some profiling to figure out what's > >> going on. > >> > >> HTH, > >> Paul Davis > > > > > > In the <1 hour I've devoted to the topic so far, it seems like writing a > native_query_server that delegates to a Java process that's communicating > via JInterface would be the best way to integrate with Java/Scala. The Java > code could dispatch to workers via a BlockingQueue. > > > > I'm not an Erlang whiz, so I'm using this as an excuse to learn a little > Erlang (like I have time to learn yet another new language! :/) and see if I > can do this myself... > > > > Thanks! > > > > J. Brisbin > > http://jbrisbin.com/ > > > > Oh right, I forgot to suggest that. If you want to go ahead with > trying the JInterface on the current trunk, your best bet is to write > a file that matches the current Erlang view server implementation: > > > http://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_native_process.erl > > Feel free to ask questions if you get stuck. > --0015174bee0015e514048e4992a1--