> > Wouldn't every application which isn't as dumb as the chat example > > (which does not care about the content it reads but simply passes it > > back to it's clients) need to implement it's own mechanism to check > > whether there is enough input available to start parsing a chunk of > > data? > > > Either that, or you can parse the information "on demand", as > it comes in.
The problem is: I only know that SOME input is available, but I don't know if the parser will succeed without a blocking read. With other words: I cannot know whether the last closing bracket of my SOAP request is already available in the input unless I know the number of bytes of the complete chunk in advance. If I want to parse it 'on availability' (I think 'on demand' is not the right term here) I would need a parser that suspends on reaching the end of available data (returning something like a 'not finished' indication) and can be resumed with the next read event. Otherwise I would have to try a new parse attempt (starting with byte 0 again) with each read event, until I finally succeed. Furthermore, I usually parse a sequence of characters, not bytes, and I think it does not make sense to start decoding the bytes in the input if there are still bytes of the message missing. Thus, my conclusion is that 'parsing on availability' is not a solution except for some rare situations. > What you seem to want is more in line with the "asynchronous servlet" Well, for the scenario I am working on, you are right. But the problem of knowing whether a complete chunk of input is available for processing without a blocking read is also present if a Servlet reads one SOAP request after the other within the scope of the same http request. > As for blocking reads in your servlet, I don't think there is > anything > which prevents you from doing multiple blocking reads from > the request > input stream in a READ event. The description of the READ event is as > follows: > > EventType.READ: This indicates that input data is available, and that > one read can be made without blocking. > > It does not say you are not allowed to do additional reads (with the > risk of blocking). Note that I have not tried this yet, and > it might not > work. It would be useful to have a thorough description of > the API which > documents these things (as well as other issues such as > synchronization, > lifetime/scope of the event object, etc), with a clear seperation > between API (things one can depend on), and implementation details > (things which happen to work some way due to the current > implementation > but are subject to change without notice). I totally agree! Matthias --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
