OXtender 6.16 - db tables not created

[Albéric]

Hi,

I installed Open-Xchange 6.14 then upgraded to 6.16. I then proceeded to install OXtender for Business Mobility following the guide on oxpedia (http://oxpedia.org/wiki/index.php?ti...allation_Guide).

When I try to initiate a synchronisation, I have the following in /var/log/open-xchange/open-xchange.log.0 (real username removed) :

30000c: com.openexchange.usm.api.exceptions.USMSQLException: 1:6:$USERNAME@defaultcontext:EAS:2CE262DC45796017EB855AFDF2A5EA9C SQL error while retrieving persistent data from DB

I'm guessing the interesting line of the following traceback is this :

Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'oxdatabase_11.USMSession' doesn't exist

I had a look in the database and indeed the table USMSession is missing. On one of our staging servers, the following tables have been created and are missing on this install :

• USMDataStorage
• USMSession
• USMSessionFields
• easUIDMapping
• usmIdMapping
• UUIDHeader
• UUIDMapping
• messagingAccount
• sequence_usmIdMapping
• sequence_usmSessionId

The guide says that you should move around a certain updatetasks.cfg, which I don't have since I'm working with 6.16. I suppose that this file is now replaced by the table updateTasks in the database. The contents of this table are as follows :

select * from updateTask where taskName like '%usm%';
cid     taskName        successful      lastModified
0       com.openexchange.usm.database.ox.USMClearTablesUpdateTask       1       1274198211555
0       com.openexchange.usm.database.ox.USMTablesUpdateTask    1       1274198211571
0       com.openexchange.usm.database.ox.USMUUIDTablesUpdateTask        1       1274198211598
0       com.openexchange.usm.database.ox.USMClearTablesUpdateTask93     1       1274198211601

It seems the update jobs have been ran and OX believes they did what they were supposed to. Am I correct in assuming that removing these entries from the table and restarting the groupware will force theses tasks to be rerun ? Could this break anything ?


The OXtender deb installed perfectly on our staging machine but not on our production machine (the latter being a virtual clone of the former). I experienced exactly the same aforementioned problem on another similar setup and have yet to figure out the right way to fix it.


Distro is stock Debian Lenny on all three setups.


Thanks for your help. I can provide any additional information you may require.


Full traceback :

20 mai 2010 10:41:40 com.openexchange.usm.eas.delegate.BaseXMLDelegate logError
GRAVE: null 1:6:$USERNAMEe@defaultcontext:EAS:2CE262DC45796017EB855AFDF2A5EA9C SQL error while retrieving persistent data from DB
30000c: com.openexchange.usm.api.exceptions.USMSQLException: 1:6:$USERNAME@defaultcontext:EAS:2CE262DC45796017EB855AFDF2A5EA9C SQL error while retrieving persistent data from DB
        at com.openexchange.usm.session.impl.PersistentSessionData.readPersistentData(PersistentSessionData.java:406)
        at com.openexchange.usm.session.impl.PersistentSessionData.initialize(PersistentSessionData.java:317)
        at com.openexchange.usm.session.impl.SessionImpl.initialize(SessionImpl.java:109)
        at com.openexchange.usm.session.impl.SessionManagerImpl.getSession(SessionManagerImpl.java:200)
        at com.openexchange.usm.session.impl.SessionManagerService.getSession(SessionManagerService.java:28)
        at com.openexchange.usm.eas.servlet.EASServlet.handleRequest(EASServlet.java:449)
        at com.openexchange.usm.eas.servlet.EASServlet.doPost(EASServlet.java:350)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:616)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl.doServletService(AJPv13RequestHandlerImpl.java:504)
        at com.openexchange.ajp13.AJPv13Request.response(AJPv13Request.java:129)
        at com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl.createResponse(AJPv13RequestHandlerImpl.java:316)
        at com.openexchange.ajp13.najp.AJPv13ConnectionImpl.createResponse(AJPv13ConnectionImpl.java:207)
        at com.openexchange.ajp13.najp.AJPv13Task.call(AJPv13Task.java:346)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
        at java.util.concurrent.FutureTask.run(FutureTask.java:123)
        at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$Worker.runTask(CustomThreadPoolExecutor.java:737)
        at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$Worker.run(CustomThreadPoolExecutor.java:763)
        at java.lang.Thread.run(Thread.java:595)
Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'oxdatabase_11.USMSession' doesn't exist
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1026)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1885)
        at com.openexchange.database.internal.wrapping.PreparedStatementWrapper.executeQuery(PreparedStatementWrapper.java:103)
        at com.openexchange.usm.session.impl.PersistentSessionData.readPersistentData(PersistentSessionData.java:361)
        ... 18 more
