Anonymous | Login | Signup for a new account | 11-22-2024 04:42 PST |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | |||||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
0003149 | [Quercus] | minor | always | 12-11-08 08:58 | 01-04-09 14:40 | |||||||
Reporter | ferg | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | urgent | Resolution | open | |||||||||
Status | new | Product Version | 3.2.1 | |||||||||
Summary | 0003149: code version switchover | |||||||||||
Description |
(rep by Steven Grimm) I talked about the "deploy the new code at time X" idea with one of the engineers who does code pushes here, and though it's obviously a huge win to be able to flip our entire site to a new release at the same instant, there's a further wrinkle that would make it even cooler. Specifically, we have the problem right now as we're pushing new code that if a client loads, say, some JavaScript code from release 1, then does an AJAX request that happens to hit a server running release 2, it might get back a response that is intended for the release 2 JavaScript code. Flipping the entire site to release 2 at the same time will cut the severity of that problem way down, but given the fact that the client doesn't request all its resources simultaneously (especially on an AJAX-heavy site where the same page might stay open for a long time), it is still a possibility for a client to get mismatched resources. But we could eliminate it entirely if the client were able to specify a version number as part of the request (the exact mechanism is not important). Then the JS code would say, "I want to make this AJAX request to release 1 of the AJAX handler" and that's the code that'd get used even if release 2 was the default one. We'd impose some maximum time limit on that (a client would force a page refresh after noticing it was out of date) but during the processing of a single page, we could guarantee a consistent set of server code would get used even across multiple requests. The thought that occurred to me was that this would dovetail nicely with the developer sandbox stuff. In some sense each release could be considered a separate sandbox, and with the shared PHP class registry we discussed, the cost of that would be pretty low if most of the code is unchanged from one release to the next (which it usually is). Then we just need to be able to route to the right pseudo-sandbox -- which we could do, e.g., with our own servlet code -- and everything should work. Anyway, this isn't fully-formed yet as an idea, and in fact even if you gave it to us tomorrow we wouldn't be able to use it since it would require application code changes. But being able to do, essentially, a generational view of a site in the middle of a code upgrade seems like a pretty neat thing in general; it would completely remove a major recurring point of instability for lots of sites. If we had this and made the changes in our code to make use of it, we would almost certainly do far more code pushes than we do now, in fact; we try to limit it to once a day in part because it currently causes user-visible instability. |
|||||||||||
Additional Information | ||||||||||||
Attached Files | ||||||||||||
|
There are no notes attached to this issue. |
Issue History | |||
Date Modified | Username | Field | Change |
12-11-08 08:58 | ferg | New Issue | |
12-17-08 23:46 | koreth | Issue Monitored: koreth | |
01-04-09 14:40 | ferg | Priority | normal => urgent |
Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed. 25 unique queries executed. |