Tomcatの最大使用可能スレッド数の見積 - 銀の鍵 (The Silver Key)
我等が働き者、Tomcat。君は一体、どの程度まで多くのスレッドを作成してリクエストをさばく事が出来るんだい？ まず最初にLinuxのスレッドライブラリについて軽く言及しておかねばなるまい。Linuxのスレッドライブラリには二種類ある。 まず、昨今のLinux（Kernel 2.6及びそれ以降）で用いられているNTPL（Native POSIX Thread Library）。これは1:1モデルのスレッドライブラリで、スレッドをプロセスとして実装してある。SolarisなどではいわゆるLWP(Light Weight Process)をしてスレッドを実装してあるのだけれども、Linuxではスレッドもプロセスも同じtask_struct構造体として扱い、COE（Context Of Execution、実行コンテキスト）をそれぞれ用に割り当てて用いているようだ。各プロセスは独立した仮想メモリ
Commons DBCPを超えるTomcat JDBC Poolとは
Commons DBCPを超えるTomcat JDBC Poolとは：Tomcat 7の新機能で何ができるようになるのか？（番外編）（1/2 ページ） TomcatのDBコネクション・プールは2つある ＠IT読者の皆さんは「Tomcat JDBC Connection Pool」をご存じですか？ 通常、TomcatのDBコネクション・プールといえばApache Commonsプロジェクトの「Commons DBCP」を想像するかと思います。しかし、Tomcatには「Commons DBCP」以外にもDBコネクション・プールの実装が存在します。それが、「Tomcat JDBC Connection Pool」（以下、Tomcat JDBC Pool）です。 Tomcat JDBC Poolとは、Apache Tomcatプロジェクトが独自に作成したDBコネクション・プールの実装のことです。
Tomcat7の新機能(CSRFとメモリリーク） - カタヤマンがプログラマチックに今日もコードアシスト
巷でうわさのTomcat7ですが、新しい機能として Generic CSRF protection Web application memory leak detection and prevention という気になる機能が入っているね、とT2チーム内で話題になっていました。 Tomcatのサイトを見るとバイナリ版配布が開始されていたので、とりいそぎJadってみることにしました。 Generic CSRF protection CSRFについては高木先生などの専門家に解説をまかせますが、要はサイト外からのリクエストによって不正な処理が行われてしまう、というセキュリティホールです。（リンクを押すと、mixiに勝手に書き込まれてしまうとかありましたよね） これを防ぐには、リクエストデータがサイト外からきているかどうかを判定する（=リクエストがサイト内から来ていることを判定する）ことが必要です
Servlet で redirect した時の location ヘッダにセットされる ホスト名ってどうなっているのか - Takuya71 のぶろぐ
Servlet で redirect した時の location ヘッダにセットされる ホスト名ってどうなっているのか Servlet では HttpServletResponse.sendRedirect(location) メソッド使ってリダイレクトできますが、 この location に相対パスを設定した場合でも location ヘッダには 絶対パスが出力されます。 この時のホスト名は なんの情報から設定されるのだろうか？ という疑問 Tomcat7.0 の ソースで調べてみた。 Response.java をみると sendRedirect(String location) があり、この中で toAbsolute が呼ばれていて、ここで 相対パス -> 絶対パスへの変換がされているようだ ... protected String toAbsolute(String locatio
wall-climb » TomcatのSSL/non-SSL通信時のリダイレクト
「SSLアクセラレータ配下ぜ Apache自己圏 ? URL」ぜ SSLアクセラレータ配下ぜ Apacheのリダイレクト問題を記述したが、こぜ ApacheがTomcatと連携している場合に同じ問題がTomcat側で発生する。つまり、以? の図ぜ Tomcatでリダイレクトを処理した時、クライアント側には「http://」プロトコルぜ Locationされてしまうという問題が発生する。 クライアント ｜ SSL通? SSLアクセラレー゜ ｜ non-SSL通? Apache ｜ non-SSL通? Tomcat Apache側ではこの問題に対応する為に、SSL、non-SSL2つぜ VirtualHostを作成し、ServerName定義を分けることで対応した。Tomcat側でもSSL、non-SSL2つのコネクタを用? すればこの問題に対応可能となる。server.xmlは以下のように?
nginx(ssl offload)+tomcat - nori3tsu's blog
nginxでssl offloadしてtomcatをバックに置く場合の簡易設定メモです。 nginx /etc/nginx/conf.d/app.conf upstream app { server localhost:8080; keepalive 16; } server { listen *:443 default_server; server_name app.example.com; server_tokens off; # ssl ssl on; ssl_certificate /etc/nginx/certs/app/certificate.crt; ssl_certificate_key /etc/nginx/certs/app/rsa-secret.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!AD
アクセスログに送信元のIPアドレスを出す | code up
AWSにて、ELBからのリクエストをEC2のApache httpd経由で最終的にTomcatで受け取っている。ロードバランサとリバースプロキシの構成。 この構成でTomcatのアクセスログに送信元のIPアドレスを出力するずばりな方法が見つからなかったので、試してうまくできた方法を記録。 以下はconf/server.xmlの設定値だけど、context.xmlでも試してないけどいけるでしょう、たぶん。 <Valve className="org.apache.catalina.valves.RemoteIpValve" internalProxies="10\.\d{1,3}\.\d{1,3}\.\d{1,3}" /> <!-- Access log processes all example. Documentation at: /docs/config/valve.html Note
Tomcatのproxyなんとか周りについて – ハック｜無料グループウェア「アイポ」
tomcatをロードバランサ越しに使うと、 ドメイン、ポート、プロトコルが合わなくなるケースがよく有りますがてっとり速く解決するのが以下の方法 server.xmlのconnectorのところに <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" proxyName="{lb-domain}" proxyPort="443" scheme="https" secure="true" /> と項目を追加する。 ロードバランサ側が 「X-Forwarded-For」「X-Forwarded-Port」「X-Forwarded-Proto」に対応していて Tomcat6,7であれば http://tomcat.apache.org/tomcat-6.0-doc/api/org
Java におけるプロキシ経由のリモートIP 取得あれこれ
Servlet プログラミングで、リモートホストの IP の取得に HttpServletRequest#getRemoteAddr をしたところ、プロキシ経由からのアクセスだったためにプロキシサーバの IP が取得されてしまうという、さみしい事態になることがあります。 この対策として 3 パターンほど挙げます。 HttpServletRequest#getHeader("x-forwaded-for") を利用 (Tomcat6以降のみ)RemoteIpValve を利用 Byteman を利用 プロキシの想定 今回はリバースプロキシとして、CentOS 6.4 に yum でインストールした Nginx を利用していると想定します。 インストールしていない場合は以下を実施ください。 # rpm -ivh http://nginx.org/packages/centos/6/noarch
TomcatではなくJBossを選ぶ○○の理由 - nekop's blog
java-ja忘年会でharu860さんに聞かれたのでエントリを書くよ。と思ってざっくり書いて放置していましたすみません。この質問へのよくある回答として「EJBを使うとき」みたいなものがありますが、この回答は多くの場合何の役にも立ちませんね。このような回答をする人はJBossをあまり良く理解していない可能性があります。 というわけで、JBossを使っているユーザがどのようなモチベーションでTomcatではなくJBossを使うのか、もしくは完全にJBossに乗り換えているのか、実例ベースの理由をいくつか紹介しましょう。 機能 Tomcatで提供される機能は基本的にServlet, JSP, JDBC接続プールのみで、他のものは提供されていません。シンプルですが、他のものが必要になったときに、それらをインテグレーションするコストが発生するなど、少し面倒なことになります。 TomcatになくてJ
How to install CDI in Tomcat?
Introduction JSF was since version 2.2 moving towards CDI for bean management. Since JSF 2.2, as part of Java EE 7, there's the new CDI compatible @ViewScoped and there's the CDI-only @FlowScoped which doesn't have an equivalent for @ManagedBean. Since JSF 2.3, as part of Java EE 8, the @ManagedBean and associated scopes from javax.faces.bean package are deprecated in favor of CDI. Now, there are
Configuring CDI with Tomcat example
In this tutorial you will learn how to configure Contexts and Dependency Injection (CDI) with Tomcat. Tomcat is not a full-blown EE container so we must include some required libraries in order to enable CDI support. In this tutorial we will cover CDI configuration in Tomcat and also provide a working sample. This tutorial considers the following software and environment: Ubuntu 12.04 JDK 1.7.0.09
Javaで乱数を生成する(4) - あしのあしあと
「Javaで乱数を生成する」というタイトルだが、生成できるのは疑似乱数。疑似乱数生成器の動作概要については「Javaで乱数を生成する(1)」に説明した。また、Javaでどのように実装するかについて「Javaで乱数を生成する(2)」に説明した。「Javaで乱数を生成する(3)」でTomcatのソースを読む準備をして、いよいよ疑似乱数の生成方法を教えてもらうことに。 なお、本エントリのソースコードは、全てApache Tomcat 7.0.5の“org.apache.catalina.session.ManagerBase”クラスと“org.apache.tomcat.jni.OS”クラスから引用*1している。 Tomcatでは、セッション管理を行うための“org.apache.catalina.Manager”インターフェースが用意されている。実際に、通常のセッション管理を行うマネージャや、
【デプロイ】Fabricを学ぶ：Vol.02：tomcatの起動完了を監視する【python】 - 文系プログラマによるTIPSブログ
Vol2です〜 Fabric連載第2回です。 Vol01で結構沢山書いてしまったので書く事がなくなりつつあるので、役に立つかもしれないタスク等を公開してみようとおもいます。 今回のお題は tomcatの起動完了を監視する です。 では早速いってみましょう。 Fabricでtomcatの起動完了を待つ まずはタスクのサンプルです。 #coding:utf-8 import os, time from fabric.api import env, run, sudo, local, put, cd from fabric.decorators import task from fabric.utils import abort from fabric.colors import red, green, yellow, cyan env.warn_only = True @task def mo
アプリケーションサーバをダウンさせる時に、セッションをどうするか？ : funasaki
前回の書き込みから随分時間が経過してしまいました。 引き続き、ロードバランサ＆セッションネタを続けます。 下記のようなパターンを考えます。 アプリケーション(AP)サーバが３台立っているとします。（サーバ1,2,3） そのフロントにロードバランサが立っていて、アクセスを割り振っています。 そこで、サーバ1をダウンさせる場合、サーバ1 が持っているセッションはどうなるか？ APサーバ間で、セッションレプリケーションを頻繁に行っていれば、サーバ1がダウンしても、他のサーバ2,3で同じセッションに接続できます。セッションレプリケーションを、サーバをダウンさせるタイミングで実行するように、AP 側で設定することも可能です。セッションレプリケーションにより、シリアライズされたセッション情報を DB に格納する手段もあります。 セッションのデータサイズが大きく、全 AP サーバ間で共有してしまうと、リ
LBを経由して、毎回同じAPサーバへアクセスさせるには？（Sticky Session） : funasaki
ロードバランサ(LB) を立てて、バックエンドに複数のAPサーバを立ててみたけども、LBを経由して毎回同じAP サーバへアクセスさせたい時、ありますよね。APサーバ1に、一度アクセスしていて、そのセッションが保持されている場合です。そんな時に、APサーバ2にLBからアクセスが振られてしまうと、またログイン画面が表示されてしまう、というパターンに陥ることがあります。 これをLBで、どのように調整しているかというと、APサーバ1,2ごとにそれぞれ異なる識別子を持たせます。 例えば APサーバ1 には jvm1 を、APサーバ2 には jvm2 という値を識別子を持たせます。そして、個々のユーザの Cookie 内に仕込まれる JSESSIONID の末尾にこれらの値を挿入させます。( Tomcat 等のアプリケーションサーバ側の設定で、自動的に挿入されます。） ユーザ１の JSESSIONI
Amazon DynamoDBによるTomcatセッション永続化とフェイルオーバー | DevelopersIO
Tomcatのセッション管理 Tomcatでクラスター構成にする場合、課題となるのがセッション管理です。ロードバランサーでセッションIDを保持することで、毎回同じサーバーにリクエストが向かうのであれば問題なさそうに見えますが、あるサーバーがダウンしてしまうとセッション情報が消えてしまいます。これを解決する方法として、データベースにセッション情報を保持する方法が一般的ですが、データベースへ負荷が掛かりますし、データベースが落ちたら困ります。何かもっと良い方法は無いかと皆さん思っていたはずです。そこで、AWSですよねー。AWSでは、ElastiCacheやDynamoDBがサービスとして提供されています。ここで、永続化をしっかりやってくれるのはDynamoDBであり、AWS SDK for Javaでの登場が待たれていたわけです。そして、このたび出てきました！ スティッキーセッション ロードバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Secure Bitbucket behind nginx using SSL | Bitbucket Data Center and Server 8.17 | Atlassian Documentation
Apache Tomcat 7 (7.0.109) - Proxy Support HOW-TO
Loading...