Re: [akka-user] problem with pinned dispatcher

[mc]

I got this to work by defining actor group, see my other post ("how to bind 
each actor in a pool to a thread").
Thanks,

M



On Tuesday, August 1, 2017 at 12:31:36 PM UTC-7, Patrik Nordwall wrote:
>
> I don't think that is the right way to define the dispatcher for router 
> pool. See docs 
> http://doc.akka.io/docs/akka/current/scala/routing.html#configuring-dispatchers
>
> /Patrik
>
>
> tis 1 aug. 2017 kl. 20:40 skrev Viktor Klang  >:
>
>> «Note that it’s not guaranteed that the *same* thread is used over time, 
>> since the core pool timeout is used for PinnedDispatcher to keep 
>> resource usage down in case of idle actors. To use the same thread all the 
>> time you need to add thread-pool-executor.allow-core-timeout=off to the 
>> configuration of the PinnedDispatcher.»
>>
>>
>> http://doc.akka.io/docs/akka/current/scala/dispatchers.html#types-of-dispatchers
>>
>>
>>
>> On Tue, Aug 1, 2017 at 5:04 PM, mc  
>> wrote:
>>
>>> Hello,
>>>
>>> I'm trying to use PinnedDispatcher using the following configuration (in 
>>> application.conf):
>>>
>>> app {
>>> pinnedDispatcher {
>>> type = "PinnedDispatcher"
>>> executor = "thread-pool-executor"
>>> thread-pool-executor.allow-
>>> core-timeout = off
>>> thread-pool-executor {
>>> core-pool-size-min = 2
>>> core-pool-size-factor = 2.0
>>> core-pool-size-max = 4
>>> }
>>> throughput = 1
>>> }
>>> }
>>>
>>> akka.actor.deployment {
>>> /master/worker {
>>> dispatcher = app.pinnedDispatcher
>>> router = round-robin-pool
>>> }
>>> }
>>>
>>> This is my code for creating worker pool (inside MyMaster actor called 
>>> "master"):
>>>   private lazy val worker = 
>>> context.actorOf(FromConfig.props(Props[MyWorker]), "worker")
>>>
>>> Worker actors are receiving messages but it looks like actors created on 
>>> one thread are later executed on another thread.
>>> Is my configuration incorrect? I thought that using pinned dispatcher 
>>> would guarantee that an actor created on a thread would later be always 
>>> called from that same thread.
>>> I'd appreciate any help with this problem.
>>> Thanks,
>>>
>>> M
>>>
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@googlegroups.com .
>>> To post to this group, send email to akka...@googlegroups.com 
>>> .
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Cheers,
>> √
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[akka-user] Re: how to bind each actor in a pool to a thread

[mc]

Hello,

Thank you for your help. After reading your comment ("the router, not for 
it's routees") I remembered about actor groups (as opposed to pools).
I defined a common pinned dispatcher (in application.conf, directly under 
"akka" element):

pinnedDispatcher {
type = "PinnedDispatcher"
executor = "thread-pool-executor"
thread-pool-executor.allow-core-timeout = off
}

Then created worker actors first:

  private lazy val workers = for (i <- 0 until MyWorkerCount) yield {
context.actorOf(Props[MyWorker].withDispatcher("pinnedDispatcher"), 
"myWorker" + i) //actor names need to be unique
  }

And then created round robin actor group:

  private lazy val workerGroup = 
context.actorOf(RoundRobinGroup(workers.map(_.path.toString)).props(), 
"workerGroup")

Now each worker actor in the group is running on a separate thread, and 
always on the same one.
Thanks,

M


On Tuesday, August 1, 2017 at 12:49:00 PM UTC-7, Rafał Sumisławski wrote:
>
> I'm not experienced with configuring routers from config, since I prefer 
> using code, but as far as I understand you did set a dispatcher for the 
> /master/worker - the router, not for it's routees - the actual worker 
> actors. If you print the thread name in constructor an in receive of 
> workers you should see that your using default-dispatcher.
>
> Something like this may be closer to what you're trying to achieve:
> akka.actor.deployment {
> /master/worker {
> pool-dispatcher = {
> type = "PinnedDispatcher"
> executor = "thread-pool-executor"
> thread-pool-executor.allow-core-timeout = off
> throughput = 1
> }
> router = round-robin-pool
> }
> }
>
> BTW AFAIK you shouldn't/don't have to configure thread pool size for a 
> pinned dispatcher. It's creating a separate single-thread pool for each 
> actor.
>
> W dniu wtorek, 1 sierpnia 2017 00:26:34 UTC+2 użytkownik mc napisał:
>>
>> Hello,
>>
>> I tried to use PinnedDispatcher using the following configuration (in 
>> application.conf):
>>
>> app {
>> pinnedDispatcher {
>> type = "PinnedDispatcher"
>> executor = "thread-pool-executor"
>> thread-pool-executor.allow-core-timeout = off
>> thread-pool-executor {
>> core-pool-size-min = 2
>> core-pool-size-factor = 2.0
>> core-pool-size-max = 4
>> }
>> throughput = 1
>> }
>> }
>>
>> akka.actor.deployment {
>> /master/worker {
>> dispatcher = app.pinnedDispatcher
>> router = round-robin-pool
>> }
>> }
>>
>> This is my code for creating worker pool (inside MyMaster actor called 
>> "master"):
>>   private lazy val worker = 
>> context.actorOf(FromConfig.props(Props[MyWorker]), "worker")
>>
>> Worker actors are receiving messages but it looks like actors created on 
>> one thread are later executed on another thread.
>> Is my configuration incorrect? I thought that using pinned dispatcher 
>> would guarantee that an actor created on a thread would later be always 
>> called from that same thread.
>> I'd appreciate any help with this problem.
>> Thanks,
>>
>> M
>>
>>
>>
>> On Thursday, July 27, 2017 at 11:17:12 AM UTC-7, Rafał Sumisławski wrote:
>>>
>>> Hi
>>> A PinnedDispatcher may be what your looking for. It creates a dedicated 
>>> thread for each actor.
>>>
>>> It's documented (with an example) here: 
>>> http://doc.akka.io/docs/akka/current/scala/dispatchers.html#types-of-dispatchers
>>>
>>> Best Regards,
>>> Rafał
>>>
>>

-- 
>>  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] Flow.fromSinkAndSource and backpressure

