On Thu, 2007-01-04 at 09:57 +0530, Asankha C. Perera wrote: > Hi Roland > > Our focus is on a comfortable blocking > > API, since that is what most users want and also what we > > need in order to obsolete the 3.x version of HttpClient. > > However, if Synapse has good ideas about a comfortable > > non-blocking API which we could put on top of HttpCore, > > please let us know. > A non-blocking client API is important to Synapse, as we may act as a > client to many back-end servers, on behalf of our [actual] clients. > Since we run on top of Apache Axis2, it is a requirement to allow > reading from and writing into streams. For example, if we are reading a > huge Base 64 encoded message and sending it to another server as an MTOM > optimized SOAP message, we want to support this without reading the > whole message into our memory or waiting for the whole message to be > received from the client before we start sending it out. However, I > understand that in such scenarios, the application threads may block if > an internal read buffer runs dry waiting for data. > > This brings up another question, .. If I use HttpCore-NIO, and start > reading a SOAP message and as soon as I am done reading my SOAP header, > I start to process it, it is possible that your internal read buffer > gets filled up during this time. Once the read buffers are full, do you > reject available reads so that you could retry to read them in the > buffers again in your next select cycles? I am assuming that you do... >
Hi Asankha, Yes, we do. I have put a lot of efforts into trying to assure there can be no buffer overflow condition nether when consuming nor producing message content. > Synapse also wants SSL support in server and client mode, and we are ok > to move to JDK 1.5 to do this with NIO. > > Another optimization we would like to have is the ability for the client > API to be able to reuse underlying connections if possible - i.e. > something in the lines of a connection pool. In some preliminary > performance testing, opening a new socket for each message being sent to > a back-end causes us a huge cost. Not done yet, but certainly planned > > I don't know MINA myself, but Oleg does and he has taken > > care that HttpCore-NIO should be easy to run on top of > > MINA. > Could you explain this in a bit more detail? i.e. if we run HttpCore-NIO > on top of MINA I assume all calls made on the HttpCore-NIO APIs will > never block as MINA has already buffered the complete messages.. ? There are a couple of things I do not quite like about MINA, mainly related to its memory management. HttpCore NIO employs a different memory management strategy intended to ensure NIO connections can operate with a constant memory footprint and minimal intermediate garbage on the heap. Having said that, the plan is to put HttpCore protocol layer on top of MINA's transport layer at some point of time. > > That's why I recommend that you don't develop a > > new HTTP framework. Even if it might seem that you save > > some effort now by implementing a "good enough" solution, > > you will eventually run into the same kind of problems > > that we have seen with HttpClient over the years. > I see this point much more clearly than sometime back.. > > I am going to take the next couple of days to dive again into HttpCore, > Client and the NIO extensions in more detail, and would try to create a > basic transport for Synapse using them. We are planning to make a > decision on this in the next two weeks as we are getting ready for our > 1.0 soon after this is ready. > Admittedly HttpCore is a complex API, but it simply reflects the complexity of the problem domain. The goal was to provide a very flexible, low footprint, and memory efficient API. The idea is have HttpCore at the bottom of the component stack and provide a simpler facade API tailored for a specific use case (use cases) on top of it. This is what we are trying to achieve with HttpClient 4.0. So, please let me know if you need help with the API while hacking up the transport using HttpCore, I'll be happy to lend a helping hand. Cheers Oleg > thanks > asankha > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
