Re: [akka-user] Re: Akka Stream Getting Stuck (2.4.9-RC2)

[Viktor Klang]

Create a reproducer?

-- 
Cheers,
√

On Aug 6, 2016 1:18 AM, "tigerfoot"  wrote:

> I should add that when it fails it just locks the stream--nothing further
> processed.  No errors or other output is produced.
>
> On Friday, August 5, 2016 at 6:11:34 PM UTC-5, tigerfoot wrote:
>>
>> I'm having a nasty issue I hope someone can help me with.
>>
>> I have some stream code like this:
>>
>>   val contentAssembly = Flow[CRec].map { crec =>
>> println("HERE!")
>> val x = expression.render(crec.value).
>> asInstanceOf[Message[OutputWrapper]]
>> println("X is "+x)
>> (crec, x)
>>   }
>>   val sendIt = Flow[(CRec, Message[OutputWrapper])].map { case (crec,
>> output) => println("THERE!"); sendAndNotifyFn(output); crec }
>>
>>   src ~> filter ~> contentAssembly ~> sendIt ~> commitQ ~>
>> Sink.ignore
>>  filter ~> commitQ ~> Sink.ignore
>>
>>
>> The two interesting stages are contentAssembly and sendIt.  About 1/2 the
>> time this works just fine.
>> When it works, I see output from the "HERE!" message, the "X" message,
>> and the "THERE" message.
>>
>> When it doesn't work I see HERE! and X but not the THERE.  As you can
>> see, there nothing in my code that happens between the "X" message in
>> contentAssembly and the THERE message in sendIt.
>>
>> My working theory is that somehow Akka Streams is sometimes losing the
>> supply/demand handshake between these two stages.
>>
>> I first noticed this on 2.4.7 then moved to 2.4.9-RC2 hoping someone had
>> found a bug, but no luck.
>>
>> What can I do to dig deeper and try to figure out what's going on between
>> contentAssembly and sendIt stages?
>>
>> 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 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.

[akka-user] Re: Akka Stream Getting Stuck (2.4.9-RC2)

[tigerfoot]

I should add that when it fails it just locks the stream--nothing further 
processed.  No errors or other output is produced.

On Friday, August 5, 2016 at 6:11:34 PM UTC-5, tigerfoot wrote:
>
> I'm having a nasty issue I hope someone can help me with.
>
> I have some stream code like this:
>
>   val contentAssembly = Flow[CRec].map { crec =>
> println("HERE!")
> val x = 
> expression.render(crec.value).asInstanceOf[Message[OutputWrapper]]
> println("X is "+x)
> (crec, x)
>   }
>   val sendIt = Flow[(CRec, Message[OutputWrapper])].map { case (crec, 
> output) => println("THERE!"); sendAndNotifyFn(output); crec }
>
>   src ~> filter ~> contentAssembly ~> sendIt ~> commitQ ~> Sink.ignore 
>  filter ~> commitQ ~> Sink.ignore
>
>
> The two interesting stages are contentAssembly and sendIt.  About 1/2 the 
> time this works just fine. 
> When it works, I see output from the "HERE!" message, the "X" message, and 
> the "THERE" message.
>
> When it doesn't work I see HERE! and X but not the THERE.  As you can see, 
> there nothing in my code that happens between the "X" message in 
> contentAssembly and the THERE message in sendIt.
>
> My working theory is that somehow Akka Streams is sometimes losing the 
> supply/demand handshake between these two stages.
>
> I first noticed this on 2.4.7 then moved to 2.4.9-RC2 hoping someone had 
> found a bug, but no luck.
>
> What can I do to dig deeper and try to figure out what's going on between 
> contentAssembly and sendIt stages?
>
> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka Stream Getting Stuck (2.4.9-RC2)

[tigerfoot]

I'm having a nasty issue I hope someone can help me with.

I have some stream code like this:

  val contentAssembly = Flow[CRec].map { crec =>
println("HERE!")
val x = 
expression.render(crec.value).asInstanceOf[Message[OutputWrapper]]
println("X is "+x)
(crec, x)
  }
  val sendIt = Flow[(CRec, Message[OutputWrapper])].map { case (crec, 
output) => println("THERE!"); sendAndNotifyFn(output); crec }

  src ~> filter ~> contentAssembly ~> sendIt ~> commitQ ~> Sink.ignore 
 filter ~> commitQ ~> Sink.ignore


The two interesting stages are contentAssembly and sendIt.  About 1/2 the 
time this works just fine. 
When it works, I see output from the "HERE!" message, the "X" message, and 
the "THERE" message.

When it doesn't work I see HERE! and X but not the THERE.  As you can see, 
there nothing in my code that happens between the "X" message in 
contentAssembly and the THERE message in sendIt.

My working theory is that somehow Akka Streams is sometimes losing the 
supply/demand handshake between these two stages.

I first noticed this on 2.4.7 then moved to 2.4.9-RC2 hoping someone had 
found a bug, but no luck.

What can I do to dig deeper and try to figure out what's going on between 
contentAssembly and sendIt stages?

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

[akka-user] Dynamically move proxied journal (PersistencePluginProxy) to another node

[oleksiys]

Hi,

I have a usecase, where I'd like to be able to move the proxied journal 
from one cluster node to another.
Looks like I can redirect all the journal clients using:

*PersistencePluginProxy.setTargetLocation(someNewLocation)*

But now on the cluster node, that has to host the journal I need to 
actually start the actual journal plugin (considering the default journal 
plugin is proxied-journal).
So I need a way to start a non-default journal plugin at runtime.

The closest I could get to it was:

*Persistence(system).adaptersFor(journalPluginId)*

it looks a bit hacky, but unfortunately:

*Persistence(system).journalFor(journalPluginId)*
*Persistence(system).snapshotStoreFor(snapshotStorePluginId)*

are all in the private[akka] scope.

Any suggestions?

Thank you.

WBR,
Alexey

-- 
>>  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 Cluster (with Sharding) not working without auto-down-unreachable-after

[Justin du coeur]

On Fri, Aug 5, 2016 at 2:02 PM, Endre Varga 
wrote:

> No, you are doing a great job explaining these! Maybe a guest blog post?
> (wink, wink, nudge, nudge ;) )
>

Thanks.  Everything's on an "as time permits" basis -- most of my attention
has to be on Querki -- but I'll consider writing something up.

There *is* a big blog post in the plans sometime in the next few weeks,
though, a case study on using Kryo for Akka Persistence.  (Which, knock on
wood, seems to be going decently well, but I have a *lot* of opinions on
the subject, some of them a tad idiosyncratic.)

FYI, while my blog is pretty diverse, this tag covers the programming topics
...

-- 
>>  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: Websockets and Flow.fromSinkAndSource

[Aditya Prasad]

For anyone interested: turns out it's an error in the doc. Closing the 
listening side is *not* supposed to close the sending side.

On Friday, July 29, 2016 at 6:28:14 PM UTC-7, Aditya Prasad wrote:
>
> Hi!
>
> I've got code like this:
>
>> val flow = Http().webSocketClientFlow(WebSocketRequest(s"ws://...")))
>> val sink = Sink.actorRef(actor, EventsComplete)
>> Source.tick[Message](KeepAliveDelay, KeepAliveDelay, 
>> KeepAlive).via(flow).runWith(sink)
>
>
> The Source.tick is there because if I use Source.empty, the websocket 
> connection gets closed immediately. The docs suggest using Source.maybe 
> instead, 
> but then the websocket is still closed after some timeout. I need my client 
> to listen forever.
>
> Anyway: if actor finishes (e.g., server requests a hangup and it gets an 
> EventsComplete), the websocket does not close. The ticking keeps going, 
> sending stuff over the wire.
>
> This is strange because the docs say it doesn't support half-closed 
> websockets[1]. Any guesses what's going on, and what I should do about it? 
> In my actual code, one method generates the Source, and another piece of 
> code creates the Actor and runs with that Source.
>
> For now I've got a nasty (though fun to code!) workaround, with a custom 
> TerminationWatcherKillSwitch thing so that Flow.fromSinkAndSource will 
> terminate one stream if the other terminates.
>
> Thanks!
>
> [1] 
> http://doc.akka.io/docs/akka/2.4.8/scala/http/client-side/websocket-support.html
>

-- 
>>  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 cluster node shutting down in the middle of processing requests

[Eric Swenson]

One more clue as to the cluster daemon's shutting itself down.  Earlier in 
the logs (although prior to several successful requests being handled), I 
find this:

[INFO] [08/05/2016 05:04:45.042] 
[ClusterSystem-akka.actor.default-dispatcher-5] 
[akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node 
[akka.tcp://ClusterSystem@10.0.3.103:2552] - Leader can currently not 
perform its duties, reachability status: 
[akka.tcp://ClusterSystem@10.0.3.103:2552 -> 
akka.tcp://ClusterSystem@10.0.3.102:2552: Unreachable [Unreachable] (16), 
akka.tcp://ClusterSystem@10.0.3.103:2552 -> 
akka.tcp://ClusterSystem@10.0.3.104:2552: Unreachable [Unreachable] (17), 
akka.tcp://ClusterSystem@10.0.3.103:2552 -> 
akka.tcp://ClusterSystem@10.0.3.176:2552: Unreachable [Unreachable] (18), 
akka.tcp://ClusterSystem@10.0.3.103:2552 -> 
akka.tcp://ClusterSystem@10.0.3.240:2552: Unreachable [Unreachable] (19)], 
member status: [akka.tcp://ClusterSystem@10.0.3.102:2552 Up seen=false, 
akka.tcp://ClusterSystem@10.0.3.103:2552 Up seen=true, 
akka.tcp://ClusterSystem@10.0.3.104:2552 Up seen=false, 
akka.tcp://ClusterSystem@10.0.3.176:2552 Up seen=false, 
akka.tcp://ClusterSystem@10.0.3.240:2552 Up seen=false]


All these log messages are from the node at IP address 10.0.3.103.  So I'm 
assuming this means the Leader is THIS node.  It seems to be saying that it 
cannot reach all the other cluster members, and because of that, it cannot 
do its job. This probably accounts for why it decided to shut itself down.  


There were 6 AWS EC2 instances running this application at the time (not 
10, as I said in an earlier message).  However, the cluster membership 
above, only shows 5 members at the time of this log message.  Not sure what 
happened to the other one.  


[akka.tcp://ClusterSystem@10.0.3.102:2552 Up seen=false,

 akka.tcp://ClusterSystem@10.0.3.103:2552 Up seen=true,

 akka.tcp://ClusterSystem@10.0.3.104:2552 Up seen=false,

 akka.tcp://ClusterSystem@10.0.3.176:2552 Up seen=false,

 akka.tcp://ClusterSystem@10.0.3.240:2552 Up seen=false]


I'm going to assume, not having any other evidence, that AWS/EC2 
experienced some network issue at the time in question, and consequently 
this node was not able to talk to the rest of the cluster and therefore 
this member (the leader) shut down.  I only have logs for one of the other 
5 cluster nodes, so I will check to see what that other node thought about 
all this at the time.  But I'm not very comfortable with the robustness of 
akka here.  I would have thought that the other cluster members could have, 
perhaps, noticing that the Leader was unreachable (assuming they couldn't 
reach it), and because I had auto-down-unreachable-after set (yes, yes, 
I've sense replaced this with manual downing logic -- but that is on our 
dev deployment and this issue happened on our staging deployment), elected 
a new leader and carried on -- even if this node became catatonic.  


This raises another point:  When the ClusterDaemon shuts itself down, it 
would appear that I should handle some event here (not sure how to do 
that), to cause the entire JVM to terminate.  This would cause AWS/ECS to 
launch a new instance to join the remaining cluster.


Thoughts?  -- Eric





-- 
>>  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 cluster node shutting down in the middle of processing requests

[Eric Swenson]

Also, what does this message mean?  I saw it earlier on in the logs:

[DEBUG] [08/05/2016 05:04:50.450] 
[ClusterSystem-akka.actor.default-dispatcher-17] 
[akka://ClusterSystem/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%4010.0.3.176%3A2552-6]
 
unhandled message from 
Actor[akka://ClusterSystem/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%4010.0.3.176%3A2552-6#1200432312]:
 
Ungate

On Friday, August 5, 2016 at 12:58:55 PM UTC-7, Eric Swenson wrote:
>
> Our akka-cluster-sharding service went down last night. In the middle of 
> processing akka-http requests (and sending these requests to a sharding 
> region for processing) on a 10-node cluster, one of the requests got an 
> "ask timeout" exception:
>
> [ERROR] [08/05/2016 05:04:51.077] 
> [ClusterSystem-akka.actor.default-dispatcher-16] 
> [akka.actor.ActorSystemImpl(ClusterSystem)] Error during processing of 
> request HttpRequest(HttpMetho\
>
> d(GET),
> http://eim.staging.example.com/eim/check/a0afbad4-69a8-4487-a6fb-f3e884a8d0aa?cache=false=15,List(Host:
>  
> eim.staging.example.com, X-Real-Ip: 10.0.3.9, X-Forwarded-Fo\
>
> r: 10.0.3.9, Connection: upgrade, Accept: */*, Accept-Encoding: gzip, 
> deflate, compress, Authorization: Bearer 
> aaa-1ZdrFpgR5AyOGa69Q2s3fwv_y5zz9UCL5F85Hc, User-Agent: python-requests\
>
> /2.2.1 CPython/2.7.6 Linux/3.13.0-74-generic, Timeout-Access: 
> ),HttpEntity.Strict(application/json,),HttpProtocol(HTTP/1.1))  
>
>
> akka.pattern.AskTimeoutException: 
> Recipient[Actor[akka://ClusterSystem/system/sharding/ExperimentInstance#-1675878517]]
>  
> had already been terminated. Sender[null] sent the message of t\
>
> ype "com.genecloud.eim.ExperimentInstance$Commands$CheckExperiment".   
> 
>  
>
> As the error message says, the reason for the ask timeout was because the 
> actor (sharding region?) had been terminated.  
>
> Looking back in the logs, I see that everything was going well for quite 
> some time, until the following:
>
>
> [DEBUG] [08/05/2016 05:04:50.480] 
> [ClusterSystem-akka.actor.default-dispatcher-2] [akka.tcp://
> ClusterSystem@10.0.3.103:2552/system/IO-TCP/selectors/$a/955] Resolving 
> login.dev.example.com before connecting
>
> [DEBUG] [08/05/2016 05:04:50.480] 
> [ClusterSystem-akka.actor.default-dispatcher-2] [akka.tcp://
> ClusterSystem@10.0.3.103:2552/system/IO-TCP/selectors/$a/955] Attempting 
> connection to [login.dev.example.com/52.14.30.100:443]
>
> [DEBUG] [08/05/2016 05:04:50.481] 
> [ClusterSystem-akka.actor.default-dispatcher-6] [akka.tcp://
> ClusterSystem@10.0.3.103:2552/system/IO-TCP/selectors/$a/955] Connection 
> established to [login.dev.example.com:443]
>
> [DEBUG] [08/05/2016 05:04:50.481] 
> [ClusterSystem-akka.actor.default-dispatcher-5] 
> [akka://ClusterSystem/system/IO-TCP] no longer watched by 
> Actor[akka://ClusterSystem/user/StreamSupervisor-7/$$H#-1778344261]
>
> [DEBUG] [08/05/2016 05:04:50.481] 
> [ClusterSystem-akka.actor.default-dispatcher-5] 
> [akka://ClusterSystem/system/IO-TCP/selectors/$a/955] now watched by 
> Actor[akka://ClusterSystem/user/StreamSupervisor-7/$$H#-1778344261]
>
> [DEBUG] [08/05/2016 05:04:50.483] 
> [ClusterSystem-akka.actor.default-dispatcher-17] 
> [akka://ClusterSystem/user/StreamSupervisor-7] now supervising 
> Actor[akka://ClusterSystem/user/Strea
> mSupervisor-7/flow-993-1-unknown-operation#819117275]
>
> [DEBUG] [08/05/2016 05:04:50.484] 
> [ClusterSystem-akka.actor.default-dispatcher-2] 
> [akka://ClusterSystem/user/StreamSupervisor-7/flow-993-1-unknown-operation] 
> started (akka.stream.impl.io.TLSActor@66dd942c)
>
> [INFO] [08/05/2016 05:04:50.526] 
> [ClusterSystem-akka.actor.default-dispatcher-17] 
> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
> ClusterSystem@10.0.3.103:2552] - Shutting down myself
>
> [INFO] [08/05/2016 05:04:50.527] 
> [ClusterSystem-akka.actor.default-dispatcher-17] 
> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
> ClusterSystem@10.0.3.103:2552] - Shutting down...
>
> [DEBUG] [08/05/2016 05:04:50.528] 
> [ClusterSystem-akka.actor.default-dispatcher-3] 
> [akka://ClusterSystem/system/cluster/core] stopping
>
> [DEBUG] [08/05/2016 05:04:50.528] 
> [ClusterSystem-akka.actor.default-dispatcher-16] 
> [akka://ClusterSystem/system/cluster/heartbeatReceiver] stopped
>
> [DEBUG] [08/05/2016 05:04:50.539] 
> [ClusterSystem-akka.actor.default-dispatcher-16] 
> [akka://ClusterSystem/system/cluster/metrics] stopped
>
> [DEBUG] [08/05/2016 05:04:50.540] 
> [ClusterSystem-akka.actor.default-dispatcher-18] 
> [akka://ClusterSystem/system/cluster] stopping
>
> [INFO] [08/05/2016 05:04:50.573] 
> [ClusterSystem-akka.actor.default-dispatcher-18] [akka.tcp://
> ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstanceCoordinator] 
> Self removed\
>
> 

[akka-user] Akka cluster node shutting down in the middle of processing requests

[Eric Swenson]

Our akka-cluster-sharding service went down last night. In the middle of 
processing akka-http requests (and sending these requests to a sharding 
region for processing) on a 10-node cluster, one of the requests got an 
"ask timeout" exception:

[ERROR] [08/05/2016 05:04:51.077] 
[ClusterSystem-akka.actor.default-dispatcher-16] 
[akka.actor.ActorSystemImpl(ClusterSystem)] Error during processing of 
request HttpRequest(HttpMetho\

d(GET),http://eim.staging.example.com/eim/check/a0afbad4-69a8-4487-a6fb-f3e884a8d0aa?cache=false=15,List(Host:
 
eim.staging.example.com, X-Real-Ip: 10.0.3.9, X-Forwarded-Fo\

r: 10.0.3.9, Connection: upgrade, Accept: */*, Accept-Encoding: gzip, 
deflate, compress, Authorization: Bearer 
aaa-1ZdrFpgR5AyOGa69Q2s3fwv_y5zz9UCL5F85Hc, User-Agent: python-requests\

/2.2.1 CPython/2.7.6 Linux/3.13.0-74-generic, Timeout-Access: 
),HttpEntity.Strict(application/json,),HttpProtocol(HTTP/1.1))  
   

akka.pattern.AskTimeoutException: 
Recipient[Actor[akka://ClusterSystem/system/sharding/ExperimentInstance#-1675878517]]
 
had already been terminated. Sender[null] sent the message of t\

ype "com.genecloud.eim.ExperimentInstance$Commands$CheckExperiment".   

 

As the error message says, the reason for the ask timeout was because the 
actor (sharding region?) had been terminated.  

Looking back in the logs, I see that everything was going well for quite 
some time, until the following:


[DEBUG] [08/05/2016 05:04:50.480] 
[ClusterSystem-akka.actor.default-dispatcher-2] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/IO-TCP/selectors/$a/955] 
Resolving login.dev.example.com before connecting

[DEBUG] [08/05/2016 05:04:50.480] 
[ClusterSystem-akka.actor.default-dispatcher-2] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/IO-TCP/selectors/$a/955] 
Attempting connection to [login.dev.example.com/52.14.30.100:443]

[DEBUG] [08/05/2016 05:04:50.481] 
[ClusterSystem-akka.actor.default-dispatcher-6] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/IO-TCP/selectors/$a/955] 
Connection established to [login.dev.example.com:443]

[DEBUG] [08/05/2016 05:04:50.481] 
[ClusterSystem-akka.actor.default-dispatcher-5] 
[akka://ClusterSystem/system/IO-TCP] no longer watched by 
Actor[akka://ClusterSystem/user/StreamSupervisor-7/$$H#-1778344261]

[DEBUG] [08/05/2016 05:04:50.481] 
[ClusterSystem-akka.actor.default-dispatcher-5] 
[akka://ClusterSystem/system/IO-TCP/selectors/$a/955] now watched by 
Actor[akka://ClusterSystem/user/StreamSupervisor-7/$$H#-1778344261]

[DEBUG] [08/05/2016 05:04:50.483] 
[ClusterSystem-akka.actor.default-dispatcher-17] 
[akka://ClusterSystem/user/StreamSupervisor-7] now supervising 
Actor[akka://ClusterSystem/user/Strea
mSupervisor-7/flow-993-1-unknown-operation#819117275]

[DEBUG] [08/05/2016 05:04:50.484] 
[ClusterSystem-akka.actor.default-dispatcher-2] 
[akka://ClusterSystem/user/StreamSupervisor-7/flow-993-1-unknown-operation] 
started (akka.stream.impl.io.TLSActor@66dd942c)

[INFO] [08/05/2016 05:04:50.526] 
[ClusterSystem-akka.actor.default-dispatcher-17] 
[akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node 
[akka.tcp://ClusterSystem@10.0.3.103:2552] - Shutting down myself

[INFO] [08/05/2016 05:04:50.527] 
[ClusterSystem-akka.actor.default-dispatcher-17] 
[akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node 
[akka.tcp://ClusterSystem@10.0.3.103:2552] - Shutting down...

[DEBUG] [08/05/2016 05:04:50.528] 
[ClusterSystem-akka.actor.default-dispatcher-3] 
[akka://ClusterSystem/system/cluster/core] stopping

[DEBUG] [08/05/2016 05:04:50.528] 
[ClusterSystem-akka.actor.default-dispatcher-16] 
[akka://ClusterSystem/system/cluster/heartbeatReceiver] stopped

[DEBUG] [08/05/2016 05:04:50.539] 
[ClusterSystem-akka.actor.default-dispatcher-16] 
[akka://ClusterSystem/system/cluster/metrics] stopped

[DEBUG] [08/05/2016 05:04:50.540] 
[ClusterSystem-akka.actor.default-dispatcher-18] 
[akka://ClusterSystem/system/cluster] stopping

[INFO] [08/05/2016 05:04:50.573] 
[ClusterSystem-akka.actor.default-dispatcher-18] 
[akka.tcp://ClusterSystem@10.0.3.103:2552/system/sharding/ExperimentInstanceCoordinator]
 
Self removed\

, stopping ClusterSingletonManager

[DEBUG] [08/05/2016 05:04:50.573] 
[ClusterSystem-akka.actor.default-dispatcher-18] 
[akka://ClusterSystem/system/sharding/ExperimentInstanceCoordinator] 
stopping


As you can see, from the "Resolving..." and "Attempting connection" log 
messages, an actor was happily sending off an HTTP request to another 
microservice using TLS, but just after this point, the cluster node said it 
was "Shutting down myself".  This killed the ClusterSingletonManager.  From 
that point on, all incoming requests to the shard region were rejected 
(because it was down).


Now the node was NOT down, and there are tons of messages after this point 
in the log -- and any request that 

Re: [akka-user] Akka Cluster (with Sharding) not working without auto-down-unreachable-after

[Endre Varga]

On Fri, Aug 5, 2016 at 12:04 AM, Justin du coeur  wrote:

> It does do reassignment -- but it has to know to do that.  Keep in mind
> that "down" is the master switch here: until the node is downed, the rest
> of the system doesn't *know* that NodeA should be avoided.  I haven't dug
> into that particular code, but I assume from what you're saying that the
> allocation algorithm doesn't take unreachability into account when choosing
> where to allocate the shard, just up/down.  I suspect that unreachability
> is too local and transient to use as the basis for these allocations.
>
> Keep in mind that you're looking at this from a relatively all-knowing
> global perspective, but each node is working from a very localized and
> imperfect one.  All it knows is "I can't currently reach NodeA".  It has no
> a priori way of knowing whether NodeA has been taken offline (so it should
> be avoided), or there's simply been a transient network glitch between here
> and there (so things are *mostly* business as usual).  Downing is how you
> tell it, "No, really, stop using this node"; until then, most of the code
> assumes that the more-common transient situation is the case.  It's
> *probably* possible to take unreachability into account in the case you're
> describing, but it doesn't surprise me if that's not true.
>
> Also, keep in mind that, IIRC, there are a few cluster singletons involved
> here, at least behind the scenes.  If NodeA currently owns one of the key
> singletons (such as the ShardCoordinator), and it hasn't been downed, I
> imagine the rest of the cluster is going to *quickly* lock up, because the
> result is that nobody is authorized to make these sorts of allocation
> decisions.
>
> All that said -- keep in mind, I'm just a user of this stuff, and am
> talking at the edges of my knowledge.  Konrad's the actual expert...
>

No, you are doing a great job explaining these! Maybe a guest blog post?
(wink, wink, nudge, nudge ;) )

-Endre



>
> On Thu, Aug 4, 2016 at 4:59 PM, Eric Swenson  wrote:
>
>> While I'm in the process of implementing your proposed solution, I did
>> want to make sure I understood why I'm seeing the failures I'm seeing when
>> a node is taken offline, auto-down is disabled, and no one is handling the
>> UnreachableNode message.  Let me try to explain what I think is happening
>> and perhaps you (or someone else who knows more about this than I) can
>> confirm or refute.
>>
>> In the case of akka-cluster-sharding, a shard might exist on the
>> unreachable node.  Since the node is not yet marked as "down", the cluster
>> simply cannot handle an incoming message for that shard.  To create another
>> sharded actor on an available cluster node might duplicate the unreachable
>> node state.  In the case of akka-persistence actors, even though a new
>> shard actor could resurrect any journaled state, we cannot be sure that the
>> old unreachable node might not at any time, add other events to the
>> journal, or come online and try to continue operating on the shard.
>>
>> Is that the reason why I see the following behavior:  NodeA is online.
>> NodeB comes online and joins the cluster.  A request comes in from
>> akka-http and is sent to the shard region.  It goes to NodeA which creates
>> an actor to handle the sharded object.  NodeA is taken offline (unbeknownst
>> to the akka-cluster).  Another message for the above-mentioned shard comes
>> in from akka-http and is sent to the shard region. The shard region can't
>> reach NodeA.  NodeA isn't marked as down.  So the shard region cannot
>> create another actor (on an available Node). It can only wait (until
>> timeout) for NodeA to become reachable.  Since, in my scenario, NodeA will
>> never become reachable and NodeB is the only one online, all requests for
>> old shards timeout.
>>
>> If the above logic is true, I have one last issue:  In the above
>> scenario, if a message comes into the shard region for a shard that WOULD
>> HAVE BEEN allocated to NodeA but has never yet been assigned to an actor on
>> NodeA, and NodeA is unreachable, why can it simply be assigned to another
>> Node?  is it because the shard-to-node algorithm is fixed (by default) and
>> there is no dynamic ability to "reassign" to an available Node?
>>
>> Thanks again.  -- Eric
>>
>> On Wednesday, August 3, 2016 at 7:00:42 PM UTC-7, Justin du coeur wrote:
>>>
>>> The keyword here is "auto".  Autodowning is an *incredibly braindead*
>>> algorithm for dealing with nodes coming out of service, and if you use it
>>> in production you more or less guarantee disaster, because that algorithm
>>> can't cope with cluster partition.  You *do* need to deal with downing, but
>>> you have to get something smarter than that.
>>>
>>> Frankly, if you're already hooking into AWS, I *suspect* the best
>>> approach is to leverage that -- when a node goes offline, you have some
>>> code to detect that through the ECS APIs, react to it, and 

Re: [akka-user] Akka Cluster (with Sharding) not working without auto-down-unreachable-after

[Eric Swenson]

Yes, thanks. I'll take a look at the default implementation and explore 
possible other implementations. I suspect, however, that the solution I've 
now implemented to "down" unreachable nodes if the AWS/ECS cluster says 
they are no longer there, will address my issues.  

On Friday, August 5, 2016 at 2:38:54 AM UTC-7, Johan Andrén wrote:
>
> You can however implement your own 
> akka.cluster.sharding.ShardCoordinator.ShardAllocationStrategy which will 
> allow you to take whatever you want into account, and deal with the 
> consequences thereof ofc ;) 
>
> --
> Johan
>
> On Friday, August 5, 2016 at 12:04:12 AM UTC+2, Justin du coeur wrote:
>>
>> It does do reassignment -- but it has to know to do that.  Keep in mind 
>> that "down" is the master switch here: until the node is downed, the rest 
>> of the system doesn't *know* that NodeA should be avoided.  I haven't dug 
>> into that particular code, but I assume from what you're saying that the 
>> allocation algorithm doesn't take unreachability into account when choosing 
>> where to allocate the shard, just up/down.  I suspect that unreachability 
>> is too local and transient to use as the basis for these allocations.
>>
>> Keep in mind that you're looking at this from a relatively all-knowing 
>> global perspective, but each node is working from a very localized and 
>> imperfect one.  All it knows is "I can't currently reach NodeA".  It has no 
>> a priori way of knowing whether NodeA has been taken offline (so it should 
>> be avoided), or there's simply been a transient network glitch between here 
>> and there (so things are *mostly* business as usual).  Downing is how you 
>> tell it, "No, really, stop using this node"; until then, most of the code 
>> assumes that the more-common transient situation is the case.  It's 
>> *probably* possible to take unreachability into account in the case you're 
>> describing, but it doesn't surprise me if that's not true.
>>
>> Also, keep in mind that, IIRC, there are a few cluster singletons 
>> involved here, at least behind the scenes.  If NodeA currently owns one of 
>> the key singletons (such as the ShardCoordinator), and it hasn't been 
>> downed, I imagine the rest of the cluster is going to *quickly* lock up, 
>> because the result is that nobody is authorized to make these sorts of 
>> allocation decisions.
>>
>> All that said -- keep in mind, I'm just a user of this stuff, and am 
>> talking at the edges of my knowledge.  Konrad's the actual expert...
>>
>> On Thu, Aug 4, 2016 at 4:59 PM, Eric Swenson > > wrote:
>>
>>> While I'm in the process of implementing your proposed solution, I did 
>>> want to make sure I understood why I'm seeing the failures I'm seeing when 
>>> a node is taken offline, auto-down is disabled, and no one is handling the 
>>> UnreachableNode message.  Let me try to explain what I think is happening 
>>> and perhaps you (or someone else who knows more about this than I) can 
>>> confirm or refute.
>>>
>>> In the case of akka-cluster-sharding, a shard might exist on the 
>>> unreachable node.  Since the node is not yet marked as "down", the cluster 
>>> simply cannot handle an incoming message for that shard.  To create another 
>>> sharded actor on an available cluster node might duplicate the unreachable 
>>> node state.  In the case of akka-persistence actors, even though a new 
>>> shard actor could resurrect any journaled state, we cannot be sure that the 
>>> old unreachable node might not at any time, add other events to the 
>>> journal, or come online and try to continue operating on the shard.
>>>
>>> Is that the reason why I see the following behavior:  NodeA is online.  
>>> NodeB comes online and joins the cluster.  A request comes in from 
>>> akka-http and is sent to the shard region.  It goes to NodeA which creates 
>>> an actor to handle the sharded object.  NodeA is taken offline (unbeknownst 
>>> to the akka-cluster).  Another message for the above-mentioned shard comes 
>>> in from akka-http and is sent to the shard region. The shard region can't 
>>> reach NodeA.  NodeA isn't marked as down.  So the shard region cannot 
>>> create another actor (on an available Node). It can only wait (until 
>>> timeout) for NodeA to become reachable.  Since, in my scenario, NodeA will 
>>> never become reachable and NodeB is the only one online, all requests for 
>>> old shards timeout.
>>>
>>> If the above logic is true, I have one last issue:  In the above 
>>> scenario, if a message comes into the shard region for a shard that WOULD 
>>> HAVE BEEN allocated to NodeA but has never yet been assigned to an actor on 
>>> NodeA, and NodeA is unreachable, why can it simply be assigned to another 
>>> Node?  is it because the shard-to-node algorithm is fixed (by default) and 
>>> there is no dynamic ability to "reassign" to an available Node? 
>>>
>>> Thanks again.  -- Eric
>>>
>>> On Wednesday, August 3, 2016 at 7:00:42 PM UTC-7, Justin du coeur 

Re: [akka-user] Akka Cluster (with Sharding) not working without auto-down-unreachable-after

[Eric Swenson]

Thanks Justin.  Makes good sense.  And I believe you've explained the lock 
up -- the shard coordinator singleton was probably on the unreacheable node 
(actually, it must have been, because prior to the second node's coming up, 
the first node was the only node) and since the cluster-of-two determined 
the first node to be unreachable, there was no shard coordinator accessible 
until the first node was "downed" and the shard coordinator moved to the 
second node.  

I appreciate all your insight. -- Eric

On Thursday, August 4, 2016 at 3:04:12 PM UTC-7, Justin du coeur wrote:
>
> It does do reassignment -- but it has to know to do that.  Keep in mind 
> that "down" is the master switch here: until the node is downed, the rest 
> of the system doesn't *know* that NodeA should be avoided.  I haven't dug 
> into that particular code, but I assume from what you're saying that the 
> allocation algorithm doesn't take unreachability into account when choosing 
> where to allocate the shard, just up/down.  I suspect that unreachability 
> is too local and transient to use as the basis for these allocations.
>
> Keep in mind that you're looking at this from a relatively all-knowing 
> global perspective, but each node is working from a very localized and 
> imperfect one.  All it knows is "I can't currently reach NodeA".  It has no 
> a priori way of knowing whether NodeA has been taken offline (so it should 
> be avoided), or there's simply been a transient network glitch between here 
> and there (so things are *mostly* business as usual).  Downing is how you 
> tell it, "No, really, stop using this node"; until then, most of the code 
> assumes that the more-common transient situation is the case.  It's 
> *probably* possible to take unreachability into account in the case you're 
> describing, but it doesn't surprise me if that's not true.
>
> Also, keep in mind that, IIRC, there are a few cluster singletons involved 
> here, at least behind the scenes.  If NodeA currently owns one of the key 
> singletons (such as the ShardCoordinator), and it hasn't been downed, I 
> imagine the rest of the cluster is going to *quickly* lock up, because the 
> result is that nobody is authorized to make these sorts of allocation 
> decisions.
>
> All that said -- keep in mind, I'm just a user of this stuff, and am 
> talking at the edges of my knowledge.  Konrad's the actual expert...
>
> On Thu, Aug 4, 2016 at 4:59 PM, Eric Swenson  > wrote:
>
>> While I'm in the process of implementing your proposed solution, I did 
>> want to make sure I understood why I'm seeing the failures I'm seeing when 
>> a node is taken offline, auto-down is disabled, and no one is handling the 
>> UnreachableNode message.  Let me try to explain what I think is happening 
>> and perhaps you (or someone else who knows more about this than I) can 
>> confirm or refute.
>>
>> In the case of akka-cluster-sharding, a shard might exist on the 
>> unreachable node.  Since the node is not yet marked as "down", the cluster 
>> simply cannot handle an incoming message for that shard.  To create another 
>> sharded actor on an available cluster node might duplicate the unreachable 
>> node state.  In the case of akka-persistence actors, even though a new 
>> shard actor could resurrect any journaled state, we cannot be sure that the 
>> old unreachable node might not at any time, add other events to the 
>> journal, or come online and try to continue operating on the shard.
>>
>> Is that the reason why I see the following behavior:  NodeA is online.  
>> NodeB comes online and joins the cluster.  A request comes in from 
>> akka-http and is sent to the shard region.  It goes to NodeA which creates 
>> an actor to handle the sharded object.  NodeA is taken offline (unbeknownst 
>> to the akka-cluster).  Another message for the above-mentioned shard comes 
>> in from akka-http and is sent to the shard region. The shard region can't 
>> reach NodeA.  NodeA isn't marked as down.  So the shard region cannot 
>> create another actor (on an available Node). It can only wait (until 
>> timeout) for NodeA to become reachable.  Since, in my scenario, NodeA will 
>> never become reachable and NodeB is the only one online, all requests for 
>> old shards timeout.
>>
>> If the above logic is true, I have one last issue:  In the above 
>> scenario, if a message comes into the shard region for a shard that WOULD 
>> HAVE BEEN allocated to NodeA but has never yet been assigned to an actor on 
>> NodeA, and NodeA is unreachable, why can it simply be assigned to another 
>> Node?  is it because the shard-to-node algorithm is fixed (by default) and 
>> there is no dynamic ability to "reassign" to an available Node? 
>>
>> Thanks again.  -- Eric
>>
>> On Wednesday, August 3, 2016 at 7:00:42 PM UTC-7, Justin du coeur wrote:
>>>
>>> The keyword here is "auto".  Autodowning is an *incredibly braindead* 
>>> algorithm for dealing with nodes coming out of 

Re: [akka-user] What is idiomatic way to share state on a local node.

[scala solist]

This approach does not work with complex data structures. They should be 
composable, each part separately addressable, other actors should be able 
to subscribe to the state changes individually. There should be a way to 
create read-only view for a data and so on.

Approach "just create actor and bunch of accessor messages for wrapped 
structure" could not scale and adapt for complex structures.
,
On Friday, August 5, 2016 at 5:45:13 PM UTC+3, Martynas Mickevičius wrote:
>
> One of the simplest solutions would be to model it as an actor itself.
>
> A fun challenge would also be to model backgammon board based on a 
> Conflict Free Replicated Data type. If you solve that, then you could use 
> Akka 
> Distributed Data 
>  module.
>
> On Fri, Aug 5, 2016 at 3:24 PM, scala solist  > wrote:
>
> For example, we would like to model the backgammon game with akka actors. 
>> Both players are actors (either human or AI), there is also an actor that 
>> rules the board and determines dice rolls for players. They all share the 
>> single board. What is idiomatic way to have access to the board and to take 
>> notifications on board position changes?
>>
>>

-- 
>>  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] [ANNOUNCE] Akka 2.4.9-RC2 released!

[Konrad 'ktoso' Malawski]

Dear hAkkers,

We—the Akka committers—are pleased to announce the availability of Akka 
2.4.9-RC2. 

This release does not change much over the previous Release Candidate, 
except fixing one OSGi plugin induced packaging problem which might have 
caused compilation errors, see issue #21105 
 if you want to know more about 
the root cause of the problem (it was related to sbt-osgi, which we have 
fixed in the plugin itself).

The 2.4.9 release is focused on improving Akka HTTP and Streams 
performance, for details about how HTTP throughput and latency has improved 
since 2.4.8 please refer to the 2.4.9-RC1 announcement 
.

Streaming performance of fused islands have been also improved, resulting 
in 20-30% speedup of elements processed per second (for more extreme 
scenarios the improvement range is between 10%-100%). This is due to one 
optimization that speeds up the common case of long push-pull loops, and 
also due to a memory layout reorganization that reduces indirect load 
pressure on the CPU inside the GraphInterpreter main loop, the workhorse of 
Akka Streams.

We would like to ask you to try out this Release Candidate and report any 
issues, if you happen to stumble upon any, via the mailing list 
, github issues 
, or gitter chat 
. After some community feedback about this RC 
will shortly release a stable version of it.


Credits:

commits added removed

   2 147 134 Konrad Malawski

   2   5  10 Endre Sándor Varga

   2  22   8 Johan Andrén

   1   1   1 Todd Ginsberg

   1   2   2 skchrko


The complete list of closed tickets can be found in the 2.4.9-RC2 milestone 
 on GitHub. 

Happy hakking!


-- 

Akka team


-- 
>>  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] Stashing vs Scala Collection

[Martynas Mickevičius]

Hi,

for the usecase you mentioned, it makes more sense for me to use a
collection, as you will be able to process exactly as many stashed requests
as you have available resources. You will also be able to track the number
of stashed resources and deal with overflow more easily.

On Thu, Aug 4, 2016 at 2:29 PM,  wrote:

>
> Hi all.
>
>
> I've been using akka in my application, but I've encountered a problem
> managing my resources.
>
> I have an actor which controls access to 3 pools of a limited resource.
> When one of these pools is depleated, I need to stash future requests to
> that pool, while still attending requests for the others.
>
> When one of the items in my pool is freed, I unstashAll to recover the
> requests for this resource.
>
> Should I unstashAll (with the inconvenience of reading messages that I'm
> going to stash again) or should I use some Scala Collection (presumably a
> queue) where I enqueue the messages until I can tend to them?
>
>
> Thank you in advance :)
>
> --
> >> 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] Distributed usage: 3rd party connectors (instead of TCP)

[Martynas Mickevičius]

Hi Michael,

I would assume that you want to implement network communication API based
on actors as it is done with TCP and UDP in Akka Io module
. Feel free to look
at the source code

of this module and design your connectors accordingly.

IMO this would be a better approach instead of implementing a custom
transport for Akka Remoting.

On Fri, Aug 5, 2016 at 12:42 PM, Michael Mangeng  wrote:

> Hi!
>
> i'm new to akka. Newer used it. Only played with activator.
>
> I think akka and especially the actor model would fit very very nicely on
> a new release of a project i'm working on.
> It's a distributed communication network where nodes are communicating via:
> * TCP (not really used currently).
> * HTTPS
> * Bluetooth Low Energy
> * A proprietary M2M Protocol. Mainly consisting of a up to 3k big messages
> which can be sent via this line.
> (All implemented in java.)
>
> === My question is now ===
> Can i extend akka to use https, bluetooth low energy as well as the
> proprietary m2m protocol and can somebody point me to e.g. a java package
> where i have to start.
> (As far as i can see, TCP is already available.)
>
> And are there topics where i have to pay special attention to while
> implementing those connectors?
>
>
> Additional information about the project:
> Communication Model:
> Server  < (M2M or HTTPS) > Master-Nodes  < (Bluetooth LE)
> > Slave Nodes
> The Server is on our companys server farm.
> The Master-Nodes as well as the Slave nodes are at production sites of our
> customers.
> a.) There can be multiple masters on a customer site.
> b.) The nodes on the customers site form a mesh of any form. (star- as
> well as line-formation).
>
> The nodes on the installations are mostly offline. They get online in a
> definable interval. (by default every 2 hours) via the M2M connectivity.
>
> greetings,
> Michael
>
>
> --
> >> 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] What is idiomatic way to share state on a local node.

[Martynas Mickevičius]

One of the simplest solutions would be to model it as an actor itself.

A fun challenge would also be to model backgammon board based on a Conflict
Free Replicated Data type. If you solve that, then you could use Akka
Distributed Data
 module.

On Fri, Aug 5, 2016 at 3:24 PM, scala solist  wrote:

> For example, we would like to model the backgammon game with akka actors.
> Both players are actors (either human or AI), there is also an actor that
> rules the board and determines dice rolls for players. They all share the
> single board. What is idiomatic way to have access to the board and to take
> notifications on board position changes?
>
> --
> >> 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] [akka-stream] How to emit the newest element every n seconds?

[Martynas Mickevičius]

Hi. You were quite close. Instead of buffer.drophead use conflate which is
a rate detached operation. That allows upstream before conflate progress
faster than downstream after the conflate.

Source
  .unfold(0) { e => Some((e + 1, e)) }
  .conflate[Int] { case (_, e) => e }
  .throttle(1, 1.second, 1, ThrottleMode.Shaping)
  .runForeach(println)

On Fri, Jul 29, 2016 at 4:27 PM, Dominykas Mostauskis <
dominykas.mostaus...@gmail.com> wrote:

> In Akka Stream, I'd like a stream with a timer that emits an element every
> n seconds. The timer should emit from a 1 element buffer that drops head on
> overflow (meaning only keeps the newest element). So essentially emit the
> newest element in intervals of n seconds. How can this be done?
>
> My attempts could not get me further than a stream that emits the newest
> element with a lag of n seconds, meaning the current timer's cycle doesn't
> sample new elements. It looked something like `in ~> buffer.drophead ~>
> throttle(1 element/per second)`.
>
> --
> >> 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.

[akka-user] What is idiomatic way to share state on a local node.

[scala solist]

For example, we would like to model the backgammon game with akka actors. 
Both players are actors (either human or AI), there is also an actor that 
rules the board and determines dice rolls for players. They all share the 
single board. What is idiomatic way to have access to the board and to take 
notifications on board position changes?

-- 
>>  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: explanation of pickMaxOfThree

[murtuza chhil]

Hi Gitted,

I am a newbie and not much of a scala guy

The example referenced is for producing the largest of the 3 numbers input.

zip1's zipwith is using 2 of the 3 numbers as input and producing one 
output that is the larger of the 2 numbers.
zip2's zipwith is going to use the third number and output of the max of 
zip1's 2 numbers getting you the largest of the 3 as output..

Look at  scaladoc  for zipwith 
 and 
zipwith2 
. 
The latter explains the in0, in1 and out (2 inputs 1 output)

UniformFanInShape takes an outlet and a number of inlets. [see doc here 

]
zip2.out is going to be the max value outputted and zip1.in0, zip1.in1 and 
zip2.in1 are going to take the 3 numbers as input (via the 
source.single(..)). 
Remember zip2.in0 is connected with zip1.out. 



-chhil

On Thursday, August 4, 2016 at 11:36:08 PM UTC+5:30, gitted wrote:
>
>
>1. Hello,
>
> Hoping someone can explain the example given herE: 
> http://doc.akka.io/docs/akka/2.4.9-RC1/scala/stream/stream-graphs.html
>
>1. 
>2. val pickMaxOfThree = GraphDSL.create() { implicit b =>
>3. import GraphDSL.Implicits._
>4.  
>5. val zip1 = b.add(ZipWith[Int, Int, Int](math.max _))
>6. val zip2 = b.add(ZipWith[Int, Int, Int](math.max _))
>7. zip1.out ~> zip2.in0
>8.  
>9. UniformFanInShape(zip2.out, zip1.in0, zip1.in1, zip2.in1)
>10. }
>
> This graph is returning a UniformFanInShape, which from what I understand 
> is multiple inputs and a single output correct?
>
> Can someone detail what this line is doing:
>
>1. val zip1 = b.add(ZipWith[Int, Int, Int](math.max _))
>
> Why does ZipWith have 3 type parameters? Is it just input, input and 
> output i.e [Int, Int, Int]
>
> Can someone explain what .out, .in0, .in1 etc. are doing here? 
>
>1. UniformFanInShape(zip2.out, zip1.in0, zip1.in1, zip2.in1)
>
>
>
>
>

-- 
>>  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: Multipart Fileupload problem with Akka 2.4.8 and 2.4.9-RC1

[Scott Lunel]

Ah ok that explains a lot.

No worries, thanks for the reply. I appreciate it!

On Friday, August 5, 2016 at 5:49:14 AM UTC-4, Konrad Malawski wrote:
>
> Hi Scott,
> OSGi messed up our RC1 release.
> Sorry for the trouble, though glad we did the RC which is there for 
> finding such issues before we release a stable version.
>
> The bug is explained in https://github.com/akka/akka/issues/21105 and 
> I've fixed both root cause and sbt plugin so we'll never have this issue 
> again.
> I'm releasing RC2 right now, please wait a bit and upgrade to it then.
>
> Thanks
>
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 5 August 2016 at 11:46:35, Scott Lunel (scott...@gmail.com 
> ) wrote:
>
> Hey, sorry but I have yet another stupid question. 
>
> All of my dependencies seem to be correct now, but when I switch from 
> version 2.4.8 to 2.4.9-RC1, I get this error:
>
> [ERROR] error: missing or invalid dependency detected while loading class 
> file 'Unmarshaller.class'.
> [INFO] Could not access type Unmarshaller in value 
> akka.http.javadsl.unmarshalling,
> [INFO] because it (or its dependencies) are missing. Check your build 
> definition for
> [INFO] missing or conflicting dependencies.
>
> It says in the migration documentation from 2.4.8 to 2.4.9-RC1 that the 
> package has been moved from akka.http.javadsl.server to the unmarshalling 
> one shown above.
>
> I can't seem to get around this error no matter what I do.
>
> On Thursday, August 4, 2016 at 11:28:56 AM UTC-4, Scott Lunel wrote: 
>>
>> Hello everyone, 
>>
>>
>> I seem to be having a problem with Multipart file upload since Akka 
>> 2.4.8. It works perfectly fine in 2.4.7.
>>
>> I've google searched for anything related to this and haven't found much, 
>> so I've decided to post here.
>>
>> Code to reproduce:
>>
>> val upload = path("upload") {
>> post {
>>   fileUpload("file") {
>> case (fileInfo, bytes) ⇒
>>   complete("Done")
>>   }
>> }
>> }
>>
>>
>> The exception:
>>
>> Uncaught error from thread [toplevel-akka.actor.default-dispatcher-10] 
>> shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for 
>> ActorSystem[toplevel]
>> java.lang.NoSuchMethodError: 
>> akka.stream.ActorMaterializer$.downcast(Lakka/stream/Materializer;)Lakka/stream/ActorMaterializer;
>> at 
>> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2$$anonfun$2.apply(MultipartUnmarshallers.scala:78)
>> at 
>> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2$$anonfun$2.apply(MultipartUnmarshallers.scala:78)
>> at scala.Option.getOrElse(Option.scala:121)
>> at 
>> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(MultipartUnmarshallers.scala:78)
>> at 
>> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(MultipartUnmarshallers.scala:71)
>> at 
>> akka.http.scaladsl.unmarshalling.Unmarshaller$$anon$1.apply(Unmarshaller.scala:52)
>> at 
>> akka.http.scaladsl.unmarshalling.LowerPriorityGenericUnmarshallers$$anonfun$messageUnmarshallerFromEntityUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(GenericUnmarshallers.scala:20)
>> at 
>> akka.http.scaladsl.unmarshalling.LowerPriorityGenericUnmarshallers$$anonfun$messageUnmarshallerFromEntityUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(GenericUnmarshallers.scala:20)
>> at 
>> akka.http.scaladsl.unmarshalling.Unmarshaller$$anon$1.apply(Unmarshaller.scala:52)
>>
>>
>> This appears to be throwing an exception when the code hits:
>>
>> entity(as[Multipart.FormData])
>>
>> I've written my own custom code to do multipart form file uploads and I 
>> initially suspected it was a problem on my end. However, after testing the 
>> above code (using one of the file upload directives), this error is being 
>> thrown in the akka http source.
>>
>> Is anyone else having this issue? I can't seem to get multipart file 
>> uploads to work in 2.4.8 and 2.4.9-RC1.
>>
>> Any help / information would be greatly appreciated.
>>
>>
>> Regards,
>>
>> Scott.
>>
> --
> >> 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/

Re: [akka-user] Re: Multipart Fileupload problem with Akka 2.4.8 and 2.4.9-RC1

[Konrad Malawski]

Hi Scott,
OSGi messed up our RC1 release.
Sorry for the trouble, though glad we did the RC which is there for finding
such issues before we release a stable version.

The bug is explained in https://github.com/akka/akka/issues/21105 and I've
fixed both root cause and sbt plugin so we'll never have this issue again.
I'm releasing RC2 right now, please wait a bit and upgrade to it then.

Thanks

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 5 August 2016 at 11:46:35, Scott Lunel (scott.lu...@gmail.com) wrote:

Hey, sorry but I have yet another stupid question.

All of my dependencies seem to be correct now, but when I switch from
version 2.4.8 to 2.4.9-RC1, I get this error:

[ERROR] error: missing or invalid dependency detected while loading class
file 'Unmarshaller.class'.
[INFO] Could not access type Unmarshaller in value
akka.http.javadsl.unmarshalling,
[INFO] because it (or its dependencies) are missing. Check your build
definition for
[INFO] missing or conflicting dependencies.

It says in the migration documentation from 2.4.8 to 2.4.9-RC1 that the
package has been moved from akka.http.javadsl.server to the unmarshalling
one shown above.

I can't seem to get around this error no matter what I do.

On Thursday, August 4, 2016 at 11:28:56 AM UTC-4, Scott Lunel wrote:
>
> Hello everyone,
>
>
> I seem to be having a problem with Multipart file upload since Akka 2.4.8.
> It works perfectly fine in 2.4.7.
>
> I've google searched for anything related to this and haven't found much,
> so I've decided to post here.
>
> Code to reproduce:
>
> val upload = path("upload") {
> post {
>   fileUpload("file") {
> case (fileInfo, bytes) ⇒
>   complete("Done")
>   }
> }
> }
>
>
> The exception:
>
> Uncaught error from thread [toplevel-akka.actor.default-dispatcher-10]
> shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
> ActorSystem[toplevel]
> java.lang.NoSuchMethodError: akka.stream.ActorMaterializer$
> .downcast(Lakka/stream/Materializer;)Lakka/stream/ActorMaterializer;
> at akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$
> anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$
> apply$2$$anonfun$2.apply(MultipartUnmarshallers.scala:78)
> at akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$
> anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$
> apply$2$$anonfun$2.apply(MultipartUnmarshallers.scala:78)
> at scala.Option.getOrElse(Option.scala:121)
> at akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$
> anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(
> MultipartUnmarshallers.scala:78)
> at akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$
> anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(
> MultipartUnmarshallers.scala:71)
> at akka.http.scaladsl.unmarshalling.Unmarshaller$$
> anon$1.apply(Unmarshaller.scala:52)
> at akka.http.scaladsl.unmarshalling.LowerPriorityGenericUnmarshall
> ers$$anonfun$messageUnmarshallerFromEntityUnmarshaller$1$$anonfun$apply$
> 1$$anonfun$apply$2.apply(GenericUnmarshallers.scala:20)
> at akka.http.scaladsl.unmarshalling.LowerPriorityGenericUnmarshall
> ers$$anonfun$messageUnmarshallerFromEntityUnmarshaller$1$$anonfun$apply$
> 1$$anonfun$apply$2.apply(GenericUnmarshallers.scala:20)
> at akka.http.scaladsl.unmarshalling.Unmarshaller$$
> anon$1.apply(Unmarshaller.scala:52)
>
>
> This appears to be throwing an exception when the code hits:
>
> entity(as[Multipart.FormData])
>
> I've written my own custom code to do multipart form file uploads and I
> initially suspected it was a problem on my end. However, after testing the
> above code (using one of the file upload directives), this error is being
> thrown in the akka http source.
>
> Is anyone else having this issue? I can't seem to get multipart file
> uploads to work in 2.4.8 and 2.4.9-RC1.
>
> Any help / information would be greatly appreciated.
>
>
> Regards,
>
> Scott.
>
--
>> 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 

[akka-user] Re: Multipart Fileupload problem with Akka 2.4.8 and 2.4.9-RC1

[Scott Lunel]

Hey, sorry but I have yet another stupid question.

All of my dependencies seem to be correct now, but when I switch from 
version 2.4.8 to 2.4.9-RC1, I get this error:

[ERROR] error: missing or invalid dependency detected while loading class 
file 'Unmarshaller.class'.
[INFO] Could not access type Unmarshaller in value 
akka.http.javadsl.unmarshalling,
[INFO] because it (or its dependencies) are missing. Check your build 
definition for
[INFO] missing or conflicting dependencies.

It says in the migration documentation from 2.4.8 to 2.4.9-RC1 that the 
package has been moved from akka.http.javadsl.server to the unmarshalling 
one shown above.

I can't seem to get around this error no matter what I do.

On Thursday, August 4, 2016 at 11:28:56 AM UTC-4, Scott Lunel wrote:
>
> Hello everyone,
>
>
> I seem to be having a problem with Multipart file upload since Akka 2.4.8. 
> It works perfectly fine in 2.4.7.
>
> I've google searched for anything related to this and haven't found much, 
> so I've decided to post here.
>
> Code to reproduce:
>
> val upload = path("upload") {
> post {
>   fileUpload("file") {
> case (fileInfo, bytes) ⇒
>   complete("Done")
>   }
> }
> }
>
>
> The exception:
>
> Uncaught error from thread [toplevel-akka.actor.default-dispatcher-10] 
> shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for 
> ActorSystem[toplevel]
> java.lang.NoSuchMethodError: 
> akka.stream.ActorMaterializer$.downcast(Lakka/stream/Materializer;)Lakka/stream/ActorMaterializer;
> at 
> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2$$anonfun$2.apply(MultipartUnmarshallers.scala:78)
> at 
> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2$$anonfun$2.apply(MultipartUnmarshallers.scala:78)
> at scala.Option.getOrElse(Option.scala:121)
> at 
> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(MultipartUnmarshallers.scala:78)
> at 
> akka.http.scaladsl.unmarshalling.MultipartUnmarshallers$$anonfun$multipartUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(MultipartUnmarshallers.scala:71)
> at 
> akka.http.scaladsl.unmarshalling.Unmarshaller$$anon$1.apply(Unmarshaller.scala:52)
> at 
> akka.http.scaladsl.unmarshalling.LowerPriorityGenericUnmarshallers$$anonfun$messageUnmarshallerFromEntityUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(GenericUnmarshallers.scala:20)
> at 
> akka.http.scaladsl.unmarshalling.LowerPriorityGenericUnmarshallers$$anonfun$messageUnmarshallerFromEntityUnmarshaller$1$$anonfun$apply$1$$anonfun$apply$2.apply(GenericUnmarshallers.scala:20)
> at 
> akka.http.scaladsl.unmarshalling.Unmarshaller$$anon$1.apply(Unmarshaller.scala:52)
>
>
> This appears to be throwing an exception when the code hits:
>
> entity(as[Multipart.FormData])
>
> I've written my own custom code to do multipart form file uploads and I 
> initially suspected it was a problem on my end. However, after testing the 
> above code (using one of the file upload directives), this error is being 
> thrown in the akka http source.
>
> Is anyone else having this issue? I can't seem to get multipart file 
> uploads to work in 2.4.8 and 2.4.9-RC1.
>
> Any help / information would be greatly appreciated.
>
>
> Regards,
>
> Scott.
>

-- 
>>  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] Distributed usage: 3rd party connectors (instead of TCP)

[Michael Mangeng]

Hi!

i'm new to akka. Newer used it. Only played with activator.

I think akka and especially the actor model would fit very very nicely on a 
new release of a project i'm working on.
It's a distributed communication network where nodes are communicating via:
* TCP (not really used currently).
* HTTPS
* Bluetooth Low Energy
* A proprietary M2M Protocol. Mainly consisting of a up to 3k big messages 
which can be sent via this line.
(All implemented in java.)

=== My question is now ===
Can i extend akka to use https, bluetooth low energy as well as the 
proprietary m2m protocol and can somebody point me to e.g. a java package 
where i have to start.
(As far as i can see, TCP is already available.)

And are there topics where i have to pay special attention to while 
implementing those connectors?


Additional information about the project:
Communication Model:
Server  < (M2M or HTTPS) > Master-Nodes  < (Bluetooth LE) > 
Slave Nodes
The Server is on our companys server farm.
The Master-Nodes as well as the Slave nodes are at production sites of our 
customers.
a.) There can be multiple masters on a customer site.
b.) The nodes on the customers site form a mesh of any form. (star- as well 
as line-formation).

The nodes on the installations are mostly offline. They get online in a 
definable interval. (by default every 2 hours) via the M2M connectivity.

greetings,
Michael


-- 
>>  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 Cluster (with Sharding) not working without auto-down-unreachable-after

[Johan Andrén]

You can however implement your own 
akka.cluster.sharding.ShardCoordinator.ShardAllocationStrategy which will 
allow you to take whatever you want into account, and deal with the 
consequences thereof ofc ;) 

--
Johan

On Friday, August 5, 2016 at 12:04:12 AM UTC+2, Justin du coeur wrote:
>
> It does do reassignment -- but it has to know to do that.  Keep in mind 
> that "down" is the master switch here: until the node is downed, the rest 
> of the system doesn't *know* that NodeA should be avoided.  I haven't dug 
> into that particular code, but I assume from what you're saying that the 
> allocation algorithm doesn't take unreachability into account when choosing 
> where to allocate the shard, just up/down.  I suspect that unreachability 
> is too local and transient to use as the basis for these allocations.
>
> Keep in mind that you're looking at this from a relatively all-knowing 
> global perspective, but each node is working from a very localized and 
> imperfect one.  All it knows is "I can't currently reach NodeA".  It has no 
> a priori way of knowing whether NodeA has been taken offline (so it should 
> be avoided), or there's simply been a transient network glitch between here 
> and there (so things are *mostly* business as usual).  Downing is how you 
> tell it, "No, really, stop using this node"; until then, most of the code 
> assumes that the more-common transient situation is the case.  It's 
> *probably* possible to take unreachability into account in the case you're 
> describing, but it doesn't surprise me if that's not true.
>
> Also, keep in mind that, IIRC, there are a few cluster singletons involved 
> here, at least behind the scenes.  If NodeA currently owns one of the key 
> singletons (such as the ShardCoordinator), and it hasn't been downed, I 
> imagine the rest of the cluster is going to *quickly* lock up, because the 
> result is that nobody is authorized to make these sorts of allocation 
> decisions.
>
> All that said -- keep in mind, I'm just a user of this stuff, and am 
> talking at the edges of my knowledge.  Konrad's the actual expert...
>
> On Thu, Aug 4, 2016 at 4:59 PM, Eric Swenson  wrote:
>
>> While I'm in the process of implementing your proposed solution, I did 
>> want to make sure I understood why I'm seeing the failures I'm seeing when 
>> a node is taken offline, auto-down is disabled, and no one is handling the 
>> UnreachableNode message.  Let me try to explain what I think is happening 
>> and perhaps you (or someone else who knows more about this than I) can 
>> confirm or refute.
>>
>> In the case of akka-cluster-sharding, a shard might exist on the 
>> unreachable node.  Since the node is not yet marked as "down", the cluster 
>> simply cannot handle an incoming message for that shard.  To create another 
>> sharded actor on an available cluster node might duplicate the unreachable 
>> node state.  In the case of akka-persistence actors, even though a new 
>> shard actor could resurrect any journaled state, we cannot be sure that the 
>> old unreachable node might not at any time, add other events to the 
>> journal, or come online and try to continue operating on the shard.
>>
>> Is that the reason why I see the following behavior:  NodeA is online.  
>> NodeB comes online and joins the cluster.  A request comes in from 
>> akka-http and is sent to the shard region.  It goes to NodeA which creates 
>> an actor to handle the sharded object.  NodeA is taken offline (unbeknownst 
>> to the akka-cluster).  Another message for the above-mentioned shard comes 
>> in from akka-http and is sent to the shard region. The shard region can't 
>> reach NodeA.  NodeA isn't marked as down.  So the shard region cannot 
>> create another actor (on an available Node). It can only wait (until 
>> timeout) for NodeA to become reachable.  Since, in my scenario, NodeA will 
>> never become reachable and NodeB is the only one online, all requests for 
>> old shards timeout.
>>
>> If the above logic is true, I have one last issue:  In the above 
>> scenario, if a message comes into the shard region for a shard that WOULD 
>> HAVE BEEN allocated to NodeA but has never yet been assigned to an actor on 
>> NodeA, and NodeA is unreachable, why can it simply be assigned to another 
>> Node?  is it because the shard-to-node algorithm is fixed (by default) and 
>> there is no dynamic ability to "reassign" to an available Node? 
>>
>> Thanks again.  -- Eric
>>
>> On Wednesday, August 3, 2016 at 7:00:42 PM UTC-7, Justin du coeur wrote:
>>>
>>> The keyword here is "auto".  Autodowning is an *incredibly braindead* 
>>> algorithm for dealing with nodes coming out of service, and if you use it 
>>> in production you more or less guarantee disaster, because that algorithm 
>>> can't cope with cluster partition.  You *do* need to deal with downing, but 
>>> you have to get something smarter than that.
>>>
>>> Frankly, if you're already hooking into AWS, I *suspect* 

[akka-user] Re: Using TestProbe to automate test by replying automatically just to ensure that the test goes

[Maatary Okouya]

I do not understand the following sentence either: 

The run method must return the auto-pilot for the next message, which may 
be KeepRunning to retain the current one or NoAutoPilot to switch it off.

1 - what is the current one referring to here: the next message or the 
auto-pilot ? To me, this sentence is just confusing, as much as the 
example. I believe i would need more help to understand it. 

On Friday, August 5, 2016 at 2:58:59 AM UTC-4, Henry Mai wrote:
>
> Defining a receive for TestProbe won't do anything.
> Instead take a look at Auto-Pilot for the behavior that you want: 
> http://doc.akka.io/docs/akka/current/scala/testing.html#Auto-Pilot
>
> On Thursday, August 4, 2016 at 3:59:50 PM UTC-7, Maatary Okouya wrote:
>>
>> I am trying to get a test probe to reply with an acknowledgement, 
>> whenever it receive any message .
>>
>> I wrote the following code in my test but it does not work:
>>
>> val chgtWriter = new TestProbe(system)  {
>>
>>   def receive: Receive = {
>>
>> case m => println("receive messagereplying with ACK"); sender() 
>> ! ACK
>>
>>   }
>>
>> }
>>
>> Is there a way to do that. The actor that is actually sending the message 
>> to the test probe is definitely running on another thread than the 
>> TestThread. Below you can see the full test as currently crafted.
>>
>> feature("The changeSetActor periodically fetch new change set following a 
>> schedule") {
>>
>>
>> scenario("A ChangeSetActor fetch new changeset from a Fetcher Actor that 
>> return a full and an empty ChangeSet"){
>>
>>
>>   Given("a ChangeSetActor with a schedule of fetching a message every 10 
>> seconds, a ChangeFetcher and a ChangeWriter")
>>
>> val chgtFetcher = TestProbe()
>>
>> val chgtWriter = new TestProbe(system)  {
>>
>>   def receive: Receive = {
>>
>> case m => println("receive message {} replying with ACK"); sender() 
>> ! ACK
>>
>>   }
>>
>> }
>> val fromTime = Instant.now().truncatedTo(ChronoUnit.SECONDS)
>> val chgtActor = system.actorOf(ChangeSetActor.props(chgtWriter.ref, 
>> chgtFetcher.ref, fromTime))
>>
>>   When("all are started")
>>
>>
>>   Then("The Change Fetcher should receive at least 3 messages from the 
>> ChangeSetActor within 40 seconds")
>>
>> var changesetSNum = 1
>>
>> val received = chgtFetcher.receiveWhile( 40 seconds) {
>>
>>   case FetchNewChangeSet(m) => {
>>
>> println(s"received: FetchNewChangeSet(${m}")
>>
>> if (changesetSNum == 1) {
>> chgtFetcher.reply(NewChangeSet(changeSet1))
>> changesetSNum += 1
>>   }
>>   else
>> chgtFetcher.reply(NoAvailableChangeSet)
>> }
>>
>>   }
>>
>> received.size should be (3)
>> }
>>
>> }
>>
>> The changeSetActor is fully tested and works. The test hang with the 
>> ChangeWriter. It never receive a message in the receive method.
>>
>

-- 
>>  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: Using TestProbe to automate test by replying automatically just to ensure that the test goes

[Maatary Okouya]

I have seen it, but i simply don't understand it at all. 


   1. val probe = TestProbe()
   2. probe.setAutoPilot(new TestActor.AutoPilot {
   3. def run(sender: ActorRef, msg: Any): TestActor.AutoPilot =
   4. msg match {
   5. case "stop" ⇒ TestActor.NoAutoPilot
   6. case x ⇒ testActor.tell(x, sender); TestActor.KeepRunning
   7. }
   8. })

What is testActor  ? There is no variable of that name? what does it 
represent ?  

On Friday, August 5, 2016 at 2:58:59 AM UTC-4, Henry Mai wrote:
>
> Defining a receive for TestProbe won't do anything.
> Instead take a look at Auto-Pilot for the behavior that you want: 
> http://doc.akka.io/docs/akka/current/scala/testing.html#Auto-Pilot
>
> On Thursday, August 4, 2016 at 3:59:50 PM UTC-7, Maatary Okouya wrote:
>>
>> I am trying to get a test probe to reply with an acknowledgement, 
>> whenever it receive any message .
>>
>> I wrote the following code in my test but it does not work:
>>
>> val chgtWriter = new TestProbe(system)  {
>>
>>   def receive: Receive = {
>>
>> case m => println("receive messagereplying with ACK"); sender() 
>> ! ACK
>>
>>   }
>>
>> }
>>
>> Is there a way to do that. The actor that is actually sending the message 
>> to the test probe is definitely running on another thread than the 
>> TestThread. Below you can see the full test as currently crafted.
>>
>> feature("The changeSetActor periodically fetch new change set following a 
>> schedule") {
>>
>>
>> scenario("A ChangeSetActor fetch new changeset from a Fetcher Actor that 
>> return a full and an empty ChangeSet"){
>>
>>
>>   Given("a ChangeSetActor with a schedule of fetching a message every 10 
>> seconds, a ChangeFetcher and a ChangeWriter")
>>
>> val chgtFetcher = TestProbe()
>>
>> val chgtWriter = new TestProbe(system)  {
>>
>>   def receive: Receive = {
>>
>> case m => println("receive message {} replying with ACK"); sender() 
>> ! ACK
>>
>>   }
>>
>> }
>> val fromTime = Instant.now().truncatedTo(ChronoUnit.SECONDS)
>> val chgtActor = system.actorOf(ChangeSetActor.props(chgtWriter.ref, 
>> chgtFetcher.ref, fromTime))
>>
>>   When("all are started")
>>
>>
>>   Then("The Change Fetcher should receive at least 3 messages from the 
>> ChangeSetActor within 40 seconds")
>>
>> var changesetSNum = 1
>>
>> val received = chgtFetcher.receiveWhile( 40 seconds) {
>>
>>   case FetchNewChangeSet(m) => {
>>
>> println(s"received: FetchNewChangeSet(${m}")
>>
>> if (changesetSNum == 1) {
>> chgtFetcher.reply(NewChangeSet(changeSet1))
>> changesetSNum += 1
>>   }
>>   else
>> chgtFetcher.reply(NoAvailableChangeSet)
>> }
>>
>>   }
>>
>> received.size should be (3)
>> }
>>
>> }
>>
>> The changeSetActor is fully tested and works. The test hang with the 
>> ChangeWriter. It never receive a message in the receive method.
>>
>

-- 
>>  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] Stream within Actor Supervision

[Konrad Malawski]

Stream errors are *in* the stream.
It does not blow up the Actor, nor should it.

What's your use case?

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 5 August 2016 at 09:31:16, Gary Struthers (agilej...@earthlink.net)
wrote:

I think I understand. The other part of my question is when a stream is
within an actor. If the stream has an error where I want the enclosing
actor to stop how do I do that? Also, any advice on testing error handling?
--
>> 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] Stream within Actor Supervision

[Gary Struthers]

I think I understand. The other part of my question is when a stream is 
within an actor. If the stream has an error where I want the enclosing 
actor to stop how do I do that? Also, any advice on testing error handling?

-- 
>>  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: Using TestProbe to automate test by replying automatically just to ensure that the test goes

[Henry Mai]

Defining a receive for TestProbe won't do anything.
Instead take a look at Auto-Pilot for the behavior that you 
want: http://doc.akka.io/docs/akka/current/scala/testing.html#Auto-Pilot

On Thursday, August 4, 2016 at 3:59:50 PM UTC-7, Maatary Okouya wrote:
>
> I am trying to get a test probe to reply with an acknowledgement, whenever 
> it receive any message .
>
> I wrote the following code in my test but it does not work:
>
> val chgtWriter = new TestProbe(system)  {
>
>   def receive: Receive = {
>
> case m => println("receive messagereplying with ACK"); sender() ! 
> ACK
>
>   }
>
> }
>
> Is there a way to do that. The actor that is actually sending the message 
> to the test probe is definitely running on another thread than the 
> TestThread. Below you can see the full test as currently crafted.
>
> feature("The changeSetActor periodically fetch new change set following a 
> schedule") {
>
>
> scenario("A ChangeSetActor fetch new changeset from a Fetcher Actor that 
> return a full and an empty ChangeSet"){
>
>
>   Given("a ChangeSetActor with a schedule of fetching a message every 10 
> seconds, a ChangeFetcher and a ChangeWriter")
>
> val chgtFetcher = TestProbe()
>
> val chgtWriter = new TestProbe(system)  {
>
>   def receive: Receive = {
>
> case m => println("receive message {} replying with ACK"); sender() ! 
> ACK
>
>   }
>
> }
> val fromTime = Instant.now().truncatedTo(ChronoUnit.SECONDS)
> val chgtActor = system.actorOf(ChangeSetActor.props(chgtWriter.ref, 
> chgtFetcher.ref, fromTime))
>
>   When("all are started")
>
>
>   Then("The Change Fetcher should receive at least 3 messages from the 
> ChangeSetActor within 40 seconds")
>
> var changesetSNum = 1
>
> val received = chgtFetcher.receiveWhile( 40 seconds) {
>
>   case FetchNewChangeSet(m) => {
>
> println(s"received: FetchNewChangeSet(${m}")
>
> if (changesetSNum == 1) {
> chgtFetcher.reply(NewChangeSet(changeSet1))
> changesetSNum += 1
>   }
>   else
> chgtFetcher.reply(NoAvailableChangeSet)
> }
>
>   }
>
> received.size should be (3)
> }
>
> }
>
> The changeSetActor is fully tested and works. The test hang with the 
> ChangeWriter. It never receive a message in the receive method.
>

-- 
>>  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] Stream within Actor Supervision

[Konrad Malawski]

If you write *custom* GraphStages, then *you* need to decide what
supervision means in that context – then is supports it:
https://github.com/akka/akka/commit/5382014133d01cd38729d731763841680f93a42c#diff-3203199ba389ee802eef94486f26dc88R41


-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 5 August 2016 at 04:47:58, Gary Struthers (agilej...@earthlink.net)
wrote:

Thanks Konrad, when I skimmed that page I read it as supervision didn't
work with GraphStage, which I use a lot but reading slowly I see it's
GraphStage junction that's not supported and I don't use that. This gives
me what I need.
--
>> 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.