[Jeff]

I didn't see much in the documentation, so I thought I'd ask. If I have a 
Sink.actorRef and a Source.actorRef, and I combine them using
 Flow.fromSinkAndSource, does this somehow propagate backpressure?

-- 
>>  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: how to bind each actor in a pool to a thread

[Rafał Sumisławski]

I'm not experienced with configuring routers from config, since I prefer 
using code, but as far as I understand you did set a dispatcher for the 
/master/worker - the router, not for it's routees - the actual worker 
actors. If you print the thread name in constructor an in receive of 
workers you should see that your using default-dispatcher.

Something like this may be closer to what you're trying to achieve:
akka.actor.deployment {
/master/worker {
pool-dispatcher = {
type = "PinnedDispatcher"
executor = "thread-pool-executor"
thread-pool-executor.allow-core-timeout = off
throughput = 1
}
router = round-robin-pool
}
}

BTW AFAIK you shouldn't/don't have to configure thread pool size for a 
pinned dispatcher. It's creating a separate single-thread pool for each 
actor.

W dniu wtorek, 1 sierpnia 2017 00:26:34 UTC+2 użytkownik mc napisał:
>
> Hello,
>
> I tried to use PinnedDispatcher using the following configuration (in 
> application.conf):
>
> app {
> pinnedDispatcher {
> type = "PinnedDispatcher"
> executor = "thread-pool-executor"
> thread-pool-executor.allow-core-timeout = off
> thread-pool-executor {
> core-pool-size-min = 2
> core-pool-size-factor = 2.0
> core-pool-size-max = 4
> }
> throughput = 1
> }
> }
>
> akka.actor.deployment {
> /master/worker {
> dispatcher = app.pinnedDispatcher
> router = round-robin-pool
> }
> }
>
> This is my code for creating worker pool (inside MyMaster actor called 
> "master"):
>   private lazy val worker = 
> context.actorOf(FromConfig.props(Props[MyWorker]), "worker")
>
> Worker actors are receiving messages but it looks like actors created on 
> one thread are later executed on another thread.
> Is my configuration incorrect? I thought that using pinned dispatcher 
> would guarantee that an actor created on a thread would later be always 
> called from that same thread.
> I'd appreciate any help with this problem.
> Thanks,
>
> M
>
>
>
> On Thursday, July 27, 2017 at 11:17:12 AM UTC-7, Rafał Sumisławski wrote:
>>
>> Hi
>> A PinnedDispatcher may be what your looking for. It creates a dedicated 
>> thread for each actor.
>>
>> It's documented (with an example) here: 
>> http://doc.akka.io/docs/akka/current/scala/dispatchers.html#types-of-dispatchers
>>
>> Best Regards,
>> Rafał
>>
>

-- 
>>  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: Sharding coordinator comms issues running on Kubernetes

[Patrik Nordwall]

You're welcome. Yes, you are supposed to register (start) the sharding on
all nodes (or nodes with a certain role). The coordinator is a Cluster
Singleton, i.e. running on oldest node (when you have started it). Other
nodes try to register to the coordinator at the oldest node.

/Patrik
tis 1 aug. 2017 kl. 16:45 skrev Stephen Kennedy :

> Thanks for the prompt reply. As hoped it has instantly made me realize the
> error of our ways.
>
> Our application bootstrap code was over using lazy val's, so as you
> suggest we weren't actually calling ClusterSharding.start until that node
> needed the ActorRef.
>
> So I can further my understanding, could you explain the logic regarding
> api-1 / api-2 assuming the coordinator is on api-0 - even though it hasn't
> registered a ShardRegion yet?
>
> Is it that all nodes in the cluster are required to call
> ClusterSharding.start? Reading docs a bit more it sounds like that is the
> case, as if we wanted to only run on a sub-group of nodes we should use
> roles.
>
> Thanks again for helping out.
>
> On Tuesday, 1 August 2017 14:56:33 UTC+1, Patrik Nordwall wrote:
>
>> Looks like ClusterSharding.start is missing at startup of api-0. Are you
>> sure that you do that when the ActorSystem has been started and not lazily
>> on first request?
>>
>> Enable debug level logging and you should see what it is doing. You
>> should see log entries in api-0 at startup.
>>
>> /Patrik
>>
> tis 1 aug. 2017 kl. 15:39 skrev Stephen Kennedy :
>>
> As a follow up, I've now just ruled out any kubernetes networking issue by
>>> recreating the same behaviour running 3 nodes via docker-compose instead -
>>> again it only works if an API call hits the first node in seed-nodes list.
>>>
>>>
>>> On Tuesday, 1 August 2017 14:11:07 UTC+1, Stephen Kennedy wrote:

 Hi,

 Seeing some strange issues running Cluster Sharded actors in a
 kubernetes environment.

 We are currently running a 3 node akka cluster, with our app running
 within a docker container within a kubernetes stateful set (similar to the
 akka-seed set described here
 ).
 The nodes are all akka-http API servers, which run behind a HTTP load
 balancer, and use akka-persistence for our domain entities. So we use
 cluster sharding to ensure that each entity can only live on a single node
 at once.

 So the cluster config of our akka nodes looks something like this:

 akka {
   remote {
 enabled-transports = ["akka.remote.netty.tcp"]
 netty.tcp {
   hostname = ${POD_NAME}.api
   port = 2551
 }
   }

   cluster {
 seed-nodes = [
   "akka.tcp://actor-sys...@api-0.api:2551",
   "akka.tcp://actor-sys...@api-1.api:2551",
   "akka.tcp://actor-sys...@api-2.api:2551"
 ]
   }
 }


 Where "api" is the kubernetes service (which provides DNS mapping) and
 "api-0/1/2" are the consistent pod names that using a stateful set gives
 us. Using the default sharding config.

 And within the code we have a number of calls to ClusterSharding.start
 - for each type of our sharded entity actors. We then only fire a message
 to these actors when an appropriate API call comes in.

 Now when the nodes come up they all consistently connect to the cluster
 properly, and I see gossip messages suggesting they all know about each
 other, but we are then seeing communication issues on the Cluster Sharded
 actors.

 As far as I can tell, if the first API request for a particular type of
 entity comes into api-1 or api-2, it often fails because that node is
 unable to communicate with the coordinator - which it seems to think is on
 api-0.

 From api-1:
 2017-08-01 12:22:15.253 DEBUG akka.actor.ActorSystemImpl -
 http://xxx/envelopes - HttpMethod(GET) - Starting
 2017-08-01 12:23:05.336 WARN  akka.cluster.sharding.ShardRegion -
 Trying to register to coordinator at
 [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/),
 Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])],
 but no acknowledgement. Total [10] buffered messages.
 2017-08-01 12:23:07.336 WARN  akka.cluster.sharding.ShardRegion -
 Trying to register to coordinator at
 [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/),
 Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])],
 but no acknowledgement. Total [10] buffered messages.
 2017-08-01 12:23:09.336 WARN  akka.cluster.sharding.ShardRegion -
 Trying to register to coordinator at
 [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/),
 Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])],

