Great, so maybe neo4j-index should be updated to depend on Lucene 2.9.3.

2010/7/9 Bill Janssen <jans...@parc.com>

> Note that a couple of memory issues are fixed in Lucene 2.9.3.  Leaking
> when indexing big docs, and indolent reclamation of space from the
> FieldCache.
>
> Bill
>
> Arijit Mukherjee <ariji...@gmail.com> wrote:
>
> > I've a similar problem. Although I'm not going out of memory yet, I can
> see
> > the heap constantly growing, and JProfiler says most of it is due to the
> > Lucene indexing. And even if I do the commit after every X transactions,
> > once the population is finished, the final commit is done, and the graph
> db
> > closed - the heap stays like that - almost full. An explicit gc will
> clean
> > up some part, but not fully.
> >
> > Arijit
> >
> > On 9 July 2010 17:00, Mattias Persson <matt...@neotechnology.com> wrote:
> >
> > > 2010/7/9 Marko Rodriguez <okramma...@gmail.com>
> > >
> > > > Hi,
> > > >
> > > > > Would it actually be worth something to be able to begin a
> transaction
> > > > which
> > > > > auto-committs stuff every X write operation, like a batch inserter
> mode
> > > > > which can be used in normal EmbeddedGraphDatabase? Kind of like:
> > > > >
> > > > >    graphDb.beginTx( Mode.BATCH_INSERT )
> > > > >
> > > > > ...so that you can start such a transaction and then just insert
> data
> > > > > without having to care about restarting it now and then?
> > > >
> > > > Thats cool! Does that already exist? In my code (like others on the
> list
> > > it
> > > > seems) I have a counter++ that every 20,000 inserts (some made up
> number
> > > > that is not going to throw an OutOfMemory) commits and the reopens a
> new
> > > > transaction. Sorta sux.
> > > >
> > >
> > > No it doesn't, I just wrote stuff which I though someone could think of
> as
> > > useful. A cool thing with just telling it to do a batch insert mode
> > > transaction (not the actual commit interval) is that it could look at
> how
> > > much memory it had to play around with and commit whenever it would be
> the
> > > most efficient, even having the ability to change the limit on the fly
> if
> > > the memory suddenly ran out.
> > >
> > >
> > > > Thanks,
> > > > Marko.
> > > >
> > > > _______________________________________________
> > > > Neo4j mailing list
> > > > User@lists.neo4j.org
> > > > https://lists.neo4j.org/mailman/listinfo/user
> > > >
> > >
> > >
> > >
> > > --
> > > Mattias Persson, [matt...@neotechnology.com]
> > > Hacker, Neo Technology
> > > www.neotechnology.com
> > > _______________________________________________
> > > Neo4j mailing list
> > > User@lists.neo4j.org
> > > https://lists.neo4j.org/mailman/listinfo/user
> > >
> >
> >
> >
> > --
> > "And when the night is cloudy,
> > There is still a light that shines on me,
> > Shine on until tomorrow, let it be."
> > _______________________________________________
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to