Re: [akka-user] Is ExecutionContext.reportFailure working?

[Viktor Klang]

Hi Sean,

On Tue, Jun 20, 2017 at 12:51 AM, Sean Shubin  wrote:

> While I was trying to stub out an execution context to test concurrent
> code, I noticed some surprising behavior demonstrated below.  I would have
> expected the exception thrown by the Future to cause reportFailure to be
> invoked.  To my surprise, reportFailure never got called at all, and the
> runnable.run() method carried on like nothing happened, even though an
> exception was thrown.  Obviously the code block run by the future is being
> wrapped by a runnable at some point, the surprising thing is that it seems
> to be handling the exception in a way that never notifies the reportFailure
> method.  I am having a hard time figuring it out from the source code, so
> was hoping someone more familiar with the scala.concurrent library could
> help me understand what is going on here.  My eventual goal is to be able
> to unit-test concurrent code by having tests take control of when different
> futures are launched and resolved.  That way I can resolve futures in
> different orders and make sure the code is correct no matter how the thread
> scheduler happens to fire off the futures.
>
> import java.util.concurrent.TimeUnit
>
> import org.scalatest.FunSuite
>
> import scala.concurrent.duration.Duration
> import scala.concurrent.{Await, ExecutionContext, Future}
>
> class PrototypeForStubbingExecutionContext extends FunSuite {
>   test("foo") {
> implicit val executionContext = new ExecutionContext {
>   override def execute(runnable: Runnable): Unit = {
> println("a")
> runnable.run()
> println("d")
>   }
>
>   override def reportFailure(cause: Throwable): Unit = {
> println("e")
> cause.printStackTrace()
> throw cause
>   }
> }
> val x = Future {
>   println("b")
>   throw new RuntimeException("boo!")
>   println("c")
> }(executionContext)
> Await.ready(x, Duration(1, TimeUnit.SECONDS))
> println(x)
>   }
> }
>

There are several issues with the code above,

1: `reportFailure` is only invoked if there is nowhere else to send the
exception, in the case of Future if it is possible to complete the end
result with the failure.

2: `reportFailure` should most definitely not throw exceptions, the only
reason it was invoked was that there was nowhere else to pass the original
exception, so rethrowing from it make little-to-no-sense at all.

3: Await.ready for logic executed on a synchronous EC seems superfluous?

You can see the `reportFailure` be invoked in for instance, `andThen`
throws an exception:

scala> Future(1).andThen({ case _ => throw null }).foreach(println)
java.lang.NullPointerException
at
$line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse(:18)
at
$line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse(:18)
at scala.concurrent.Future.$anonfun$andThen$1(Future.scala:531)
at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:29)
at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:29)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)
at
scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:140)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at
java.util.concurrent.ForkJoinPool$WorkQueue.pollAndExecAll(ForkJoinPool.java:1021)
at
java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(ForkJoinPool.java:1046)
at
java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1058)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at
java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
1


>
> Output
>
> a
> b
> d
> Future(Failure(java.lang.RuntimeException: boo!))
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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

Re: [akka-user] Is ExecutionContext.reportFailure working?

[Viktor Klang]

happy hakking!

On Tue, Jun 20, 2017 at 10:32 PM, Sean Shubin  wrote:

> Regarding #1, that is the information I was missing, thank you for
> clearing that up.  Hopefully that will guide me to how to test asynchronous
> code with an synchronous execution context.
>
> Regarding #2 and #3, I agree, I was just trying to figure out what was
> going on.  The reportFailure behavior was surprising to me, so I was
> guarding against other surprises.
>
> On Tuesday, June 20, 2017 at 1:01:09 AM UTC-7, √ wrote:
>>
>> Hi Sean,
>>
>> On Tue, Jun 20, 2017 at 12:51 AM, Sean Shubin  wrote:
>>
>>> While I was trying to stub out an execution context to test concurrent
>>> code, I noticed some surprising behavior demonstrated below.  I would have
>>> expected the exception thrown by the Future to cause reportFailure to be
>>> invoked.  To my surprise, reportFailure never got called at all, and the
>>> runnable.run() method carried on like nothing happened, even though an
>>> exception was thrown.  Obviously the code block run by the future is being
>>> wrapped by a runnable at some point, the surprising thing is that it seems
>>> to be handling the exception in a way that never notifies the reportFailure
>>> method.  I am having a hard time figuring it out from the source code, so
>>> was hoping someone more familiar with the scala.concurrent library could
>>> help me understand what is going on here.  My eventual goal is to be able
>>> to unit-test concurrent code by having tests take control of when different
>>> futures are launched and resolved.  That way I can resolve futures in
>>> different orders and make sure the code is correct no matter how the thread
>>> scheduler happens to fire off the futures.
>>>
>>> import java.util.concurrent.TimeUnit
>>>
>>> import org.scalatest.FunSuite
>>>
>>> import scala.concurrent.duration.Duration
>>> import scala.concurrent.{Await, ExecutionContext, Future}
>>>
>>> class PrototypeForStubbingExecutionContext extends FunSuite {
>>>   test("foo") {
>>> implicit val executionContext = new ExecutionContext {
>>>   override def execute(runnable: Runnable): Unit = {
>>> println("a")
>>> runnable.run()
>>> println("d")
>>>   }
>>>
>>>   override def reportFailure(cause: Throwable): Unit = {
>>> println("e")
>>> cause.printStackTrace()
>>> throw cause
>>>   }
>>> }
>>> val x = Future {
>>>   println("b")
>>>   throw new RuntimeException("boo!")
>>>   println("c")
>>> }(executionContext)
>>> Await.ready(x, Duration(1, TimeUnit.SECONDS))
>>> println(x)
>>>   }
>>> }
>>>
>>
>> There are several issues with the code above,
>>
>> 1: `reportFailure` is only invoked if there is nowhere else to send the
>> exception, in the case of Future if it is possible to complete the end
>> result with the failure.
>>
>> 2: `reportFailure` should most definitely not throw exceptions, the only
>> reason it was invoked was that there was nowhere else to pass the original
>> exception, so rethrowing from it make little-to-no-sense at all.
>>
>> 3: Await.ready for logic executed on a synchronous EC seems superfluous?
>>
>> You can see the `reportFailure` be invoked in for instance, `andThen`
>> throws an exception:
>>
>> scala> Future(1).andThen({ case _ => throw null }).foreach(println)
>> java.lang.NullPointerException
>> at $line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse
>> (:18)
>> at $line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse
>> (:18)
>> at scala.concurrent.Future.$anonfun$andThen$1(Future.scala:531)
>> at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:29)
>> at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:29)
>> at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)
>> at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTa
>> sk.exec(ExecutionContextImpl.scala:140)
>> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>> at java.util.concurrent.ForkJoinPool$WorkQueue.pollAndExecAll(
>> ForkJoinPool.java:1021)
>> at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(
>> ForkJoinPool.java:1046)
>> at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(
>> ForkJoinPool.java:1058)
>> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
>> at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorker
>> Thread.java:157)
>> 1
>>
>>
>>>
>>> Output
>>>
>>> a
>>> b
>>> d
>>> Future(Failure(java.lang.RuntimeException: boo!))
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To u

Re: [akka-user] remoting comparison: Artery vs Netty

[Viktor Klang]

Likely bottlenecked either by network or serialization method (or quite
possibly both?).

-- 
Cheers,
√

On Jul 3, 2017 1:06 PM, "Patrik Nordwall"  wrote:

> What is the unit of the values in the table, e.g. 416? I guess it's
> milliseconds?
>
> That doesn't match our tests
> 
> at all. We have measured 800k msg/s for the 100 byte payload.
>
> I'd recommend that you use something bigger than micro instances.
> Corresponding to 4 cores at least. I don't know how much the far apart
> regions matters, we have only tried in same zone.
>
> On Mon, Jul 3, 2017 at 11:42 AM, 'Kostiantyn Gorustovych' via Akka User
> List  wrote:
>
>> Hi guys. We are migrating our application from akka 2.4 to 2.5 and among
>> other there is new remoting available.
>> The throughput Before switching from netty to artery we decided to
>> compare them.
>>
>> So I created the app with two modules: sender & receiver with 16 remote
>> actors spawned by sender on receiver side.
>> The finished transmission is that one in which the payload delivered to
>> receiver and message id returned to sender.
>>
>> The tests implemented as a series of messaging batches. Each batch
>> consisted of 1000 message transmissions of K bytes (per message).
>> I tested it with messages of 100 byte, 1000 byte, 1 byte with
>> different idle-cpu-level.
>> With 100 byte message the artery's throughput looks better than netty's
>> (up to 26%), but for the rest it seems that netty beat artery (40% for 1k
>> message and 60% for 10k message).
>>
>> Some info about test execution:
>> - warm up the system with 50 batches of 100 bytes messages;
>> - measure the average for 100 batches of 100 bytes messages;
>> - measure the average for 50 batches of 1000 bytes messages;
>> - measure the average for 115 batches of 1 bytes messages;
>>
>> I tested it on AWS micro instances in different regions.
>>
>> Is it expected results?
>>
>> idle-cpu-level is represented as Artery X, e.g. Artery 1
>> AWS micro instances (singapore ↔ frankfurt)
>> messages / bytes per message Artery 1 Artery 3 Artery 5 Artery 7 Artery 9 
>> Artery
>> 10 Netty
>> 1k / 100 441 400 416 445 466 969 543
>> 1k / 1k 1655 1671 1674 1790 1755 3728 1217
>> 1k / 10k 14005 15237 19142 19463 20833 37539 8565
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Cool! What kind of scalability&performance profile are you getting?

On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:

> Hi,
>
> We are developing an AMQP messaging broker - ChanaMQ, which is based on
> Akka actors and Akka streaming.
>
> It's currently under Alpha phase, but with lots of AMQP 0-9-1 features
> implemented, including ack, persistent (Cassandra only so far) etc.
>
> Methods/Features are not supported yet:
>
>- Connection.SecureOk
>- Channel.Flow
>- Exchange.Bind / Exchange.Unbind
>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>- Access.Request
>- Tx.Select / Tx.Commit / Tx.Rollback
>- Confirm.Select
>- ...
>
> For more information, please visit:
>
> https://github.com/qingmang-team/chanamq
>
> Regards,
>
> Caoyuan Deng
> Qingmang  - Your magazine on mobile
> Twitter: @dcaoyuan
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Cool. What does the p90 and p99 look like?

-- 
Cheers,
√

On Jul 25, 2017 12:19 AM, "Caoyuan"  wrote:

> I've got some preliminary benchmarks. As the maximized distributed design
> of ChanaMQ. It's bit lagging behind RabbitMQ when applying a few
> publishers/consumers, but will be on par with RabbitMQ when applying lots
> of publishers/consumers.
>
> Attached are benchmarks on my dual Intel Xeon E5620@2.4GHz
>
> ChanaMQ is designed as a plain Akka sharding cluster, so it should scale
> out well, although I do not yet take a serious test on it.
>
> --
> Cheers
> Caoyuan Deng
>
> On Monday, July 24, 2017 at 12:36:27 AM UTC-7, √ wrote:
>>
>> Cool! What kind of scalability&performance profile are you getting?
>>
>> On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:
>>
>>> Hi,
>>>
>>> We are developing an AMQP messaging broker - ChanaMQ, which is based on
>>> Akka actors and Akka streaming.
>>>
>>> It's currently under Alpha phase, but with lots of AMQP 0-9-1 features
>>> implemented, including ack, persistent (Cassandra only so far) etc.
>>>
>>> Methods/Features are not supported yet:
>>>
>>>- Connection.SecureOk
>>>- Channel.Flow
>>>- Exchange.Bind / Exchange.Unbind
>>>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>>>- Access.Request
>>>- Tx.Select / Tx.Commit / Tx.Rollback
>>>- Confirm.Select
>>>- ...
>>>
>>> For more information, please visit:
>>>
>>> https://github.com/qingmang-team/chanamq
>>>
>>> Regards,
>>>
>>> Caoyuan Deng
>>> Qingmang  - Your magazine on mobile
>>> Twitter: @dcaoyuan
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Very consistent. What's the current bottleneck?

On Thu, Jul 27, 2017 at 7:52 PM, Caoyuan  wrote:

> Below is the latency in ms when applying 1-publishers - 100-consumers:
>
>
>   "max-latency":15.044784,
>   "min-latency":13.960142,
>   "avg-latency":14.623772,
>   "p95-latency":14.830327,
>   "p99-latency":14.884950,
>
> On Monday, July 24, 2017 at 11:30:04 PM UTC-7, √ wrote:
>>
>> Cool. What does the p90 and p99 look like?
>>
>> --
>> Cheers,
>> √
>>
>> On Jul 25, 2017 12:19 AM, "Caoyuan"  wrote:
>>
>>> I've got some preliminary benchmarks. As the maximized distributed
>>> design of ChanaMQ. It's bit lagging behind RabbitMQ when applying a few
>>> publishers/consumers, but will be on par with RabbitMQ when applying lots
>>> of publishers/consumers.
>>>
>>> Attached are benchmarks on my dual Intel Xeon E5620@2.4GHz
>>>
>>> ChanaMQ is designed as a plain Akka sharding cluster, so it should scale
>>> out well, although I do not yet take a serious test on it.
>>>
>>> --
>>> Cheers
>>> Caoyuan Deng
>>>
>>> On Monday, July 24, 2017 at 12:36:27 AM UTC-7, √ wrote:

 Cool! What kind of scalability&performance profile are you getting?

 On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:

> Hi,
>
> We are developing an AMQP messaging broker - ChanaMQ, which is based
> on Akka actors and Akka streaming.
>
> It's currently under Alpha phase, but with lots of AMQP 0-9-1 features
> implemented, including ack, persistent (Cassandra only so far) etc.
>
> Methods/Features are not supported yet:
>
>- Connection.SecureOk
>- Channel.Flow
>- Exchange.Bind / Exchange.Unbind
>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>- Access.Request
>- Tx.Select / Tx.Commit / Tx.Rollback
>- Confirm.Select
>- ...
>
> For more information, please visit:
>
> https://github.com/qingmang-team/chanamq
>
> Regards,
>
> Caoyuan Deng
> Qingmang  - Your magazine on mobile
> Twitter: @dcaoyuan
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/additional/faq.html
> >> Search the archives: https://groups.google.com/grou
> p/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.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Cheers,
 √

>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Would be interesting to see if the new AffinityPool would make any
difference.

On Thu, Jul 27, 2017 at 10:44 PM, Caoyuan  wrote:

>
>
> On Thursday, July 27, 2017 at 12:47:39 PM UTC-7, √ wrote:
>>
>> Very consistent. What's the current bottleneck?
>>
>
> Not too much so far. The major decision of ChanaMQ design is that each
> message is an actor and each queue is an actor etc. So the scalability on
> number of CPU cores or cluster nodes should be well. I can see the CPU
> cores usages are balanced very well.
>
> The only issue is the fluctuated of send/receive rate under some cases,
> I'll try to figure out whether the cause is from client side or ChanaMQ
> server side.
>
>
>
>> On Thu, Jul 27, 2017 at 7:52 PM, Caoyuan  wrote:
>>
>>> Below is the latency in ms when applying 1-publishers - 100-consumers:
>>>
>>>
>>>   "max-latency":15.044784,
>>>   "min-latency":13.960142,
>>>   "avg-latency":14.623772,
>>>   "p95-latency":14.830327,
>>>   "p99-latency":14.884950,
>>>
>>> On Monday, July 24, 2017 at 11:30:04 PM UTC-7, √ wrote:

 Cool. What does the p90 and p99 look like?

 --
 Cheers,
 √

 On Jul 25, 2017 12:19 AM, "Caoyuan"  wrote:

> I've got some preliminary benchmarks. As the maximized distributed
> design of ChanaMQ. It's bit lagging behind RabbitMQ when applying a few
> publishers/consumers, but will be on par with RabbitMQ when applying lots
> of publishers/consumers.
>
> Attached are benchmarks on my dual Intel Xeon E5620@2.4GHz
>
> ChanaMQ is designed as a plain Akka sharding cluster, so it should
> scale out well, although I do not yet take a serious test on it.
>
> --
> Cheers
> Caoyuan Deng
>
> On Monday, July 24, 2017 at 12:36:27 AM UTC-7, √ wrote:
>>
>> Cool! What kind of scalability&performance profile are you getting?
>>
>> On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:
>>
>>> Hi,
>>>
>>> We are developing an AMQP messaging broker - ChanaMQ, which is based
>>> on Akka actors and Akka streaming.
>>>
>>> It's currently under Alpha phase, but with lots of AMQP 0-9-1
>>> features implemented, including ack, persistent (Cassandra only so far) 
>>> etc.
>>>
>>> Methods/Features are not supported yet:
>>>
>>>- Connection.SecureOk
>>>- Channel.Flow
>>>- Exchange.Bind / Exchange.Unbind
>>>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>>>- Access.Request
>>>- Tx.Select / Tx.Commit / Tx.Rollback
>>>- Confirm.Select
>>>- ...
>>>
>>> For more information, please visit:
>>>
>>> https://github.com/qingmang-team/chanamq
>>>
>>> Regards,
>>>
>>> Caoyuan Deng
>>> Qingmang  - Your magazine on mobile
>>> Twitter: @dcaoyuan
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/additional/faq.html
> >> Search the archives: https://groups.google.com/grou
> p/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.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.

Re: [akka-user] problem with pinned dispatcher

[Viktor Klang]

«Note that it’s not guaranteed that the *same* thread is used over time,
since the core pool timeout is used for PinnedDispatcher to keep resource
usage down in case of idle actors. To use the same thread all the time you
need to add thread-pool-executor.allow-core-timeout=off to the
configuration of the PinnedDispatcher.»

http://doc.akka.io/docs/akka/current/scala/dispatchers.html#types-of-dispatchers


On Tue, Aug 1, 2017 at 5:04 PM, mc  wrote:

> Hello,
>
> I'm trying to use PinnedDispatcher using the following configuration (in
> application.conf):
>
> app {
> pinnedDispatcher {
> type = "PinnedDispatcher"
> executor = "thread-pool-executor"
> thread-pool-executor.allow-
> core-timeout = off
> thread-pool-executor {
> core-pool-size-min = 2
> core-pool-size-factor = 2.0
> core-pool-size-max = 4
> }
> throughput = 1
> }
> }
>
> akka.actor.deployment {
> /master/worker {
> dispatcher = app.pinnedDispatcher
> router = round-robin-pool
> }
> }
>
> This is my code for creating worker pool (inside MyMaster actor called
> "master"):
>   private lazy val worker = context.actorOf(FromConfig.props(Props[MyWorker]),
> "worker")
>
> Worker actors are receiving messages but it looks like actors created on
> one thread are later executed on another thread.
> Is my configuration incorrect? I thought that using pinned dispatcher
> would guarantee that an actor created on a thread would later be always
> called from that same thread.
> I'd appreciate any help with this problem.
> Thanks,
>
> M
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Using zip with mapAsyncUnordered

[Viktor Klang]

 Hi Ori,

The answer is: it is allowed for the materializer, dispatcher, JVM, OS
Scheduler to allow for elements produced by the mapAsyncUnordered to be
reordered—it doesn't mean that they will sometimes, will always, will
never, etc.

If you don't want possible reordering, use mapAsync.

Cheers,
√

On Sat, 26 Aug 2017 at 17:11, Ori Popowski  wrote:

>
> Hi,
>
> Say that I have a stream with a consecutive integers source (1, 2, 3 ...),
> and assume that toString returns a Future[String]:
>
> source ~> bcast ~> toString.mapAsyncUnordered(8)(identity) ~> zip.in0
>   bcast ~>zip.in1
>   zip.out ~>
> sink
>
> My question is if mapAsyncUnordered will cause a shuffling, or will every
> integer will be paired with its own toString representation?
>
> Will the result be this:
>
> "1" -> 1
> "2" -> 2
> "3" -> 3
> ...
>
>
>
> or more like this:
>
> "1" -> 7
> "2" -> 1
> "3" -> 3
> ...
>
>
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Ask not working if Future is used in receive partial method

[Viktor Klang]

Hi Danny,

there are two problems:

1)
https://doc.akka.io/docs/akka/current/scala/additional/faq.html#sender-getsender-disappears-when-i-use-future-in-my-actor-why-

2)
https://doc.akka.io/docs/akka/current/scala/general/jmm.html#jmm-shared-state

Happy hakking!


On Fri, Oct 13, 2017 at 6:59 PM, Danny Lesnik 
wrote:

> I have the following stateful Actor
>
> class StudentActor extends Actor with ActorLogging{
>
>   var student:Student = Student(id,firstName,lastName)
>
>   implicit val executionContext = Try {
> context.system.dispatchers.lookup("blocking-code-dispatcher")
>   }.getOrElse(context.system.dispatcher)
>
>
>   override def receive = {
>
> case UpdateStudent(_, c) =>
>   Future[Student] {
>
> val updatedStudent = student.copy(counter = student.counter + c)
> student = updatedStudent
> log.info(sender().toString())
> updatedStudent
>   }(executionContext).map(updatedStudent => sender() ! updatedStudent)
>
> case GetStudent(id,_) => sender() ! student
>
>   }
> }
>
>
>
> When I try to use ask pattern to update this student from main method, I'm 
> receiving timeout
>
>
> holder.ask(UpdateStudent("1")).mapTo[Student].foreach(println(_))
>
>
> However, if I remove Future method and using the following code it works like 
> charm:
>
>
>   case UpdateStudent(_, c) =>val updatedStudent = 
> student.copy(counter = student.counter + c)
>
> student = updatedStudent
> log.info(sender().toString())
> updatedStudent
>
> sender() ! updatedStudent
>
>
> Why using Future in partial method causes ask timeout?
>
> I believe this is something stupid, but I can't figure it out :)
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Viktor Klang]

What definition of latency are you using? (i.e. how is it derived)

On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf  wrote:

> Hi Konrad,
>
> Our real issue is that we can not reproduce the results.  The web server
> we are having latency issues with is under peak load of 10-15
> requests/second - obviously not much to deal with.
>
> When we use load tests (https://github.com/apigee/apib), it's easy for us
> to throw a few thousand requests/second at it and get latencies in the ~ 3
> ms range.  We use kamon to track internal metrics - what we see is that our
> 95th and 99th percentiles only look bad under the production traffic but
> not under load tests.
>
> I've since used kamon to print out the actual requests trying to find any
> pattern in them to hint at what's wrong in my own code, but they seem to be
> completely random.  What we do know is that downgrading to spray gets us
> 99.9th percentile latencies under 2ms, so something related to the upgrade
> is allowing this.
>
> Thanks,
>
> Gary
>
> On Tuesday, October 17, 2017 at 12:07:51 PM UTC-4, Konrad Malawski wrote:
>>
>> Step 1 – don’t panic ;-)
>> Step 2 – as I already asked for, please share actual details of the
>> benchmarks. It is not good to discuss benchmarks without any insight into
>> what / how exactly you’re measuring.
>>
>> --
>> Cheers,
>> Konrad 'ktoso ' Malawski
>> Akka  @ Lightbend 
>>
>> On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com) wrote:
>>
>> We have a web service that we just finished migrating from spray 1.3 to
>> Akka-Http 10.0.9.  While in most cases it is performing well, we are seeing
>> terrible 99th percentile latencies 300-450ms range) starting from a very
>> low request rate (10/second) on an ec2 m3.large.
>>
>> Our service does not do anything complicated - it does a few Map lookups
>> and returns a response to a request.  In spray, even 99th percentile
>> latencies were on the order of 1-3 ms, so we are definitely concerned.
>> Connections as with many pixel-type servers are short-lived -> we actually
>> pass the Connection: Close header intentionally in our responses.
>>
>> Is there any obvious tuning that should be done on the server
>> configuration that others have found?
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Viktor Klang]

No, I mean, is it from first-byte-received to last-byte-sent or what?

On Mon, Oct 23, 2017 at 10:22 PM, Gary Malouf  wrote:

> We are using percentiles computed via Kamon 0.6.8.  In a very low request
> rate environment like this, it takes roughly 1 super slow request/second to
> throw off the percentiles (which is what I think is happening).
>
>
>
> On Mon, Oct 23, 2017 at 4:20 PM, Viktor Klang 
> wrote:
>
>> What definition of latency are you using? (i.e. how is it derived)
>>
>> On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf 
>> wrote:
>>
>>> Hi Konrad,
>>>
>>> Our real issue is that we can not reproduce the results.  The web server
>>> we are having latency issues with is under peak load of 10-15
>>> requests/second - obviously not much to deal with.
>>>
>>> When we use load tests (https://github.com/apigee/apib), it's easy for
>>> us to throw a few thousand requests/second at it and get latencies in the ~
>>> 3 ms range.  We use kamon to track internal metrics - what we see is that
>>> our 95th and 99th percentiles only look bad under the production traffic
>>> but not under load tests.
>>>
>>> I've since used kamon to print out the actual requests trying to find
>>> any pattern in them to hint at what's wrong in my own code, but they seem
>>> to be completely random.  What we do know is that downgrading to spray gets
>>> us 99.9th percentile latencies under 2ms, so something related to the
>>> upgrade is allowing this.
>>>
>>> Thanks,
>>>
>>> Gary
>>>
>>> On Tuesday, October 17, 2017 at 12:07:51 PM UTC-4, Konrad Malawski wrote:
>>>>
>>>> Step 1 – don’t panic ;-)
>>>> Step 2 – as I already asked for, please share actual details of the
>>>> benchmarks. It is not good to discuss benchmarks without any insight into
>>>> what / how exactly you’re measuring.
>>>>
>>>> --
>>>> Cheers,
>>>> Konrad 'ktoso <http://kto.so>' Malawski
>>>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>>>
>>>> On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com)
>>>> wrote:
>>>>
>>>> We have a web service that we just finished migrating from spray 1.3 to
>>>> Akka-Http 10.0.9.  While in most cases it is performing well, we are seeing
>>>> terrible 99th percentile latencies 300-450ms range) starting from a very
>>>> low request rate (10/second) on an ec2 m3.large.
>>>>
>>>> Our service does not do anything complicated - it does a few Map
>>>> lookups and returns a response to a request.  In spray, even 99th
>>>> percentile latencies were on the order of 1-3 ms, so we are definitely
>>>> concerned.  Connections as with many pixel-type servers are short-lived ->
>>>> we actually pass the Connection: Close header intentionally in our
>>>> responses.
>>>>
>>>> Is there any obvious tuning that should be done on the server
>>>> configuration that others have found?
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>>> urrent/additional/faq.html
>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>>> p/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.
>>>> To post to this group, send email to akka...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Viktor Klang]

And you consume the entityBytes I presume?

On Mon, Oct 23, 2017 at 10:35 PM, Gary Malouf  wrote:

