anonymous wrote : I think it's the packet's responsibility to know how to encode itself, whether it encodes itself into one messagingbuffer (normal packet) or many (large message) is behaviour of the packet. Ok, i can move this. anonymous wrote : For large messages it's important we don't re-encode since that's a lot of copying. | If the logic for encoding is inside the packet, then it can make the decision at send time whether to just use the message's current buffers as is (for large messages) or re-encode them into another buffer (e.g. small messages). | | Again, this is up to the packet how it wants to encode itself. ok, again i can change this, I'll add some threshold level, i.e. if body < x add to original buffer. anonymous wrote : I don't think that is true. The decoded message can just maintain a list of messagingbuffers and a pointer (int) to a position in the first buffer where the data starts. Different messges can point to the same buffers if there are many messages in the same buffer. I don't think there is any need for re-assembling there. I think the point is that we cant decode the message until the last fragment has arrived. so we need to cache these buffers somewhere until we are ready. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167875#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...