[ http://issues.apache.org/jira/browse/AXIS2-296?page=comments#action_12358910 ]
Eran Chinthaka commented on AXIS2-296: -------------------------------------- I think we can not do the second point mentioned here. i.e. we CAN NOT send back 202 and immediately return. This will close the input and output streams, so we won't be able to do differed building anymore. According to the current implementation, the MR knows when to return, which is I think correct thing to do. I know this is problematic, but this is the opportunity cost for having differed building. > Async processing mapping to threads > ----------------------------------- > > Key: AXIS2-296 > URL: http://issues.apache.org/jira/browse/AXIS2-296 > Project: Apache Axis 2.0 (Axis2) > Type: Improvement > Components: core, client-api > Versions: 0.93 > Environment: All environments > Reporter: Paul Fremantle > > The current behaviour for threading is not optimal. > Firstly on the client side, when the user selects invokeNonBlocking, the > client should spawn the thread immediately rather than execute the outbound > request on the clients thread, since the outbound HTTP request may cause > unnecessary blocking. Also, because different transports have different > behaviour, the most appropriate approach is not to block even during the > outbound request. Possibly this could be an option > In the server case, the ideal behaviour for non-blocking is if the server > IMMEDIATELY returns 202 and spawns a thread to handle the request. At the > moment, as I understand it, all the incoming phase processing happen on the > transport thread and it is only when it finally gets to the receiver that it > spawns a new thread. > Ideally in both cases in fact we should not randomly spawn threads, but queue > work against a thread pool. For example, it would be really good if threads > in the pool were returned while the code was waiting on IO, but I know that > is difficult in a servlet model. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