> It is from when I start the Kamon trace (just inside of my
> path("myawesomepath") declaration until (theoretically) a 'complete' call
> is made.
>
> path("myawesomepath") {
>   traceName("CoolStory") {
> ///do some stuff
>  complete("This is great")
> } }
>
> For what it's worth, this route is a 'POST' call.
>
> On Mon, Oct 23, 2017 at 4:30 PM, Viktor Klang 
> wrote:
>
>> No, I mean, is it from first-byte-received to last-byte-sent or what?
>>
>> On Mon, Oct 23, 2017 at 10:22 PM, Gary Malouf 
>> wrote:
>>
>>> We are using percentiles computed via Kamon 0.6.8.  In a very low
>>> request rate environment like this, it takes roughly 1 super slow
>>> request/second to throw off the percentiles (which is what I think is
>>> happening).
>>>
>>>
>>>
>>> On Mon, Oct 23, 2017 at 4:20 PM, Viktor Klang 
>>> wrote:
>>>
>>>> What definition of latency are you using? (i.e. how is it derived)
>>>>
>>>> On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf 
>>>> wrote:
>>>>
>>>>> Hi Konrad,
>>>>>
>>>>> Our real issue is that we can not reproduce the results.  The web
>>>>> server we are having latency issues with is under peak load of 10-15
>>>>> requests/second - obviously not much to deal with.
>>>>>
>>>>> When we use load tests (https://github.com/apigee/apib), it's easy
>>>>> for us to throw a few thousand requests/second at it and get latencies in
>>>>> the ~ 3 ms range.  We use kamon to track internal metrics - what we see is
>>>>> that our 95th and 99th percentiles only look bad under the production
>>>>> traffic but not under load tests.
>>>>>
>>>>> I've since used kamon to print out the actual requests trying to find
>>>>> any pattern in them to hint at what's wrong in my own code, but they seem
>>>>> to be completely random.  What we do know is that downgrading to spray 
>>>>> gets
>>>>> us 99.9th percentile latencies under 2ms, so something related to the
>>>>> upgrade is allowing this.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gary
>>>>>
>>>>> On Tuesday, October 17, 2017 at 12:07:51 PM UTC-4, Konrad Malawski
>>>>> wrote:
>>>>>>
>>>>>> Step 1 – don’t panic ;-)
>>>>>> Step 2 – as I already asked for, please share actual details of the
>>>>>> benchmarks. It is not good to discuss benchmarks without any insight into
>>>>>> what / how exactly you’re measuring.
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Konrad 'ktoso <http://kto.so>' Malawski
>>>>>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>>>>>
>>>>>> On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com)
>>>>>> wrote:
>>>>>>
>>>>>> We have a web service that we just finished migrating from spray 1.3
>>>>>> to Akka-Http 10.0.9.  While in most cases it is performing well, we are
>>>>>> seeing terrible 99th percentile latencies 300-450ms range) starting from 
>>>>>> a
>>>>>> very low request rate (10/second) on an ec2 m3.large.
>>>>>>
>>>>>> Our service does not do anything complicated - it does a few Map
>>>>>> lookups and returns a response to a request.  In spray, even 99th
>>>>>> percentile latencies were on the order of 1-3 ms, so we are definitely
>>>>>> concerned.  Connections as with many pixel-type servers are short-lived 
>>>>>> ->
>>>>>> we actually pass the Connection: Close header intentionally in our
>>>>>> responses.
>>>>>>
>>>>>> Is there any obvious tuning that should be done on the server
>>>>>> configuration that others have found?
>>>>>> --
>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>>>>> urrent/additional/

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

[Viktor Klang]

Does it behave differently from
`Source.single(somePromise.future).mapAsync(1)(identity)` ?

On Wed, Oct 25, 2017 at 12:01 PM, Christopher Hunt 
wrote:

> Hey community,
>
> I've got a situation where there's a promise that, when completed, I'd
> like to concat its value onto the *end* of any stream elements before it
> i.e.:
>
> someSource.concat(Source.fromFuture(somePromise.future))
>
> What I'm noticing is that if the promise is completed then the promised
> value doesn't wait for someSource to complete. Rather, it yields an element
> near to the time that the promise was completed, seemingly ignoring any
> further elements from someSource.
>
> This problem appears to be similar to https://github.com/akka/
> akka/issues/22042, where flatMapConcat is recommended. However, I'm not
> sure that flatMapConcat as its contract appears to be different - I only
> want to concat elements when someSource is complete. flatMapConcat appears
> to get called for each element from someSource.
>
> Any further pointers in order to achieve the API description of concat in
> conjunction with Source.fromFuture?
>
> Cheers,
> -C
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

[Viktor Klang]

On Wed, Oct 25, 2017 at 1:16 PM, Christopher Hunt  wrote:

>
>
> > On 25 Oct 2017, at 21:05, Viktor Klang  wrote:
> >
> > Does it behave differently from 
> > `Source.single(somePromise.future).mapAsync(1)(identity)`
> ?
>
> Interesting idea. Thanks Viktor. I’ll try it in the morning.
>
> It feels a little odd to look at though...
>

Sure, I'm asking if it behaves differently because AFAICT they shouldn't.
So if the alternate encoding fixes it, then it's pretty simple to
utility-fy it until the inconsistency is fixed.


>
> --
> >>>>>>>>>>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Usage of StreamConverters.asOutputStream / possible alternative API?

[Viktor Klang]

Be careful though, as you need to ensure proper happens-before relationship
between the writes and the closing of the OutputStream. (and other writes
of course)

On Thu, Oct 26, 2017 at 1:56 PM, Rafał Krzewski 
wrote:

> That worked like a charm :) Thanks a lot Johan!
>
> Cheers,
> Rafał
>
> W dniu czwartek, 26 października 2017 10:49:52 UTC+2 użytkownik Johan
> Andrén napisał:
>>
>> Materialization is not async, so anything you do in mapMaterializedValue
>> will block the materialization. Simplest solution is to not run the logic
>> that feeds the OutputStream inside the materialization, but instead do that
>> by keeping the materialized value through your chain of stages, and getting
>> it as the returned value from run(). In some cases, maybe yours, you cannot
>> do that because you are passing the blueprint to some API that will do the
>> actual materialization, in that case you can instead fork off a
>> future/thread to do the writing, to let the materialization complete.
>>
>> Something like this:
>>
>>   def legacySource =
>> StreamConverters.asOutputStream()
>>   .mapMaterializedValue { outputstream =>
>> Future {
>>   while(something) {
>> outputstream.write(data)
>>   }
>> }(use-a-blocking-specific-dispatcher-here-as-write-is-blocking)
>> NotUsed
>>   }
>>
>>   val route = get {
>> complete {
>>   HttpEntity(
>> ContentTypes.`application/octet-stream`,
>> legacySource
>>   )
>> }
>>   }
>>
>> --
>> Johan
>> Akka Team
>>
>> On Wednesday, October 25, 2017 at 1:42:58 PM UTC+2, Rafał Krzewski wrote:
>>>
>>> Hi,
>>>
>>> I've tried using `StreamConverters.asOutputStream` and immediately run
>>> into the deadlock described in the documentation [1]
>>>
>>> My use case is that I am am creating Excel spreadsheet using Apache
>>> POI's streaming API [2] and then stream out the result using Akka HTTP.
>>>
>>> Under the hood POI is writing the row data into a temporary files on
>>> disk. When all data is ready, one can write out the result to an arbitrary
>>> `OutputStream` [3].
>>>
>>> When interoperating with Akka HTTP I need to provide a `Source` that is
>>> materialized by the framework. That's why my intuition was using
>>> `mapMaterializedValue` to provide the code making use of the `OutputStream`
>>> at the site when I'm creating the source. Unfortunately this does not work.
>>> I was able to work around that by writing out the spreadsheet to another
>>> temporary file, providing a `Source` to Akka HTTP side using `FileIO` and
>>> some additional song and dance to clean up the temporary files in all
>>> circumstances.
>>>
>>>
>>> I am wondering if there is a way I could use
>>> `StreamConverters.asOutputStream` correctly in this scenario that I
>>> don't see? Or maybe another kind of API would be necessary here? I'm
>>> thinking about something along the lines of:
>>>
>>>
>>> `asOutputStream(f: OutputStream => Done, writeTimeout: FiniteDuration =
>>> 5.seconds): Source[ByteString, Future[IOResult]]`
>>>
>>>
>>> `f` would be invoked after the stream is ready for writing. After `f`
>>> completes, the framework could ensure the stream is cleaned up properly.
>>> The returned `IOResult.status` could be used to check whether `f` completed
>>> normally. If `f` fails to complete within specified timeout, any further
>>> attempt to call methods on the `OutputStream` should result in an
>>> `IOException`. The problem I see is that `f` could get permanently blocked
>>> on some condition and thus steal a thread from
>>> `akka.stream.blocking-io-dispatcher` but I don't think there is any way
>>> to handled that on the JVM.
>>>
>>>
>>> I am not sure if the above is feasible but if it were I'm sure people
>>> would find it useful for interfacing with legacy code ;)
>>>
>>>
>>> Cheers,
>>>
>>> Rafał
>>>
>>>
>>> [1] https://doc.akka.io/docs/akka/current/scala/stream/stages-ov
>>> erview.html#additional-sink-and-source-converters
>>>
>>> [2] https://poi.apache.org/spreadsheet/how-to.html#sxssf
>>>
>>> [3] https://poi.apache.org/apidocs/org/apache/poi/xssf/streaming
>>> /SXSSFWorkbook.html#write-java.io.OutputStream-
>>>
>> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.h

Re: [akka-user] Re: Usage of StreamConverters.asOutputStream / possible alternative API?

[Viktor Klang]

Yup

On Thu, Oct 26, 2017 at 3:51 PM, Rafał Krzewski 
wrote:

> Hi Viktor,
>
> I'm passing the OutputStream to a single method that does a bunch of
> writes synchronously and as soon as it returns I do os.close() so I should
> be good, no?
>
> Cheers,
> Rafał
>
> W dniu czwartek, 26 października 2017 14:02:32 UTC+2 użytkownik √ napisał:
>>
>> Be careful though, as you need to ensure proper happens-before
>> relationship between the writes and the closing of the OutputStream. (and
>> other writes of course)
>>
>> On Thu, Oct 26, 2017 at 1:56 PM, Rafał Krzewski 
>> wrote:
>>
>>> That worked like a charm :) Thanks a lot Johan!
>>>
>>> Cheers,
>>> Rafał
>>>
>>> W dniu czwartek, 26 października 2017 10:49:52 UTC+2 użytkownik Johan
>>> Andrén napisał:

 Materialization is not async, so anything you do in
 mapMaterializedValue will block the materialization. Simplest solution is
 to not run the logic that feeds the OutputStream inside the
 materialization, but instead do that by keeping the materialized value
 through your chain of stages, and getting it as the returned value from
 run(). In some cases, maybe yours, you cannot do that because you are
 passing the blueprint to some API that will do the actual materialization,
 in that case you can instead fork off a future/thread to do the writing, to
 let the materialization complete.

 Something like this:

   def legacySource =
 StreamConverters.asOutputStream()
   .mapMaterializedValue { outputstream =>
 Future {
   while(something) {
 outputstream.write(data)
   }
 }(use-a-blocking-specific-dispatcher-here-as-write-is-blocking)
 NotUsed
   }

   val route = get {
 complete {
   HttpEntity(
 ContentTypes.`application/octet-stream`,
 legacySource
   )
 }
   }

 --
 Johan
 Akka Team

 On Wednesday, October 25, 2017 at 1:42:58 PM UTC+2, Rafał Krzewski
 wrote:
>
> Hi,
>
> I've tried using `StreamConverters.asOutputStream` and immediately
> run into the deadlock described in the documentation [1]
>
> My use case is that I am am creating Excel spreadsheet using Apache
> POI's streaming API [2] and then stream out the result using Akka HTTP.
>
> Under the hood POI is writing the row data into a temporary files on
> disk. When all data is ready, one can write out the result to an arbitrary
> `OutputStream` [3].
>
> When interoperating with Akka HTTP I need to provide a `Source` that
> is materialized by the framework. That's why my intuition was using
> `mapMaterializedValue` to provide the code making use of the 
> `OutputStream`
> at the site when I'm creating the source. Unfortunately this does not 
> work.
> I was able to work around that by writing out the spreadsheet to another
> temporary file, providing a `Source` to Akka HTTP side using `FileIO` and
> some additional song and dance to clean up the temporary files in all
> circumstances.
>
>
> I am wondering if there is a way I could use
> `StreamConverters.asOutputStream` correctly in this scenario that I
> don't see? Or maybe another kind of API would be necessary here? I'm
> thinking about something along the lines of:
>
>
> `asOutputStream(f: OutputStream => Done, writeTimeout: FiniteDuration
> = 5.seconds): Source[ByteString, Future[IOResult]]`
>
>
> `f` would be invoked after the stream is ready for writing. After `f`
> completes, the framework could ensure the stream is cleaned up properly.
> The returned `IOResult.status` could be used to check whether `f` 
> completed
> normally. If `f` fails to complete within specified timeout, any further
> attempt to call methods on the `OutputStream` should result in an
> `IOException`. The problem I see is that `f` could get permanently blocked
> on some condition and thus steal a thread from
> `akka.stream.blocking-io-dispatcher` but I don't think there is any
> way to handled that on the JVM.
>
>
> I am not sure if the above is feasible but if it were I'm sure people
> would find it useful for interfacing with legacy code ;)
>
>
> Cheers,
>
> Rafał
>
>
> [1] https://doc.akka.io/docs/akka/current/scala/stream/stages-ov
> erview.html#additional-sink-and-source-converters
>
> [2] https://poi.apache.org/spreadsheet/how-to.html#sxssf
>
> [3] https://poi.apache.org/apidocs/org/apache/poi/xssf/streaming
> /SXSSFWorkbook.html#write-java.io.OutputStream-
>
 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Viktor Klang]

When you say "unhandled exception" you mean "uncaught exception"?

On Mon, Nov 13, 2017 at 4:48 AM, Christopher Hunt  wrote:

> Hi everyone,
>
> I have a situation where I need to call System.exit upon an actor system
> having terminated. In some runtime situations, a SecurityException will
> be thrown and I need that to be propagated as an unhandled exception. I can
> go into the details of why if required, but my question is how to enable
> this. Here's my existing termination handler which does what I want.
> However, I'm wondering if there's a better way given that onComplete and
> friends all swallow exceptions and pass them onto the Dispatcher's reporter:
>
>   system.whenTerminated
> .andThen {
>   case _ =>
> new Thread({ () =>
>   println("Exiting")
>   System.exit(exitStatus.getOrElse(1))
> }: Runnable).start()
> }
>
>
> Cheers,
> -C
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Viktor Klang]

Depends on what you want to achieve. You can always do
Thread.currentThread.getUncaughtExeptionHandler and pass your exception in
manually (if you don't want to throw a Fatal exception or provide your own
`reporter` (to the ExecutionContext).

On Mon, Nov 13, 2017 at 1:30 PM, Christopher Hunt  wrote:

> Ah yes, uncaught. Thanks for the correction.
>
> On 13 Nov 2017, at 21:12, Viktor Klang  wrote:
>
> When you say "unhandled exception" you mean "uncaught exception"?
>
> On Mon, Nov 13, 2017 at 4:48 AM, Christopher Hunt 
> wrote:
>
>> Hi everyone,
>>
>> I have a situation where I need to call System.exit upon an actor system
>> having terminated. In some runtime situations, a SecurityException will
>> be thrown and I need that to be propagated as an unhandled exception. I can
>> go into the details of why if required, but my question is how to enable
>> this. Here's my existing termination handler which does what I want.
>> However, I'm wondering if there's a better way given that onComplete and
>> friends all swallow exceptions and pass them onto the Dispatcher's reporter:
>>
>>   system.whenTerminated
>> .andThen {
>>   case _ =>
>> new Thread({ () =>
>>   println("Exiting")
>>   System.exit(exitStatus.getOrElse(1))
>> }: Runnable).start()
>> }
>>
>>
>> Cheers,
>> -C
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> √
>
> --
> >>>>>>>>>> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/akka-user/gZkCvLWhyGc/unsubscribe.
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Preventing Memory Leaks

[Viktor Klang]

The ActorRef won't prevent the Actor-instance from being garbage-collected.
But if you want to avoid hanging onto stale ActorRefs I'd recommend using
Death Watch and remove the refs as they are reported in as dead.

On Sun, Nov 19, 2017 at 8:13 PM, Joseph Mansigian <
joseph.c.mansig...@gmail.com> wrote:

> I have a Play Framework Scala application in development that stores long
> lived ActorRefs in a mutable Map. When an actor is no longer needed it is
> sent it a message that informs it to stop itself and it will.
>
> My concern is about the visibility of stopped actors to JVM garbage
> collection; especially those whose ActorRefs are enclosed within a
> Collection,
>
> What do I need to do if  ActorRefs are ( hidden ? ) inside a Scala
> Collection?
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to measure performance of Actor Message from one actor reaching to another actor

[Viktor Klang]

Also, is serialization/deserialization included? At what point does the
timer clock start, and when does it stop?

-- 
Cheers,
√

On Dec 15, 2017 20:31, "Patrik Nordwall"  wrote:

> What are you interested in? Throughput (msg/s) or latency (us)? Remote or
> local? What will the results of the benchmarks be used for?
>
> /Patrik
> fre 15 dec. 2017 kl. 12:23 skrev Akka Team :
>
>> I think the floodPipe benchmark may do what you want, commented out but
>> you could easily uncomment and run locally:
>>
>> https://github.com/akka/akka/blob/master/akka-bench-jmh/
>> src/main/scala/akka/actor/ForkJoinActorBenchmark.scala#L92
>>
>> --
>> Johan
>> Akka Team
>>
>> On Fri, Dec 15, 2017 at 11:20 AM,  wrote:
>>
>>> Ok, I just looked at TellOnlyBenchmark.scala
>>> 
>>>  closely and it just drops all the message and does not take into
>>> consideration of time taken by message to reach receiving actor.
>>>
>>>
>>> On Friday, December 15, 2017 at 2:54:55 PM UTC+5:30,
>>> kpr...@thoughtworks.com wrote:

 Hello,

 I want to measure a performance of following use case using jmh.




 1.
 Actor A sends Msg A to Actor B
 2. On receiving Msg A, Actor B sends Same Msg A to Actor C

 I just want to measure performance of Msg A from Actor A reaching to
 Actor C (Do not want to consider acknowledgment).
 Is there any way i can measure this performance?

 I was going through Akka jmh benchmarks and found this
 TellOnlyBenchmark.scala
 

 But not sure it just measures the performance of sending messages or it
 considers time required to reach message to Echo Actor?


 Thanks


 --
>>> >> 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 https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> >> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Request for help on Improving Scalability for Akka Streams Program

[Viktor Klang]

Where is your bottleneck?

On Thu, Jan 11, 2018 at 12:17 PM,  wrote:

> Hi Everyone,
>
> I am learning Scala and Akka Streams, I would kindly like to request for
> help on enhancing my small Akka Streams Program so that it can scale with
> increase in data. Below are the two functions of the Program;
>
> a. convertTxtToPDF: This function converts raw text files to PDF files
> b. setPwdLock: This function sets a password on PDF files generated
>
> It takes below time for processing;
>
> i. 1000 text files takes 8 mins (50 parallelism)
> ii. 3000 text files takes 14 mins (150 parallelism)
> iii. 1 text files takes 47 mins (500 parallelism)
>
> I noted that with increase in files, the longer it takes to process.
> Kindly help me enhance the Program to scale with increased data i.e
> processing should take less time with increased number of text files.
>
> Please find the attached code for the Program.
>
> Kind Regards,
> Emmanuel.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka stream out of band data

[Viktor Klang]

How do you deal with M:N ports or X:Y element permutations?

-- 
Cheers,
√

On Feb 18, 2018 01:53, "Christopher Hunt"  wrote:

> Hi there,
>
> I’ve been wondering recently if there’s been any thought around carrying
> out of band data through an Akka Stream in the spirit of network streams:
> https://en.m.wikipedia.org/wiki/Out-of-band_data
>
> One use case is for carrying Open Tracing Spans with elements without
> polluting stream stage operations. To illustrate: https://github.com/akka/
> alpakka/issues/463#issuecomment-365765409
>
> By way of solution, perhaps this could be achieved similarly to the
> materialiser api calls eg viaMat/viaOob.
>
> Thoughts?
>
> Cheers
> C
>
> --
> >>  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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] HTTP server performance

[Viktor Klang]

Mirek,

As a general note: Benchmarking using default configuration is almost
pointless* since a default configuration is—by definition, and by
necessity—a configuration which will not be *optimal for a specific
use-case*.

*It can be useful as a baseline for tuning.

On Mon, Feb 19, 2018 at 11:30 PM, Mirek Suk  wrote:

> Hi everyone.
>
> AKKA 2.5.9 / HTTP 10.0.11
>
> As part of prototyping architecture, I ran some benchmarks (including
> http) few months ago.
> A simple hello world (request handler is completed with result
> immediately) had nice performance ~2.7m requests/minute. with 1,6m r/m when
> response included ask to sharded actor.
>
> Recently I re-did those benchmarks to find out around ~9x performance drop
> on original test system.
> Rolled prototype back to point of original test with similar result.
> Built scala http sample with similar result.
> Reinstalled JVM with similar result.
> Randomly got performance back, until system restart (yeah like what ?)
>
> On EC2-T2.medium I can do ~7k req/s to "hello world" page with 100% CPU
> usage (2 cores).
> No akka.http configuration is changed and system does no background
> processing.
> Default dispatcher is unchanged (only due to clustering throughput = 10).
>
> Is this kind of performance expected ?
> Is there something I can try ?
>
> Thanks,
> M.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] HTTP server performance

[Viktor Klang]

The top hit for me when searching for "tuning akka http" is:
https://stackoverflow.com/questions/41297334/akka-http-performance-tuning

On Tue, Feb 20, 2018 at 5:39 PM, Mirek Suk  wrote:

> There is not much to change in akka http server configuration. Care to
> share any tips ?
>
> I've tried fidling with io.tcp with little luck. (accept batches etc...)
> EC2 instances are restarted during every deployment.
>
> Anyways I'm currently in process of migration of http interface to
> finangle as it seems to have ~2.5x better throughput with less cpu
> consumed.
> But I still wonder where the performance I initially measured went. (I
> blame the meltdown patch on windows secretly lol)
>
> Thanks
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] HTTP server performance

[Viktor Klang]

Ok. So besides the common dispatcher tuning tips, JVM tuning tips, and
Linux IO tuning tips there's also a lot of settings for Akka Http

 specifically.

On Tue, Feb 20, 2018 at 6:23 PM, Mirek Suk  wrote:

> Thanks, but been there seen that, I would not be here without simple
> google search.
>
> Guy used blocking operations which limited his throughput. We - as far as
> I know and as far cpu usage says - don't.
> For http benchmark i use - as I mentioned - simple complete("hello world")
> For normal operation we use ask pattern which creates temporary actor and
> complete requests in async manner.
>
> M.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] HTTP server performance

[Viktor Klang]

What dispatcher tuning did you experiment with?

On Tue, Feb 20, 2018 at 10:57 PM, Mirek Suk  wrote:

> Only a few of them could affect CPU consumption and throuput, unless they
> mean something else.
> Besides that as I mentioned in op throuput degradation was "random" and on
> same system. Tunning (in java) usually means ~50%. As I mentioned I'm
> experiencing 9x performance drop from initial benchmarks.
>
> As a sidenote
> JVM tuning: min, max memory = 2gb (bit op, but due to sharding state),disable
> shared memory (akka is distributed as docker)
> Linux IO tuning: netty (both v3 and v4 as akka uses v3) epoll loop used.
>
> Performance degradation happened on windows server machine used for
> initial evaluation. I sadly never did benchmarks on EC2 linux instances
> initially as we were bound for Azure, so my reference point sucks a bit.
> I still do consider 7k requests with 1000milicores on 2xcpu a very
> miserable result.
>
> My experience with scala/java is very limited - 2 months (c++ guy here) so
> my expectations may be above what jvm is capable of.
> Benchmark from someone else would probably help, but akka http benchmarks
> are scarce.
>
> Besides that I'm unsure why do I answer to non constructive posts.
> Probably because I needed help which won't be found here.
>
> Thanks.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: HTTP server performance

[Viktor Klang]

On Tue, Feb 20, 2018 at 11:46 PM, Mirek Suk  wrote:

> I doubt dispatcher is problem as forkjoinpool with default (and lesser
> settings due to tests required by ops) were tried.
>

What do you mean by "lesser settings"? How did changing pool size and/or
throughput affect your bench?

What tool are you using to bench it with?


> No other dispatches would make sense in our case.
>
> As a sidenote grpc.io endpoint which does
> - route to akka cluster instance where state is via sharding actor (artery
> is used)
> - persistent actor modifies state (cassandra cluster)
> - route response back and respond to grpc call
>
> This endpoint has performance of ~6k req/sec (akka is cpu bound here)
> which (considering the amount of work) is "nice" (once again I see
> performance metrics in c++ so I'm biased, but rapid development in akka
> somewhat erases some issues for me)
>
> So I don't see where http endpoint could spend so much time if it has only
> ~15% more performance over grpc.
>
> Once again my main issue here is original vs current tests.
> Sadly I can find proof for both cases - akka http unacceptable/acceptable
> - online. One here, second on unrelated site.
> However nothing still explains performance degradation, except for my
> error.
> https://groups.google.com/forum/#!topic/akka-user/qhZlh0KBl2A
> https://www.techempower.com/benchmarks/
>
> I did not study methodologies used to validate any of those benchmarks.
> Possibly akka team should do that so we have reference point.
>
> M.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: HTTP server performance

[Viktor Klang]

What does wrk2 say w.r.t. throughput?
Are you testing pipelined requests or new connections for each request? Are
you testing over network or not?

On Wed, Feb 21, 2018 at 12:25 AM, Mirek Suk  wrote:

> Lesser = less maximum threads. Akka has minimum which is "high" for 2 core
> machines. = in error margin difference +-~5%
> throuput on default displtcher changed to 100 and 1 (clustering changes
> this to 10 from 1)
> 1 = worse performance (around -20%, but once again consider artery in
> play, with default remoting I assume it would be worse)
> 100 = in error margin.
>
> I even tried to create "local" actorSystem for services which are local to
> each akka pod/node (in jvm process) instead of using clusered one. made no
> difference.
> Noticeable difference in grpc was
> https://grpc.io/grpc-java/javadoc/io/grpc/ServerBuilder.
> html#directExecutor--
> around 10% in overall cpu consumption. meaning routing "something" from
> netty thread to executor is somewhat slow. (considering we only do ask in
> grpc)
>
> Tools
> - jmeter (for "hello world" benchmark)
> - custom device simulator. We're prototyping IOT server app.
>
> M.
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] import context.dispatcher nullpointerexception

[Viktor Klang]

Context is bound to the lifecycle of the actor.

On Tue, Mar 6, 2018 at 8:37 PM, Jeff  wrote:

> I have noticed an issue where if a future maps/flatmaps after actor
> shutdown, a NullPointerException is thrown. I've narrowed it down to the 
> import
> context.dispatcher, which I technically understand since that is closing
> over actor state. If I change that to implicit val ec = context.dispatcher,
> everything works fine.
>
> I'd like to understand what is the best practice in this case, since the
> documentation for context.dispatcher indicates that it is threadsafe and
> looking at the actor trait, context is a val. Most documentation seems to
> indicate that import context.dispatcher is preferred.
>
> Thanks
> Jeff
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Exception when persisting the ShardCoordinator

[Viktor Klang]

Just an "off the cuff" guess: akka-persistence-jdbc does not provide a
ConnectionPoolSettings when creating the connection pool, which means that
the defaults will be provided, which does not contain a validation query,
which means that the only way to test the validity of the connections to
Oracle DB is via the "isValid" getter, which does not reset the idle timer
of the connection, which leads to connections timing out.

So if my guess is correct the fix is to add the proper validation query
when creating the connection pool, and if memory serves me right the common
query for this when it comes to Oracle DB is "select 1 from dual".

