Good day to everyone. I am the proud owner/developer/code money responsible for a fairly new GWT application at my workplace. Overall, the response to the application has been quite good and it has been a pleasant change from the (now legacy) JSP development I still have to do. Today, however, we have been getting some odd errors, and although I believe I understand the issue, I was hoping to strike up some discussion here, both to confirm my diagnosis and to see if there are better ways of handling things in the GWT world.
So, a bit of back story. I made an oops, and a bug escaped into production during one of our scheduled releases, leaving the eviscerated bodies of several QA people in its wake. Early the next day, the flames of users began to roar in our inboxes as the symptoms became apparent, and I quickly developed a fix. Because of the severity of the issue, and fear of various forms of pox inflicted upon us by the users, we deployed the fix in the middle of the day. For a brief time, the flames went down, the users were placated with their blankets, and all was well. Some time later, we were inundated with more flames, but of a different kind. Many users began reporting strange errors when attempting to navigate around the application. In particular, 404 errors when downloading, or attempting to download anyway, code fragments from the app server. The existence of the code fragments is of no surprise, as some time ago we implemented code splitting as a way to reduce the perceived slow startup time of the application. As to why they began to fail to download, I had to ponder for a bit. I believe the answer to this is that our own haste has returned to destroy us. Our mid-day deployment would seem to have unleashed upon the world an app that isn't quite compatible with the clients that some of our users had left open. The JS code fragments live in sub- folders contained in the "deferredjs" directory of the deployment, and it seems as though the sub-folders have names that may change. Based on the random gibberish of the names, I would assume they are some form of hashed value, although I haven't gone through the compiler code to verify whether that is the case or not. But my theory is that the old deployment, and the clients that were subsequently loaded from that deployment, had different sub-directory names, and therefore when the old clients attempted to load up new fragments, they 404'd out on their attempts to fetch non-existent things. I'm hoping the general populace of this group could possibly help to confirm this theory, if only to help retain what little of my sanity remains, as there is not much else I can think of that would have caused this. Now, assuming this to be true, we can simply be more careful with future releases. It would be quite easy to send out e-mails in such events, and tell the users to close their browsers and re-load the application. For an organization of our size (<100 people), that is an acceptable solution. However, I am wondering about solutions for larger organizations, or perhaps even applications deployed to the general web. The latter case would be particularly difficult due to the high cost of gas and the inefficiency of driving around the world and knocking on that many doors. I mulled over various possibilities in my head, such as having a polling thread on the client that is checking for new versions, or incorporating that check into the base message object that flies back and forth. I suppose I could also look for the 404 errors in the onFailure method of the RunAsyncCallback, but that seems hacky, and I would have no guarantee that the evil clients would be closed before they did unspeakable things to my precious data. Thoughts? Considerations? Ponies? -Ben -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
