Bugzilla – Full Text Bug Listing
| Summary: | mid-air collisions when timestamp in wrong format (2.18 only) | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | David Barri <japgolly> |
| Component: | Mylyn | Assignee: | Robert Elves <robert.elves> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P4 | CC: | arinehart, inw-eclipse, lm, pochmans, ruth, Tom.Talbott |
| Version: | 0.5 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
David Barri
It is possible that something went wrong with your offline reports file settings, although we have not seen this before. Could you try to delete all of the org.eclipse.mylar.* plug-ins in .metadata\.plugins and let us know if that resolves it? Hi. I deleted all the org.eclipse.mylar.* from .metadata/.plugins but the problem persisted. I then deleted org.eclipse.mylar.* from .metadata/.plugins/org.eclipse.core.runtime but then I could open bugs anymore. It kept throwing NPEs. Next I created a brand new workspace, and tried again and got the same problem. Rob: we need to figure out what's going on asap. David: since we haven't seen this before and nobody else has reported it we'll need more help in tracking it down. Here's what I'm assuming, please verify 1) you've got a completely fresh workspace, to it you add your server 2) when you try to submit changes to an existing bug you get a mid air colision (Mylar error dialog with embedded HTML from Bugzilla) 3) when you right click and Synchronize that report the incoming arrow goes away, but the problem persists 4) you do not see this problem when posting to eclipse.org (e.g. this bug, feel free to use it as a test)? Also, can you reproduce this problem on the test server you set up for us a while back, if that's still around? test via mylar Re previous 4 step. Did 1-3, same prob. Did 4 and it worked (as u can see from the above comment, hehe). My server is 2.22 and 100% uncustomized. Do u guys have access to a 2.22 server to test? I'm (wildly) guessing that it might be a ver compat prob. Re my old bugzilla test server, that's gone now. :) If worst comes to worst i'll just create a new user on my actual work bugzilla server. I trust u two (Mik+Rob) not to misuse it. :-) You can use this one, but create new bugs for your testing purposes instead of modifying existing ones: http://mylar.eclipse.org/bugs222 I'll email you the login credentials. And yes, you can trust us ;) Thanks. I tried it with your test server and everything worked fine. Could you please try my server? I will email you the details. It my server works fine for you then at least we know it's not a mylar prob. :) I hava exactly the same problem here. i am using an uncustomized bugzilla 2.18.4 The Date, Time, and Timezone (server side timezone preference) was included in bugzilla submission's delta time stamp but Bugzilla only accepts the date and time. Dropped time zone and all is well. Tested against David's repository (thanks David!). Mik, if you don't mind cutting a dev build tonight we can get these guys up and running. Wow, u guys r good! Well done! :) On the topic though, u just reminded me of something. In 0.5.2 (i think? maybe 0.5.3) there used to be a timezone pref in the repos properties dialog. What happened to that? Also if ur not sending the tz anymore, do u first convert to utc or something? Or just send local time? I'm sure u know what ur doing but i'm just curious. :-) Thanks, we try. ;) Regarding timezones, we were using them to convert the time strings returned by the repository into the local time. This ended up causing more problems then it was worth (especially when your local time was wrong). Now we use the delta time stamp from the repository itself (rather than one derived from a *possibly inaccurate* local time/timezone conversion) for synchronization. Thanks for posting this bug, our test repositories do not have a timezone setting so this bug did not appear during testing. I see. Makes sense ;) Thanks for everything man. Cheers. David, the new dev build will be available tomorrow. Thanks. (^_-)m Dev build is now available, let us know how it goes. Sweet! Confirmed with latest dev build. Works fine. Nice work guys. Great! Marking fixed. i upgraded to version 0.6.0.v20060706-1440. deleted old jars in eclipse/plugins, and deleted workspace/.metadata/plugins/org.eclipse.mylar* . i still get mid-air collisions, when i try to submit a change to the repository. please reopen the bug Lutz, we'll need more details on reproducing your mid-air collisions since they are likely to be a different problem now that the timezone one has been fixed. Could you please create a new bug report and include your exact Bugzilla version, customizations if any, and the simplest way to reproduce the failure? ok. i am going to try a different bugzilla repository and a fresh eclipse install first. if this fails i will open a new bug. Either way we want to figure out why it's not working for you, so once you have any evidence of that go ahead and submit the bug. I am also having this problem. I believe it started occuring around 0.5.3 as stated in the bug and I have tried 0.6.0.v20060707-1900 dev build to try and solve it. The bugzilla version is 2.18 and I don't believe it has been customized much at all, but I am not the owner of it. Also, it was occuring in Eclipse 3.1 with versions 0.5.3+ and I recently upgraded to Eclipse 3.2 with Mylar 0.6+. Both had this issue. I have not tried it with a fresh workspace. The error is a bit different now. Instead of getting the html dialog box, I get a simple dialog with: Bugzilla could not post your bug. A mid-air collision has occurred, please synchronize. Which I have done numerous times trying to get it to work. After synchronizing, I can click "compare" and it tells me there are no differences. When I enter text in the comment field and then click compare, it shows the New Comment as the difference. But, when I click "Submit to Repository" I get the above dialog. I would really like to get this working again, it would just starting to be real useful... Sorry to here this is still not working for some. Tom, could you post the exact version you are working with (2.18.?). Lutz, Tom, could you specify the character encoding being used? (In reply to comment #23) As far as I can tell, the version is 2.18. I cannot find any other designation, but I've put a request in to get it if it exists. The encoding of the webpage is ISO-8859-1. Thanks. -Tom i connect to bugzilla version 2.18.4 . we use the same encoding as tom does. iso-8859-1. i tried i fresh eclipse install with a new workspace, i still get the mid-air-collision (now in a different dialog box). Okay thank you both for this information. I will be investigating this issue today and hope to have it resolved in time for tonight's developer build. Could you paste 1) the Last modified string displayed on the bugillz bug report page and 2) the delta_ts element from the html content of that page. For example: 1) Last modified: 2006-06-13 20:24:59 2) <input type="hidden" name="delta_ts" value="2006-06-13 20:24:59"> That would help a lot, thanks! :) Last modified: 2006-07-13 10:27 <input type="hidden" name="delta_ts" value="20060713102723"> Okay great, this appears to be the source of our problem since I just installed a clean 2.18.4 and my delta_ts date format is like so: 2006-07-14 14:51:28. Could you go to the same bug but append &ctype=xml to the url in order to get the same report but in xml and post the delta_ts xml here? This should be the last of my demands. ;) Thanks for your patients. <delta_ts>2006-07-13 10:27</delta_ts> Okay so Tom, at least in your case it appears that you are accessing a modified (perhaps stale) bugzilla server version. We can see that it has differing ideas of timestamp format which we cannot resolve (since we don't have enough information in the xml to reproduce the long timestamp format). There may be other explanations for this format difference, perhaps the result of a bugzilla server upgrade where the database timestamp format didn't get changed, but I'm just guessing at this point. Lets wait to hear what version of bugzilla you are in fact using and we'll take it from there. Lutz, does this date format discrepancy appear to be the source of your problems as well? in the htmlview i have: Last modified: 2006-07-14 11:13 CEST <input type="hidden" name="delta_ts" value="20060714111317"> and in xml: <delta_ts>2006-07-14 11:13 CEST</delta_ts> except from the appended timezone string, the output seems to be the same as in toms bugzilla version (I dont have that suffix when i set the timezone property in bugzilla to an empty string). I use an unmodified version 2.18.4 At this point all I can suggest is upgrading bugzilla to the latest version (although I realize this may be out of your control) and see if that resolves this problem. Another option is, if you have access to the repository, we could investigate the timestamp format in the database underlying the bugzilla installation. Unfortunately I'm unable to reproduce on a 2.18.4 repository here but it hasn't undergone upgrades etc so is probably not be a good representation of your configuration. Are either of these options viable? Upgrading is not a near term solution since I am the only one using Mylar and this bug will probably prevent others from considering it. The request has been made, but it is not a priority. It may be possible to get access to the repository. If so, what exactly would we be looking for? We could start by looking at what the timestamp format is in your database table and compare that to what seems to be working here. I'll have a look at what my test repository is using and if you do the same perhaps this will shed some light on this. I haven't looked at the schema here yet but aim to clarify which table/field is of interest by end of today. I was able to look at the database and I found these fields in the "bugs" table: +---------------------+----------------+------+----+---------------------+----------------+ | Field | Type | Null |Key | Default | Extra | +---------------------+----------------+------+----+---------------------+----------------+ | creation_ts | datetime | |MUL | 0000-00-00 00:00:00 | | | delta_ts | timestamp(14) | YES |MUL | NULL | | I'm guessing that the "timestamp(14)" is the key info here. From my 2.18.4 db: +----------+-----------+------+-----+-------------------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+-----------+------+-----+-------------------+-------+ | delta_ts | timestamp | YES | MUL | CURRENT_TIMESTAMP | | +----------+-----------+------+-----+-------------------+-------+ Which results in a date format of '2006-07-21 15:14:48' being stored. Your timestamp(14) format results in YYYYMMDDHHMMSS. I was able to track down: https://bugzilla.mozilla.org/show_bug.cgi?id=257315 which addresses this issue and the outcome (for 2.20+) is that the field is now of type datetime and the upgrade process does the appropriate table alterations. From my 2.20 test db: +----------+----------+------+-----+---------------------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+----------+------+-----+---------------------+-------+ | delta_ts | datetime | | MUL | 0000-00-00 00:00:00 | | +----------+----------+------+-----+---------------------+-------+ So it looks to me like your only option (aside from upgrading) is to alter your delta_ts timestamp format. Of course we can't be certain if this will resolve the issue (or cause serious problems) so must recommend trying this out on a test db first. ;) If you go this route let us know how it turns out! Unfortunately, I doubt that a request to alter the database structure will be greeted with any better response than requesting an upgrade. Marking 'helpwanted'. Placed information related to this problem in wiki faq: http://wiki.eclipse.org/index.php/Mylar_FAQ#Bugzilla_Connector_troubleshooting Now that we know the format of the string. It would see that we could do a translation. Could you provide a pointer to where in the code the delta_ts is read and used? If I get frustrated enough, I may find time to look at it. It looks like the data we have to work with (from the xml: 2006-07-14 11:13) doesn't give us seconds so we can't do an exact translation. Of course I'm open to other suggestions/ideas as to how to resolve this! :) ...You could of course try it out with a) no seconds and b) with something like 59s. If you want to try this out, a quick way to do this would be to modify BugzillaReportSubmitForm. The code I changed in order to resolve the timezone problem (see earlier in this report) can be found if you look for "Strip off timezone information". Right around there (for element BugzillaReportElement.DELTA_TS) you could try doing your time conversion and see what happens. *** Bug 163483 has been marked as a duplicate of this bug. *** As discussed in Rob's comments above this is a Bugzilla data migration bug/limitation that we are unable to address. The work-around is to upgrade to Bugzilla 2.20 or later. *** Bug 167228 has been marked as a duplicate of this bug. *** Bug 167228 is no longer marked as a duplicate of this bug. *** Bug 199934 has been marked as a duplicate of this bug. *** |