【事象】
Redmineではプロジェクトを作成する際に、API呼び出しなどの際に利用するプロジェクトを一意に定めるための値として識別子というのを登録する必要がある。
この値は、通常プロジェクトを一度作成すると変更できない。
そのため、変な値が設定されない様に命名規則を設定しておきたい。
【対応方法】
現状デフォルト値を設定する方法はなさそう。
挙動を見る限りでは、一番最後に作成したプロジェクトの識別子の末尾を1インクリメンタルしている模様である。
なお、末尾がアルファベットの場合においてもインクリメントするようである。
(識別子abcで作成すれば、次回はabdがデフォルト値で設定されている)
【その他】
Redmine4.x系は未確認
「管理」→「カスタムフィールド」をクリックし、調べたいフィールドをクリックする。
その際のURLに記載されている番号がIDとなる。
自身がアクセス権限があり、調べたいフィールドが含まれているチケットに以下のURLでアクセスする。
https://RedmineのURL/issues.xml?issue_id=チケットNo&key=表示されたAPIアクセスキー
Timeout
リクエストを待つ時間
デフォルト60秒(60)
ProxyTimeout
mod_proxy経由でのリクエストを待つ時間
デフォルト300秒
但し、mod_proxy 内で ProxyTimeout が設定されていない場合はTimeoutの値を参照
(Apache コア機能 TimeOut ディレクティブ より抜粋)
5. mod_proxy 内で、 ProxyTimeout が設定されていない場合のデフォルトの待ち時間
keepAliveTimeout
HTTPセッションを閉じるまでの時間
当時間を長くすればするほど同じコネクションを使い回すので反応は早いが、待ち受けしておかないといけないのでリソースを消費する
KeepAliveをonにしておき、MaxKeepAliveRequestsで許容リクエスト数を設定する必要がある
デフォルト5秒(5)
maxIdleTime
アクティブスレッドがminSpareThreads以下で無い場合に、アイドルスレッドを停止するまでの時間をミリ秒指定
そのため、リクエストのタイムアウトに直接関わる値ではない
デフォルト1分(60000)
(Connector AJP/HTTP1.1)
asyncTimeout
非同期リクエストにおけるデフォルトのタイムアウト[ミリ秒]
非同期リクエストに関しては、以下の非同期処理の流れが分かりやすい(用途としてはオンラインというよりJavaBatch的な使い方か)
Tomcat 7も対応したServlet 3.0の変更点 後編：Tomcat 7の新機能で何ができるようになるのか？（2）（1/3 ページ） - ＠IT
デフォルト30秒(30000)
受付したConnectorが接続した後、レスポンスデータを返すまでの待ち時間
-1を設定するとタイムアウトは行わない
disableUploadTimeoutがtrueの場合は、アップロードのタイムアウトもこの値を参照する
デフォルト AJP：無限(-1) HTTP：60秒(60000)、但しserver.xmlに20秒(20000)が予め定義されている(=定義を削除すると60秒になる)
データアップロード中に使用されるタイムアウト値
disableUploadTimeoutがfalseが設定されている必要有
デフォルト5分(300000)
Connectorの停止処理が進む前にプライベートな内部Executorがリクエスト処理スレッドが終了するのを待つ時間
デフォルト0秒[BIOコネクタ]、5秒(5000)[NIO, NIO2, ARP, nativeコネクタ]
HTTPコネクションを閉じる前に次のHTTPリクエストを待つ時間
-1はタイムアウトせずに貼りっぱにする(この設定するのは用途限定でしないと危険すぎる…)
デフォルトはconnectionTimeoutの値を参照
一旦割愛(必要になった時に書き加える)
一旦詳細は割愛(必要になった時に書き加える)
この値を小さくすると、いくつけのケースでKeep Alive接続の待ち時間をわずかに効率化できるが、余程で無い限りはチューニングする値ではなさげ
(Connector HTTP2.0)
一旦割愛(必要になった時に書き加える)
StuckThreadDetectionValve
処理が遅い場合にログを吐き出したり、強制終了できたりする
thresholdがログだけ吐き出したい時間(秒)、interruptThreadThresholdが強制終了させる時間(秒)
定義例
<Valve className="org.apache.catalina.valves.StuckThreadDetectionValve" threshold="60" interruptThreadThreshold="120" />
CrawlerSessionManagerValve
一旦詳細は割愛(必要になった時に書き加える)
Webクローラによる大量のセッション生成を防止するためのValve
セッションを廃棄する時間
Tomcatではこの時間の起点をthisAccessdTime(今回のアクセス開始時間)とlastAccessedTime(前回のセッションのアクセス時間=ServletAPIのgetLastAccessedTime()で返却される時間))の2つの時間で定義する。
2つのセッションのアクセス時間の計算方法は、通常は前回のアクセス終了時間からの経過時間となる。
(org.apache.catalina.session.StandardSession.LAST_ACCESS_AT_STARTのプロパティ値で決定するが、余程でない限り触りにいかなくて良いと思われる)
Tomcatとして出てくる箇所はJavaDoc位しか見つけれなかった
コミットするタイミングで当値を経過していた場合はタイムアウトさせる
そのためコミットされないと評価されない
よく勘違いするのは、タイムアウト値過ぎてもトランザクションは動き続け、当値を評価するのはコミットするタイミングである
デフォルト10分(10 minutes)
定義例
<tomee> <TransactionManager id="Default Transaction Manager"> defaultTransactionTimeoutSeconds = 10 minutes </TransactionManager> </tomee>
一旦割愛(必要になった時に書き加える)
一旦割愛(コネクションプール側で設定する事が多いと思うので)
HikariCP
いろんなサンプルが載っていたのでわかりやすかった
com.zaxxer.hikari.HikariConfig#setIdleTimeout
Tomcat JDBC Connection Pool
ぱらっと眺めるのであれば、公式よりもやはり日本語で書いてくれた方が読みやすい
Tomcat JDBC Connection Poolの存在を忘れてました - Qiita
HTTPSession#setMaxInactiveInterval
セッションの有効期限の個別設定
@DataSourceDefinition#maxIdleTime
コネクションプールに未使用のまま状態で置いておく時間
@DataSourceDefinition#loginTimeout
データベース接続を行う際にログインできるまで待つ時間
com.sun.mail.smtp
(mail.smtp.connectiontimeout)
メール送信時のSocket read時のタイムアウト値
デフォルト無限
(mail.smtp.timeout)
メール送信全体の処理が完了するまでの待ち時間
デフォルト無限
(mail.smtp.writetimeout)
メール送信時のSocket write時のタイムアウト値
デフォルト無限
当値を制御しているのは、javamailの場合はSocketFetcher.javaである。
pop, imapも同様にタイムアウト設定があるが記載は割愛
システムに関する記述書：会社の内部統制の状況をどの様な手順などで運営しているかを記述したもの
受託会社確認書：システム記述書に嘘偽りがないことを確認した書類
【参考リンク】
受託会社確認書｜サービス：会計監査｜デロイト トーマツ グループ｜Deloitte
「クラウド」という業務委託のガバナンス最前線--前編：SOCRとは何か - ZDNet Japan
2. IT ガバナンスにおける EDM モデル
本ガイドラインでは、前節の IT ガバナンスの定義における経営陣の行動を、情報システムの企画、開発、保守、運用に関わる IT マネジメントとそのプロセスに対して、経営陣が評価し、指示し、モニタすることとする。
また、IT ガバナンスにおける国際標準であるISO/IEC 38500 シリーズ及び日本での規格である JIS Q 38500 より、評価（Evaluate）、指示（Direct）、モニタ（Monitor）の頭文字をとって EDM モデルと呼ぶ。
・評価とは、現在の情報システムと将来のあるべき姿を比較分析し、IT マネジメントに期待する効果と必要な資源、想定されるリスクを見積もることである。
・指示とは、情報システム戦略を実現するために必要な責任と資源を組織へ割り当て、期待する効果の実現と想定されるリスクに対処するよう、IT マネジメントを導くことである。
・モニタとは、現在の情報システムについて、情報システム戦略で見積もった効果をどの程度満たしているか、割り当てた資源をどの程度使用しているか、及び、想定したリスクの発現状況についての情報を得られるよう、IT マネジメントを整備すると共に、IT マネジメントの評価と指示のために必要な情報を収集することである。
平成31年 春期 システム監査技術者 午前II 問1 にて出題
3. IT ガバナンスにおける 6 つの原則
IT ガバナンスを成功に導くため、経営陣は、次の 6 つの原則を採用することが望ましい。
① 責任
役割に責任を負う人は、その役割を遂行する権限を持つ。
② 戦略
情報システム戦略は、情報システムの現在及び将来の能力を考慮して策定し、現在
及び将来のニーズを満たす必要がある。
③ 取得
情報システムの導入は、短期・長期の両面で効果、リスク、資源のバランスが取れ
た意思決定に基づく必要がある。
④ パフォーマンス
情報システムは、現在及び将来のニーズを満たすサービスを提供する必要がある。
⑤ 適合
情報システムは、関連する全ての法律及び規制に適合する必要がある。
⑥ 人間行動
情報システムのパフォーマンスの維持に関わる人間の行動を尊重する必要がある。
平成31年 春期 システム監査技術者 午前II 問3 にて出題
【参考リンク】
経済産業省 平成30年度システム管理基準
https://www.meti.go.jp/policy/netsecurity/downloadfiles/system_kanri_h30.pdf
