newToMina wrote:
Thanks for the quick response Ashish...
I don't have any control over the protocol. The root element is
<Message></Message>. The communication is always between 2 machines. A 3rd
party machine connects to our server and keeps sending xml documents (it
could be one at a time or many). We have to process it and send the response
back. The maximum number of possible simultaneous messages is about 5000.
What do you mean by 'simultaneous messages' ?
Average size of a message will be 2KB. All these will happen in real time
when a customer scans a gift card.
If I write the completed xml document to the decoderoutput and wait for the
completion of the next message (if the bytebuffer has more data on it), then
shouldn't I be holding up the first message until the next one completes and
thus by increasing the response time?
As soon as you have decoded a message, you should push it to the next
filter. Let's consider the different possible cases :
1) You receive a byte buffer containing a starting message, but it is
not complete. As you can't find the </message> tag, you have to wait for
the next messageReceived() event.
2) The byte buffer contains exactly one message (ie, the </message> tag
is at the end of your byte buffer. Perfect. You transform it to an
objetc, and call the handler. You are basically done.
3) The byte buffer contains one message plus some extra bytes. As you
have found the </message> tag for the first message, get the
corresponding bytes, create you object, and push it to the handler. When
done, read the remaining bytes searching for the next </message> tag.
You won't find it, so you wait (very similar to case 1)
4) You have more than one message in the incoming byte buffer. Just loop
building new objects from the message you find, calling the handler for
each of them, until you can't find a </message> in the byte buffer, or
until the byte buffer is empty. This is the general case, in fact.
When I say 'you wait', that means you just return, as the byte buffer
won't be discarded, but it will be completed by the next incoming bytes.
That should do the trick, and it will be as fast as you need.You won't
have a response time increase.
I saw another post where the user was making use of a queue to process the
continuous xml stream. Could anyone provide more insight on this approach?
This is the same thing, but instead of calling the handler directly, you
first build all the objets from the found messages, store them in a
queue, and then push the queue to the handler (or the next filter). It's
up to you, your choice.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