Re: [akka-user] problem with pinned dispatcher

[Viktor Klang]

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

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


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

> Hello,
>
> I'm trying to use PinnedDispatcher using the following configuration (in
> application.conf):
>
> app {
> pinnedDispatcher {
> type = "PinnedDispatcher"
> executor = "thread-pool-executor"
> thread-pool-executor.allow-
> core-timeout = off
> thread-pool-executor {
> core-pool-size-min = 2
> core-pool-size-factor = 2.0
> core-pool-size-max = 4
> }
> throughput = 1
> }
> }
>
> akka.actor.deployment {
> /master/worker {
> dispatcher = app.pinnedDispatcher
> router = round-robin-pool
> }
> }
>
> This is my code for creating worker pool (inside MyMaster actor called
> "master"):
>   private lazy val worker = context.actorOf(FromConfig.props(Props[MyWorker]),
> "worker")
>
> Worker actors are receiving messages but it looks like actors created on
> one thread are later executed on another thread.
> Is my configuration incorrect? I thought that using pinned dispatcher
> would guarantee that an actor created on a thread would later be always
> called from that same thread.
> I'd appreciate any help with this problem.
> Thanks,
>
> M
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

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

Re: [akka-user] Consuming akka-streams service via Javascript

[Konrad “ktoso” Malawski]

Yes, since we translate reactive streams back-pressure onto TCP flow
control which has tot be handled (and is handled) by anything that speaks
TCP, which includes any HTTP call.

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 2 August 2017 at 02:35:35, B Wills (bwill...@gmail.com) wrote:

Will back pressure still work over http, without a library on the
Javascript side that uses the same protocol as akka-streams?

On Monday, July 31, 2017 at 6:59:47 PM UTC-6, Konrad Malawski wrote:
>
> Hi there,
> In general “streaming consumption" of such API can be simplified to “start
> working with the data before the entire transfer completes.
> Since it’s JSON you likely want to parse it somewhat, or select specific
> elements etc.
>
> AFAICS http://oboejs.com/examples is one of the streaming parsers
> available for javascript, so you could use that for example.
> I’m sure theres others too, in general what you’re looking for is “sax” or
> “streaming” parsers.
>
> —
> Konrad `kto.so` Malawski
> Akka  @ Lightbend 
>
> On 1 August 2017 at 09:43:35, B Wills (bwil...@gmail.com) wrote:
>
> Hi,
>
> I have created a web service that sends a response in the form of a JSON
> stream, similar to the below code snippet from the akka-streams
> documentation:
>
> val route =
>   path("tweets") {
> // [3] simply complete a request with a source of tweets:
> val tweets: Source[Tweet, NotUsed] = getTweets
> complete(tweets)
>   }
>
>
>
> I would like to be able to consume the stream over http via a Node.js
> client - has anyone done something like this before? I have looked at
> akka.js and scala.js some, but based on my reading it sounds like this
> might "just work" without any special libraries on the client-side.
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
"Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
>>  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] Consuming akka-streams service via Javascript

[B Wills]

Will back pressure still work over http, without a library on the 
Javascript side that uses the same protocol as akka-streams?

On Monday, July 31, 2017 at 6:59:47 PM UTC-6, Konrad Malawski wrote:
>
> Hi there,
> In general “streaming consumption" of such API can be simplified to “start 
> working with the data before the entire transfer completes.
> Since it’s JSON you likely want to parse it somewhat, or select specific 
> elements etc.
>
> AFAICS http://oboejs.com/examples is one of the streaming parsers 
> available for javascript, so you could use that for example.
> I’m sure theres others too, in general what you’re looking for is “sax” or 
> “streaming” parsers.
>
> —
> Konrad `kto.so` Malawski
> Akka  @ Lightbend 
>
> On 1 August 2017 at 09:43:35, B Wills (bwil...@gmail.com ) 
> wrote:
>
> Hi, 
>
> I have created a web service that sends a response in the form of a JSON 
> stream, similar to the below code snippet from the akka-streams 
> documentation:
>
> val route =
>   path("tweets") {
> // [3] simply complete a request with a source of tweets:
> val tweets: Source[Tweet, NotUsed] = getTweets
> complete(tweets)
>   }
>
>
>
> I would like to be able to consume the stream over http via a Node.js 
> client - has anyone done something like this before? I have looked at 
> akka.js and scala.js some, but based on my reading it sounds like this 
> might "just work" without any special libraries on the client-side.
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com .
> To post to this group, send email to akka...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>

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

[akka-user] Re: DistributedPubSub sending messages to DeadLetter

[Rafał Sumisławski]

Hi Johan
Thanks for your response. I'll try implementing it and submitting a PR.

Best Regards
Rafał

