Hi Laura > Testing on the current version of jackrabbit shows significant reduction is > performance when we hit upwards of 100K documents.
This sound like you are storing all documents in a flat list within a single parent node. This is a known (design) limitation in Jackrabbit. You should be able to work around this by creating a hierarchy and store < 10k documents within a single parent node. With such a structure storing 1 million documents should not cause performance problems. Oak can handle larger child lists, as long as the parent node is not orderable. Hope this helps. Regards Julian On Mon, Nov 10, 2014 at 6:08 PM, O'Donnell, Laura <lodonn...@inmedius.com> wrote: > Our company is currently using jackrabbit embedded into our product. > > We run on JBoss and access jackrabbit through JCA, and have stored the > jackrabbit content in an oracle database. > > Our current product is being revamped to be able to handle as much as 1 > million documents, so we need a responsive repository that can do the same. > > Testing on the current version of jackrabbit shows significant reduction is > performance when we hit upwards of 100K documents. > > So, we are looking for alternatives. OAK obviously is the first question. > However, in order to consider OAK we need to know the following? > > Can OAK run in JBOSS like jackrabbit did? > > Can we use an Oracle or MySQL db to store the OAK content? > > Is there a plan to expose a build that we can use instead of requiring users > to compile the source and then try to figure out which jars are necessary? > > If the answer is no to the above questions, is there a timeframe where any of > the above are planned to be available? > > We are at a point where we need to decide whether OAK should even be > considered within our plans, so any information on the above would be > appreciated. > > > > Thanks, > > Laura O'Donnell >
