Closed
Bug 464906
Opened 16 years ago
Closed 14 years ago
An unexpected error has occurred! when posting to forums while logged in
Categories
(support.mozilla.org :: Forum, task)
support.mozilla.org
Forum
Tracking
(Not tracked)
VERIFIED
INCOMPLETE
People
(Reporter: cww, Unassigned)
Details
(Whiteboard: 08/06/2009)
I can't tell if it's temporary or if something broke with 0.7.2 so I'm filing a bug. Go to forums, try to reply to existing thread, get An unexpected error has occurred! It may be a performance issue since everything seems to have slowed down.
Comment 1•16 years ago
|
||
According to Quarantine [1], this still happens often and is a major issue. Cww, did you want to set a target milestone on this? [1]<http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=211632&forumId=3>
Updated•16 years ago
|
Severity: normal → major
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → 0.8
Sorry, I always assumed target milestones were set during sumodev meetings. I would love to have this in the next release. We could also try the 99999999 trick since I think reverting that is when this started.
Comment 3•16 years ago
|
||
This should be a performance issue. It's about time to optimize that part. It's probably an inefficient query. The "unexpected error" is basically a db error (which means it probably the sql server has gone away or something similar) due to the time limit set on queries. To reduce overall load on the forums, you can try setting in the Admin.. Forums admin panel, "Performance - Limit forum topic listings to recent (hours)", "Performance - Limit ranking listings to recent posts (hours)" to a smaller number.
Comment 4•16 years ago
|
||
Also, is the tiki_comments db table innodb or myISAM? I remember we converted most tables to innodb but left some in myISAM due to need for FULLTEXT index requirements. Is this table one of them? Just wondering if this might be behind performance problems.
Updated•16 years ago
|
Target Milestone: 0.8 → 0.9
Comment 5•15 years ago
|
||
What's the status of this? Are we still getting errors? I imagine this was fixed with the recent query revisions.
Comment 6•15 years ago
|
||
Has anyone seen this recently?
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 8•15 years ago
|
||
This is happening today. Both me and Noah are having the problems.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 9•15 years ago
|
||
It is now happening again. I also got the error
Comment 10•15 years ago
|
||
This seems a on and off problem. Some threads give you this problem some dont.
Reporter | ||
Comment 11•15 years ago
|
||
Moving to server ops to see what happened to cause this recently. We think that getting more servers helped last time but there doesn't seem to be a spike in traffic so we'll need some investigative work from IT to figure out what's killing the DB. Can we get a SHOW FULL PROCESSLIST for prod unless you know of servers that are going down for other reasons?
Assignee: nobody → server-ops
Severity: major → critical
Component: Forum → Server Operations
Product: support.mozilla.com → mozilla.org
QA Contact: forum → mrz
Target Milestone: 0.9 → ---
Version: unspecified → other
Comment 12•15 years ago
|
||
I don't see any InnoDB in there, it's entirely MyISAM. No load at all on the database, gonna have to check the web server logs...
Updated•15 years ago
|
Assignee: server-ops → justdave
Comment 13•15 years ago
|
||
ok, the sumo site was recently moved to a new web cluster, and the error logging wasn't set up correctly (was trying to log to a directory that didn't exist). I just fixed that and we're getting logs now. Next time it happens get the timestamps and we'll find it in the logs.
Comment 14•15 years ago
|
||
Witnessed the error again today @ 6:57pm CST after posting in the forums.
Comment 15•15 years ago
|
||
Not a thing recorded in the logs near that timestamp. Whatever error is happening isn't getting logged.
Comment 16•15 years ago
|
||
Also witnessed at 15:48 BST
Comment 17•15 years ago
|
||
Seeing a lot of this...Dave, how would you feel about turning on verbose logging maybe just on one webhead?
Comment 18•15 years ago
|
||
What I actually mean is on one *slave* since it's a config setting.
Comment 19•15 years ago
|
||
hmm, this apparently got left here while I was on vacation last week, I'm still getting caught up. It's been a week, are we still seeing this? I've got no qualms with turning on verbose logging on a webhead to test this.
Comment 20•15 years ago
|
||
i also get it while voting on comments on the KB...
Comment 21•15 years ago
|
||
(In reply to comment #19) > I've got no qualms with turning on verbose logging on a webhead to test this. You mean you didn't already do this? *Faceplant* Do it! >It's been a week, are we still seeing this? Yes! All day today, and last night. Right now I'm seeing it consistently after 6pm CDT, looking again its 6:20pm, and its still happening. If I post/edit my post in the Firefox forum, its there! Staring me in the face! *Stabs tiki wiki*
Comment 22•15 years ago
|
||
(In reply to comment #17) > Seeing a lot of this...Dave, how would you feel about turning on verbose > logging maybe just on one webhead? How is that done?
Updated•15 years ago
|
Whiteboard: waiting on verbose steps
Comment 23•15 years ago
|
||
This is happening again today as of 7:20 pm CDT. It's causing users to think their posts aren't going thru, making them post twice.
Comment 24•15 years ago
|
||
Laura, how do we turn on logging? I think we're stuck debugging since nothing's logging anything interesting.
Comment 25•15 years ago
|
||
(In reply to comment #24) > Laura, how do we turn on logging? I think we're stuck debugging since > nothing's logging anything interesting. Via the admin interface usually. I *don't* think we want to do this on all boxes for perf reasons, so I'm wondering if we can somehow hive off one slave and set it there. It's on https://support.mozilla.com/tiki-admin.php?locale=en-US&page=general The settings we want are "TikiWiki verbose error reporting" and "Log SQL" We should also set it to "Report all PHP errors". To set this on a single slave we'll need to set these directly on that slave. In the database these settings correspond to name-value pairs in the tiki_preferences table. error_reporting_level should be set to 2047 error_reporting_adminonly set to 'y' tiki_error_reporting_verbose to 'y' log_sql to 'y'
Comment 26•15 years ago
|
||
They all use the same pool of database slaves, and the config for which database to talk to is shared between all of them. I don't think there's a way to set this on just one if it's stored in the database.
Comment 27•15 years ago
|
||
Maybe we can just do it for a short period of time during an off-peak time of day or something?
Comment 28•15 years ago
|
||
k, let's turn it on one evening. Dave, I'll leave when up to you as you have a better view of the traffic patterns.
Reporter | ||
Comment 29•15 years ago
|
||
Does this error still happen when traffic is not at peak (just out of curiosity)? Noah, do you have insights as to when this is most likely to happen?
Comment 30•15 years ago
|
||
Cww, I thought it was based on traffic but since I have no access to those stats I couldn't say. Keeping in mind my central timezone, I witnessed the problem all day long (11am-9pm) as I was posting in the forums. Even to late evening. Which makes me think this isn't based on traffic at all, and something just broke where ever it broke.
Comment 31•15 years ago
|
||
Don't see a plan here so here's one - 1. Turn on logging during tonight's maintenance window. 2. Let logging run throughout the whole window 3. Attempt to reproduce problem Will there be enough people online and around to help test?
I don't think I'll be online tonight, no.
Comment 33•15 years ago
|
||
Scratch tonight, plan for next week instead. Dave might even be around in person!
Updated•15 years ago
|
Whiteboard: waiting on verbose steps → 07/21 ?
Updated•15 years ago
|
Flags: needs-downtime+
Updated•15 years ago
|
Whiteboard: 07/23 → 08/06/2009
Comment 35•15 years ago
|
||
I don't think this needs to be announced but it'd be great it everyone's around to get this tested tonight.
(In reply to comment #35) > I don't think this needs to be announced but it'd be great it everyone's around > to get this tested tonight. I'll be around, but will have both a small SFx push and an AMO release tonight, by myself.
Comment 37•15 years ago
|
||
ok, so we have the logging enabled cluster-wide, and we're not getting anything new that we weren't already getting in the apache logs on the webheads, nor in the tiki_logs table in the database. Anyone know if there's somewhere special the new logged items get stored?
Comment 38•15 years ago
|
||
I'm not seeing any performance impact at the moment from having this stuff enabled, might as well leave it on until we do. Still haven't figured out if/where it's logging anything though.
Comment 39•15 years ago
|
||
Ive just has this error so if we find out where its logging too we should check the time stamp about 4 mins before now
Comment 40•15 years ago
|
||
This is now happening on every thread I reply too.
Comment 41•15 years ago
|
||
Laura, any clue where to find debug logs? I feel like were stuck here.
Comment 42•15 years ago
|
||
Alternatively, if we can't figure out where it logs to, can we add some debugging output that will intentionally log stuff around the code that probably handles this action?
Comment 43•15 years ago
|
||
Move this back to server ops when there's actually something for IT to do again.
Assignee: justdave → nobody
Component: Server Operations → Forum
Flags: needs-downtime+
Product: mozilla.org → support.mozilla.com
QA Contact: mrz → forum
Version: other → unspecified
Comment 44•14 years ago
|
||
So long ago.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → INCOMPLETE
Meow.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•