Also, I believe that it should be consistent, I think Java fixed thread
pool factories will give you a thread pool that expire the threads after 1
minute being idle,
should be the same *-consistency-* for Akka?
On Monday, October 3, 2016 at 4:20:01 PM UTC+1, Guido Medina wrote:
>
> Look and learn about the configuration option:
>
>
> 1. thread-pool-executor.allow-core-timeout = off
>
> I suspect that what's happening is that your only thread is dying and
> another started when a new task is queued.
>
> HTH,
>
> Guido.
>
> On Friday, September 30, 2016 at 9:29:42 AM UTC+1, Marek Żebrowski wrote:
>>
>> I'm trying to understand how thread-pool-executor works.
>> In my config I have:
>> queue-ec {
>> type = Dispatcher
>> executor = "thread-pool-executor"
>> thread-pool-executor {
>> fixed-pool-size = 1
>> }
>> throughput = 1
>> }
>> and I have a piece of code that executes following loop - it basically is
>> a Future that calls itself on complete
>> def receive[T](n:Int):Future[T] = ...
>> implicit val ec =system.dispatchers.lookup("queue-ec")
>> def looper: Unit =
>> receive(queueSize) onComplete {
>> case Success(msgs) =>
>> val t = Thread.currentThread()
>> println(s"Looper thread ${t.getName}/${t.getId}/${t.hashCode()}")
>> looper
>> case Failure(failure) =>
>> looper
>> }
>> What I can see from logs is that each invocation of looper is executed on
>> another thread, whereas I would expect that all invocations are on the same
>> thread from "queue-ec" thread-pool-executor
>> logs:
>>
>> 10:10:36 [sgActors-queue-ec-52] INFO
>> m.s.g.SqsGroupsProcessingQueueConsumer: Looper thread
>> sgActors-queue-ec-52/134/2039717271
>> 10:10:46 [sgActors-queue-ec-57] INFO
>> m.s.g.SqsGroupsProcessingQueueConsumer: Looper thread
>> sgActors-queue-ec-57/142/1130275026
>> 10:10:57 [sgActors-queue-ec-61] INFO
>> m.s.g.SqsGroupsProcessingQueueConsumer: Looper thread
>> sgActors-queue-ec-61/153/1511413879
>> 10:11:07 [sgActors-queue-ec-63] INFO
>> m.s.g.SqsGroupsProcessingQueueConsumer: Looper thread
>> sgActors-queue-ec-63/158/6809925
>>
>> when I replace thread-pool-executor with
>> implicit val ec
>> = ExecutionContext.fromExecutor(Executors.newFixedThreadPool(1))
>> I have expected behavior of execution on the same thread in execution
>> context:
>>
>> 10:18:15 [pool-19-thread-1] INFO m.s.g.SqsGroupsProcessingQueueConsumer:
>> Looper thread pool-19-thread-1/133/4527812
>> 10:18:25 [pool-19-thread-1] INFO m.s.g.SqsGroupsProcessingQueueConsumer:
>> Looper thread pool-19-thread-1/133/4527812
>> 10:18:35 [pool-19-thread-1] INFO m.s.g.SqsGroupsProcessingQueueConsumer:
>> Looper thread pool-19-thread-1/133/4527812
>>
>>
>> So question is: is it possible to have a fixed threads behavior using
>> "thread-pool-executor" with fixed-pool-size parameter ? Some clarification
>> of
>> http://doc.akka.io/docs/akka/2.4/scala/dispatchers.html#More_dispatcher_configuration_examples
>>
>> would help
>> And more general question: is it a good practice to use Akka dispatchers
>> for pure scala Futures, or should I rather use separate ExecutionContext
>> for that purpose ?
>>
>>
--
>>>>>>>>>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
