On Mon, 2012-07-02 at 15:18 +0200, Francesco Corazza wrote: > Hi, > I'm doing a cross protocol proxy to translate http to a custom protocol > (udp based). Therefore my architecture is composed by the http async server > on one side and the custom client on the other side. I have created a > custom HttpAsyncRequestHandler to manage the server's behavior. > To produce the request there are no problems because I haven't to manage > anything asynchronously; using the BasicAsyncRequestConsumer is enough for > my purposes. > > The problem is the opposite direction. To produce the http response the > proxy should wait the "completion" of the client process to get datagram > and translate it to a http response. In other words, the client is the > producer and the server is the consumer when creating an http response. > > My solution (actually a dirty workaround) was defining a subclass of > HttpAsyncResponseProducer to manage this asynchronous behavior. Each > instance of the custom HttpAsyncResponseProducer has a mutex to synchronize > this consumer thread (done in the method generateResponse) and to continue > iff the producer thread (client) has already dispatched the response. From > the client side, I created a map to dispatch the correct response to the > corresponding ResponseProducer instance. > > I don't like my solution because of the overhead created by > one-thread-per-request approach. Is there a smarter way to do this job > (i.e., exploiting some API that I have not recognized)? > > > Thank you all. > Best regards, > > > Francesco Corazza
Hi Francesco Do I understand it correctly that the outgoing service with the custom protocol is effectively synchronous and requires a dedicated worker thread to execute? Do you need to stream response content or can you afford buffering the entire message in memory? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
