Hi Pete,
first thanx for the answer. Unfortunately some questions are always a
little bit unclear ... please see my comments below.
peter royal wrote:
On May 3, 2006, at 2:03 PM, Michael Bauroth wrote:
1) In a decoder method I want to do a pattern search. Can I assume,
that in the meantime (imagine the search takes longer) the incoming
ByteBuffer doesn't increase?
yes. Just do it synchronously wrt the decoder method returning.
so I don't need an aquire at the beginning of the method and still set a
local variable to in.remaining(). Right?
2) Imagine I use instead of the SimpleByteBufferAllocator the default
one. Now it can happen, that while long lasting decoding additional
worker threads will be opened. When I'm right and I've added my
Decoder to the Acceptor chain (not to each session), now exists for
each worker thread one decoder. Right? Can I assume, that for a
defined session XYZ all incoming data chunks flows through the same
decoder or can it happen, that in the worst case one data snippet for
the session XYZ flows through decoder A and the second through
decoder B and that in the worsest case parallel?
Depends on whether or not your ProtocolCodecFactory returns the same
Decoder instance each time getDecoder is called, or a new instance.
If you have the same instance, you're still fine, as long as you don't
store state in class-level variables.
I only store attributes directly in the sessions. Is this ok?
3) When I do in my decoder some pattern search and don't restore the
position in the ByteBuffer to the initial one, can I assume, that the
data are consumed and will be dropped / overwritten or simple cleared
through the system in the next time?
yes. If you look at the ProtocolCodecFilter, it does nothing more than
pass the buffer into the decoder.
Or must I modify the incoming ByteBuffer for such things in that way,
that I create a new ByteBuffer, where I copy only a part from the
incoming buffer and forward it?
If you pass the same ByteBuffer on, just be sure to acquire/release it,
since by default, the ProtocolCodecFilter assumes that the buffer is
done once the decoder has run.
This part I haven't understand. In which case are the aquire() and
release() methods related to my question? Or better, let me write a
little sample:
The ByteBuffer contains 2 bytes. I call
in.get()
in.get()
the position is now increased. When I leave it in this state, the two
bytes are not any longer available in the messageReceived method from
the session (they are already consumed). A call of in.remaining() in the
messageReceived() method gets 0 bytes. Right?
4) For a pattern search in the ByteBuffer I want to use a modified
Boyer Moore algorithm. That means, that I have to skip chunks of
bytes in the ByteBuffer and must use instead of simple get() the get
(index) method. Two questions: Will the get(index) method change the
position() of the ByteBuffer too?
no, get(index) will not change the position.
So I have to set the position manually afterwards or set it before and
call a simple get(). Right?
And ... seems the idea to be good or do you think, that the use of
simple get() method works faster?
Both are probably equally as fast, in the manner in which we're
concerned, since it probably boils down to direct array access either way.
-pete
Once more. Thank you for your help.
Michael
