On Fri, Aug 20, 2010 at 3:05 PM, Jon Brisbin <[email protected]> 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.
