|
About the database required information:
00:23:25,854 http://xxen.xen.net/xwiki/bin/skin/skins/albatross/actionbar-bg2.png 11:15:54,403 http://xepecnet.environmentalchange.net/xwiki/bin/view/Main/ Vincent,
About reproducing the problem: no clue at all! I don't know at the moment how to debug the conversation with the database, so the only things I have are the logs and the sequences of mouse clicks leading to this situation. I have been trying to find a pattern, but nothing conclusive so far. Some ideas: 1. Access to revisions of documents already in the database prior to the updated always fail. During these last days I've been playing with: 1. LDAPAuthenticater. There are a number of pending issue on my side about this, but this revisions problem is a really big problem and is causing some frustrating situations with our users. I am really concern about this: you know how sensitive users are! I thought it could be related with importing/not importing the updated .xar. It doesn't seem the case. Please, let me know how could I help to work out this issue. Thanks for your work! Ah I may have one idea...
In 1.2 XWiki saves the full document as a revision every 5 revisions. In between revisions are saved as diff only. So it may happen you've done more than 5 revision saves and there's a problem after that. I'll do some testing to about this here. On this side and about the last two test documents: three and five revisions; Both are in troubles now and throwing the exception.
Ricardo,
Have you deleted any revision on these pages? Thanks Deletion is not possible when the problem appears.
If I try to delete a revision, it throws... Error number 13027 in 13: Exception while patching Wrapped Exception: java.lang.NumberFormatException: For input string: " " BUT rollback does work. And after rollingback to any version deletion and comparison seem to work again. Does this make any sense for you? Sorry I was asking for something different.
I was asking if you had done any deletion or rollbacks on the documents that are having problems BEFORE the problem appeared... I'm checking if the deletion or rollback could have been the cause of the problem appearing. Thanks Nope! The problem appears without deleting or rolling back to any version. But it is curiouse that after rolling back an in troubles document it seems to work again...
I've checked the xwiki.log and couldn't find any instance of the problem... so that's strange (note that xwiki.org is running 1.3 SNAPSHOT but that shouldn't make a difference)
This problem should appear when xwiki consider that a revision is diff while it's actually a full content revision or vice-versa. So the only possibility of error I can imagine is when we reach 5 revisions. However I've added some unit tests for that and it seems to be working fine.
I'm stumped. And since it doesn't happen on xwiki.org either it would be nice if you could make your mysql dump available for download somewhere so that I could try with it. Thanks Cannot reproduce this with Tomcat 6.0.14, MacOS and mySQL 5.0.45, on a clean install.
Some more details which could help:
The fact that the history works fine for a period of time has a simple cause: the archive is taken from the cache. So, when you create a new document and some history for it, it is stored in an archive cache, and also persisted in the database. This cache expires at some moment, so when trying to use the document archive will result in a load from the database, instead of using the cache. And, when loading the archive from the database, something goes wrong. So the problem is somewhere between XWiki and the database. Forgot to mention, I am using mysql-connector-java-5.1.5.
Just tried with mysql 5.0.27, and it works. So it probably doesn't depend on the mysql version.
Hi Vincent, Sergiu,
This is making me nuts... My test environment: Mac OS X (Leopard fully patched), MySQL 5.0.27, Tomcat 6.0.10, mysql-connector-java-5.1.5
I have been preparing an ad hoc database where you can be the errors. It was doing "fine" (I mean, errors appear systematically), but after some rollback operations and deleting some entries from the recyble bin, all the documents seem to work fine now. I will sent to Vincent an account for the in troubles xwiki installation and to access to the mysql dump. It is running in a Linux box (Suse Linux 9.x / OES) and MySQL 5.0.24a, Tomcat 6.0.10. Thanks! Ricardo, here's what I think happened:
You were using a 1.2 version of XE (maybe a milestone or a RC version). At some point there was a bug introduced ( I've tested your DB and any new revision added work just fine. BTW when I imported your DB dump the version was 0 so that's really weird. I'm going to modify the Yes, this database was used both with milestones and RC versions. There are a message somewhere in the list about this. We do need some bugs solved/improvements only available in the RCs, so we gone ahead with the "update".
As for editing the database by hand, as far as I remember I've only tried to remove an entry referenced in "[xwiki-users] document name including /" thread in About new revisions I am not so sure. Pleae, check this... http://xepecnet.environmentalchange.net/xwiki/bin/viewrev/Sandbox/TrackingChanges02?rev=4.1 This document was created after the last update to 1.2.6932 and is throwing the "Exception while patching"... at least here. It is a virtual wiki, I don't know if this mind or it doesn't. Sorry, I don't get the point with the 0 version in the DB dump... Did I anything wrong while backing up the database? Anything I must check here? Thank you so much! I've tried the TrackingChanges02 page and all the revisions I create (by modifying the content) are fine and I can view them using the history. It's only version 4.1 that doesn't work.
I know how to fix the problem for all your revisions but I don't know what's causing the problem apart from what I've mentioned in the previous comment. The fact that TrackingChanges02 was created in 1.2 final and has the problem is a real issue... There's a table in the database called xwikidbversion. In your dump it didn't have any value inside. The value in there should have been 6430. Can you create a testing account, so that I can write some velocity code? You can send it by email to sergiu at xwiki.com
Ricardo, I've given Sergiu my userid/pwd on your instance. Hope this is ok.
Vincent,
As far as I understand, I must populate xwikidbversion with value 6430 (I see the value in this table for the controller is 6431). And now, restart the servlet container and try again? Any other action? Stop until receive more instructions? Thanks! No, no, no
You don't have to change anything and in general you should never touch the database's content I was just surprised that the dump you gave me was not correct in this regards and I'm wondering why. Sttoped! I rolled back changes in xwiki_epecnet.xwikidbversion.
As for the account for Sergiu, of course it is OK, but I've sent him his own account. Thanks! Ricardo,
It seems you didn't upgrade cleanly. For example Sergiu found that your version of http://xepecnet.environmentalchange.net/xwiki/bin/skin/skins/albatross/usersandgroups.js This implies you didn't upgrade correctly. A correct upgrade implies changing an existing WAR with a newer version and copying back the config files (xwiki.cfg, hibernate.cfg.xml) and possibly some additional libs (like extra plugins installed and jdbc jars). Could you also check the version of the WEB-INF/lib/xwiki-core*.jar (i.e. the value replacing *)? I think you should try to install a clean version of xwiki. -Vincent I do hope all this work has not been only caused for an error of mine
This are the xwiki-core* files: mire:/usr/share/tomcat-6.0.10/webapps/xwiki/WEB-INF/lib # ls xwiki-core*.* -l As far as I remember, that is what I have done: substitute the WAR file, restarting the servlet container and copying bak a number of .jar files together and editing again xwiki.cfg an hibernate.cfg.xml to avoid to miss any new parameter added in tha last release. As for skins, I use an unmodified albatross for the controller (well, I've substituted the logo). And any other virtual wiki has his own skin folder. So, I am not able to figure out why this erroneous .js is in the albatross folder. But it is obvious that I did something wrong. Now, at this point, 1. Must I install a new 1.2.6932 or move to the snapshot you are using in xwiki.org? Thanks again, Ricardo Ricardo,
Could you please do the following: 1) Reinstall XE 1.2 from a clean installation (you keep your DB) xwiki.store.migration.force=com.xpn.xwiki.store.migration.hibernate.R6079XWIKI1878Migrator 4) Start XE. This will force the execution of the migrator that fixes RCS data so your DB will be in a working state from now on Hope this will fix everything. Thanks | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Major
"Exception while patching" error
from xwikircs
Ricardo, any hint on how to reproduce this?
Thanks
-Vincent