W dniu piątek, 28 lipca 2017 09:11:49 UTC+2 użytkownik Johan Andrén napisał:
>
> In many cases it may be a sign that something is wrong when there are no 
> subscribers, for example because topic name was misspelled etc. Just like 
> how other messages ending up in dead letter could indicate a problem but 
> might be normal. 
>
> It is also useful when debugging, if for example a subscription has not 
> yet been gossiped to a node when a message is published to a topic. 
>
> The feature was added in 2.4.5, here's the issue: 
> https://github.com/akka/akka/issues/19009
>
> I think we'd be open for a PR making this configurable, keeping the 
> current behaviour as default. If you're not up for that then adding a dummy 
> subscriber sounds like a possible solution.
>
> --
> Johan 
> Akka Team
>
> On Saturday, July 22, 2017 at 4:02:35 PM UTC+2, Rafał Sumisławski wrote:
>>
>> Hi,
>>
>> I was surprised to discover that the DistributedPubSub does not simply 
>> forward a published message to all (0 or more) subscribers for a given 
>> topic. There's a special case implemented to send the message to the 
>> DeadLetter in case there are no subscribers for that topic (
>> https://github.com/akka/akka/blob/9d2bec7f232b628cc087231af75e457072823e61/akka-cluster-tools/src/main/scala/akka/cluster/pubsub/DistributedPubSubMediator.scala#L716).
>>  
>> Sending these messages to DeadLetter makes it look like it's something 
>> wrong, while IMO it's a perfectly valid and common use case for 
>> publish-subscribe pattern to have 0 or more subscribers. I see value of 
>> this behaviour during debugging, but it's strange that it's a default and 
>> as far as I can see it can't be disabled. 
>>
>> What is the reason why DistributedPubSub is implemented this way?
>>
>> What is the best way to avoid published messages ending up in the 
>> DeadLetter? Currently I'm spawning a fake subscriber actor (usually one per 
>> node) for each topic I plan to publish some messages to.
>>
>> Best Regards
>> Rafał
>>
>

-- 
>>  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 Data - OversizedPayloadException even when splitting ORMultiMap into many keys

[Yee-Ning Cheng]

Hi,

I currently am using using ~100 instances of ORMultiMap[Int, Int] by the 
following code and am constantly adding/deleting elements (~200/sec) in the 
value sets.

I have delta-crdt enabled as well.

def hash(key: Int, mod: Int) = {
  key % mod
}

def mapKey(key: Int) = {
  ORMultiMapKey[Int, Int](hash(key, 100).toString)
}


replicator ! Update(mapKey(key), ORMultiMap.empty[Int, Int], WriteLocal) { ... 
} etc.


>From my understanding, this should split up the top-level entries into 100 
ORMultiMap as suggested in the documentation.  And since it splits up the 
maps individually, this should split up the replication messages across the 
network to other nodes in the cluster.  However when I put a breakpoint in 
akka.remote.Endpoint where it throws an OversizedPayloadException (128000 
byte default)

akka.remote.OversizedPayloadException: Discarding oversized payload sent to 
Actor[akka.tcp://ClusterSystem@127.0.0.1:2551/system/ddataReplicator#1569786013]:
 
max allowed size 128000 bytes, actual size of encoded class 
akka.cluster.ddata.Replicator$Internal$Gossip was 129103 bytes.

I look in the akka.remote.Send.message field and see that the updatedData 
TrieMap seems to contain updates for all the ORMultiMaps.  Is it batching 
all the updates?  If so, doesn't this make hashing the individual 
ORMultiMaps useless for preventing large replication messages?

Please let me know if I have a poor understanding or I am doing something 
wrong here..

Thanks,

Yee-Ning

-- 
>>  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] problem with pinned dispatcher

[mc]

Hello,

I'm trying to use PinnedDispatcher using the following configuration (in 
application.conf):

app {
pinnedDispatcher {
type = "PinnedDispatcher"
executor = "thread-pool-executor"
thread-pool-executor.allow-
core-timeout = off
thread-pool-executor {
core-pool-size-min = 2
core-pool-size-factor = 2.0
core-pool-size-max = 4
}
throughput = 1
}
}

akka.actor.deployment {
/master/worker {
dispatcher = app.pinnedDispatcher
router = round-robin-pool
}
}

This is my code for creating worker pool (inside MyMaster actor called 
"master"):
  private lazy val worker = 
context.actorOf(FromConfig.props(Props[MyWorker]), "worker")

Worker actors are receiving messages but it looks like actors created on 
one thread are later executed on another thread.
Is my configuration incorrect? I thought that using pinned dispatcher would 
guarantee that an actor created on a thread would later be always called 
from that same thread.
I'd appreciate any help with this problem.
Thanks,

M

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

Re: [akka-user] Re: Sharding coordinator comms issues running on Kubernetes

[Stephen Kennedy]

Thanks for the prompt reply. As hoped it has instantly made me realize the 
error of our ways.

Our application bootstrap code was over using lazy val's, so as you suggest 
we weren't actually calling ClusterSharding.start until that node needed 
the ActorRef.

So I can further my understanding, could you explain the logic regarding 
api-1 / api-2 assuming the coordinator is on api-0 - even though it hasn't 
registered a ShardRegion yet? 

Is it that all nodes in the cluster are required to call 
ClusterSharding.start? Reading docs a bit more it sounds like that is the 
case, as if we wanted to only run on a sub-group of nodes we should use 
roles.

Thanks again for helping out. 

