[MNT-14125] Errors related to sizeCurrent property. Created: 26-Mar-15  Updated: 14-Sep-15  Resolved: 11-Aug-15

Status: Closed
Project: Service Packs and Hot Fixes
Component/s: Upgrades
Affects Version/s: 5.0.1
Fix Version/s: 5.0.2

Type: Bug
Reporter: David González (Inactive) Assignee: Closed Bugs
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 week, 1 day, 55 minutes
Original Estimate: Not Specified
Environment:

Debian Linux 7.8 Wheezy x64, Java 8 (JDK 8u40), Apache Tomcat 7.0.59, MySQL 5.6.23, 16GB RAM


Attachments: File MNT-14125-DH01.patch     Text File MNT-14125-alf_applied_patch.txt    
Issue Links:
Duplicate
is duplicated by ALF-21315 Alfresco 5.0c -> 5.0d change views "M... Closed
is duplicated by ALF-21373 LDAP sync not updating mail Closed
Related
relates to MNT-13556 Integrity check allows null values fo... Closed
Bug Priority:
Category 1
Build Location: https://releases.alfresco.com/Enterprise-5.0/5.0.2/build-00086/ALL

 Description   

Hello,

I'm trying to update one Alfresco installation which is working fine from v.4.2.d to v.5.0.d. I had to reindex all the contents because I changed to Solr4 too.

Reindexing process finished without problems and all the files which was present in our old repository can be found through this instalation of Alfresco.

However, it seems there is a problem with users (who were imported from our old installation) because every time I try to access to options like Actions, Tags, etc. from Alfresco Share web interface one error dialog related to a mandatory property not set (sizeCurrent) is displayed.

If I check Tomcat log I can see this information logged:

 2015-03-26 14:34:39,910  ERROR [extensions.webscripts.AbstractRuntime] [http-apr-8080-exec-3] Exception from executeScript - redirecting to status template error: 02260680 Found 1 integrity violations:
Mandatory property not set:
   Node: workspace://SpacesStore/4b5fd62f-2ec6-402b-9e74-9fac3a571735
   Name: 4b5fd62f-2ec6-402b-9e74-9fac3a571735
   Type: {http://www.alfresco.org/model/content/1.0}person
   Property: {http://www.alfresco.org/model/content/1.0}sizeCurrent
 org.alfresco.repo.node.integrity.IntegrityException: 02260680 Found 1 integrity violations:
Mandatory property not set:
   Node: workspace://SpacesStore/4b5fd62f-2ec6-402b-9e74-9fac3a571735
   Name: 4b5fd62f-2ec6-402b-9e74-9fac3a571735
   Type: {http://www.alfresco.org/model/content/1.0}person
   Property: {http://www.alfresco.org/model/content/1.0}sizeCurrent
        at org.alfresco.repo.node.integrity.IntegrityChecker.checkIntegrity(IntegrityChecker.java:664)
        at org.alfresco.repo.node.integrity.IntegrityChecker.beforeCommit(IntegrityChecker.java:766)
        at org.alfresco.util.transaction.TransactionSupportUtil$TransactionSynchronizationImpl.beforeCommit(TransactionSupportUtil.java:498)
        at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerBeforeCommit(TransactionSynchronizationUtils.java:95)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerBeforeCommit(AbstractPlatformTransactionManager.java:925)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:738)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:724)
        at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:475)
        at org.alfresco.util.transaction.SpringAwareUserTransaction.commit(SpringAwareUserTransaction.java:482)
        at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:479)
        at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecute(RepositoryContainer.java:551)
        at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecuteAs(RepositoryContainer.java:619)
        at org.alfresco.repo.web.scripts.RepositoryContainer.executeScriptInternal(RepositoryContainer.java:399)
        at org.alfresco.repo.web.scripts.RepositoryContainer.executeScript(RepositoryContainer.java:280)
        at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:378)
        at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:209)
        at org.springframework.extensions.webscripts.servlet.WebScriptServlet.service(WebScriptServlet.java:132)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.alfresco.web.app.servlet.GlobalLocalizationFilter.doFilter(GlobalLocalizationFilter.java:61)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:409)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1044)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
        at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2378)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

