hello, just need to give my 2 cents: static fields with state in a webapplication is a synonym for "having concurrency problems" for me. I just have a rough idea how classloaders work with j2ee but I do not see how several threads can run with the same context classloader and having only one runtime. other stateful object like transactions are put into a static threadlocal to allow concurrency.
regards Kristian On Wed, Jan 6, 2010 at 9:54 PM, Yoko Harada <[email protected]> wrote: > On Wed, Jan 6, 2010 at 10:29 AM, Rob Heittman > <[email protected]> wrote: >> I have to think through this a bit. It should not be a problem to have a >> static runtime, and make everything to do with class loading >> classloader-specific. My concerns have to do with state; we have situations >> where the same application embeds several JRuby runtimes that persist >> different state and serve different purposes -- for example, a Rails app and >> various user-interactive scripting contexts. > > I have the same concern about the state. Current Ruby runtime has many > states. Some of them are ok for VM wide state, but others are not. I > think we should decouple no VM wide state from Ruby runtime. > >> It's OK for all of these to share the same class loading environment (and we >> do actually share them now as much as we can by setting the class cache >> explicitly). The Red Bridge stuff currently makes a strong effort to >> separate out Ruby application global state from runtime state -- but for >> various little reasons we haven't been able to go there 100% yet. I haven't >> drilled into it in great detail, but one fear I have is of there being a lot >> of overhead (and possibly resulting synchronization and delay) associated >> with re-establishing state, when one runtime is being used to serve multiple >> purposes. >> There is also some study to be done here from the OSGi perspective. Right >> now I think -- fairly -- there is a lot more fit for JRuby with the command >> line and JEE class loading models than OSGi. This almost certainly >> correctly reflects installed base. But I believe that OSGi, or at least >> some variation on the theme that provides better classloader isolation, >> organization, and lifecycle support, is extremely important looking forward. >> Since this proposed effort is Not Trivial, it seems like this is a good >> opportunity to look at these user stories more intently. I was planning to >> have a fresh look at OSGi issues in JRuby 1.4 due to a recent post on the >> list anyway. > > Yes, OSGi issues should be resolved since people want to use JRuby on > OSGi environment. To make this happen, JRuby needs to consider OSGi > specific classloading way. Current JRuby doesn't work well with OSGi. > > -Yoko > >> On Wed, Jan 6, 2010 at 9:58 AM, Charles Oliver Nutter <[email protected]> >> wrote: >>> >>> Ok, it's time to start biting off a big change: we need to make the >>> JRuby runtime be classloader-global (i.e. static). >>> >>> There's many reasons for this: >>> >>> * You won't have to pass a Ruby instance into object construction >>> * Serialization will work, since it will just be able to grab the >>> classloader-global Ruby instance when constructing >>> * All core classes will be able to start inline caching calls back to >>> Ruby (where they do almost *no* caching right now) >>> * Replacing arbitrary pieces of Java code with Ruby code will be *much* >>> easier >>> >>> And the list goes on. >>> >>> Perhaps the most important person I'd like to see in this discussion >>> would be Yoko Harada, since it may be possible to hide all this behind >>> RedBridge and the 223/BSF engines. But I'd like to hear from others >>> interested in the above features/changes, or from anyone with concerns >>> about how this change might affect their code. >>> >>> For the record, this will almost exclusively impact only users >>> embedding JRuby or calling into JRuby from non-Ruby code. Users >>> running plain-old-Ruby probably will never see any real impact. >>> >>> - Charlie >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Kristian Meier + Saumya Sharma + Sanuka Meier Vadakkethu House, Edayanmula West PO - 689532, Pathanamthitta District, Kerala, INDIA tel: +91 468 2319577 protect your privacy while searching the net: www.ixquick.com _=_ q(-_-)p '_) (_` /__/ \ _(<_ / )_ (__\_\_|_/__) --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