On Tuesday, 1 August 2017 14:56:33 UTC+1, Patrik Nordwall wrote:
>
> Looks like ClusterSharding.start is missing at startup of api-0. Are you 
> sure that you do that when the ActorSystem has been started and not lazily 
> on first request?
>
> Enable debug level logging and you should see what it is doing. You should 
> see log entries in api-0 at startup.
>
> /Patrik
> tis 1 aug. 2017 kl. 15:39 skrev Stephen Kennedy  >:
>
>> As a follow up, I've now just ruled out any kubernetes networking issue 
>> by recreating the same behaviour running 3 nodes via docker-compose instead 
>> - again it only works if an API call hits the first node in seed-nodes list.
>>
>>
>> On Tuesday, 1 August 2017 14:11:07 UTC+1, Stephen Kennedy wrote:
>>>
>>> Hi,
>>>
>>> Seeing some strange issues running Cluster Sharded actors in a 
>>> kubernetes environment.
>>>
>>> We are currently running a 3 node akka cluster, with our app running 
>>> within a docker container within a kubernetes stateful set (similar to the 
>>> akka-seed set described here 
>>> ).
>>>  
>>> The nodes are all akka-http API servers, which run behind a HTTP load 
>>> balancer, and use akka-persistence for our domain entities. So we use 
>>> cluster sharding to ensure that each entity can only live on a single node 
>>> at once.
>>>
>>> So the cluster config of our akka nodes looks something like this:
>>>
>>> akka {
>>>   remote {
>>> enabled-transports = ["akka.remote.netty.tcp"]
>>> netty.tcp {
>>>   hostname = ${POD_NAME}.api
>>>   port = 2551
>>> }
>>>   }
>>>
>>>   cluster {
>>> seed-nodes = [
>>>   "akka.tcp://actor-sys...@api-0.api:2551",
>>>   "akka.tcp://actor-sys...@api-1.api:2551",
>>>   "akka.tcp://actor-sys...@api-2.api:2551"
>>> ]
>>>   }
>>> }
>>>
>>>
>>> Where "api" is the kubernetes service (which provides DNS mapping) and 
>>> "api-0/1/2" are the consistent pod names that using a stateful set gives 
>>> us. Using the default sharding config.
>>>
>>> And within the code we have a number of calls to ClusterSharding.start - 
>>> for each type of our sharded entity actors. We then only fire a message to 
>>> these actors when an appropriate API call comes in.
>>>
>>> Now when the nodes come up they all consistently connect to the cluster 
>>> properly, and I see gossip messages suggesting they all know about each 
>>> other, but we are then seeing communication issues on the Cluster Sharded 
>>> actors.
>>>
>>> As far as I can tell, if the first API request for a particular type of 
>>> entity comes into api-1 or api-2, it often fails because that node is 
>>> unable to communicate with the coordinator - which it seems to think is on 
>>> api-0.
>>>
>>> From api-1:
>>> 2017-08-01 12:22:15.253 DEBUG akka.actor.ActorSystemImpl - 
>>> http://xxx/envelopes - HttpMethod(GET) - Starting
>>> 2017-08-01 12:23:05.336 WARN  akka.cluster.sharding.ShardRegion - Trying 
>>> to register to coordinator at 
>>> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
>>> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
>>> but no acknowledgement. Total [10] buffered messages.
>>> 2017-08-01 12:23:07.336 WARN  akka.cluster.sharding.ShardRegion - Trying 
>>> to register to coordinator at 
>>> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
>>> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
>>> but no acknowledgement. Total [10] buffered messages.
>>> 2017-08-01 12:23:09.336 WARN  akka.cluster.sharding.ShardRegion - Trying 
>>> to register to coordinator at 
>>> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
>>> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
>>> but no acknowledgement. Total [10] buffered messages.
>>> akka.pattern.AskTimeoutException: Ask timed out on 
>>> [Actor[akka://actor-system/system/sharding/EnvelopeShard#92546893]] after 
>>> [15000 ms]. Sender[null] sent message of type 
>>> "com.goodlord.server.domain.envelope.EnvelopeAggregate$Protocol$Get".
>>> 2017-08-01 12:23:10.344 DEBUG akka.actor.ActorSystemImpl - 
>>> http://xxx/envelopes - 

[akka-user] Re: Akka Camel and Akka Streams

[Sam D]

Martin,

Is there an Ack or Nack/Status.Failure mechanism with the new streamz camel 
api like in the akka-camel actor Consumer api?

Thanks,
Sam

On Thursday, July 13, 2017 at 4:16:52 AM UTC-4, Andreas Gies wrote:
>
> Hi, 
>
> thanks for the pointer to the Camel docs. I knew I had a blindspot 
> somewhere.
>
> Best regards 
> Andreas
>
> Am Dienstag, 11. Juli 2017 14:26:09 UTC+2 schrieb Andreas Gies:
>>
>> Hello HAkkers, 
>>
>> we are maintaining an integration framework (OSGi) project built on top 
>> of ActiveMQ, Spray and Camel implemented in Scala [1]
>>
>> Most of our internal API's rely on Akka and some also on the Akka-Camel 
>> integration. 
>>
>>
>> With the next major release we plan to upgrade our Spray routes to 
>> Akka-Http. Now that I have started looking at the concrete 
>> steps I have noticed that Akka-Camel is also deprecated and to be 
>> replaced with alpakka. 
>>
>> I had a look through the Alpakka project. So far I haven't found the 
>> replacement for the Akka-Camel efforts in there. 
>> Perhaps I have overlooked something or is the replacement just on the 
>> roadmap ? 
>>
>> Also I did have a look at the JMS part of Alpakka. It seems that this 
>> implementation currently only supports TextMessages 
>> and ignores any properties within the message. If I understand the 
>> implementation correctly, it would fail the stream in case 
>> of any JMSException and also when the buffer has been filled up ?
>>
>> On a broader level I was wondering if the implementation should be in the 
>> form that the inbound stream fails if and only if 
>> the connection is irrecoverably broken and in other cases the Stream 
>> should reconnect transparently. 
>>
>> Also on a broader level I have noticed, that the messages are 
>> acknowledged as soon as they pushed. Coming from a JMS
>> background that feels a bit strange to me, but that might be because I am 
>> unfamiliar with the streaming API. In our world 
>> a message is normally acknowledged when it has been processed 
>> successfully (which is normally it has been written to 
>> the file system, forwarded to another JMS destination or triggered some 
>> execution in the database). 
>>
>> If the container crashes before it has acknowledged the message, the 
>> message will be redelivered. In cases we encounter 
>> an error we pass the message to an error handling destination or a retry 
>> destination. 
>>
>>
>> Apparently the architecture and the acceptance level of message loss 
>> changes when switching to a streaming approach. 
>>
>>
>> For now I have some concrete questions:
>>
>> 1) Have I missed the Camel replacement in Alpakka and if so, where is it 
>> located within Alpakka ?
>> 2) How are others coping with the "window of potential message loss" when 
>> migrating from pure JMS flows to streams ?
>> 3) Any pointers to good hands-on white papers are much appreciated. I 
>> have read through some and also through most 
>> of the streams documentation, but I guess I need to get my hands 
>> dirty ... 
>> 4) I don't dare to ask, but if anyone is using Akka / AkkaHttp and / or 
>> AkkaStream within OSGi I would be more than happy 
>> to exchange experiences & ideas. 
>>
>> [1] https://github.com/woq-blended/blended
>>
>>
>> Thanks in advance for your attention 
>> Best regards 
>> Andreas
>>
>

