掲示板
Duplicate entry x for key 'IX_8D83D0CE' during upgrade from 5.2.3 to 6.0.6
12年前 に John Ryder によって更新されました。
Duplicate entry x for key 'IX_8D83D0CE' during upgrade from 5.2.3 to 6.0.6
New Member 投稿: 5 参加年月日: 11/09/30 最新の投稿
I'm experiencing issues upgrading from Liferay 5.2.3 to 6.0.6. The initial upgrade completes smoothly, but I get an exception (see below) on an index when attempting to use the permissions conversion tool. It doesn’t seem to matter if I check “create custom roles”. I've added the legacy properties to my portal-ext.properties file (see below) before staring Liferay 6 against the Liferay 5 database.
To give some background on this, we are running a single home grown portlet application (30 or so portlets) within the Liferay 5.2.3 bundle on Windows 2008 R2 against MySQL 5.1. It is more or less a standard JSR-286 portlet WAR that deploys cleanly in LR 5 and 6. We have a hook, model listener, and custom role defined in the WAR file. We do not have any permissions defined for our role. We are not using the ext environment and have not made any customizations to Liferay at all. I’ve undeployed our web app in Lifreay 5 before attempting the upgrade.
I saw a few comments indicating that this could be caused by omitting the image.hook.impl legacy property, but I’m already using that property (image.hook.impl=com.liferay.portal.image.DatabaseHook). I tried running the conversion tool on the images first, removing the legacy property from portal-ext.properties, and restarting Liferay before running the permissions migration tool.
I can easily restore the content of the site (it’s not much), so I’ve tried creating a new blank organization, deleting the organization we are currently using, deleting all web content, images, and documents, and then upgrading to LR 6 but it still fails.
I did some research on the exception. Index IX_8D83D0CE is for ResourcePermission.C_N_S_P_R. So, 10112 is my company, 103 is the name, 4 means individual scope, “10140_LAYOUT_103” is the single root layout of my blank organization and 10119 is the guest role. The first few times I tried this, the exception was slightly different and indicated that it was failing while converting the ResourcePermission for the “Owner” role, so I removed all “Owner” permissions on the single blank page of my blank organization before running the upgrade to 6. Now it is failing on Guest.
I’m stumped on this. We haven't made any modifications to Liferay at all and haven't really done anything with the permissions. We’ve tried the upgrade at least 15 different times, tried deleting the Lucene search index, deleting the content of temp and work folders, deleting our entire organization and all content within LR 5 before the upgrade, running the steps in slightly different order, etc and cannot seem to get past this.
Potentially related Jira issues:
http://issues.liferay.com/browse/LPS-20956 (this is from 6.0 to 6.1, also I deleted all of the images, documents, and web content before attempting the upgrade)
http://issues.liferay.com/browse/LPS-12214 (similar exception, slightly different circumstances)
http://issues.liferay.com/browse/LPS-13474 (similar exception, different circumstances)
http://issues.liferay.com/browse/LPS-7811 (similar exception, different circumstances)
Properties that I’m using when initially starting Liferay 6:
Exception that we are encountering when converting permissions:
To give some background on this, we are running a single home grown portlet application (30 or so portlets) within the Liferay 5.2.3 bundle on Windows 2008 R2 against MySQL 5.1. It is more or less a standard JSR-286 portlet WAR that deploys cleanly in LR 5 and 6. We have a hook, model listener, and custom role defined in the WAR file. We do not have any permissions defined for our role. We are not using the ext environment and have not made any customizations to Liferay at all. I’ve undeployed our web app in Lifreay 5 before attempting the upgrade.
I saw a few comments indicating that this could be caused by omitting the image.hook.impl legacy property, but I’m already using that property (image.hook.impl=com.liferay.portal.image.DatabaseHook). I tried running the conversion tool on the images first, removing the legacy property from portal-ext.properties, and restarting Liferay before running the permissions migration tool.
I can easily restore the content of the site (it’s not much), so I’ve tried creating a new blank organization, deleting the organization we are currently using, deleting all web content, images, and documents, and then upgrading to LR 6 but it still fails.
I did some research on the exception. Index IX_8D83D0CE is for ResourcePermission.C_N_S_P_R. So, 10112 is my company, 103 is the name, 4 means individual scope, “10140_LAYOUT_103” is the single root layout of my blank organization and 10119 is the guest role. The first few times I tried this, the exception was slightly different and indicated that it was failing while converting the ResourcePermission for the “Owner” role, so I removed all “Owner” permissions on the single blank page of my blank organization before running the upgrade to 6. Now it is failing on Guest.
I’m stumped on this. We haven't made any modifications to Liferay at all and haven't really done anything with the permissions. We’ve tried the upgrade at least 15 different times, tried deleting the Lucene search index, deleting the content of temp and work folders, deleting our entire organization and all content within LR 5 before the upgrade, running the steps in slightly different order, etc and cannot seem to get past this.
Potentially related Jira issues:
http://issues.liferay.com/browse/LPS-20956 (this is from 6.0 to 6.1, also I deleted all of the images, documents, and web content before attempting the upgrade)
http://issues.liferay.com/browse/LPS-12214 (similar exception, slightly different circumstances)
http://issues.liferay.com/browse/LPS-13474 (similar exception, different circumstances)
http://issues.liferay.com/browse/LPS-7811 (similar exception, different circumstances)
Properties that I’m using when initially starting Liferay 6:
users.image.max.height=0
users.image.max.width=0
locale.prepend.friendly.url.style=0
auth.token.check.enabled=false
permissions.user.check.algorithm=5
permissions.view.dynamic.inheritance=false
# removing the below property and restarting after using data migration tool in LR 6
image.hook.impl=com.liferay.portal.image.DatabaseHook
cdn.host.http=${cdn.host}
cdn.host.https=${cdn.host}
virtual.hosts.default.community.name=
breadcrumb.show.guest.group=false
breadcrumb.show.parent.groups=false
wiki.page.titles.regexp=([^/\\\\\\[\\]%&?@]+)
wiki.page.titles.remove.regexp=([/\\\\\\[\\]%&?@]+)Exception that we are encountering when converting permissions:
13:54:15,213 INFO [Table:407] Finished backup of ResourcePermissionView to D:\apps\liferay-portal-6.0.6\tomcat-6.0.29\temp/temp-db-ResourcePermissionView-1317390855211 in 2 ms
13:54:15,236 INFO [Table:371] Starting backup of ResourcePermissionView to D:\apps\liferay-portal-6.0.6\tomcat-6.0.29\temp/temp-db-ResourcePermissionView-1317390855236
13:54:15,238 INFO [Table:407] Finished backup of ResourcePermissionView to D:\apps\liferay-portal-6.0.6\tomcat-6.0.29\temp/temp-db-ResourcePermissionView-1317390855236 in 2 ms
13:54:15,239 DEBUG [MaintenanceUtil:64] Updating ResourcePermission table13:54:15,546 FATAL [ConvertProcessMessageListener:35] Unable to process message{destinationName=liferay/convert_process, responseDestinationName=null, responseId=null, payload=com.liferay.portal.convert.ConvertPermissionAlgorithm, values=null}
com.liferay.portal.convert.ConvertException: java.sql.BatchUpdateException: Duplicate entry '10112-103-4-10140_LAYOUT_103-10119' for key 'IX_8D83D0CE'
at com.liferay.portal.convert.ConvertProcess.convert(ConvertProcess.java:53)
at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.doReceive(ConvertProcessMessageListener.java:47)
at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.receive(ConvertProcessMessageListener.java:32)
at com.liferay.portal.kernel.messaging.InvokerMessageListener.receive(InvokerMessageListener.java:63)
at com.liferay.portal.kernel.messaging.SerialDestination$1.run(SerialDestination.java:56)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.BatchUpdateException: Duplicate entry '10112-103-4-10140_LAYOUT_103-10119' for key 'IX_8D83D0CE'
at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:1257)
at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:943)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeBatch(NewProxyPreparedStatement.java:1723)
at com.liferay.portal.upgrade.util.Table.populateTableRows(Table.java:532)
at com.liferay.portal.upgrade.util.Table.populateTable(Table.java:494)
at com.liferay.portal.upgrade.util.Table.populateTable(Table.java:437)
at com.liferay.portal.convert.ConvertPermissionAlgorithm.convertToBitwise(ConvertPermissionAlgorithm.java:169)
at com.liferay.portal.convert.ConvertPermissionAlgorithm.doConvert(ConvertPermissionAlgorithm.java:660)
at com.liferay.portal.convert.ConvertProcess.convert(ConvertProcess.java:44)
... 7 more
12年前 に John Ryder によって更新されました。
RE: Duplicate entry x for key 'IX_8D83D0CE' during upgrade from 5.2.3 to 6.
New Member 投稿: 5 参加年月日: 11/09/30 最新の投稿
Did some more research on this. The error seems to be specifically related to converting to the bitwise permissions storage mechanism. I get a very similar stack trace (with slightly different line numbers) if I use the "Convert Legacy Permissions" feature within Liferay 5. The only difference is that within Liferay 5, the exception rolls by in the logs and the site comes back up. In Liferay 6, the server seems to deactivate itself after the exception has encountered.
Does anyone know if it is safe to run the bitwise converter within Liferay 5, ignore the exception that comes up, and then do the upgrade to Liferay 6? I guess I would start Liferay 6 without the permissions.user.check.algorithm=5 line.
Any help here would be greatly appreciated. I'm way deeper into Liferay internals than I ever expected to be for a routine upgrade, especially since we haven't done any sort of customization or modifications.
Does anyone know if it is safe to run the bitwise converter within Liferay 5, ignore the exception that comes up, and then do the upgrade to Liferay 6? I guess I would start Liferay 6 without the permissions.user.check.algorithm=5 line.
Any help here would be greatly appreciated. I'm way deeper into Liferay internals than I ever expected to be for a routine upgrade, especially since we haven't done any sort of customization or modifications.
12年前 に John Ryder によって更新されました。
RE: Duplicate entry x for key 'IX_8D83D0CE' during upgrade from 5.2.3 to 6.
New Member 投稿: 5 参加年月日: 11/09/30 最新の投稿
Looks like at least one other person has run into this issue (with no resolution): http://www.liferay.com/community/forums/-/message_boards/message/6493162
12年前 に John Ryder によって更新されました。
RE: Duplicate entry x for key 'IX_8D83D0CE' during upgrade from 5.2.3 to 6.
New Member 投稿: 5 参加年月日: 11/09/30 最新の投稿
Looking at the Liferay 5 database before I run the conversion, there are a lot of entires in the in the resourcepermission table. This is probably why I'm receiving the index violation when running the conversion tool. I'm really confused at this point because I thought that this table wasn't used with algorithm 5 (we did not set permissions.user.check.algorithm=6 when installing LR 5.2.3 nor did we use the conversion tool).
I tried starting Liferay 6 against the database without adding permissions.user.check.algorithm=5 and now I receive a different exception on startup: com.liferay.portal.NoSuchResourceActionException: com.liferay.portlet.journal.model.JournalArticle#DELETE_DISCUSSION. Other forum posts seem to indicate that this is addressed by adding permissions.user.check.algorithm=5, and the portal does indeed start if I do so, but then it fails later when I try to convert to algorithm 6.
Is there a way to blow away all of the permissions within the installation and revert back to default values? My needs are really simple - I just need to lock down some pages within our single organization to be viewable only by users that have logged in, and other pages to be viewable only to users that are in our single custom role.
I tried starting Liferay 6 against the database without adding permissions.user.check.algorithm=5 and now I receive a different exception on startup: com.liferay.portal.NoSuchResourceActionException: com.liferay.portlet.journal.model.JournalArticle#DELETE_DISCUSSION. Other forum posts seem to indicate that this is addressed by adding permissions.user.check.algorithm=5, and the portal does indeed start if I do so, but then it fails later when I try to convert to algorithm 6.
Is there a way to blow away all of the permissions within the installation and revert back to default values? My needs are really simple - I just need to lock down some pages within our single organization to be viewable only by users that have logged in, and other pages to be viewable only to users that are in our single custom role.
12年前 に Bin Li によって更新されました。
RE: Duplicate entry x for key 'IX_8D83D0CE' during upgrade from 5.2.3 to 6.
New Member 投稿: 14 参加年月日: 12/01/17 最新の投稿
We hit similar issue, appreciate who can help solve this issue!
Since we use permissions.user.check.algorithm=5 in previous version, it will show warning in the log when starts up:
06:20:38,891 WARN [MainServlet:901] Liferay is configured to use permission algorithm 5. Versions after 6.1 will only support algor
ithm 6 and above. Please sign in as an administrator, go to the Control Panel, select "Server Administration", select the "Data Migr
ation" tab, and convert from this legacy permission algorithm as soon as possible.
So we followed this operation (go to the Control Panel, select "Server Administration", select the "Data Migration" tab, and convert from this legacy permission algorithm), but it has following errors:
07:01:41,730 DEBUG [MaintenanceUtil:64] Updating ResourcePermission table
07:01:44,553 FATAL [ConvertProcessMessageListener:35] Unable to process message {destinationName=liferay/convert_process, response=n
ull, responseDestinationName=null, responseId=null, payload=com.liferay.portal.convert.ConvertPermissionAlgorithm, values={principal
Password=..., principalName=10129, companyId=10109}}
com.liferay.portal.convert.ConvertException: java.sql.BatchUpdateException: Duplicate entry '11302-100-4-11902_LAYOUT_100-11308' for
key 2
at com.liferay.portal.convert.ConvertProcess.convert(ConvertProcess.java:53)
at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.doReceive(ConvertProcessMessageListener.java:47)
at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.receive(ConvertProcessMessageListener.java:32)
at com.liferay.portal.kernel.messaging.InvokerMessageListener.receive(InvokerMessageListener.java:65)
at com.liferay.portal.kernel.messaging.SerialDestination$1.run(SerialDestination.java:101)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._runTask(ThreadPoolExecutor.java:669)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask.run(ThreadPoolExecutor.java:580)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.BatchUpdateException: Duplicate entry '11302-100-4-11902_LAYOUT_100-11308' for key 2
at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:1257)
at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:943)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeBatch(NewProxyPreparedStatement.java:1723)
at com.liferay.portal.upgrade.util.Table.populateTableRows(Table.java:538)
at com.liferay.portal.upgrade.util.Table.populateTable(Table.java:500)
at com.liferay.portal.upgrade.util.Table.populateTable(Table.java:443)
at com.liferay.portal.convert.ConvertPermissionAlgorithm.convertToBitwise(ConvertPermissionAlgorithm.java:176)
at com.liferay.portal.convert.ConvertPermissionAlgorithm.doConvert(ConvertPermissionAlgorithm.java:693)
at com.liferay.portal.convert.ConvertProcess.convert(ConvertProcess.java:44)
... 7 more
Since we use permissions.user.check.algorithm=5 in previous version, it will show warning in the log when starts up:
06:20:38,891 WARN [MainServlet:901] Liferay is configured to use permission algorithm 5. Versions after 6.1 will only support algor
ithm 6 and above. Please sign in as an administrator, go to the Control Panel, select "Server Administration", select the "Data Migr
ation" tab, and convert from this legacy permission algorithm as soon as possible.
So we followed this operation (go to the Control Panel, select "Server Administration", select the "Data Migration" tab, and convert from this legacy permission algorithm), but it has following errors:
07:01:41,730 DEBUG [MaintenanceUtil:64] Updating ResourcePermission table
07:01:44,553 FATAL [ConvertProcessMessageListener:35] Unable to process message {destinationName=liferay/convert_process, response=n
ull, responseDestinationName=null, responseId=null, payload=com.liferay.portal.convert.ConvertPermissionAlgorithm, values={principal
Password=..., principalName=10129, companyId=10109}}
com.liferay.portal.convert.ConvertException: java.sql.BatchUpdateException: Duplicate entry '11302-100-4-11902_LAYOUT_100-11308' for
key 2
at com.liferay.portal.convert.ConvertProcess.convert(ConvertProcess.java:53)
at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.doReceive(ConvertProcessMessageListener.java:47)
at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.receive(ConvertProcessMessageListener.java:32)
at com.liferay.portal.kernel.messaging.InvokerMessageListener.receive(InvokerMessageListener.java:65)
at com.liferay.portal.kernel.messaging.SerialDestination$1.run(SerialDestination.java:101)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._runTask(ThreadPoolExecutor.java:669)
at com.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask.run(ThreadPoolExecutor.java:580)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.BatchUpdateException: Duplicate entry '11302-100-4-11902_LAYOUT_100-11308' for key 2
at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:1257)
at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:943)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeBatch(NewProxyPreparedStatement.java:1723)
at com.liferay.portal.upgrade.util.Table.populateTableRows(Table.java:538)
at com.liferay.portal.upgrade.util.Table.populateTable(Table.java:500)
at com.liferay.portal.upgrade.util.Table.populateTable(Table.java:443)
at com.liferay.portal.convert.ConvertPermissionAlgorithm.convertToBitwise(ConvertPermissionAlgorithm.java:176)
at com.liferay.portal.convert.ConvertPermissionAlgorithm.doConvert(ConvertPermissionAlgorithm.java:693)
at com.liferay.portal.convert.ConvertProcess.convert(ConvertProcess.java:44)
... 7 more
12年前 に John Ryder によって更新されました。
RE: Duplicate entry x for key 'IX_8D83D0CE' during upgrade from 5.2.3 to 6.
New Member 投稿: 5 参加年月日: 11/09/30 最新の投稿
I wasn't able to get past this issue. We ended up doing a mysqldump on our 5.2.3 database and writing a Perl script to port the important parts (mainly just the users) into a fresh install of LR 6. Fortunately the content wasn't that important in our case, and we were able to import a LAR from another LR 6 installation.