20 mai 2010 10:41:40 com.openexchange.usm.eas.servlet.EASServlet logResponse
FIN: No session: FolderSync executed in 457 ms.

[Martin Heiland]

Hi,

please *DO NOT* alter or remove anything at the database, especially not the updatetasks entries. 6.16 is able to execute the mobility update tasks without any files moved around etc. That's also mentioned at the Upgrade Guide for business mobility. If the database on the other system has been altered manually, some tables might be missing. You can re-run update tasks using:

/opt/open-xchange/sbin/resetversion -v 33 -c 1

This re-runs all updatetasks since DB version 33 which includes all mobility tasks.

Greetings

[Albéric]

Thanks for your fast reply. I ran the command you gave me and it complained with the following output :

Unexpected error: UPD-0018 Category=1 Message=The version can not be set back if the update tasks handling has been migrated to the Remember Executed Update Tasks concept on schema oxdatabase_11. exceptionID=-1776863247-67

I have to admit I don't understand what this means at all.

Please note I have not yet altered the database in any way.

Just wondering : there is an excludedupdatetasks.properties lying in /opt/open-xchange/etc/groupware. It doesn't have any reference to the USM tasks in it. Is it normal ?

[Martin Heiland]

Ah, sorry. You cannot execute pre-6.16 updatetasks with 6.16 since we changed the updatetask handling and migrated updatetask info - thats what the error messages says.

Updatetasks can be added manually to excludedupdatetasks.properties before updating to exclude them from being executed. There is no reason why USM tasks should be executed because they must be executed in case USM is installed. If no USM is installed, no USM tasks are executed.

Have you manipulated anything at the database? Do you have any log files from the time when the update to 6.16 has been performed?

Thanks

[Albéric]

USM is precisely installed (open-xchange-usm package) and from my understanding, the database has the tasks marked as having been executed (the flag "successful" being to 1).

I haven't changed anything in the database and basically I haven't done anything (I think) that is not in the guide for now. I am merely investigating.

Ah, sorry. You cannot execute pre-6.16 updatetasks with 6.16 since we changed the updatetask handling and migrated updatetask info - thats what the error messages says.

Does this mean that I can execute something like

/opt/open-xchange/sbin/resetversion -v 200 -c 1

Would that make sense ?

I'm attaching the whole /var/log/open-xchange.


Thanks again for your time and attention.

[Albéric]

I haven't figured anything out yet so this is just a small update. The following commands didn't do anything :

/opt/open-xchange/sbin/resetversion -v 200 -c 1

/opt/open-xchange/sbin/resetversion -v 199 -c 1

I get the same messages about the tasks handling system having been migrated to the new concept.

I got the same symptoms on a 6.14 upgraded to 6.16 as well as on a fresh 6.16.

I just don't know and I can't risk to reinstall the one that is currently running in production as I am not sure I can totally migrate the user datas in a reasonable time frame.

Cheers

[Martin Heiland]

Hi,

please contact the support they might know a solution for this one.

Thanks

[Marcus Klein]

The correct way to fix this after 6.16 is installed is to call the following commands:

/opt/open-xchange/sbin/forceupdatetask -t com.openexchange.usm.database.ox.USMTablesUpdateTask
/opt/open-xchange/sbin/forceupdatetask -t com.openexchange.usm.database.ox.USMClearTablesUpdateTask
/opt/open-xchange/sbin/forceupdatetask -t com.openexchange.usm.database.ox.USMUUIDTablesUpdateTask
/opt/open-xchange/sbin/forceupdatetask -t com.openexchange.usm.database.ox.USMClearTablesUpdateTask93