On Tue, Dec 23, 2014 at 11:24 PM, Miguel Vilá  wrote:

> Thanks, Endre
>
> A colleague of mine already submitted an issue to them but we haven't
> received any response yet:
> https://github.com/dnvriend/akka-persistence-jdbc/issues/9 . Is it
> possible to have the coordinator's persistence use a different journal than
> the one used by our own persistent actors?
>
> El martes, 23 de diciembre de 2014 14:42:24 UTC-5, Akka Team escribió:
>>
>> Hi Miguel,
>>
>> This seems to be a journal issue. You should contact the maintainer of
>> the JDBC journal.
>>
>> -Endre
>>
>> On Tue, Dec 23, 2014 at 7:43 PM, Miguel Vilá 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm having a problem with akka-persistence and akka-sharding. Every now
>>> and then, sometimes after running our app for a long time I get this error:
>>>
>>> DELETE FROM USERSIS.snapshot WHERE persistence_id = '/user/sharding/
>>> TokenRouterCoordinator/singleton/coordinator' AND sequence_nr = 2
>>>
>>>
>>> [ERROR] [12/18/2014 13:51:28.826] [TokenCluster-akka.actor.default-
>>> dispatcher-16] [akka://TokenCluster/system/snapshot-store] No more data
>>> to read from socket
>>> java.sql.SQLRecoverableException: No more data to read from socket
>>> at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:
>>> 1157)
>>> at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:350)
>>> at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:227)
>>> at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
>>> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedS
>>> tatement.java:208)
>>> at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPr
>>> eparedStatement.java:1046)
>>> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(Orac
>>> leStatement.java:1336)
>>> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(O
>>> raclePreparedStatement.java:3613)
>>> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(Ora
>>> clePreparedStatement.java:3694)
>>> at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(
>>> OraclePreparedStatementWrapper.java:1354)
>>> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate
>>> (DelegatingPreparedStatement.java:105)
>>> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate
>>> (DelegatingPreparedStatement.java:105)
>>> at scalikejdbc.StatementExecutor$$anonfun$executeUpdate$1.apply
>>> $mcI$sp(StatementExecutor.scala:337)
>>> at scalikejdbc.StatementExecutor$$anonfun$executeUpdate$1.apply(
>>> StatementExecutor.scala:337)
>>> at scalikejdbc.StatementExecutor$$anonfun$executeUpdate$1.apply(
>>> StatementExecutor.scala:337)
>>> at scalikejdbc.StatementExecutor$NakedExecutor.apply(StatementE
>>> xecutor.scala:33)
>>> at scalikejdbc.StatementExecutor$$anon$1.scalikejdbc$
>>> StatementExecutor$LoggingSQLAndTiming$$super$apply(StatementExecutor.
>>> scala:317)
>>> at scalikejdbc.StatementExecutor$LoggingSQLAndTiming$class.apply(
>>> StatementExecutor.scala:264)
>>> at scalikejdbc.StatementExecutor$$anon$1.scalikejdbc$
>>> StatementExecutor$LoggingSQLIfFailed$$super$apply(StatementExecutor.
>>> scala:317)
>>> at scalikejdbc.StatementExecutor$LoggingSQLIfFailed$class.apply(
>>> StatementExecutor.scala:295)
>>> at scalikejdbc.StatementExecutor$$anon$1.apply(StatementExecutor.
>>> scala:317)
>>> at scalikejdbc.StatementExecutor.executeUpdate(StatementExecutor.
>>> scala:337)
>>> at scalikejdbc.DBSession$$anonfun$updateWithFilters$1.apply(
>>> DBSession.scala:352)
>>> at scalikejdbc.DBSession$$anonfun$updateWithFilters$1.apply(
>>> DBSession.scala:350)
>>> at scalikejdbc.LoanPattern$class.using(LoanPattern.scala:33)
>>> at scalikejdbc.ActiveSession.using(DBSession.scala:457)
>>> at scalikejdbc.DBSession$class.updateWithFilters(DBSession.scala:349
>>> )
>>> at scalikejdbc.ActiveSession.updateWithFilters(DBSession.scala:457)
>>> at scalikejdbc.DBSession$class.updateWithFilters(DBSession.scala:327
>>> )
>>> at scalikejdbc.ActiveSession.updateWithFilters(DBSession.scala:457)
>>> at scalikejdbc.SQLUpdate$$anonfun$10.apply(SQL.scala:486)
>>> at scalikejdbc.SQLUpdate$$anonfun$10.apply(SQL.scala:486)
>>> at scalikejdbc.DBConnection$class.autoCommit(DBConnection.scala:183)
>>> at scalikejdbc.DB.autoCo

Re: [akka-user] calling code that uses jsr166y

[Viktor Klang]

Hi Tim,

is it using ForkJoinTask/RecursiveTask directly?


On Wed, Jan 7, 2015 at 12:23 PM, Tim Pigden  wrote:

> Hi
> I'm going to be calling some Java multi-threaded code that is currently
> using JSR166Y (due to backward compatibility requirements with some legacy
> java 6 code).
>
> My Java developer wants to know if he should do a branch to use java7 (or
> 8) compatible fork join pool instead
>
> The intention is I call this from within an actor and possibly from within
> multiple actors (i.e. simultaneously). So I could have 2 or 3 actors each
> calling this code (a fairly long lived dynamic program at up to 500ms)
> which itself is using fork join to parallel process with a fairly low
> number of threads.
>
> Is there a recommendation of best practice here?
>
> Tim
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] calling code that uses jsr166y

[Viktor Klang]

Hmmm, I've reread your question a couple of times and I am not sure what
you are asking, is there something more specific your wonder? (I don't know
what goals you have)

On Wed, Jan 7, 2015 at 12:40 PM, Tim Pigden  wrote:

> hi - yes
>
>
> On 7 January 2015 at 11:32, Viktor Klang  wrote:
>
>> Hi Tim,
>>
>> is it using ForkJoinTask/RecursiveTask directly?
>>
>>
>> On Wed, Jan 7, 2015 at 12:23 PM, Tim Pigden 
>> wrote:
>>
>>> Hi
>>> I'm going to be calling some Java multi-threaded code that is currently
>>> using JSR166Y (due to backward compatibility requirements with some legacy
>>> java 6 code).
>>>
>>> My Java developer wants to know if he should do a branch to use java7
>>> (or 8) compatible fork join pool instead
>>>
>>> The intention is I call this from within an actor and possibly from
>>> within multiple actors (i.e. simultaneously). So I could have 2 or 3 actors
>>> each calling this code (a fairly long lived dynamic program at up to 500ms)
>>> which itself is using fork join to parallel process with a fairly low
>>> number of threads.
>>>
>>> Is there a recommendation of best practice here?
>>>
>>> Tim
>>>
>>> --
>>> >>>>>>>>>> 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.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>> --
>> >>>>>>>>>> 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 a topic in the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/D4eu8JUq2Lk/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>>
>
>
>
> --
> Tim Pigden
> Optrak Distribution Software Limited
> +44 (0)1992 517100
> http://www.linkedin.com/in/timpigden
> http://optrak.com
> Optrak Distribution Software Ltd is a limited company registered in
> England and Wales.
> Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings,
> Hoe Lane, Ware, SG12 9LR England
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Optrak Distribution Software Ltd. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error.
>
> --
> >>>>>>>>>> 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.
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  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.

Re: [akka-user] calling code that uses jsr166y

[Viktor Klang]

Hi Tim,

Akka fork-join-executor-based dispatchers uses Scala's embedded jsr166
version of FJ.
I don't think it lets you work with FJT though.

On Wed, Jan 7, 2015 at 1:16 PM, Tim Pigden  wrote:

> Hi Viktor,
> Ok sorry - I'm not an expert in these matters - apologies for the
> vagueness.  I'll do some homework and make him read the docs. Dispatcher
> looks a good place to start.
>
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Akka Persistence on the Query Side: The Conclusion

[Viktor Klang]

On Fri, Jan 9, 2015 at 11:56 AM, Greg Young  wrote:

> Usually it comes down to the realization that the computer is not the book
> of record. One of my favourites was being asked to build a fully consistent
> inventory system. I generally like to approach things with questions, the
> one i had was 'sure but how do we get people who are stealing stuff to
> appropriately check it out?'
>
+Long.MAX_VALUE on this. Building warehouse management systems is very
eye-opening.



> On 9 Jan 2015 12:02, "Sebastian Bach" 
> wrote:
>
>>
>> Thank you Greg. The mind shift from a preventive to a reactive workflow
>> is not easy for users (humans), because it requires a change of habits. For
>> many people computer systems are kind of authoritative. There is this wrong
>> assumption (from early days of computation?) that a computer accepts only a
>> valid input or returns an error. It was then only black or white, the
>> golden era of transactions. But this was (as you pointed out) always to
>> some degree an hypocrisy. Now we have this shades of gray and many users
>> feel unsettled. This holds true for any kind of resource allocation
>> application and the overbooking (or wrong booking) problem. Some of the
>> users define taking workload off of them as avoiding of planning mistakes,
>> like commit and forget. But the actual workflow seems to shift towards an
>> iterative process of human-computer interaction, to some kind of
>> react-react ping-pong.
>>
>> Best Regards
>> Sebastian
>>
>>
>> W dniu środa, 7 stycznia 2015 22:15:42 UTC+1 użytkownik Greg Young
>> napisał:
>>>
>>> "The consistency of the query model should be achieved as soon as
>>> possible and close to real-time."
>>>
>>> It really depends on the domain. I have worked in many situations
>>> where the data in question would be perfectly fine updated once per
>>> month.
>>>
>>> " (e.g. adding a sold out item to the shopping cart)."
>>>
>>> This is a funny example because it shows not that you need to update
>>> read models more quickly but that you need to get the whole business
>>> on board. Remember that computer systems are normally part of a larger
>>> system fulfilling business needs. It really is a mind shift moving to
>>> eventual consistency.
>>>
>>> In the example of adding a sold out item... why stop it? Does it
>>> matter that we don't have any of this item? The real question is how
>>> quickly we can get it and if its worth our while to do so. To be fair
>>> 30 years ago these times were much much higher than what we talk about
>>> today and yet businesses still managed to work their way through
>>> things.
>>>
>>> For many of these types allowing things to go incorrectly is actually
>>> a good thing (overbooked seats on an airline, overdraft charges at
>>> banks...). To really be benefiting from eventual consistency the whole
>>> business process must recognize it. In terms of handling failures they
>>> are normally handled in a reactive not a preventative manner (like
>>> most business problems). Detect the failure, let a human deal with it.
>>>
>>> At the end of the day the primary role of the computer system is to
>>> take workload off of humans. You will hit the law of diminishing
>>> returns. dont try to solve every problem :)
>>>
>>> Greg
>>>
>>> On Wed, Jan 7, 2015 at 11:07 PM, Sebastian Bach
>>>  wrote:
>>> > Hi Roland,
>>> >
>>> > one thing to keep in mind in the CQRS/ES architecture is that not only
>>> the
>>> > query side depends on the command side (by following the event stream)
>>> but
>>> > also the command side depends on the query side for validation of
>>> complex
>>> > business rules. This has a deep impact on correctness and throughput.
>>> > Validation checks on an potentially outdated query model in an
>>> eventually
>>> > consistent architecture is a hard problem (e.g. adding a sold out item
>>> to
>>> > the shopping cart). The consistency of the query model should be
>>> achieved as
>>> > soon as possible and close to real-time. A PersistentView in Akka has
>>> a
>>> > default of 5s? On the other hand the speed of validation depends on
>>> the
>>> > speed of the queries. And the throughput depends on the validation
>>> speed.
>>> > Thus, queries directly on the whole event stream are less useful than
>>> > persistent projections.
>>> >
>>> > Keep up the good work :)
>>> > Cheers
>>> > Sebastian
>>> >
>>> >
>>> > W dniu wtorek, 7 października 2014 07:32:20 UTC+2 użytkownik rkuhn
>>> napisał:
>>> >>
>>> >> Hi Vaughn,
>>> >>
>>> >> from our side nothing has happened yet: my conclusion is that this
>>> thread
>>> >> contains all the information we need when we start working on this.
>>> The
>>> >> reason why we are waiting is that this work will depend heavily upon
>>> Akka
>>> >> Streams and therefore we are finishing those first, which should take
>>> >> roughly one month. Meanwhile, if use cases come up which could be
>>> used to
>>> >> refine the plans, please point them out here so that we can take all
>>> the
>>> >> 

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

[Viktor Klang]

Hi David,

yes, I can definitely understand that it can be surprising, but I wouldn't
call it a bug -per se-, since it is not a promise that was violated.

If you happen to have, or come by, a performant version of a PriorityQueue
with the semantics you described, please don't hesitate to share it.

On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
wrote:

> It occurs to me that I wasn't completely clear:
>
>- Of course the priority mailbox must break message ordering in some
>general sense. Else it wouldn't be a priority mailbox at all!
>- But it is highly surprising to me that it should break ordering for
>messages of equal priority between a sender-receiver pair.
>
>
> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>>
>> Hi,
>>
>> We've been tracking down a bug in which reading from a TCP stream was
>> getting all messed up.
>>
>> It turns out that we see the problem only when our actor handling
>> Tcp.Received messages is using an UnboundedPriorityMailbox; the default
>> mailbox doesn't exhibit any problem.
>>
>> I believe that the issue is that the UnboundedPriorityMailbox is backed
>> by a PriorityBlockingQueue; and that, per the documentation for that class,
>> "Operations on this class make no guarantees about the ordering of elements
>> with equal priority".
>>
>> That is, it seems that the UnboundedPriorityMailbox breaks the guarantee
>> of message ordering per sender–receiver pair.  In our case, the result
>> being that different chunks of the TCP data stream arrive not in the order
>> in which they were read from the wire.
>>
>> Does this analysis seem to be correct?
>>
>> If yes, is it a bug?  Would you like me to raise a ticket?
>>
>> Thanks!
>>
>> David
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

[Viktor Klang]

On Fri, Jan 9, 2015 at 9:40 PM, David Hotham 
wrote:

> Of course it's normal and expected that a PriorityQueue returns equal
> priority elements in arbitrary order.  That's just how heaps work.  However
> that doesn't imply that a mailbox has to do the same thing!
>

Absolutely, the reordering is not a requirement :) However, silently
switching to a new, non-reordering-of-same-priority implementation would
risk breaking existing code (that for some reason relies on this behavior).


>
> For instance, I guess that it shouldn't be very hard for the mailbox to
> maintain a sequence number that it associates with each message.
>

Sure! The question is how how big the impact is on memory consumption and
performance.


> Then it could order messages first according to the comparator that it
> currently uses, and second according to the sequence number.  That way it
> would return equal priority messages in the same order that it saw them
> arrive - which gives exactly the property that I'd hoped for.
>

Absolutely :)


>
> I can't tell from your reply whether you think that maintaining order for
> equal priority messages is desirable or not.
>

I think it could be interesting as an alternative to the current version of
the PriorityMailbox, or perhaps even as a replacement if it is performing
as well as the thing it replaces.


>
>- If yes, what do you think about an implementation along these
>lines?  Is it worth me raising an issue at github?
>
> I wish I had time to do that, is it something you'd be willing/able to
take a stab at? Would love to see something like that.

>
>- If no, can I at least encourage the Akka maintainers to add an
>explicit note to the documentation, so that other users are less likely to
>fall into my error?
>
> I think this should be done anyway, since it as you said, and I confirmed,
surprising at first. :)



> Cheers,
>
> David
>
> On Friday, 9 January 2015 19:43:27 UTC, √ wrote:
>>
>> Hi David,
>>
>> yes, I can definitely understand that it can be surprising, but I
>> wouldn't call it a bug -per se-, since it is not a promise that was
>> violated.
>>
>> If you happen to have, or come by, a performant version of a
>> PriorityQueue with the semantics you described, please don't hesitate to
>> share it.
>>
>> On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
>> wrote:
>>
>>> It occurs to me that I wasn't completely clear:
>>>
>>>- Of course the priority mailbox must break message ordering in some
>>>general sense. Else it wouldn't be a priority mailbox at all!
>>>- But it is highly surprising to me that it should break ordering
>>>for messages of equal priority between a sender-receiver pair.
>>>
>>>
>>> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:

 Hi,

 We've been tracking down a bug in which reading from a TCP stream was
 getting all messed up.

 It turns out that we see the problem only when our actor handling
 Tcp.Received messages is using an UnboundedPriorityMailbox; the default
 mailbox doesn't exhibit any problem.

 I believe that the issue is that the UnboundedPriorityMailbox is backed
 by a PriorityBlockingQueue; and that, per the documentation for that class,
 "Operations on this class make no guarantees about the ordering of elements
 with equal priority".

 That is, it seems that the UnboundedPriorityMailbox breaks the
 guarantee of message ordering per sender–receiver pair.  In our case, the
 result being that different chunks of the TCP data stream arrive not in the
 order in which they were read from the wire.

 Does this analysis seem to be correct?

 If yes, is it a bug?  Would you like me to raise a ticket?

 Thanks!

 David

>>>  --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> 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-u

Re: [akka-user] Re: How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Viktor Klang]

Hi Allen,

What's the bottleneck?
Have you tried enabling the experimental optimizations?

On Fri, Jan 9, 2015 at 9:52 PM, Allen Nie  wrote:

> Thank you Soumya,
>
>I think Akka-streams is the way to go. However, I would also
> appreciate some performance boost as well - still have 40 million lines to
> go through! But thanks anyway!
>
>
> On Friday, January 9, 2015 at 12:43:49 PM UTC-5, Soumya Simanta wrote:
>>
>> I would recommend using the Akka-streams API for this.
>> Here is sample. I was able to process a 1G file with around 1.5 million
>> records in *20MB* of memory. The file read and the writing on the
>> console rates are different but the streams API handles that.  This is not
>> the fastest but you at least won't run out of memory.
>>
>>
>>
>> 
>>
>> import java.io.FileInputStream
>> import java.util.Scanner
>>
>> import akka.actor.ActorSystem
>> import akka.stream.{FlowMaterializer, MaterializerSettings}
>> import akka.stream.scaladsl.Source
>>
>> import scala.util.Try
>>
>>
>> object StreamingFileReader extends App {
>>
>>
>>   val inputStream = new FileInputStream("/path/to/file")
>>   val sc = new Scanner(inputStream, "UTF-8")
>>
>>   implicit val system = ActorSystem("Sys")
>>   val settings = MaterializerSettings(system)
>>   implicit val materializer = 
>> FlowMaterializer(settings.copy(maxInputBufferSize
>> = 256, initialInputBufferSize = 256))
>>
>>   val fileSource = Source(() => Iterator.continually(sc.nextLine()))
>>
>>   import system.dispatcher
>>
>>   fileSource.map { line =>
>> line //do nothing
>>   //in the for each print the line.
>>   }.foreach(println).onComplete { _ =>
>> Try {
>>   sc.close()
>>   inputStream.close()
>> }
>> system.shutdown()
>>   }
>> }
>>
>>
>>
>>
>> On Friday, January 9, 2015 at 10:53:33 AM UTC-5, Allen Nie wrote:
>>>
>>> Hi,
>>>
>>> I am trying to process a csv file with 40 million lines of data in
>>> there. It's a 5GB size file. I'm trying to use Akka to parallelize the
>>> task. However, it seems like I can't stop the quick memory growth. It
>>> expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This is
>>> the code in my main() method:
>>>
>>> val inputStream = new 
>>> FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
>>> Scanner(inputStream, "UTF-8")
>>> var counter = 0
>>> while (sc.hasNextLine) {
>>>
>>>   rowActors(counter % 20) ! Row(sc.nextLine())
>>>
>>>   counter += 1}
>>>
>>> sc.close()
>>> inputStream.close()
>>>
>>> Someone pointed out that I was essentially creating 40 million Row
>>> objects, which naturally will take up a lot of space. My row actor is not
>>> doing much. Just simply transforming each line into an array of integers
>>> (if you are familiar with the concept of vectorizing, that's what I'm
>>> doing). Then the transformed array gets printed out. Done. I originally
>>> thought there was a memory leak but maybe I'm not managing memory right.
>>> Can I get any wise suggestions from the Akka experts here??
>>>
>>>
>>>
>>> 
>>>
>>>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Viktor Klang]

Hi Allen,

I'd suspect the reason that it works well with Akka Streams is that they
have back-pressure while your actor solution does not (you'll send 40
million messages as fast as you can, but the actor processing them might
not be able to keep up)

On Fri, Jan 9, 2015 at 10:53 PM, Allen Nie  wrote:

> Hey Viktor,
>
> I'm trying to use Akka to parallelize this process. There shouldn't be
> any bottleneck, and I don't understand why I got memory overflow with my
> first version (actor version). The main task is to read in a line, break it
> up, and turn each segments (strings) into an integer, then prints it out to
> a CSV file (vectorization process).
>
>def processLine(line: String): Unit = {
>
>   val vector: ListBuffer[String] = ListBuffer()
>   val segs = line.split(",")
>
>   println(segs(0))
>
>   (1 to segs.length - 1).map {i =>
> val factorArray = dictionaries(i-1)
> vector += factorArray._2.indexOf(segs(i)).toString   //get the factor 
> level of string
>   }
>
>   timer ! OneDone
>
>   printer ! Print(vector.toList)}
>
>
> When I'm doing this in pure Akka (with actors), since I created 40
> million objects: Row(line: String), I get memory overflow issue. If I use
> Akka-stream, there is no memory overflow issue, but the performance is too
> similar to the non-parallelized version (even slower).
>
> It's my first time using Akka-stream. So I'm unfamiliar with the
> optimization you were talking about.
>
> Sincerely,
> Allen
>
> On Friday, January 9, 2015 at 4:03:13 PM UTC-5, √ wrote:
>>
>> Hi Allen,
>>
>> What's the bottleneck?
>> Have you tried enabling the experimental optimizations?
>>
>> On Fri, Jan 9, 2015 at 9:52 PM, Allen Nie  wrote:
>>
>>> Thank you Soumya,
>>>
>>>I think Akka-streams is the way to go. However, I would also
>>> appreciate some performance boost as well - still have 40 million lines to
>>> go through! But thanks anyway!
>>>
>>>
>>> On Friday, January 9, 2015 at 12:43:49 PM UTC-5, Soumya Simanta wrote:

 I would recommend using the Akka-streams API for this.
 Here is sample. I was able to process a 1G file with around 1.5 million
 records in *20MB* of memory. The file read and the writing on the
 console rates are different but the streams API handles that.  This is not
 the fastest but you at least won't run out of memory.



 

 import java.io.FileInputStream
 import java.util.Scanner

 import akka.actor.ActorSystem
 import akka.stream.{FlowMaterializer, MaterializerSettings}
 import akka.stream.scaladsl.Source

 import scala.util.Try


 object StreamingFileReader extends App {


   val inputStream = new FileInputStream("/path/to/file")
   val sc = new Scanner(inputStream, "UTF-8")

   implicit val system = ActorSystem("Sys")
   val settings = MaterializerSettings(system)
   implicit val materializer = 
 FlowMaterializer(settings.copy(maxInputBufferSize
 = 256, initialInputBufferSize = 256))

   val fileSource = Source(() => Iterator.continually(sc.nextLine()))

   import system.dispatcher

   fileSource.map { line =>
 line //do nothing
   //in the for each print the line.
   }.foreach(println).onComplete { _ =>
 Try {
   sc.close()
   inputStream.close()
 }
 system.shutdown()
   }
 }




 On Friday, January 9, 2015 at 10:53:33 AM UTC-5, Allen Nie wrote:
>
> Hi,
>
> I am trying to process a csv file with 40 million lines of data in
> there. It's a 5GB size file. I'm trying to use Akka to parallelize the
> task. However, it seems like I can't stop the quick memory growth. It
> expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This 
> is
> the code in my main() method:
>
> val inputStream = new 
> FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
> Scanner(inputStream, "UTF-8")
> var counter = 0
> while (sc.hasNextLine) {
>
>   rowActors(counter % 20) ! Row(sc.nextLine())
>
>   counter += 1}
>
> sc.close()
> inputStream.close()
>
> Someone pointed out that I was essentially creating 40 million Row
> objects, which naturally will take up a lot of space. My row actor is not
> doing much. Just simply transforming each line into an array of integers
> (if you are familiar with the concept of vectorizing, that's what I'm
> doing). Then the transformed array gets printed out. Done. I originally
> thought there was a memory leak but maybe I'm not managing memory right.
> Can I get any wise suggestions from the Akka experts here??
>
>
>
> 
>
>  --
>>> >> Read the docs: http

Re: [akka-user] Sharing message queue between two akka actors?

[Viktor Klang]

Hi Krishna!

On Sat, Jan 10, 2015 at 5:16 PM, Krishna Kadam  wrote:

> HI all akka experts,
>
> I have following questions for you
> 1. Is it possible to share message queue between two akka actors?
>

Yes and no, there's a BalancingRouter, but it's only for that one.


> 2. Is there any effect of increasing number of dispatchers on the message
> processing rate of akka actors?
>

Having multiple dispatchers is about bulkheading different actor subtrees,
not about processing rate (throughput).


> 3. What are the factors that affect the rate of message processing using
> akka Actors?
>

Short answer: Little's Law
Long answer: Depending where the bottleneck is, you may want to tune
dispatcher settings (throughput iso fairness, backing executor service,
number of threads and mailbox implementation).


>
> *Thanks & Regards *
> *Shrikrishna Kadam*
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

[Viktor Klang]

On Wed, Jan 14, 2015 at 2:44 PM, Endre Varga 
wrote:

>
>
> On Fri, Jan 9, 2015 at 10:02 PM, Viktor Klang 
> wrote:
>
>>
>>
>> On Fri, Jan 9, 2015 at 9:40 PM, David Hotham > > wrote:
>>
>>> Of course it's normal and expected that a PriorityQueue returns equal
>>> priority elements in arbitrary order.  That's just how heaps work.  However
>>> that doesn't imply that a mailbox has to do the same thing!
>>>
>>
>> Absolutely, the reordering is not a requirement :) However, silently
>> switching to a new, non-reordering-of-same-priority implementation would
>> risk breaking existing code (that for some reason relies on this behavior).
>>
>
> I disagree, previously the order between same priority entries was
> undefined, and undefined includes that the order is unchanged (the new
> behavior). Just my 2c.
>

The proposed solution has worse performance than the current though. That
would be a regression.