-- 
>>  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: Sharding coordinator comms issues running on Kubernetes

[Patrik Nordwall]

Looks like ClusterSharding.start is missing at startup of api-0. Are you
sure that you do that when the ActorSystem has been started and not lazily
on first request?

Enable debug level logging and you should see what it is doing. You should
see log entries in api-0 at startup.

/Patrik
tis 1 aug. 2017 kl. 15:39 skrev Stephen Kennedy :

> As a follow up, I've now just ruled out any kubernetes networking issue by
> recreating the same behaviour running 3 nodes via docker-compose instead -
> again it only works if an API call hits the first node in seed-nodes list.
>
>
> On Tuesday, 1 August 2017 14:11:07 UTC+1, Stephen Kennedy wrote:
>>
>> Hi,
>>
>> Seeing some strange issues running Cluster Sharded actors in a kubernetes
>> environment.
>>
>> We are currently running a 3 node akka cluster, with our app running
>> within a docker container within a kubernetes stateful set (similar to the
>> akka-seed set described here
>> ).
>> The nodes are all akka-http API servers, which run behind a HTTP load
>> balancer, and use akka-persistence for our domain entities. So we use
>> cluster sharding to ensure that each entity can only live on a single node
>> at once.
>>
>> So the cluster config of our akka nodes looks something like this:
>>
>> akka {
>>   remote {
>> enabled-transports = ["akka.remote.netty.tcp"]
>> netty.tcp {
>>   hostname = ${POD_NAME}.api
>>   port = 2551
>> }
>>   }
>>
>>   cluster {
>> seed-nodes = [
>>   "akka.tcp://actor-sys...@api-0.api:2551",
>>   "akka.tcp://actor-sys...@api-1.api:2551",
>>   "akka.tcp://actor-sys...@api-2.api:2551"
>> ]
>>   }
>> }
>>
>>
>> Where "api" is the kubernetes service (which provides DNS mapping) and
>> "api-0/1/2" are the consistent pod names that using a stateful set gives
>> us. Using the default sharding config.
>>
>> And within the code we have a number of calls to ClusterSharding.start -
>> for each type of our sharded entity actors. We then only fire a message to
>> these actors when an appropriate API call comes in.
>>
>> Now when the nodes come up they all consistently connect to the cluster
>> properly, and I see gossip messages suggesting they all know about each
>> other, but we are then seeing communication issues on the Cluster Sharded
>> actors.
>>
>> As far as I can tell, if the first API request for a particular type of
>> entity comes into api-1 or api-2, it often fails because that node is
>> unable to communicate with the coordinator - which it seems to think is on
>> api-0.
>>
>> From api-1:
>> 2017-08-01 12:22:15.253 DEBUG akka.actor.ActorSystemImpl -
>> http://xxx/envelopes - HttpMethod(GET) - Starting
>> 2017-08-01 12:23:05.336 WARN  akka.cluster.sharding.ShardRegion - Trying
>> to register to coordinator at
>> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/),
>> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])],
>> but no acknowledgement. Total [10] buffered messages.
>> 2017-08-01 12:23:07.336 WARN  akka.cluster.sharding.ShardRegion - Trying
>> to register to coordinator at
>> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/),
>> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])],
>> but no acknowledgement. Total [10] buffered messages.
>> 2017-08-01 12:23:09.336 WARN  akka.cluster.sharding.ShardRegion - Trying
>> to register to coordinator at
>> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/),
>> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])],
>> but no acknowledgement. Total [10] buffered messages.
>> akka.pattern.AskTimeoutException: Ask timed out on
>> [Actor[akka://actor-system/system/sharding/EnvelopeShard#92546893]] after
>> [15000 ms]. Sender[null] sent message of type
>> "com.goodlord.server.domain.envelope.EnvelopeAggregate$Protocol$Get".
>> 2017-08-01 12:23:10.344 DEBUG akka.actor.ActorSystemImpl -
>> http://xxx/envelopes - HttpMethod(GET) - 500 Internal Server
>> Error
>>
>> The trying to register log lines are then repeated forever and if more
>> API calls come into this node (for this shard) the buffered count just goes
>> up. Logging into the
>>
>> However, if we subsequently hit the API and the load balancer chooses
>> api-0, then it works and also seems to initialize the coordinator (which
>> then triggers api-1 to register which clears it's backlog):
>>
>> From api-0:
>> 2017-08-01 12:25:05.902 DEBUG akka.actor.ActorSystemImpl -
>> http://xxx/envelopes - HttpMethod(GET) - Starting
>> 2017-08-01 12:25:05.932 INFO  a.c.s.ClusterSingletonManager - Singleton
>> manager starting singleton actor
>> [akka://actor-system/system/sharding/EnvelopeShardCoordinator/singleton]
>> 2017-08-01 12:25:05.933 DEBUG akka.cluster.ddata.Replicator - Received
>> Get for key [EnvelopeShardCoordinatorState]
>> 2017-08-01 

[akka-user] Re: Sharding coordinator comms issues running on Kubernetes

[Stephen Kennedy]

As a follow up, I've now just ruled out any kubernetes networking issue by 
recreating the same behaviour running 3 nodes via docker-compose instead - 
again it only works if an API call hits the first node in seed-nodes list.

On Tuesday, 1 August 2017 14:11:07 UTC+1, Stephen Kennedy wrote:
>
> Hi,
>
> Seeing some strange issues running Cluster Sharded actors in a kubernetes 
> environment.
>
> We are currently running a 3 node akka cluster, with our app running 
> within a docker container within a kubernetes stateful set (similar to the 
> akka-seed set described here 
> ).
>  
> The nodes are all akka-http API servers, which run behind a HTTP load 
> balancer, and use akka-persistence for our domain entities. So we use 
> cluster sharding to ensure that each entity can only live on a single node 
> at once.
>
> So the cluster config of our akka nodes looks something like this:
>
> akka {
>   remote {
> enabled-transports = ["akka.remote.netty.tcp"]
> netty.tcp {
>   hostname = ${POD_NAME}.api
>   port = 2551
> }
>   }
>
>   cluster {
> seed-nodes = [
>   "akka.tcp://actor-sys...@api-0.api:2551",
>   "akka.tcp://actor-sys...@api-1.api:2551",
>   "akka.tcp://actor-sys...@api-2.api:2551"
> ]
>   }
> }
>
>
> Where "api" is the kubernetes service (which provides DNS mapping) and 
> "api-0/1/2" are the consistent pod names that using a stateful set gives 
> us. Using the default sharding config.
>
> And within the code we have a number of calls to ClusterSharding.start - 
> for each type of our sharded entity actors. We then only fire a message to 
> these actors when an appropriate API call comes in.
>
> Now when the nodes come up they all consistently connect to the cluster 
> properly, and I see gossip messages suggesting they all know about each 
> other, but we are then seeing communication issues on the Cluster Sharded 
> actors.
>
> As far as I can tell, if the first API request for a particular type of 
> entity comes into api-1 or api-2, it often fails because that node is 
> unable to communicate with the coordinator - which it seems to think is on 
> api-0.
>
> From api-1:
> 2017-08-01 12:22:15.253 DEBUG akka.actor.ActorSystemImpl - 
> http://xxx/envelopes - HttpMethod(GET) - Starting
> 2017-08-01 12:23:05.336 WARN  akka.cluster.sharding.ShardRegion - Trying 
> to register to coordinator at 
> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
> but no acknowledgement. Total [10] buffered messages.
> 2017-08-01 12:23:07.336 WARN  akka.cluster.sharding.ShardRegion - Trying 
> to register to coordinator at 
> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
> but no acknowledgement. Total [10] buffered messages.
> 2017-08-01 12:23:09.336 WARN  akka.cluster.sharding.ShardRegion - Trying 
> to register to coordinator at 
> [Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
> Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
> but no acknowledgement. Total [10] buffered messages.
> akka.pattern.AskTimeoutException: Ask timed out on 
> [Actor[akka://actor-system/system/sharding/EnvelopeShard#92546893]] after 
> [15000 ms]. Sender[null] sent message of type 
> "com.goodlord.server.domain.envelope.EnvelopeAggregate$Protocol$Get".
> 2017-08-01 12:23:10.344 DEBUG akka.actor.ActorSystemImpl - 
> http://xxx/envelopes - HttpMethod(GET) - 500 Internal Server Error
>
> The trying to register log lines are then repeated forever and if more API 
> calls come into this node (for this shard) the buffered count just goes up. 
> Logging into the 
>
> However, if we subsequently hit the API and the load balancer chooses 
> api-0, then it works and also seems to initialize the coordinator (which 
> then triggers api-1 to register which clears it's backlog):
>
> From api-0:
> 2017-08-01 12:25:05.902 DEBUG akka.actor.ActorSystemImpl - 
> http://xxx/envelopes - HttpMethod(GET) - Starting
> 2017-08-01 12:25:05.932 INFO  a.c.s.ClusterSingletonManager - Singleton 
> manager starting singleton actor 
> [akka://actor-system/system/sharding/EnvelopeShardCoordinator/singleton]
> 2017-08-01 12:25:05.933 DEBUG akka.cluster.ddata.Replicator - Received Get 
> for key [EnvelopeShardCoordinatorState]
> 2017-08-01 12:25:07.338 DEBUG a.c.sharding.DDataShardCoordinator - 
> ShardRegion registered: 
> [Actor[akka.tcp://actor-sys...@api-1.api:2551/system/sharding/EnvelopeShard#92546893]]
> 2017-08-01 12:25:07.339 DEBUG akka.cluster.ddata.Replicator - Received 
> Update for key [EnvelopeShardCoordinatorState]
> 2017-08-01 12:25:07.341 DEBUG a.c.sharding.DDataShardCoordinator - The 
> coordinator state was successfully updated with 
> 

[akka-user] Sharding coordinator comms issues running on Kubernetes

[Stephen Kennedy]

Hi,

Seeing some strange issues running Cluster Sharded actors in a kubernetes 
environment.

We are currently running a 3 node akka cluster, with our app running within 
a docker container within a kubernetes stateful set (similar to the 
akka-seed set described here 
).
 
The nodes are all akka-http API servers, which run behind a HTTP load 
balancer, and use akka-persistence for our domain entities. So we use 
cluster sharding to ensure that each entity can only live on a single node 
at once.

So the cluster config of our akka nodes looks something like this:

akka {
  remote {
enabled-transports = ["akka.remote.netty.tcp"]
netty.tcp {
  hostname = ${POD_NAME}.api
  port = 2551
}
  }

  cluster {
seed-nodes = [
  "akka.tcp://actor-sys...@api-0.api:2551",
  "akka.tcp://actor-sys...@api-1.api:2551",
  "akka.tcp://actor-sys...@api-2.api:2551"
]
  }
}


Where "api" is the kubernetes service (which provides DNS mapping) and 
"api-0/1/2" are the consistent pod names that using a stateful set gives 
us. Using the default sharding config.

And within the code we have a number of calls to ClusterSharding.start - 
for each type of our sharded entity actors. We then only fire a message to 
these actors when an appropriate API call comes in.

Now when the nodes come up they all consistently connect to the cluster 
properly, and I see gossip messages suggesting they all know about each 
other, but we are then seeing communication issues on the Cluster Sharded 
actors.

As far as I can tell, if the first API request for a particular type of 
entity comes into api-1 or api-2, it often fails because that node is 
unable to communicate with the coordinator - which it seems to think is on 
api-0.

>From api-1:
2017-08-01 12:22:15.253 DEBUG akka.actor.ActorSystemImpl - 
http://xxx/envelopes - HttpMethod(GET) - Starting
2017-08-01 12:23:05.336 WARN  akka.cluster.sharding.ShardRegion - Trying to 
register to coordinator at 
[Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
but no acknowledgement. Total [10] buffered messages.
2017-08-01 12:23:07.336 WARN  akka.cluster.sharding.ShardRegion - Trying to 
register to coordinator at 
[Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
but no acknowledgement. Total [10] buffered messages.
2017-08-01 12:23:09.336 WARN  akka.cluster.sharding.ShardRegion - Trying to 
register to coordinator at 
[Some(ActorSelection[Anchor(akka.tcp://actor-sys...@api-0.api:2551/), 
Path(/system/sharding/EnvelopeShardCoordinator/singleton/coordinator)])], 
but no acknowledgement. Total [10] buffered messages.
akka.pattern.AskTimeoutException: Ask timed out on 
[Actor[akka://actor-system/system/sharding/EnvelopeShard#92546893]] after 
[15000 ms]. Sender[null] sent message of type 
"com.goodlord.server.domain.envelope.EnvelopeAggregate$Protocol$Get".
2017-08-01 12:23:10.344 DEBUG akka.actor.ActorSystemImpl - 
http://xxx/envelopes - HttpMethod(GET) - 500 Internal Server Error

The trying to register log lines are then repeated forever and if more API 
calls come into this node (for this shard) the buffered count just goes up. 
Logging into the 

However, if we subsequently hit the API and the load balancer chooses 
api-0, then it works and also seems to initialize the coordinator (which 
then triggers api-1 to register which clears it's backlog):

>From api-0:
2017-08-01 12:25:05.902 DEBUG akka.actor.ActorSystemImpl - 
http://xxx/envelopes - HttpMethod(GET) - Starting
2017-08-01 12:25:05.932 INFO  a.c.s.ClusterSingletonManager - Singleton 
manager starting singleton actor 
[akka://actor-system/system/sharding/EnvelopeShardCoordinator/singleton]
2017-08-01 12:25:05.933 DEBUG akka.cluster.ddata.Replicator - Received Get 
for key [EnvelopeShardCoordinatorState]
2017-08-01 12:25:07.338 DEBUG a.c.sharding.DDataShardCoordinator - 
ShardRegion registered: 
[Actor[akka.tcp://actor-sys...@api-1.api:2551/system/sharding/EnvelopeShard#92546893]]
2017-08-01 12:25:07.339 DEBUG akka.cluster.ddata.Replicator - Received 
Update for key [EnvelopeShardCoordinatorState]
2017-08-01 12:25:07.341 DEBUG a.c.sharding.DDataShardCoordinator - The 
coordinator state was successfully updated with 
ShardRegionRegistered(Actor[akka.tcp://actor-sys...@api-1.api:2551/system/sharding/EnvelopeShard#92546893])
2017-08-01 12:25:07.341 DEBUG akka.cluster.ClusterRemoteWatcher - Watching: 
[akka://actor-system/system/sharding/EnvelopeShardCoordinator/singleton/coordinator
 
-> akka.tcp://actor-sys...@api-1.api:2551/system/sharding/EnvelopeShard]
2017-08-01 12:25:07.345 DEBUG akka.cluster.ddata.Replicator - Received 
Update for key [EnvelopeShardCoordinatorState]
2017-08-01 12:25:07.348 

[akka-user] Akka-HTTP: How does backpressure work with Futures and execution contexts?

[Josh F]

Hi all,

I am just trying out akka-http and haven't been able to find much 
information about how backpressure works when we use futures and run 
operations async.

For example, if I create a REST API with a route that looks like this:
```
val route = 
  (path("users") & post & entity(as[NewUser])) { user =>
complete(createNewUser(user))
  }
```
where the method `createNewUser(user)` spawns an async operation which 
interacts with a database and returns a Future[User].

Say the database slows down and there is a backlog of pending requests, 
does akka-http recognize that the futures are taking a long time to 
complete, and then slow down the number of calls to createNewUser?

Also how does the execution context used to execute the futures affect the 
backpressure? For example, if my database operations take place on an 
execution context which only supports 4 concurrent operations, will 
akka-http ensure that there are at most 4 pending futures/calls to 
createNewUser at any time?

Thanks for any insights on this!

Josh

-- 
>>  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-1.3.1.xsd schema location

[Konrad “ktoso” Malawski]

Hi there,
you could get them from here:
https://github.com/akka/akka.github.com/tree/968159d916d9a54c5d247c5b228398e1e0d43d68
(old version of what was the website, and had all these files).


—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 1 August 2017 at 17:36:09, francesco.malve...@unimore.it (
francesco.malve...@unimore.it) wrote:

A very old application leveraging akka-camel-1.3.1 is now failing with the
following error:

XmlBeanDefinitionReader.java:396:in `doLoadBeanDefinitions':
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
126 in XML document from class path resource [camel-context.xml] is
invalid; nested exception is org.xml.sax.SAXParseException; lineNumber:
126; columnNumber: 41; cvc-complex-type.2.4.c: il carattere jolly
corrispondente è rigoroso ma non è possibile trovare una dichiarazione per
l'elemento "akka:camel-service".


(the Italian text is about not finding declaration of "akka:camel-service"
element).

The schema definitions in the configuration file are:

http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:akka="http://akka.io/schema/akka;
xmlns:camel="http://camel.apache.org/schema/spring;
xmlns:p="http://www.springframework.org/schema/p;
xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
 http://akka.io/schema/akka
 http://repo.akka.io/akka-1.3.1.xsd
 http://camel.apache.org/schema/spring
 http://camel.apache.org/schema/spring/camel-spring.xsd;>

Today the http://repo.akka.io/ site does not respond.

Is there a current location where I can find the  akka-1.3.1.xsd file?

thank you,

Francesco
--
>> 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] akka-1.3.1.xsd schema location

[francesco . malvezzi]

A very old application leveraging akka-camel-1.3.1 is now failing with the 
following error:

XmlBeanDefinitionReader.java:396:in `doLoadBeanDefinitions': 
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 
126 in XML document from class path resource [camel-context.xml] is 
invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 
126; columnNumber: 41; cvc-complex-type.2.4.c: il carattere jolly 
corrispondente è rigoroso ma non è possibile trovare una dichiarazione per 
l'elemento "akka:camel-service".


(the Italian text is about not finding declaration of "akka:camel-service" 
element).

The schema definitions in the configuration file are:

http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:akka="http://akka.io/schema/akka;
xmlns:camel="http://camel.apache.org/schema/spring;
xmlns:p="http://www.springframework.org/schema/p;
xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
 http://akka.io/schema/akka
 http://repo.akka.io/akka-1.3.1.xsd
 http://camel.apache.org/schema/spring
 http://camel.apache.org/schema/spring/camel-spring.xsd;>

Today the http://repo.akka.io/ site does not respond.

Is there a current location where I can find the  akka-1.3.1.xsd file?

thank you,

Francesco

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