Thanks for the help, I'll explore both of these suggestions. Rob
On Mon, Mar 17, 2014 at 3:09 PM, "" <[email protected]> wrote: > Another way to avoid this really is to run two instances of jetty, > production and production-standby. You deploy your new application > version to the standby then tell your load balancer to send all requests > without an already established session to the standby instance which > effectively makes the standby production and the old production into a > standby, This should be possible with nginx but certainly is using other > reverse proxy arrangements. > > An advantage for this is that if your production and production-standby > use two different installations of jetty, then it will be much easier to > perform upgrades / maintenance of jetty. It also allows you to test your > new application on production-standy before letting customers at it. > > Of course, this requires a bit more sysadmin type effort. > > > On 17 March 2014 12:14, Jan Bartel <[email protected]> wrote: > >> Robert, >> >> A 404 seems pretty reasonable. If the connectors are still running, >> then the server is still accepting requests. Therefore there is a >> small amount of time during which the webapp is stopped, and the >> restart has not yet completed, and a request can arrive. During that >> period, it is correct that there is no context matching the request. >> >> If you want to avoid a 404 you could deploy a 2nd webapp at the same >> context path. When the 1st webapp stops due to the hot update, the 2nd >> webapp will answer the request. Normally this 2nd webapp would contain >> a static page with a maintenance message, maybe doing an automatic >> reload or directing the user to do the reload, and of course turning >> off caching. After you've got the 1st webapp redeployed, you can use >> jmx to turn off the 2nd webapp, so traffic will flow again to the 1st >> webapp. >> >> Jan >> >> On 15 March 2014 00:56, Robert Nikander <[email protected]> wrote: >> > Upgrading to Jetty 9.1.3 fixed the NullPointerExceptions. But now, >> instead of the 500 error, I get a 404 not found error for a second while >> the app is redeploying. So, my question remains: is that normal, or is >> re-deployment supposed to work seamlessly? >> > >> > Rob >> > >> > >> > On Mar 14, 2014, at 9:02 AM, Robert Nikander <[email protected]> >> wrote: >> > >> >> Ah, this may be fixed in newer Jetty versions. I'll try upgrading. >> >> >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=417475 >> >> >> >> Rob >> >> >> >> On Mar 14, 2014, at 8:49 AM, Robert Nikander <[email protected]> >> wrote: >> >> >> >>> Jan, >> >>> >> >>> I believe the rsync is finished. I use a shell script and and the >> two commands are sequential. Here is the script, and some log messages. >> >>> >> >>> #!/bin/bash >> >>> rsync -v myapp.war myserver:/opt/webapps >> >>> rsync -v deployment/myapp.xml myserver:/opt/jetty/webapps/ >> >>> >> >>> If I run that, the logs show a stop and start. >> >>> >> >>> 2014-03-14 12:37:01.706:INFO:oejsh.ContextHandler:Scanner-0: >> Stopped o.e.j.w.WebAppContext@358ee631 >> {/myapp,file:/tmp/jetty-0.0.0.0-8080-myapp.war-_myapp-any-/webapp/,UNAVAILABLE}{/myapp.war} >> >>> 2014-03-14 12:37:03.644:INFO:oejsh.ContextHandler:Scanner-0: >> Started o.e.j.w.WebAppContext@760aa0cd >> {/myapp,file:/tmp/jetty-0.0.0.0-8080-myapp.war-_myapp-any-/webapp/,AVAILABLE}{/myapp.war} >> >>> >> >>> I ran the script again, but this time kept reloading a page in the >> browser, to trigger an error. Between the stop and the start messages, I >> see a bunch of errors like this: >> >>> >> >>> 2014-03-14 12:37:33.079:WARN:oejs.HttpChannel:qtp121295574-906: >> /myapp/static/common/angular/angular-sanitize.min.js >> >>> java.lang.NullPointerException >> >>> at >> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:192) >> >>> at >> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109) >> >>> at >> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) >> >>> at >> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:317) >> >>> at >> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) >> >>> at org.eclipse.jetty.server.Server.handle(Server.java:445) >> >>> at >> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:268) >> >>> at >> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:229) >> >>> at >> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358) >> >>> at >> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601) >> >>> at >> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532) >> >>> at java.lang.Thread.run(Thread.java:744) >> >>> >> >>> Rob >> >>> >> >>> >> >>> On Mar 13, 2014, at 10:27 PM, Jan Bartel <[email protected]> wrote: >> >>> >> >>>> Robert, >> >>>> >> >>>> Are you sure that the rsync has finished by the time you touch the >> xml file? >> >>>> >> >>>> Upgrading is generally a good idea :), but I can't think of anything >> >>>> specifically that would affect the hot redeployment (other than the >> >>>> war file not being fully copied). >> >>>> >> >>>> Might be able to comment more if you could post an example of the >> log messages. >> >>>> >> >>>> cheers >> >>>> Jan >> >>>> >> >>>> On 14 March 2014 02:33, Robert Nikander <[email protected]> >> wrote: >> >>>>> Hi, >> >>>>> >> >>>>> (I posted on stackoverflow first [1] but no answers, so I'll try >> here.) >> >>>>> >> >>>>> I have the usual web app deployer as described in the docs [2] and >> defined in etc/jetty-deploy.xml. I use an xml file to define my web app >> context, so when I push new code to my production server, I upload a new >> myapp.war file using `rsync` and then touch that myapp.xml file. This works >> pretty well, but there are few seconds where the app throws a >> NullPointerException or other weirdness, and some users appear to be >> getting corrupt statically served files (.js files from the war), so that >> they have to flush their browser's cache for the app to work again. >> >>>>> >> >>>>> Is this supposed to work perfectly, or do you expect a brief dead >> period like this? Is there a recommended way to deploy new code without >> the 2-second snafu? >> >>>>> >> >>>>> Jetty is behind nginx with simple proxy configuration, if that >> matters. I'm running 9.0.5, but could upgrade. >> >>>>> >> >>>>> thanks, >> >>>>> Rob >> >>>>> >> >>>>> >> >>>>> [1] >> http://stackoverflow.com/questions/22357690/can-jetty-hot-redeployment-work-without-service-interruption >> >>>>> [2] >> http://www.eclipse.org/jetty/documentation/current/hot-deployment.html >> >>>>> _______________________________________________ >> >>>>> jetty-users mailing list >> >>>>> [email protected] >> >>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Jan Bartel <[email protected]> >> >>>> www.webtide.com >> >>>> 'Expert Jetty/CometD developer,production,operations advice' >> >>>> _______________________________________________ >> >>>> jetty-users mailing list >> >>>> [email protected] >> >>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >>> >> >> >> > >> > _______________________________________________ >> > jetty-users mailing list >> > [email protected] >> > https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> -- >> Jan Bartel <[email protected]> >> www.webtide.com >> 'Expert Jetty/CometD developer,production,operations advice' >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
