Hello everyone, I'm trying to implement HttpAsyncResponseProducer using SharedOutputBuffer and found that I'm unable to control amount of concurrent response producers. Most probably, this problem comes from my incorrect understanding of HttpAsyncResponseProducer design. So, let me explain, how I'm solving this problem now and what problems I expect if I will use response producer.
Currently, in HttpAsyncRequestHandler<HttpRequest>.handle(), I create worker object, which will write content to PipedOutputStream, and push it into executor (mine implementation of Executor.execute() will block if there is no idle worker threads to process passed task). After Executor.execute() returns I call HttpAsyncExchange.submitResponse(BasicAsyncResponseProducer(response)) where response contains InputStreamEntity, which handles corresponding PipedInputStream. That's it, amount of concurrent HttpAsyncContentProducer objects is limited by executor queue. In case of HttpAsyncResponseProducer I'm using the following logic: 1. In HttpAsyncRequestHandler<HttpRequest>.handle() I'm submitting my implementation of HttpAsyncResponseProducer to HttpAsyncExchange.submitResponse(). 2. In HttpAsyncResponseProducer.produceContent() checks if it is a first call, and if so creates SharedOutputBuffer using passed IOControl and, using created buffer, creates new worker object and pass it to executor. 3. If this wasn't a first call to HttpAsyncResponseProducer.produceContent() then I simply call SharedOutputBuffer.produceContent() The problem is that all IOReactor worker threads can stuck in Executor.execute() and Executor worker threads will stuck on SharedOutputBuffer.write(), because all IOReactor worker threads waiting for their completion. There is another approach which can help avoid problem described above. Executor.execute() can reject task (by throwing an exception) if there is no idle workers. In case of exception HttpAsyncResponseProducer.produceContent() will do nothing and will try to create SharedOutputBuffer and task on the next HttpAsyncResponseProducer.produceContent() invocation. But in this case amount of response producers can grow limitless and cause OutOfMemoryException, so, this approach is not acceptable, too. Can somebody explain, which is a proper way to implement asynchronous handler, which content is being generated by separate thread? Unfortunately, I was unable to find any hints on this in source code. -- Thanks in advance, Dmitry --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
