Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Scott Jenkins
Migration failed from 6.1.0 cega1 to 6.1.1 cega2 > My solution was ..
November 8, 2012 7:00 AM
Answer

Scott Jenkins

Rank: New Member

Posts: 3

Join Date: August 31, 2012

Recent Posts

Some virtual portal instances, that I did not even require any longer (but Liferay won't let me remove them), caused migration process verification fail. I debugged the code and noticed that it would break at class com.liferay.portal.verify.VerifyDocumentLibrary. Sometimes it failed as it created some temp files and then said "Duplicate file exception" and sometimes another place in the code could not find some file. What was not so nice, that any error would break the process. So - I decided to take a shot and collect all verification errors and let the process finish. Then I would check the errors later.

My question before my solution is - Why the verification errors / other errors cannot be collected? I think it should be at least my choise - then I could check all the positions, where the migration fails. Now it fails to the first error and I have no glue how many there are still to come. This would be important in order to estimate how long some migration process might take. Customers require this information very much..

The troubles in 6.1.1 cega2 code were caused here (class com.liferay.portal.verify.VerifyDocumentLibrary):

 1
 2..
 3//Breaks on all errors!
 4@Override
 5protected void doVerify() throws Exception {
 6            checkMisversionedDLFileEntries(); //THIS BROKE SOME TIMES
 7            checkDLFileEntryType();
 8            checkMimeTypes(); //AND THIS ALSO SOMETIMES
 9            removeOrphanedDLFileEntries();
10            updateAssets();
11}
12..


My modified version does not break on all errors:

 1
 2@Override
 3protected void doVerify() throws Exception {
 4
 5        try {
 6
 7            checkMisversionedDLFileEntries();
 8            checkDLFileEntryType();
 9            checkMimeTypes();
10            removeOrphanedDLFileEntries();
11            updateAssets();
12
13        } catch(Exception e)  {
14
15            VerifyProcessErrorObject o = new VerifyProcessErrorObject();
16            o.exception = e;
17            o.cause = -1;
18           VerifyProcessErrorStack.push(o);
19        }
20
21        if (!VerifyProcessErrorStack.isEmpty()) {
22            System.out.println("**********************************************");
23            System.out.println("There was errors during verification process: ");
24            System.out.println("***********************************************");
25            VerifyProcessErrorStack.printAll();
26            System.out.println("***********************************************");
27            System.out.println("***********************************************");
28        }
29}


And the errors inside all the verification methods were collected like this:

 1
 2for (DLFileEntry dlFileEntry : dlFileEntries) {
 3
 4            //Surrounded with try / catch to continue in case of failed verification
 5            try {
 6
 7                copyDLFileEntry(dlFileEntry);
 8                addDLFileVersion(dlFileEntry);
 9
10            } catch (Exception e) {
11                VerifyProcessErrorObject o = new VerifyProcessErrorObject();
12                o.exception = e;
13                o.cause = dlFileEntry;
14                VerifyProcessErrorStack.push(o);
15            }
16
17    }


The wrapping object of the printer is very simple:

 1
 2
 3package com.liferay.portal.verify;
 4
 5public class VerifyProcessErrorObject {
 6
 7    public Exception exception;
 8    public Object cause;
 9
10    public void print() {
11        System.out.println("Object that caused error: " +  cause);
12        System.out.println("Exception stored with the object: " + exception);
13    }
14}


And the error stack is also very basic list wrapper:

 1
 2public class VerifyProcessErrorStack {
 3
 4    private static final List<VerifyProcessErrorObject> objectsThatFailedVerification = new ArrayList<VerifyProcessErrorObject>();
 5
 6    public static void push(VerifyProcessErrorObject failed) {
 7       objectsThatFailedVerification.add(failed);
 8    }
 9
10    public static boolean isEmpty() {
11        return objectsThatFailedVerification.isEmpty();
12    }
13
14    public static void clear() {
15        objectsThatFailedVerification.clear();
16    }
17
18    public static void printAll() {
19        for (VerifyProcessErrorObject o : objectsThatFailedVerification) {
20            o.print();
21        }
22    }
23}
Scott Jenkins
RE: Migration failed from 6.1.0 cega1 to 6.1.1 cega2 > My solution was ..
November 9, 2012 6:43 AM
Answer

Scott Jenkins

Rank: New Member

Posts: 3

Join Date: August 31, 2012

Recent Posts

FYI:

This kind of exceptions:

Exception stored with the object: com.liferay.portlet.documentlibrary.DuplicateFileException: \liferay-portal-6.1.1-ce-ga2\data\document_library\12901\28113\DLFE\10\102.zip\102_1.0.zip

went away by renaming some rows to numbers to the DB like this

update dlfileentry set name = '9999' where name = 'DLFE-2.doc'
update dlfileentry set name = '9998' where name = 'DLFE-101.txt'
update dlfileentry set name = '9997' where name = 'DLFE-102.zip'

Those were the only cases were name was not number. That seemed to cause duplicateFileException and break the process.
Scott Jenkins
RE: Migration failed from 6.1.0 cega1 to 6.1.1 cega2 > My solution was ..
November 9, 2012 7:14 AM
Answer

Scott Jenkins

Rank: New Member

Posts: 3

Join Date: August 31, 2012

Recent Posts

Actually looks like any row having type "application/octet-stream" in table "dlfileentry" causes troubles, as deleting those rows (in my case only 5 rows) lets the verification process through succesfully..