Getting the following error when trying to use the CLI to convert a Twiki for Confluence 4.1.4:
Exception in thread "main" java.lang.StackOverflowError
at java.util.regex.Pattern.sequence(Pattern.java:1906)
at java.util.regex.Pattern.expr(Pattern.java:1769)
at java.util.regex.Pattern.group0(Pattern.java:2547)
at java.util.regex.Pattern.sequence(Pattern.java:1823)
at java.util.regex.Pattern.expr(Pattern.java:1769)
at java.util.regex.Pattern.compile(Pattern.java:1477)
at java.util.regex.Pattern.<init>(Pattern.java:1150)
at java.util.regex.Pattern.compile(Pattern.java:840)
at com.atlassian.uwc.hierarchies.TWikiHierarchy.getAncestors(TWikiHierarchy.java:125)
at com.atlassian.uwc.hierarchies.TWikiHierarchy.getAncestors(TWikiHierarchy.java:152)
at com.atlassian.uwc.hierarchies.TWikiHierarchy.getAncestors(TWikiHierarchy.java:152)
at com.atlassian.uwc.hierarchies.TWikiHierarchy.getAncestors(TWikiHierarchy.java:152)
.
.
.
OK, this problem is this.
Twiki somehow allows for circular reference in pages, e.g. page B can be a child of A which in turn can be a child of B, and so on. I'm not sure if this is by design or just corruption. This causes an endless loop in the getAncestors() function in the TWikiHierarchy class. If you can find the pages with the issue and manually fix the wiki source, that's good and you can likely figure out where the page should live. If not, you'll have to protect by modifying the source by adding a check in the getAncestors() function.
I'm having the same problelm. The pages reported as "no parent" do have parents specified. Was there anything specific about the files you deleted?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think part of the problem is because we are trying to use the UWC for Confluence 4.1, which is not supported in current version of UWC. The other part could have been an unexpected condition in the data. I deleted files in pub and data for a couple of users and it got past this error.
Additionally, there were several "can't find parent" errors for documents (they really did have parents) but they did not stop UWC from completing, however not everything was converted.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That's a lot better! Good luck with the remainder!
G.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Have you turned up the java VM memory numbers? What is the command line you're using to run the command?
You can use the -Xmx8m argument to (for instance) increase the memory for the VM to 8meg. You might need a lot mor than that!
Example file toy.java:
public class toy { public static void main(String[] args) { Runtime runtime = Runtime.getRuntime(); System.out.println("Total Memory: " +
runtime.maxMemory() / (1024 * 1024) + "mb"); System.exit(0); } }
Example compile:
% javac toy.java
Example run with default:
% java toy Total Memory: 81mb
Example run with 111 meg of heap:
% java -Xmx111m toy
Total Memory: 108mb
Increase away! It won't hurt anything, change anything permanently, etc. It will make it slower especially if the machine doesn't have enough RAM but it'll have a chance. Like on PC's where the first thing you do is reboot, in Java, the 1st thing you look for is "not enough memory". From the stack indications (line numbers) its a memory kabooey due to recursion. You might have to turn the thing up to 100, 200, 500m, who knows?
G.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I did tweak the parameters but it didn’t fix it. (I increased Xmx and Xss) Here is the relevant line in the script:
java -Xms256m -Xmx1024m -Xss64m $APPLE_ARGS -classpath $CLASSPATH com.atlassian.uwc.ui.UWCCommandLineInterface $1 $2 $3 $4
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Since its blowing up on the stack, I'd say increase the stack wildly, or, leave the arg out, and let the VM proportion it to the VM size in general. Your choice! Good luck! G.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The Xss arg was originally not there and was added to do just as you recommended, increase the stack size. I also tried it at 1024 and it just took longer to blow up.
Thanks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well, darn it. Good luck!...maybe you can try it on another platform...elsewise, I'd say you have a bonafide bug! [to report]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Idea: can you make a copy of the Twiki, and cut it roughly in half, and see if the bug occurs again? If you keep cutting in half, down to small pieces you'll discover one or more of the following:
- Its a size problem, and/or
- Its a problem with the page content
G.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.