>
> -Endre
>
>
>>
>>
>>>
>>> For instance, I guess that it shouldn't be very hard for the mailbox to
>>> maintain a sequence number that it associates with each message.
>>>
>>
>> Sure! The question is how how big the impact is on memory consumption and
>> performance.
>>
>>
>>> Then it could order messages first according to the comparator that it
>>> currently uses, and second according to the sequence number.  That way it
>>> would return equal priority messages in the same order that it saw them
>>> arrive - which gives exactly the property that I'd hoped for.
>>>
>>
>> Absolutely :)
>>
>>
>>>
>>> I can't tell from your reply whether you think that maintaining order
>>> for equal priority messages is desirable or not.
>>>
>>
>> I think it could be interesting as an alternative to the current version
>> of the PriorityMailbox, or perhaps even as a replacement if it is
>> performing as well as the thing it replaces.
>>
>>
>>>
>>>- If yes, what do you think about an implementation along these
>>>lines?  Is it worth me raising an issue at github?
>>>
>>> I wish I had time to do that, is it something you'd be willing/able to
>> take a stab at? Would love to see something like that.
>>
>>>
>>>- If no, can I at least encourage the Akka maintainers to add an
>>>explicit note to the documentation, so that other users are less likely 
>>> to
>>>fall into my error?
>>>
>>> I think this should be done anyway, since it as you said, and I
>> confirmed, surprising at first. :)
>>
>>
>>
>>> Cheers,
>>>
>>> David
>>>
>>> On Friday, 9 January 2015 19:43:27 UTC, √ wrote:
>>>>
>>>> Hi David,
>>>>
>>>> yes, I can definitely understand that it can be surprising, but I
>>>> wouldn't call it a bug -per se-, since it is not a promise that was
>>>> violated.
>>>>
>>>> If you happen to have, or come by, a performant version of a
>>>> PriorityQueue with the semantics you described, please don't hesitate to
>>>> share it.
>>>>
>>>> On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
>>>> wrote:
>>>>
>>>>> It occurs to me that I wasn't completely clear:
>>>>>
>>>>>- Of course the priority mailbox must break message ordering in
>>>>>some general sense. Else it wouldn't be a priority mailbox at all!
>>>>>- But it is highly surprising to me that it should break ordering
>>>>>for messages of equal priority between a sender-receiver pair.
>>>>>
>>>>>
>>>>> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We've been tracking down a bug in which reading from a TCP stream was
>>>>>> getting all messed up.
>>>>>>
>>>>>> It turns out that we see the problem only when our actor handling
>>>>>> Tcp.Received messages is using an UnboundedPriorityMailbox; the default
>>>>>> mailbox doesn't exhibit any problem.
>>>>>>
>>>>>> I believe that the issue is that the UnboundedPriorityMailbox is
>>>>>> backed by a PriorityBlockingQueue; and that, per the documentation for 
>

Re: [akka-user] WartRemover error on Akka receive methods

[Viktor Klang]

One idea:

def receive = { case => ... } : Receive

(On my phone so may not work)
-- 
Cheers,
√
On 15 Jan 2015 23:06, "javierg"  wrote:

