Re: [akka-user] Re: Node quarantined

[Guido Medina]

Hi Ben,

As my experience goes Netty 3 doesn't get much love, issues are barely 
fixed,
like I mentioned before I'm running my own Netty 3.10.6 built internally, 
also; 3.10.0 is not even a good version,
if you want force your version to 3.10.5.Final until they release 
3.10.6.Final which has nice fixes.

or

you could get my branch, set the version to whatever is comfortable for you 
and build your own Netty,

My branch: https://github.com/guidomedina/netty/commits/3.10-SFS

has the following 
milestone: 
https://github.com/netty/netty/issues?q=milestone%3A3.10.6.Final+is%3Aclosed

plus some minor fixes I added myself, as of interest there is a race 
condition fixed at 3.10.6 and
I saw another between 3.10.0 and 3.10.5 which might be causing the issue 
you are experiencing.

HTH,

Guido.

-- 
>>  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: Node quarantined

[Benjamin Black]

I'm following up on this topic after upgrading to akka 2.3.15. I'm 
reasonably confident that the issue is the resullt of using akka along with 
another library that causes the netty dependency to be upgraded from 
3.9.2.Final to 3.10.0.Final. For now I have removed the dependency on the 
newer version of netty, but I thought I'd report what I was seeing in the 
logs. I am running five nodes for a few hours with no issue, and then two 
nodes fall out of the cluster. Here are the logs from each node:

