Get visibility and insights across your whole organization, powering actions that improve security, reliability and innovation velocity.
WebSocketが一番速いアプリケーションサーバはどれだ?:Tomcat、Jetty、Socket.IO/Node.js性能比較(1/3 ページ) はじめに 2012年の10月にWindows 8が発売され、そこに搭載されたInternet Explorer(以下、IE) 10ではHTML5の機能が利用できるようになりました。また、2013年の2月にWindows 7版のIE 10もリリースされ多くのユーザーがHTML5の恩恵を受けられるようになりました。 HTML5の機能の多くは、Webブラウザ側で実装されれば、HTMLやCSSを適切に記述することで利用が可能です。しかし、今回取り上げるWebSocketはサーバ側でも機能の実装が必要です。このため、WebSocketを利用する場合はWebブラウザだけではなくサーバを選ぶ必要があります。 WebSocketそのものの技術的な解説は、以下
「Web アプリのバージョンアップ時に Tomcat を再起動してもいいのは小学生までだよねー」 ということで、Tomcat でダウンタイム無しで Web アプリのバージョンアップをする方法についてまとめてみる。 Parallel Deployment Tomcat 7 から Parallel Deployment という機能が追加され、同一 Web アプリの複数バージョンを同時にデプロイができるようになった。 war のファイル名を somewebapp##001.war 等にしておくことで、 - $CATALINA_BASE/ - webapps/ - somewebapp##001.war - somewebapp##002.warのように配備をすると、 http://localhost:8080/somewebapp/ でアクセスした場合に、セッションが継続している場合には古い方(
You can add system properties when running Tomcat (mvn tomcat:run). The syntax has the following format: <project> ... <build> ... <plugins> ... <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <version>1.1</version> <configuration> <systemProperties> <example.value.1>alpha</example.value.1> <example.value.2>beta</example.value.2> </systemProperties> </con
原文(投稿日:2009/8/5)へのリンク Google App Engineが当初使っていたウェブサーバ/サーブレットコンテナはApache Tomcatだった。しかし最終的にJettyへと変更された。開発コミュニティではこの決定により、なぜ変えたのか、Tomcatでなにか問題があったのか、と多くの人が問いを投げかけた。InfoQはJettyの開発元企業であるWebtideのチームにインタビューをする機会を得て、今回の決定の事情について詳細を聞いた。 InfoQ:GoogleがTomcatや他の選択肢でなくJettyをApp Engineに選んだのはなぜでしょうか。 GoogleがJettyを選んだ理由と思われる特質はサイズと柔軟性です。クラウドではサイズが重要です。Jettyのインスタンスを(Googleがしているように)数万動かすとすると、各サーバが1MB小さければ全体で数十GBのメ
In many production environments, it is very useful to have the capability to deploy a new web application, or undeploy an existing one, without having to shut down and restart the entire container. In addition, you can request an existing application to reload itself, even if you have not declared it to be reloadable in the Tomcat 6 server configuration file. To support these capabilities, Tomcat
id: 105 所有者: msakamoto-sf 作成日: 2007-02-25 15:13:44 カテゴリ: Java [ Prev ] [ Next ] [ 技術 ] お仕事のヘルプでJSPをデバッグしたい(但しEclipse抜き)とのこと。 ということで、取り急ぎTomcatの環境と、JSPのデバッグ?できるような基本的なサンプルを用意してみる。先方の環境として、JDK1.4(1.3?)、Tomcat4(多分、4)とのことなので、取り急ぎ合わせる。 Tomcat 環境 本筋と関係のないディレクトリは省いている。とりあえずで良いので、ユーザはrootで、いい加減でも動けば良いみたいなノリ。 /opt/in_vitro/apps/apache-tomcat-4.1.34/ ... 以降、TOMCAT_HOME bin/ ... 起動・停止シェルスクリプト conf/ ... XML設定
Java仮想マシンの配下では、多くのクラスが複雑に(かつ密接に)絡み合い、Javaアプリケーションの動作を支えています。しかし、複数のアプリケーションを利用しているうちに、相互のアプリケーション間で、同名でバージョンだけが異なるクラス(ライブラリ)が必要になったとしたらどうなるでしょう? しかも、そのクラスライブラリには、バージョン間の上位/下位互換性がないとしたら、どうしたらよいでしょうか。 このように、バージョンアップしなければアプリケーションBが動かない、バージョンアップすればアプリケーションAが正常に動かなくなってしまうというケースは、多くのアプリケーションが並存するサーバ上においては、大いにあり得ることです。 そこで、Tomcatのようなコンテナでは、複数のクラスローダに階層関係を持たせることで、個々のクラス(ライブラリ)の独立性を保証しています。クラスローダとは、その名のとおり
昨今、良くある(僕自身も好みの)組み合わせで、 ・IDE・・・Eclipse ・ビルドツール・・・Maven2 及び Eclipse m2eclipseプラグイン ・コンテナ・・・Tomcat 及び Tomcatプラグイン ・フレームワーク・・・Seasar2 及び S2ファミリー と言うのがあります。 しかし、開発環境構築は結構難問です。 Eclipse、Maven2、m2eclipse、Tomcatプラグイン... それぞれ「個別の問題」にフォーカスしたツールを組み合わせようとすると、 細かいところでギャップがあって、各ツールの長所を活かしつつ、うまく連携させるには試行錯誤が必要です。 そこで、以下のような各ツールの長所を活かせる開発環境を作ってみる。 1.Eclipse ・修正したソースのインクリメンタルコンパイル。 ・その他もろもろ... 2.Maven2 ・pom.xmlによるプ
EclipseのTOMCATプラグインで、オプションの「開発用クラスローダーを有効にする」にチェックすると、 org.apache.catalina.loader.DevLoader というクラスが無いために例外がおきます。 (DevLoader.zipの展開を忘れずに参照) ここでは、 %TOMCAT_HOME%\Server\classes\配下に(展開した時のフォルダ構成のまま)コピーする。 という手順で解決していますが、TOMCAT6の場合は%TOMCAT_HOME%\Server\classes\がありません。 Tomcat5とTomcat6の違い に違いがTOMCAT5と6の違いが以下のようにあります。 Tomcat5とTomcat6では、フォルダ構成が下記の通り異なります。 Tomcat5のcommon、shared、serverの各ディレクトリがTomcat6
あまりに久しぶりな日記だ。 m2eclipseプラグインとtomcatプラグイン(DevLoader)を使用したWebアプリ開発の際、tomcatを開始するとFilter初期化時に「java.lang.ClassCastException」が発生してしまう現象に何回も遭遇しました。 原因は、tomcatプラグイン(DevLoader)が対象とするライブラリから servlet-api jsp-api を除外できないためでした。 pom.xml から一旦上記を除外して対応したりしていましたが、せっかくDevLoaderのソースは公開されているので、改変してみました。 (単にservlet-apiやjsp-apiをロードしないだけですが) http://mrsp.sourceforge.jp/devloader/ ここの「devloader-3.1.jar」を $TOMCAT_HOME/ser
Tomcat 6では、NIO APIを使用した新しいHTTPコネクタが追加されました。これは非ブロッキングIOをサポートし、複数のリクエストを同時並行して受け付けることができます。Tomcat 6はこの新しい機能を応用してCometをサポートしています。新しく生まれ変わったHTTPコネクタのテストも兼ねて、Cometサーブレットを作成して遊んでみよう。 catalina.jarをクラスパスに追加 Comet関連のAPIはJ2EE標準のAPIではなくTomcatプロジェクトの独自実装です。このため、Comet関連クラスは servlet.jarではなく、Tomcat自身(catalina.jar)に含まれています。Cometなサーブレットをコンパイルするには catalina.jarにクラスパスを通す必要があります。開発環境がEclipse 3.2+Tomcatプラグインならば、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く