> Hi Konrad,
> Adding the type signature doesn't seem to have any effect
>
> *Error:(31, 26) Inferred type containing Any*
> *  def receive: Receive = {*
> * ^*
>
> I'm aware that WartRemover can be configured.
> I could set this particular wart to be reported as a *warning* and not an
> *error* but that will also make any other (valid) instances to marked as
> such and it's my experience that warnings get, more often than not, "swept
> under the rug" (something I was trying to avoid.)
> Still, like you mentioned, there doesn't seem to be a solution for this at
> the moment. I just wanted to be sure I wasn't missing something obvious.
> Many thanks for the prompt reply.
>
>
>
> On Thursday, January 15, 2015 at 4:32:47 PM UTC-5, Konrad Malawski wrote:
>>
>> Hello there,
>> As I understand it, wart-remover is configurable to which "warts” it
>> should be reporting.
>>
>> In the case of Actor.Receive it’s not happy because it is an alias to Any
>> => Unit.
>> Without a large philosophical dive why it is such and not a different
>> signature (and btw. Roland will soon soon get a new impl ot akka.typed out
>> for preview ;-)),
>> let’s address your problem and question at hand.
>>
>> Two solutions come to mind:
>> 1) Since the wart is triggered for “inferred type contains Any”, you can
>> write the type explicitly (def receive: Receive = …) instead of it being
>> inferred I assume? (Did not try that though)
>>
>> 2) As seen on: https://github.com/puffnfresh/wartremover these warts can
>> be enabled / disabled at will.
>> warts can be configured and in your case you’d like to keep all “except
>> inferred type contains Any”,
>> so you could use:
>>
>> wartremoverErrors := Warts.allBut(Wart.Any)
>>
>> which should make it happy on receive methods.
>>
>>
>> Hope this helps!
>> Disclaimer: I did not try this, but it seems to all logically fall into
>> place :-)
>>
>> --
>> Konrad 'ktoso’ Malawski
>> Akka  @ Typesafe 
>>
>> On 15 January 2015 at 22:24:00, javierg (javie...@gmail.com) wrote:
>>
>> Hi all,
>> Apologies for the more than slightly offtopic question.
>> I recently started using WartRemover and one of the first things that I
>> encountered is a barrage of error notifications like what follows (for, as
>> long as I can see, every receive method in my codebase)
>>
>> *Error:(31, 7) Inferred type containing Any*
>> *  def receive = {*
>> *  ^*
>>  Before WartRemover this code used to compile (and run) without issues.
>> WartRemover claims it doesn't report false positives, but I'm getting this
>> error on cases as simple and trivial as the following (admittedly
>> contrived) example
>>
>> *def receive = {*
>> *case a:String => log.info (a)*
>> *case _ => log.info ("Unexpected input")*
>> *} *
>>
>> Is there a way to solve this (other than asking WartRemover to not report
>> this)?
>> Thanks in advance,
>>
>> Javier
>>
>>
>>  --
>> >> 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.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  --
> >> 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.
>

-- 
>>  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

Re: [akka-user] Dispatcher assignment issue for Http Server

[Viktor Klang]

Hi Randy,

What makes you say it doesn't respect your core pool size?

-- 
Cheers,
√
On 16 Jan 2015 02:34, "Randy Fox"  wrote:

> I am trying to assign a dispatcher to be used for my http server (using
> the new Akka HTTP Server) and can’t get it to honor my pool size settings.
> Logs show it is using the dispatcher, but visualvm shows it is not using
> the core pool size settings.   Loos like it might be using the defaults for
> a thread-pool-executor.
>
>
> All I did was modify the example:
>
>1. import akka.http.Http
>2. import akka.stream.FlowMaterializer
>3.
>4. implicit val system = ActorSystem()
>5. implicit val materializer = FlowMaterializer(*MaterializerSettings*(
>*system*).withDispatcher(*“myhttpRequestHandler.dispatcher"*))
>6.
>7. val serverBinding = Http(system).bind(interface = "localhost", port
>= 8080)
>8. serverBinding.connections.foreach { connection => // foreach
>materializes the source
>9.   println("Accepted new connection from " +
>connection.remoteAddress)
>10. }
>11. …
>
> myhttpRequestHandler {
>
>   dispatcher {
>
> type = Dispatcher
>
> executor = *"thread-pool-executor"*
>
> name = httprequesthandler-dispatcher
>
> thread-pool-executor {
>
>   core-pool-size-min = 100
>
>   core-pool-size-factor = 2.0
>
>   core-pool-size-max = 100
>
> }
>
> throughput = 5
>
>   }
>
> }
>
> [INFO] [2015-01-15 17:24:27,516] [DUDE-myhttpRequestHandler.dispatcher-79]
> HttpRequestHandler(akka://DUDE): Accepted new connection from /
> 127.0.0.1:54046
>
> What am I missing?
>
> Thanks,
>
> Randy Fox
>
> --
> >> 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.
>

-- 
>>  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.

Re: [akka-user] Re: Dispatcher assignment issue for Http Server

[Viktor Klang]

Alright. Did you manage to sort it out?

-- 
Cheers,
√
On 16 Jan 2015 16:56, "Randy Fox"  wrote:

> I expected the thread pool to be pegged at 100 threads, but watching in
> visual vm showed 24 threads (default).  Poking around the object structure
> in the debugger, I found nested deep under the flowmaterializer was a
> maxsize of 64 (also default).
>
> -r
>
> On Thursday, January 15, 2015 at 5:34:05 PM UTC-8, Randy Fox wrote:
>>
>> I am trying to assign a dispatcher to be used for my http server (using
>> the new Akka HTTP Server) and can’t get it to honor my pool size settings.
>> Logs show it is using the dispatcher, but visualvm shows it is not using
>> the core pool size settings.   Loos like it might be using the defaults for
>> a thread-pool-executor.
>>
>>
>> All I did was modify the example:
>>
>>1. import akka.http.Http
>>2. import akka.stream.FlowMaterializer
>>3.
>>4. implicit val system = ActorSystem()
>>5. implicit val materializer = FlowMaterializer(*MaterializerSettings*
>>(*system*).withDispatcher(*“myhttpRequestHandler.dispatcher"*))
>>6.
>>7. val serverBinding = Http(system).bind(interface = "localhost",
>>port = 8080)
>>8. serverBinding.connections.foreach { connection => // foreach
>>materializes the source
>>9.   println("Accepted new connection from " +
>>connection.remoteAddress)
>>10. }
>>11. …
>>
>> myhttpRequestHandler {
>>
>>   dispatcher {
>>
>> type = Dispatcher
>>
>> executor = *"thread-pool-executor"*
>>
>> name = httprequesthandler-dispatcher
>>
>> thread-pool-executor {
>>
>>   core-pool-size-min = 100
>>
>>   core-pool-size-factor = 2.0
>>
>>   core-pool-size-max = 100
>>
>> }
>>
>> throughput = 5
>>
>>   }
>>
>> }
>>
>> [INFO] [2015-01-15 17:24:27,516] [DUDE-myhttpRequestHandler.dispatcher-79]
>> HttpRequestHandler(akka://DUDE): Accepted new connection from /
>> 127.0.0.1:54046
>>
>> What am I missing?
>>
>> Thanks,
>>
>> Randy Fox
>>
>  --
> >> 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.
>

-- 
>>  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.

Re: [akka-user] received Supervise from unregistered child ... this will not end well

[Viktor Klang]

Have you closed over "context.actorOf" and execute it within a Future or
similar?

On Tue, Jan 20, 2015 at 6:47 PM, Marco Luca Sbodio 
wrote:

> Hello everyone,
>
> while testing my system I'm randomly getting error messages similar to the
> one in the subject of this topic. Here's an example:
>
> 17:27:59.265UTC ERROR
> [MySystemMultiNodeTest-akka.actor.default-dispatcher-16]
> [org.mysystem.actor.Worker]
> [akka://MySystemMultiNodeTest/user/the-engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe604/planner/sub-planner-951/worker0]
> - received Supervise from unregistered child Actor[akka.tcp://
> mysystemmultinodet...@nd06.domain.com:3002/remote/akka.tcp/mysystemmultinodet...@nd03.domain.com:3001/user/the-engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe604/planner/sub-planner-951/worker0/worker1.4#-430862452],
> this will not end well
>
> I really have no clue what might cause these errors, and what the
> consequences are ("this will not end well"). I've tried searching on the
> Web, but didn't find anything that helped me.
>
> I'm using akka 2.2.3
>
> Any help is highly appreciated!
>
> Thanks,
> Marco
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: Dispatcher assignment issue for Http Server

[Viktor Klang]

Could you put together a minimized reproducer?

On Tue, Jan 20, 2015 at 5:21 PM, Randy Fox  wrote:

> Nope.  Did I find a bug or am i doing something wrong?
>
> On Saturday, January 17, 2015 at 1:21:12 PM UTC-8, √ wrote:
>>
>> Alright. Did you manage to sort it out?
>>
>> --
>> Cheers,
>> √
>> On 16 Jan 2015 16:56, "Randy Fox"  wrote:
>>
>>> I expected the thread pool to be pegged at 100 threads, but watching in
>>> visual vm showed 24 threads (default).  Poking around the object structure
>>> in the debugger, I found nested deep under the flowmaterializer was a
>>> maxsize of 64 (also default).
>>>
>>> -r
>>>
>>> On Thursday, January 15, 2015 at 5:34:05 PM UTC-8, Randy Fox wrote:

 I am trying to assign a dispatcher to be used for my http server (using
 the new Akka HTTP Server) and can’t get it to honor my pool size settings.
 Logs show it is using the dispatcher, but visualvm shows it is not using
 the core pool size settings.   Loos like it might be using the defaults for
 a thread-pool-executor.


 All I did was modify the example:

1. import akka.http.Http
2. import akka.stream.FlowMaterializer
3.
4. implicit val system = ActorSystem()
5. implicit val materializer = FlowMaterializer(
*MaterializerSettings*(*system*).withDispatcher(
*“myhttpRequestHandler.dispatcher"*))
6.
7. val serverBinding = Http(system).bind(interface = "localhost",
port = 8080)
8. serverBinding.connections.foreach { connection => // foreach
materializes the source
9.   println("Accepted new connection from " +
connection.remoteAddress)
10. }
11. …

 myhttpRequestHandler {

   dispatcher {

 type = Dispatcher

 executor = *"thread-pool-executor"*

 name = httprequesthandler-dispatcher

 thread-pool-executor {

   core-pool-size-min = 100

   core-pool-size-factor = 2.0

   core-pool-size-max = 100

 }

 throughput = 5

   }

 }

 [INFO] [2015-01-15 17:24:27,516] [DUDE-myhttpRequestHandler.dispatcher-79]
 HttpRequestHandler(akka://DUDE): Accepted new connection from /
 127.0.0.1:54046

 What am I missing?

 Thanks,

 Randy Fox

>>>  --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Cluster unreachable and a lot of cluster connections

[Viktor Klang]

Hi Johannes,

see the news item: http://akka.io/news/2015/01/19/akka-2.3.9-released.html

On Wed, Jan 21, 2015 at 4:47 PM, Johannes Berg  wrote:

> Upgrading to 2.3.9 does indeed seem to solve my problem. At least I
> haven't experienced them yet.
>
> Now I'm curious what the fixes were, is there somewhere a change summary
> between versions or where is it listed what bugs have been fixed in which
> versions?
>
> On Wednesday, January 21, 2015 at 11:31:02 AM UTC+2, drewhk wrote:
>>
>> Hi Johannes,
>>
>> We just released 2.3.9 with important bugfixes. I recommend to update and
>> see if the problem is still persisting.
>>
>> -Endre
>>
>> On Wed, Jan 21, 2015 at 10:29 AM, Johannes Berg 
>> wrote:
>>
>>> Many connections seem to be formed in the case when the node has been
>>> marked down for unreachability even though it's still alive and it tries to
>>> connect back into the cluster. The removed node prints:
>>>
>>> "Address is now gated for 5000 ms, all messages to this address will be
>>> delivered to dead letters. Reason: The remote system has quarantined this
>>> system. No further associations to the remote system are possible until
>>> this system is restarted."
>>>
>>> It doesn't seem to close the connections properly even though it opens
>>> new ones continously.
>>>
>>> Anyway that's a separate issue that I'm not that concerned about right
>>> now, I've now realized I don't want to use automatic downing instead I
>>> would like to allow nodes to go unreachable and come back to reachable even
>>> if it takes quite some time and manually stopping the process and downing
>>> the node in case of an actual crash.
>>>
>>> Consequently I've put
>>>
>>> auto-down-unreachable-after = off
>>>
>>> in the config. Now I have the problem that nodes still are removed, this
>>> is from the leader node log:
>>>
>>> 08:50:14.087UTC INFO [system-akka.actor.default-dispatcher-4]
>>> Cluster(akka://system) - Cluster Node [akka.tcp://system@ip1:port1] -
>>> Leader is removing unreachable node [akka.tcp://system@ip2:port2]
>>>
>>> I can understand my node is marked unreachable beause it's under heavy
>>> load but I don't understand what could cause it to be removed. I'm not
>>> doing any manual downing and have the auto-down to off, what else could
>>> trigger the removal?
>>>
>>> Using the akka-cluster script I can see that the node has most other
>>> nodes marked as unreachable (including the leader) and that it has another
>>> leader than other nodes.
>>>
>>> My test system consists of 8 nodes.
>>>
>>> About the unreachability I'm not having long GC pauses and not sending
>>> large blobs, but I'm sending very many smaller messages as fast as I can.
>>> If I just hammer it fast enough it will end up unreachable which I can
>>> except, but I need to get it back to reachable.
>>>
>>> On Thursday, December 11, 2014 at 11:22:41 AM UTC+2, Björn Antonsson
>>> wrote:

 Hi Johannes,

 On 9 December 2014 at 15:29:53, Johannes Berg (jber...@gmail.com)
 wrote:

 Hi! I'm doing some load tests in our system and getting problems that
 some of my nodes are marked as unreachable even though the processes are
 up. I'm seeing it going a few times from reachable to unreachable and back
 a few times before staying unreachable saying connection gated for 5000ms
 and staying silently that way.

 Looking at the connections made to one of the seed nodes I see that I
 have several hundreds of connections from other nodes except the failing
 ones. Is this normal? There are several (hundreds) just between two nodes.
 When are connections formed between cluster nodes and when are they taken
 down?


 Several hundred connections between two nodes seems very wrong. There
 should only be one connection between two nodes that communicate over akka
 remoting or are part of a cluster. How many nodes do you have in your
 cluster?

 If you are using cluster aware routers then there should be one
 connection between the router node and the rooutee nodes (can be the same
 connection that is used for the cluster communication).

 The connections between the nodes don't get torn down, they stay open,
 but they are reused for all remoting communication between the nodes.

 Also is there some limit on how many connections a node with default
 settings will accept?

 We have auto-down-unreachable-after = 10s set in our config, does this
 mean if the node is busy and doesn't respond in 10 seconds it becomes
 unreachable?

 Is there any reason why it would stay unreachable and not re-try to
 join the cluster?


 The auto down, setting is actually just what it says. I the node is
 considered unreachable for 10 seconds, it will be moved to DOWN and won't
 be able to come back into the cluster. The different states of the cluster
 and the settings are explained in the documentation.
>>

Re: [akka-user] received Supervise from unregistered child ... this will not end well

[Viktor Klang]

Hi Marco,

Please upgrade to 2.3.9 if you haven't already, there was a couple of
remoting-related issues fixed there.

On Wed, Jan 21, 2015 at 6:45 PM, Marco Luca Sbodio 
wrote:

> I haven't.
>
> I've managed to figure out that sometimes the following code
>
> [[
> int nextStepNumber = planSteps[0].getStepNumber();
> Address nextAddress = planSteps[0].getPeer().getAddress();
> PlanStep[] nextPlanSteps = new PlanStep[planSteps.length];
> System.arraycopy(planSteps, 0, nextPlanSteps, 0,
> planSteps.length);
> firstWorker = getContext().actorOf(
> Worker.mkProps(sink, nextPlanSteps).withDeploy(new
> Deploy(new RemoteScope(nextAddress))),
> Worker.actorName + nextStepNumber);
> firstWorker.tell(CommonApi.START, getSelf());
> log.debug("started first worker");
> Chunk chunk = new Chunk(0, new byte[] {});
> firstWorker.tell(chunk, getSelf());
> log.debug("empty chunk sent to first worker");
> ]]
>
> generate such an error:
>
> [[
> 17:20:08.195UTC ERROR
> [MySystemMultiNodeTest-akka.actor.default-dispatcher-16]
> [org.mysystem.actor.SubPlanner]
> [akka://MySystemMultiNodeTest/user/the-engine/executor-6eb81c68-e91d-47cd-bb26-be53eee90f63/planner/sub-planner-11]
> - received Supervise from unregistered child Actor[akka.tcp://
> mysystemmultinodet...@nd06.domain.com:3002/remote/akka.tcp/mysystemmultinodet...@nd03.domain.com:3001/user/the-engine/executor-6eb81c68-e91d-47cd-bb26-be53eee90f63/planner/sub-planner-11/worker0#-1680645824],
> this will not end well
> ]]
>
> tracing back "sub-planner-11" in my logs I find the two messages
> log.debug("started first worker");
> firstWorker.tell(chunk, getSelf());
>
> and then I get the error ... and I have no clue why
>
> Thank you in advance for any help/suggestion.
>
> Cheers,
> Marco
>
> On Tuesday, 20 January 2015 18:12:08 UTC, √ wrote:
>>
>> Have you closed over "context.actorOf" and execute it within a Future or
>> similar?
>>
>> On Tue, Jan 20, 2015 at 6:47 PM, Marco Luca Sbodio 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> while testing my system I'm randomly getting error messages similar to
>>> the one in the subject of this topic. Here's an example:
>>>
>>> 17:27:59.265UTC ERROR 
>>> [MySystemMultiNodeTest-akka.actor.default-dispatcher-16]
>>> [org.mysystem.actor.Worker] [akka://MySystemMultiNodeTest/
>>> user/the-engine/executor-7b7690ee-f31d-45f1-93ef-
>>> 79cba01fe604/planner/sub-planner-951/worker0] - received Supervise from
>>> unregistered child Actor[akka.tcp://MySystemMulti
>>> nodet...@nd06.domain.com:3002/remote/akka.tcp/
>>> mysystemmultinodet...@nd03.domain.com:3001/user/the-
>>> engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe604/
>>> planner/sub-planner-951/worker0/worker1.4#-430862452], this will not
>>> end well
>>>
>>> I really have no clue what might cause these errors, and what the
>>> consequences are ("this will not end well"). I've tried searching on the
>>> Web, but didn't find anything that helped me.
>>>
>>> I'm using akka 2.2.3
>>>
>>> Any help is highly appreciated!
>>>
>>> Thanks,
>>> Marco
>>>
>>> --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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 a

Re: [akka-user] received Supervise from unregistered child ... this will not end well

[Viktor Klang]

Hi Marco,

you'll need to update all Akka dependencies to the 2.3.9 version and make
sure that your dependencies that depend on akka transitively are built for
Akka 2.3.x

On Thu, Jan 22, 2015 at 11:57 AM, Marco Luca Sbodio 
wrote:

> Hi Viktor,
>
> after upgrading to akka 2.3.9 my multi-jvm-test crashes with this error:
>
> 10:49:07.654UTC ERROR
> [MySystemMultiNodeTest-akka.actor.default-dispatcher-21]
> [akka.actor.ActorSystemImpl] [ActorSystem(MySystemMultiNodeTest)] -
> Uncaught error from thread
> [MySystemMultiNodeTest-akka.actor.default-dispatcher-21] shutting down JVM
> since 'akka.jvm-exit-on-fatal-error' is enabled
> java.lang.AbstractMethodError: akka/actor/Actor.aroundPreStart()V
> at akka.actor.ActorCell.create(ActorCell.scala:580)
> ~[akka-actor_2.10-2.3.9.jar:na]
> at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:456)
> ~[akka-actor_2.10-2.3.9.jar:na]
> at akka.actor.ActorCell.systemInvoke(ActorCell.scala:478)
> ~[akka-actor_2.10-2.3.9.jar:na]
> at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:279)
> [akka-actor_2.10-2.3.9.jar:na]
> at akka.dispatch.Mailbox.run(Mailbox.scala:220)
> [akka-actor_2.10-2.3.9.jar:na]
> at akka.dispatch.Mailbox.exec(Mailbox.scala:231)
> [akka-actor_2.10-2.3.9.jar:na]
> at
> scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
> [scala-library-2.10.4.jar:na]
> at
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
> [scala-library-2.10.4.jar:na]
> at
> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> [scala-library-2.10.4.jar:na]
> at
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
> [scala-library-2.10.4.jar:na]
>
> Has something change with multi-jvm/multi-node testing from akka 2.2.4 to
> akka 2.3.9?
> Any clue?
>
> Thank you in advance,
> Marco
>
> On Wednesday, 21 January 2015 19:15:51 UTC, √ wrote:
>>
>> Hi Marco,
>>
>> Please upgrade to 2.3.9 if you haven't already, there was a couple of
>> remoting-related issues fixed there.
>>
>> On Wed, Jan 21, 2015 at 6:45 PM, Marco Luca Sbodio 
>> wrote:
>>
>>> I haven't.
>>>
>>> I've managed to figure out that sometimes the following code
>>>
>>> [[
>>> int nextStepNumber = planSteps[0].getStepNumber();
>>> Address nextAddress = planSteps[0].getPeer().
>>> getAddress();
>>> PlanStep[] nextPlanSteps = new
>>> PlanStep[planSteps.length];
>>> System.arraycopy(planSteps, 0, nextPlanSteps, 0,
>>> planSteps.length);
>>> firstWorker = getContext().actorOf(
>>> Worker.mkProps(sink,
>>> nextPlanSteps).withDeploy(new Deploy(new RemoteScope(nextAddress))),
>>> Worker.actorName + nextStepNumber);
>>> firstWorker.tell(CommonApi.START, getSelf());
>>> log.debug("started first worker");
>>> Chunk chunk = new Chunk(0, new byte[] {});
>>>
>>> firstWorker.tell(chunk, getSelf());
>>> log.debug("empty chunk sent to first worker");
>>> ]]
>>>
>>> generate such an error:
>>>
>>> [[
>>> 17:20:08.195UTC ERROR 
>>> [MySystemMultiNodeTest-akka.actor.default-dispatcher-16]
>>> [org.mysystem.actor.SubPlanner] [akka://MySystemMultiNodeTest/
>>> user/the-engine/executor-6eb81c68-e91d-47cd-bb26-
>>> be53eee90f63/planner/sub-planner-11] - received Supervise from
>>> unregistered child Actor[akka.tcp://MySystemMulti
>>> nodet...@nd06.domain.com:3002/remote/akka.tcp/
>>> mysystemmultinodet...@nd03.domain.com:3001/user/the-
>>> engine/executor-6eb81c68-e91d-47cd-bb26-be53eee90f63/
>>> planner/sub-planner-11/worker0#-1680645824], this will not end well
>>> ]]
>>>
>>> tracing back "sub-planner-11" in my logs I find the two messages
>>> log.debug("started first worker");
>>> firstWorker.tell(chunk, getSelf());
>>>
>>> and then I get the error ... and I have no clue why
>>>
>>> Thank you in advance for any help/suggestion.
>>>
>>> Cheers,
>>> Marco
>>>
>>> On Tuesday, 20 January 2015 18:12:08 UTC, √ wrote:

 Have you closed over "context.actorOf" and execute it within a Future
 or similar?

 On Tue, Jan 20, 2015 at 6:47 PM, Marco Luca Sbodio >>> > wrote:

> Hello everyone,
>
> while testing my system I'm randomly getting error messages similar to
> the one in the subject of this topic. Here's an example:
>
> 17:27:59.265UTC ERROR 
> [MySystemMultiNodeTest-akka.actor.default-dispatcher-16]
> [org.mysystem.actor.Worker] [akka://MySystemMultiNodeTest/
> user/the-engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe60
> 4/planner/sub-planner-951/worker0] - received Supervise from
> unregistered child Actor[akka.tcp://MySystemMulti
> nodet...@nd06.domain.com:3002/remote/akka.tcp/MySystemMultiN
> odet...@nd03.domain.com:3001/user/the-engine/executor-7b7690ee-f31d-
> 45f1-93ef-79cba01fe60

Re: [akka-user] Cluster unreachable and a lot of cluster connections

[Viktor Klang]

Endre, could it be due to pending-to-send system message overflow?

On Thu, Jan 22, 2015 at 11:45 AM, Johannes Berg  wrote:

> Okay, I increased the load further and now I see the same problem again.
> It seems to just have gotten a bit better in that it doesn't happen as
> fast, but with enough load it happens.
>
> To re-iterate, I have Akka 2.3.9 on all (8) nodes and
> auto-down-unreachable-after = off on all nodes and I don't do any manual
> downing anywhere, still the leader log prints this:
>
> 2015-01-22 10:35:37 + - [INFO] - from Cluster(akka://system) in
> system-akka.actor.default-dispatcher-2
> Cluster Node [akka.tcp://system@ip1:port1] - Leader is removing
> unreachable node [akka.tcp://system@ip2:port2]
>
> and the node(s) under load is(are) removed from the cluster (quarantined).
> How is this possible?
>
> On Wednesday, January 21, 2015 at 5:53:06 PM UTC+2, drewhk wrote:
>>
>> Hi Johannes,
>>
>> See the milestone here: https://github.com/akka/
>> akka/issues?q=milestone%3A2.3.9+is%3Aclosed
>>
>> The tickets cross reference the PRs, too, so you can look at the code
>> changes. The issue that probably hit you is https://github.com/akka/
>> akka/issues/16623 which manifested as system message delivery errors on
>> some systems, but actually was caused by accidentally duplicated internal
>> actors (a regression).
>>
>> -Endre
>>
>> On Wed, Jan 21, 2015 at 4:47 PM, Johannes Berg  wrote:
>>
>>> Upgrading to 2.3.9 does indeed seem to solve my problem. At least I
>>> haven't experienced them yet.
>>>
>>> Now I'm curious what the fixes were, is there somewhere a change summary
>>> between versions or where is it listed what bugs have been fixed in which
>>> versions?
>>>
>>> On Wednesday, January 21, 2015 at 11:31:02 AM UTC+2, drewhk wrote:

 Hi Johannes,

 We just released 2.3.9 with important bugfixes. I recommend to update
 and see if the problem is still persisting.

 -Endre

 On Wed, Jan 21, 2015 at 10:29 AM, Johannes Berg 
 wrote:

> Many connections seem to be formed in the case when the node has been
> marked down for unreachability even though it's still alive and it tries 
> to
> connect back into the cluster. The removed node prints:
>
> "Address is now gated for 5000 ms, all messages to this address will
> be delivered to dead letters. Reason: The remote system has quarantined
> this system. No further associations to the remote system are possible
> until this system is restarted."
>
> It doesn't seem to close the connections properly even though it opens
> new ones continously.
>
> Anyway that's a separate issue that I'm not that concerned about right
> now, I've now realized I don't want to use automatic downing instead I
> would like to allow nodes to go unreachable and come back to reachable 
> even
> if it takes quite some time and manually stopping the process and downing
> the node in case of an actual crash.
>
> Consequently I've put
>
> auto-down-unreachable-after = off
>
> in the config. Now I have the problem that nodes still are removed,
> this is from the leader node log:
>
> 08:50:14.087UTC INFO [system-akka.actor.default-dispatcher-4]
> Cluster(akka://system) - Cluster Node [akka.tcp://system@ip1:port1] -
> Leader is removing unreachable node [akka.tcp://system@ip2:port2]
>
> I can understand my node is marked unreachable beause it's under heavy
> load but I don't understand what could cause it to be removed. I'm not
> doing any manual downing and have the auto-down to off, what else could
> trigger the removal?
>
> Using the akka-cluster script I can see that the node has most other
> nodes marked as unreachable (including the leader) and that it has another
> leader than other nodes.
>
> My test system consists of 8 nodes.
>
> About the unreachability I'm not having long GC pauses and not sending
> large blobs, but I'm sending very many smaller messages as fast as I can.
> If I just hammer it fast enough it will end up unreachable which I can
> except, but I need to get it back to reachable.
>
> On Thursday, December 11, 2014 at 11:22:41 AM UTC+2, Björn Antonsson
> wrote:
>>
>> Hi Johannes,
>>
>> On 9 December 2014 at 15:29:53, Johannes Berg (jber...@gmail.com)
>> wrote:
>>
>> Hi! I'm doing some load tests in our system and getting problems that
>> some of my nodes are marked as unreachable even though the processes are
>> up. I'm seeing it going a few times from reachable to unreachable and 
>> back
>> a few times before staying unreachable saying connection gated for 5000ms
>> and staying silently that way.
>>
>> Looking at the connections made to one of the seed nodes I see that I
>> have several hundreds of connections from other nodes except the failing
>> ones. Is

Re: [akka-user] [akka-stream] Prebuilt Source with simple synchronous API

[Viktor Klang]

Hi Alexey,

On Sat, Jan 24, 2015 at 11:20 AM, Alexey Romanchuk <
alexey.romanc...@gmail.com> wrote:

> Hey hakkers,
>
> I wonder why there is not such prebuilt Source that provides API to
> externally emit message by simple method call. I am talking about something
> like this:
>
> //building and starting flow
> val flow = ???
> val source = ExternalSource[String]
> source.via(flow).to(BlackholeSink).run
>
> //using source
> source.emit("")
>

What would happen if it can't?


> source.complete()
> source.error(new Exception)
>
> It can be implemented manually using actor, buffer inside it and exposing
> some object that internally sends message to this actor. I think this
> source can be very useful in case of integration with external API.
>

I agree, I think something like this could be quite useful, the "problem"
is getting the API right.


>
> Thanks
>
> p.s. Sure, we can not directly use ExternalSource to emit objects, but
> should use some object created during flow materialization, like PropSource
> does.
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Acceptable Limits for Actor Creation and Destruction?

[Viktor Klang]

Hi Paul,

There's also the question if they are spawned under the same parent or not.

On Mon, Jan 26, 2015 at 5:07 PM, Paul Cleary  wrote:

> Thank your for the reply,
>
> These machines are typically 4 core / 8 GB machines with only our app
> running.  The only JVM settings are CMS and Parallel Young Generation.
> Also Java 1.7, Scala 2.11, Play 2.3.
>
> We have not benchmarked the actors themselves, as there are several actors
> in the system.  The other actors are more permanent, with the FSM actor
> being the short lived one.
>
> My question was more of, is there guidance (JVM or Akka tuning, vm specs)
> in this scenario w.r.t. to VM sizing / JVM args based on a "50,000 or
> 100,000 actor per second" kind of model?
>
> The benchmark is an interesting idea.  I could write an alternative
> implementation that did not use FSMs are actors at all, and then run our
> perf tests to see what the impact would be.
>
>
> On Monday, January 26, 2015 at 8:24:54 AM UTC-5, Björn Antonsson wrote:
>>
>> Hi Paul,
>>
>> There are a lot of moving parts in creating an actor, and the associated
>> costs. What is a lot of garbage? It's a completely subjective question.
>> Also, depending on the size of your machine, 5 actors per second might
>> be easy, or not possible.
>>
>> Have you tried to benchmark the creation of your actors?
>>
>> B/
>>
>> On 21 January 2015 at 14:35:53, Paul Cleary (pcle...@gmail.com) wrote:
>>
>> I have an application where we are creating and destroying "a lot" of
>> actors.  The amount of actors that are created is tied to the volume of
>> requests on the application.
>>
>> I am using FSM for the Actor in question here.
>>
>> I do not fully understand what is involved with the setup / teardown of
>> an individual actor, so that is part of the motivation for the question.
>>
>> Is it "reasonable" to be creating 10s of thousands of these FSM instances
>> per second (say 50,000 actors create and destroyed every second)?
>>
>> Is there an upper limit that I should look at?
>>
>> Will this result in a lot of garbage?
>>
>> Thanks for the help!
>>  --
>> >> 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.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Björn Antonsson
>> Typesafe  – Reactive Apps on the JVM
>> twitter: @bantonsson 
>>
>>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Acceptable Limits for Actor Creation and Destruction?

[Viktor Klang]

Hi Paul,

you may want to put the parent on a different dispatcher than the children,
since the creation process is a handshake. (so both parent and child needs
CPU time)

On Mon, Jan 26, 2015 at 5:49 PM, Paul Cleary  wrote:

> Victor,
> Yes, they are spawned under the same parent (same actual actor ref).  The
> parent is "long-lived", i.e. intended to hang around for the lifetime of
> the process.
>
> On Monday, January 26, 2015 at 11:14:40 AM UTC-5, √ wrote:
>>
>> Hi Paul,
>>
>> There's also the question if they are spawned under the same parent or
>> not.
>>
>> On Mon, Jan 26, 2015 at 5:07 PM, Paul Cleary  wrote:
>>
>>> Thank your for the reply,
>>>
>>> These machines are typically 4 core / 8 GB machines with only our app
>>> running.  The only JVM settings are CMS and Parallel Young Generation.
>>> Also Java 1.7, Scala 2.11, Play 2.3.
>>>
>>> We have not benchmarked the actors themselves, as there are several
>>> actors in the system.  The other actors are more permanent, with the FSM
>>> actor being the short lived one.
>>>
>>> My question was more of, is there guidance (JVM or Akka tuning, vm
>>> specs) in this scenario w.r.t. to VM sizing / JVM args based on a "50,000
>>> or 100,000 actor per second" kind of model?
>>>
>>> The benchmark is an interesting idea.  I could write an alternative
>>> implementation that did not use FSMs are actors at all, and then run our
>>> perf tests to see what the impact would be.
>>>
>>>
>>> On Monday, January 26, 2015 at 8:24:54 AM UTC-5, Björn Antonsson wrote:

 Hi Paul,

 There are a lot of moving parts in creating an actor, and the
 associated costs. What is a lot of garbage? It's a completely subjective
 question. Also, depending on the size of your machine, 5 actors per
 second might be easy, or not possible.

 Have you tried to benchmark the creation of your actors?

 B/

 On 21 January 2015 at 14:35:53, Paul Cleary (pcle...@gmail.com) wrote:

 I have an application where we are creating and destroying "a lot" of
 actors.  The amount of actors that are created is tied to the volume of
 requests on the application.

 I am using FSM for the Actor in question here.

 I do not fully understand what is involved with the setup / teardown of
 an individual actor, so that is part of the motivation for the question.

 Is it "reasonable" to be creating 10s of thousands of these FSM
 instances per second (say 50,000 actors create and destroyed every second)?


 Is there an upper limit that I should look at?

 Will this result in a lot of garbage?

 Thanks for the help!
  --
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ: http://doc.akka.io/docs/akka/c
 urrent/additional/faq.html
 >> Search the archives: https://groups.google.com/grou
 p/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.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


 --
 Björn Antonsson
 Typesafe  – Reactive Apps on the JVM
 twitter: @bantonsson 

  --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>

Re: [akka-user] [Akka-2.3.7][Scala] - akka.remote.EndpointWriter

[Viktor Klang]

Hi Yarden,

please upgrade to the latest bugfix release for the given major version
(2.3.9 for 2.3 for instance).

http://akka.io/news/2015/01/19/akka-2.3.9-released.html

On Tue, Jan 27, 2015 at 8:50 AM, Yarden Bar  wrote:

> Hi All,
> I recently upgraded my application Akka version from 2.2.4 to 2.3.7.
>
> Since then I started seeing messages like this:
> akka.remote.EndpointWriter Drained buffer with maxWriteCount: 50,
> fullBackoffCount: 1, smallBackoffCount: 1, noBackoffCount: 0 ,
> adaptiveBackoff: 2000
>
> Google-ing about this subject sent me to a couple of articles in chineese.
>
> Can anyone shed some light on this EndpointWriter or the scenarios for
> getting the above message?
>
>
> Thanks,
> Yarden
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Simple, local, garbage collected actors

[Viktor Klang]

Hi Arek,

We used to do it like that about 5 years ago:
https://github.com/akka/akka/blob/v0.8.1/akka-core/src/main/scala/actor/Actor.scala#L105

:)

On Tue, Jan 27, 2015 at 10:07 AM, Arkadiusz Burdach 
wrote:

> Hi all.
>
> What do you think about an idea of module providing possibility to create
> actor by *new* operator eg.
>
> val actor = new SimpleActor {
>   override def receive: Receive = {
> case _ => sender() ! "OK"
>   }
> }
>
>
> Those actors would be garbage collected so there will be no need to send
> PoisonPIll them.
>
> I've prepared proof of concept: https://github.com/arkadius/akka-simple
>
> It will be usefull? Or maybe there is already other way to use this kind
> of syntax of actors?
>
> Arek
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: Addressing paths to cluster peers

[Viktor Klang]

Hi Mark,

The "user" section means that it is for actors spawned by a user, and not
by the system itself, for example.

On Mon, Jan 26, 2015 at 8:44 PM, Mark Grey  wrote:

> I got this addressing to work using the path below:
>
> ActorPath path = new RootActorPath(mUp.member().address(),
>> "/").descendant(Arrays.asList("user","orchestrator"));
>>
>
> I'm curious why this would make a difference?  Also, where does the "user"
> section of the path come from and what is it's purpose in akka-cluster?
> Thanks!
>
> On Monday, January 26, 2015 at 12:00:53 AM UTC-5, Mark Grey wrote:
>>
>> Hello guys,
>>
>> I have a use case that is somewhat unique for akka-cluster that I'm
>> trying to get to work.  Hopefully someone can point out what I'm doing
>> wrong.
>>
>> In my clustered app, an actor called an Orchestrator is started many
>> times, once per running member node.  These orchestrators are subscribed to
>> member events like MemberUp.  My intention is to have the orchestrator
>> communicate peer to peer.
>>
>> My problem is I can't seem to figure out how to do remote path addressing
>> between the peer orchestrators.  Nodes are joining the cluster okay, but I
>> can't get the right address out of MemberUp.member().address() for one
>> orchestrator to exchange messages with another.  For example:
>>
>> if (message instanceof ClusterEvent.MemberUp){
>>> ClusterEvent.MemberUp mUp = (ClusterEvent.MemberUp) message;
>>> Boolean isSelf = mUp.member().address().
>>> hostPort().equals(cluster.selfAddress().hostPort());
>>> String path = mUp.member().uniqueAddress().address().toString();
>>> String salt = Integer.toString(mUp.member().
>>> uniqueAddress().uid());
>>> context().actorSelection(path + "/orchestrator").tell(new
>>> Messages.AreYouAlive(), getSelf());
>>> }
>>
>>
>> Using this code in the orchestrator actor seems to result in all
>> AreYouAlive messages to be delivered to deadletters.  The peers are
>> definitely connected (I can see the Leader logs moving the to up.)
>>
>> I noticed that the dead letters delivery shows a mixture of remote
>> (akka.tcp) and local (akka://) paths:
>>
>> Message [AreYouAlive] from 
>> Actor[akka://actor-system/user/orchestrator#296853392]
>>> to Actor[akka://actor-system/orchestrator] was not delivered.
>>>
>>
>> Is there any way to address between identical actor instances in a peer
>> cluster like this?  I've tried mixing out the UID from the UniqueAddress
>> enclosed in MemberUp, but that doesn't seem to match the numbers appended
>> to the address.
>>
>> Thanks!
>>
>> Mark
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Basic Akka Configuration and parallelism

[Viktor Klang]

Hi all,

if you want a router, then you need to create a router:


   1. ActorRef actorRef =
   2. actorSystem.actorOf(FromConfig.getInstance().props(Props.create(
   MyActor.class)),
   3. "myActor");


On Wed, Jan 28, 2015 at 3:24 PM, Björn Antonsson <
bjorn.antons...@typesafe.com> wrote:

> Hi Cos,
>
> Your single actor will process one single message at a time, in sequence.
> That is a fundamental principle of actors.
>
> If you want to have things happening in parallel then you need to have
> mutliple actors.
>
> B/
>
> On 28 January 2015 at 15:21:14, Cosmin Marginean (cosmin...@gmail.com)
> wrote:
>
> We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to
> scale for more throughput (as it apparently isn't happening).
>
> I am struggling with the Akka documentation as well as some of the
> examples out there as there is always some contextual information that
> seems to be missing.
> However, in order to make sure I'm not going mad, I've extracted the code
> and config in a dead-simple unit test (I even removed akka's JavaTestKit).
>
> The code and config here suggest that there should be a lot of messages
> processed in parallel, however the entire processing is totally serialised
> and I can't understand where have I failed in this setup.
>
> Any suggestion would be helpful.
>
> Thank you
> Cos
>
>  @Test
> public void testAkka() throws Exception {
> Config cfg = ConfigFactory.load("test-akka.conf");
> ActorSystem actorSystem = ActorSystem.create("main", 
> cfg.getConfig("main"));
> ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
> "myactor");
> for (int i = 0; i < 150; i++) {
> actorRef.tell("nothing", ActorRef.noSender());
> }
> Thread.sleep(100);
> }
>
> public static final class MyActor extends UntypedActor {
> @Override
> public void onReceive(Object message) throws Exception {
> System.out.println("Doing stuff");
> Thread.sleep(2000);
> }
>
> }
>
>
> And the test-akka.conf file
>
>  main {
>   app-dispatcher {
> type = Dispatcher
> executor = "fork-join-executor"
> fork-join-executor {
>   parallelism-min = 16
>   parallelism-factor = 32.0
>   parallelism-max = 512
> }
> throughput = 1
>   }
>
>   akka.actor.deployment {
> /myactor {
>   dispatcher = app-dispatcher
>   router = round-robin-pool
>   nr-of-instances = 16
> }
>   }
> }
>
>  --
> >> 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.
>
>
> --
> Björn Antonsson
> Typesafe  – Reactive Apps on the JVM
> twitter: @bantonsson 
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Basic Akka Configuration and parallelism

[Viktor Klang]

Yes, we chose it to be non transparent to use routers or not since it
fundamentally changes semantics.

-- 
Cheers,
√
On 28 Jan 2015 16:09, "Cosmin Marginean"  wrote:

> Right, I got it now.
> So that needs to be explicit about using a router in the code using the
> actor. So this is not entirely enough on its own
>
> /myactor {
>   ...
>   router = round-robin-pool
>
>
> Thanks, at least I know that now.
>
> Cos
>
> On Wednesday, 28 January 2015 14:27:10 UTC, √ wrote:
>>
>> Hi all,
>>
>> if you want a router, then you need to create a router:
>>
>>
>>1. ActorRef actorRef =
>>2. actorSystem.actorOf(FromConfig.getInstance().props(Props.create(
>>MyActor.class)),
>>3. "myActor");
>>
>>
>> On Wed, Jan 28, 2015 at 3:24 PM, Björn Antonsson > > wrote:
>>
>>> Hi Cos,
>>>
>>> Your single actor will process one single message at a time, in
>>> sequence. That is a fundamental principle of actors.
>>>
>>> If you want to have things happening in parallel then you need to have
>>> mutliple actors.
>>>
>>> B/
>>>
>>> On 28 January 2015 at 15:21:14, Cosmin Marginean (cosm...@gmail.com)
>>> wrote:
>>>
>>> We're running Akka 2.3.7 (Java) and I'm now working on reconfiguring to
>>> scale for more throughput (as it apparently isn't happening).
>>>
>>> I am struggling with the Akka documentation as well as some of the
>>> examples out there as there is always some contextual information that
>>> seems to be missing.
>>> However, in order to make sure I'm not going mad, I've extracted the
>>> code and config in a dead-simple unit test (I even removed akka's
>>> JavaTestKit).
>>>
>>> The code and config here suggest that there should be a lot of messages
>>> processed in parallel, however the entire processing is totally serialised
>>> and I can't understand where have I failed in this setup.
>>>
>>> Any suggestion would be helpful.
>>>
>>> Thank you
>>> Cos
>>>
>>>  @Test
>>> public void testAkka() throws Exception {
>>> Config cfg = ConfigFactory.load("test-akka.conf");
>>> ActorSystem actorSystem = ActorSystem.create("main", 
>>> cfg.getConfig("main"));
>>> ActorRef actorRef = actorSystem.actorOf(Props.create(MyActor.class), 
>>> "myactor");
>>> for (int i = 0; i < 150; i++) {
>>> actorRef.tell("nothing", ActorRef.noSender());
>>> }
>>> Thread.sleep(100);
>>> }
>>>
>>> public static final class MyActor extends UntypedActor {
>>> @Override
>>> public void onReceive(Object message) throws Exception {
>>> System.out.println("Doing stuff");
>>> Thread.sleep(2000);
>>> }
>>>
>>> }
>>>
>>>
>>> And the test-akka.conf file
>>>
>>>  main {
>>>   app-dispatcher {
>>> type = Dispatcher
>>> executor = "fork-join-executor"
>>> fork-join-executor {
>>>   parallelism-min = 16
>>>   parallelism-factor = 32.0
>>>   parallelism-max = 512
>>> }
>>> throughput = 1
>>>   }
>>>
>>>   akka.actor.deployment {
>>> /myactor {
>>>   dispatcher = app-dispatcher
>>>   router = round-robin-pool
>>>   nr-of-instances = 16
>>> }
>>>   }
>>> }
>>>
>>>  --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Björn Antonsson
>>> Typesafe  – Reactive Apps on the JVM
>>> twitter: @bantonsson 
>>>
>>>  --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> 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 ema

Re: [akka-user] Is forwarding a message to all children via an actor selection more efficient than iterating over the child ActorRefs?

[Viktor Klang]

+1 guess for nr 2

-- 
Cheers,
√
On 29 Jan 2015 09:00, "Roland Kuhn"  wrote:

> Hi Nick,
>
> I never benchmarked this, but I would guess that the second one should be
> a tad faster. Please share your findings!
>
> Thanks,
>
> Roland
>
> 28 jan 2015 kl. 21:37 skrev Nick Ebbitt :
>
> I have a scenario where when an actor receives a specific message it must
> forward the message to all of it's children that exist at that time.
>
> I think I have 2 options to solve this.
>
> getContext().actorSelection("*").forward(message, getContext());
>
> or
>
> getContext().getChildren().forEach(child -> child.forward(message, 
> getContext()));
>
> Without fully understanding the internal implementation of actor selection
> it's hard to know which will perform better. I plan to perform some bench
> marks with the kind of scale I am expecting to require but would appreciate
> any insight to this that experienced users may have.
>
> Thanks
>
> I've also created a stack overflow question for this if anyone would like
> to answer that:
> http://stackoverflow.com/questions/28189059/is-forwarding-a-message-to-all-children-via-an-actor-selection-more-efficient-th
>
> --
> >> 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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Reactive apps on the JVM.
> twitter: @rolandkuhn
> 
>
>  --
> >> 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.
>

-- 
>>  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.

Re: [akka-user] Delaying futures?

[Viktor Klang]

Hi John,

try this signature instead:
http://doc.akka.io/japi/akka/2.3.9/akka/pattern/Patterns.html#after(scala.concurrent.duration.FiniteDuration,
akka.actor.Scheduler, scala.concurrent.ExecutionContext,
java.util.concurrent.Callable)

On Thu, Jan 29, 2015 at 10:34 PM, John Ulric  wrote:

> Is there a way to delay the execution (not the completion) of a future,
> similar to the scheduleOnce method for actors? I tried this:
>
> Future delayedString = Patterns.after(new FiniteDuration(10, 
> TimeUnit.SECONDS),
> system.scheduler(), system.dispatcher(), Futures.future(new 
> Callable() {
> public String call() throws Exception {
> System.out.println("Returning some string immediately");
> return "Some string.";
> }
> }, system.dispatcher()));
>
> System.out.println("delayedString=" + Await.result(delayedString, 
> Duration.Inf()));
>
>
> But this calls the Callable immediately and only waits 10 seconds for the 
> result to be returned.
>
>
> Thanks, John
>
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Linking actors after creation

[Viktor Klang]

Hi Ugo,

Thanks for your question!

No, Akka does not support any notion of "adoption".

On Tue, Feb 3, 2015 at 6:15 PM, Ugo Matrangolo 
wrote:

> Hi,
>
> trying to wrap my head around Akka and I have simple question: is it
> possible to create a parent-child relationship between two actors *after*
> the 2nd one has been created (and not from the context of the first one, of
> course) ??
>
> Regards,
> Ugo
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: [akka-http 1.0-M2] Trying to add backpressure

[Viktor Klang]

The best kids of bugs are the non-bugs :)

On Tue, Feb 3, 2015 at 9:06 PM, Luis Ángel Vicente Sánchez <
langel.gro...@gmail.com> wrote:

> As usual... after asking a question, you find the answer yourself. The
> tool I'm using, was keeping the same connection alive; therefore all
> requests from that connection were handle by the same branch.
>
> El martes, 3 de febrero de 2015, 19:57:04 (UTC), Luis Ángel Vicente
> Sánchez escribió:
>
>> Dear hakkers,
>>
>> I have been trying to add back pressure to an akka-http application using
>> a transformation Stage and I have found something... unexpected. I have
>> created a SafetyStage that buffers up to a maximum number of elements:
>>
>> https://github.com/lvicentesanchez/random/blob/master/src/main/scala/io/
>> github/lvicentesanchez/streams/stage/SafetyStage.scala
>>
>> I have also simulated a random failure with a simple random number
>> generator.
>>
>> Instead of handling akka-http connections using the method handleWith of
>> the ServerBinding object, I'm creating the following FlowGraph:
>>
>> https://github.com/lvicentesanchez/random/blob/master/src/main/scala/io/
>> github/lvicentesanchez/Boot.scala#L56
>>
>> The connection Source is transformed using the SafetyStage. If the
>> maximum capacity, or a random error happens, a Left object is created; if
>> not, a Right object is created. A FlexiRoute sends the Left requests to a
>> sink that handles every failed/discarded connnection (it completes them
>> with  503 error); Right requests go to a sink that handles them using an
>> akka-http router.
>>
>> In my tests, once one of the Sink handles the first IncomingConnnection,
>> all future connections are handled using the "handler" of that Sink. I.e.
>> if the random number generator decided that the first connection suffered
>> an error, all future connections would also be completed with a 503 error.
>>
>> I guess what I'm trying to do is fundamentally wrong, but I still don't
>> understand why the transformation stage is completely ignored once the
>> first connection is handled.
>>
>> Regards,
>>
>> Luis
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: [akka-http 1.0-M2] Trying to add backpressure

[Viktor Klang]

The best typo as well.

s/kids/kinds

On Tue, Feb 3, 2015 at 9:16 PM, Viktor Klang  wrote:

> The best kids of bugs are the non-bugs :)
>
> On Tue, Feb 3, 2015 at 9:06 PM, Luis Ángel Vicente Sánchez <
> langel.gro...@gmail.com> wrote:
>
>> As usual... after asking a question, you find the answer yourself. The
>> tool I'm using, was keeping the same connection alive; therefore all
>> requests from that connection were handle by the same branch.
>>
>> El martes, 3 de febrero de 2015, 19:57:04 (UTC), Luis Ángel Vicente
>> Sánchez escribió:
>>
>>> Dear hakkers,
>>>
>>> I have been trying to add back pressure to an akka-http application
>>> using a transformation Stage and I have found something... unexpected. I
>>> have created a SafetyStage that buffers up to a maximum number of elements:
>>>
>>> https://github.com/lvicentesanchez/random/blob/master/src/main/scala/io/
>>> github/lvicentesanchez/streams/stage/SafetyStage.scala
>>>
>>> I have also simulated a random failure with a simple random number
>>> generator.
>>>
>>> Instead of handling akka-http connections using the method handleWith of
>>> the ServerBinding object, I'm creating the following FlowGraph:
>>>
>>> https://github.com/lvicentesanchez/random/blob/master/src/main/scala/io/
>>> github/lvicentesanchez/Boot.scala#L56
>>>
>>> The connection Source is transformed using the SafetyStage. If the
>>> maximum capacity, or a random error happens, a Left object is created; if
>>> not, a Right object is created. A FlexiRoute sends the Left requests to a
>>> sink that handles every failed/discarded connnection (it completes them
>>> with  503 error); Right requests go to a sink that handles them using an
>>> akka-http router.
>>>
>>> In my tests, once one of the Sink handles the first IncomingConnnection,
>>> all future connections are handled using the "handler" of that Sink. I.e.
>>> if the random number generator decided that the first connection suffered
>>> an error, all future connections would also be completed with a 503 error.
>>>
>>> I guess what I'm trying to do is fundamentally wrong, but I still don't
>>> understand why the transformation stage is completely ignored once the
>>> first connection is handled.
>>>
>>> Regards,
>>>
>>> Luis
>>>
>>  --
>> >>>>>>>>>> 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.
>>
>
>
>
> --
> Cheers,
> √
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  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.

Re: [akka-user] Does akka support fiber/coroutine? (do not modify source code)

[Viktor Klang]

Hi Chansey,

What would you look to gain by switching to coroutines?

On Fri, Feb 6, 2015 at 7:44 PM,  wrote:

> Hello,
>
> Does akka support fiber/coroutine?
>
> I found that all akka's dispatchers rely on JVM threads now.
>
> Is there any way to config dispatchers which could run actor on
> fiber/coroutine?  (do not modify the akka source code)
>
> Like StubFiber in retLang which use ExecuteAllPendingUntilEmpty to run
> dispatcher schedule instead of actual JVM thread.
>
> PS:
> I maybe could make akka support it, but need modify some akka code...
>
> I am using akka.NET now.
>
> Very thanks.
>
> Br,
> Chansey
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Does akka support fiber/coroutine? (do not modify source code)

[Viktor Klang]

On Fri, Feb 6, 2015 at 8:24 PM,  wrote:

> Hi
>
> Because my application is  running on one thread now. (It maybe extend to
> multi-thread in the future)
>
> To be frank,
>
> I get benefit from akka by using actor model programming paradigm instead
> of its concurrency.
>

You can use an Akka Dispatcher with a single thread and then make it
non-daemonic and exit your main thread and your Akka application will be
single-threaded?


>
> Br,
> Chansey
>
> 在 2015年2月7日星期六 UTC+8上午2:58:10，√写道：
>>
>> Hi Chansey,
>>
>> What would you look to gain by switching to coroutines?
>>
>> On Fri, Feb 6, 2015 at 7:44 PM,  wrote:
>>
>>> Hello,
>>>
>>> Does akka support fiber/coroutine?
>>>
>>> I found that all akka's dispatchers rely on JVM threads now.
>>>
>>> Is there any way to config dispatchers which could run actor on
>>> fiber/coroutine?  (do not modify the akka source code)
>>>
>>> Like StubFiber in retLang which use ExecuteAllPendingUntilEmpty to run
>>> dispatcher schedule instead of actual JVM thread.
>>>
>>> PS:
>>> I maybe could make akka support it, but need modify some akka code...
>>>
>>> I am using akka.NET now.
>>>
>>> Very thanks.
>>>
>>> Br,
>>> Chansey
>>>
>>> --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] akka.io downloads - no java?

[Viktor Klang]

Hi Jeffrey,

Akka is built in Scala but offers Java APIs, so the "Scala downloads"
should be just fine.

However, if you are getting started I'd recommend the Activator download as
you can get started with the Akka Java tutorials.

On Sun, Feb 8, 2015 at 9:32 PM, Jeffrey Kelly  wrote:

> I feel pretty stupid for asking this, but if I wanted to experiment with
> Akka for Java, where would I find it? For all the Java/Scala parallel
> documentation, the downloads section of the site only appears to provide
> Scala options (along with an entire ecosystem that I'm not interested in).
> I was kind of just hoping for a jar or 10. Am I missing something? Is Java
> Akka still a thing?
>
> jef
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] [akka-stream] Prebuilt Source with simple synchronous API

[Viktor Klang]

Hi Alexey,

Doug is currently working on a proposal for this for JDK9, perhaps
something for inspiration?
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/SubmissionPublisher.html

On Sun, Feb 8, 2015 at 5:54 PM, Alexey Romanchuk  wrote:

> Hello again,
>
> My idea right now is to specify buffer size explicitly and return
> Future[Try[Unit]] that indicates result of enqueuing into buffered source.
> I am not sure that there is right way, but I need to connect some non
> stream based system with akka streams. Any thoughts?
>
> Unfortunately, I faced https://github.com/akka/akka/issues/16762 and
> right now it is impossible to provide high level API to custom sources
> instead of prebuilt ones.
>
> воскресенье, 25 января 2015 г., 20:09:07 UTC+6 пользователь √ написал:
>>
>> Hi Alexey,
>>
>> On Sat, Jan 24, 2015 at 11:20 AM, Alexey Romanchuk > > wrote:
>>
>>> Hey hakkers,
>>>
>>> I wonder why there is not such prebuilt Source that provides API to
>>> externally emit message by simple method call. I am talking about something
>>> like this:
>>>
>>> //building and starting flow
>>> val flow = ???
>>> val source = ExternalSource[String]
>>> source.via(flow).to(BlackholeSink).run
>>>
>>> //using source
>>> source.emit("")
>>>
>>
>> What would happen if it can't?
>>
>>
>>> source.complete()
>>> source.error(new Exception)
>>>
>>> It can be implemented manually using actor, buffer inside it and
>>> exposing some object that internally sends message to this actor. I think
>>> this source can be very useful in case of integration with external API.
>>>
>>
>> I agree, I think something like this could be quite useful, the "problem"
>> is getting the API right.
>>
>>
>>>
>>> Thanks
>>>
>>> p.s. Sure, we can not directly use ExternalSource to emit objects, but
>>> should use some object created during flow materialization, like PropSource
>>> does.
>>>
>>> --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Handling of Fatal errors

[Viktor Klang]

Hi Andrey,

Thanks for your email, I've attempted to elucidate the current semantics
but there may definitely be room for improvements.

On 10 Feb 2015 17:23, "Andrey"  wrote:
>
> Hello,
>
> I have Akka configured not to exit JVM on fatal errors by setting the
"akka.jvm-exit-on-fatal-error" property to "off". In such case, it's
expected to shutdown the actor system.

>As a side note, I find Scala's opinion as to which java.lang.Error are to
be treated as fatal and non-fatal >to be mildly peculiar. One example would
be the OSGi environment where NoClassDefFoundError is >not a fatal
exception, but on the contrary, is very much recoverable without a JVM
restart. Scala >disagrees.

it is only the catchall (NonFatal) that considers it fatal, if you expect
it [NCDFE] in your code, you can/should surround it with a try catch and
promote it to a non fatal exception or otherwise deal with the "normal"
case. "Generic" NCDFEs are definitely not recoverable as they typically
signal that the classpath/application is broken.

>
> Anyway, back to the problem, Akka seems to recognize the setting
correctly and doesn't halt the JVM process. However, when later I call a
shutdown() followed by an awaitTermination() on the instance of the actor
system whose actor has just "fatally" failed, the awaitTermination() call
never returns (blocks forever). Also, neither the actor that has thrown the
Error, nor its parents (up the supervision tree) get called postStop(). It
looks almost like if Akka forgets to stop the failed actor and its
immediate parent is left waiting forever unable to proceed with its own
shutdown.

In the face of a fatal error no guarantees can be made as to the
consistency of the JVM nor the data within it, as such we recommend to
forcibly shut down the JVM.

>Please note that the siblings of the failed actor (as well as all other
unrelated actors) do get their postStop() invoked.

Since `postStop` is invoked in the -instance- that produced a fatal failure
I guess there's the philosophical argument to be had whether it can attempt
to stop itself or not.

>
> Although I could not find anything relevant in Akka documentation, my
expectation is that postStop() of all actors is always invoked during actor
system shutdown.

That is not a guarantee that can be made nor kept on the JVM as thread
interruption is cooperative and thread stop is undefined.

>
> Below is a simple unit test that demonstrates the problem.
>
> Thanks you for your help.
> Andrey
>
> package example;
>
> import java.util.concurrent.TimeUnit;
>
> import akka.actor.ActorRef;
> import akka.actor.ActorSystem;
> import akka.actor.Props;
> import akka.actor.UntypedActor;
> import com.google.common.util.concurrent.SettableFuture;
> import com.typesafe.config.ConfigFactory;
> import org.junit.After;
> import org.junit.Before;
> import org.junit.Test;
> import scala.concurrent.duration.Duration;
>
> public class AkkaUtilTest {
> ActorSystem akka;
>
> @Before
> public void setUp() throws Exception {
> akka = ActorSystem.create("test",
>
ConfigFactory.parseString("akka.jvm-exit-on-fatal-error=off"));
> }
>
> @After
> public void tearDown() throws Exception {
> akka.shutdown();
> // This call never returns.
> akka.awaitTermination(Duration.create(5000,
TimeUnit.MILLISECONDS));
> }
>
> @Test(timeout = 2000)
> public void testError() throws Exception {
> SettableFuture result = SettableFuture.create();
> ActorRef actorRef =
akka.actorOf(Props.create(ThrowingActor.class, result));
>
> actorRef.tell(new Object(), ActorRef.noSender());
>
> // The get() call never returns and the test times out.
> result.get();
> }
>
> static class ThrowingActor extends UntypedActor {
> final SettableFuture stopped;
>
> ThrowingActor(SettableFuture stopped) {
> this.stopped = stopped;
> }
>
> @Override
> public void onReceive(Object message) throws Exception {
> // These cause postStop() never called on this actor and the
actor system can't be
> // gracefully shutdown.
>
> //throw new OutOfMemoryError("oh, my!");
> throw new NoClassDefFoundError("no-class-def");
>
> // These work just fine:
> // throw new AssertionError("assertion");
> // throw new Error("error");
> }
>
> @Override
> public void postStop() throws Exception {
> // Never called.
> stopped.set(null);
> }
> }
> }
>
>
>
> --
> >> 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
em

Re: [akka-user] Handling of Fatal errors

[Viktor Klang]

Hi Andrey,

if NCDFEs are fine in your app you can always wrap and rethrow to signal
that you think it's fine.

"An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch. Most such errors are
abnormal conditions. The ThreadDeath error, though a "normal" condition, is
also a subclass of Error because most applications should not try to catch
it.

A method is not required to declare in its throws clause any subclasses of
Error that might be thrown during the execution of the method but not
caught, since these errors are abnormal conditions that should never
occur." - https://docs.oracle.com/javase/6/docs/api/java/lang/Error.html
We should most definitely improve the documentation on this, as you note.

On Wed, Feb 11, 2015 at 4:53 PM, Andrey  wrote:

> Hi Viktor,
>
> Thank you for your reply!
>
> My issue at the moment is not so much lack of any type of guarantees while
> processing a fatal exception (which indeed can be improved), but the fact
> that - as the unit test demonstrates - Akka is unable to shut down itself
> cleanly.
>
> Besides, "fatal" exceptions like NoClassDefFoundError do not make JVM
> unstable or inconsistent like some others may (the VirtualMachineError
> subclasses, for example), so in my mind there is no reason for Akka not to
> try its best and shutdown cleanly under any conditions.
>
> Regards
> Andrey
>
> On Wednesday, February 11, 2015 at 4:53:46 AM UTC-8, √ wrote:
>>
>> Hi Andrey,
>>
>> Thanks for your email, I've attempted to elucidate the current semantics
>> but there may definitely be room for improvements.
>>
>> On 10 Feb 2015 17:23, "Andrey"  wrote:
>> >
>> > Hello,
>> >
>> > I have Akka configured not to exit JVM on fatal errors by setting the
>> "akka.jvm-exit-on-fatal-error" property to "off". In such case, it's
>> expected to shutdown the actor system.
>>
>> >As a side note, I find Scala's opinion as to which java.lang.Error are
>> to be treated as fatal and non-fatal >to be mildly peculiar. One example
>> would be the OSGi environment where NoClassDefFoundError is >not a fatal
>> exception, but on the contrary, is very much recoverable without a JVM
>> restart. Scala >disagrees.
>>
>> it is only the catchall (NonFatal) that considers it fatal, if you expect
>> it [NCDFE] in your code, you can/should surround it with a try catch and
>> promote it to a non fatal exception or otherwise deal with the "normal"
>> case. "Generic" NCDFEs are definitely not recoverable as they typically
>> signal that the classpath/application is broken.
>>
>> >
>> > Anyway, back to the problem, Akka seems to recognize the setting
>> correctly and doesn't halt the JVM process. However, when later I call a
>> shutdown() followed by an awaitTermination() on the instance of the actor
>> system whose actor has just "fatally" failed, the awaitTermination() call
>> never returns (blocks forever). Also, neither the actor that has thrown the
>> Error, nor its parents (up the supervision tree) get called postStop(). It
>> looks almost like if Akka forgets to stop the failed actor and its
>> immediate parent is left waiting forever unable to proceed with its own
>> shutdown.
>>
>> In the face of a fatal error no guarantees can be made as to the
>> consistency of the JVM nor the data within it, as such we recommend to
>> forcibly shut down the JVM.
>>
>> >Please note that the siblings of the failed actor (as well as all other
>> unrelated actors) do get their postStop() invoked.
>>
>> Since `postStop` is invoked in the -instance- that produced a fatal
>> failure I guess there's the philosophical argument to be had whether it can
>> attempt to stop itself or not.
>>
>> >
>> > Although I could not find anything relevant in Akka documentation, my
>> expectation is that postStop() of all actors is always invoked during actor
>> system shutdown.
>>
>> That is not a guarantee that can be made nor kept on the JVM as thread
>> interruption is cooperative and thread stop is undefined.
>>
>> >
>> > Below is a simple unit test that demonstrates the problem.
>> >
>> > Thanks you for your help.
>> > Andrey
>> >
>> > package example;
>> >
>> > import java.util.concurrent.TimeUnit;
>> >
>> > import akka.actor.ActorRef;
>> > import akka.actor.ActorSystem;
>> > import akka.actor.Props;
>> > import akka.actor.UntypedActor;
>> > import com.google.common.util.concurrent.SettableFuture;
>> > import com.typesafe.config.ConfigFactory;
>> > import org.junit.After;
>> > import org.junit.Before;
>> > import org.junit.Test;
>> > import scala.concurrent.duration.Duration;
>> >
>> > public class AkkaUtilTest {
>> > ActorSystem akka;
>> >
>> > @Before
>> > public void setUp() throws Exception {
>> > akka = ActorSystem.create("test",
>> > ConfigFactory.parseString("
>> akka.jvm-exit-on-fatal-error=off"));
>> > }
>> >
>> > @After
>> > public void tearDown() throws Exception {
>> > akka.shutdown();
>> > // This

Re: [akka-user] Future and Thread.

[Viktor Klang]

Hi Maatary,

1) This is rather easily explored with the following incantation:

scala> Future { Thread.currentThread.isDaemon } foreach println
true

2) I am not sure I understand the question, would you mind elaborating?
Hi,

by default, on which kind of Thread is a future executed ?

Example:

when i run the following program


object ThreadAPP extends App {

  import scala.concurrent.ExecutionContext.Implicits.global

  val future = Future {

println("done with the future"); "hello"

  }

  future foreach println

  //Thread.sleep(5000)

}


As you can see with the Thread.sleep commanted. or let say no await, the
println is empty and the program terminate.


however with The sleep or an await, my main does not terminate.


Hence, i wonder what is happening behind the scene. The Main thread in Java
is supposed to be a daemon thread. (1) *Is the future executed in a Deamon
thread ? *

(2) Can an executorService manager both daemon (the main thread) and
non-deamon (futures) at once? or the executorService of Implicit.global
only create thread for whatever asynchronous code will come with future ?

If someone could explain a little how Implicit.global works that would
help.





 --
>> 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.

-- 
>>  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.

Re: [akka-user] Re: streams - Source that emits only 1 (or no) element

[Viktor Klang]

Giovanni,

On Mon, Feb 16, 2015 at 9:37 PM, Giovanni Alberto Caporaletti <
paradi...@gmail.com> wrote:

> What I'm saying is that conceptually having a single item or a stream are
> two different things and this should be reflected in the type system (e.g.
> rx Task).
>

I disagree and let me tell you why :) Think about it—Stream subsumes
Future: there is no type that reflects an empty stream, there is no type
that discerns bounded from unbounded streams, hot or cold streams, no type
for bounded streams of size N, no type for this is a stream that fails
after N elements…
If you were to provide types for all these very important >>shapes<< of
streams you'd end up executing the streams inside the compiler when you try
to typecheck the program.


>  What you're suggesting is implementation details, the assumption that a
> source will only emit 1 item is nowhere to be seen in the type.
> if I have a signature that returns (or takes) a Stream[T] I don't see the
> constraint that that stream will never have more than 1 item.
>
> A Future is a very different animal from the Stream, especially because it
> represents a computation that's already happening.
>

The statement regarding Future is provably false:

Let me present Exhibit A:

val p = Promise[Pigdog]()

val f = p.future // is f an already running computation?

One of the most prevalent misconceptions is that Futures are inherently
about computation—they're not :) Future are about facts which may or may
not be available at a specific point in time. I think the source of the
confusion is twofold: Future.apply and Future., in fact,
if Future only had the `onComplete` method one could create typeclasses
that would provide -all- of the functionality already available for Future
(of course given that Promise allows for populating it with a value).


> I have no way (afaik) of expressing in a type signature that "this is a
> blueprint for a source of a single (or zero) item".
>
> Look at the rx Observable.single method. It does that but it doesn't
> express it in the type system (as Task does). A lot of use cases involve
> Observables/Producers/Sources that can possibly have only one item, hence
> this PR: https://github.com/ReactiveX/RxJava/pull/2641.
>
>
But don't get me wrong, it doesn't mean that Future (or rx.Task) isn't
useful, quite the contrary, but stream is provably more useful (since it
supports more usecases).


>
> On Monday, 16 February 2015 18:41:07 UTC, Jim Hazen wrote:
>>
>> These days the current API supports a number of ways of constructing a
>> Source.
>>
>> http://doc.akka.io/api/akka-stream-and-http-experimental/
>> 1.0-M3/?_ga=1.72893075.1209102577.1407799351#akka.stream.scaladsl.Source$
>>
>> Based upon these available methods, if I needed to supply 0 or 1 elements
>> based upon some business logic, I would probably create a custom iterator
>> implementation.  Your business logic can then determine whether to emit an
>> element or provide hasNext=false, which I believe will signal that the
>> source is empty and trigger a teardown of the materialized flow.
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: streams - Source that emits only 1 (or no) element

[Viktor Klang]

Hi Giovanni,

On Mon, Feb 16, 2015 at 11:31 PM, Giovanni Alberto Caporaletti <
paradi...@gmail.com> wrote:

> You're absolutely right about the future not representing an "already
> running computation". But it's not a "blueprint". If a see a future, I take
> for granted that something will happen sooner or later. If I see a source
> and I don't materialize it, nothing will ever happen if it's cold.
>

That's absolutely correct—a Future is not a blueprint. To get a blueprint
for it you'd need () => Future[X]


>
> Regarding those use cases, I'm not that extreme, but for a single item
> observable/stream I think it would be really useful to have that
> abstraction, mostly because a lot of my code is based on the assumption
> that the observable will return exactly one item.
>

But it cannot be proven as an Exception (or rather a Throwable) could be
thrown at any point in time in the execution of that Source.
(StackOverFlowError, ThreadDeath, OutOfMemoryError etc)
Making assumptions is OK, but one needs to consider the failure cases
(because they do tend to occur in practice).


>
> Maybe it's just me but i find really helpful to have "talking" signatures.
> E.g. if I saw in an api a data lookup method 'def retrieveUserByName(name:
> String)', knowing that it returns a SingleItemStream[User] instead of a
> Stream[User]  would help a lot because it'd be immediately clear that name
> is a unique attribute of the user. I really think that this expressive
> power, when consistent all over the codebase, is of great help.
>

I completely agree, being able to have the type system prove things for us
is really neat, but unfortunately it is not really feasible to track source
sizes—what's good is that you can create, as Endre nicely points out, a
value class wrapper for some of them.

It should be noted that a Future[T] really has 3 outcomes: never completed,
value or Exception


>
> Sorry if something I wrote is not correct, I started studying
> reactive/asynchronous programming only recently and I'm grateful to whoever
> helps me to understand it :)
>

No need to apologize! :)


>
> Cheers
> G
>
> On Monday, 16 February 2015 21:29:10 UTC, √ wrote:
>>
>> Giovanni,
>>
>> On Mon, Feb 16, 2015 at 9:37 PM, Giovanni Alberto Caporaletti <
>> para...@gmail.com> wrote:
>>
>>> What I'm saying is that conceptually having a single item or a stream
>>> are two different things and this should be reflected in the type system
>>> (e.g. rx Task).
>>>
>>
>> I disagree and let me tell you why :) Think about it—Stream subsumes
>> Future: there is no type that reflects an empty stream, there is no type
>> that discerns bounded from unbounded streams, hot or cold streams, no type
>> for bounded streams of size N, no type for this is a stream that fails
>> after N elements…
>> If you were to provide types for all these very important >>shapes<< of
>> streams you'd end up executing the streams inside the compiler when you try
>> to typecheck the program.
>>
>>
>>>  What you're suggesting is implementation details, the assumption that a
>>> source will only emit 1 item is nowhere to be seen in the type.
>>> if I have a signature that returns (or takes) a Stream[T] I don't see
>>> the constraint that that stream will never have more than 1 item.
>>>
>>> A Future is a very different animal from the Stream, especially because
>>> it represents a computation that's already happening.
>>>
>>
>> The statement regarding Future is provably false:
>>
>> Let me present Exhibit A:
>>
>> val p = Promise[Pigdog]()
>>
>> val f = p.future // is f an already running computation?
>>
>> One of the most prevalent misconceptions is that Futures are inherently
>> about computation—they're not :) Future are about facts which may or may
>> not be available at a specific point in time. I think the source of the
>> confusion is twofold: Future.apply and Future., in fact,
>> if Future only had the `onComplete` method one could create typeclasses
>> that would provide -all- of the functionality already available for Future
>> (of course given that Promise allows for populating it with a value).
>>
>>
>>> I have no way (afaik) of expressing in a type signature that "this is a
>>> blueprint for a source of a single (or zero) item".
>>>
>>> Look at the rx Observable.single method. It does that but it doesn't
>>> express it in the type system (as Task does). A lot of use cases involve
>>> Observables/Producers/Sources that can possibly have only one item, hence
>>> this PR: https://github.com/ReactiveX/RxJava/pull/2641.
>>>
>>>
>> But don't get me wrong, it doesn't mean that Future (or rx.Task) isn't
>> useful, quite the contrary, but stream is provably more useful (since it
>> supports more usecases).
>>
>>
>>>
>>> On Monday, 16 February 2015 18:41:07 UTC, Jim Hazen wrote:

 These days the current API supports a number of ways of constructing a
 Source.

 http://doc.akka.io/api/akka-stream-and-http-experimental/1.
 0-M3/?_ga=1.72893075.12091025

Re: [akka-user] Re: streams - Source that emits only 1 (or no) element

[Viktor Klang]

Thanks for raising a good question!

-- 
Cheers,
√
On 17 Feb 2015 12:47, "Giovanni Alberto Caporaletti" 
wrote:

> Thank you for your replies Viktor and Endre. I see your point and of
> course the possibility of a failure has always to be considered, regardless
> of the "cardinality" of the stream.
> I agree that a value class would only be a runtime check (same as calling
> .single on an rx observable).
>
> I think my worries come from how we're using rx here, that is something
> similar to what slick 3.0 does, that is loading items from a database and
> other external sources.
> Apart from the particular case of loading rows from a db (possibly on a
> different dispatcher if the driver is blocking etc), I think that I was
> generally thinking about cold sources that, when subscribed to, are
> resource-heavy, but backpressure already handles this nicely.
>
> In the end, a specialized type for single-item sources would probably only
> add runtime checks and not guarantee anything at compile time. A value
> class wrapper is nice to have but doesn't add much more value than an api
> doc.
>
> So yeah, I think you just changed my mind, thanks guys :P
>
> Cheers
> G
>
> On Tuesday, 17 February 2015 10:04:03 UTC, √ wrote:
>>
>> Hi Giovanni,
>>
>> On Mon, Feb 16, 2015 at 11:31 PM, Giovanni Alberto Caporaletti <
>> para...@gmail.com> wrote:
>>
>>> You're absolutely right about the future not representing an "already
>>> running computation". But it's not a "blueprint". If a see a future, I take
>>> for granted that something will happen sooner or later. If I see a source
>>> and I don't materialize it, nothing will ever happen if it's cold.
>>>
>>
>> That's absolutely correct—a Future is not a blueprint. To get a blueprint
>> for it you'd need () => Future[X]
>>
>>
>>>
>>> Regarding those use cases, I'm not that extreme, but for a single item
>>> observable/stream I think it would be really useful to have that
>>> abstraction, mostly because a lot of my code is based on the assumption
>>> that the observable will return exactly one item.
>>>
>>
>> But it cannot be proven as an Exception (or rather a Throwable) could be
>> thrown at any point in time in the execution of that Source.
>> (StackOverFlowError, ThreadDeath, OutOfMemoryError etc)
>> Making assumptions is OK, but one needs to consider the failure cases
>> (because they do tend to occur in practice).
>>
>>
>>>
>>> Maybe it's just me but i find really helpful to have "talking"
>>> signatures. E.g. if I saw in an api a data lookup method 'def
>>> retrieveUserByName(name: String)', knowing that it returns a
>>> SingleItemStream[User] instead of a Stream[User]  would help a lot because
>>> it'd be immediately clear that name is a unique attribute of the user. I
>>> really think that this expressive power, when consistent all over the
>>> codebase, is of great help.
>>>
>>
>> I completely agree, being able to have the type system prove things for
>> us is really neat, but unfortunately it is not really feasible to track
>> source sizes—what's good is that you can create, as Endre nicely points
>> out, a value class wrapper for some of them.
>>
>> It should be noted that a Future[T] really has 3 outcomes: never
>> completed, value or Exception
>>
>>
>>>
>>> Sorry if something I wrote is not correct, I started studying
>>> reactive/asynchronous programming only recently and I'm grateful to whoever
>>> helps me to understand it :)
>>>
>>
>> No need to apologize! :)
>>
>>
>>>
>>> Cheers
>>> G
>>>
>>> On Monday, 16 February 2015 21:29:10 UTC, √ wrote:

 Giovanni,

 On Mon, Feb 16, 2015 at 9:37 PM, Giovanni Alberto Caporaletti <
 para...@gmail.com> wrote:

> What I'm saying is that conceptually having a single item or a stream
> are two different things and this should be reflected in the type system
> (e.g. rx Task).
>

 I disagree and let me tell you why :) Think about it—Stream subsumes
 Future: there is no type that reflects an empty stream, there is no type
 that discerns bounded from unbounded streams, hot or cold streams, no type
 for bounded streams of size N, no type for this is a stream that fails
 after N elements…
 If you were to provide types for all these very important >>shapes<< of
 streams you'd end up executing the streams inside the compiler when you try
 to typecheck the program.


>  What you're suggesting is implementation details, the assumption that
> a source will only emit 1 item is nowhere to be seen in the type.
> if I have a signature that returns (or takes) a Stream[T] I don't see
> the constraint that that stream will never have more than 1 item.
>
> A Future is a very different animal from the Stream, especially
> because it represents a computation that's already happening.
>

 The statement regarding Future is provably false:

 Let me present Exhibit A:

 val p = Promise[Pigdog]()

 val f

Re: [akka-user] Many concurrent network connections

[Viktor Klang]

Hi Haddock,

First, let me say that your name is awesome.

Secondly, have a look here:
https://typesafe.com/blog/qa-with-caoyuan-deng-akka-at-wandoujia

-- 
Cheers,
√
On 25 Feb 2015 20:35, "Haddock"  wrote:

> Hello,
>
> I have a questions concerning holding many network connections and whether
> Akka can handle this. Let's say a system needs to be able to hold 50.000
> network connections at the same time. So there are 50.000 incoming
> connections and 50.000 outgoing connections. In a conventional system this
> would mean that 100.000 threads need to be spawned. Obviously, that many
> threads cannot be created on the JVM (I know Erlang can do this). My
> question is now whether Akka can do this or whether I need to move some
> load balancer in place like Vert.x or Erlang or something.
>
> Thanks, Haddock
>
> --
> >> 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.
>

-- 
>>  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.

Re: [akka-user] Problem with akka tcp streams

[Viktor Klang]

This looks weird:

val file = scala.io.Source.fromFile(new File("./logfile.txt"))
  val lines = file.getLines() <-- getLines here?

  Source(() => file.getLines()).map(line => {

On Thu, Mar 19, 2015 at 8:28 PM, Martynas Mickevičius <
martynas.mickevic...@typesafe.com> wrote:

> Hi,
>
> are you sure you do not stop this actor or the whole ActorSystem while the
> transfer is still going?
>
> On Thu, Mar 19, 2015 at 1:32 AM, zergood  wrote:
>
>> Hi!
>>
>> I want to stream file lines through tcp to server.
>>
>> Here is the code:
>>
>> class StreamingTcpActor(remoteAddress:InetSocketAddress, system: 
>> ActorSystem){
>>   implicit val actorSystem = system
>>   implicit val materializer = ActorFlowMaterializer()
>>
>>   val connection = StreamTcp().outgoingConnection(remoteAddress)
>>   val file = scala.io.Source.fromFile(new File("./logfile.txt"))
>>   val lines = file.getLines()
>>
>>   Source(() => file.getLines()).map(line => {
>> val message = MessageWithId(UUID.randomUUID().toString, line)
>> RunTcpStreamEx.messageSerializer.toByteString(message)
>>   }).via(connection.flow).to(Sink.ignore).run()
>> }
>>
>>
>> Problem: Some lines were not send to the network.
>> If I rewrite client code with out akka-streaming everything would be ok.
>>
>> I am new to akka streams. Could you provide me some doc links to figure
>> out what`s wrong here.
>>
>> --
>> >> 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.
>>
>
>
>
> --
> Martynas Mickevičius
> Typesafe  – Reactive
>  Apps on the JVM
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] akka-streams constructing Source from Iterator

[Viktor Klang]

You need to also make sure that the underlying connection gets closed both
in the case of afilure but also in the case of non-exhaustion.

On Thu, Mar 19, 2015 at 10:08 PM,  wrote:

> Martynas,
>
> I have an existing function that creates Iterator that wraps ResultSet and
> I can pass this function to Source(f: () => Iterator) which would allow
> re-materialization. It makes sense though to execute query in hasNext as an
> optimization in case Iterator is never consumed. Given that I can pass
> function that creates Iterator wrapper for ResultSet, can I prevent
> re-materialization of such Source within the same execution of runnable
> flow. DatabasePublisher from Slick allows only one subscriber so this
> ensures that there are no concurrency issues. Unfortunately, Slick is not
> an easy option given existing investment in our database layer.
>
> Here's an example of what I would like to accomplish() using akka-streams:
>
> Source(() => myDataService.getIterator)) // Iterator.next() returns mapped
> entity
>
> After this point in the flow, is there anything that I need to be aware of
> that may inadvertently trigger
>
>
>
>
> Thank you for your response,
> Andre
>
>>   --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Surviving VirtualMachineError

[Viktor Klang]

Hi Alexandre,

unfortunately it does not work like that. Recovering from SOE and OOME is
not possible in general, and as such it is better to fail fast and fix the
bug instead of limping along in a possibly corrupted state.

On Wed, Mar 25, 2015 at 3:13 PM, Alexandre Russel 
wrote:

> Hi all,
>
>  we're using an actor system in our play application with the default
> strategies. One of our actor misbehaved and throw a StackOverflowError
> which shutdown the actor system. The JVM was still running but the actor
> system was down. I was wondering if it would make sense to catch
> StackOverflow and OutOfMemory error in our default strategy. We are not
> keeping state in our actors and once the actor is restarted the stack or
> memory should be back to working state. What do you think ?
>
> Alex
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Akka Stream 1.0M5 : buffersize = 0

[Viktor Klang]

Hi Peter,

Akka streams is about async stream processing and without a buffer you
cannot be async.

-- 
Cheers,
√
On 30 Mar 2015 09:22, "Peter Schmitz"  wrote:

> Actually ActorFlowMaterializerSettings is complaining
> about initialInputBufferSize = 0. What are the reasons you can't disable
> buffering elements by setting initialInputBufferSize and maxInputBufferSize
> to zero? I am aware that one of the core features of akka-stream is
> buffering to gain throughput. But in my use case I like to disable
> buffering at least for a certain stream-section. Are there other ways to
> accomplish this?
>
> Thanks in advance! Great job, guys!
>
> Peter
>
>  --
> >> 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.
>

-- 
>>  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.

Re: [akka-user] Akka Stream 1.0M5 : buffersize = 0

[Viktor Klang]

On Mon, Mar 30, 2015 at 10:36 AM, Peter Schmitz 
wrote:

>
> I know that, but a section of my Flowgraph (SubFlowGraph) should act like
> a single stream stage,
>

"should act like a single stream stage"—from what/whose perspective?


> that means having only one (possibly large) buffer for that section. The
> whole section will be used async. Currently each stage in my SubFlowGraph
> buffers at least one element. Sadly it's not possible to make that section
> a function f to use Flow[T].map(f).
> Any ideas?
>

May I ask what the problem with the current behavior is for you?


>
>
> Am Montag, 30. März 2015 10:08:10 UTC+2 schrieb √:
>>
>> Hi Peter,
>>
>> Akka streams is about async stream processing and without a buffer you
>> cannot be async.
>>
>> --
>> Cheers,
>> √
>> On 30 Mar 2015 09:22, "Peter Schmitz"  wrote:
>>
>>> Actually ActorFlowMaterializerSettings is complaining
>>> about initialInputBufferSize = 0. What are the reasons you can't disable
>>> buffering elements by setting initialInputBufferSize and maxInputBufferSize
>>> to zero? I am aware that one of the core features of akka-stream is
>>> buffering to gain throughput. But in my use case I like to disable
>>> buffering at least for a certain stream-section. Are there other ways to
>>> accomplish this?
>>>
>>> Thanks in advance! Great job, guys!
>>>
>>> Peter
>>>
>>>  --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Akka Stream 1.0M5 : buffersize = 0

[Viktor Klang]

Assuming that the flow is local you can always skip entries that are old
(I'd advise against using wallclock; and nanoTime is local only) on a per
stage basis.

On Mon, Mar 30, 2015 at 2:57 PM, Endre Varga 
wrote:

> Hi Peter,
>
> Why don't you just create a custom stage then where you bundle up all the
> calculations you need to be done synchronously?
>
> (Btw, I agree with Roland that you probably over-worry about those buffers)
>
> -Endre
>
> On Mon, Mar 30, 2015 at 2:54 PM, Peter Schmitz 
> wrote:
>
>> Hi Endre,
>>
>> I am aware of this, and I know I want to disable a core feature of akka
>> stream for a certain section of my flow.
>> That said my actor buffering in front of processing is fine but the in
>> between these two actors processing by my partial flowgraph should be done
>> without buffering due to the staleness issue I mentioned.
>>
>> Peter
>>
>>
>> Am Montag, 30. März 2015 14:39:53 UTC+2 schrieb drewhk:
>>>
>>> Hi Peter,
>>>
>>> The issue is, that these processing elements are actors, which have a
>>> mailbox, so there is buffering in any case. You cannot have meaningful
>>> asynchronous processing without at least a buffer size of one.
>>>
>>> -Endre
>>>
>>> On Mon, Mar 30, 2015 at 2:36 PM, Peter Schmitz 
>>> wrote:
>>>
 Hi Roland,

 I've tried different OverflowStrategies in front of my partial flow,
 but none worked... as expected because this doesn't change my problem that
 there are already stale elements in the processing chain. I guess the chain
 is about 10 stages long (but user defined and not known in advance) and
 even with buffer = 1 for each stage there are 10 stale elements since the
 time buffers have been filled up (> 10 fast inputs). So there is a non
 acceptable lag on my "screen" regarding my example.
 Recently I tried to solve this by using a FlowGraph with one in-actor
 and one out-actor (PropsSource/PropsSink) passed. All in-elements are piped
 through my partial flow graph and passed to the out-actor. So outside of
 the main flowgraph after materialization I connected the out-actor to the
 in-actor so if the out-actor gets an element the in-actor is notified to
 send the next element into the processing chain. In addition the in-actor
 buffers all external incoming events and manages to discard old ones.
 My remaining problem is, that it is a user defined processing and I
 can't assume that one input element will generate exactly one output
 element. So I can determine when processing was done.



 Am Montag, 30. März 2015 14:06:59 UTC+2 schrieb rkuhn:
>
> Hi Peter,
>
> 30 mar 2015 kl. 13:30 skrev Peter Schmitz :
>
> Hi Roland,
>
> thank you for your detailed answer.
> In my timestamp example timestamps are processed while new timestamps
> arrive and at this point processing of old timestamps is obsolete but they
> are somewhere in the processing chain. Of course I can discard them at the
> end when dealing with timestamps (comparing with the current time) and
> perhaps (have to think about that) even when not dealing with timestamps
> but rather with some other inputstream with new incoming elements
> invalidating the processing of not fully processed elements before they 
> are
> stucked in the buffers of some stage(s) of my partial flowgraph.
> A synchronous processing of my partial(!) flowgraph avoids having
> elements that are obsolete AND not fully processed. I this manner only
> required elements are processed and CPU load is lower and more important a
> more realtime outcome.
> For example, say you have a stream of stock prices and you do some
> processing in a partial flowgraph and finally you show the result as some
> remolded "value" on a screen. If stockprices are faster generated than 
> your
> processing yielding a screen "value" can handle you won't see real time
> prices anymore and if the prices stream pauses emitting at stock exchange
> closing your screen is still refreshing until all involved intermediate
> buffers are drained.
> That won't happen with a certain buffer strategy (DropHead) for the
> stock prices stream and synchronous processing for the following partial
> flowgraph.
> So my program is not broken but it is not realtime and heats up my CPU
> more than necessary.
> Delay is inevitable because processing takes time but unnecessary
> delay of having obsolete elements in internal buffers is evitable.
>
>
> It seems that you are worrying a little too much: in practice all
> these buffers of size one will ever do is to allow pipelining of the
> processing of stages, which means that the latency of pushing something
> through the pipeline should not change much between this minimal buffer 
> and
> no buffering at all, while the throughput will increase due to the ability
>

Re: [akka-user] Re: how to tune akka remoting performance

[Viktor Klang]

Sounds like you're using too many FJ threads.

On Mon, Mar 30, 2015 at 6:36 PM, Ivan Balashov  wrote:

>
> While running the test I see that interrupts and context switches are
> rather high (for a 4 cpu core box)
>
> r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id
>> wa
>
> 5  0  0 2083556  11296 39838000 0 0 15491 39242 58 21
>>> 21  0
>>
>>  1  0  0 2110728  11304 39838000 0 7 17791 42876 50
>>> 21 29  0
>>
>>  0  0  0 2114272  11304 39838000 0 0 22580 47400 34
>>> 15 51  0
>>
>>  3  0  0 2132924  11304 39838000 0 4 26861 53711 26
>>> 10 65  0
>>
>>  0  0  0 2119648  11304 39838000 0 2 27225 54133 26
>>> 10 64  0
>>
>>
>
> Trying to adjust "akka.remote.default-remote-dispatcher.throughput" did
> not have any noticeable effect.
>
> Could anyone suggest how to reduce context switches with akka remoting in
> case of many small messages?
>
> Thanks,
>
>
> On Monday, March 30, 2015 at 1:38:40 PM UTC+3, Ivan Balashov wrote:
>>
>> Hi,
>>
>> Running simple Ping-Pong test (http://goo.gl/6gyWsd) between two JVMs on
>> same box (4 Cores, tested both on my laptop and GCE) gives me total
>> throughput 20K msg/sec, which are a CPU bound processes on both sides.
>>
>> Any ideas how you could manage 60K with almost idle CPU?
>>
>> Thanks,
>>
>> On Saturday, August 9, 2014 at 5:08:18 PM UTC+3, Sean Zhong wrote:
>>>
>>> For Akka 2.3.4, 2 machines, GbE network, one machine contains a sender
>>> actor, the other contains a reciver actor. Sender actor will continuously
>>> send message (100 bytes each, pre-created in memory) to receiver actor with
>>> simple flow control based on sliding window and acking(one ack per 100
>>> messages).
>>>
>>> I can only get throughput about 60K messages/second , which is much
>>> slower than my expectation. The CPU usage is almost idle(3%). Network usage
>>> is about 20% of the bandwidth.  I use kryo serialization, and
>>> singleConsumerUnboundedMailBox, 4 local dispatcher, 4 remote
>>> dispatcher, default setting for netty.
>>>
>>> Is there performance baseline  number for akka remoting in your smoke
>>> test?
>>>
>>>
>>>
>>>
>>>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: Memory leak somehow related to ask pattern

[Viktor Klang]

Wow, what an amazing catch!

On Tue, Mar 31, 2015 at 1:01 AM, Konrad Malawski <
konrad.malaw...@typesafe.com> wrote:

> Hi guys,
> quick update on the topic.
> It has indeed uncovered a bug in the PromiseActorRef.
> It does handle sending Termination properly, but did so with a mistaken
> actor in the Terminated(…) message, thus you wouldn’t get the Terminated
> you were waiting for, and the above explanation of Yaroslav completes the
> rest of the story.
>
> The fix is in this PR since today morning:
> https://github.com/akka/akka/pull/17102
> 
>
> Thanks for notifying us that something is fishy around there!
>
> --
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Typesafe 
>
> On 29 March 2015 at 09:33:49, Yaroslav Klymko (t3h...@gmail.com) wrote:
>
> So PrmiseActorRef is leaking and keeps reference on Promise &
> WriteEventsCompleted, still I'm not able to find a combination of
> dispatchers/actors to reproduce on simple example.
>
> On Saturday, March 28, 2015 at 9:33:15 PM UTC+2, Yaroslav Klymko wrote:
>>
>> Hi guys,
>> I have a very strange problem, it was originally spotted by @gfduszynski
>>  https://github.com/EventStore/EventStore.Akka.Persistence/issues/11
>>
>> Here is a problematic line of code
>>  https://github.com/EventStore/EventStore.Akka.Persistence/
>> blob/v2.0.0/src/main/scala/akka/persistence/eventstore/
>> journal/EventStoreJournal.scala#L28
>>
>> Basically it is a *actor ? WriteEvents* which returns
>> *Future[WriteEventsCompleted]*, these *WriteEventsCompleted* messages
>> are leaking, however *actor ! WriteEvents* is not leaking...
>> Also I couldn't reproduce this using simple app without akka persistence.
>>
>>  I will really appreciate any help, any ideas.
>> Thanks!
>>
>>
>>
>>
>> 
>>
>>
>>
>> 
>>
>>
>>
>>   --
> >> 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.
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: how to tune akka remoting performance

[Viktor Klang]

Could you share your entire config?

On Tue, Mar 31, 2015 at 5:31 PM, Ivan Balashov  wrote:

>
>
> On Tuesday, March 31, 2015 at 11:23:25 AM UTC+3, √ wrote:
>>
>> Sounds like you're using too many FJ threads.
>>
>
> I wish it was that simple. For both remoting and actor pool the same
> dispatcher is used (4 core box):
>
>   type = Dispatcher
>>   executor = "fork-join-executor"
>>   throughput = 1000  // Does this apply to FJ, or only to
>> ThreadPoolEx?
>>   fork-join-executor {
>> parallelism-min = 1
>> parallelism-max = 4
>>   }
>
>
> I get lower CS values if I set parallelism-max=1, maintaining about the
> same total throughput only with less cpu burn.
> However, it looks like CS should not depend much on whether we have 1 or 4
> or 10 FJ threads, most switching must be happing on deeper level, e.g.
> controlled by `throughput`.
>
>
>
>
>>   --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: how to tune akka remoting performance

[Viktor Klang]

Looks like you're using Java Serialization, a good first start would be to
switch serializers for your messages.

On Wed, Apr 1, 2015 at 3:49 PM, Ivan Balashov  wrote:

> Viktor,
>
> Here is the latest configuration that allowed to me reach 30msg/sec
> between 2 x 4cpu hosts in GCE network.
>
> http://goo.gl/sPnjQS
>
> On both sides context switches jumped to 30-50K/sec
>
> Client:
> 0  0  0 1528652  94396 79422800 0 4  468  772  0  0
> 100  0
>  2  0  0 1533988  94408 79422400 0 5 9051 16555 11  4
> 85  0
>  1  0  0 1326560  94412 79422400 0 6 28710 52792 34 13
> 54  0
>  2  0  0 1326188  94412 79422800 0 3 30209 59439 26  8
> 66  0
>  1  0  0 1325444  94420 79422800 0 4 26194 51556 24  6
> 70  0
>  1  0  0 1328172  94424 79422800 0 1  468  725  0  0
> 100  0
>
> Server:
>  3  0  0 827812  30372 206631600 0 3 9762 13188 48  7
> 45  0
>  1  0  0 564080  30388 206631600 0 3 19969 23901 29 13
> 59  0
>  4  0  0 416900  30388 206631600 0 0 24864 31988 39 13
> 48  0
>  1  0  0 241876  30388 206631600 0 3 24113 34808 42 11
> 47  0
>  4  0  0 145280  30404 201443200 0 2 21127 40357 44  6
> 50  0
>  2  0  0 106608  30404 196002400 0 0 19162 36545 47  6
> 47  0
>  4  0  0 138560  30328 186709200 0 6 14574 27803 57  4
> 39  0
>  2  0  0 293616  30336 186709200 0 4 6390 10023 42 12
> 46  0
>
> Couple more things that concerned me:
>
> 1) [WARN] [04/01/2015 12:54:26.125] [systemB-network-dispatcher-5]
> [akka.tcp://
> systemB@10.110.112.155:2001/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FsystemA%4010.110.47.70%3A2001-0/endpointWriter]
> [
> *473494*] buffered messages in EndpointWriter for [akka.tcp://
> systemA@10.110.47.70:2001]. *You should probably implement flow control
> to avoid flooding the remote connection.*
>
> Looks like either side is sending more messages than receiving is capable
> to accept. This however, might be cause by 1M network buffer, which, OTOH
> is needed for higher throughput.
> jFTR, GCE network is quite fast (my last measurement gives me 72Mb/sec,
> while during the test we barely hit 10Mb/sec).
>
> 2) Significant heap pressure, apparently caused by 1) and, as a
> consequence, some GC activity. Profiler gives me estimate of ~700bytes per
> every message in the queue, quickly growing heap. The slower messages get
> processed, the more of them are accumulated, the more cpu is needed for GC,
> chicken-egg.
>
> Any configuration advice to achieve better throughput in this scenario of
> many small messages?
>
>
> On Wednesday, April 1, 2015 at 10:59:32 AM UTC+3, √ wrote:
>>
>> Could you share your entire config?
>>
>> On Tue, Mar 31, 2015 at 5:31 PM, Ivan Balashov  wrote:
>>
>>>
>>>
>>> On Tuesday, March 31, 2015 at 11:23:25 AM UTC+3, √ wrote:

 Sounds like you're using too many FJ threads.

>>>
>>> I wish it was that simple. For both remoting and actor pool the same
>>> dispatcher is used (4 core box):
>>>
>>>   type = Dispatcher
   executor = "fork-join-executor"
   throughput = 1000  // Does this apply to FJ, or only to
 ThreadPoolEx?
   fork-join-executor {
 parallelism-min = 1
 parallelism-max = 4
   }
>>>
>>>
>>> I get lower CS values if I set parallelism-max=1, maintaining about the
>>> same total throughput only with less cpu burn.
>>> However, it looks like CS should not depend much on whether we have 1 or
>>> 4 or 10 FJ threads, most switching must be happing on deeper level, e.g.
>>> controlled by `throughput`.
>>>
>>>
>>>
>>>
   --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>  --
> >> 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@

Re: [akka-user] Akka io udp broadcast to subnet

[Viktor Klang]

Hi,

255.255.255.255 has been deprecated/discouraged for many many years.

Related:
http://stackoverflow.com/questions/7481332/udp-broadcast-on-java-doesnt-work

On Thu, Apr 2, 2015 at 10:27 PM,  wrote:

> I am trying to use akka-io to broadcast a UDP packet to all the nodes in
> my subnet? I am following up the scala example from
> http://doc.akka.io/docs/akka/snapshot/scala/io-udp.html
>
> Its not working if I am using 255.255.255.255. Although its working fine
> when I give direct IP - 10.172.137.125
>
> I tried the same task using java.net.DatagramSocket and it is working
> perfectly, i.e. i can receive the broadcast message on all subnet nodes,
> when sending using 255.255.255.255. So that means that there are no
> networking issues between machines. But if possible I want to do it using
> akka-io itself?
>
> I am new to network programming. Any ideas what I might be doing wrong?
>
> Let me know what more info can I provide to identify the issue.
>
>
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: Akka Stream is not running (without compiler error)

[Viktor Klang]

Works on my machine:

scala> import scala.collection.mutable.ArrayBuffer
import scala.collection.mutable.ArrayBuffer

scala> import akka.stream._
import akka.stream._

scala> import akka.stream.scaladsl._
import akka.stream.scaladsl._

scala> implicit val sys = ActorSystem("repl")
sys: akka.actor.ActorSystem = akka://repl

scala> import sys.dispatcher
import sys.dispatcher

scala> implicit val fm = ActorFlowMaterializer()
fm: akka.stream.ActorFlowMaterializer =
ActorFlowMaterializerImpl(ActorFlowMaterializerSettings(4,16,,,StreamSubscriptionTimeoutSettings(CancelTermination,5000
milliseconds),false,1000,Optimizations(false,false,false,false)),akka.dispatch.Dispatchers@3dff9cf6
,Actor[akka://repl/user/$b#575469743],1,flow,Optimizations(false,false,false,false))

scala> val source: Source[Int, Unit] = Source(1 to 10)
source: akka.stream.scaladsl.Source[Int,Unit] =
akka.stream.scaladsl.Source@4d8aca2f

scala> val printSink = Sink.foreach[Int](println)
printSink: akka.stream.scaladsl.Sink[Int,scala.concurrent.Future[Unit]] =
akka.stream.scaladsl.Sink@7d6cac88


scala> val actionStream: ArrayBuffer[(Int) => Int] =
ArrayBuffer.empty[(Int) => Int]
actionStream: scala.collection.mutable.ArrayBuffer[Int => Int] =
ArrayBuffer()

scala> def add(a: Int) = a + 1
add: (a: Int)Int

scala>

scala> def exec(): Unit =
 |   actionStream.drop(1).foldLeft(source)(
 | (source, action) => source.via(Flow[Int].mapAsync(e =>
Future(action(e
 |   ).runWith(printSink)
exec: ()Unit

scala>

scala> actionStream += add
res6: actionStream.type = ArrayBuffer()

scala> actionStream += add
res7: actionStream.type = ArrayBuffer(, )

scala> exec()

scala> 2
3
4
5
6
7
8
9
10
11

On Thu, Apr 2, 2015 at 11:29 PM, Allen Nie  wrote:

> I came up a much simplified program to test, and I still get nothing:
>
> val source: Source[Int, Unit] = Source(1 to 10)
> val printSink = Sink.foreach[Int](e => println(e))
>
> val actionStream: ArrayBuffer[(Int) => Int] = ArrayBuffer.empty[(Int) => Int]
>
> def add(a: Int) = a + 1
>
> def exec(): Unit = {
>   val sourceReady = actionStream.drop(1).foldLeft(source)
>   {(source, action) =>
> source.via(Flow[Int].mapAsync(e => Future(action.apply(e
>   }
>
>   sourceReady
>
>   sourceReady.runWith(printSink)
> }
>
> "parallel test" should "work" in {
>   actionStream += ((a: Int) => add(a))
>   actionStream += ((a: Int) => add(a))
>
>   exec()
> }
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Re: Akka Stream is not running (without compiler error)

[Viktor Klang]

I suspect your problem is that your test exits before the stream has a
chance to run.

On Thu, Apr 2, 2015 at 11:56 PM, Viktor Klang 
wrote:

> Works on my machine:
>
> scala> import scala.collection.mutable.ArrayBuffer
> import scala.collection.mutable.ArrayBuffer
>
> scala> import akka.stream._
> import akka.stream._
>
> scala> import akka.stream.scaladsl._
> import akka.stream.scaladsl._
>
> scala> implicit val sys = ActorSystem("repl")
> sys: akka.actor.ActorSystem = akka://repl
>
> scala> import sys.dispatcher
> import sys.dispatcher
>
> scala> implicit val fm = ActorFlowMaterializer()
> fm: akka.stream.ActorFlowMaterializer =
> ActorFlowMaterializerImpl(ActorFlowMaterializerSettings(4,16,,,StreamSubscriptionTimeoutSettings(CancelTermination,5000
> milliseconds),false,1000,Optimizations(false,false,false,false)),akka.dispatch.Dispatchers@3dff9cf6
> ,Actor[akka://repl/user/$b#575469743],1,flow,Optimizations(false,false,false,false))
>
> scala> val source: Source[Int, Unit] = Source(1 to 10)
> source: akka.stream.scaladsl.Source[Int,Unit] =
> akka.stream.scaladsl.Source@4d8aca2f
>
> scala> val printSink = Sink.foreach[Int](println)
> printSink: akka.stream.scaladsl.Sink[Int,scala.concurrent.Future[Unit]] =
> akka.stream.scaladsl.Sink@7d6cac88
>
>
> scala> val actionStream: ArrayBuffer[(Int) => Int] =
> ArrayBuffer.empty[(Int) => Int]
> actionStream: scala.collection.mutable.ArrayBuffer[Int => Int] =
> ArrayBuffer()
>
> scala> def add(a: Int) = a + 1
> add: (a: Int)Int
>
> scala>
>
> scala> def exec(): Unit =
>  |   actionStream.drop(1).foldLeft(source)(
>  | (source, action) => source.via(Flow[Int].mapAsync(e =>
> Future(action(e
>  |   ).runWith(printSink)
> exec: ()Unit
>
> scala>
>
> scala> actionStream += add
> res6: actionStream.type = ArrayBuffer()
>
> scala> actionStream += add
> res7: actionStream.type = ArrayBuffer(, )
>
> scala> exec()
>
> scala> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 11
>
> On Thu, Apr 2, 2015 at 11:29 PM, Allen Nie  wrote:
>
>> I came up a much simplified program to test, and I still get nothing:
>>
>> val source: Source[Int, Unit] = Source(1 to 10)
>> val printSink = Sink.foreach[Int](e => println(e))
>>
>> val actionStream: ArrayBuffer[(Int) => Int] = ArrayBuffer.empty[(Int) => Int]
>>
>> def add(a: Int) = a + 1
>>
>> def exec(): Unit = {
>>   val sourceReady = actionStream.drop(1).foldLeft(source)
>>   {(source, action) =>
>> source.via(Flow[Int].mapAsync(e => Future(action.apply(e
>>   }
>>
>>   sourceReady
>>
>>   sourceReady.runWith(printSink)
>> }
>>
>> "parallel test" should "work" in {
>>   actionStream += ((a: Int) => add(a))
>>   actionStream += ((a: Int) => add(a))
>>
>>   exec()
>> }
>>
>>  --
>> >>>>>>>>>> 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.
>>
>
>
>
> --
> Cheers,
> √
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  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.

Re: [akka-user] Re: Akka Stream is not running (without compiler error)

[Viktor Klang]

You'll need to either use a test framework which can deal with async tests
or you'll have to wait for the result and perform the assertion at the end
of each test.

-- 
Cheers,
√
On 3 Apr 2015 00:21, "Allen Nie"  wrote:

> Thank you Viktor!! I tried to switch from test to App, and it works. Also
> it works with Map instead of MapAsync.
>
> Does this mean I can not test this kind of things anymore? Is there
> anything I can do to still make the test case work??
>
> Sincerely,
> Allen
>
> On Thursday, April 2, 2015 at 6:04:24 PM UTC-4, √ wrote:
>
>> I suspect your problem is that your test exits before the stream has a
>> chance to run.
>>
>> On Thu, Apr 2, 2015 at 11:56 PM, Viktor Klang 
>> wrote:
>>
>>> Works on my machine:
>>>
>>> scala> import scala.collection.mutable.ArrayBuffer
>>> import scala.collection.mutable.ArrayBuffer
>>>
>>> scala> import akka.stream._
>>> import akka.stream._
>>>
>>> scala> import akka.stream.scaladsl._
>>> import akka.stream.scaladsl._
>>>
>>> scala> implicit val sys = ActorSystem("repl")
>>> sys: akka.actor.ActorSystem = akka://repl
>>>
>>> scala> import sys.dispatcher
>>> import sys.dispatcher
>>>
>>> scala> implicit val fm = ActorFlowMaterializer()
>>> fm: akka.stream.ActorFlowMaterializer = ActorFlowMaterializerImpl(
>>> ActorFlowMaterializerSettings(4,16,,,
>>> StreamSubscriptionTimeoutSettings(CancelTermination,5000
>>> milliseconds),false,1000,Optimizations(false,false,
>>> false,false)),akka.dispatch.Dispatchers@3dff9cf6,Actor[
>>> akka://repl/user/$b#575469743],1,flow,Optimizations(false,
>>> false,false,false))
>>>
>>> scala> val source: Source[Int, Unit] = Source(1 to 10)
>>> source: akka.stream.scaladsl.Source[Int,Unit] =
>>> akka.stream.scaladsl.Source@4d8aca2f
>>>
>>> scala> val printSink = Sink.foreach[Int](println)
>>> printSink: akka.stream.scaladsl.Sink[Int,scala.concurrent.Future[Unit]]
>>> = akka.stream.scaladsl.Sink@7d6cac88
>>>
>>>
>>> scala> val actionStream: ArrayBuffer[(Int) => Int] =
>>> ArrayBuffer.empty[(Int) => Int]
>>> actionStream: scala.collection.mutable.ArrayBuffer[Int => Int] =
>>> ArrayBuffer()
>>>
>>> scala> def add(a: Int) = a + 1
>>> add: (a: Int)Int
>>>
>>> scala>
>>>
>>> scala> def exec(): Unit =
>>>  |   actionStream.drop(1).foldLeft(source)(
>>>  | (source, action) => source.via(Flow[Int].mapAsync(e =>
>>> Future(action(e
>>>  |   ).runWith(printSink)
>>> exec: ()Unit
>>>
>>> scala>
>>>
>>> scala> actionStream += add
>>> res6: actionStream.type = ArrayBuffer()
>>>
>>> scala> actionStream += add
>>> res7: actionStream.type = ArrayBuffer(, )
>>>
>>> scala> exec()
>>>
>>> scala> 2
>>> 3
>>> 4
>>> 5
>>> 6
>>> 7
>>> 8
>>> 9
>>> 10
>>> 11
>>>
>>> On Thu, Apr 2, 2015 at 11:29 PM, Allen Nie  wrote:
>>>
>>>> I came up a much simplified program to test, and I still get nothing:
>>>>
>>>> val source: Source[Int, Unit] = Source(1 to 10)
>>>> val printSink = Sink.foreach[Int](e => println(e))
>>>>
>>>> val actionStream: ArrayBuffer[(Int) => Int] = ArrayBuffer.empty[(Int) => 
>>>> Int]
>>>>
>>>> def add(a: Int) = a + 1
>>>>
>>>> def exec(): Unit = {
>>>>   val sourceReady = actionStream.drop(1).foldLeft(source)
>>>>   {(source, action) =>
>>>> source.via(Flow[Int].mapAsync(e => Future(action.apply(e
>>>>   }
>>>>
>>>>   sourceReady
>>>>
>>>>   sourceReady.runWith(printSink)
>>>> }
>>>>
>>>> "parallel test" should "work" in {
>>>>   actionStream += ((a: Int) => add(a))
>>>>   actionStream += ((a: Int) => add(a))
>>>>
>>>>   exec()
>>>> }
>>>>
>>>>  --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/
>>>> current/additional/faq.html
>>>>

Re: [akka-user] Re: Best practices for selecting or creating actor

[Viktor Klang]

val ref = context.child(name).getOrElse(context.actorOf(props, name))

On Sun, Apr 5, 2015 at 11:53 PM, Adam  wrote:

> First of all, you shouldn't ever block like this, as you do with Await.
>
> As for your question - this sounds like something the parent actor should
> be responsible for.
> I'm not even sure the code above works (it at least never occurred to me
> to try to create an actor using a full path as I always understood the docs
> as if it shouldn't be possible).
> I think allowing the parent actor to determine if one of his children
> exists or not is cleaner.
> It also has direct access to this through the actor context, so the answer
> is immediate.
>
>
>
>
> On Sunday, April 5, 2015 at 10:50:28 PM UTC+3, Fatih Dönmez wrote:
>>
>> Hi,
>>
>> I want to create an actor if it didn't created already. To check its
>> existence I use actorSelection. If there is no actor defined by the path, I
>> create a new one with actorOf.
>> Is this approach correct? How can I improve the design? Here is the code
>> I come up with currently;
>>
>> val fullPath: String = path.format(appId)
>> var starter: ActorRef = null
>> implicit val timeout = Timeout(5 seconds)
>>
>> try {
>>   starter = Await.result(context.actorSelection(fullPath).
>> resolveOne,FiniteDuration(5,TimeUnit.SECONDS))
>> } catch {
>>   case e: ActorNotFound => {
>> starter = context.actorOf(Props(new StarterNode(customer,
>> appId)), name = fullPath)
>> logger.info("Actor [" + fullPath + "] creating for first time")
>>   }
>>   case e: Exception => logger.error("Actor [" + fullPath + "]
>> selection failed",e)
>> }
>>
>> //TODO
>> if(starter != null) {
>>   starter ! event
>> } else {
>>   logger.warn("Starter node failed with timeout")
>> }
>>
>>
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Refer to the same cluster-wide router from several actors in the cluster on the same node

[Viktor Klang]

actorOf creates a new actor, and in this case you're doing it at the system
level from within another actor:

val httpWorkers =
context.system.actorOf(FromConfig.props(Props.empty),
"cluster_router_httpworker")

That's the problem.


On Sun, Apr 5, 2015 at 6:54 PM, Eugene Dzhurinsky 
wrote:

> Hello!
>
> I have a cluster configuration like this:
>
> "/cluster_router_httpworker"  {
>   router = consistent-hashing-group
>   nr-of-instances = 10
>   routees.paths = [ "/user/router_httpworker" ]
>   cluster {
> enabled = on
> max-nr-of-instances-per-node = 5
> allow-local-routees = off
> use-role = "http"
>   }
> },
> "/cluster_router_chunkworker" {
>   router = consistent-hashing-group
>   nr-of-instances = 5
>   routees.paths = ["/user/router_chunkworker" ]
>   cluster {
> enabled = on
> max-nr-of-instances-per-node = 1
> allow-local-routees = off
> use-role = "chunk"
>   }
> }
>
>
> Now I start a *TaskChunkActor* the as below:
>
> val sys = ActorSystem("HttpCluster", config)
> val ref = sys.actorOf(Props[TaskChunkActor].withRouter(RoundRobinPool(10)), 
> "router_chunkworker")
> val clusterRef = sys.actorOf(FromConfig.props(Props.empty), 
> "cluster_router_chunkworker")
>
>
> The *TaskChunkActor* initializes its internal references to the
> *HttpWorker* :
>
> val httpWorkers = context.system.actorOf(FromConfig.props(Props.empty), 
> "cluster_router_httpworker")
>
>
> At this point I'm getting the exception:
>
> akka.actor.InvalidActorNameException: actor name [cluster_router_httpworker] 
> is not unique!
> at 
> akka.actor.dungeon.ChildrenContainer$NormalChildrenContainer.reserve(ChildrenContainer.scala:130)
> at akka.actor.dungeon.Children$class.reserveChild(Children.scala:76)
> at akka.actor.ActorCell.reserveChild(ActorCell.scala:369)
> at akka.actor.dungeon.Children$class.makeChild(Children.scala:201)
> at akka.actor.dungeon.Children$class.attachChild(Children.scala:41)
> at akka.actor.ActorCell.attachChild(ActorCell.scala:369)
> at akka.actor.ActorSystemImpl.actorOf(ActorSystem.scala:553)
>
>
> It seems that every *TaskChunkActor* tries to create it's own reference
> to the cluster-related actor, and fails.
>
> I see that I could pass the route to every instance of *TaskChunkActor*
> via constructor, but perhaps there's a way to either create an instance of
> the actor from config or return the existing one?
>
> Thanks!
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Java : How should Futures be handled when Unit testing?

[Viktor Klang]

Does this help?

http://christopher-batey.blogspot.se/2014/02/testing-scala-futures-with-scalatest-20.html

On Thu, Apr 9, 2015 at 1:27 PM, Adam Daines  wrote:

> Hi all,
>
> I've got a question in relation to the unit testing of a piece of non
> actor code that produces a Future via performing an
> actorSelection().resolveOne on the ActorSystem.
>
> Within the Future.onFailure() a value is being set that I would like to
> test but the Future is making use of the ActorSystem.dispatcher() which is
> therefore causing asynchronicity issues when attempting to Assert that the
> value has been set as expected.
>
> I am currently performing a Thread.sleep() within the Unit test to provide
> enough time for the value to have been set but this is far from ideal!
>
> What is the best way to go about testing this type of code without having
> to sleep and wait? Is it possible to override the dispatcher that the
> ActorSystem returns with the CallingThreadDispatcher?
>
> Thanks.
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] 2-way communication between Akka Streams and (remote) actors

[Viktor Klang]

You could have a mapAsync and use ask on the remote ActorRef?

On Thu, Apr 9, 2015 at 8:49 PM, Robin Green  wrote:

> Closely related to this question
> ,
> I know that Akka Streams do not yet support remote materialisation, but
> what if you want to have Akka Streams handle a local graph of stream
> processing, and have some intermediate processing work done by existing
> (possibly remote) actors? The way I would approach it is to have an
> ActorSubscriber as a sink to talk to each actor and an ActorPublisher as a
> source to receive results for each actor, but this is likely to lead to
> multiple flows or graphs that are disconnected from each other. Is there
> any more elegant way to approach it?
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Java : How should Futures be handled when Unit testing?

[Viktor Klang]

Hi Adam,

I generally recommend against using onComplete, onSuccess and onFailure for
that reason,
instead use map/flatMap/andThen/recover/recoverWith/transform

On Thu, Apr 9, 2015 at 4:14 PM, Adam Daines  wrote:

> Hi again,
>
> At first it had appeared that the issue was fully resolved but the test I
> had written began to fail again intermittently.
> It appears that taking the approach Endre suggested does not quite work as
> I had expected. It appears that the Await triggers and unblocks at the
> moment that the Future gets completed which is before the .onSuccess &
> .onFailure have actually run.
>
> In my use case the variable (which is a deferredResult) is actually set
> inside the .onFailure, therefore I cannot do an assertion on it until after
> the .onFailure has finished running.
>
> Any further assistance would be much appreciated.
>
> Thanks.
>
>
> On Thursday, April 9, 2015 at 1:46:22 PM UTC+1, Adam Daines wrote:
>>
>> Thank you both for the quick and helpful responses!
>> Our issue is now resolved :)
>>
>> Thanks.
>>
>> On Thursday, April 9, 2015 at 1:01:24 PM UTC+1, √ wrote:
>>>
>>> Ouch, nice catch, now we've covered both the question and the
>>> alternative (Scala) :)
>>>
>>> On Thu, Apr 9, 2015 at 1:59 PM, Akka Team  wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 9, 2015 at 1:33 PM, Viktor Klang 
>>>> wrote:
>>>>
>>>>> Does this help?
>>>>>
>>>>> http://christopher-batey.blogspot.se/2014/02/testing-
>>>>> scala-futures-with-scalatest-20.html
>>>>>
>>>>
>>>> That is for scala though. We usually use scala.concurrent.Await which
>>>> can be used like this
>>>>
>>>>   assert(Await.result(myFuture, timeoutDuration) == xyz)
>>>>
>>>> This will block the test and wait until the future becomes ready. If
>>>> the future completes then the assertion will run. If the future fails, then
>>>> Await.result() will throw the exception. If the future does not complete
>>>> during the time defined in timeoutDuration, then it will throw A
>>>> TimeoutException.
>>>>
>>>> -Endre
>>>>
>>>>
>>>>>
>>>>> On Thu, Apr 9, 2015 at 1:27 PM, Adam Daines 
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've got a question in relation to the unit testing of a piece of non
>>>>>> actor code that produces a Future via performing an
>>>>>> actorSelection().resolveOne on the ActorSystem.
>>>>>>
>>>>>> Within the Future.onFailure() a value is being set that I would like
>>>>>> to test but the Future is making use of the ActorSystem.dispatcher() 
>>>>>> which
>>>>>> is therefore causing asynchronicity issues when attempting to Assert that
>>>>>> the value has been set as expected.
>>>>>>
>>>>>> I am currently performing a Thread.sleep() within the Unit test to
>>>>>> provide enough time for the value to have been set but this is far from
>>>>>> ideal!
>>>>>>
>>>>>> What is the best way to go about testing this type of code without
>>>>>> having to sleep and wait? Is it possible to override the dispatcher that
>>>>>> the ActorSystem returns with the CallingThreadDispatcher?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> --
>>>>>> >>>>>>>>>> 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.
>>>>>> To post to this group, send email to akka...@googlegroups.com.
>>>>>> Visit this group at http://groups.google.com/group/akka-user.
>>>>>> For more options, vis

Re: [akka-user] akka-streams - How to define a Source from an arbitrary event stream?

[Viktor Klang]

  pushRecursively() onComplete {
case Failure(ex) =>
  onError(ex)
  context.stop(self)
case s =>
  }



that's not safe.


On Thu, Apr 9, 2015 at 1:16 PM, Jakub Liska  wrote:

> I do it just via ActorPublisher, the "scroll" method is basically
> asynchronously loading elasticsearch records (classic cursor thingy). It's
> a combination of request demand and asynchronous source of events :
>
>   def receive: Receive = {
> case Request(n) if totalDemand > 0 && n > 0 && isActive =>
>   def pushRecursively(n: Long = Math.min(n, totalDemand), scrollId: 
> String = lastScrollId): Future[Unit] = {
>
> scroll(scrollId) flatMap {
>   case (sid, recs) if recs.isEmpty => // empty hits means end of 
> scanning/scrolling
> onComplete()
> context.stop(self)
> Future.successful(())
>   case (sid, recs) =>
> lastScrollId = sid
> val contexts = recs.map {
>   case (recId, rec) => EsResource :: Map.empty[String, String] :: 
> recId :: rec :: HNil
> }
> onNext(contexts)
> if (n > 1)
>   pushRecursively(n-1, sid)
> else
>   Future.successful(())
> }
>   }
>
>   pushRecursively() onComplete {
> case Failure(ex) =>
>   onError(ex)
>   context.stop(self)
> case s =>
>   }
>
> case Cancel =>
>   context.stop(self)
>   }
> }
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] Java : How should Futures be handled when Unit testing?

[Viktor Klang]

Ouch, nice catch, now we've covered both the question and the alternative
(Scala) :)

On Thu, Apr 9, 2015 at 1:59 PM, Akka Team  wrote:

>
>
> On Thu, Apr 9, 2015 at 1:33 PM, Viktor Klang 
> wrote:
>
>> Does this help?
>>
>>
>> http://christopher-batey.blogspot.se/2014/02/testing-scala-futures-with-scalatest-20.html
>>
>
> That is for scala though. We usually use scala.concurrent.Await which can
> be used like this
>
>   assert(Await.result(myFuture, timeoutDuration) == xyz)
>
> This will block the test and wait until the future becomes ready. If the
> future completes then the assertion will run. If the future fails, then
> Await.result() will throw the exception. If the future does not complete
> during the time defined in timeoutDuration, then it will throw A
> TimeoutException.
>
> -Endre
>
>
>>
>> On Thu, Apr 9, 2015 at 1:27 PM, Adam Daines  wrote:
>>
>>> Hi all,
>>>
>>> I've got a question in relation to the unit testing of a piece of non
>>> actor code that produces a Future via performing an
>>> actorSelection().resolveOne on the ActorSystem.
>>>
>>> Within the Future.onFailure() a value is being set that I would like to
>>> test but the Future is making use of the ActorSystem.dispatcher() which is
>>> therefore causing asynchronicity issues when attempting to Assert that the
>>> value has been set as expected.
>>>
>>> I am currently performing a Thread.sleep() within the Unit test to
>>> provide enough time for the value to have been set but this is far from
>>> ideal!
>>>
>>> What is the best way to go about testing this type of code without
>>> having to sleep and wait? Is it possible to override the dispatcher that
>>> the ActorSystem returns with the CallingThreadDispatcher?
>>>
>>> Thanks.
>>>
>>> --
>>> >>>>>>>>>> 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.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>> --
>> >>>>>>>>>> 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.
>>
>
>
>
> --
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
>
> --
> >>>>>>>>>> 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.
>



-- 
Cheers,
√

-- 
>>>>>>>>>>  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.

Re: [akka-user] Re: akka-streams: FlexiRoute - route specific elements to specific outlets

[Viktor Klang]

What will you do if you get B's but only demand for As?

-- 
Cheers,
√
On 9 Apr 2015 19:10, "Andrey Kuznetsov"  wrote:

> If I change State condition to DemandFromAll, stage will wait for all
> outlets to start demanding but I need elements to be emitted as soon as
> possible.
>
> On Thursday, April 9, 2015 at 7:58:45 PM UTC+3, Andrey Kuznetsov wrote:
>>
>> I need to create a stage with one inlet accepting elements of type
>> Message and three outlets emitting elements of types A, B, C, all of which
>> are Message subtypes.
>> Depending on which element came (A, B or C) it should be emitted on one
>> of three outlets.
>> I am wondering how is it possible to achieve? If I create a State with
>> DemandFromAny(all three outlets), I have no guarantee that element passed
>> in State's onInput is an instance of type that demanding outlets should
>> emit.
>> Here is FlexiRoute example (I simplified it to Message, A, B and C types
>> to make in my app-context independent). It works only when it is so lucky
>> that element matches type of the demanding outlet.
>>
>> sealed trait Message
>> class A extends Message
>> class B extends Message
>> class C extends Message
>>
>> class MessageDiscriminatorShape(_init: Init[Message] = 
>> Name[Message]("MessageDiscriminator"))
>>   extends FanOutShape[Message](_init) {
>>   val outA = newOutlet[A]("outA")
>>   val outB = newOutlet[B]("outB")
>>   val outC = newOutlet[C]("outC")
>>
>>   protected override def construct(i: Init[Message]) = new 
>> MessageDiscriminatorShape(i)
>> }
>>
>> class MessageDiscriminator
>>   extends FlexiRoute[Message, MessageDiscriminatorShape](
>> new MessageDiscriminatorShape, 
>> OperationAttributes.name("MessageDiscriminator")) {
>>   import FlexiRoute._
>>
>>   override def createRouteLogic(p: PortT) = new RouteLogic[Message] {
>> override def initialState = State[Any](DemandFromAny(p.outlets)) {
>>   (ctx, _, element) =>
>> element match {
>>   case e: A =>
>> ctx.emit(p.outA)(e)
>>   case e: B =>
>> ctx.emit(p.outB)(e)
>>   case e: C =>
>> ctx.emit(p.outC)(e)
>> }
>>
>> SameState
>> }
>>
>> override def initialCompletionHandling = eagerClose
>>   }
>> }
>>
>>
>>
>>
>  --
> >> 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.
>

-- 
>>  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.

Re: [akka-user] How to restart a node?

[Viktor Klang]

The reason why it is not possible to rejoin is because other nodes have
already acted upon the death of that node.

Allowing the Undead in a cluster makes it really hard to reason about.

On Sat, Apr 11, 2015 at 1:36 AM, Andrey Ilinykh  wrote:

> Thank you! It works. But still there is a slim chance something goes wrong
> (for example java process crashed). What a reason not to allow the same
> actor system join multiple times? As far as I understand each actor system
> has internal UUID which is generated every time you start akka. If some how
> this UUID persists between restarts will akka cluster allow to join
> multiple times?
>
> Thank you,
>   Andrey
>
> On Friday, April 10, 2015 at 2:29:41 AM UTC-7, Akka Team wrote:
>>
>> Hi,
>>
>> Even if you turn off auto-downing you still have the programmatic API:
>> Cluster(system).down(address)
>>
>> So if you have a logic for downing that can be automatized (i.e.
>> expressed in Scala) the you can implement it by using the above API.
>>
>> But if I understood correctly, you want to stop a node gracefully before
>> starting up it again with new code. In this case (
>> http://doc.akka.io/docs/akka/2.3.9/scala/cluster-usage.html#Leaving):
>>
>> A more graceful exit can be performed if you tell the cluster that a node
>> shall leave. This can be performed using *JMX*
>> 
>>  or*Command Line Management*
>> .
>> It can also be performed programatically with Cluster(system).leave(
>> address).
>>
>> Note that this command can be issued to any member in the cluster, not
>> necessarily the one that is leaving. The cluster extension, but not the
>> actor system or JVM, of the leaving member will be shutdown after the
>> leader has changed status of the member to Exiting. Thereafter the
>> member will be removed from the cluster. Normally this is handled
>> automatically, but in case of network failures during this process it might
>> still be necessary to set the node’s status toDown in order to complete
>> the removal.
>> So if you have an API that can tell the node to restart, you can just
>>  - leave the cluster manually
>>  - after successfully leaving or timing out, shut down the actor system
>>
>> -Endre
>>
>> On Thu, Apr 9, 2015 at 8:52 PM, Andrey Ilinykh  wrote:
>>
>>> Hello everybody!
>>>
>>>
>>> I have a simple cluster with disabled auto downing. (I don't want a
>>> cluster to be partitioned eventually). As result every time I deploy new
>>> code node becomes unreachable. I have to down it manually. Which is
>>> annoying even you have two nodes. For big cluster it become nightmare. So,
>>> my question is - how to restart node easily. Or what is the best practice
>>> to deploy new code?
>>>
>>> Thank you,
>>>Andrey
>>>
>>> --
>>> >> 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.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Akka Team
>> Typesafe - Reactive apps on the JVM
>> Blog: letitcrash.com
>> Twitter: @akkateam
>>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] ReadPrefered in FlexiMerge (akka-streams)

[Viktor Klang]

Is if(input eq p.priority) also true?

On Mon, Apr 13, 2015 at 7:11 PM, Johannes Plapp 
wrote:

> Hi,
>
> While implementing a FlexiMerge we stumbled on the following issue:
>
> override def initialState =
>   State[T](ReadPreferred(p.priority, p.second)) {
> (ctx, input, element) =>
>   if(input == p.priority).. // always true
>   ctx.emit(element)
>   SameState
>   }
>
>
> Even if ReadPrefered returns an element from the second input, the
> returned input always equals the first one (p.priority).
>
> Is this intended behaviour? I also submitted a test covering this issue:
> https://github.com/akka/akka/issues/17157
>
> Thanks,
> Johannes Plapp
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] 2.4-SNAPSHOT Did bind-hostname/bind-port functionality change?

[Viktor Klang]

Hi Greg,

have you verified that the configuration is applied to the application?

On Tue, Apr 14, 2015 at 10:13 AM, tigerfoot  wrote:

> Hello,
>
> I had a working demo of Akka remoting working in a Docker container.  I
> ran my server in Docker and was able to communicate with it from an
> external program.  My application.conf looked like this:
>
> akka {
> loglevel = "ERROR"
> stdout-loglevel = "ERROR"
> loggers = ["akka.event.slf4j.Slf4jLogger"]
> actor {
> provider = akka.remote.RemoteActorRefProvider
> }
> remote {
> enabled-transports = ["akka.remote.netty.tcp"]
> netty.tcp {
> # Internal addr
> bind-hostname = localhost # also tried 127.0.0.1
> bind-port = 2551
>
> # External Docker addr
> hostname = "172.16.240.141"
> port = 9100
> }
> }
> }
>
> Boxed up I run my container like this (to map ports)--the web port mapping
> works fine:
>
> docker run -it -p 9100:2551 -p 9101:8080 --name dexp localhost:5000/root
>
> My client tries to connect to it like this:
>
> val c = ConfigFactory parseString """akka {
>
>   actor {
>
> provider = "akka.remote.RemoteActorRefProvider"
>
>   }
>
>   remote {
>
> enabled-transports = ["akka.remote.netty.tcp"]
>
> netty.tcp {
>
>   hostname = "localhost"
>
>   port = 5151
>
> }
>
>   }
>
> }"""
>
>
>
>   val sys = ActorSystem( "boom", c )
>
>   val actor = sys.actorSelection("akka.tcp://
> dockerexp@172.16.240.141:9100/user/dockerexp")
>
>   println("Actor: "+actor)
>
>   implicit val timo = Timeout(5.seconds)
>
>   try {
>
> println( Await.result( (actor ? "hey").asInstanceOf[Future[String]],
> 15.seconds) )
>
>   } finally {
>
> println("Dying...")
>
> Thread.sleep(5000)
>
> sys.shutdown()
>
>   }
>
> This isn't working anymore--just times out and dies.  It did work several
> months ago when 2.4-SNAPSHOT was first available.  Am I doing something
> wrong?
>
> Thanks,
> Greg
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.

Re: [akka-user] akka-http is there an example of showing how to integrate with servlet container?

[Viktor Klang]

One integration you can do easily is to have a ServletContextListener that
creates the Akka Http server endpoint when loaded and stops it on unload.

On Tue, Apr 14, 2015 at 3:53 PM, Roland Kuhn  wrote:

> Hi Tomer,
>
> the servlet container way of running things completely negates all the
> benefits that Akka HTTP would give you, so there is no point in supporting
> this scenario—spray-servlet will not be ported to Akka HTTP.
>
> Sorry for the bad news,
>
> Roland
>
> 14 apr 2015 kl. 15:45 skrev Jas :
>
> is there an example showing how to integrate servlet container with
> akka-http? i'm currently using spray with serlvet with
> https://github.com/spray/spray/blob/master/spray-servlet/src/main/scala/spray/servlet/Servlet30ConnectorServlet.scala
> and was hoping to find an example showing how to perform this with
> akka-http..
>
> thanks
>
> --
> >> 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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Reactive apps on the JVM.
> twitter: @rolandkuhn
> 
>
>  --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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.