Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
Docker と SO_REUSEPORT を組み合わせてコンテナのHot Deployにチャレンジ - blog.nomadscafe.jp
「Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1」のその2です。 結論から言うと、「単体ではリクエストの取りこぼしが若干あるけど、Reverse Proxyを工夫すればコンテナのHot Deployを実現できるかも」という感じです。 Rhebok の SO_REUSEPORT 対応 前回は簡単に検証するためにmemcachedを使いましたが、今回はアプリケーションサーバが対象ということで、 unicornの2倍ぐらい速いRackサーバであるRhebokに手をいれてSO_REUSEPORT対応しました。version 0.2.3〜です。 rhebok | RubyGems.org | your community gem host 起動時に ReusePort オプションを追加します。 $ bundle exec rackup -Ilib -s Rhebok
LL言語でのhot deployとJavaでのhot deploy - wyukawa's diary
JVM Operation Casual Talksで出てた話としてJavaでhot deployってどうしてんの？ってのがありました。 hot deployっていうのはアプリケーションコードを変更してもAPサーバーを再起動せずに反映する技術です。 この辺別に僕は全然知らないし答えを持っているわけではないですが、まあちょっと興味があったのでLL言語でのhot deployとJavaでhot deployを簡単に調べたのでメモっときます。 コードを変更してAPサーバーを再起動する場合、APサーバーが止まっているときにアクセスが行くと困るので、ロードバランサから外してAPサーバーを再起動してまた戻すみたいなことをやるのがオーソドックスな方法のようですが、hot deployだとそういったことをやる必要が無くなります。 Server::Starterから学ぶhot deployの仕組み - $s
それは、ブラウザからアップロードされたファイルの保存をどこで、実装させるかということです。 ファイルの保存は､プレゼンテーション層のHelperロジックなので､それ用のコンポーネントを作り､ActionにDIします。なぜ、Serviceでやらないかというと、トランザクションは必要としないからです。 GWを使いきり､HOT deployを完成させました。 HOT deployとは何か。アプリケーションサーバを稼動させたまま､クラスを追加､変更しても､アプリケーションのリロードは不要で､その変更が即座に認識される技術です。JavaEEのアプリケーションサーバにありがちなjar形式にまとめてどこかに配置するだとか、そんな面倒なことは必要ありません。EclipseのようなIDEを使っているなら､ソースを保存するだけでいいのです(ソースを保存するとクラスファイルを書き出す設定(build autom
![[Seasar]HOT deploy完成 - ひがやすを blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
普通のサーバでDocker ContainerをHot DeployしたかったのでProxy書いた - Hateburo: kazeburo hatenablog
2018年も後半だけど、普通のサーバ上でコンテナをHot Deployしたいと思ってproxy書いた github.com 任意のラベルがついたDocker containerのpublic portをdocker api経由で取得して、private portをlistenして、proxyを開始するものです。 ラベルがついたコンテナが複数個あると、必ず一番新しいものだけにproxyするようになってます。 これで、みんな大好きserver_starterと組み合わせると、Hot Deployができます。 使い方 コンテナを起動 $ KILL_OLD_DELAY=5 start_server -- docker run -P -l app=nginx nginx public portが32774、private portが80となります $ docker ps CONTAINER ID I
Seasar2.4.xのHOT deployでは、filterやutil、entityといったのようなSMART deploy対象外のクラスから、actionやservice、dao、dtoといったSMART deploy対象のクラスを参照すると、ClassCastExceptionが発生する。この対策を考えてみた。 ちなみに、COOL deployでは発生しない。 2009/4/14 追記 utilやentityがSMART deploy対象外クラスと書いたが、S2Containerにコンポーネントの自動登録がされない(おそらくS2Containerがインスタンスを管理する必要がないから)だけで、コードの変更はHotに反映されるし、クラスローダーもちゃんとHotdeployClassLoaderになる。なので、SMART deploy対象外というのは誤りと思いますので、訂正しました。 原
実際に利用してみての注意点としては，再起動せずに変更を反映するホット・デプロイ機能は，クラス数が多くなると遅くなることを挙げた。開発が進みクラスが増えてくると，最終的はホット・デプロイを使わずにアプリケーション・サーバーを再起動した方が早くなったという。 Seasar Conference 2009 White でもそんな話があったようだし，最近 ML でも問い合わせがあったし，某巨大掲示板でも話題になってたので，少し (？) 書いておきます． まず，HOT deploy では必要となったコンポーネントだけがロードされます． 例えば Web アプリであれば SAStruts や Teeda などのフレームワークがリクエストに応じて fooAction とか fooPage という名前のコンポーネントを Seasar2 に要求するところから始まります． その際，Seasar2 はファイルシス
Slim3では、ルートパッケージ直下がagileパッケージとfirmパッケージに分かれます。agileパッケージには、agileに開発する必要のある機能要件に応じたクラスが入ります。firmパッケージには、ユーザの要件には直接関係しない非機能要件に応じたクラス(一般的にはインフラストラクチャ層のクラス)が入ります。 例えば、ルートパッケージがtutorialの場合、次のようになります。agileとかfirmの名前はもちろん自由に選べます。 tutorial root package tutorial.agile agile package tutorial.agile.action agile package for action tutorial.agile.xxx agile package for xxx tutorial.firm firm package tutorial.fir
元ネタ http://ducquoc.wordpress.com/2010/11/06/eclipse-wtp-tomcat-hot-deploy/ EclipseでWebプロジェクトを作るときはWTPを使っています。tomcatプラグインなんてのもありますが、mavenでのライブラリ管理と相性がイマイチなので最近はもっぱらWTPです。 んでデフォルトままWTPにアプリケーションデプロイすると、tomcatのserver.xmlに <Context docBase="appname" path="/appname" reloadable="true" source="org.eclipse.jst.j2ee.server:network-application"/></Host> のような設定でデプロイされます。reloadable="true"とかあるのでクラスファイルに変更があったりす
gunicornをsupervisorで制御しつつhot deployできるようにする - （ひ）メモ
タイトルの通り、gunicornなWebアプリをsupervisorで制御しつつhot deployできるようにしたメモです。 登場人物 supervisor v3.3.1 gunicorn v19.9.0 start_server v0.34 unicornherder v0.1.0 envdir v0.7 の standalone版 ちなみに checkinstall で雑にdeb化 問題 gunicornのhot deployを利用する場合、直接はsupervisorの制御下に置けない gunicornはhot deployの仕組みを持っている Upgrading to a new binary on the fly 流れ gunicornのmasterプロセスにUSR2シグナルを送ると、新しいmasterプロセスを産む つまり新masterの親プロセスは旧master 旧maste
久々にJava Servletをさわっていて、ソースファイルの修正のたびにjettyを再起動するのが苦痛になったのでJettyのHOT Deployの設定をしました。 一応、classの再読み込み処理が走って修正したソースの内容が反映されたので問題ないと思いますが、classのローディング周りは詳しくないので自信が無いです。 JettyのHOT Deployは、Jettyの起動オプションで scanIntervalSeconds を 1以上にすると有効になります。 scanIntervalSeconds で指定した間隔でwebapp下のclassファイルに変更あった場合、contextの再読み込みを実施するみたいです。 使用したフレームワークは下記になります。今回、RESTfulのJSON形式でMySQLのデータを出力できればいいので、View層のフレームワークは除外しています。 t2fr
[Seasar-user:16915] Re: [Seasar] HOT deploy と COOL deploy の挙動の違いを教えて頂けないでしょうか
[Seasar-user:16915] Re: [Seasar] HOT deploy と COOL deploy の挙動の違いを教えて頂けないでしょうか Koichi Kobayashi [E-MAIL ADDRESS DELETED] 2009年 2月 13日 (金) 21:00:04 JST 前の記事 [Seasar-user:16913] [Seasar] HOT deploy と COOL deploy の挙動の違いを教えて頂けないでしょうか 次の記事 [Seasar-user:16923] Re: [Seasar] HOT deploy と COOL deploy の挙動の違いを教えて頂けないでしょうか 記事の並び順: [ 日付 ] [ スレッド ] [ 件名 ] [ 著者 ] 小林 (koichik) です． Date: Fri, 13 Feb 2009 19:19:30 +
現時点(Seasar2.4.34まで)のHOT deployでは、HttpSessionを直接使用して、リクエストをまたいでHttpSessionに格納されたオブジェクトを取得してキャストすると、ClassCastExceptionが発生する。 例.XxxAction#indexでセッションにXxxDtoを格納して、XxxAction#index2でセッションから取得する。 public class XxxAction { @Resource protected XxxDto xxxDto; @Execute(validator = false) public String index() { HttpSession session = RequestUtil.getRequest().getSession(); session.setAttribute("xxxDto", xxxDto)
Hot Deploy利用時に、Hot Deploy対象外クラス内でHot Deploy対象クラスを使うための正しい作法は？ - Writing Some Code
「Hot Deploy」「Hot Deploy」連呼によって、今までで一番長いタイトル。。 気を取り直して本題を。 SeasarのHot Deploy機能はアプリケーションサーバーの再起動不要で修正コードがすぐに反映されるという便利な反面、ちょっとフレームワークの拡張をした時に「Hot Deployでは動くのにCool Deployでは動かない」（またはその逆）といったことにハマることが多いように思います。 S2Container本体やHot Deploy機能の理解が浅いせいもあって、自分も何回泣かされたことか。。。 今回もSAStrutsを使っていて遭遇してしまいました。 Hot Deploy対象外クラス（RequestProcessorやtaglibなど）内で、HotDeploy対象のServiceクラスやDtoクラスをgetComponentするような以下のコードを書くとClassC
僕はDropwizard使った事ないんですが、DropwizardでもServer::Starterを使ってhot deploy出来たら便利かも知れないと思ったので、 プルリクを送ってみたらマージしてもらえました。 次にリリースされる、1.0.0に含まれます。 Dropwizardの設定としては、yamlファイルに以下のようにinheritChannel: trueって書くだけでOKです。 server: type: simple connector: type: http port: 8080 inheritChannel: true Server::Starterのしくみや設定については以下を読んでください。 Server::Starterから学ぶhot deployの仕組み Server::Starter を Java で利用する方法。または、System.inheritedChan
Server Starter - a superdaemon to hot-deploy server programs
Server::Starter is a superdaemon that allows for hot deployment of server programs without downtime or resource leaks. It works by binding to TCP ports and spawning application server processes to handle connections while signaling old processes to shutdown when new ones are launched. This allows servers to be upgraded without interrupting service and prevents issues like file descriptor leaks tha
GitHub - dazraf/vertx-hot: A Maven plugin for hot-deploy of Vert.x projects
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
WebLogic的には、FastSwapというそうですが、アプリケーションサーバを稼動させた状態で、クラスに変更を加えたときに、その変更をアプリケーションを再デプロイなしに認識する機能がWebLogicにも入るようです。 http://edocs.bea.com/wls/essex/TechPreview/pdf/FastSwap.pdf 残念なのは、変更をリフレクションでは検知できないことかな。アノテーションをつけたり、削除したりしても変更できないということなので、いまどきのアノテーションベース、リフレクションベースのフレームワークは、その恩恵を受けることができません。 JavaRebelでもそうですが、VMレベルで変更を認識することが可能でも、結局フレームワークがHOT deployに対応していないことには、どうしようもありません。 JavaRebelのSpring対応では、クラスファ
https://github.com/lestrrat/go-server-starter The start_server utility is a superdaemon for hot-deploying server programs. Let's try. Environment: EC2 AMI ID: Amazon Linux AMI 2015.09 (HVM), SSD Volume Type - ami-9a2fb89a Go Sample app Install Go $ sudo yum -y install golang $ go version go version go1.4.2 linux/amd64 $ mkdir ~/gocode $ echo 'export GOPATH=$HOME/gocode' >> ~/.bashrc $ source $HOME
その HOT deploy を本番運用でも利用できないものかな。 LL のアプリケーションのように。 こう考えるのは三つの理由から。 一つは「アプリケーションを止められない」というビジネス的な都合。 そして「バグ修正や機能追加のモジュール入れ替えなどの複雑で面倒な作業をしたくないし、その方法や実施順序なんか考えたくもない」というのが二つ目。 技術的には、別に難しくはないのですが、運用を考えたときには、クラスタリングをさせておいて、その中の一つを止めて、デプロイを順々に繰り返せばいいだけなので、HOT deployを本番でも使うというのは、あまり賛成できません。 作業が面倒ならスクリプト化しておけばいいだけです。 開発時は、さくさくHOT deploy。本番は、パフォーマンス重視でCOOL deployってのが、最もそれぞれの特徴が生かされているので、いいと思いますよ。
Server::Starterの仕組みを学び、Golangでミニマムで 実装してみた
Hot DeployとはJavaのソースコードを修正した際にアプリケーションサーバの再起動無しに、 結果をすぐ確認できるもの。 じゃあこれをどう実現しているかというと、 クラスローダに読み込まれたクラスファイルは変更できない。 なのでHTTPリクエストのたびにクラスローダをつくって、変更後のクラスファイルを読み込む。 HotdeployFilterをみると下記のようにリクエストのたびにHotdeployBehaviorのstart、stopをよんでいる。 このstartからstopまでがHot Deployの範囲。 HotdeployUtilのstart、stopでも同様。 HotdeployBehavior ondemand = (HotdeployBehavior) provider; ondemand.start(); try { request.setAttribute(KEY,
GWTとS2(再)とHOT deploy
Issue 389: Refactor RPC out of RemoteServiceServlet これを拾ってきてRemoteServiceServletを継承。 public class GatewayService extends RemoteServiceServlet { private static final long serialVersionUID = 1L; protected String handleCall(RPCCall call, HttpServletRequest request, HttpServletResponse response) throws SerializationException, InvocationTargetException { String serviceIntfName = call.getInterfaceName()
One of the reasons why JavaEE does not have many succesful projects is that its development time is usually longer than other competitors’ time (PHP, Ruby, Python, ASP.NET, …) . Ok, we all know the burden of overly complicated design and over-engineered implementations from Sun, so let’s skip them and go to the one to be resolved: the Hot-Deploy time. In other words, the time for developers to see
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Seasar]HOT deploy完成 - ひがやすを blog
HOT deployでのClassCastException対策 - 日記のような何か
HOT deploy が遅くなるとき - 日記
HOT deployで嵌らないためのパッケージ構成 - ひがやすを技術ブログ
Eclipse WTP Tomcat hot deploy - Yamkazu's Blog
でHOT Deploy? - にゃんだふる日記
HOT deployでのClassCastException対策その2 - 日記のような何か
DropwizardがServer::Starterを使ったhot deployに対応しました
WebLogicでHOT deploy - ひがやすを技術ブログ
Go lang hot-deploy with go-server-starter
HOT deployを本番でも使えないか - ひがやすを技術ブログ
Golangで学ぶHot deployの仕組み
Hot Deploy - wyukawa's diary
Eclipse WTP Tomcat hot deploy