S2JMS開発記 S2JMS-Container の仕様を考える - 続・メッセージのマッピング

本件、了解です。

例外投げ続けると、コネクションが切られてしまうのは困りものですね。振る舞いとしては、たしかにリソースアダプタ側に例外を投げるしかないような気もするのですが。

この件は、私の方でも実装したときに振る舞いを調べてみたいと思います。

さて、昨日検討し残した BytesMessage と StreamMessage のマッピングを検討しましょう。

・・・が、この２つは扱いに結構悩みます。両方とも基本的にバイト配列をペイロードとしてもっており、readInt() や readLong() のようなメソッドを使って頭から順番にデータを取り出していく使い方です。両者の違いは、

のようです。どちらにせよ、Messageオブジェクト自体にデータを取り出すための振る舞いがついているので、単純にマッピングすることができません。手としては、以下の2つの方法が考えられます。

どちらも、いまいちピンときませんね。

この2つのメッセージは、何らかの形でエンコードされたバイト配列を扱うもののはずです。その用途から考えると

最初の8バイトは → long messageId
次の2バイト     → short senderId
・・・

のような感じで、エンコード情報にしたがって取り出してマッピングしてあげるのが親切なのでしょうね。

@Param(bytesMapping=1)  // 最初に取り出したlong値を割り当てる、の意
private long messageId;

@Param(bytesMapping=2)  // 2番目に取り出したlong値を割り当てる、の意
private short senderId;

のように、強引にアノテーションで指定することもできますが、ちょっとやり過ぎか？

そもそも、この2つのメッセージを利用頻度がどのくらい高いのか不明です。

最初は強引にbyte[]にマッピングする程度の実装に済ましておこうかしら。