IP: 160
13:59:57.252 INFO  [geyser-akka.actor.default-dispatcher-6] AngelOfTheAbyss 
- Unreachable member (Member(address = 
akka.tcp://geyser@172.16.119.42:7000, status = Up)|Size:4)
13:59:58.541 INFO  [geyser-akka.actor.default-dispatcher-306] 
AngelOfTheAbyss - Unreachable member (Member(address = 
akka.tcp://geyser@172.16.125.13:7000, status = Up)|Size:3)
14:00:11.540 INFO  [geyser-akka.actor.default-dispatcher-282] 
AngelOfTheAbyss - Member removed (Member(address = 
akka.tcp://geyser@172.16.119.42:7000, status = Removed)|Size:3)
14:00:11.541 INFO  [geyser-akka.actor.default-dispatcher-282] 
AngelOfTheAbyss - Member removed (Member(address = 
akka.tcp://geyser@172.16.125.13:7000, status = Removed)|Size:3)
14:00:11.545 WARN  [geyser-akka.remote.default-remote-dispatcher-8] 
Remoting - Association to [akka.tcp://geyser@172.16.119.42:7000] having UID 
[-477546934] is irrecoverably failed. UID is now quarantined and all 
messages to this UID will be delivered to dead letters. Remote actorsystem 
must be restarted to recover from this situation.
14:00:11.546 WARN  [geyser-akka.remote.default-remote-dispatcher-8] 
Remoting - Association to [akka.tcp://geyser@172.16.125.13:7000] having UID 
[-1471771858] is irrecoverably failed. UID is now quarantined and all 
messages to this UID will be delivered to dead letters. Remote actorsystem 
must be restarted to recover from this situation.

IP: 42
13:59:57.326 WARN  [geyser-cluster-dispatcher-15] a.c.ClusterCoreDaemon - 
Cluster Node [akka.tcp://geyser@172.16.119.42:7000] - Marking node(s) as 
UNREACHABLE [Member(address = akka.tcp://geyser@172.16.125.13:7000, status 
= Up)]
13:59:57.328 INFO  [geyser-akka.actor.default-dispatcher-46] 
AngelOfTheAbyss - Unreachable member (Member(address = 
akka.tcp://geyser@172.16.125.13:7000, status = Up)|Size:4)
14:00:07.345 INFO  [geyser-cluster-dispatcher-15] Cluster(akka://geyser) - 
Cluster Node [akka.tcp://geyser@172.16.119.42:7000] - Leader is 
auto-downing unreachable node [akka.tcp://geyser@172.16.125.13:7000]
14:00:07.346 INFO  [geyser-cluster-dispatcher-15] Cluster(akka://geyser) - 
Cluster Node [akka.tcp://geyser@172.16.119.42:7000] - Marking unreachable 
node [akka.tcp://geyser@172.16.125.13:7000] as [Down]
14:00:07.694 INFO  [geyser-cluster-dispatcher-15] Cluster(akka://geyser) - 
Cluster Node [akka.tcp://geyser@172.16.119.42:7000] - Shutting down...
14:00:07.695 INFO  [geyser-cluster-dispatcher-15] Cluster(akka://geyser) - 
Cluster Node [akka.tcp://geyser@172.16.119.42:7000] - Successfully shut down
14:00:07.703 WARN  [geyser-akka.remote.default-remote-dispatcher-27] 
Remoting - Association to [akka.tcp://geyser@172.16.125.13:7000] having UID 
[-1471771858] is irrecoverably failed. UID is now quarantined and all 
messages to this UID will be delivered to dead letters. Remote actorsystem 
must be restarted to recover from this situation.
14:00:10.360 WARN  [geyser-akka.remote.default-remote-dispatcher-7] 
a.r.ReliableDeliverySupervisor - Association with remote system 
[akka.tcp://geyser@172.16.119.46:7000] has failed, address is now gated for 
[5000] ms. Reason: [Disassociated]
14:00:11.361 WARN  [geyser-akka.remote.default-remote-dispatcher-7] 
a.r.ReliableDeliverySupervisor - Association with remote system 
[akka.tcp://geyser@172.17.110.139:7000] has failed, address is now gated 
for [5000] ms. Reason: [Disassociated]
14:00:11.544 WARN  [geyser-akka.remote.default-remote-dispatcher-7] 
a.r.ReliableDeliverySupervisor - Association with remote system 
[akka.tcp://geyser@172.16.120.160:7000] has failed, address is now gated 
for [5000] ms. Reason: [Disassociated]

IP: 13
13:59:57.244 WARN  [geyser-cluster-dispatcher-17] a.c.ClusterCoreDaemon - 
Cluster Node [akka.tcp://geyser@172.16.125.13:7000] - Marking node(s) as 
UNREACHABLE [Member(address = akka.tcp://geyser@172.16.119.42:7000, status 
= Up)]
13:59:57.245 INFO  [geyser-akka.actor.default-dispatcher-61] 
AngelOfTheAbyss - Unreachable member (Member(address = 
akka.tcp://geyser@172.16.119.42:7000, status = Up)|Size:4)
13:59:57.326 INFO  [geyser-cluster-dispatcher-15] Cluster(akka://geyser) - 
Cluster Node [akka.tcp://geyser@172.16.125.13:7000] - Ignoring received 
gossip status from unreachable 
[UniqueAddress(akka.tcp://geyser@172.16.119.42:7000,-477546934)]
14:00:07.711 WARN  [geyser-akka.remote.default-remote-dispatcher-7] 
a.r.ReliableDeliverySupervisor - Association with remote system 
[akka.tcp://geyser@172.16.119.42:7000] has failed, address is now gated 

[akka-user] Re: Testing Parent/Child with dependency injection

[Spencer Judge]

Whoops, forgot to change a name, that CLFSM in the second snippet should be 
"MyClass", and the first snippet is defined in "MyClass"'s companion object.

On Thursday, April 28, 2016 at 10:15:23 AM UTC-7, Spencer Judge wrote:
>
> Hi all,
>
> The section here: 
> http://doc.akka.io/docs/akka/2.4.4/scala/testing.html#Testing_parent-child_relationships
>
> Has some good advice on doing child creation via dep injection so I could 
> pass in mock children during testing. That's great, but the example is a 
> bit of a toy because you can't pass a name or non-default properties, which 
> makes it pretty useless for anything real-world.
>
> I ended up doing this:
>
> type ActorMaker = (ActorRefFactory, Props, String) => ActorRef
> private def childMaker(f: ActorRefFactory, p: Props, actorName: String) = {
>   f.actorOf(p, actorName)
> }
>
>
> class MyClass(...stuff...
>   childActorFactory: ActorMaker = CLFSM.childMaker)
>
>
> And then calling it like
>
> childActorFactory(context,
>   SomeChild.props(props, go, here),
>   "SomeName")
>
>
> That's fine, I guess, but seems a little uglier than necessary.
>
> I tried defining childMaker with an implicit ActorRefFactory, but then the 
> class can't compile because it's trying to find the ActorRefFactory 
> "outside" of the class, since that is where default values are evaluated.
>
> Is there a more clever way I can do this without having to pass "context" 
> every time inside my class? Is there a better way I can do it entirely?
>
> Thanks!
>
> Spencer
>

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

[akka-user] Testing Parent/Child with dependency injection

[Spencer Judge]

Hi all,

The section here: 
http://doc.akka.io/docs/akka/2.4.4/scala/testing.html#Testing_parent-child_relationships

Has some good advice on doing child creation via dep injection so I could 
pass in mock children during testing. That's great, but the example is a 
bit of a toy because you can't pass a name or non-default properties, which 
makes it pretty useless for anything real-world.

I ended up doing this:

type ActorMaker = (ActorRefFactory, Props, String) => ActorRef
private def childMaker(f: ActorRefFactory, p: Props, actorName: String) = {
  f.actorOf(p, actorName)
}


class MyClass(...stuff...
  childActorFactory: ActorMaker = CLFSM.childMaker)


And then calling it like

childActorFactory(context,
  SomeChild.props(props, go, here),
  "SomeName")


That's fine, I guess, but seems a little uglier than necessary.

I tried defining childMaker with an implicit ActorRefFactory, but then the 
class can't compile because it's trying to find the ActorRefFactory 
"outside" of the class, since that is where default values are evaluated.

Is there a more clever way I can do this without having to pass "context" 
every time inside my class? Is there a better way I can do it entirely?

Thanks!

Spencer

-- 
>>  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: Scheduler overflow

[Patrik Nordwall]

It would be great if you can create a reproducer in the SchedulerSpec:
https://github.com/akka/akka/blob/master/akka-actor-tests/src/test/scala/akka/actor/SchedulerSpec.scala

I think it has a way to drive the clock:
https://github.com/akka/akka/blob/master/akka-actor-tests/src/test/scala/akka/actor/SchedulerSpec.scala#L525

/Patrik

On Thu, Apr 28, 2016 at 2:23 PM, Eric Cartner 
wrote:

> What information can I provide to help out?
>
> On Thursday, April 28, 2016 at 5:11:39 AM UTC-5, Konrad Malawski wrote:
>>
>> Yes, the reported issue is might be real and I'd like to get more info on
>> it to investigate, I was arguing against the suggestion made to increase
>> the range of the scheduler.
>>
>> --
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 28 April 2016 at 12:10:03, Patrik Nordwall (patrik@gmail.com)
>> wrote:
>>
>> If I have not misunderstood the reported issue this is not about
>> scheduling something 50 days into the future, but after 50 days the
>> scheduler stops working. Scheduled tasks were typically around 8 ms.
>>
>> On Thu, Apr 28, 2016 at 12:07 PM, Konrad Malawski <
>> konrad@lightbend.com> wrote:
>>
>>> Is 50 days long enough? I think there is no right or wrong answer to
>>> that,
>>> a quick solution maybe will be to change from Integer to Long which will
>>> be an easy fix with a minimal effort, that should extend it to like 500
>>> days or more?
>>>
>>> No, because for long term scheduling you want to make sure the thing
>>> gets executed – i.e. you need persistence of the events, and also handling
>>> things like "it should have triggered in the past, but a node died, before
>>> doing it, so we need to run it now".
>>>
>>> These are design goals completely different from the Akka scheduler
>>> which is geared towards lots and lots of short and very quickly
>>> added/removed timeouts – think about all the ask timeouts in the system,
>>> there's tens of thousands of those and they last a few seconds.
>>>
>>>
>>> So there seems to be something wrong indeed, let's investigate, however
>>> it is not a goal to make the scheduler handle very large intervals – 50
>>> days is too much already one might argue actually, but we don't restrain
>>> more because why would we :)
>>>
>>> -- Konrad
>>> --
>>> >> 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 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+...@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.
>>
>>


-- 

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.

[akka-user] [akka-http][akka-streams] Back-pressure uploading big zip files

[Juan José Vázquez Delgado]

Hi all, 

I'm using akka-http for uploading big zip files (~ 1Gb) containing a bunch 
of files to parse. My goal is not to have to temporarily save to disk the 
file but reading it on the fly. In order to do this, we've written a 
`ZipInputStreamSource` that builds a `Source` from an `InputStream`. A zip 
`Source` would have the following type:

val zipSource: Source[(ZipEntryData, ByteString), Future[Long]]

where the `ZipEntryData` contains some info about the zip entry, e.g. the 
name, and the `ByteString` is the data chunk.

My code looks more or less like this:


```
def route = 
  pathPrefix("q") {
post {
  fileUpload("part-name") {
case (fileInfo, source) =>
  val sink = StreamConverters.asInputStream()
  val is = source.runWith(sink)
  val zipSource =
ZipInputStreamSource(() => is)
  .map { case (zed, bs) => (zed.name, bs) }
  .groupBy(1, _._1)
  .reduce((t1, t2) => (t2._1, t1._2 ++ t2._2))
  .async
  .mergeSubstreams

  
  complete(...)
  }
}
  }
```

Basically, we need to do some kind of `reduceByKey` behaviour in order to 
parse every zip entry as a whole (entries are XML files so we need to parse 
them completely and cannot be re-chunked).

So far so good. The problem is that we're not able to apply any 
back-pressure on the uploading process. Basically, when we upload the file 
with curl, the uploading process ends quickly but the service is blown up 
returning an OutOfMemory error as soon as the file is big enough.

> curl -O --form "part-name=@the_file.zip" -H "Transfer-Encoding: chunked" 
http://localhost:8080/q

How could I get the back-pressure behaviour as expected?.

Thanks in advance for your help.

Regards, 

Juanjo.

-- 
>>  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: Scheduler overflow

[Eric Cartner]

What information can I provide to help out?

On Thursday, April 28, 2016 at 5:11:39 AM UTC-5, Konrad Malawski wrote:
>
> Yes, the reported issue is might be real and I'd like to get more info on 
> it to investigate, I was arguing against the suggestion made to increase 
> the range of the scheduler.
>
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 28 April 2016 at 12:10:03, Patrik Nordwall (patrik@gmail.com 
> ) wrote:
>
> If I have not misunderstood the reported issue this is not about 
> scheduling something 50 days into the future, but after 50 days the 
> scheduler stops working. Scheduled tasks were typically around 8 ms.
>
> On Thu, Apr 28, 2016 at 12:07 PM, Konrad Malawski <
> konrad@lightbend.com > wrote:
>
>> Is 50 days long enough? I think there is no right or wrong answer to that,
>> a quick solution maybe will be to change from Integer to Long which will 
>> be an easy fix with a minimal effort, that should extend it to like 500 
>> days or more?
>>
>> No, because for long term scheduling you want to make sure the thing gets 
>> executed – i.e. you need persistence of the events, and also handling 
>> things like "it should have triggered in the past, but a node died, before 
>> doing it, so we need to run it now".
>>
>> These are design goals completely different from the Akka scheduler which 
>> is geared towards lots and lots of short and very quickly added/removed 
>> timeouts – think about all the ask timeouts in the system, there's tens of 
>> thousands of those and they last a few seconds.
>>
>>
>> So there seems to be something wrong indeed, let's investigate, however 
>> it is not a goal to make the scheduler handle very large intervals – 50 
>> days is too much already one might argue actually, but we don't restrain 
>> more because why would we :)
>>
>> -- Konrad
>> --
>> >> 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 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+...@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.

Re: [akka-user] snapshot's sequence_nr is 0 for first time running

[Patrik Nordwall]

what does your persistent actor look like?

On Mon, Apr 25, 2016 at 7:23 PM, Yan Pei  wrote:

> Got another issue.
>
> The logic is very simple: after sending certain number of messages, take a
> snapshot. But the sequence_nr is always 0 for the first time run. The
> second time, I saw some positive numbers in sequce_nr but the number is not
> what I am expecting.
>
>  persistence_id   |
> sequence_nr | ser_id | ser_manifest | snapshot | snapshot_data|
> timestamp
>
> --+-++--+--+--+---
>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist0/$a0 |
> 120 |  1 |  | null | 0xaced0005740004736e6170 |
> 1461603958981
>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist0/$a0 |
> 0 |  1 |  | null | 0xaced0005740004736e6170 |
> 1461603938737
>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist1/$a1 |
> 120 |  1 |  | null | 0xaced0005740004736e6170 |
> 1461603958977
>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist1/$a1 |
> 0 |  1 |  | null | 0xaced0005740004736e6170 |
> 1461603938737
>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist2/$a2 |
> 120 |  1 |  | null | 0xaced0005740004736e6170 |
> 1461603958970
>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist2/$a2 |
> 0 |  1 |  | null | 0xaced0005740004736e6170 |
> 1461603938732
>
>
>
> What did I miss?
>
> Thanks very much!
>
> Yan
>
> --
> >> 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.
>



-- 

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.

Re: [akka-user] How to transfer files between a local and remote actor

[Patrik Nordwall]

You can't send the file handle, unless you have a shared file system.

Actor messages should not be large. I would recommend Akka Streams, using
TCP or Http.

/Patrik

On Mon, Apr 25, 2016 at 5:09 AM, Raymond Guo  wrote:

> Hi,everyone:
>
> sorry that I'm just new to akka.
> I need to transfer some potentially large file between my remote actors
> asynchronously.
> Can I just wrap the file object in my message and tell it to my remote
> actor? Or should I use the underlying  java thread to perform socket stream
> independently then back to my actor mechanism?
>
>
> Can someone give me some advises? Thank you for any reply!
>
>
>
> --
> >> 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.
>



-- 

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.

Re: [akka-user] Re: Scheduler overflow

[Guido Medina]

I'm not arguing about it, all I saying is:

now in millis + times expressed as Integer limits it to 50 days
now in millis + times expressed as Long limits it to 1000s of days.

Guido.

On Thursday, April 28, 2016 at 11:11:39 AM UTC+1, Konrad Malawski wrote:
>
> Yes, the reported issue is might be real and I'd like to get more info on 
> it to investigate, I was arguing against the suggestion made to increase 
> the range of the scheduler.
>
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 28 April 2016 at 12:10:03, Patrik Nordwall (patrik@gmail.com 
> ) wrote:
>
> If I have not misunderstood the reported issue this is not about 
> scheduling something 50 days into the future, but after 50 days the 
> scheduler stops working. Scheduled tasks were typically around 8 ms.
>
> On Thu, Apr 28, 2016 at 12:07 PM, Konrad Malawski <
> konrad@lightbend.com > wrote:
>
>> Is 50 days long enough? I think there is no right or wrong answer to that,
>> a quick solution maybe will be to change from Integer to Long which will 
>> be an easy fix with a minimal effort, that should extend it to like 500 
>> days or more?
>>
>> No, because for long term scheduling you want to make sure the thing gets 
>> executed – i.e. you need persistence of the events, and also handling 
>> things like "it should have triggered in the past, but a node died, before 
>> doing it, so we need to run it now".
>>
>> These are design goals completely different from the Akka scheduler which 
>> is geared towards lots and lots of short and very quickly added/removed 
>> timeouts – think about all the ask timeouts in the system, there's tens of 
>> thousands of those and they last a few seconds.
>>
>>
>> So there seems to be something wrong indeed, let's investigate, however 
>> it is not a goal to make the scheduler handle very large intervals – 50 
>> days is too much already one might argue actually, but we don't restrain 
>> more because why would we :)
>>
>> -- Konrad
>> --
>> >> 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 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+...@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.

Re: [akka-user] Re: Scheduler overflow

[Guido Medina]

CPU wise in today's CPUs Long operations and comparison are faster than 
with Integer (Integers are up cast to Long) but
memory wise Long has 2 more bytes, GC wise I think there is more work to do 
with Integers than Long even if you end up consuming more longer term 
memory.

That's getting down to the bits of one vs another.

Guido.

On Thursday, April 28, 2016 at 11:07:23 AM UTC+1, Konrad Malawski wrote:
>
> Is 50 days long enough? I think there is no right or wrong answer to that,
> a quick solution maybe will be to change from Integer to Long which will 
> be an easy fix with a minimal effort, that should extend it to like 500 
> days or more?
>
> No, because for long term scheduling you want to make sure the thing gets 
> executed – i.e. you need persistence of the events, and also handling 
> things like "it should have triggered in the past, but a node died, before 
> doing it, so we need to run it now".
>
> These are design goals completely different from the Akka scheduler which 
> is geared towards lots and lots of short and very quickly added/removed 
> timeouts – think about all the ask timeouts in the system, there's tens of 
> thousands of those and they last a few seconds.
>
>
> So there seems to be something wrong indeed, let's investigate, however it 
> is not a goal to make the scheduler handle very large intervals – 50 days 
> is too much already one might argue actually, but we don't restrain more 
> because why would we :)
>
> -- Konrad
>

-- 
>>  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: Scheduler overflow

[Konrad Malawski]

Yes, the reported issue is might be real and I'd like to get more info on it to 
investigate, I was arguing against the suggestion made to increase the range of 
the scheduler.

-- 
Konrad `ktoso` Malawski
Akka @ Lightbend

On 28 April 2016 at 12:10:03, Patrik Nordwall (patrik.nordw...@gmail.com) wrote:

If I have not misunderstood the reported issue this is not about scheduling 
something 50 days into the future, but after 50 days the scheduler stops 
working. Scheduled tasks were typically around 8 ms.

On Thu, Apr 28, 2016 at 12:07 PM, Konrad Malawski 
 wrote:
Is 50 days long enough? I think there is no right or wrong answer to that,
a quick solution maybe will be to change from Integer to Long which will be an 
easy fix with a minimal effort, that should extend it to like 500 days or more?
No, because for long term scheduling you want to make sure the thing gets 
executed – i.e. you need persistence of the events, and also handling things 
like "it should have triggered in the past, but a node died, before doing it, 
so we need to run it now".

These are design goals completely different from the Akka scheduler which is 
geared towards lots and lots of short and very quickly added/removed timeouts – 
think about all the ask timeouts in the system, there's tens of thousands of 
those and they last a few seconds.



So there seems to be something wrong indeed, let's investigate, however it is 
not a goal to make the scheduler handle very large intervals – 50 days is too 
much already one might argue actually, but we don't restrain more because why 
would we :)

-- Konrad

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



--
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] Re: Scheduler overflow

[Patrik Nordwall]

If I have not misunderstood the reported issue this is not about scheduling
something 50 days into the future, but after 50 days the scheduler stops
working. Scheduled tasks were typically around 8 ms.

On Thu, Apr 28, 2016 at 12:07 PM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> Is 50 days long enough? I think there is no right or wrong answer to that,
> a quick solution maybe will be to change from Integer to Long which will
> be an easy fix with a minimal effort, that should extend it to like 500
> days or more?
>
> No, because for long term scheduling you want to make sure the thing gets
> executed – i.e. you need persistence of the events, and also handling
> things like "it should have triggered in the past, but a node died, before
> doing it, so we need to run it now".
>
> These are design goals completely different from the Akka scheduler which
> is geared towards lots and lots of short and very quickly added/removed
> timeouts – think about all the ask timeouts in the system, there's tens of
> thousands of those and they last a few seconds.
>
>
> So there seems to be something wrong indeed, let's investigate, however it
> is not a goal to make the scheduler handle very large intervals – 50 days
> is too much already one might argue actually, but we don't restrain more
> because why would we :)
>
> -- Konrad
>
> --
> >> 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.
>



-- 

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.

Re: [akka-user] Re: Scheduler overflow

[Konrad Malawski]

Is 50 days long enough? I think there is no right or wrong answer to that,
a quick solution maybe will be to change from Integer to Long which will be an 
easy fix with a minimal effort, that should extend it to like 500 days or more?
No, because for long term scheduling you want to make sure the thing gets 
executed – i.e. you need persistence of the events, and also handling things 
like "it should have triggered in the past, but a node died, before doing it, 
so we need to run it now".

These are design goals completely different from the Akka scheduler which is 
geared towards lots and lots of short and very quickly added/removed timeouts – 
think about all the ask timeouts in the system, there's tens of thousands of 
those and they last a few seconds.



So there seems to be something wrong indeed, let's investigate, however it is 
not a goal to make the scheduler handle very large intervals – 50 days is too 
much already one might argue actually, but we don't restrain more because why 
would we :)

-- Konrad

-- 
>>  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: Scheduler overflow

[Guido Medina]

I think for an in-memory scheduler it is reasonable to have it contained 
within an Integer (50 days),
in the micro-services world that is a long time to have the services 
restarted,
some good reason for a restart is to update dependencies as part of any 
standard maintenance cycle.

Is 50 days long enough? I think there is no right or wrong answer to that,
a quick solution maybe will be to change from Integer to Long which will be 
an easy fix with a minimal effort, that should extend it to like 500 days 
or more?

Hope that helps,

Guido.

On Thursday, April 28, 2016 at 10:55:52 AM UTC+1, Patrik Nordwall wrote:
>
> That is interesting. The scheduler will reject tasks scheduled too far 
> into the future, but you are not doing that. Please create an issue: 
> https://github.com/akka/akka/issues
>
> Regards,
> Patrik
>
> On Thu, Apr 28, 2016 at 9:49 AM, Guido Medina  > wrote:
>
>> Hi Eric,
>>
>> That's a hell of a finding, I think the immediate solution will be to 
>> change Int.MaxValue to Long.MaxValue, I don't think a system will be 
>> without restart for so many days, but who knows.
>>
>> Cheers,
>>
>> Guido.
>>
>>
>> On Thursday, April 28, 2016 at 7:43:57 AM UTC+1, Eric Cartner wrote:
>>>
>>> I've got an application with a crude bitrate throttle - a transmitter 
>>> actor receives a ByteString, writes it to a MulticastSocket and then 
>>> schedules an acknowledgement that it is ready for more data. The ack goes 
>>> to whomever sent the ByteString. The transmitter actor schedules delivery 
>>> of the ack via *scheduleOnce* using a small delay (typically around 8 
>>> ms). In this system I've dropped the scheduler tick duration down to 2ms.
>>>
>>> My application runs great except it stops transmitting after 
>>> approximately 50 days (actually a little under 50 days). The 50 day stop is 
>>> completely repeatable and happens on both Linux and OS X environments. No 
>>> exceptions or anything else unusual in the logs. The rest of the 
>>> application is completely functional. It's just not sending any more data. 
>>> I keep thinking that it acts like the transmitter has stopped sending acks.
>>>
>>> This morning I put two and two together (pun intended) and realized that 
>>> my tick duration of 2ms * Int.MaxValue is 49 days, 17 hours and change. 
>>> That sure seems like one hell of a coincidence. I've started looking at the 
>>> scheduler source and reading up on the timer wheel but I haven't yet found 
>>> anything that would explain what is happening.
>>>
>>> Does my throttle implementation seem reasonable or am I missing a giant 
>>> "You can't do that!" and simply trying to use the scheduler in a way it 
>>> can't be used?
>>>
>>> Any help will be greatly appreciated.
>>>
>> -- 
>> >> 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 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.

Re: [akka-user] Re: Scheduler overflow

[Patrik Nordwall]

That is interesting. The scheduler will reject tasks scheduled too far into
the future, but you are not doing that. Please create an issue:
https://github.com/akka/akka/issues

Regards,
Patrik

On Thu, Apr 28, 2016 at 9:49 AM, Guido Medina  wrote:

> Hi Eric,
>
> That's a hell of a finding, I think the immediate solution will be to
> change Int.MaxValue to Long.MaxValue, I don't think a system will be
> without restart for so many days, but who knows.
>
> Cheers,
>
> Guido.
>
>
> On Thursday, April 28, 2016 at 7:43:57 AM UTC+1, Eric Cartner wrote:
>>
>> I've got an application with a crude bitrate throttle - a transmitter
>> actor receives a ByteString, writes it to a MulticastSocket and then
>> schedules an acknowledgement that it is ready for more data. The ack goes
>> to whomever sent the ByteString. The transmitter actor schedules delivery
>> of the ack via *scheduleOnce* using a small delay (typically around 8
>> ms). In this system I've dropped the scheduler tick duration down to 2ms.
>>
>> My application runs great except it stops transmitting after
>> approximately 50 days (actually a little under 50 days). The 50 day stop is
>> completely repeatable and happens on both Linux and OS X environments. No
>> exceptions or anything else unusual in the logs. The rest of the
>> application is completely functional. It's just not sending any more data.
>> I keep thinking that it acts like the transmitter has stopped sending acks.
>>
>> This morning I put two and two together (pun intended) and realized that
>> my tick duration of 2ms * Int.MaxValue is 49 days, 17 hours and change.
>> That sure seems like one hell of a coincidence. I've started looking at the
>> scheduler source and reading up on the timer wheel but I haven't yet found
>> anything that would explain what is happening.
>>
>> Does my throttle implementation seem reasonable or am I missing a giant
>> "You can't do that!" and simply trying to use the scheduler in a way it
>> can't be used?
>>
>> Any help will be greatly appreciated.
>>
> --
> >> 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.
>



-- 

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.

[akka-user] Re: Akka streams TLS info available in later stages

[Konrad Malawski]

Hi Magnus,
As far as I remember this is not available, please open a ticket and let's 
discuss there.
We likely won't be able to focus on it, but it would be a nice 
contribution.. Also, the TLS stage needs to be rewritten to GraphStage, but 
that's a rather big and painful task (needs to be done eventually).

-- Konrad

W dniu czwartek, 28 kwietnia 2016 01:16:49 UTC+2 użytkownik Magnus 
Andersson napisał:
>
> Hi
>
> When looking at the TLS stage I cannot figure out if it is possible to 
> access the certificate that have been presented for during TLS two way 
> (client) authentication? It would be very useful to extract information 
> from that cert to identify the connecting client. I'm implementing an 
> existing TCP-protocol so I cannot add authentication into the normal 
> message flow.
>
> If this is not available would there be interest to add it?
>
> /Magnus
>

-- 
>>  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] Intended use for akka.Done and akka.NotUsed

[Bruno Bieth]

Well, I've suggested it: https://github.com/scala/scala/pull/5137

On Wednesday, April 27, 2016 at 4:41:07 PM UTC+2, Bruno Bieth wrote:
>
> I agree with Roland that having a Future[Unit] may lead to subtle bugs due 
> to the value discarding mechanism. My favorite is mixing map and flatMap by 
> mistake:
>
> // this compiles just fine: map[T] is infered to be map[Unit], then Future 
> { println("two"); Done } which is of type Future[Done] is discarded to 
> satisfy map[Unit]
> def compute: Future[Unit] = Future[Done] { println("one"); Done }.map( _ 
> => Future { println("two"); Done } )
>
> On the other hand:
>
> // won't compile!
> def compute: Future[Done] = Future[Done] { println("one"); Done }.map( _ 
> => Future { println("two"); Done } )
>
> Now, this could be a good reason for bringing this into the scala library?
>
> Bruno
>
>
> On Wednesday, February 24, 2016 at 5:12:24 PM UTC+1, rkuhn wrote:
>>
>> There is one other use that these types can be put to: Scala’s habit of 
>> conjuring a Unit out of thin air where needed can make it non-obvious where 
>> all the exit points of a method are. Declaring a different return type 
>> means that all such points need to be marked out explicitly. But outside 
>> the method this is not very useful (and this was also not the reason for 
>> the introduction of these types). As Patrik and Konrad note these are 
>> intended to be used a type parameters.
>>
>> Regards,
>>
>> Roland
>>
>> 24 feb 2016 kl. 15:36 skrev Konrad Malawski :
>>
>> Yeah, agree with Patrik here.
>> It's mostly for `Future[Done]` and situations like that, void/Unit is 
>> still fine in normal return values.
>>
>> -- 
>> Cheers,
>> Konrad 'ktoso’ Malawski
>> Akka  @ Lightbend 
>> 
>> 
>>
>> On 24 February 2016 at 13:35:02, Patrik Nordwall (patrik@gmail.com) 
>> wrote:
>>
>>
>>
>> On Wed, Feb 24, 2016 at 1:23 PM, rklaehn  wrote:
>>
>>> Hi Konrad,
>>>
>>> So, if it wasn't for backward compatibility, the return type of tell 
>>> would be akka.NotUsed, to signal that successful return does not tell you 
>>> anything about successful processing of the message (akka.Done would 
>>> certainly be wrong)?
>>>
>>
>> That would be to take it one step to far, I would say. Ordinary methods 
>> should still be declared with void (java) or Unit (scala) return types. 
>> Done and NotUsed are mostly interesting when the return value is not 
>> immediate, such as in a CompletionStage (java), Future (scala), or stream 
>> materialized value.
>>  
>>
>> Cheers,
>>
>> Rüdiger
>>
>> On Wednesday, February 24, 2016 at 11:43:33 AM UTC+1, Konrad Malawski 
>> wrote:
>> Hey Rüdiger,
>> yeah those can definitely be used in all kinds of APIs.
>> The reason we have them mostly in Streams for now is because we could not 
>> break compatibility in akka-actor for example.
>>
>> The types are intended to be simply more informative than plain `Unit`, 
>> so wherever that's needed feel free to use them :-)
>>
>> -- 
>> Cheers,
>> Konrad 'ktoso’ Malawski
>> Akka  @ Lightbend 
>> 
>> 
>>
>> On 24 February 2016 at 11:41:57, rklaehn (rkl...@gmail.com) wrote:
>>
>> Hi all,
>>
>> given the prominent position of akka.Done and akka.NotUsed: are these 
>> only meant to be used within akka streams, or also elsewhere?
>>
>> I am currently trying to introduce futures into a codebase with a lot of 
>> blocking, and it sure would be helpful to distinguish between methods 
>> returning Unit where successful return signals successful completion, and 
>> methods where successful return means nothing (e.g. because it is sending 
>> to some actor inside the method using !).
>>
>> Would this be a valid use case for using Done and NotUsed?
>>
>> Cheers,
>>
>> Rüdiger
>> --
>> >> 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 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] Scheduler overflow

[Eric Cartner]

I've got an application with a crude bitrate throttle - a transmitter actor 
receives a ByteString, writes it to a MulticastSocket and then schedules an 
acknowledgement that it is ready for more data. The ack goes to whomever 
sent the ByteString. The transmitter actor schedules delivery of the ack 
via *scheduleOnce* using a small delay (typically around 8 ms). In this 
system I've dropped the scheduler tick duration down to 2ms.

My application runs great except it stops transmitting after approximately 
50 days (actually a little under 50 days). The 50 day stop is completely 
repeatable and happens on both Linux and OS X environments. No exceptions 
or anything else unusual in the logs. The rest of the application is 
completely functional. It's just not sending any more data. I keep thinking 
that it acts like the transmitter has stopped sending acks.

This morning I put two and two together (pun intended) and realized that my 
tick duration of 2ms * Int.MaxValue is 49 days, 17 hours and change. That 
sure seems like one hell of a coincidence. I've started looking at the 
scheduler source and reading up on the timer wheel but I haven't yet found 
anything that would explain what is happening.

Does my throttle implementation seem reasonable or am I missing a giant 
"You can't do that!" and simply trying to use the scheduler in a way it 
can't be used?

Any help will be greatly appreciated.

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