woot thanks Saminda ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message----- From: Saminda Wijeratne <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, December 4, 2013 11:29 AM To: "[email protected]" <[email protected]> Subject: Re: Jackrabbit vs OpenJPA >+1. Thats a very good idea Chris. I think we have some performance >numbers as well to back our facts. > > > > >On Wed, Dec 4, 2013 at 11:12 AM, Chris Mattmann ><[email protected]> wrote: > >Thanks Saminda. My point was maybe grabbing that text below and then >sending to [email protected] and/or [email protected] and letting >them know they may be able to help you guys. > >Cheers, >Chris > > > >-----Original Message----- >From: Saminda Wijeratne <[email protected]> >Reply-To: "[email protected]" <[email protected]> > >Date: Wednesday, December 4, 2013 11:09 AM >To: "[email protected]" <[email protected]> >Subject: Re: Jackrabbit vs OpenJPA > >>Adding to what Raman said, we noticed a exponential-like drop in >>performance when extracting the data from a JackRabbit repository when >>adding more and more data. JackRabbit was chosen earlier because we >>wanted to persist the descriptors for the gateway. >> No of descriptors in the repository did not grow over time (other than >>occasional new descriptor when needed). Then we wanted to persist the >>workflow template (which can be a large document) and the experiment >>results. Issue was that experiment results grow >> over time and we noticed the exponential increase in data retrieval time >>to a point noticeable to a user (eg: XBaya would just freeze). >> >> >>Thus we started experimenting with using direct use of RDBMs instead and >>found it did not become slow drastically and had more control over >>picking and choosing the exact data to retrieve. >> >> >> >> >> >> >> >>On Wed, Dec 4, 2013 at 8:00 AM, Chris Mattmann >><[email protected]> wrote: >> >>Hey Guys, >> >>May be worth passing some of that along to the JackRabbit community? >> >>Cheers, >>Chris >> >> >> >>-----Original Message----- >>From: Raminder Singh <[email protected]> >>Reply-To: "[email protected]" <[email protected]> >>Date: Wednesday, December 4, 2013 7:50 AM >>To: "[email protected]" <[email protected]> >>Subject: Re: Jackrabbit vs OpenJPA >> >>> >>> >>> >>>Hi Sachith, >>> >>> >>>Airavata requirement was to persist job descriptors, state, metadata >>>etc. >>> We saw lot of over head using Jackrabbit, may be lot of >>>serialization/de-serialization going on. Jackrabbit is good for content >>>repository/management but when we were try to access >>> the content from remote machines using RMI protocol, it was really >>>getting slow. Lahiru may have more details about this. >>> >>> >>>Thanks >>>Raminder >>> >>>On Dec 4, 2013, at 3:11 AM, Sachith Withana <[email protected]> wrote: >>> >>> >>>Hi all, >>> >>> >>>Can someone please explain to me why you made the switch from Jackrabbit >>>to OpenJPA? >>>I'm curious of why you did that. >>> >>> >>>-- >>>Thanks,Sachith Dhanushka Withana >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >> >> > > > > > > > > >
