Re: Interactions with org.apache.coyote.Request/Response
Irving, Dave wrote: There's no reason to use crap stuff like a BAOS. Just append byte arrays to a buffer. I'll take a look at how this is done in tomcat at the moment. The lower level code doesn't deal with IS/OS constructs, only with byte arrays. - It looks like I'll have to implement the ActionHook stuff to deal with call-backs from the request / response. Is there anything else I'll need to do? No. That's handy. The thing that's currently puzzling me a little is that the Response seems to have an associated stream, but doesn't really write to it itself. When should I actually go about pushing stuff in to that buffer at the connector level? In response to action call-backs? There's Response.doWrite, and that's it. - Im planning to have my NIOHttpProcessor use a CoyoteAdapter the same way the Http11Processor does. Does this sound reasonable enough? I don't care how how you name your classes ;) I was asking more about whether the existing CoyoteAdapter is likely to be re-usable in such a scenario If it's not reusable, then you are in trouble ;) Any pointers / help / advice would be gratefully received. Obviously, you can feel free to experiment all you want, but such a specific connector will not be included in Tomcat. Scalability will be far more limited with your design than even with the fully threaded Tomcat. If all the server is doing are small requests and responses, then it will work well (however, the hybrid model also likes this scenario, so I don't think it will even improve on that), otherwise it will just break. Sure, there's no way I could see this being included in Tomcat proper. Like I said, its just a prototype to see if it solves a specific problem im experiencing (I just cant configure tomcat with 20,000 threads). However, your reply confuses me somewhat. These are not going to be small requests / responses: In fact, they are likely to be fairly large multi-part messages (SOAP and the like). In addition, the processing latency is going to be large (potentially up to 15 seconds per request). Surely this is a reason ** for ** breaking the thread per connection model? Why would it break with anything other than small requests and responses? (There's nothing to stop parsing to be offloaded to a small - probably CPU count matched - thread pool)? If you get large responses, then I figure GC (and maybe memory usage) is going to be a problem (all your buffers will pile up, and most likely they are not going to be short lived objects). A thread will still be needed to run the servlet, so I hope the amount of time spent in the service method will be lower than 15 seconds. Otherwise, there's no real solution besides having a large amount of threads. Personally, I did experiment and implement a hybrid model for connection handling, which improves on some aspects of the regular thread per connection model, while keeping its benefits. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Interactions with org.apache.coyote.Request/Response
Remy Maucherat wrote: A thread will still be needed to run the servlet, so I hope the amount of time spent in the service method will be lower than 15 seconds. Otherwise, there's no real solution besides having a large amount of threads. Yeah, that's the crux of it I suppose. Do you know how much of tomcat assumes single thread request / response? After the request pops out of tomcat (via axis), the processing on our side is already asyncronous: - Receive request - Pass request on for asyncronous processing - Internal request processing completes - Unblock tomcat thread, allowing response to be handled back through axis and tomcat I appreciate that dealing with axis to handle asyncronous responses is out of the scope of this list, but what about tomcat? Would much need to be changed to remove the assumption that everything has been done when servicing the servlet returns? I.e: If I can make my web-apps behave asyncronously, would a whole load need to be done within tomcat to support this? Many thanks, Dave This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interactions with org.apache.coyote.Request/Response
Irving, Dave wrote: Remy Maucherat wrote: Yeah, that's the crux of it I suppose. Do you know how much of tomcat assumes single thread request / response? After the request pops out of tomcat (via axis), the processing on our side is already asyncronous: - Receive request - Pass request on for asyncronous processing - Internal request processing completes - Unblock tomcat thread, allowing response to be handled back through axis and tomcat I appreciate that dealing with axis to handle asyncronous responses is out of the scope of this list, but what about tomcat? Would much need to be changed to remove the assumption that everything has been done when servicing the servlet returns? I.e: If I can make my web-apps behave asyncronously, would a whole load need to be done within tomcat to support this? The container portion deals with the servlet API, which is synchronous (which is good, as it is a workable programming model). Adding additional async capabilities beyond the servlet API, such as IO events, is also possible, but here there will not be any events. I think the conclusion is that your requirements are outside the use cases for which the servlet API was designed for, so besides reusing portions of the code, most of your request processing cannot quite run inside the main servlet container. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Interactions with org.apache.coyote.Request/Response
Remy Maucherat wrote: I think the conclusion is that your requirements are outside the use cases for which the servlet API was designed for, so besides reusing portions of the code, most of your request processing cannot quite run inside the main servlet container. Yes - and after doing a bit more reading around the net, it seems that this is indeed the general consensus. It would appear that some great minds have spent some serious time trying to see how this model could work - and have decided that it just isn't going to. And Im not going to argue with them :o) Fortunately, it turns out that ditching tomcat for this particular use-case isn't such a bad thing. We just use the messaging model of axis (not RPC), so do much of the parsing ourselves. So, time to throw out the servlet API and Axis (proper) and have asyncronous request / response processing, re-using axis to convert the input stream to SOAP objects for us. I think that is going to be far easier to pull that off than what I was proposing before - which Im now beginning to appreciate was a bit crazy. Will still be using tomcat in other areas though - its superb. Dave This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
