技術めも

まだwebsocketのネタが完成しないので、

小ネタを。

windowsでjmeterをGUIで起動するとき、

jmeter.bat

なるものをたたく。

ただ、こいつをたたくと、

一緒にcommandプロンプトのコンソールがあがるので、

若干わずらわしい。

そのため、

jmeter.batをちょっと修正。

%JM_START% %JM_LAUNCH% %ARGS% %JVM_ARGS% -jar “%JMETER_BIN%ApacheJMeter.jar” %JMETER_CMD_LINE_ARGS%

↓

start javaw %ARGS% %JVM_ARGS% -jar “%JMETER_BIN%ApacheJMeter.jar” %JMETER_CMD_LINE_ARGS%

これで、batを起動してもコンソールがでなくなる。

さらに、

Bat To Exe Converter

というソフトを使えば、batをexeファイルに変換してくれるから、

スタートにピン止めできる。

以上

ずいぶん間が空いたけど、

javaでwebsocketやるときのサーバ側クラス設計ができました。

↓のような感じです。

（クラス図あってるかな？？）

ポイントとしては、

• websocketのSessionインスタンスを内包するクラスを作る
• ユーザ情報はセッション内で管理する
• ペア（自分と相手）の情報を管理するクラスを作成しておく
• 実際のwebsocket処理では、スレッドセーフなCollectionを使ってインスタンスを管理する

という感じになります。

スレッドセーフなCollectionでないと、インスタンスの取り違えが起きますので、ご注意を。

ThreadLocalを使うという手もありますが、

websocketの場合、

• openハンドラの呼び出しは1回
• messageハンドラの呼び出しはn回
• closeハンドラの呼び出しは1回

なので、open時に必要なインスタンスを作成して、closeで破棄するとよいです。

（※messageで作成するときもありますが）

実は、websocketではこの考えは結構重要で、

たとえば、DB接続する際、

messageハンドラで、

connect -> disconnect

を繰り返すと、高負荷に耐えられないです。

ここで、

openハンドラでconnectし、closeハンドラでdisconnectする。

そして、messageハンドラで操作する、

という形だと接続のコストが抑えられるので、

結構有効です。

（※もちろん、アプリケーションの特性によりますが）

次は、javaのソースコードを公開する予定。

node.js側は気力があったら作成します。。