About The Failed Release This Weekend |
About The Failed Release This Weekend |
Nov 21, 2010 - 8:19 PM |
|
Administrator Joined Aug 23, '02 From Seattle, WA Currently Offline Reputation: 14 (100%) |
Cliff Notes
The release of the new version of 6GC failed miserably due to bad errors that could not be solved by tonight. I'll be taking a much-needed break tonight and then I'll be working feverishly to find out what went wrong, and fix the problem. Once the problem is fixed, I'll schedule a new release that should take about four hours in the middle of the night. I'll let you guys know in advance before 6GC goes down again for upgrades. The Long Version Everything in the release went reasonably well in the beginning. There were some hiccups, but nothing too serious. Then I swapped domains and it all broke. It's important to note how the release works. Friday during the day, while 6GC was still up, the new version of 6GC was installed on a new hosted server. This server was initially set up to run a different temporary domain name. This gave me the ability to test everything. Then, when everything worked, the plan was to swap IP addresses, which would point the 6gc.net domain to this new server with the new version of 6GC. Everything worked with a small test dataset on the temporary domain just fine, so we were go for release early Saturday morning. Around 3am Saturday morning, the live site was turned off so that the database and all photos could be copied to the new server. This only took an hour or so. At this point, the new 6GC was running flawlessly on the new server, which was running with a temporary domain name but all of the posts, information, and photos from 6gc.net. Tests passed and all was well. The last thing to do was swap the 6gc.net domain over, do some last tests of critical components, and then flip my switch to allow everyone else to see the site and not the Twizzlers-promoting maintenance page. So I swapped the domain over, and then major problems started happening. Most of the problems were configuration issues and were sorted out within a couple hours. The main problem though, was that file uploads stopped working as soon as the domain was switched over to 6gc.net. Every file upload problem I've had before was pretty easy to solve, but this was not. In fact, I still cannot figure it out, and this is the most stumped I've been in thirteen years of building websites. More technical details can be found on my cry for help at Stack Overflow. If you can help or might know a web dev who knows nginx and HTTP really well (specifically, ask them if they "know how to troubleshoot a HTTP 422 error"), if you could point them to http://stackoverflow.com/questions/4234574...progress-module I'd greatly appreciate it. I'm completely stumped and am about to start digging into the nginx source code (read: painful and slow) to try to figure this out. Once I can figure out this issue, I think everything else will go well. And then I'll schedule another release. I'm hoping I can get it done before I leave Wednesday for a couple days in Yakima. But it's all dependent on solving that problem. So yeah, I'll post when I know more. -------------------- New Toyota project coming soon...
|
Nov 23, 2010 - 8:52 PM |
|
Enthusiast Joined Apr 11, '09 Currently Offline Reputation: 11 (100%) |
i came across this
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. here is the website for documentation http://www.ruby-forum.com/topic/98002 There's nothing in your code that immediately jumps out at me as wrong. The 422 error means that the account object could not be saved because it was invalid. But typically, there's a body with the response that details the errors. You might try setting the content type to "application/xml" for your request -- I think the server could be trying to interpret your XML as URL encoded form data since it is not specified. The "Accept" header only tells the server what format to output the response -- it says nothing about the request type. http://support.recurly.com/discussions/sup...unt-create-post |
Lo-Fi Version | Time is now: December 12th, 2024 - 1:57 AM |