I'm working on a project that is using FI documents in a stateful
protocol. Currently we are using the standard request/response paradigm
for the protocol, but the socket and the streams aren't closed because
the protocol is stateful.
Currently, it appears that the code for the FI parser uses by default a
buffer size of 1024 although there appears to be a configuration
parameter that can change this. This causes some problems because our
streams never reach the end (i.e. aren't closed) and therefore the
stream being used by the parser never receives a -1 result from a read
operation. In addition, if our documents are small, which most are, the
parser blocks, waiting for the buffer to read the full 1024.
My questions are what was the design decision behind this (i.e. to
support buffered streams I would assume)? What overall impact would
reducing the size to something like 16 have? I can't seem to get the
system property to take hold, even when used command line, any ideas
why? and finally, wouldn't it make more sense to have a resizeable
buffer rather than a fixed sized buffer?
The reason I suggest the resizeable buffer is that is seems like more
ideal to parse what you can immediately, rather than blocking. Beside
when parsing the header, the buffer in some cases need be only 4 bytes
long.
Because our solution is relying on the FI parser to determine where the
end of the incoming message is so that the message can then be
processed, any blocking operation comes at a large price. One possible
solution I've thought of is to make my own InputStream that can
determine when the end of the FI document is encountered and can then
pretend as though it has reached the end of stream and return -1 from
the read operations. This seems slightly orthogonal to what the FI
parser is doing for the most part (besides obviously calling to the
ContentHandler). It really seems as though the FI implementation should
either provide this type of InputStream, or be able to provide a good
non-blocking solution to this type of scenario.
Thoughts or suggestions would help immensely.
Thanks,
Brian Pontarelli