1 getBundleGraph()
public LockableMGraph getBundleGraph() {
return this.tcManager.getMGraph(ClipsMain.GRAPH_URI);
}
2 creation of GraphBNode we pass to adToLuceneIndex
GraphNode node= new GraphNode(uri, this.getContentGraph);
where this.getContentGraph is
public LockableMGraph getClipsContentGraph() {
if (clipsContentGraph == null) {
logger.info("Create ClipsContentGraph");
clipsContentGraph = (LockableMGraph) new
UnionMGraph(this.contentGraphProvider.getContentGraph(), this.getBundleGraph());
}
return clipsContentGraph;
}
so now I see the difference myself. it's a UnionMGraph. And that one propably
gets pretty big.
-----Ursprüngliche Nachricht-----
Von: Hasan Hasan [mailto:[email protected]]
Gesendet: Dienstag, 8. Februar 2011 13:59
An: [email protected]
Betreff: Re: [jira] Created: (CLEREZZA-418) Strange behaviour of GraphNode
what this.getBundleGraph() does actually?
how is the GraphNode created that you pass to addToLuceneIndex? (in
particular how you get the graph that is used to create the GraphNode
the type of MGraph used to create the GraphNode might explain the "strange"
behavior
regards
hasan
On Tue, Feb 8, 2011 at 1:29 PM, franco fallica (JIRA) <[email protected]>wrote:
> Strange behaviour of GraphNode
> ------------------------------
>
> Key: CLEREZZA-418
> URL: https://issues.apache.org/jira/browse/CLEREZZA-418
> Project: Clerezza
> Issue Type: Question
> Environment: win7
> Reporter: franco fallica
> Priority: Minor
>
>
> Hi all,
>
> I just ran into an interesting issue, and I want to let you know.
>
> I've got a method like that. ( We use that GraphNode a lot before we pass
> it to that method)
>
> protected void addToLuceneIndex(GraphNode clip){
> (0)
> // then some stuff like that
> Document doc = new Document();
> Iterator<Literal> iter;
> doc.add(new Field(LuceneDocumentClips.url,
> URLParser.formIndexableURL(((UriRef) clip.getNode()).getUnicodeString()),
> Field.Store.YES, Field.Index.NOT_ANALYZED));
> (1) System.out.println("before getLiterals");
> iter = clip.getLiterals(DCTERMS.title);
> (2) System.out.println("after getLiterals");
> while (iter.hasNext()) {
> doc.add(new Field(LuceneDocumentClips.title,
> iter.next().getLexicalForm().trim(), Field.Store.NO,
> Field.Index.ANALYZED));
> }
> // and some more
> }
>
> with this method. Line (2) "after getLiterals" is never reached and jvm
> throws a OutOfMemoryException (Heap space) right on getLiterals()
>
> I changed the method on line (0) to:
>
> protected void addToLuceneIndex(GraphNode clipNode) {
> (0) GraphNode clip = new GraphNode(clipNode.getNode(),
> this.getBundleGraph());
>
> // the same stuff as before
> ...
> ...
>
> }
>
> and strangely it works!
>
> Why in gods name can instatiating a new GraphNode (of a allready
> instatiated node) fix a OutOfMemoryException?
>
> even stranger - CommittableGraphNode fixes the issue as well :
>
> protected void addToLuceneIndex(GraphNode clipNode) {
> (0) CommittableGraphNode clip = new CommittableGraphNode
> (clipNode.getNode(),new CommittableMGraph(new LockableMGraph(
> this.getBundleGraph())));
>
> // the same stuff as before
> ...
> ...
>
> }
>
>
> and just to make things more interessting. the following fixes it too.
>
> protected void addToLuceneIndex(GraphNode clipNode) {
> (0) GraphNode clip = new GraphNode (clipNode.getNode(),new
> CommittableMGraph(new LockableMGraph( this.getBundleGraph())));
>
> // the same stuff as before
> ...
> ...
>
> }
>
> --
> This message is automatically generated by JIRA.
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
