Upgrade 9.9 to 9.10 - Failed to load component for type [interface com.xpn.xwiki.store.AttachmentRecycleBinStore] for hint [file]

Ok, trying with xwiki-platform-store-filesystem-oldcore-9.10.1-20171122.164241-3.jar.

All of the errors look the same as before. Do you want me to upload any of the Tomcat logs for you to look at?

You should have info log before the error.

Where would that log info be? In the tomcat8-stdout.2017-11-23.log file or somewhere else?

Wait, maybe I found it and if this the case, it’s hilarious (to me anyway):

2017-11-24 09:11:44,492 [XWiki initialization] INFO  .R910010XWIKI9065DataMigration - Storing attachment metadata [C:\opt\tomcat7\data\storage\xwiki\Main\Employee+Terminate+Procedure\~this\deleted-attachments\Contact+Supervisor.docx-1488383629338] in the database 
2017-11-24 09:11:44,492 [XWiki initialization] ERROR .HibernateDataMigrationManager - Failed to migrate database [xwiki]... 
com.xpn.xwiki.store.migration.DataMigrationException: Data migration R910010XWIKI9065 failed

I already reported that we were unable to rollback a particular page back in March (http://lists.xwiki.org/pipermail/users/2017-March/034778.html), which appeared to be due to an attachment issue.

We were never able to fix it, so we just deleted that page and created a new one.

Yep, I moved deleted-attachments out of that of the C:\opt\tomcat7\data\storage\xwiki\Main\Employee+Terminate+Procedure~this folder and XWiki loads. :slight_smile:

We don’t need those, but I saved that folder in case it’s helpful for testing.

Would be great if you could also print all the INFO logs before this one (especially the one which mention the root path) since it should still not crash the migration.

Actually I may have an idea.

One things I would like to know is: is the permanent dir still located in C:\opt\tomcat7\data. One possibility for this nullpointer is moving the permdir since there is an index of deleted attachment with absolute paths in it (this index does not exist anymore in 9.10 but the migrator reads it to find them).

Attached is the log with the root path.

tomcat8-stdout.2017-11-24.log (1.3 MB)

Yes, the location has not changed.

Side note: according to your log you should delete your /solr folder and restart so that XWiki create a new up to date one.

Why is that only in the logs? Why don’t we get a message in the Wiki itself that indicates the /solr folder needs to be deleted. Better yet, why doesn’t that happen automatically? This is the second time we’ve had to do that.

Maybe it’s something specific to Windows then since the issue is that from attachment store point of view the configured root folder is \opt\tomcat7\data\storage but the index file <permdir>/storage/~GLOBAL_DELETED_ATTACHMENT_ID_MAPPINGS.xml contains paths starting with C:\opt\tomcat7\data so the migrator get lost.

Let me try something and send you a new jar.

Oh, you mean due to these errors?

2017-11-24 09:11:46,442 [solr/indexer job group daemon thread - org.xwiki.search.solr.internal.job.IndexerJob@31a0c026] ERROR s.i.j.DatabaseDocumentIterator - Failed to count the documents.
org.xwiki.query.QueryException: Exception while executing query. Query statement = []

Yes your log is full of solr index format changes related errors and warnings.

Back to deleted filesystem attachments migration, the following JAR should makes things better on Windows: http://maven.xwiki.org/snapshots/org/xwiki/platform/xwiki-platform-store-filesystem-oldcore/9.10.1-SNAPSHOT/xwiki-platform-store-filesystem-oldcore-9.10.1-20171124.171040-5.jar

1 Like

Done.

I didn’t intrude because I had nothing relevant to add to the discussion (same issue, and I also had recyclebin.hint = file) but I also had the issue on CentOS so this doesn’t seem to be a Windows related issue.

I’ll also try the JAR and tell you if it’s better for me too

@zwindler there is several issues actually, the Windows one is the Nullpointerexecption error.

OK, sorry