incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: Bizarre ReferenceManager issue
Date Tue, 05 May 2009 00:28:12 GMT
Janne -- Just checked in a few unrelated tweaks to ReferenceManager,
so if you update now you'll see what I see.

Reproducing the issue is pretty easy. In Eclipse, just fire up
JSPWikiMarkupParserTest. I've that the "testParagraph4" test reliably
bombs due to heap exhaustion. However, the real culprit seems to be
testScandicPagename1  (4 tests above). Attaching a breakpoint just
about anywhere in that test (or below it) should show you how certain
Priha property files keep getting bigger. Mine are in
The second file ( seems to be the tricky one, at
least for me.

If you pretended this issue didn't exist, we'd be above a 94% pass
rate overall, which is getting manageable. If you are able to take a
look at this, that would be swell.

In the meanwhile, I'm tempted to take a whack at the page-renaming
code -- that seems to be the one major thing that isn't working now.
Where it lives, well, I can stick it back in PageRenamer for now.


On Mon, May 4, 2009 at 3:31 PM, Andrew Jaquith
<> wrote:
> I've got a few changes to check in first; these fix some unrelated
> issues. But the tests in question are still broken, so you'll see 'em
> when you run them. With the checkin tonight, I'll provide some
> guidance on where to put breakpoints so you can see the file bloat. :)
>  --Andrew
> On Mon, May 4, 2009 at 2:09 PM, Janne Jalkanen <> wrote:
>> Could very well be; the default FileProvider might have some issues in some
>> corner cases. Can you leave the tests in a non-running state so that I can
>> debug them?
>> Multi-valued properties are the right way I think. (Nodes don't store any
>> data as such.)
>> /Janne
>> On 4 May 2009, at 16:02, Andrew Jaquith wrote:
>>> Howdy -- I just committed a big re-write of ReferenceManager that
>>> fixed all of the broken unit tests, and integrated is with JCR. It's
>>> not perfect, but it's a good start and it seems to work.
>>> Except in one case that I can't explain. It seems to be Priha-related.
>>> Some background on the new ReferenceManager:
>>> - We store the references from pages to their destinations ("outbound
>>> links" aka refersTo) as properties of the JCR node for the page.
>>> (pages/${page}[wiki:refersTo]).
>>> - We store the references to a page from their sources ("inbound
>>> links" aka referredBy) in a separate JCR path,
>>> wiki:references/wiki:wikiReferrers/${page}[wiki:referredBy], where
>>> ${page} is the page being referred to
>>> - We store "uncreated" page names in a multi-valued property of node
>>> wiki:references/wiki:notCreated[notCreated]
>>> - We store "unreferenced" page names in a multi-valued property of
>>> node wiki:references/wiki:notReferenced[notReferenced]
>>> The uncreated/unreferenced features work nicely in the unit tests, but
>>> I can reliably exhaust the heap through a sequence of events I don't
>>> fully understand involving Scandic strings. Specifically, in batch
>>> tests, just after JSPWikiMarkupParserTest.testScandicPagename1() runs
>>> (which creates a page called "ÄitiSyöÖljyä"), the single property file
>>> wiki:notReferenced/ (created by Phiha) grows
>>> seemingly exponentially until it gets to about 75-100MB or so, at
>>> which point the tests fall over. HexFiending the file shows that it
>>> contains "Main:" follows by what appears to be unicode characters that
>>> continue until the end of the file.
>>> I haven't been able to identify the root cause, but it looks like an
>>> encoding issue of some kind.
>>> Janne, anything obvious here? (If there were, I probably would've
>>> found it in the 3+ hours I spent debugging/pulling my hair out).
>>> In the meantime, I think what I will do is change the way
>>> uncreated/unreferenced pages are kept track of. Instead of using a
>>> multi-valued property, nodes are probably more reliable.
>>> Andrew

View raw message