Chris, I would look at this code by Mike Perham, which demonstrates how to mediate access to objects from lots of threads. He uses the technique to build a DB connection pool, but I think it applies to your situation as well.
https://github.com/mperham/connection_pool/blob/master/lib/connection_pool/timed_stack.rb >From that base, you would then probably need to layer on some way of checking out a specific object by session-id and tracking a last used timestamp so that you can sweep things out. As for splitting out the app into an MRI and a JRuby piece, that sounds like a lot of work and Im not sure what you would gain from that except added operational complexity. If Heroku is your issue maybe its time to revisit your deployment strategy. - john On Mon, Apr 28, 2014 at 12:27 AM, Chris McCann <[email protected]>wrote: > SD Ruby, > > I've decided to pull apart an app I've been working on for a long time > into the main front-end Rails app using MRI Ruby and a back-end service API > using JRuby. > > If anyone remembers my JRuby talk from a year or so ago, this is the same > app. I'm using JRuby because I need the Apache POI library to update and > retrieve formula values from a complex financial analysis Excel spreadsheet. > > My goal is to separate the spreadsheet engine from the rest of the app, > which will help with several memory and scalability issues. > > Here's what I'm trying to achieve: > > - When the user wants to interact with the financial analysis an initial > request will be made to the service API. A unique ID for their session > will be passed in that call. > > - The service will create an instance of the Ruby class that interfaces > with the spreadsheet library and load up a copy of the spreadsheet. > > - The user can then make API calls to set input values in the spreadsheet > and retrieve the recalculated formula values for display in a Rails view > back in the client. > > What I'm wrestling with is the stateful nature of this interaction. The > creation of the in-memory POI spreadsheet classes is expensive, so I only > want to have to do that once for each "session" in which the user interacts > with the financial analysis. Once the spreadsheet interface classes are > loaded up the setting of input values and retrieving of formula values is > pretty speedy. > > In production there could be dozens or hundreds of users all working with > their own copy of the financial analysis spreadsheet model via the service > API. > > I also want to keep from blowing up the memory requirements for keeping > possibly hundreds of the financial analysis service models around longer > than necessary. The typical user interaction will only need them to be > around for a short while, say, 20-30 minutes. > > What approach do you recommend for keeping the service-side models around > between API requests? I should probably consider a sweeper of some sort as > well to clean up instances that haven't been used in a while. > > Any suggested approaches would be greatly appreciated. If I get an > elegant implementation of this working I'll be happy to share it via an SD > Ruby talk. > > Thanks! > > Chris > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups > "SD Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
