Hi Asankha, > 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.
I am aware of that. I just mentioned the blocking client to let you know what keeps us busy at the moment. In other words: if you need a non-blocking client soon, feel free to help us out in developing it :-) > 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. I have started work on connections this week. Of course we'll start with a blocking pool. Oleg has some ideas about NIO pooling: http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200612.mbox/[EMAIL PROTECTED] >> 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? Actually I can't, because I don't know MINA. Oleg should be back from holidays later this week. The general idea was to avoid any assumptions about the transport being used in HttpCore. Of course the default connection implementations, both blocking and NIO, use plain sockets. But it is possible to develop other connection implementations, for example one using MINA. I guess. > 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. That's great. Please let us know about any shortcomings you identify, even if you should decide not to use HttpCore. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