I can't even edit user profiles because the same error reappears and it's constantly logged.

Do you know what could be the problem? I have found some references here:

http://forums.alfresco.com/fr/node/21338

https://forums.alfresco.com/es/node/39720

https://issues.alfresco.com/jira/browse/MNT-1390

But not a solution for now.

Thank you.



 Comments   
Comment by Greg Melahn [X] (Inactive) [ 29-May-15 ]

Moved to Storage&Infrastructure for investigation. I notice we used to have PersonUsagePatch.java in 4.2.x to fixup the Person, but no such in 5.0.x.

Comment by Derek Hulley [X] (Inactive) [ 01-Jun-15 ]

Needs to be triaged out of ALF project for anything to happen.

Comment by Derek Hulley [X] (Inactive) [ 01-Jun-15 ]

Pushed for investigation. Thanks for reporting this (and to those who raised the same issue elsewhere).

Comment by David González (Inactive) [ 02-Jun-15 ]

Hello,

I'd like to say that I finally solved this problem just using JavaScript Console addon to set sizeCurrent value to 0. After the upgrade, this value was null for all the users.

Thanks.

Comment by Andreea Dragoi [X] (Inactive) [ 08-Jun-15 ]

Had some issue with indexing after upgrade, I managed to solve them, but I can't reproduce the issue. I've tried different scenarios with new alfresco instances where I created a user, a site with the new user, and added some documents to document library :

  • 4.2.d -> 5.0.a and 5.0.a -> 5.0.d - with solr1 ( encountered same error as in ACE-2842, the mentioned fix did not worked for me)
  • with solr4 ( indexing worked fine, created a new site with the non-admin user, tagged some existing documents, no error was raised )
  • 4.2.d -> 5.0.d - same result

Also tested on enterprise:

  • 4.2.5 - > 5.0.1.1 - same result, the issue is not reproducing when performing mentioned actions.

This seems to be related to existing content before upgrading, and not OS. Tested on a Windows machine. Note that Debian Linux is not a supported platform.
David González, Corina Zaharia [X] please add some details regarding content before upgrade, in order to reproduce the issue.

Comment by Derek Hulley [X] (Inactive) [ 25-Jun-15 ]

David González
Please select all contents of your alf_applied_patch table and attach to this issue (or send directly to me derek . hulley @ alfresco.com if you can't. This error is probably something lurking from a lot earlier in the data.

Also, we need the result of reproducing this with integrity tracing on. See my comment on issue ALF-21373.

Comment by Derek Hulley [X] (Inactive) [ 25-Jun-15 ]

Andreea Dragoi [X]
The user on ALF-21373 provided us with:

Current version: 5.0.0 (d r99759-b2) schema 8,022. Originally installed version: 4.0.0 (b 3835) schema 5,019.

.
I have no idea what David González's server upgrade path was (we don't have any information, yet) but it might be worth trying the path 4.0.0 -> 4.2.f -> 5.0.0d

You can drop the properties directly from the alf_node_properties table and try to reproduce like that. Then see if the attached patch fixes the issue. If not, turn on the integrity checker tracing, get the logs and we can take a look at where the person properties are updated.

For testing, it might be possible to start a transaction, remove the property from the person object and then update some other person data (email, say) and validate that the usage stuff has been added back by the precautionary code.

Comment by Derek Hulley [X] (Inactive) [ 29-Jun-15 ]

David González
Please consider trying the workaround proposed in this comment.

Comment by Derek Hulley [X] (Inactive) [ 02-Jul-15 ]

A summary for a wider audience:
The original patch.personUsagePatch set the property to NULL. The property was present but did not have a value (not even zero).
MNT-13556 tightened the meaning of property existence to ensure that NULL values are treated the same as NOT PRESENT. Therefore, people who had run the original patch.personUsagePatch now have violations.
A new patch has been introduced to fix any instances of this data that may be lying around.

Generated at Sat Aug 15 21:40:44 BST 2020 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.