Hi john,

AFAIU your question was not about existing code in akka-http but how to put 
a queue before a superpool, right? And no, putting a blocking queue inside 
of an Iterator is not likely the best solution because it will spend one 
thread permanently that is blocking in `queue.take` almost all the time. 
akka-http already provides `Http.singleRequest` which implements exactly 
what you are looking for so that should be your default entry point for 
running single requests. 

If this isn't enough (the best example IMO would be the need to provide 
custom queuing logic) akka-stream should provide a general facility that 
allows users to put a queue around one-to-one flows (with or without 
context).

Johannes

On Thursday, August 20, 2015 at 11:56:06 AM UTC+2, Konrad Malawski wrote:
>
> Hi John, 
> good observation, however this has not shown up in our initial 
> benchmarking as a bottle-neck so far AFAIR.
> We're taking a systematic aproach and first improving the perf of the 
> "biggest bang for the buck" elements of Akka Http.
> Currently this means we're focusing on fusing and need to implement fusing 
> of fan-in and fan-out stages, which will save a lot of actor creation 
> during request handling.
>
> From there we'll benchmark again and see what then becomes the bottleneck 
> :-)
>
> If you'd like to help out, we'd definitely welcome contributions (backed 
> with benchmarks in case of perf improvements).
>
> Thanks!
>
> On Sat, Aug 15, 2015 at 1:01 PM, <john....@gmail.com <javascript:>> wrote:
>
>> Is this source sound for a "flow" based on Http().superPool(...) :
>>
>> BlockingQueue<HttpRequest> queue = new LinkedBlockingQueue<>();
>>
>> Source< HttpRequest, ?> source = Source.fromIterator(() ->
>>       new Iterator<HttpRequest>() {
>>          public boolean hasNext() {return true;}
>>
>>          public HttpRequest next() {
>>             try {
>>                return queue.take();
>>             } catch (InterruptedException e) {}
>>             return null;
>>          }
>>  });
>>
>>
>> So many clients will be adding async many  HttpRequests to the single 
>> queue and the flow (based on Http().superPool(...)) should then process 
>> theses requests.
>>
>> I do think that using a concurrent LinkedBlockingQueue does scale. But 
>> is there an alternative?
>>
>>
>>
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com <javascript:>.
>> To post to this group, send email to akka...@googlegroups.com 
>> <javascript:>.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> Akka <http://akka.io/> @ Typesafe <http://typesafe.com/>
>

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to