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

[Rafał Krzewski]

Hi Viktor,

I'm passing the OutputStream to a single method that does a bunch of writes 
synchronously and as soon as it returns I do os.close() so I should be 
good, no?

Cheers,
Rafał

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

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

[Rafał Krzewski]

That worked like a charm :) Thanks a lot Johan!

Cheers, 
Rafał

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

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

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

[Rafał Krzewski]

Hi,

I've tried using `StreamConverters.asOutputStream` and immediately run into 
the deadlock described in the documentation [1]

My use case is that I am am creating Excel spreadsheet using Apache POI's 
streaming API [2] and then stream out the result using Akka HTTP.

Under the hood POI is writing the row data into a temporary files on disk. 
When all data is ready, one can write out the result to an arbitrary 
`OutputStream` [3].

When interoperating with Akka HTTP I need to provide a `Source` that is 
materialized by the framework. That's why my intuition was using 
`mapMaterializedValue` to provide the code making use of the `OutputStream` 
at the site when I'm creating the source. Unfortunately this does not work. 
I was able to work around that by writing out the spreadsheet to another 
temporary file, providing a `Source` to Akka HTTP side using `FileIO` and 
some additional song and dance to clean up the temporary files in all 
circumstances.


I am wondering if there is a way I could use 
`StreamConverters.asOutputStream` correctly in this scenario that I don't 
see? Or maybe another kind of API would be necessary here? I'm thinking 
about something along the lines of:


`asOutputStream(f: OutputStream => Done, writeTimeout: FiniteDuration = 
5.seconds): Source[ByteString, Future[IOResult]]`


`f` would be invoked after the stream is ready for writing. After `f` 
completes, the framework could ensure the stream is cleaned up properly. 
The returned `IOResult.status` could be used to check whether `f` completed 
normally. If `f` fails to complete within specified timeout, any further 
attempt to call methods on the `OutputStream` should result in an 
`IOException`. The problem I see is that `f` could get permanently blocked 
on some condition and thus steal a thread from 
`akka.stream.blocking-io-dispatcher` but I don't think there is any way to 
handled that on the JVM.


I am not sure if the above is feasible but if it were I'm sure people would 
find it useful for interfacing with legacy code ;)


Cheers,

Rafał


[1] 
https://doc.akka.io/docs/akka/current/scala/stream/stages-overview.html#additional-sink-and-source-converters

[2] https://poi.apache.org/spreadsheet/how-to.html#sxssf

[3] 
https://poi.apache.org/apidocs/org/apache/poi/xssf/streaming/SXSSFWorkbook.html#write-java.io.OutputStream-

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

[akka-user] Re: [akka-cluster] ShardRegion in proxy mode vs. access ShardRegion via ClusterClient

[Rafał Krzewski]

Hi,

as you are well aware, running multiple separate Akka clusters increases 
operational/administrative burden for your application. Of course some 
applications need to run in separate clusters because of security / 
compliance constraints. But other than that, the more idiomatic way would 
be running a single Akka cluster and using cluster roles to manage how many 
instances of each service are active. I also think ShardRegion in proxy 
mode fits your use case very well.

Cheers,
Rafał

W dniu wtorek, 9 maja 2017 20:34:00 UTC+2 użytkownik Evgeny Shepelyuk 
napisał:
>
> Hello
>
> We're implementing  microservice system consisting of several services 
> representing completely different domains.
> Let's consider that we have following 
>
>- wallet service representing customer balance, supporting deposit, 
>withdraw and get balance commands
>- wallet client service that interacts with a wallet
>
> Because of Docker based infrastructure we have to use ConstructR for Akka 
> Cluster,so setup is not quite trivial.
> Our intentions were
>
>- join wallet service instance into akka cluster
>- do not join wallet client service into cluster
>- expose each ShardRegion via ClusterClientReceptionist
>- from wallet client service access wallets in shards via ClusterClient
>
> But after digging into akka docs, I've found a possibility to use 
> ShardRegion in proxy only mode, so another architecture idea appeared
>
>
>- join wallet and wallet client into the same Akka Cluster
>- on wallet service nodes start ShardRegion in normal mode
>- on wallet client nodes start ShardRegion in proxy only mode
>- access wallets from wallet client using local ShardRegion
>
> Dear community, could you provide pros / cons of both solutions ?
> What is more AKKA way of achieving the goal.
>
> Thanks 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.

[akka-user] Re: [akka-cluster] ClusterClient and ConstructR

[Rafał Krzewski]

Hi Evgeny,

In such situation I'd 
use de.heikoseeberger.constructr.coordination.Coordination (it's subclass 
specific for the data store you are using) on the nodes outside the cluster 
that need to look up contact points.
You can call Coordination.getNodes() and if None comes back, wait some time 
and retry.

Cheers,
Rafał


W dniu czwartek, 4 maja 2017 14:28:53 UTC+2 użytkownik Evgeny Shepelyuk 
napisał:
>
> Hi All
>
> Is there any example of using ConstructR with ClusterClient.
>
> I am having AKKA cluster bootstrapped with ConstructR and Zookeeper, i.e. 
> I have no predefined seed nodes to create ClusterClient.
>
> So, I should connect too Zookeeper and retrieve seed nodes set by 
> ConstructR.
>
> What is the proper way of doing this except using low level Zookeeper API
>
> P.S. This is not Zookeeper specific question, it's the same for  ETCD / 
> Consul.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Slowing down Akka HTTP responses

[Rafał Krzewski]

How about something like:
complete { 
  
Source.single(yourResponse).via(Flow.delay(delayDuration)).to(Sink.head).run() 
}
I'm shooting from the hip here, you may need to use the type of your 
response as parameter somewhere in the middle.
The idea is that Sink.head[T] materializes into a Future[T] so the response 
will be completed asynchronously when delay duration elapses.

Cheers,
Rafał

W dniu wtorek, 28 marca 2017 10:39:09 UTC+2 użytkownik Alan Burlison 
napisał:
>
> I'm working on a simulation using Akka HTTP where the HTTP responses 
> from the real system can have significant delays that I need to 
> replicate. Doing this the simple way by blocking on a sleep would 
> obviously not be a good choice so I'm wondering on how to do this? One 
> idea is to use the Akka Scheduler 
> (http://doc.akka.io/docs/akka/current/scala/scheduler.html) to send a 
> message back to the HTTP actor after a delay containing the response to 
> send back to the client, but I'm wondering if there's a smarter way to 
> do this? 
>
> Thanks, 
>
> -- 
> Alan Burlison 
> -- 
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] transactors and STM are gone. What conception to use instead?

[Rafał Krzewski]

FWIW, there's https://github.com/nbronson/scala-stm. It doesn't seem to be 
actively developed at the moment, but the most recent release was in 
November 2017. 
There's no 2.12 release and some changes are needed, 
see https://github.com/nbronson/scala-stm/issues/53
If you are interested in this kind of approach, getting involved with that 
project could be a better way forward than ripping out old code from Akka.

W dniu niedziela, 19 marca 2017 17:56:44 UTC+1 użytkownik Justin du coeur 
napisał:
>
> On Sat, Mar 18, 2017 at 4:23 PM, scala solist  > wrote:
>
>> So now I'm still using akka for single-JVM multitasking and has no desire 
>> to go back to synchronized. So I need to program local transactions 
>> somehow. It is definitely feasible since it could be done in single-JVM 
>> with synchronized. But I'd like to find idiomatic actor way.
>>
>
> I don't know if you're going to find anything that is meaningfully 
> idiomatic for the current world, given that distributed is pretty integral 
> to the current idiom.  But I suspect that the best way to start may be to 
> look at the old transactors and STM, and see if that code can be revived as 
> an external library.  I don't know offhand whether that's possible, but it 
> likely at least would provide good guidance... 
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 Streams + TCP + TLS

[Rafał Krzewski]

What JVM and Scala versions are you using? What are your project's 
dependency versions?
hint:
os shell> java -version
sbt> scalaVersion
sbt> libraryDependencies

cheers,
Rafał

W dniu wtorek, 14 marca 2017 20:23:15 UTC+1 użytkownik Pablo Milanese 
napisał:
>
> Hi Konrad,
>
> At the first view, I think the could not fnid any error .. but please take 
> into account that I am a scala beginner :)
> Now,  I am trying to test the code, and I am having a problem whe I 
> execute the line:
>
> val sslConfig: AkkaSSLConfig = AkkaSSLConfig.get(system)
>
>
> java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: 
> scala/runtime/java8/JFunction1
> at 
> com.typesafe.sslconfig.util.ConfigLoader$.(Configuration.scala:180)
> at com.typesafe.sslconfig.util.ConfigLoader$.(Configuration.scala)
> at com.typesafe.sslconfig.ssl.SSLConfigParser.parse(Config.scala:495)
> at com.typesafe.sslconfig.ssl.SSLConfigFactory$.parse(Config.scala:483)
> at 
> com.typesafe.sslconfig.akka.AkkaSSLConfig$.defaultSSLConfigSettings(AkkaSSLConfig.scala:34)
> at 
> com.typesafe.sslconfig.akka.AkkaSSLConfig$.createExtension(AkkaSSLConfig.scala:29)
> at 
> com.typesafe.sslconfig.akka.AkkaSSLConfig$.createExtension(AkkaSSLConfig.scala:19)
> at akka.actor.ActorSystemImpl.registerExtension(ActorSystem.scala:899)
> at akka.actor.ExtensionId.apply(Extension.scala:79)
> at akka.actor.ExtensionId.apply$(Extension.scala:79)
> at com.typesafe.sslconfig.akka.AkkaSSLConfig$.apply(AkkaSSLConfig.scala:24)
> at com.typesafe.sslconfig.akka.AkkaSSLConfig$.apply(AkkaSSLConfig.scala:19)
> at akka.actor.ExtensionId.get(Extension.scala:91)
> at akka.actor.ExtensionId.get$(Extension.scala:91)
> at com.typesafe.sslconfig.akka.AkkaSSLConfig$.get(AkkaSSLConfig.scala:23)
> at 
> com.paytrue.swakka.actors.channels.AbstractTcpServer.tlsStage(TcpServer.scala:88)
> at 
> com.paytrue.swakka.actors.channels.AbstractTcpServer.$anonfun$handler$1(TcpServer.scala:67)
> at 
> com.paytrue.swakka.actors.channels.AbstractTcpServer.$anonfun$handler$1$adapted(TcpServer.scala:64)
> at akka.stream.impl.fusing.Map$$anon$8.onPush(Ops.scala:43)
> at 
> akka.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:747)
> at 
> akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:710)
> at 
> akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:616)
> at 
> akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:471)
> at 
> akka.stream.impl.fusing.GraphInterpreterShell.receive(ActorGraphInterpreter.scala:423)
> at 
> akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:603)
> at 
> akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:618)
> at akka.actor.Actor.aroundReceive(Actor.scala:497)
> at akka.actor.Actor.aroundReceive$(Actor.scala:495)
> at 
> akka.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:529)
> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)
> at akka.actor.ActorCell.invoke(ActorCell.scala:495)
> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
> at akka.dispatch.Mailbox.run(Mailbox.scala:224)
> at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> at 
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> at 
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
> Caused by: java.lang.NoClassDefFoundError: scala/runtime/java8/JFunction1
> ... 38 more
> Caused by: java.lang.ClassNotFoundException: scala.runtime.java8.JFunction1
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 38 more
>
>
> Any idea ?
> Thank you!
>
> El lunes, 13 de marzo de 2017, 22:13:57 (UTC-3), Pablo Milanese escribió:
>>
>> Hello Konrad,
>>
>> Of course! No problem.
>> I will take a look to the code.
>>
>> Thank you a lot !
>>
>>
>>
>> El lunes, 13 de marzo de 2017, 18:28:42 (UTC-3), Konrad Malawski escribió:
>>>
>>> (did the conversion in a rush)
>>>
>>> -- 
>>> Konrad `ktoso` Malawski
>>> Akka  @ Lightbend 
>>>
>>> On 13 March 2017 at 22:26:51, Pablo Milanese (pablomi...@gmail.com) 
>>> wrote:
>>>
>>>  
>>> https://github.com/typesafehub/activator-akka-stream-java8/blob/master/src/main/java/sample/stream/TcpTLSEcho.java
>>>
>>>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because 

Re: [akka-user] Re: Scheduled event for sharded entity

[Rafał Krzewski]

You're welcome!

Happy hAkking :)
Rafał

W dniu wtorek, 14 marca 2017 09:03:05 UTC+1 użytkownik Arno Haase napisał:
>
> Rafał, 
>
> snapshotting these big amounts of data in the schedulers feels like a 
> bad trade-off, especially since this is not a core feature of the 
> system, but I guess I will just do some tests. 
>
> Storing the data in Cassandra with a hash as partition key to distribute 
> load, and the timestamp and user as cluster key, and querying the 
> database at intervals, looks like a promising alternative to me which I 
> will also look into. 
>
> Thanks for the discussion! 
>
> - Arno 
>
>
> Am 13.03.2017 um 21:01 schrieb Rafał Krzewski: 
> > Arno, 
> > 
> > yes, you'd have to to send a message resetting the timer on each 
> > interaction. I agree that it can become a problem. 
> > You could split the state of the scheduler actor by creating a bunch of 
> > them and using consistent hashing for assigning a subset of users 
> > entities to each scheduler. Nevertheless the totality of the scheduler 
> > actors' state will be full mapping userId -> timestamp, so I'm not sure 
> > if that helps. 
> > 
> > cheers, 
> > Rafał 
> > 
> > W dniu środa, 8 marca 2017 16:34:49 UTC+1 użytkownik Arno Haase napisał: 
> > 
> > Rafał, 
> > 
> > thank you for the fast reply! 
> > 
> > I had though about using a separate 'scheduler' actor but could not 
> > quite get my head around it. I want user inactivity to trigger an 
> > action 
> > - wouldn't I have to send an an event to the scheduler actor 
> whenever 
> > any user interacted with the system to 'restart' that user's 
> timeout? 
> > And wouldn't the scheduler actor's state become prohibitively large, 
> > containing a 'last active' timestamp for every user in the system? 
> > 
> > The core of the problem for me is that only a small fraction of user 
> > interactions will be the 'last interaction before a timeout', but 
> the 
> > application has no way of knowing in advance which they are. 
> > 
> > Does that make sense? Any advice is much appreciated! 
> > 
> > - Arno 
> > 
> > 
> > Am 08.03.2017 um 14:07 schrieb Rafał Krzewski: 
> > > Hi Arno, 
> > > 
> > > I think you need a separate persistent actor that will keep track 
> of 
> > > long-term scheduled events. It will be active at all times and 
> > keep an 
> > > agenda of future notifications in it's persistent storage. It will 
> > use 
> > > ActorSystem Scheduler to wake itself up when it's time to send out 
> > next 
> > > (batch of) notification(s). A message sent to a shared User entity 
> > will 
> > > activate the target if necessary. 
> > > I think it will be reasonable from resource management point of 
> view, 
> > > and also safe against system restarts. 
> > > 
> > > Cheers, 
> > > Rafał 
> > > 
> > > W dniu środa, 8 marca 2017 06:35:11 UTC+1 użytkownik Arno Haase 
> > napisał: 
> > > 
> > > I am working on a social media kind of system, and we have 
> users 
> > > represented as sharded persistent entities. Now we want to 
> > react to 
> > > users' inactivity, e.g. sending out 'come back' emails to 
> > users who 
> > > were 
> > > inactive for a week. 
> > > 
> > > Any suggestions for how to implement that? Scheduling (and 
> mostly 
> > > cancelling) messages in every user's actor seems both wasteful 
> > and 
> > > unreliable, at least if we remove long unused entities from 
> > memory. 
> > > 
> > > All ideas are welcome! 
> > > 
> > > - Arno 
> > > 
> > > -- 
> > >>>>>>>>>>> Read the docs: http://akka.io/docs/ 
> > >>>>>>>>>>> Check the FAQ: 
> > > http://doc.akka.io/docs/akka/current/additional/faq.html 
> > <http://doc.akka.io/docs/akka/current/additional/faq.html> 
> > >>>>>>>>>>> Search the archives: 
> > https://groups.google.com/group/akka-user 
> > <https://groups.google.com/group/akka-user> 
> > > --- 
> > > You received this message because you are subscribed to the Google 
>

Re: [akka-user] How to define contract between two actor systems

[Rafał Krzewski]

Using akka-remoting / akka-cluster for communication creates very tight 
coupling between components. If these components are being developed by 
separate teams, a lot of deliberate coordination work will be needed.
I think that in modern microsevice-oriented environments it's more typical 
to to use REST or message queue interfaces across different services 
(/teams) to reduce friction.
Message encoding solutions with schema evolution capabilities like Protobuf 
and Avro are often used for creating such interfaces: in this situation 
message schema and not specific code forms the module / service's API. It's 
more formal and unambiguous than any JavaDoc. Another advantage here is the 
ability to mix and match languages and platforms across the teams.

cheers,
Rafał

W dniu sobota, 11 marca 2017 01:56:11 UTC+1 użytkownik Allan Douglas R. de 
Oliveira napisał:
>
> Suyog,
>
> My suggestion is to move these messages to a shared library and let it be 
> your "executable documentation". If anyone needs to send messages to an 
> actor system of another team, just import the library of this team and then 
> you can figure out what are the actors and what case classes you can send 
> to them. If the team that owns the actors uses the same library, then it 
> will always up-to-date.
>
> []'s
>
> On Thu, Mar 9, 2017 at 1:13 PM, suyog choudhari  > wrote:
>
>> Hi Allan,
>>
>> Did you mean that, if two different teams working on different actor 
>> systems, which needs to communicate with each other
>>
>> In this case, one team should look into others code to check what actors 
>> are there and what messages it consumes?
>>
>> Have you tried something like Java Docs with akka which can be 
>> distributed to different teams (this is just a random thought)?
>>
>> On Wednesday, 8 March 2017 09:19:46 UTC-8, Allan Douglas R. de Oliveira 
>> wrote:
>>>
>>> Hi,
>>>
>>> See this snippet of code:
>>> https://gist.github.com/douglaz/e06c1b6dbe95a14407866165af50ad1e
>>>
>>> Look the companion object. It's not what you want (documentation), but 
>>> just an example of a convention that helps figure out what messages an Akka 
>>> actor receives and what kind of data it keeps.
>>>
>>> []'s
>>> ᐧ
>>>
>>> On Tue, Mar 7, 2017 at 2:38 PM, suyog choudhari  
>>> wrote:
>>>
 Hi,

 Is there any recommended practice to define contract between multiple 
 actor systems? 

 In short, how one actor system should release document of what all 
 actors it contains and what kind of messages each actor can expect? 
 Something similar to swagger docs in REST API world.

 Regards,
 Suyog


 -- 
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
 >> Search the archives: 
 https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to 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.

>>>
>>>
>>>
>>> -- 
>>> Allan Douglas R. de Oliveira
>>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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.
>>
>
>
>
> -- 
> Allan Douglas R. de Oliveira
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] transactors and STM are gone. What conception to use instead?

[Rafał Krzewski]

If you are up to for an adventure, I recommend you to read "Life beyond 
Distributed Transactions" paper 
http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
Akka team member also spoke about those concepts at various 
conferences: http://www.ustream.tv/recorded/46670663 
, https://parleys.com/play/545b4d2ae4b08fbc478d8bf9/chapter0/about

cheers,
Rafał


W dniu piątek, 10 marca 2017 20:39:49 UTC+1 użytkownik scala solist napisał:
>
> Thanks for mentioning the saga technique. To my surprise I had already 
> used it without knowing. That is the first thing that comes in mind in 
> certain situations.
>
> But saga by no means could provide a transaction guaranties. The 
> intermediate state is visible to third party during so called transaction 
> and that ruins isolation. The process may crash midway beyond recover 
> ability. By the time the saga master performs "rollback" the actors in 
> question may update their state dozen times, so rollback operation has no 
> meaning or could not be performed. So no atomicity for saga either.
>
> Saga is good to mitigate damage dealt by broken transaction if possible, 
> but it could not provide any guaranties.
>
> On Tuesday, January 31, 2017 at 6:43:38 PM UTC+3, Rafał Krzewski wrote:
>>
>> I think you need to look into saga pattern which is actor model analogue 
>> of (distributed) transactions. It has the advantage that the parties 
>> involved in the transaction do not need to be present on the same VM 
>> (cluster node etc.) which is a prerequisite for STM / Agents.
>>
>> Cheers,
>> 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] Re: Migrating a server from spray to akka-http

[Rafał Krzewski]

Hi Brice,

take a look at https://github.com/spray/spray/issues/780

I haven't tried it but as far as I understand, Route is just a type alias 
for a Function1[RequestContext, Future[RouteResult]] and this function is 
evaluated for every request, so if you do

def mainRoute: Route = Directives.concat(services.map(_.route)) ~ 
staticRoutes

Http().bindAndHandle(mainRoute, address, port) 

It should just work.

Cheers,
Rafał

W dniu czwartek, 9 marca 2017 18:01:19 UTC+1 użytkownik Brice Figureau 
napisał:
>
> Hi all, 
>
> I've started migrating the spray part of my app to akka-http. 
> In this app (an akka-cluster based system), I have an "administration" 
> HTTP REST interface, that runs an akka-http server. 
>
> In my system, all running actors have the possibility to register 
> "administration commands" to this internal server (this is basically an 
> actor). Each registered commands ends up as being a new route for the 
> http server that when triggered delegates to the registered actor. 
>
> Actually this is a bit more complex, because the actor that registers 
> its commands only registers it to the local http server, but we might 
> want to run this command by connecting to any node of the cluster (not 
> the one where the actor is running), so there's a distributed data based 
> system to share routes. 
>
> In short, most of the routes are dynamically inserted and removed, based 
> on actors that spawn (or stop) on nodes. 
>
> When porting this part to akka-http, I was wondering how I could model 
> this dynamic route system, since when calling: 
>  Http().bindAndHandle(routes, address, port) 
>
> the `routes` parameter is a single Route, and as such the route itself 
> is not re-evaluated on each connection. 
>
> In Spray I was doing: 
> def receive = runRoute { 
>  dynamic { 
>services.map(_.route).reduce((a,b) => a ~ b) 
>  } 
>  ~ 
>  ... static routes ... 
> } 
>
> I'm very unsure how I can migrate this part. 
>
> Thanks for any suggestions! 
> -- 
> Brice Figureau  
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 log the response duration of request which returns the Future http response ?

[Rafał Krzewski]

Hi Shivani,

you could do something like this:

  import scala.concurrent._
  import scala.concurrent.duration._
  import akka.actor.ActorSystem
  import akka.stream.Materializer
  import akka.http.scaladsl._
  import akka.http.scaladsl.model._

  def timed(req: HttpRequest)(implicit system: ActorSystem, mat: 
Materializer): Future[(HttpResponse, Duration)] = {
import system.dispatcher
val startTime = System.currentTimeMillis
Http().singleRequest(req).map { resp =>
  val endTime = System.currentTimeMillis
  (resp, Duration(endTime - startTime, MILLISECONDS))
}
  }

cheers,
Rafał

W dniu czwartek, 9 marca 2017 13:12:45 UTC+1 użytkownik Shivani Gupta 
napisał:
>
> my code snippet is 
>
> Future[HttpResponse] = Http().singleRequest(Post(httpUrl, 
> HttpEntity(ContentType(MediaTypes.`application/json`), query)))
>
>
> want to log the response duration of this. How can i do that?
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Scheduled event for sharded entity

[Rafał Krzewski]

Arno,

yes, you'd have to to send a message resetting the timer on each 
interaction. I agree that it can become a problem.
You could split the state of the scheduler actor by creating a bunch of 
them and using consistent hashing for assigning a subset of users entities 
to each scheduler. Nevertheless the totality of the scheduler actors' state 
will be full mapping userId -> timestamp, so I'm not sure if that helps.

cheers,
Rafał

W dniu środa, 8 marca 2017 16:34:49 UTC+1 użytkownik Arno Haase napisał:
>
> Rafał, 
>
> thank you for the fast reply! 
>
> I had though about using a separate 'scheduler' actor but could not 
> quite get my head around it. I want user inactivity to trigger an action 
> - wouldn't I have to send an an event to the scheduler actor whenever 
> any user interacted with the system to 'restart' that user's timeout? 
> And wouldn't the scheduler actor's state become prohibitively large, 
> containing a 'last active' timestamp for every user in the system? 
>
> The core of the problem for me is that only a small fraction of user 
> interactions will be the 'last interaction before a timeout', but the 
> application has no way of knowing in advance which they are. 
>
> Does that make sense? Any advice is much appreciated! 
>
> - Arno 
>
>
> Am 08.03.2017 um 14:07 schrieb Rafał Krzewski: 
> > Hi Arno, 
> > 
> > I think you need a separate persistent actor that will keep track of 
> > long-term scheduled events. It will be active at all times and keep an 
> > agenda of future notifications in it's persistent storage. It will use 
> > ActorSystem Scheduler to wake itself up when it's time to send out next 
> > (batch of) notification(s). A message sent to a shared User entity will 
> > activate the target if necessary. 
> > I think it will be reasonable from resource management point of view, 
> > and also safe against system restarts. 
> > 
> > Cheers, 
> > Rafał 
> > 
> > W dniu środa, 8 marca 2017 06:35:11 UTC+1 użytkownik Arno Haase napisał: 
> > 
> > I am working on a social media kind of system, and we have users 
> > represented as sharded persistent entities. Now we want to react to 
> > users' inactivity, e.g. sending out 'come back' emails to users who 
> > were 
> > inactive for a week. 
> > 
> > Any suggestions for how to implement that? Scheduling (and mostly 
> > cancelling) messages in every user's actor seems both wasteful and 
> > unreliable, at least if we remove long unused entities from memory. 
> > 
> > All ideas are welcome! 
> > 
> > - Arno 
> > 
> > -- 
> >>>>>>>>>>> Read the docs: http://akka.io/docs/ 
> >>>>>>>>>>> Check the FAQ: 
> > http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> > --- 
> > You received this message because you are subscribed to 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  
> > <mailto:akka-user+...@googlegroups.com >. 
> > To post to this group, send email to akka...@googlegroups.com 
>  
> > <mailto: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 make Akka stream to write on Orcacle Database using Java

[Rafał Krzewski]

Sink.foreachParallel is probably the easiest way to implement writing to a 
JDBC. Things to keep in mind: set parallel argument to 1 if you need write 
the elements in the same order as they arrive - usually it shouldn't matter 
but if you are generating a surrogate primary key using a sequence you may 
want to have the ids in the same order as the source items. If you don't 
care about order, set parallel to the maximum number of JVM threads and 
JDBC connections you want to use for writing at any given time. Choosing an 
optimal value is very dependent on your particular data & DB setup.
It's very important to use a dedicated executionContext for foreachParallel 
because 
it's threads are going to be blocked. Using your ActorSystem's dispatcher 
for this purpose will result in extremely bad performance.

Cheers,
Rafał

W dniu czwartek, 9 marca 2017 11:16:31 UTC+1 użytkownik DEEPAK GUPTA 
napisał:
>
> How to make Akka stream to write on Orcacle Database using Java. Example 
> will help A lot.
> Thanks 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.

[akka-user] Re: akka java tutorial , docs is too much messy

[Rafał Krzewski]

Hi,

I feel sorry for you that you are working under such pressure that you are 
forced to use a tool and not given sufficient time to study the available 
documentation. 
In my opinion documentation of Akka is excellent, one of the best I've ever 
encountered in any open source project. Moreover there are many good books 
available about the actor model and reactive programming and also about 
Akka specifically.
I don't think Akka is a toolkit that you can use by copying the examples 
from a tutorial. There are many concepts that you need to understand to use 
Akka properly - if you don't you'll run into many problems and benefit only 
little from features that Akka provides.

regards,
Rafał

W dniu czwartek, 9 marca 2017 09:38:40 UTC+1 użytkownik Laxmi Narayan 
napisał:
>
> Hi , 
>
> I really need to use this toolkit with my spring / java Impl. But I am 
> really having a real hard time to learn this.
>
> I am not getting any book or youtube channel with akka-java tutorial , I 
> have understood basic but still deep concepts 
>
> I am not able to understand , Please let me know if you know any java 
> tutorial for akka.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 get the number of source actors with akka stream?

[Rafał Krzewski]

Hi Leo,

your disconnect() method was invoked at the time stream definition was 
constructed, and connected() method was invoked the previously constructed 
stream definition was materialized into a live stream instance.
The second argument of Sink.actorRef is the message object that will be 
sent to the actor referred to by the firs argument when the stream is 
completed. You should handle that message in your actor code.

Hope that helps,
Rafał

W dniu czwartek, 9 marca 2017 08:31:30 UTC+1 użytkownik Leo Wolf napisał:
>
> Hi Rafał,
>
> I have a source as val userSource = Source.actorRef(10, OverflowStrategy.
> fail).mapMaterializedValue(connected())), and a sink as val userSink = 
> Sink.actorRef[NotifyEnvelope](usrActor, disconnect())
>
> And I printed the log in the connected() and the disconnect(), but found 
> out when the connection was established, the disconnect() always be called 
> first, then the connected(). Thus if I use the counter in the disconnect() 
> and connected(), the counter will be not correct. Do you know any 
> information about why disconnect() will be called first then the 
> connected()?
>
> p.s.: I have confirmed the connection was established correctly.
>
> Many thanks,
> Leo
>
> Rafał Krzewski於 2017年3月5日星期日 UTC+8下午5時27分38秒寫道：
>>
>> Hi Leo,
>>
>> The actor is created each time you materialize a new instance of your 
>> stream, which is something your application code does explicitly. 
>> Materializing the stream yields and ActorRef that you can send to a 
>> dedicated tracking actor.
>> Each time it receives and ActorRef, it increments an internal counter and 
>> starts to watch that ActorRef. Each time it receives a Terminated message 
>> it decrements the counter. Finally, each time it receives a dedicated 
>> ReturnCount message it responds with current value of the counter.
>>
>> Cheers,
>> Rafał
>>
>> W dniu czwartek, 2 marca 2017 12:00:00 UTC+1 użytkownik Leo Wolf napisał:
>>>
>>> Hi,
>>>
>>> I have a question about how to measure the number of source actors with 
>>> akka stream?
>>> In code of akka stream, we can use Source.actorRef to create souce 
>>> actor for akka streaming, but is there any way to get the number of created 
>>> actors rather than calculate it in code of akka stream? Since every 
>>> actor has a supervisor for it, can I get the number of created source 
>>> actors by the supervisor? If yes, then how? Thanks for the help!
>>>
>>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+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: Scheduled event for sharded entity

[Rafał Krzewski]

Hi Arno,

I think you need a separate persistent actor that will keep track of 
long-term scheduled events. It will be active at all times and keep an 
agenda of future notifications in it's persistent storage. It will use 
ActorSystem Scheduler to wake itself up when it's time to send out next 
(batch of) notification(s). A message sent to a shared User entity will 
activate the target if necessary.
I think it will be reasonable from resource management point of view, and 
also safe against system restarts.

Cheers,
Rafał 

W dniu środa, 8 marca 2017 06:35:11 UTC+1 użytkownik Arno Haase napisał:
>
> I am working on a social media kind of system, and we have users 
> represented as sharded persistent entities. Now we want to react to 
> users' inactivity, e.g. sending out 'come back' emails to users who were 
> inactive for a week. 
>
> Any suggestions for how to implement that? Scheduling (and mostly 
> cancelling) messages in every user's actor seems both wasteful and 
> unreliable, at least if we remove long unused entities from memory. 
>
> All ideas are welcome! 
>
> - Arno 
>

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

[akka-user] Re: [Akka Streams] How can i use java.sql.ResultSet as akka streams source

[Rafał Krzewski]

Hi Deepak,

http://lmgtfy.com/?q=JDBC+query+as+a+reactive+stream

You are welcome :)
Rafał

W dniu poniedziałek, 6 marca 2017 16:53:14 UTC+1 użytkownik DEEPAK GUPTA 
napisał:
>
> [Akka Streams] How can i use java.sql.ResultSet as akka streams source
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 get the number of source actors with akka stream?

[Rafał Krzewski]

Hi Leo,

The actor is created each time you materialize a new instance of your 
stream, which is something your application code does explicitly. 
Materializing the stream yields and ActorRef that you can send to a 
dedicated tracking actor.
Each time it receives and ActorRef, it increments an internal counter and 
starts to watch that ActorRef. Each time it receives a Terminated message 
it decrements the counter. Finally, each time it receives a dedicated 
ReturnCount message it responds with current value of the counter.

Cheers,
Rafał

W dniu czwartek, 2 marca 2017 12:00:00 UTC+1 użytkownik Leo Wolf napisał:
>
> Hi,
>
> I have a question about how to measure the number of source actors with 
> akka stream?
> In code of akka stream, we can use Source.actorRef to create souce actor 
> for akka streaming, but is there any way to get the number of created 
> actors rather than calculate it in code of akka stream? Since every actor 
> has a supervisor for it, can I get the number of created source actors by 
> the supervisor? If yes, then how? Thanks for the help!
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+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] newbie question about await inside actors code

[Rafał Krzewski]

Why use await, when pipeTo pattern provides clean, non-blocking integration 
between Futures and Actors?
As far as I know, the only situation when blocking in actor code is 
justifiable is interacting with legacy code that just blocks the calling 
thread and offers no way around it, like JDBC does. Of course one should 
use a dedicated dispatcher then, to avoid starving regular actors of 
resources.

W dniu poniedziałek, 20 lutego 2017 12:56:42 UTC+1 użytkownik Alan Burlison 
napisał:
>
> > This is not a solution because it creates one new thread for every 
> blocker. 
>
> In general I agree, but if the code has already aggregated all the 
> futures into a single one, as seems to be suggested in an earlier 
> email, wouldn't it be an option - albeit not an ideal one? 
>
> -- 
> Alan Burlison 
> -- 
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Cluster on different nodes minimally sharing code

[Rafał Krzewski]

Great! I'm glad it worked out OK for you :) Maybe you could publish your 
sample project on github and post a link to this thread?
I think people the come across it the future will appreciate it.

Cheers,
Rafał


W dniu poniedziałek, 20 lutego 2017 11:09:18 UTC+1 użytkownik 
klaus.wie...@gmail.com napisał:
>
> Okay,
>
> so I did my homework myself. I rewrote the 'lightbend's transformation 
> example from akka-sample-cluster-scala' to
> have separated codebases (JARS) for each role and one for the common 
> messages. It is running not only in different JVMs but also on different 
> cluster nodes (machines).
>
> If anybody is interested, please give me an e-mail (address in header) and 
> I'll publish it in my blog. 
>
> Have fun!
>
> Klaus
>
> PS: Thanks again to Rafal and Tal
>
> On Friday, February 17, 2017 at 11:38:10 AM UTC+1, klaus.wie...@gmail.com 
> wrote:
>>
>>
>>
>> On Thursday, February 16, 2017 at 4:40:10 PM UTC+1, Rafał Krzewski wrote:
>>>
>>>
>>> I'm sorry but this is getting into "please do my homework for me" 
>>> territory, so I must respectfully decline. 
>>>
>>> Cheers,
>>> Rafał
>>>
>>
>> You make me feel like a schoolboy - after all these years a heart-warming 
>> experience.
>>
>> Thank you for all your help!
>> Klaus 
>>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] newbie question about await inside actors code

[Rafał Krzewski]

The actor itself is the place where state should be held. If the actor 
"should not be bothered" by the dispatcher until a specific condition 
occurs, just stash the incoming messages for processing later. 
ActorContext.become lets you switch behaviors, for example available / 
unavailable state. When entering available state, you just unstash the 
postponed messages.

As Justin said, all the pieces needed to implement the usecase you describe 
are already there, and no sleeping or blocking is necessary.

I wouldn't say that Akka is complicated at the conceptual level. Quite the 
contrary: in my opinion it is remarkably simple and elegant. It is very 
different from typical JVM threads and locks concurrency, so it might be 
hard to wrap your head around at first.

Cheers,
Rafał

W dniu niedziela, 19 lutego 2017 21:30:19 UTC+1 użytkownik scala solist 
napisał:
>
>
> On Sunday, February 19, 2017 at 10:53:01 PM UTC+3, Justin du coeur wrote:
>>
>> Do you mean literally calling "sleep()"?  
>>
>
> I mean sleep as a thread state. Alternative is to save actor state somehow 
> and return thread to dispatcher so it can be reused. The dispatcher should 
> never bother the actor until it become available. It complicates things for 
> the actor system, but Akka is already very complicated and I'm not sure if 
> it is already implemented somewhere 
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Cluster on different nodes minimally sharing code

[Rafał Krzewski]

W dniu czwartek, 16 lutego 2017 12:28:49 UTC+1 użytkownik 
klaus.wie...@gmail.com napisał:
>
>
> > May be because I'm an old-fashioned guy who wrote his first 
> Pascal-compiler on an 8-Bit Micro with 32 KByte memory back in the 80ties. 
> But, more reasonable, the less custom code is loaded onto a node, the 
> easier it should be to find bugs made by myself, especially as long as I 
> don't have a feeling what goes on under the hood in the heavy weight  
> cluster infrastructure. 
>

I appreciate the sentiment, but having extra unused application code that 
is not getting invoked will probably be the least of your problems while 
debugging.
Eclipse is not very popular nowadays, but Scala IDE has an unique debugger 
features built specifically for Akka: 
http://scala-ide.org/docs/current-user-doc/features/async-debugger/index.html
 

> I'm a cluster newbie still - as I already confessed. So most likely I make 
> more mistakes in configuration than in actor code. 
>

I think you should look carefully into specific use cases where Akka 
Cluster is useful. You can build distributed applications using Akka 
without using akka-cluster or even akka-remoting. Communication using 
external queues (RabbitMQ, Kafka etc) or load-balanced HTTP might be a 
better choice in some applications. On the other hand if you need hundreds 
of thousands persistent actors active simultaneously or a read-intensive 
eventually consistent KV store that can handle 1 million reads per second 
from every application node, akka-cluster is indispensable.
 

> The more a little tiny but complete and working example (separated code 
> and configuration for each role) would be very very welcome (.e.g 
> lightbend's transformation example from akka-sample-cluster-scala). 
> Shouldn't be so hard for a professional ;-)
>

I'm sorry but this is getting into "please do my homework for me" 
territory, so I must respectfully decline. 

Cheers,
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] Re: Cluster on different nodes minimally sharing code

[Rafał Krzewski]

W dniu środa, 15 lutego 2017 17:12:04 UTC+1 użytkownik 
klaus.wie...@gmail.com napisał:
>
> Hi Tal,
>
> thank you for you tip.
>
> The answer to your question is: all the examples I've seen so far use one 
> cluster only. You are right, the task itself does not even require the 
> manager to be in any cluster if there is exactly one manager. So your 
> answer is very reasonable. I'll soon check it out.
>

Cluster is a heavy-weight resource. It brings on certain administrative 
challenges, especially when running on a public cloud. Running two clusters 
when in fact you could run one with two node flavors (roles) is an 
overkill. 
 

>
> However, the question that arises is: Is it necessary in Akka that all 
> nodes of a cluster have the same code base?
>

No, they don't have to. You just need to make sure that all messages can be 
de-serialized on the recipient node. There's nothing preventing you from 
splitting your project into multiple modules and packaging a separate 
binary artifact for each of the node roles that you require. Having a 
single artifact is just a simplification. Please note that even if 
unnecessary code is 1MB of compiled classes (which would require a lot of 
source code), your final artifact will typically weigh dozens MBs for a 
.tar.gz to hundreds of MBs for a Docker image. So why bother, actually?
 
Cheers,
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] Re: Cluster on different nodes minimally sharing code

[Rafał Krzewski]

Hi Klaus,

it might not look neat, but having only one binary that's getting installed 
to all nodes of the cluster is a very practical simplification of both 
development and operation side of things. You have a single build 
definition, an you can't mix up binaries at deployment time, because 
there's only one :)

You can set up your application to set an instance's cluster role using an 
environment variable (eg. put akka.cluster.roles = [${CLUSTER_ROLE}] in 
your application.conf) and check it using Cluster.getSelfRoles at runtime 
and adjust instance behavior appropriately,

If you then use a cluster manager like Kubernetes, Mesos or Docker Swarm 
you can use this environment variable to create pod/service definitions for 
each of the roles and scale them horizontally as needed.

Cheers,
Rafał

W dniu wtorek, 14 lutego 2017 17:01:08 UTC+1 użytkownik 
klaus.wie...@gmail.com napisał:
>
> I'm trying to make a cluster with one manager and multiple workers. As a 
> greenhorn in akka clusters I first googled around. I've found plenty of 
> examples for clusters running on a single JVM, which to me, is an antinomy. 
> And I've found a handful of examples running on different JVMs on the same 
> node. Thats already something, but only half of the story: these examples 
> simply copied or used ALL of the cluster code to all JVMs and started the 
> actor systems with all the worker AND manager code in the classpath. But 
> that's ugly and not what I want. I'd like to nicely separate the code 
> dedicated to the manager form the code dedicated to the workers (and 
> possibly the common code). I don't like manager code on the worker nodes or 
> worker code on the manager nodes (actor systems).
>
> I succeeded to do this with remoting (sending a string message to a remote 
> actor (system)). I'd like to do this in a cluster. I'd like to keep it as 
> simple as possible (no special routing policy necessary, actors may join 
> manually, ...)
>
> Can you please help me to overcome my stupidity?
>
> Klaus W,
>
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 ACID

[Rafał Krzewski]

Akka is much better fit for event sourcing architectures, and eventual 
rather than global consistency (implied by ACID).
Regarding coordination of different services, the typical approach of Akka 
applications is the saga pattern and compensating transactions.

"Reactive design patterns" by dr R. Kuhn and J. Allen is an excellent 
reference here: service orchestration patterns are described in chapter 15.

W dniu niedziela, 12 lutego 2017 05:07:03 UTC+1 użytkownik Sovon Nath 
napisał:
>
> Thanks Arno!
>
> My question was related to, how should I call multiple APIs and ensure, 
> that all of these calls are successful and happens only once. The solution 
> you provided, for DB, can also be for APIs. I still have some doubts about 
> this:
> - What if the API calls take time, and we drop it from the calling 
> function, but in the backend it was successful
> - What if the job that is performing the commit has to do it over multiple 
> DB and some succeed and some fail 
>
> Also, how should be orchestrate the API calls.
>
> On Saturday, February 11, 2017 at 4:17:34 AM UTC-5, Arno Haase wrote:
>>
>> Assuming you are thinking about transactional access to a relational 
>> database, you could have an actor representing the transaction. Every 
>> write goes to it as a message, and it stores these operations. A 
>> 'commit' message can then trigger the actual database transaction, with 
>> all writes being done in a single burst. 
>>
>> There are some limitations to this, mainly that there is no direct 
>> feedback based on a single write operation (e.g. number of affectred 
>> rows for an update to implement optimistic locking). You can get around 
>> these by adding a protocol on top, but that increases complexity and 
>> puts some burden on using code. 
>>
>> - Arno 
>>
>> Am 10.02.2017 um 23:29 schrieb Sovon Nath: 
>> > Hi All, 
>> > I am trying to evaluate Akka for one of our use cases. Is there any 
>> > standard pattern to implement ACID transactions in Akka? Also is there 
>> > any recommended orchestration tools that we can use for Akka APIs? 
>> > 
>> > -- 
>> >>> Read the docs: http://akka.io/docs/ 
>> >>> Check the FAQ: 
>> > http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>> Search the archives: 
>> https://groups.google.com/group/akka-user 
>> > --- 
>> > You received this message because you are subscribed to 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: Akka: How to get Children actor on Restart

[Rafał Krzewski]

All children actors are stopped when the parent is restarted. The 
information what the children of the previous actor incarnation were is not 
useful, because they no loner exist by the time then next incarnation of 
the parent actor is created. The new incarnation proceeds to create it's 
children actors as needed. That's one of the crucial element's of Akka 
fault tolerance approach succinctly summarized as "Let it crash". It 
prevents actor instance leaks and makes application code simpler: 
recreating a part of actor hierarchy in known good state after a failure is 
much easier than trying to recover and patch together remaining bits of 
state. 


W dniu piątek, 10 lutego 2017 03:40:48 UTC+1 użytkownik Achin Gupta napisał:
>
> My use case is:
>
> Before restart, there are let say 5 children of a parent. Now, i wish to 
> calculate performance and to calculate performance i need participation 
> from all these 5 children. So, after restart, i could just send the same 
> message to all children, after which children will work and respond to 
> parent. However, after restart, i am not even aware of who the children 
> were. So, what's the best way to solve these type of problems?
>
> On Thursday, 9 February 2017 22:28:50 UTC+5:30, Achin Gupta wrote:
>>
>> Thank you for the reply.
>> And, i understand that in preRestart, the parent unwatches the child. 
>>  And, hence if i override this method to do nothing, i should get the 
>> context.children() value correct.  But when i tried doing so, i still see 
>> empty collection.  Not sure what i am doing wrong.
>>
>> On Thursday, 9 February 2017 22:14:48 UTC+5:30, Rafał Krzewski wrote:
>>>
>>> Check preRestart method implementation as described in 
>>> http://doc.akka.io/docs/akka/2.4/scala/actors.html#Actor_API
>>> It should answer your question :)
>>>
>>> Cheers,
>>> Rafał
>>>
>>> W dniu czwartek, 9 lutego 2017 17:18:24 UTC+1 użytkownik Achin Gupta 
>>> napisał:
>>>>
>>>> When the System is restarted, the context.children() call returns zero 
>>>> children for a particular parent. Before restart, context.children() 
>>>> returned the actual count of children that parent had.
>>>>
>>>> Can someone please let me know how can we get the children ActorRef for 
>>>> a parent after restart?
>>>>
>>>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: How to get Children actor on Restart

[Rafał Krzewski]

Check preRestart method implementation as described 
in http://doc.akka.io/docs/akka/2.4/scala/actors.html#Actor_API
It should answer your question :)

Cheers,
Rafał

W dniu czwartek, 9 lutego 2017 17:18:24 UTC+1 użytkownik Achin Gupta 
napisał:
>
> When the System is restarted, the context.children() call returns zero 
> children for a particular parent. Before restart, context.children() 
> returned the actual count of children that parent had.
>
> Can someone please let me know how can we get the children ActorRef for a 
> parent after restart?
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Can I use Akka for such kind of architecture?

[Rafał Krzewski]

The client in private network opens the connection to the server in DMZ. 
WebSocket protocol allows bi-directional communication: the server may push 
messages the the client, and akka-http / akka-streams ensure backpressure 
propagation.


W dniu czwartek, 9 lutego 2017 14:32:59 UTC+1 użytkownik Christian Kaps 
napisał:
>
> Sorry, I meant bidirectional
>
> Am Donnerstag, 9. Februar 2017 13:10:06 UTC+1 schrieb Christian Kaps:
>>
>> And this would work without any inbound traffic from the DMZ to the 
>> private network? I had firstly the same idea. But then I thought that the 
>> web socket connection must be directional.
>>
>> Best regards,
>> Christian
>>
>> Am Donnerstag, 9. Februar 2017 12:27:57 UTC+1 schrieb Rafał Krzewski:
>>>
>>> I would probably let the proxy node in DMZ run an akka-http server and 
>>> publish a WebSocket endpoint. The worker node in private network would 
>>> connect to it using akka-http client. This is probably the easiest way to 
>>> stream messages from DMZ to private zone with backpressure and (some degree 
>>> of) delivery guarantees. Akka Streams and Akka HTTP handle a lot of 
>>> complexity for you and are preferred tool over low level TCP machinery. Of 
>>> course if you need millisecond latencies and custom binary protocols, you 
>>> need to get your hands dirty :)
>>>
>>> Cheers,
>>> Rafał
>>>
>>> W dniu czwartek, 9 lutego 2017 11:32:55 UTC+1 użytkownik Christian Kaps 
>>> napisał:
>>>>
>>>> Hi Rafał,
>>>>
>>>> Thanks for your answer! Maybe I implement an Akka TCP server which is 
>>>> located in the DMZ and a TCP client which is located in the private 
>>>> network. Is it possible that the client polls message in near real-time 
>>>> from the TCP server? Am I right, that this is possible with Pull-reading 
>>>> as 
>>>> described in the Throttling Reads and Writes 
>>>> <http://doc.akka.io/docs/akka/current/scala/io-tcp.html#Throttling_Reads_and_Writes>
>>>>  
>>>> section of the Akka TCP documentation?
>>>>
>>>> Best regards,
>>>> Christian
>>>>
>>>> Am Donnerstag, 9. Februar 2017 10:23:09 UTC+1 schrieb Rafał Krzewski:
>>>>>
>>>>> Hi Christian,
>>>>>
>>>>> Akka is very general toolkit and you can implement any communication 
>>>>> architecture that you need with it. It offers excellent HTTP support and 
>>>>> also low-level TCP and UDP communication and you can implement any 
>>>>> standard 
>>>>> or custom protocol on top of that.
>>>>> Akka Cluster however does not sound like something that would fit here:
>>>>> - it requires bidirectional connectivity among all nodes that are 
>>>>> parts of the cluster
>>>>> - the network connecting the nodes is assumed to be trusted
>>>>> - Akka Cluster is useful when you need to create an Actor system so 
>>>>> large that it does not fit on a single machine because of memory or 
>>>>> processing power requirements (say, millions of entities interacting in 
>>>>> real time)
>>>>>
>>>>> Cheers,
>>>>> Rafał
>>>>>
>>>>> W dniu czwartek, 9 lutego 2017 09:48:22 UTC+1 użytkownik Christian 
>>>>> Kaps napisał:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> for a project we need a special type of server architecture. Because 
>>>>>> of a customer compliance we cannot access the customers database server 
>>>>>> from the DMZ. The server on which the database runs can access servers 
>>>>>> inside the DMZ. In a similar project my employee has used a proxy like 
>>>>>> architecture with an additional database server. The outer side writes 
>>>>>> requests into this proxy database and the inner side polls this database 
>>>>>> for requests and writes results to it. The outer side polls then for the 
>>>>>> results.
>>>>>>
>>>>>> Is such a kind of architecture possible with Akka? Maybe with a 
>>>>>> cluster like architecture?
>>>>>>
>>>>>> Outside(Public)  | DMZ | Inside
>>>>>> Frontend Server | Backend Server | Database Server
>>>>>>
>>>>>> Best regards,
>>>>>> Christian
>>>>>>
>>>>>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Can I use Akka for such kind of architecture?

[Rafał Krzewski]

I would probably let the proxy node in DMZ run an akka-http server and 
publish a WebSocket endpoint. The worker node in private network would 
connect to it using akka-http client. This is probably the easiest way to 
stream messages from DMZ to private zone with backpressure and (some degree 
of) delivery guarantees. Akka Streams and Akka HTTP handle a lot of 
complexity for you and are preferred tool over low level TCP machinery. Of 
course if you need millisecond latencies and custom binary protocols, you 
need to get your hands dirty :)

Cheers,
Rafał

W dniu czwartek, 9 lutego 2017 11:32:55 UTC+1 użytkownik Christian Kaps 
napisał:
>
> Hi Rafał,
>
> Thanks for your answer! Maybe I implement an Akka TCP server which is 
> located in the DMZ and a TCP client which is located in the private 
> network. Is it possible that the client polls message in near real-time 
> from the TCP server? Am I right, that this is possible with Pull-reading as 
> described in the Throttling Reads and Writes 
> <http://doc.akka.io/docs/akka/current/scala/io-tcp.html#Throttling_Reads_and_Writes>
>  
> section of the Akka TCP documentation?
>
> Best regards,
> Christian
>
> Am Donnerstag, 9. Februar 2017 10:23:09 UTC+1 schrieb Rafał Krzewski:
>>
>> Hi Christian,
>>
>> Akka is very general toolkit and you can implement any communication 
>> architecture that you need with it. It offers excellent HTTP support and 
>> also low-level TCP and UDP communication and you can implement any standard 
>> or custom protocol on top of that.
>> Akka Cluster however does not sound like something that would fit here:
>> - it requires bidirectional connectivity among all nodes that are parts 
>> of the cluster
>> - the network connecting the nodes is assumed to be trusted
>> - Akka Cluster is useful when you need to create an Actor system so large 
>> that it does not fit on a single machine because of memory or processing 
>> power requirements (say, millions of entities interacting in real time)
>>
>> Cheers,
>> Rafał
>>
>> W dniu czwartek, 9 lutego 2017 09:48:22 UTC+1 użytkownik Christian Kaps 
>> napisał:
>>>
>>> Hi,
>>>
>>> for a project we need a special type of server architecture. Because of 
>>> a customer compliance we cannot access the customers database server from 
>>> the DMZ. The server on which the database runs can access servers inside 
>>> the DMZ. In a similar project my employee has used a proxy like 
>>> architecture with an additional database server. The outer side writes 
>>> requests into this proxy database and the inner side polls this database 
>>> for requests and writes results to it. The outer side polls then for the 
>>> results.
>>>
>>> Is such a kind of architecture possible with Akka? Maybe with a cluster 
>>> like architecture?
>>>
>>> Outside(Public)  | DMZ | Inside
>>> Frontend Server | Backend Server | Database Server
>>>
>>> Best regards,
>>> Christian
>>>
>>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Can I use Akka for such kind of architecture?

[Rafał Krzewski]

Hi Christian,

Akka is very general toolkit and you can implement any communication 
architecture that you need with it. It offers excellent HTTP support and 
also low-level TCP and UDP communication and you can implement any standard 
or custom protocol on top of that.
Akka Cluster however does not sound like something that would fit here:
- it requires bidirectional connectivity among all nodes that are parts of 
the cluster
- the network connecting the nodes is assumed to be trusted
- Akka Cluster is useful when you need to create an Actor system so large 
that it does not fit on a single machine because of memory or processing 
power requirements (say, millions of entities interacting in real time)

Cheers,
Rafał

W dniu czwartek, 9 lutego 2017 09:48:22 UTC+1 użytkownik Christian Kaps 
napisał:
>
> Hi,
>
> for a project we need a special type of server architecture. Because of a 
> customer compliance we cannot access the customers database server from the 
> DMZ. The server on which the database runs can access servers inside the 
> DMZ. In a similar project my employee has used a proxy like architecture 
> with an additional database server. The outer side writes requests into 
> this proxy database and the inner side polls this database for requests and 
> writes results to it. The outer side polls then for the results.
>
> Is such a kind of architecture possible with Akka? Maybe with a cluster 
> like architecture?
>
> Outside(Public)  | DMZ | Inside
> Frontend Server | Backend Server | Database Server
>
> Best regards,
> Christian
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 AKKA IN MY PLAY FRAMEWORK APPLICTION

[Rafał Krzewski]

Play framework has all the functionality for both serving and using RESTful 
resources without Akka. Using Akka together with Play is certainly possible 
and handling banking transactions with Actors might indeed be a good idea. 
Then again, there could be easier ways to accomplish what you need to do. 
It all depends on your specific use case. Akka provides tools for building 
responsive and resilient applications, but is very honest about the 
problems that a distributed application faces in the real world, like 
message loss and partial failure. This makes designing your application 
quite challenging, but if you get it right, it will pay off in the long run 
thanks to great performance and stability.

If you wish to learn more about Akka, here are two books I can recommend:
https://www.amazon.com/Akka-Concurrency-Derek-Wyatt/dp/0981531660
https://www.amazon.com/Reactive-Design-Patterns-Roland-Kuhn/dp/1617291803

Cheers,
Rafał

PS. Could you please refrain from typing in ALL CAPS? This is commonly 
understood as shouting and many people consider it very impolite.




W dniu środa, 8 lutego 2017 12:05:14 UTC+1 użytkownik Eng. Chrispinus 
Onyancha napisał:
>
> I may using an Akka application started from the controller in play 
> framework for a banking transaction. Is it a good Use case for me to use 
> Akka within play framework. Am actually doing this because i need some 
> requests that are RESTFUL.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: SMACK Stack - Benefit of Akka Cluster?

[Rafał Krzewski]

Hi Chris,

Akka Cluster is a means to an end. It enables interesting capabilities like 
cluster singletons, entity sharding, distributed data (CRDTs). They come at 
a cost of added operational complexity. Especially split-brain situations 
need to be managed carefully because of risk of data corruption. In many 
situations running a (dynamically scaled) "swarm" of standalone Akka 
instances that communicate with other parts of the system through queues 
and HTTP interfaces is perfectly fine.

Cheers,
Rafał

W dniu środa, 1 lutego 2017 15:35:19 UTC+1 użytkownik Chris Ridmann napisał:
>
> Hey everyone,
>
> I'm evaluating whether to use the SMACK stack as part of our data 
> pipeline, as demonstrated in this reference app: 
> https://github.com/killrweather/killrweather
>
> I don't want to introduce unnecessary complexity in our stack unless it 
> gives enough bang for the buck.  From that reference app, I'm trying to 
> convince myself of the value that an Akka Cluster brings to that design.  I 
> can see Akka-Streams being valuable as an ingestion layer to Kafka. 
>  However, what is the benefit of wrapping the Spark Streaming Kafka within 
> an actor?  There doesn't really seem to be much internal state within those 
> actors (except I guess a wrapper around the spark streaming context), and 
> thus couldn't Akka just be removed in favor of a simpler non-clustered 
> design?  Or is the streaming context not thread safe and thus an actor 
> provides safeguards around that?
>
> Some of our current use cases are streaming analytics, as well as batch 
> analytics on months of historical data (similar to what the aggregation 
> code in that reference app is doing).
>
> Any insight is appreciated!  
>

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

[akka-user] Re: About logging in Akka application

[Rafał Krzewski]

Hi Yinhua,

First of all, you could model all elements of your system as Actors and the 
Main class would just start an ActorSystem, instantiate your top level 
Actor and then wait for it's termination.
If this is not feasible, non-Actor parts of the application do have a 
reference to the ActorSystem you use to run your Actors, because your 
create it / terminate it, right? Thus, you can create a LoggingAdapter as 
shown above.
If you are using akka-slf4j module, your can also just use SLF4J API 
directly, and all messages should go to the same backend.

Cheers,
Rafał

W dniu środa, 1 lutego 2017 15:55:21 UTC+1 użytkownik Dai Yinhua napisał:
>
> Hi Team,
>
> I am a little confuse about using the SLF4J for logging in akka 
> application.
> I understand AKKA will use event stream so the logging is asynchronise, 
> but this seems the logging is only available inside an actor class by using 
> transient LoggingAdapter logger = Logging.getLogger(getContext().system(), 
> this);
>
> But how can I do the similar logging outside actor class? Is there a way 
> that all parts of the application can use a unified akka logging system?
> Thank you.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Delaying akka.remote.netty.tcp.{hostname, port} resolution?

[Rafał Krzewski]

Hi Dragos,

I'd probably go with #2, because I think it's more cohesive: only one HTTP 
server implementation and health check supporting code is written only once.

Cheers,
Rafał

W dniu wtorek, 31 stycznia 2017 16:17:56 UTC+1 użytkownik Dragos Manolescu 
napisał:
>
> Greetings --
>
> I'm moving here a thread started on twitter. Here's my scenario: I am 
> spinning up a cluster on a compute fabric that's managed by an external 
> component. One consequence of this configuration is that the nodes' IP 
> addresses and their ports aren't known a priori: they are dynamically 
> allocated by the external component. I have code that performs the 
> resolution and thus could configure the cluster nodes appropriately. 
> Therein lies the rub:
>
> A. The compute fabric performs periodic health checks via HTTP (which I 
> implemented on top of akka-http). The external component will resolve the 
> allocated IP and port only *after* the first health check succeeds.
> B. The resolution code queries the external component to extract the IP 
> and port, and then uses those values to inject 
> the akka.remote.netty.tcp.{hostname, port} into the actor system's config.
>
> Both steps require an actor system, and because the values of 
> akka.remote.netty.tcp.{hostname, port} are not available prior to the http 
> listener being up and ready I can't think of a clean way to accomplish this 
> workflow. I see a few of workarounds; for example:
>
> 1. Factor the health check out of Akka into a different framework that 
> doesn't need an actor system (
> https://bitbucket.org/vetler/minihttpserver/overview ???) and spin up the 
> actor system after the first health check succeeds
> 2. Use 2 actor systems: start one w/o remoting configured and answer the 
> health checks until the IP and port are allocated, then shut it down and 
> start a 2nd one configured for remoting with the acquired IP + port info as 
> well as ready to continue answering the health checks.
>
> I don't know how common this scenario is. I'd be interested in your 
> thoughts about tackling it.
>
> Thanks,
>
> -Dragos
>

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

Re: [akka-user] How to stop unstoppable actor?

[Rafał Krzewski]

Hi Sergey,

It's hard to guess with the information you provided, so here are a few 
questions:

are you sure the killSwitch is placed in the correct place in the flow? 
are flow stages executing in a timely fashion, or do they occupy CPU for 
long periods of time?
how and when are you triggering the killSwitch?
is "heavy actor" and "parrent actor" the same, or different things?

cheers,
Rafał

W dniu środa, 25 stycznia 2017 00:00:22 UTC+1 użytkownik Sergey Sopin 
napisał:
>
> Hi Konrad,
>
> Thanks for a tip! But it seems that postStop function executes only after 
> flow is finished. How to deal with it? 
> Thanks!
>
> Regards, 
> Sergey
>
> вторник, 24 января 2017 г., 22:31:41 UTC+2 пользователь Konrad Malawski 
> написал:
>>
>> Add an Akka Streams KillSwitch to your stream and trigger it from the 
>> postStop of the actor.
>> Read about those concepts in the docs.
>>
>> -- 
>> Konrad Malawski
>>
>> On 24 January 2017 at 20:02:40, Sergey Sopin (sopi...@gmail.com) wrote:
>>
>>> Hi, 
>>>
>>> I am trying to solve problem with the actor which works too long. In my 
>>> case "heavy" actor runs akka-stream which calculates some values, sometimes 
>>> this calculation takes too much time and I want to stop it. I supposed that 
>>> it will be stopped automatically in case parent actor throw 
>>> AskTimeoutException, but I was wrong. Could you please tell me how to stop 
>>> this calculation in the most elegant way? 
>>>
>>> Thank you in advance!
>>>
>>> Regards,
>>> Sergey
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

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

Re: [akka-user] transactors and STM are gone. What conception to use instead?

[Rafał Krzewski]

I think you need to look into saga pattern which is actor model analogue of 
(distributed) transactions. It has the advantage that the parties involved 
in the transaction do not need to be present on the same VM (cluster node 
etc.) which is a prerequisite for STM / Agents.

Cheers,
Rafał

W dniu piątek, 27 stycznia 2017 18:58:37 UTC+1 użytkownik scala solist 
napisał:
>
> Thanks for the reply! I'm currently implemented some plain and simple 
> observable variable model atop of normal actors. Actor could control 
> immutable state, it accepts update messages that contains write lenses and 
> applies them. It manages subscriptions to the changes where subscriber 
> provide read lens and if it had changed - new value is sent. Immutable data 
> structures as well as rough subscriptions are not very effective, but I has 
> no need in computational efficiency.
>
> The problem is what should I do, when I have two actors (or agents as you 
> have suggested) and want them to do coordinated updates to both. There was 
> transaction model in the older releases, and now I need to replace it. Is 
> there any existing library in the ecosystem, or should I write it myself?
>
> On Friday, January 13, 2017 at 7:23:01 PM UTC+3, Konrad Malawski wrote:
>>
>> You can just use the Agents as was explained in my previous email. 
>> We're moving them out, shouldn't really stop you from using it.
>>
>> If you want to officially maintain them let us know.
>>
>> -- 
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 13 January 2017 at 16:46:30, Konrad Malawski (konrad@lightbend.com) 
>> wrote:
>>
>> Correction, Agents are not gone. They will be deprecated in 2.5, they are 
>> present in 2.4.
>>
>> Just Actors ;-)
>>
>> More is documented in the upcoming migration docs:
>>
>> https://github.com/akka/akka/blob/master/akka-docs/rst/project/migration-guide-2.4.x-2.5.x.rst#agents-are-now-deprecated
>>
>>
>> Agents are now deprecated 
>>
>> Akka Agents are a very simple way of containing mutable state and 
>> allowing to access it safely from multiple threads. The abstraction is 
>> leaky though, as Agents do not work over the network (unlike Akka Actors).
>>
>> As users were often confused by "when to use an Actor vs. when to use an 
>> Agent?" a decision was made to deprecate the Agents, as they rarely are 
>> really enough and do not fit the Akka spirit of thinking about 
>> distribution. We also anticipate to replace the uses of Agents by the 
>> upcoming Akka Typed, so in preparation thereof the Agents have been 
>> deprecated in 2.5.
>>
>> If you use Agents and would like to take over the maintanance thereof, 
>> please contact the team on gitter or github.
>>
>> -- 
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 13 January 2017 at 16:42:37, scala solist (scala...@gmail.com) wrote:
>>
>> Sometimes you need to do coordinated work between actors and modify 
>> shared state. The state in broad sense is separated by actors, there is no 
>> need to share them all. But sometimes there is a need to share small chunk 
>> of state and work with it with several actors. How it should be done in the 
>> recent akka?
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to 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: Make Source from remote actor

[Rafał Krzewski]

Hi,

Ad 1. you could create your own Actor that would take Source.actorRef in 
through it's Props. You can give this actor a name as necessary and it 
would forward the messages from remote system to be published locally by 
the Source.
Ad 2. I don't see why wouldn't it be visible. ActorRef are 
network-transparent by design.
Ad 3. As with 1, you could create a helper actor that would facilitate 
remote communication and death watch, and pass it's ActorRef to 
Sink.actorRefWithAck constructor

Cheers,
Rafał

W dniu wtorek, 24 stycznia 2017 01:23:44 UTC+1 użytkownik Maksym Besida 
napisał:
>
> 1. There is an Receiver actor that listens for messages from remote actor 
> systems. I need to make a Source from that actor. Available api to make a 
> Source from actor is Source.actorRef but it doesn't allow to set actor 
> name for created actor, instead it generate the name. Without concrete 
> actor name I'm not able to send messages to that actor from remote systems.
> 2. From the sender side I designed Sink GraphStage which is responsible 
> for sending incoming message to that remote actor, it also supports 
> reliable delivery stuff(like resending, reacting to Ack messages) and 
> controling flow for the connected Source. Will the actor created via 
> getStageActor 
> be visible for remote actor via sender() reference if I'll set it to 
> sender when telling messges to remote actor via it's actorRef on sender's 
> side?
> 3. From the above mentioned GraphStageSink I need to resolve 
> remoteActorRef via it's ActorSelection(guess it should be done somehow 
> using getAsyncCallback and resolveMethod of ActorSeclection) and also need 
> to monitor resolved actorRef: if remote actor is terminated I need to 
> resolve another actorRef, guess watching could be done with 
> graphStageActor, but not sure?
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Define a SupervisorStrategyConfigurator

[Rafał Krzewski]

foo.Foo.ResumeSupervisorStrategy is an inner class, so I would expect a 
mangled name, like foo.Foo$ResumeSupervisorStrategy but it would be the 
best if you checked the actual classes folder to make sure.

cheers,
Rafał

W dniu wtorek, 17 stycznia 2017 16:35:07 UTC+1 użytkownik Kilic Ali-Firat 
napisał:
>
> Hi guys,
>
> After reading more the documentation about the fault tolerance in Akka, 
> I'm trying to a define a new guardian supervisor strategy like below :
>
> package foo
>
>
> import akka.actor.{OneForOneStrategy, SupervisorStrategy, 
> SupervisorStrategyConfigurator}
> import akka.actor.SupervisorStrategy.{Decider, Resume}
>
>
> /**
>   * Created by alifirat on 17/01/17.
>   */
> object Foo {
>
>
> final val resumeDecider: Decider = {
>   case _: Exception => Resume
> }
>
>
> final val resumeStrategy: SupervisorStrategy =  OneForOneStrategy()(
> resumeDecider)
>
>
> final class ResumeSupervisorStrategy extends 
> SupervisorStrategyConfigurator {
>   override def create() = resumeStrategy
> }
> }
>
> And in one my test, I try to set this new supervisor strategy like this :
>
> class TEST_DEVICES_ROUTER_RECEIVE_DEVICES_DATA_AND_EXCEPTIONS
>   extends TestKit(ActorSystem("TEST_DEVICES_ROUTER_RECEIVE_DEVICES_DATA", 
> ConfigFactory.parseString("""
>   akka.actor.guardian-supervisor-strategy = "foo.Foo.
> ResumeSupervisorStrategy"
>   """)))
> with FlatSpecLike
> with Matchers
> with BeforeAndAfterAll
> with MockitoSugar
> with LazyLogging {
>
>
> But when I run the test, I got the following exception :
>
> info] TEST_DEVICES_ROUTER_RECEIVE_DEVICES_DATA_AND_EXCEPTIONS *** ABORTED 
> ***
> [info]   java.lang.ClassNotFoundException: foo.Foo.
> ResumeSupervisorStrategy
> [info]   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> [info]   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> [info]   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> [info]   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> [info]   at java.lang.Class.forName0(Native Method)
> [info]   at java.lang.Class.forName(Class.java:348)
> [info]   at akka.actor.ReflectiveDynamicAccess$$anonfun$getClassFor$1.
> apply(ReflectiveDynamicAccess.scala:21)
> [info]   at akka.actor.ReflectiveDynamicAccess$$anonfun$getClassFor$1.
> apply(ReflectiveDynamicAccess.scala:20)
> [info]   at scala.util.Try$.apply(Try.scala:192)
> [info]   at akka.actor.ReflectiveDynamicAccess.getClassFor(
> ReflectiveDynamicAccess.scala:20)
> [info]   ...
>
>
> The path of the class ResumeSupervisorStrategy seems to be good but it 
> seems that I didn't an another thing which I cannot fix. Any help will be 
> appreciate !
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Simple flatfile + JSON persistence plugin?

[Rafał Krzewski]

Hi Alan,

I remember someone suggesting using a RDBMS as the store for similar use 
case.
For example you could 
take https://github.com/okumin/akka-persistence-sql-async plugin to write 
the messages to PostgreSQL, but declare the message and snapshot columns in 
the tables as JSONB rather than BYTEA. This may involve tweaking the 
plugin, but even so should be pretty straightforward.
This way you could use postgres JSON capabilities to write SQL queries on 
your data https://www.postgresql.org/docs/9.5/static/functions-json.html
I imagine it's easier than writing a custom tool for working with the flat 
files. Of course all this is moot if said tool already exist, and you are 
now trying to tweak Akka to produce event log in suitable format :)

Cheers,
Rafał

W dniu czwartek, 12 stycznia 2017 18:31:16 UTC+1 użytkownik Alan Burlison 
napisał:
>
> I have some fairly non-standard requirements for a persistence plugin 
> for a long-running lo-event-rate simulation - I can assume a shared 
> filesystem, the event rates will be low (10/sec max) and I'd like to use 
> the persistence files with external tools to analyse the event stream 
> from outside of the emulation. I'm considering using JSON in flatfiles 
> as the format, by writing my own persistence plugins. I haven't been 
> able to find such a plugin, does anyone know of one, and if not are 
> there any caveats I should particularly be aware of, other than the 
> usual atomicity/asynchronous ones? 
>
> Thanks, 
>
> -- 
> Alan Burlison 
> -- 
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: [Akka-streams] Cannot push port twice

[Rafał Krzewski]

Hi,

here's more robust implementation of stream splitter, based on Partition 
stage: https://gist.github.com/rkrzewski/a0fc5d0b47d9a3e0b2c81435adef3fe7

cheers,
Rafał

W dniu środa, 11 stycznia 2017 20:26:24 UTC+1 użytkownik Sergey Sopin 
napisał:
>
> Hi again,
>
> Rafał, could you please give me an example of how to implement waiting?
>
> Thanks!
>
> - Sergey
>
> среда, 11 января 2017 г., 18:56:00 UTC+2 пользователь Rafał Krzewski 
> написал:
>>
>> The process should look like following:
>>
>> 1. Wait for both outlets to pull
>> 2. Pull from inlet
>> 2. Wait for the inlet to push an element, make the decision and push it 
>> to the appropriate outlet
>> 3. Goto 1
>>
>> This way you only ever pull inlet once, and once the element is available 
>> you can always push it out, since both outlets are available.
>>
>> Cheers,
>> Rafał
>>
>> W dniu wtorek, 10 stycznia 2017 19:07:48 UTC+1 użytkownik Sergey Sopin 
>> napisał:
>>>
>>> So, does it make sense? It seems it would be better to allow inlet be 
>>> pullet once per outlet, not once at all. 
>>> May be there is some existing solution for the problem above? 
>>>
>>>  - Sergey
>>>
>>> понедельник, 9 января 2017 г., 17:03:43 UTC+2 пользователь Sergey Sopin 
>>> написал:
>>>>
>>>> Hi Endre,
>>>>
>>>> I am not sure if I need it. But it seems, that sometimes my inlet is 
>>>> being pulled by outlet_0 when, according to conditions, message should be 
>>>> pushed to outlet_1. In this case my flow get stuck, becase it waits until 
>>>> outlet_1 will pull it and it doesn't happen (because port is already 
>>>> pulled 
>>>> by outlet_0).
>>>>
>>>> My flow looks like following: 
>>>>
>>>>
>>>>
>>>> <https://lh3.googleusercontent.com/-91i8qjm-MXM/WHOla3zvGeI/BQA/t1sEPAi_q6oeMdPWsz4DIlsZdrB8s06QACLcB/s1600/Flow.png>
>>>>
>>>>
>>>> Custom logic of the element (FanOutShape2) can be found in the initial 
>>>> message. Let me please know if you see something wrong there.
>>>>
>>>> Thanks!
>>>>
>>>> Regards,
>>>> Sergey
>>>>
>>>> понедельник, 9 января 2017 г., 16:10:14 UTC+2 пользователь drewhk 
>>>> написал:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 9, 2017 at 3:03 PM, Sergey Sopin <sopi...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> In my case I have 1 inlet and 2 outlets. It seems that inlet port can 
>>>>>> be pulled only once.
>>>>>>
>>>>>
>>>>> Yes, this is clearly documented here: 
>>>>> http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#Port_states__InHandler_and_OutHandler
>>>>>
>>>>> Please look at the state charts of the ports.
>>>>>  
>>>>>
>>>>>> So when two outlets try to pull the same inlet one by one, like in 
>>>>>> example above, second attempt will fail, because hasBeenPulled(inlet) 
>>>>>> function will return true. Could you please help me to figure out how to 
>>>>>> deal with it?
>>>>>>
>>>>>
>>>>> Why do you want to pull again if you have already pulled?
>>>>>
>>>>> -Endre
>>>>>  
>>>>>
>>>>>> Thank you in advance!
>>>>>>
>>>>>> Cheers,
>>>>>> Sergey
>>>>>>
>>>>>>
>>>>>> понедельник, 9 января 2017 г., 14:55:22 UTC+2 пользователь Julian 
>>>>>> Howarth написал:
>>>>>>>
>>>>>>> As per 
>>>>>>> http://doc.akka.io/docs/akka/2.4.16/java/stream/stream-customize.html#Port_states__AbstractInHandler_and_AbstractOutHandler
>>>>>>>  
>>>>>>> you can only push to a port if downstream has pulled (ie signalled that 
>>>>>>> it 
>>>>>>> is ready for data). So, in addition to checking  isClosed(outx), 
>>>>>>> you also need to check isAvailable(outx).
>>>>>>>
>>>>>>>
>>>>>>> Alternatively, you can use emit(outx)which takes care of this 
&g

Re: [akka-user] Re: [Akka-streams] Cannot push port twice

[Rafał Krzewski]

Of course, you should wait explicitly. I only meant the order of events 
happening.

I coded up a minimal 
implementation 
https://gist.github.com/rkrzewski/f1d131405ddb8ce0d1a6fded55da8c23 
(it's in Scala, I hope you don't mind)

A more practical one would require handling back-pressure on each outlet 
separately, so it would look more like the implementation of Partition 
stage: 
https://github.com/akka/akka/blob/master/akka-stream/src/main/scala/akka/stream/scaladsl/Graph.scala#L501
 

Hope that helps,
Rafał

W dniu środa, 11 stycznia 2017 20:26:24 UTC+1 użytkownik Sergey Sopin 
napisał:
>
> Hi again,
>
> Rafał, could you please give me an example of how to implement waiting?
>
> Thanks!
>
> - Sergey
>
> среда, 11 января 2017 г., 18:56:00 UTC+2 пользователь Rafał Krzewski 
> написал:
>>
>> The process should look like following:
>>
>> 1. Wait for both outlets to pull
>> 2. Pull from inlet
>> 2. Wait for the inlet to push an element, make the decision and push it 
>> to the appropriate outlet
>> 3. Goto 1
>>
>> This way you only ever pull inlet once, and once the element is available 
>> you can always push it out, since both outlets are available.
>>
>> Cheers,
>> Rafał
>>
>> W dniu wtorek, 10 stycznia 2017 19:07:48 UTC+1 użytkownik Sergey Sopin 
>> napisał:
>>>
>>> So, does it make sense? It seems it would be better to allow inlet be 
>>> pullet once per outlet, not once at all. 
>>> May be there is some existing solution for the problem above? 
>>>
>>>  - Sergey
>>>
>>> понедельник, 9 января 2017 г., 17:03:43 UTC+2 пользователь Sergey Sopin 
>>> написал:
>>>>
>>>> Hi Endre,
>>>>
>>>> I am not sure if I need it. But it seems, that sometimes my inlet is 
>>>> being pulled by outlet_0 when, according to conditions, message should be 
>>>> pushed to outlet_1. In this case my flow get stuck, becase it waits until 
>>>> outlet_1 will pull it and it doesn't happen (because port is already 
>>>> pulled 
>>>> by outlet_0).
>>>>
>>>> My flow looks like following: 
>>>>
>>>>
>>>>
>>>> <https://lh3.googleusercontent.com/-91i8qjm-MXM/WHOla3zvGeI/BQA/t1sEPAi_q6oeMdPWsz4DIlsZdrB8s06QACLcB/s1600/Flow.png>
>>>>
>>>>
>>>> Custom logic of the element (FanOutShape2) can be found in the initial 
>>>> message. Let me please know if you see something wrong there.
>>>>
>>>> Thanks!
>>>>
>>>> Regards,
>>>> Sergey
>>>>
>>>> понедельник, 9 января 2017 г., 16:10:14 UTC+2 пользователь drewhk 
>>>> написал:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 9, 2017 at 3:03 PM, Sergey Sopin <sopi...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> In my case I have 1 inlet and 2 outlets. It seems that inlet port can 
>>>>>> be pulled only once.
>>>>>>
>>>>>
>>>>> Yes, this is clearly documented here: 
>>>>> http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#Port_states__InHandler_and_OutHandler
>>>>>
>>>>> Please look at the state charts of the ports.
>>>>>  
>>>>>
>>>>>> So when two outlets try to pull the same inlet one by one, like in 
>>>>>> example above, second attempt will fail, because hasBeenPulled(inlet) 
>>>>>> function will return true. Could you please help me to figure out how to 
>>>>>> deal with it?
>>>>>>
>>>>>
>>>>> Why do you want to pull again if you have already pulled?
>>>>>
>>>>> -Endre
>>>>>  
>>>>>
>>>>>> Thank you in advance!
>>>>>>
>>>>>> Cheers,
>>>>>> Sergey
>>>>>>
>>>>>>
>>>>>> понедельник, 9 января 2017 г., 14:55:22 UTC+2 пользователь Julian 
>>>>>> Howarth написал:
>>>>>>>
>>>>>>> As per 
>>>>>>> http://doc.akka.io/docs/akka/2.4.16/java/stream/stream-customize.html#Port_states__AbstractInHandler_and_AbstractOutHandler
>>>>>>>  
>>>>>>> you can only push to a port if downstream has pulled (

Re: [akka-user] Re: [Akka-streams] Cannot push port twice

[Rafał Krzewski]

The process should look like following:

1. Wait for both outlets to pull
2. Pull from inlet
2. Wait for the inlet to push an element, make the decision and push it to 
the appropriate outlet
3. Goto 1

This way you only ever pull inlet once, and once the element is available 
you can always push it out, since both outlets are available.

Cheers,
Rafał

W dniu wtorek, 10 stycznia 2017 19:07:48 UTC+1 użytkownik Sergey Sopin 
napisał:
>
> So, does it make sense? It seems it would be better to allow inlet be 
> pullet once per outlet, not once at all. 
> May be there is some existing solution for the problem above? 
>
>  - Sergey
>
> понедельник, 9 января 2017 г., 17:03:43 UTC+2 пользователь Sergey Sopin 
> написал:
>>
>> Hi Endre,
>>
>> I am not sure if I need it. But it seems, that sometimes my inlet is 
>> being pulled by outlet_0 when, according to conditions, message should be 
>> pushed to outlet_1. In this case my flow get stuck, becase it waits until 
>> outlet_1 will pull it and it doesn't happen (because port is already pulled 
>> by outlet_0).
>>
>> My flow looks like following: 
>>
>>
>>
>> 
>>
>>
>> Custom logic of the element (FanOutShape2) can be found in the initial 
>> message. Let me please know if you see something wrong there.
>>
>> Thanks!
>>
>> Regards,
>> Sergey
>>
>> понедельник, 9 января 2017 г., 16:10:14 UTC+2 пользователь drewhk написал:
>>>
>>>
>>>
>>> On Mon, Jan 9, 2017 at 3:03 PM, Sergey Sopin  wrote:
>>>
 Hi again,

 In my case I have 1 inlet and 2 outlets. It seems that inlet port can 
 be pulled only once.

>>>
>>> Yes, this is clearly documented here: 
>>> http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#Port_states__InHandler_and_OutHandler
>>>
>>> Please look at the state charts of the ports.
>>>  
>>>
 So when two outlets try to pull the same inlet one by one, like in 
 example above, second attempt will fail, because hasBeenPulled(inlet) 
 function will return true. Could you please help me to figure out how to 
 deal with it?

>>>
>>> Why do you want to pull again if you have already pulled?
>>>
>>> -Endre
>>>  
>>>
 Thank you in advance!

 Cheers,
 Sergey


 понедельник, 9 января 2017 г., 14:55:22 UTC+2 пользователь Julian 
 Howarth написал:
>
> As per 
> http://doc.akka.io/docs/akka/2.4.16/java/stream/stream-customize.html#Port_states__AbstractInHandler_and_AbstractOutHandler
>  
> you can only push to a port if downstream has pulled (ie signalled that 
> it 
> is ready for data). So, in addition to checking  isClosed(outx), you 
> also need to check isAvailable(outx).
>
>
> Alternatively, you can use emit(outx)which takes care of this 
> automatically.
>
> Julian
>
>
> On Monday, January 9, 2017 at 12:46:43 PM UTC, Sergey Sopin wrote:
>>
>> Hi,
>>
>> I have created FanOutShape2 shape with cusom logic: 
>>
>> @Override
>> public GraphStageLogic createLogic(Attributes 
>> inheritedAttributes)  {
>> return new GraphStageLogic(shape) {
>> {
>> setHandler(in, new AbstractInHandler() {
>> @Override
>> public void onPush() throws Exception {
>> Object result = process(grab(in), 
>> materializer());
>>
>> if (result instanceof ProcessingResponse) {   
>> ProcessingResponse response = 
>> (ProcessingResponse) result;
>> if (!isClosed(out1)) {
>> push(out1, response); 
>>   //This is FAndLShape.java:46
>> }
>> } else if (result != null && result 
>> instanceof FinderData) {  
>> FinderData response = (FinderData) result;
>> if (!isClosed(out0)) {
>> push(out0, response);
>> }
>> }
>> }
>> });
>>
>> setHandler(out0, new AbstractOutHandler() {
>> @Override
>> public void onPull() throws Exception {
>> if ((!hasBeenPulled(in)) && (!isClosed(in))) {
>> pull(in);
>> }
>> }
>> });
>>
>> setHandler(out1, new AbstractOutHandler() {
>> @Override
>> public void onPull () throws Exception {
>>   

[akka-user] Re: Emulate Geo Dispersed Actors on Local Machine

[Rafał Krzewski]

You can do it by starting multiple JVMs on you local machine.
Akka provides a dedicated toolkit for creating this kind of 
tests: http://doc.akka.io/docs/akka/2.4/dev/multi-node-testing.html
The documentation is rather terse, but you can study the tests of 
akka-remoting and akka-cluster which are implemented this way.

Cheers,
Rafał

W dniu środa, 4 stycznia 2017 17:52:43 UTC+1 użytkownik Joseph Mansigian 
napisał:
>
> After I do an actorSelection on the remote path:
> akka.tcp://community@127.0.0.1:4000/user/speaker
> executing actor.Selection.pathString on the ActorSelection above shows the 
> local path: /user/speaker 
>
> When I send a message it ends up in dead letters as you would expect.
> This is problematical because I want to emulate remote processing of 
> many geographically separate actors on a local machine for development 
> purposes.
> Can I do this?
>
> This happens with my application code written in scala 2.11.8  using
> akka 2.4.9 and java 1.8.0_25 SE.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] Pause Reading/Request with FileIO

[Rafał Krzewski]

W dniu wtorek, 3 stycznia 2017 19:54:14 UTC+1 użytkownik Marcin Pękalski 
napisał:
>
>
> That is why I think foreach{thing => doStuff(thing)} is not a good option 
> for me. I need to be able to use backpressure if computations take too long 
> so I do not run out of RAM. Also the matrix with weights will probably be 
> big (tens of GB), so it would be good if I did not have to store too many 
> rows from file in the memory.
>

That's a valid concern, but Akka streams take care of that. foreach{thing 
=> doStuff(thing)} pulls next "thing" from upstream only after "doStuff" 
completes processing previous "thing", so back pressure is maintained. Of 
course this means that the "things" are processed sequentially. You can 
process them in parallel if you wish, by changing doStuff(thing) to return 
Future[Unit] instead of Unit and then doing for example 
mapAsyncUnordered(4)(doStuff).to(Sink.ignore) Akka Streams would ensure 
that at most 4 invocations of "doStuff" are running at any given time. 

cheers,
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] Re: Best hardware for Akka development

[Rafał Krzewski]

Hi Tom,

In general JVM applications are mostly portable across Windows/MacOS/Linux 
but occasional road bumps do happen, you have experienced.

I believe most of Akka developers are using Apple hardware, but Linux is 
also a fine choice. It runs much better on desktops and laptops than it 
used to, and it also gives you best fidelity WRT target environments, 
because most of cloud environments are running Linux. Of course you can run 
Windows servers in the cloud too, but then there are OS license fees to 
consider. Another alternative is using Docker on you Windows / MacOS laptop 
to test your application in Linux environment before deploying it to the 
cloud.

cheers,
Rafał

W dniu poniedziałek, 2 stycznia 2017 16:07:22 UTC+1 użytkownik Tom Bodine 
napisał:
>
> I have just spent two very frustrating days trying to get SBT and Akka to 
> run an application developed by  a contractor who developed it using a 
> macintosh computer but I have a windows 10 machine.
>
> So I am considering buying up. Which platform will allow me to develop and 
> extend this application written with SBT and Akka at home so I can deploy 
> the resulting application somewhere visible and useful to the world?
>
> Thanks
>
>
>

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

[akka-user] Re: [DesignProposal] AKKA cluster in Docker Swarm Environment

[Rafał Krzewski]

Excellent!

Happy hAkking, and all the best in the New Year!
Rafał

W dniu piątek, 30 grudnia 2016 10:13:10 UTC+1 użytkownik Evgeny Shepelyuk 
napisał:
>
> Hello
> Successfully implemented cluster joining using ConstructR, thanks !
>
> четвер, 29 грудня 2016 р. 15:21:47 UTC+2 користувач Rafał Krzewski написав:
>>
>> Hi, 
>> You are welcome! 
>> You can use https://github.com/hseeberger/constructr together with 
>> https://github.com/typesafehub/constructr-zookeeper to initialize Akka 
>> cluster using Zookeeper. 
>>
>> Cheers, 
>> 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] Re: [DesignProposal] AKKA cluster in Docker Swarm Environment

[Rafał Krzewski]

Hi,
You are welcome! 
You can use https://github.com/hseeberger/constructr together with 
https://github.com/typesafehub/constructr-zookeeper to initialize Akka cluster 
using Zookeeper.

Cheers,
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] how to enable secure tcp socket connection on server side in Akka

[Rafał Krzewski]

Gaurav, as Roland wrote above, you cannot just "enable it" in current 
version of Akka. You need to combine a few components provided by 
akka-streams module to create an SSL-enabled client or server. 
Also, you will need to learn the concepts behind Akka Streams because they 
are very different than "plain" Akka actors. They are excellent tool and I 
think it's a good investment to learn and understand them.

Regarding the lack of example of akka.stream.scaladsl.TLS usage in 
documentation, noticed by Roland, I've filed an 
issue: https://github.com/akka/akka/issues/22071 Hopefully it was just 
misplaced.

Cheers,
Rafał

W dniu środa, 28 grudnia 2016 12:33:53 UTC+1 użytkownik Gaurav Kumar 
Jayswal napisał:
>
> Hi Roland, I didn't get a way to enable secure TCP socket connection. Can 
> you plz share me some snap of code that how to enable tls in tcp message 
>  bind?
>
> Regards
> Gaurav
>  
> On Friday, 30 September 2016 11:33:23 UTC+5:30, rkuhn wrote:
>>
>> The library you’re looking for is Akka Streams, not bare Akka IO. Coming 
>> from Mina you might want to read 
>> http://doc.akka.io/docs/akka/2.4/java/stream/stream-composition.html about 
>> how protocol pipelines are expressed.
>>
>> Unfortunately I cannot seem to find the documentation section that 
>> contained the TLS example (nor the BidiFlow). Endre, has this been removed? 
>> We should definitely have docs for this use-case, HTTPS is not the only 
>> thing that uses TLS ;-)
>>
>> Regards,
>>
>> Roland
>>
>> 30 sep. 2016 kl. 07:14 skrev Gaurav Kumar Jayswal :
>>
>> Thanks for you reply. I'm new in akka. I didn't get how to enable secure 
>> tcp chat server, while binding. Can you plz give some example code...
>>
>> Tcp.get(getContext().system()).manager().tell(TcpMessage.bind(getSelf(), 
>> inetSocketAddress, 100), getSelf());
>>
>>
>> On Thursday, 29 September 2016 17:01:47 UTC+5:30, Konrad Malawski wrote:
>>>
>>> Please refer to the documentation: 
>>>
>>> http://doc.akka.io/docs/akka/2.4.10/java/http/server-side-https-support.html#ssl-config-java
>>>
>>> It has a nice search box which you can use to search for "SSL".
>>>
>>> -- 
>>> Konrad `ktoso` Malawski
>>> Akka  @ Lightbend 
>>>
>>> On 29 September 2016 at 13:28:51, Gaurav Kumar Jayswal (
>>> me.ga...@gmail.com) wrote:
>>>
>>> In Mina Simply I have added by this. 
>>>
>>>
>>> private static void addSSLSupport(DefaultIoFilterChainBuilder chain) throws 
>>> Exception {
>>>SslFilter sslFilter = new SslFilter(new 
>>> SSLContextGenerator().getSslContext());
>>>chain.addFirst("sslFilter", sslFilter);
>>> }
>>>
>>>
>>> Can anyone let me know how to add sslcontext in Akka tcp 
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to 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+...@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: [DesignProposal] AKKA cluster in Docker Swarm Environment

[Rafał Krzewski]

W dniu środa, 28 grudnia 2016 13:30:23 UTC+1 użytkownik Evgeny Shepelyuk 
napisał:
>
> Hello,
>
> In Docker Swarm when service is created, it's assigned to Virtual IP. I.e. 
> when I create several instances of *wallet-seed *they will get an single 
> IP (10.0.0.2, for example), while each of container will have own IP 
> (10.0.0.5, 10.0.0.6, 10.0.0.7 and so on)
> When *wallet-seed* address is resolved within Swarm cluster - it will 
> initially resolves to service VIP (10.0.0.2) and then to the IP of 
> particular container in round robin fashion.
>
> So if I put *wallet-seed * as a seed node address in my *wallet *service 
> config, then 1st instance could resolve it to 10.0.0.5, second instance can 
> resolve to 10.0.0.6 etc.
>
> As far as I understand this will lead to cluster partitioning, right ?
>

No, I meant something else. First of all, Akka cluster is implemented on 
top of Akka remoting. And for Akka remoting to work, each node needs to 
know it's self address, which is the IP the other nodes will use to connect 
to it. The node address becomes the part of remote ActorRefs. Any incoming 
message that contains different address than the node's self address is 
dropped. This is a good thing, because you could have actors with the same 
local paths on different node clusters and the results of delivering 
message to a wrong instance could potentially be disastrous. Because of 
this, even if you create *wallet-seed* service with virtual IP 10.0.0.2 you 
cannot use this IP as the address of the seed, because the containers 
backing the service will expect to receive messages addressed to 10.0.0.5, 
10.0.0.6 and so on and will discard messages addressed to 10.0.0.2.
You could use docker-swarm service in a different way: to advertise the 
proper IP address of the cluster seed, but you cannot use Akka remoting 
protocol for that, for reason given above. Suppose you implement it the 
following way: define a HTTP endpoint, say at port 5000 that will respond 
to GET /seeds with a text/plain message containing IP address of cluster 
seed. Each node upon startup will do the following:
- attempt a GET wallet-seed:5000/seed 
- if it succeeds, join the cluster at received IP
- if it fails, this node is the first one and it should:
  - bootstrap the cluster by joining itself
  - publish a HTTP service at port 5000 advertising it's own address
The definition of wallet-seed service should include a health check 
condition so that only containers publishing the HTTP at port 5000 would be 
act as it's backend
That would work, but has a glaring problem: there is a race condition 
between the seed nodes. More than one container can "elect itself" as the 
seed. Then the other nodes would access different seeds through 
*wallet-seed* in round-robin fashion and join their respective clusters.
Using a consistent store like consul or etcd provides a solution to the 
race condition but also solves a second problem: it can be used to 
advertise seed address without crafting a custom service.

Cheers,
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] Re: [DesignProposal] AKKA cluster in Docker Swarm Environment

[Rafał Krzewski]

If you can set the IPs of your seed node(s) upfront and put them into 
configuration of every node all is fine and well. Unfortunately this is not 
what happens in a dynamic environment, hence the need to elect the seed 
node before Akka cluster boots up.

Cheers,
Rafał

W dniu środa, 28 grudnia 2016 11:56:56 UTC+1 użytkownik Evgeny Shepelyuk 
napisał:
>
> Hello
>
> Do you mean that in AKKA cluster there's only one seed node ? 
> I thought AKKA cluster may have several seed node, so new instances can 
> connect to any of them.
> AKKA documentations show example with multiple seed nodes.
>
> середа, 28 грудня 2016 р. 12:48:33 UTC+2 користувач Rafał Krzewski написав:
>>
>> Evgeny,
>> The role of etcd / consul / zookeeper in the booting up an Akka cluster 
>> is to provide a distributed lock rather than service discovery. When you 
>> boot up a number of uniform nodes they need to decide among themselves 
>> which one will act as a seed of Akka cluster. The other nodes then join the 
>> seed. An external service that provides consistency guarantees prevents the 
>> cluster from brain-splitting at the very outset. I'm not familiar with 
>> docker-swarm feature set, but unless it provides a strongly consistent KV 
>> store or other means of distributed coordination, this is not going to fly.
>>
>> Cheers,
>> 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] RESTCONF streaming for events can be enabled on akka.http.

[Rafał Krzewski]

Great! Happy hAkking :)

W dniu środa, 28 grudnia 2016 02:46:07 UTC+1 użytkownik aarti napisał:
>
> Thanks Rafal and Konard. I have gone through  
> https://github.com/hseeberger/akka-sse 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fhseeberger%2Fakka-sse=D=1=AFQjCNHqxwsMT3Q4YpufUiivy77ZG-ZZig>,
>  
> it helped me a lot. Will revert with doubts in between. :)
>
>
> On Tuesday, 27 December 2016 16:45:27 UTC+5:30, Rafał Krzewski wrote:
>>
>> This is also the first time I've heard about RESTCONF :) I've taken a 
>> look at the specification draft [1] and it turns out, that the RESTCONF 
>> notifications [2] are provided as W3C Serrver-Sent Events [3].
>> Akka HTTP is end-to-end stream based, so it would be easy enough to use 
>> it to implement RESTCONF protocol client (or server) directly, but here's a 
>> handy module provided by Heiko Seeberger [4] that implements SSE event 
>> streams on top of Akka HTTP.
>>
>> cheers,
>> Rafał
>>
>> [1] https://tools.ietf.org/html/draft-ietf-netconf-restconf-18
>> [2] https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#section-6
>> [3] https://www.w3.org/TR/eventsource/
>> [4] https://github.com/hseeberger/akka-sse 
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fhseeberger%2Fakka-sse=D=1=AFQjCNHqxwsMT3Q4YpufUiivy77ZG-ZZig>
>>
>> W dniu wtorek, 27 grudnia 2016 07:18:39 UTC+1 użytkownik aarti napisał:
>>>
>>> I need to enable streaming capability on akka.http. which api of can be 
>>> used for that. is websocket can be used is there something else which can 
>>> support streaming.
>>>   
>>>
>>> On Monday, 26 December 2016 15:11:11 UTC+5:30, Konrad Malawski wrote:
>>>>
>>>> RESTCONF seems rather very technology specific... First time I see it 
>>>> mentioned to be honest.
>>>> What are you trying to achieve?
>>>>
>>>> -- 
>>>> Konrad Malawski
>>>>
>>>> On 26 December 2016 at 10:37:59, aarti (leoart...@gmail.com) wrote:
>>>>
>>>>> Hi,  
>>>>> Can anyone guide me how can we enable RESTCONF streaming for events on 
>>>>> akka.http. What are steps, jars etc. will be required for the same.
>>>>>
>>>>> --
>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>> >>>>>>>>>> Check the FAQ: 
>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>> >>>>>>>>>> Search the archives: 
>>>>> https://groups.google.com/group/akka-user
>>>>> ---
>>>>> You received this message because you are subscribed to 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: [DesignProposal] AKKA cluster in Docker Swarm Environment

[Rafał Krzewski]

Evgeny,
The role of etcd / consul / zookeeper in the booting up an Akka cluster is 
to provide a distributed lock rather than service discovery. When you boot 
up a number of uniform nodes they need to decide among themselves which one 
will act as a seed of Akka cluster. The other nodes then join the seed. An 
external service that provides consistency guarantees prevents the cluster 
from brain-splitting at the very outset. I'm not familiar with docker-swarm 
feature set, but unless it provides a strongly consistent KV store or other 
means of distributed coordination, this is not going to fly.

Cheers,
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] RESTCONF streaming for events can be enabled on akka.http.

[Rafał Krzewski]

This is also the first time I've heard about RESTCONF :) I've taken a look 
at the specification draft [1] and it turns out, that the RESTCONF 
notifications [2] are provided as W3C Serrver-Sent Events [3].
Akka HTTP is end-to-end stream based, so it would be easy enough to use it 
to implement RESTCONF protocol client (or server) directly, but here's a 
handy module provided by Heiko Seeberger [4] that implements SSE event 
streams on top of Akka HTTP.

cheers,
Rafał

[1] https://tools.ietf.org/html/draft-ietf-netconf-restconf-18
[2] https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#section-6
[3] https://www.w3.org/TR/eventsource/
[4] https://github.com/hseeberger/akka-sse

W dniu wtorek, 27 grudnia 2016 07:18:39 UTC+1 użytkownik aarti napisał:
>
> I need to enable streaming capability on akka.http. which api of can be 
> used for that. is websocket can be used is there something else which can 
> support streaming.
>   
>
> On Monday, 26 December 2016 15:11:11 UTC+5:30, Konrad Malawski wrote:
>>
>> RESTCONF seems rather very technology specific... First time I see it 
>> mentioned to be honest.
>> What are you trying to achieve?
>>
>> -- 
>> Konrad Malawski
>>
>> On 26 December 2016 at 10:37:59, aarti (leoart...@gmail.com) wrote:
>>
>>> Hi,  
>>> Can anyone guide me how can we enable RESTCONF streaming for events on 
>>> akka.http. What are steps, jars etc. will be required for the same.
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to 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: Usage of Akka cluster in Docker Swarm cluster

[Rafał Krzewski]

W dniu poniedziałek, 26 grudnia 2016 14:00:41 UTC+1 użytkownik Evgeny 
Shepelyuk napisał:
>
> 1. Possible network overhead because swarm nodes and akka nodes are auto 
> discovering each other using gossip.
>

I wouldn't worry about it too much, because it only happens when the 
cluster is starting up. or is being scaled up/down. 
 

> 2. How to find seed nodes for AKKA cluster nodes, i.e. is it possible to 
> not use third party services like consul for this and rely completely on 
> Docker Swarm ?
>

I would recommend running a consistent KV store like Consul or etcd and 
then using https://github.com/hseeberger/constructr on top of that to 
manage Akka cluster seed nodes. This makes it easy to migrate your 
application to Kubernetes or Mesos if you ever need to.
 

> 3. Is there any advice on cluster topology, i.e. is it better to join all 
> nodes into single cluster, or create a cluster per service and use cluster 
> client to access it ?
>

This depends on your actual use case. First and foremost you shouldn't run 
Akka cluster at all unless you need one or more features it enables like 
sharding, distributed data, singletons and so on. Many clustered 
applications can be built as ensembles of standalone Akka nodes 
communicating through HTTP endpoints. The latter approach fits very well 
into Docker Swarm / Kubernetes services model. Or you might want to use 
Akka cluster for one layer of your application and a "swarm" of independent 
nodes communicating through HTTP or a message queue for another. It all 
depends on what you want to build. 
 
cheers,
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] Re: TCP SSl Support in Akka 2.4.16 http://doc.akka.io/docs/akka/current/java/io-tcp.html

[Rafał Krzewski]

You should take a look at Akka Streams. You can combine 
akka.streams.javadsl.Tcp and akka.streams.javadsl.TLS to create custom 
SSL/TLS enabled TCP servers and clients.

Cheers,
Rafał

W dniu środa, 21 grudnia 2016 13:59:27 UTC+1 użytkownik Gaurav Kumar 
Jayswal napisał:
>
> I have found tcp ssl support in akka 2.2 but didn't found how to appy ssl 
> support in current stable version. Can anyone help to know how to apply ssl 
> support like this 
> https://github.com/akka/akka/blob/v2.2.0/akka-docs/rst/java/code/docs/io/japi/SslDocTest.java
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] Understanding race conditions when creating actors

[Rafał Krzewski]

W dniu czwartek, 15 grudnia 2016 08:02:29 UTC+1 użytkownik Dmb napisał:
>
>
> Do you mean that the state of the outer actor can be used from the inner 
> actor by mistake? It sounds a little nonsensical to me to use one actor 
> from another directly (not by sending a message).
>

You are right, but since Scala happily captures vars or val references to 
mutable objects when creating closures its' rather easy to do this by 
mistake. 

Cheers,
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] Re: How to deal with Futures in Sources/Flows

[Rafał Krzewski]

If you need to consume messages from a number of Sources that are created 
at run time you probably need to use a MergeHub
http://doc.akka.io/docs/akka/2.4/scala/stream/stream-dynamic.html#dynamic-fan-in-and-fan-out-with-mergehub-and-broadcasthub

cheers,
Rafał

W dniu czwartek, 8 grudnia 2016 21:21:08 UTC+1 użytkownik sub...@gmail.com 
napisał:
>
> Hi,
>
> I'm creating a Source via GraphStageLogic which makes calls to another 
> api, which happens to return a Source. However I'm unsure how to deal with 
> Source/Futures in a GraphStageLogic. It seems that I want my shape to look 
> like
>
> val shape: SourceShape[Seq[String]] = SourceShape(out)
>
>
> but I get back a Source[ByteString, NotUsed] which I can covert to 
> Future[Seq[String]] 
> via runWith(Sink.seq). So should I make my shape
>
> val shape: SourceShape[Future[Seq[String]]] = SourceShape(out)
>
>
> But then I need to materialize the Source inside the onPull(), which 
> doesn't seem right. Is there a better way to handle this situation?
>
> Thanks!
>

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

[akka-user] Re: Installing Akka in Textmate 2 on macOS Sierra

[Rafał Krzewski]

What do you mean "installing akka in Textmate 2"? Do you usually use 
Textmate 2 for writing Scala programs, but have some unexpected trouble 
with Akka?

As far as I know, here's what editors / IDEs people use for working with 
Scala:

http://scala-ide.org/
https://confluence.jetbrains.com/display/SCA/Scala+Plugin+for+IntelliJ+IDEA 
http://ensime.github.io/editors/

There's also ENSIME plugin for Textmate 2, but it's ancient 
(2012) https://github.com/mads-hartmann/ensime.tmbundle

cheers,
Rafał

W dniu piątek, 2 grudnia 2016 20:29:49 UTC+1 użytkownik Daniel Martin 
napisał:
>
> Hello,
>
> I do have big troubles installing akka in Textmate 2 on my macOS Sierra 
> MacBook.
> Can someone help me out and give me a step by step instruction?
> How am I doing this? :/ 
>
> Thanks 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.

[akka-user] Re: How can Akka HTTP be configured to accept more concurrent connections?

[Rafał Krzewski]

I think you are looking for akka.http.server.max-connections. See [1]

akka.http.host-connection-pool are client settings for per-host connection 
pooling.

Cheers,
Rafał

[1] 
http://doc.akka.io/docs/akka-http/current/scala/http/low-level-server-side-api.html#controlling-server-parallelism

W dniu wtorek, 29 listopada 2016 18:59:55 UTC+1 użytkownik Benjamin Geer 
napisał:
>
> I'm having trouble understanding how to configure Akka HTTP (version 
> 2.4.11) to accept more than about 130 concurrent connections. My minimal 
> test case is this example from the docs, in which I've tried to set 
> relevant configuration options:
>
>
> import akka.actor.ActorSystem
> import akka.http.scaladsl.Http
> import akka.http.scaladsl.model._
> import akka.http.scaladsl.server.Directives._
> import akka.stream.ActorMaterializer
> import com.typesafe.config.ConfigFactory
>
> import scala.io.StdIn
>
> object WebServer {
> def main(args: Array[String]) {
>
> val parallel = 1024
>
> implicit val system = ActorSystem("my-system", 
> ConfigFactory.parseString(
> s"""
>|akka {
>|http {
>|server {
>|backlog = $parallel
>|pipelining-limit = $parallel
>|}
>|
>|host-connection-pool {
>|max-connections = $parallel
>|max-open-requests = $parallel
>|max-connections = $parallel
>|}
>|}
>|}
>  """.stripMargin))
>
> implicit val materializer = ActorMaterializer()
> // needed for the future flatMap/onComplete in the end
> implicit val executionContext = system.dispatcher
>
> val route =
> path("hello") {
> get {
> complete(HttpEntity(ContentTypes.`text/html(UTF-8)`, 
> "Say hello to akka-http"))
> }
> }
>
> val bindingFuture = Http().bindAndHandle(route, "localhost", 8080)
>
> println(s"Server online at http://localhost:8080/\nPress RETURN to 
> stop...")
> StdIn.readLine() // let it run until user presses return
> bindingFuture
> .flatMap(_.unbind()) // trigger unbinding from the port
> .onComplete(_ => system.terminate()) // and shutdown when done
> }
> }
>
>
> I'm testing it with ab (on Mac OS X with a 4 GHz Intel Core i7):
>
>
> $ ab -n 2000 -c 150 http://localhost:8080/hello
> This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking localhost (be patient)
> apr_socket_recv: Connection reset by peer (54)
>
>
> When the value of -c is greater than about 130, I always get Connection 
> reset by peer immediately, regardless of the configuration options above.
>
>
> What am I missing?
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: ClusterSingleton router location and routing logic

[Rafał Krzewski]

Hi Shyam,

I think you need to use some kind of consistent hashing [1] scheme. Akka 
provides consistent hashing router [1]  also cluster sharding [2]  but the 
former AFAICT isn't aware of remoting / clustering (and thus rebalancing 
when cluster membership changes) and the latter is more heavy weight and 
geared towards Entity / Aggregate Root actors. 

Cheers,
Rafał

[1] https://en.wikipedia.org/wiki/Consistent_hashing
[2] 
http://doc.akka.io/docs/akka/snapshot/scala/routing.html#ConsistentHashingPool_and_ConsistentHashingGroup
[3] http://doc.akka.io/docs/akka/snapshot/scala/cluster-sharding.html

W dniu wtorek, 29 listopada 2016 08:32:27 UTC+1 użytkownik oShyam napisał:
>
> Hi,
>
> We are having several kinds of tasks and we wanted to control the number 
> of actors spawned across the cluster to do a particular task. So we went 
> with having many cluster singleton routers (1000s) in our project. All the 
> routers are sitting on the oldest member of the cluster as mentioned in the 
> docs, and all the messages to the actors under these routers are going 
> through the oldest node and the oldest node became the bottleneck.
>
> 1. Is there anyway we can distribute the cluster singleton instances 
> across the cluster so that the load would be shared.
>
> 2. Is it possible to extract the routing info from the oldest node, so 
> that the requests would be forwarded directly to the actors without 
> involving the router instance.
>
> currently the messages are forwarded in this way: 
>
> rotuerProxy ---> routerInstance -> actor
>
> wanted: 
>
> routerProxy (has the routing info) --> actor
>
>
> Cheers,
> Shyam
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Distributed data

[Rafał Krzewski]

Hi Steve,
have you looked 
at http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html? It seems 
well suited to your use case if I understood it correctly.

Cheers,
Rafał

W dniu poniedziałek, 28 listopada 2016 18:24:23 UTC+1 użytkownik Steve 
Winfield napisał:
>
> Hey,
>
> I'm currently programming a room service application which gets a room 
> actor reference from a map (given an id) or creates a new room actor if 
> there is no reference existent. Right now, it works fine because there is 
> only one service. Nevertheless, I want to create a cluster of room services 
> and this is where it begins to get tricky for me.
>
> *I want to ensure that there is only one instance of a room among the 
> services.*
>
> My first attempt:
>
> (Starting up)
> 1. When started, it waits for the CurrentClusterState and sends a 
> "register" message to all given nodes.
> 2. It creates a counter for expected "register" responses to make sure 
> that it doesn't look for existent rooms across the services until it knows 
> about all.
> 3. After getting all responses, it is ready for "get this room" input.
>
> (Fetching rooms)
> 4. When it receives a "get room with id 1" message, it looks for an entry 
> in the local map.
> 5. If it founds one, it's done.
> 6. If it doesn't find it, it sends a "get room with id 1 or avoid creation 
> of it" message across the cluster (the "avoid creation of it" message is 
> sent in order to avoid that another service creates the same room after it 
> was made sure that the room doesn't exist globally).
> 7. Now, it waits for all responses. If there is a room, it sends a "make 
> the room creatable again" message to all services and it's done.
> 8. If it doesn't find it again, it creates the room, adds it to the local 
> map and sends a "make the room creatable again" message to all services.
> 9. (Sends result to requestor)
>
> In my opinion, this solution is way too complicated and it depends too 
> much on the availability of all nodes.
>
> *Is Redis (especially the command https://redis.io/commands/setnx 
> ) a good alternative (my second approach)? 
> How would you guys solve this "problem"?*
>
> Thanks!
>
> Cheers,
> Steve Winfield
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Ramifications of calling Await.result in akka http

[Rafał Krzewski]

W dniu piątek, 25 listopada 2016 17:12:06 UTC+1 użytkownik gitted napisał:
>
> Instead of composing futures in my akka http application, if I was to 
> frequently make use of Await.result what is the ramification of doing this?
>

Threads would get blocked and performance of your application would 
plummet. Why would you ever want do do that? 


> By default how many threads are there in the main execution context?
>

see http://doc.akka.io/docs/akka/2.4/scala/dispatchers.html 

cheeres,
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] How to reference an existing actor?

[Rafał Krzewski]

W dniu środa, 2 listopada 2016 18:28:22 UTC+1 użytkownik Harinath 
Mallepally napisał:
>
> Hi Rafal,
>
> How do I get to stop my actor, if i want to? looks like I don't see an 
> option. we have defined actors that do certain activities when ordered to 
> do so and have life cycle, so we create and then when we are done with it, 
> we are stopping too.  trying to avoid use deprecated methods now.
>

There are multiple ways:
- actor can stop itself by calling context.stop(self)
- actor can be stopped by it's parent - actor can access ActorRefs of all 
child actors it creates (context.childen, context.child(name: String))
- actor can be stopped automatically when it's parent is stopped
- you can send an akka.actor.PoisonPill message to an actor to stop it

Usually the first way is recommended: upon reaching a certain state (after 
receiving all pending confirmations, a timeout etc depending on use case) 
actor stops itself. 

cheers,
Rafał
 

>
> the ActorSystem.stop takes a ActorRef as input and not ActorSelection. 
> Also [1] says we preferable method to communicate with Actor is through 
> ActorRef and not through ActorSelection is this correct?
>
> Thanks
> Hari
>
> 1. 
> http://doc.akka.io/docs/akka/2.4/java/untyped-actors.html#Identifying_Actors_via_Actor_Selection
>
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Synchronization issue

[Rafał Krzewski]

Hi,
the callbacks are definitely not a good idea. The idiomatic way is sending 
messages that are pure immutable data.
In your case, this means that the ExecuteOnPlayersByPosition message should 
act as an envelope for another message specifying the details of the 
operation.
It's not clear to me which actor tracks the positions of players. Supposing 
that it's the room supervisor actor: upon reception of 
ExecuteOnPlayersByPosition it filters the list of players by position and 
forwards the embedded message to their respective actors. Supposing that 
each player's actor tracks her own position, room supervisor forwards 
ExecuteOnPlayersByPosition verbatim to all players in the room, and 
player's actor checks the envelope and if position matches sends the 
extracted command to self, otherwise ignores the message.

Cheers,
Rafał


W dniu środa, 2 listopada 2016 14:18:43 UTC+1 użytkownik Steve Winfield 
napisał:
>
> Hey,
>
> I got a question regarding a project I'm working on.
>
> There are player actors that can be managed by a "player director" actor 
> which belongs to a virtual room and supervises the players. A player 
> maintains its current position and name as a mutable state.
>
> The director looks like this:
>
> class PlayerDirector extends Actor {
>  
>  private val players = mutable.Map[Int, ActorRef]() // Id, Player ref
>  
>  override def receive = {
>   case SpawnPlayer(playerReference) => players += 
> (incrementAndGetId() -> context.actorOf(Player.props(playerReference)))
>   case RemovePlayer(id) => ...
>  }
> }
>
>
> Now I'd like to execute some operations on all players which are 
> positioned at x, y
>
> My first attempt:
>
> class PlayerDirector ...
>receive = {
>   
>   case ExecuteOnPlayersByPosition(position, callback) => {
> for ((id, player) <- players) {
>player ! ExecuteIfPositionMatches(position, callback)
> }
>   }
>   
>
>
> Then, the player would check its position and execute the callback from 
> its context. I don't like this implementation because it forces me to have 
> the callback executed on the player's actor, but It's the only way to 
> guarantee synchronization (I guess).
>
> Do you have any advice for me?
>
> 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] How to reference an existing actor?

[Rafał Krzewski]

W dniu wtorek, 1 listopada 2016 23:38:22 UTC+1 użytkownik Harinath 
Mallepally napisał:
>
> Thanks for the response,
>
> another question:
> How will I know that message is not delivered to the actor? 
>
> You will not. You may know that the message WAS delivered if the recipient 
sends back a reply. That's one of core principles of Akka: 
http://doc.akka.io/docs/akka/2.4/general/message-delivery-reliability.html
It may sound strange, but there's a deep meaning to it: it prevents you 
from falling 
for https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

cheers,
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] Re: Custom logic BroadcastHub dynamic stream to load balance

[Rafał Krzewski]

Hi,

you'll definitely need to implement a custom GraphStage then. The API you 
want looks something like this:

object SplitterHub {
  /** Materialized when a graph containing hub Sink is run. 
   *  Allows dynamic creation of Sources the Sink will forward elements to. 
*/
  trait Splitter[T] {
/** Will emit elements matched by `selector` predicate */
def source(selector: T => Boolean): Source[T, NotUsed]
/** Will emit elements not matched by any of active selectors */
def defaultSource: Source[T, NotUsed]
  }  
  def sink[T]: Sink[T, Splitter[T]]
  def sink[T](bufferSize: Int): Sink[T, Splitter[T]]
}

and the usage pattern for the use case you described above:

case class Event(i: Int)

val producer: Source[Event] = ???
val sink2: Sink[Event] = ???
val sink3: Sink[Event] = ???
val sink4: Sink[Event] = ???

val splitter = SplitterHub.Splitter[Event] =
  producer.toMat(SplitterHub.sink)(Keep.right).run()

splitter.source(_.i % 2 == 0).to(sink2).run()
splitter.source(_.i % 3 == 0).to(sink3).run()
splitter.source(_.i % 4 == 0).to(sink4).run()
splitter.defaultSource.to(Sink.ignore).run()

Event(4) will be propagated to sink4 and sink2, Event(3) will be propagated 
to sink3, Event(2) will be propagated to sink2, and Event(1) will be 
ignored.
If a defaultSource was not connected to a Sink, Event(1) would "clog" the 
hub, until a suitable Sink was connected.

This is just a sketch of API however. Fleshing out the details of the 
semantics especially with respect to backpressure will be quite a bit of 
work. On the other hand, such component would be quite generally usable - a 
great opportunity to contribute to Akka!

Cheers,
Rafał

W dniu piątek, 28 października 2016 11:17:33 UTC+2 użytkownik auxdx napisał:
>
> Hi,
>
> The number of consumers are not fixed. There can be other consumer types 
> like: Filter(divisible by 3), Filter(divisible by 4), etc... later on. That 
> is why I want a broadcastHub so that I can inject/create new consumer type 
> later on.   When an event arrives for which there is no suitable consumer 
> connected at the moment, this event will simply be ignore. But once 
> consumer like Filter(divisible by 4) join BroadCastHub for instance, all 
> number which is "divisible by 4" will be forwarded to that consumer (such 
> as number 4). Number 4 will also be forwarded to "EvenConsumer" (because 4 
> mod 2 = 0). There will be a custom function so that for each element in the 
> stream, it will return list of all registed consumers it should forward to. 
> However, stand graph stages approach required a fixed output port (not 
> dynamic). Could you please suggest/elaborate more a suitable way to handle 
> this?
>
> Thanks.
>
> On Friday, 28 October 2016 01:55:44 UTC+8, Rafał Krzewski wrote:
>>
>> W dniu czwartek, 27 października 2016 19:29:14 UTC+2 użytkownik auxdx 
>> napisał:
>>>
>>> There might be several consumers. Each consumer has an type; For 
>>> "EvenConsumer"; it expects to receive ONLY even numbers; for "OddConsumer", 
>>> it expects to receive ONLY odd number; If at the beginning; old 
>>> EvenConsumer join the Hub; even number from the datasource will be sent to 
>>> evenconsumer; where odd number from data will be ignore; later on, 
>>> OddConsumer might joined, and it will receive odd number from data source.
>>>
>>> Are types of consumers fixed up front? What happens when an event 
>> arrives for which there is no suitable consumer connected at the moment?
>> If the answers are yes, upstream is backpressured, you could implement it 
>> with standard graph stages:
>>
>> in ~> Broadcast ~> Filter (even) ~> BroadcastHub
>>  \
>>   ~> Filter (odd) ~> BroadcastHub 
>>
>> You'll need to do some materialized value wrangling, because you'd need 
>> to get a hold on both of the values produced by broadcast hubs.
>>
>> If you need more flexibility, you'll have to implement a CustomGraph 
>> stage that will provide a materialized value allowing attaching consumers, 
>> just like BroadcastHub does.
>>
>> cheers,
>> 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] Re: Load balance a reactive datasource from one machine to multiple remote consumers (on remote VM) via TCP

[Rafał Krzewski]

Hi,

you could use TCP, chunked HTTP or WebSockets to transfer the stream of 
data across VMs while preserving backpressure, but what about error 
handling? How do you deal with VM2 or VM3 crashing after accepting data 
elements from VM1?

I have a very basic understanding of Kafka, but maybe a partitioned topic 
could be a suitable mechanism to reliably distribute work? I have no idea 
though if Kafka could be configured to backpressure the writer if the 
readers are not keeping up. This may or may not be a deal breaker, 
depending on your use case. 

Alternatively, you could use ActorPublisher / ActorSubscriber at the 
boundaries of your Akka Streams and use Actor-level constructs to 
distribute the work: Akka remoting / cluster / sharding etc.

Cheers,
Rafał


W dniu czwartek, 27 października 2016 19:19:44 UTC+2 użytkownik auxdx 
napisał:
>
> Hi,
>
> I know that akka stream doesn't support remote actor. But I am trying to 
> achieve something similar to "balancer" stages of akka stream for remote 
> actors / remote processes. My user case is a bit complicated but I will use 
> a simple example to demonstrate it. 
>
> Suppose, I have a reactive source: such as val source =  Source(1 to 10) 
> which run on VM1 (data can be pulled from Kafka constantly). On VM2, and 
> VM3, I will need to somehow run an expensive computation runnable graph 
> (such as Source.via(Flow.something).to(Sink.ignore)) which operates on a 
> subset of VM1's source's elements . For instance, I want VM2 to handle even 
> number; such as Source(2 to 10 by 2); and VM3 handle odd number such as 
> Source(1 to 9 by 2); In other words, given that VM1 having a single 
> publisher which publishes a data stream consistently; I want to somehow 
> load balance it to VM2 and VM3 (remote PC) to distribute computation; which 
> VM (2 or 3) it should forward to is based on property of the number such as 
> if number is odd or even.
>
> In case the computation runnable graph must be on VM2 and VM3, what is the 
> best way to achieve it given that the data source is on VM1? Via TCP? If 
> so, how to make sure it's back-pressure. 
>
> I guess one way to do is somehow run 2 actors (ActorPublishers) on VM2, 
> VM3; when those 2 are back-pressued from downstream; it will pull data from 
> source on VM1; It this the correct way to do so. Some code will be helpful. 
>
> Thanks.
>

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

[akka-user] Re: Akka HTTP Source in a Graph

[Rafał Krzewski]

Hi Héctor,

You should take a look at MergeHub [1]. You could then wrap each incoming 
message into a Source.single and send it through the hub into the intended 
consumer.

Alternatively you could create a Source.actorPublisher, and pass the 
ActorRef produced by materialization of your flow to the route. You'd have 
to implement an ActorPubslisher then and it's not trivial, so unless you 
have to process thousands of such messages per second, MergeHub would be 
preferable.

Cheers,
Rafał

[1] 
http://doc.akka.io/docs/akka/2.4/scala/stream/stream-dynamic.html#Dynamic_fan-in_and_fan-out_with_MergeHub_and_BroadcastHub

W dniu czwartek, 27 października 2016 00:11:44 UTC+2 użytkownik Héctor 
Veiga napisał:
>
> Hi,
>
> I am trying to figure out if it is possible to use an HTTP Akka Source as 
> a Source in a Graph DSL.
> My main problem is how to reference the next element in the graph in the 
> akka route.
>
> When you are not using it as a Source you can do the following:
>
>   private def route(someActor: ActorRef) =
> post {
>   entity(as[String]) { message =>
> someActor ! message
> complete("")
>   }
> } 
>
> Then you call Http().bind(...) but you need to pass an ActorRef to the 
> route().
>
> However, I would like to do something like:
>
>   private def route() =
> post {
>   entity(as[String]) { message =>
> *nextElement* ! message
> complete("")
>   }
> } 
>
> val g = RunnableGraph.fromGraph(GraphDSL.create() { implicit builder: 
> GraphDSL.Builder[NotUsed] =>
>   import GraphDSL.Implicits._
>   val source = Http.bind(...)
>   val out = Sink.ignore
>  
>   val f1 = Flow[Int].map(_ + "something")
>  
>   in ~> f1 ~> out
>   ClosedShape
> })
>
> "nextElement" is what I am looking for. A way of pushing to the next 
> element in the graph.
>
> Thanks,
>
> Héctor.
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: [akka-stream] Problems with the shape creation

[Rafał Krzewski]

Sergey, I spent a few minutes looking at your code, and I see two problems:
-inletNumberToPullFrom is not scoped properly. It should be local to 
GraphLogic implementation. In the current form, it is shared between all 
ManagementFlow instances that get materialized that is definitely not what 
you want
- you expect that elements will be pushed to the inlets before findInelt() 
method will be first called. To the best of my knowledge this is not how 
Akka Streams work. If you don't see the exception in the default case of 
switch(inletNumbetToPullFrom) thrown, that would mean that the demand token 
never reaches ManagementFlow inlet 0, possibly because it is not propagated 
correctly in FL graph.

My recommendation is still to test FL, S, C and ManagementFlow in isolation 
(ie connecting them only to TestSource, TestSink, Source.single, 
Sink.ignore etc) and only then proceed to wiring them together.

BTW, have you read the blog posts [1] and [2]? I find them quite 
informative.

Cheers,
Rafał

[1] http://blog.akka.io/streams/2016/07/30/mastering-graph-stage-part-1
[2] 
http://blog.akka.io/integrations/2016/08/25/simple-sink-source-with-graphstage

W dniu poniedziałek, 24 października 2016 23:38:54 UTC+2 użytkownik Sergey 
Sopin napisał:
>
> Hi Rafał,
>
> - sink requests data from you
>> - OutletHandler.onPull is invoked on the outlet where the sink is 
>> connected to
>> - you propagate demand outstream by calling pull on any (or all) of your 
>> Inlets, depending on your logic
>> - eventually data becomes available upstream
>> - InletHandler.onPush is invoked on the inlet you pulled previously, with 
>> the incoming element
>>
>
> I tried to add logging into onPull functions, but it didn't help. I see 
> only messages from the beggining of flow ("Message_1"), but not from my 
> custom shape. 
>
> OK, but the actual number of workers should not be greater than the number 
>> of available CPUs, because otherwise Akka will interleave their execution 
>> anyway. Spawning 1000s of worker flows will only waste memory. Of course I 
>> understand that the input of fixed collection of data is artif
>>
>
> I tried to remove balancer at all and work with the single worker. It 
> doesn't help.
>
>  I usually prefer to debug single problem at a time than a number of 
>> possibly interrelated problems at once.
>>
>
> Me too and I will try, but I am sure that it will give me nothing in this 
> case.
> The problem is in the shape itself. 
>
> Regards,
> Sergey
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: [akka-stream] Problems with the shape creation

[Rafał Krzewski]

W dniu czwartek, 20 października 2016 20:28:26 UTC+2 użytkownik Sergey 
Sopin napisał:
>
> Rafał,
>
> - If I understand onPulI() function correctly, it is allowed only for 
> outlets, so in order to pull something you need to push it in this outlet 
> firstly.
>
>
Here's how I understand how this works (and if I'm wrong, I'd really 
appreciate comments / corrections!)

The initiating component in the system is the Sink. It pulls data out of 
it's upstream component. So, if there is a attached to your custom 
flow-shaped GraphStage the sequence of events is as follows:

- sink requests data from you
- OutletHandler.onPull is invoked on the outlet where the sink is connected 
to
- you propagate demand outstream by calling pull on any (or all) of your 
Inlets, depending on your logic
- eventually data becomes available upstream
- InletHandler.onPush is invoked on the inlet you pulled previously, with 
the incoming element
- you do your processing and call push on the appropriate outlet, which 
means any outlet that signaled demand beforehand. This also means that you 
might want to postpone pulling from upstream until *all* of your outlets 
signaled demand. Otherwise you might end up with a processed element that 
you can't emit downstream because it's intended outlet is backpressuring 
you (ie. not requesting an element at the moment). 

GraphStages can also react to asynchronous events other than pulls and 
pushes: timers, cancellation requests etc, but that's whole another story.

 

> - Balancer has been taken from the docs: 
> Balancing_jobs_to_a_fixed_pool_of_workers 
> <http://www.google.com/url?q=http%3A%2F%2Fdoc.akka.io%2Fdocs%2Fakka%2F2.4%2Fjava%2Fstream%2Fstream-cookbook.html%23Balancing_jobs_to_a_fixed_pool_of_workers=D=1=AFQjCNFP3NVatZlUNZC8N2z_ewDYMu40-w>
>  
>
>
OK, but the actual number of workers should not be greater than the number 
of available CPUs, because otherwise Akka will interleave their execution 
anyway. Spawning 1000s of worker flows will only waste memory. Of course I 
understand that the input of fixed collection of data is artificial 
example. If the amount of data was fixed and small enough to fit into RAM, 
using Akka Streams for processing it would be an overkill.
 

> - I don't think that testing will help me, because based on the first 
> statement I would see something in the log. So, messages do not go inside 
> the shape and stuck somewhere between flow and managementFlow. 
>
>
Whatever floats your boat, man :) I usually prefer to debug single problem 
at a time than a number of possibly interrelated problems at once. Also, I 
still believe that the the messages are not pulled into managementFlow 
because demand is somehow lost. The few messages that you see leaving the 
source are probably pulled into the buffers at async boundary created with 
worker.async().But that's just my guess.

Cheers,
Rafał
 

> Regards,
> Sergey
>
> четверг, 20 октября 2016 г., 13:52:58 UTC+3 пользователь Rafał Krzewski 
> написал:
>>
>> Sergey,
>> I have a few remarks after cursory reading of your code:
>>
>> - Akka Streams (and Reactrive Streams) are pull based. As the messages 
>> travel downstream, virtual demand tokens travel upstream. Each graph 
>> element is allowed to push elements downstream only when demand is 
>> signaled. This means that you must keep track of demand carefully. In a 
>> GraphStage that is flow-shaped (has both inlets and outlets), flow of data 
>> is initiated by a pull on it's outlets. If you fails to propagate such pull 
>> to some (or all) of your GraphStage's inlets things are going to stall. In 
>> your test code, you put debut statements in onPush methods, but you should 
>> also monitor onPull
>>
>> - There's something strange with your balancer component. Either I'm 
>> misreading things, or you removed some important details while editing the 
>> code for publication, but it seems to me that each Data input element will 
>> be processed in a dedicated, parallel finderFlow / each finderFlow will 
>> ever see only a single element. This also could be a reason of the "clog" 
>> you experience.
>>
>> - In general I would suggest building your flow processing "outwards": 
>> first try to validate that managementFlow works in isolation (unit tests 
>> with Stream Test Kit would be recommended here) and once you have this 
>> settled, build and test large flows progressively.
>>
>> Hope that helps,
>> Rafał
>>
>>
>>

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

Re: [akka-user] Re: [akka-stream] Problems with the shape creation

[Rafał Krzewski]

Sergey,
I have a few remarks after cursory reading of your code:

- Akka Streams (and Reactrive Streams) are pull based. As the messages 
travel downstream, virtual demand tokens travel upstream. Each graph 
element is allowed to push elements downstream only when demand is 
signaled. This means that you must keep track of demand carefully. In a 
GraphStage that is flow-shaped (has both inlets and outlets), flow of data 
is initiated by a pull on it's outlets. If you fails to propagate such pull 
to some (or all) of your GraphStage's inlets things are going to stall. In 
your test code, you put debut statements in onPush methods, but you should 
also monitor onPull

- There's something strange with your balancer component. Either I'm 
misreading things, or you removed some important details while editing the 
code for publication, but it seems to me that each Data input element will 
be processed in a dedicated, parallel finderFlow / each finderFlow will 
ever see only a single element. This also could be a reason of the "clog" 
you experience.

- In general I would suggest building your flow processing "outwards": 
first try to validate that managementFlow works in isolation (unit tests 
with Stream Test Kit would be recommended here) and once you have this 
settled, build and test large flows progressively.

Hope that helps,
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: [akka-stream] Problems with the shape creation

[Rafał Krzewski]

Sergey, you haven't shown any code related to passing messages yet, so it's 
impossible to guess what's happening at this point.
As I said in previous message, the critical things are the actual 
components you put *inside* of your graph. The shapes just determine 
external connectors.

Cheers,
Rafał

W dniu środa, 19 października 2016 12:11:20 UTC+2 użytkownik Sergey Sopin 
napisał:
>
> Yep, I was trying to make something like that, but my code doesn't work. 
> Messages stuck somewhere and I don't know how to fix it due to lack of 
> Scala knowledge. You can find the code in my initial message here. 
> I took UniformFanOut as example and unsuccessfully tried to replace single 
> Inlet with the set of them.
> If you could help me to fix it I would be more than happy :)
> Thanks!
>
> Regards,
> Sergey
>
> среда, 19 октября 2016 г., 11:32:05 UTC+3 пользователь Konrad Malawski 
> написал:
>>
>> Shapes don't need separate java or scala api, it's shared.
>>
>> You can just subclass a shape and make a class that directly represents 
>> your shape.
>> If you want AmorphousShape then sure, but please note that it's purpose 
>> is to "forget about the types of those".
>>
>> If you want a well typed one simply extend Shape and fill in the abstract 
>> methods - see FlowShape etc for examples how to do this.
>>
>> -- 
>> Konrad `ktoso` Malawski
>> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>>
>> On 19 October 2016 at 08:03:16, Sergey Sopin (sopi...@gmail.com) wrote:
>>
>> Hi, 
>>
>> Yes, but it seems that I need to create Java API for it, because my app 
>> is in Java. 
>> I used Inkscape app. to draw the diagram.
>>
>> Cheers,
>> Sergey
>>
>> среда, 19 октября 2016 г., 0:46:00 UTC+3 пользователь Rafał Krzewski 
>> написал: 
>>>
>>> A custom GraphStage [1] using AmorphousShape is probably the way to go 
>>> in this case. 
>>>
>>> That's a really neat diagram, BTW! What software did you us to create it?
>>>
>>> Cheers,
>>> Rafał
>>>
>>> [1] 
>>> http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#Custom_processing_with_GraphStage
>>>
>>> W dniu wtorek, 18 października 2016 22:12:07 UTC+2 użytkownik Sergey 
>>> Sopin napisał: 
>>>>
>>>> Hi again,
>>>>
>>>> I have a very specific case. My flow looks like this one: 
>>>>
>>>>
>>>> <https://lh3.googleusercontent.com/-qrP4yHkVYI8/WAaAO1-q67I/Abw/acUT-YaG48k0lo7MkePGv9QVVRkH5L_BACLcB/s1600/Flow.png>
>>>>
>>>> The idea of multi input/output shape was to redirect messages to a 
>>>> right output based on the message data.
>>>>
>>>> I just learn streams, so maybe you can suggest a better solution?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> Cheers, 
>>>>
>>>> Sergey
>>>>
>>>>
>>>>
>>>> вторник, 18 октября 2016 г., 18:34:22 UTC+3 пользователь Rafał Krzewski 
>>>> написал: 
>>>>>
>>>>> It's not clear to me, what are you trying to accomplish. It looks like 
>>>>> you are trying to implement AmorphousShape (ie. arbitrary number of open 
>>>>> inlets and outlets) on your own, and then a specific variant of it, that 
>>>>> has all inlets sharing the same type, and all outlets sharing another 
>>>>> type. 
>>>>> The "Fan" fragment in the names you used is a bit misleading, since in 
>>>>> Akka 
>>>>> Stream's own usage of it names like FanIn / FanOut shape mean that such 
>>>>> grap has many inlets and single outlet / single inlet many outlets. The 
>>>>> analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
>>>>> many blades :) I am wondering what use case you have in mind for your 
>>>>> AmorphousShape because the graphs that can be materialized and executed 
>>>>> must ultimately have a ClosedShape. You could use such multi-outlet 
>>>>> graphs 
>>>>> for reusing pieces of functionality, but anything more complex than a 
>>>>> BidiShape  seems  rather unwieldy to me. 
>>>>>
>>>>> My understanding is that Graph's shape should not interfere with 
>>>>> message flow, because it's just a canvas with contact points on the 
>>>>> perimeter. What matters are the components th

[akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

[Rafał Krzewski]

Hi,

I took a quick look at the new Akka HTTP artifacts published on Maven 
Central, and I've noticed that artifact names don't have Scala version 
suffix in them. Is this intentional?

Cheers,
Rafał

W dniu wtorek, 18 października 2016 00:22:17 UTC+2 użytkownik Konrad 
'ktoso' Malawski napisał:
>
> Dear hakkers,
>
> We are proud to announce the first Release Candidate of the Akka HTTP's 
> "fully stable" release–the only missing, bit was the Routing DSLs, which we 
> now deem stable enough to support for an extended period of time.
>
>
> This release marks the first of the 3.0.0 series of this project and 
> signifies a large step in terms of confidence in the library, as well as 
> the move of Akka HTTP into its own repository. From now on Akka HTTP will 
> be versioned separately from Akka “core”. This has been discussed at large 
> with the community on akka-meta , and 
> the akka-http  repositories on 
> github. Thank you very much for your input!
>
> For more background why this move, please read “Akka HTTP - stable, 
> growing and tons of opportunity 
> ” on akka-meta. While 
> preparing In the meantime we have delivered a Proof-of-Concept of HTTP/2 
> for Akka HTTP and plan to continue this work later this year–community help 
> is very much welcome on this front as well.
>
> The documentation from now on will be available here: 
>
> Some noteworthy changes in the *3.0.0-RC1* (since it's move out from 
> 2.4.11) release are:
>
>
>- 
>
>New lightbend/paradox powered documentation
>- 
>   
>   This will allow us to aggregate it together with Akka and other 
>   documentation, as well as link more easily to ScalaDoc pages
>   - 
>   
>   Akka HTTP documentation will from now on live here: 
>   http://doc.akka.io/docs/akka-http/current/index.html
>   - 
>   
>   We’ll work on a better theme for it very soon.
>   - 
>
>Multipart is now correctly Binary MediaType (instead of 
>WithOpenCharset) #398 
>- 
>
>A new designated mailing-list and page for any critical security 
>issues that might come up has been created: 
>http://doc.akka.io/docs/akka-http/current/security.html 
>- 
>   
>   Please follow the linked mailing list if you have production Akka 
>   systems, so you’ll be the first to know in case a security issue is 
> found 
>   and fixed in Akka.
>   
>
> The plan regarding releasing a stable 3.0.0 is to wait a little bit for 
> community feedback on the release candidates, and call a stable one no 
> longer than a few weeks from now. We’re eagerly awaiting your feedback and 
> can’t wait to ship the stable version of all of Akka HTTP’s modules!
>
> Credits
>
> A total 15 issues were closed since 2.4.11, most of the work was moving 
> source code, documentation and issues to their new places.
>
> The complete list of closed issues can be found on the 3.0.0-RC1 
>  milestone on 
> github.
>
> For this release we had the help of 14 committers – thank you!
>
> A special thanks to Jonas Fonseca  who did a 
> tremendously awesome job at migrating all the docs from sphinx 
> (restructuredtext) to paradox (markdown), contributing features that the 
> Akka docs needed to upstream Paradox–thanks a lot!
>
> Credits:
>
> commits added removed
>
>   10   22489   24696 Jonas Fonseca
>
>   101927 256 Johannes Rudolph
>
>   10 849 412 Konrad Malawski
>
>4 448 136 Robert Budźko
>
>2  37  37 Bernard Leach
>
>2 107   7 Richard Imaoka
>
>2  26  24 Jakub Kozłowski
>
>1 145 101 Jan @gosubpl
>
>1 108 114 Derek Wyatt
>
>1  45  33 Wojciech Langiewicz
>
>1  49   0 @2beaucoup
>
>1   6   6 Markus Hauck
>
>1   1   1 Ian Forsey
>
>1   1   1 Johan Andrén
>
>
> Happy hakking!
>
> – The 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.

[akka-user] Re: [akka-stream] Problems with the shape creation

[Rafał Krzewski]

A custom GraphStage [1] using AmorphousShape is probably the way to go in 
this case.

That's a really neat diagram, BTW! What software did you us to create it?

Cheers,
Rafał

[1] 
http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#Custom_processing_with_GraphStage

W dniu wtorek, 18 października 2016 22:12:07 UTC+2 użytkownik Sergey Sopin 
napisał:
>
> Hi again,
>
> I have a very specific case. My flow looks like this one:
>
>
> <https://lh3.googleusercontent.com/-qrP4yHkVYI8/WAaAO1-q67I/Abw/acUT-YaG48k0lo7MkePGv9QVVRkH5L_BACLcB/s1600/Flow.png>
>
> The idea of multi input/output shape was to redirect messages to a right 
> output based on the message data.
>
> I just learn streams, so maybe you can suggest a better solution?
>
> Thanks!
>
>
> Cheers, 
>
> Sergey
>
>
>
> вторник, 18 октября 2016 г., 18:34:22 UTC+3 пользователь Rafał Krzewski 
> написал:
>>
>> It's not clear to me, what are you trying to accomplish. It looks like 
>> you are trying to implement AmorphousShape (ie. arbitrary number of open 
>> inlets and outlets) on your own, and then a specific variant of it, that 
>> has all inlets sharing the same type, and all outlets sharing another type. 
>> The "Fan" fragment in the names you used is a bit misleading, since in Akka 
>> Stream's own usage of it names like FanIn / FanOut shape mean that such 
>> grap has many inlets and single outlet / single inlet many outlets. The 
>> analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
>> many blades :) I am wondering what use case you have in mind for your 
>> AmorphousShape because the graphs that can be materialized and executed 
>> must ultimately have a ClosedShape. You could use such multi-outlet graphs 
>> for reusing pieces of functionality, but anything more complex than a 
>> BidiShape  seems  rather unwieldy to me.
>>
>> My understanding is that Graph's shape should not interfere with message 
>> flow, because it's just a canvas with contact points on the perimeter. What 
>> matters are the components that you plug into it. Akka just makes sure that 
>> you don't leave any of the contact points dangling. This makes me think 
>> that the problems with messages getting "stuck" was caused somewhere other 
>> than graph shape construction site.
>>
>> Have you tried inserting probes alon the lines of Flow.alsoTo(Sink.foreach(_ 
>> => println("beep!"))) (shooting from the hip here, apologies if it does 
>> not compile straight away) into your graph? That could help you locate 
>> where the messages are stuck / discarded.
>>
>> Cheers,
>> Rafał
>>
>> W dniu poniedziałek, 17 października 2016 20:22:43 UTC+2 użytkownik 
>> Sergey Sopin napisał:
>>>
>>> Hi,
>>>
>>> I am trying to create my own akka streams shape with several Inlets and 
>>> Outlets. I have written following code: 
>>>
>>> package kernel.modeller.workers.streamFinder.generic
>>>
>>> import akka.stream.{Shape, Outlet, Inlet}
>>> import scala.annotation.unchecked.uncheckedVariance
>>> import scala.collection.immutable
>>>
>>> object FanShape {
>>>   sealed trait Init[_] {
>>> def inlets: immutable.Seq[Inlet[_]]
>>> def outlets: immutable.Seq[Outlet[_]]
>>> def name: String
>>>   }
>>>   final case class Name[_](override val name: String) extends Init[Any] {
>>> override def inlets: immutable.Seq[Inlet[_]] = Nil
>>> override def outlets: immutable.Seq[Outlet[_]] = Nil
>>>   }
>>>   final case class Ports[_](override val inlets: immutable.Seq[Inlet[_]], 
>>> override val outlets: immutable.Seq[Outlet[_]]) extends Init[Any] {
>>> override def name: String = "FanShape"
>>>   }
>>> }
>>>
>>> abstract class FanShape[_] private (_in: Iterator[Inlet[_]], _out: 
>>> Iterator[Outlet[_]], _name: String) extends Shape {
>>>   
>>>   import FanShape._
>>>
>>>   def this(init: FanShape.Init[_]) = this(init.inlets.iterator, 
>>> init.outlets.iterator, init.name)
>>>
>>>   final override def outlets: immutable.Seq[Outlet[_]] = _outlets
>>>   final override def inlets: immutable.Seq[Inlet[_]] = _inlets
>>>
>>>   private var _outlets: Vector[Outlet[_]] = Vector.empty
>>>   private var _inlets: Vector[Inlet[_]] = Vector.empty
>>>
>>>   protected def newOutlet[T](name: String): Outlet[T] = {
>>> val p = if (_out.hasNext) _out.ne

[akka-user] Re: [akka-stream] Problems with the shape creation

[Rafał Krzewski]

It's not clear to me, what are you trying to accomplish. It looks like you 
are trying to implement AmorphousShape (ie. arbitrary number of open inlets 
and outlets) on your own, and then a specific variant of it, that has all 
inlets sharing the same type, and all outlets sharing another type. The 
"Fan" fragment in the names you used is a bit misleading, since in Akka 
Stream's own usage of it names like FanIn / FanOut shape mean that such 
grap has many inlets and single outlet / single inlet many outlets. The 
analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
many blades :) I am wondering what use case you have in mind for your 
AmorphousShape because the graphs that can be materialized and executed 
must ultimately have a ClosedShape. You could use such multi-outlet graphs 
for reusing pieces of functionality, but anything more complex than a 
BidiShape  seems  rather unwieldy to me.

My understanding is that Graph's shape should not interfere with message 
flow, because it's just a canvas with contact points on the perimeter. What 
matters are the components that you plug into it. Akka just makes sure that 
you don't leave any of the contact points dangling. This makes me think 
that the problems with messages getting "stuck" was caused somewhere other 
than graph shape construction site.

Have you tried inserting probes alon the lines of Flow.alsoTo(Sink.foreach(_ 
=> println("beep!"))) (shooting from the hip here, apologies if it does not 
compile straight away) into your graph? That could help you locate where 
the messages are stuck / discarded.

Cheers,
Rafał

W dniu poniedziałek, 17 października 2016 20:22:43 UTC+2 użytkownik Sergey 
Sopin napisał:
>
> Hi,
>
> I am trying to create my own akka streams shape with several Inlets and 
> Outlets. I have written following code: 
>
> package kernel.modeller.workers.streamFinder.generic
>
> import akka.stream.{Shape, Outlet, Inlet}
> import scala.annotation.unchecked.uncheckedVariance
> import scala.collection.immutable
>
> object FanShape {
>   sealed trait Init[_] {
> def inlets: immutable.Seq[Inlet[_]]
> def outlets: immutable.Seq[Outlet[_]]
> def name: String
>   }
>   final case class Name[_](override val name: String) extends Init[Any] {
> override def inlets: immutable.Seq[Inlet[_]] = Nil
> override def outlets: immutable.Seq[Outlet[_]] = Nil
>   }
>   final case class Ports[_](override val inlets: immutable.Seq[Inlet[_]], 
> override val outlets: immutable.Seq[Outlet[_]]) extends Init[Any] {
> override def name: String = "FanShape"
>   }
> }
>
> abstract class FanShape[_] private (_in: Iterator[Inlet[_]], _out: 
> Iterator[Outlet[_]], _name: String) extends Shape {
>   
>   import FanShape._
>
>   def this(init: FanShape.Init[_]) = this(init.inlets.iterator, 
> init.outlets.iterator, init.name)
>
>   final override def outlets: immutable.Seq[Outlet[_]] = _outlets
>   final override def inlets: immutable.Seq[Inlet[_]] = _inlets
>
>   private var _outlets: Vector[Outlet[_]] = Vector.empty
>   private var _inlets: Vector[Inlet[_]] = Vector.empty
>
>   protected def newOutlet[T](name: String): Outlet[T] = {
> val p = if (_out.hasNext) _out.next().asInstanceOf[Outlet[T]] else 
> Outlet[T](s"${_name}.$name")
> _outlets :+= p
> p
>   }
>
>   protected def newInlet[T](name: String): Inlet[T] = {
> val p = if (_in.hasNext) _in.next().asInstanceOf[Inlet[T]] else 
> Inlet[T](s"${_name}.$name")
> _inlets :+= p
> p
>   }
>
>   protected def construct(init: Init[_]): FanShape[_]
>
>   def deepCopy(): FanShape[_] = construct(Ports(inlets.map(_.carbonCopy()), 
> outlets.map(_.carbonCopy(
>   final def copyFromPorts(inlets: immutable.Seq[Inlet[_]], outlets: 
> immutable.Seq[Outlet[_]]): FanShape[_] = {
> require(outlets.size == _outlets.size, s"proposed outlets 
> [${outlets.mkString(", ")}] do not fit FanShape")
> require(inlets.size == _inlets.size, s"proposed inlects 
> [${inlets.mkString(", ")}] do not fit FanShape")
> construct(Ports(inlets, outlets))
>   }
> }
>
> object UniformFanShape {
>   def apply[I, O](inlets: Array[Inlet[I]], outlets: Outlet[O]*): 
> UniformFanShape[I, O] =
> new UniformFanShape(inlets.size, outlets.size, 
> FanShape.Ports(inlets.toList, outlets.toList))
> }
>
> class UniformFanShape[-I, +O](n: Int, m: Int, _init: FanShape.Init[_]) 
> extends FanShape(_init) {
>   def this(n: Int, m: Int) = this (n, m, FanShape.Name("UniformFan"))
>   def this(n: Int, m: Int, name: String) = this(n, m, FanShape.Name(name))
>   def this(inlets: Array[Inlet[I]], outlets: Array[Outlet[O]]) = 
> this(inlets.size, outlets.size, FanShape.Ports(inlets.toList, outlets.toList))
>   override protected def construct(init: FanShape.Init[_]): FanShape[_] = new 
> UniformFanShape(n, m, init)
>   override def deepCopy(): UniformFanShape[I, O] = 
> super.deepCopy().asInstanceOf[UniformFanShape[I, O]]
>
>   val inArray: Array[Inlet[I @uncheckedVariance]] = 

[akka-user] Re: How to correctly close system when websocket is open?

[Rafał Krzewski]

Hi,
just a quick suggestion: mabe a KillSwitch [1] in Channel flow would help?

cheers,
Rafał

[1] 
http://doc.akka.io/api/akka/2.4/?_ga=1.230565852.1388425308.1467760779#akka.stream.KillSwitch

W dniu poniedziałek, 17 października 2016 21:52:55 UTC+2 użytkownik Andrzej 
Giniewicz napisał:
>
> Hello,
>
> I'm building a prototype for application that aims to use akka-http and 
> websockets for communication. It mostly works, but on close we get 
> exception:
>
> [ERROR] [10/17/2016 19:38:56.104] 
> [my-system-akka.actor.default-dispatcher-10] 
> [akka.actor.ActorSystemImpl(my-system)] WebSocket handler failed with 
> Processor actor 
> [Actor[akka://my-system/user/StreamSupervisor-0/flow-4-0-unknown-operation#1709634420]]
>  
> terminated abruptly (akka.stream.AbruptTerminationException)
>
> We tried many suggestions over the web, including calling 
> Http().shutdownAllConnectionPools() (which ends with success) and unbind 
> (which ends with success as well). Unfortunately it doesn't help - after 
> calling shutdownAllConnectionPools and unbind the websocket is still up (we 
> can send messages and receive answers from it). How to correctly close the 
> system to avoid such issue?
>
> This is how (fragments) of how we build the binding (for now this is 
> single client app, so we have single actor to process messages):
>
> val processing = system.actorOf(Props[ProcessingActor], "processing-1")
> val route = get {
>   pathEndOrSingleSlash {
> complete {
> // ...
> }
>   } ~ encodeResponse {
> getFromResourceDirectory("")
>   } ~ path("ws") {
> handleWebSocketMessages(Channel(processing))
>   }
> }
> val bindingFuture = Http().bindAndHandle(route, "localhost", port)
>
> and then we wait (readLine) after which we close (as I said we have 
> shutdownAllConnectionPools, unbind and terminate). Page contains html and 
> Channel is custom flow.
>
> object Channel {
>   private val bufferSize = 5
>   def apply(processing: ActorRef)(implicit system: ActorSystem): 
> Flow[WSMessage, WSMessage, _] = Flow.fromGraph(GraphDSL.create(
>   Source.actorRef[Message](bufferSize=bufferSize, 
> OverflowStrategy.fail)
> ) { implicit builder => source =>
>   val sink = Sink.actorRef[SystemCommand](processing, Close)
>   val actor = builder.materializedValue.map(a => Initialize(a))
>   val fromSocket = builder.add(Flow[WSMessage].collect {
> // ...
>   })
>   val toSocket = builder.add(Flow[Message].map {
> // ...
>   })
>   val merge = builder.add(Merge[SystemCommand](2))
>   fromSocket ~> merge.in(0)
>   actor ~> merge.in(1)
>   merge ~> sink
>   source ~> toSocket
>   FlowShape(fromSocket.in, toSocket.out)
>   })
> }
>
> Any help would be appreciated - and btw, this was one of first attempts 
> and we got something up and running in just few hours, so even that we have 
> issues with close, we would like to emphatize that we think Akka is great!
> Andrzej.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: What's the replacement for Akka Actor Publisher and Subscriber?

[Rafał Krzewski]

You can use Akka HTTP with WebSockets for streaming data over a network 
link between nodes. This way you could attach a reactive stream in one node 
with a remote reactive stream, preserving backpressure semantics.
If you are concerned with the overhead, you could use 
akka.streams.scaladsl.Tcp to stream data over a raw TCP socket, but of 
course you'd need to work out your custom protocol details.
This may look like a lot of work, but that's just another example of Akka 
being honest with you: network is unreliable in general, and "exactly once" 
semantics of message delivery come at a cost.

Cheers,
Rafał

W dniu wtorek, 11 października 2016 21:08:03 UTC+2 użytkownik Justin du 
coeur napisał:
>
> One of the team will have to answer this -- AFAIK, streams just plain 
> don't work cross-node yet.  (Which is why I'm not using them myself yet.)
>
> On Mon, Oct 10, 2016 at 7:27 PM, Dagny T  > wrote:
>
>>
>> Right; can you provide a Blog URL or something to explain further?  
>>
>> What is the recommended architecture when you want to stream data between 
>> remote Actor-based services?
>> i.e. the implementations of Actor Publisher/Subscriber which actually 
>> work across remote boundaries 
>> (location transparency, I thought was the whole point of Akka's 
>> awesomeness).
>>
>> Thanks in advance!
>> D
>>
>> On Monday, September 26, 2016 at 12:07:55 AM UTC-7, Dagny T wrote:
>>>
>>> Hi there,
>>>
>>> The latest info I have from a prior Akka Team response was that the Akka 
>>> Actor Publisher/Subscriber APIs are now deprecated; 
>>> and one should be looking at the Graph DSL instead.
>>>
>>> i.e. Latest Akka Docs state:
>>> ActorPublisher and ActorSubscriber
>>>  cannot be used with remote actors, 
>>> because if signals of the Reactive Streams protocol (e.g. request) are 
>>> lost the the stream may deadlock.
>>>
>>> So, now I'm not clear on what the replacement APIs we're supposed to be 
>>> using; as far as connecting State-Holding Akka Actors to Graph DSL 
>>> Event-Streams.
>>>
>>> Is there an Akka Team Blog with a GitHub link to a small focused example 
>>> which demonstrates this?
>>>
>>> THANKS in advance for any help with finding the latest APIs to use for 
>>> this!
>>> Dagny
>>>
>>>
>>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [akka-user] How to handle web socket message to upload base64 encoded string of 10mb file

[Rafał Krzewski]

Right, thanks :)

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

Re: [akka-user] How to handle web socket message to upload base64 encoded string of 10mb file

[Rafał Krzewski]

In my particular application the messages I'm receiving a few kB in size. 
Sometimes they arrive as Strict and sometimes as Streaming, but they are 
small enough to be collected and processed as a single chunk. Here's a 
pipeline stage I'm using to handle both cases in an uniform way:









*val unframing: Flow[Message, String, NotUsed] =  
Flow.fromFunction[Message, Future[String]](_ match {case 
TextMessage.Strict(text) =>  Future(text)case 
TextMessage.Streamed(textStream) =>  textStream.runFold("")(_ + _)  
  case _ =>  throw new Exception("unexpected binary message")  
}).mapAsyncUnordered(1)(identity)*


This flow is attached to webSocketClientFlow output.

An alternative solution would be looking up websocket buffering settings 
and jacking it up enough to receive all messages as Strict :)

cheers,
Rafał

W dniu poniedziałek, 10 października 2016 12:43:20 UTC+2 użytkownik Narayan 
Kumar napisał:
>
> thanks  for quick reply rafal .
> Yes you hav mentioned right , I am getting the 'message does no arrive'  , 
> but not any exception .
>
> I have tried with  the TextMessage.Streamed , but no progress from here 
> also . Please find the code below : -
>
> case TextMessage.Streamed(stream) => {
>   stream
> .limit(1) // Max frames we are willing to wait for
> .completionTimeout(50 seconds) // Max time until last frame
> .runFold("")(_ + _) // Merges the frames
> .flatMap { msg =>
>   logger.info("Getting streamed message " + msg)
>   val action = (parse(msg) \ (ACTION)).extractOpt[String]
>   if (action.isDefined) {
> action.get match {
>   case UPDATE_USER_PROFILE =>
> val userProfile = parse(msg).extractOpt[UserProfileJson].get
> val cover = userProfile.cover
> val picture = userProfile.picture
> val uploadCoverFile = 
> FileUploadUtility.decodeBase64String(cover.get)
> val uploadPictureFile = 
> FileUploadUtility.decodeBase64String(picture.get)
> println(" 1 " + uploadCoverFile + " @@@  2 " 
> + uploadPictureFile)
> Future(TextMessage("File Uploaded"))
>   case _ => Future(TextMessage(INVALID_ACTION))
> }
>   } else {
> Future(TextMessage(INVALID_ACTION))
>   }
> }
> }
>
>
>
> Also I cannot test the case  properly cause the web socket client gets 
> hang's every time I send the large file Json.,
> and using the above code also we are not getting any response back . 
> Please can you suggest any possible way to handle the scenarios.
>
>
> Thanks in advance , waiting for positive early reply :) .
>
>
>
> On Monday, October 10, 2016 at 3:12:36 PM UTC+5:30, Rafał Krzewski wrote:
>>
>> Please elaborate on "unable to handle it" -- are you getting an 
>> exception, message does no arrive, something other?
>> Also it would be helpful if you showed your code for TextMessage.Streamed 
>> case because that's how large messages would show up. 
>> I don't know the specifics but there appears to be a buffer in Akka 
>> WebSockets client code: if the incoming message fits into this buffer in 
>> full it's sent to the client code as Strict message, but when the message 
>> is too large to fit in the buffer Akka switches to streaming mode: Streamed 
>> message is sent to client code, carrying a stream that will deliver the 
>> message contents in buffer-sized chunks.
>>
>> Cheers,
>> aRafał
>>
>>
>> W dniu poniedziałek, 10 października 2016 08:21:14 UTC+2 użytkownik 
>> Narayan Kumar napisał:
>>>
>>>
>>>
>>> On Friday, October 7, 2016 at 7:52:03 PM UTC+5:30, √ wrote:
>>>>
>>>> Why are you assuming that it is a Strict message?
>>>>
>>>> On Fri, Oct 7, 2016 at 2:11 PM, Narayan Kumar <nar...@knoldus.com> 
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>> Actually i was trying to handle a Web Socket message for base64 
>>>>> encoded string of 10mb file.but unable to handle it.
>>>>> is there any way to handle large message please suggest ?
>>>>>
>>>>> Here is the code:
>>>>>
>>>>> def mediaUploadHandler: Flow[Message, Message, _] = {
>>>>> val (accountSource, accountQueue) = sourceQueue
>>>>> Flow[Message]
>>>>>   .collect {
>>>>> case TextMessage.Strict(txt) ⇒ {
>>>>>   logger.i

Re: [akka-user] How to handle web socket message to upload base64 encoded string of 10mb file

[Rafał Krzewski]

Please elaborate on "unable to handle it" -- are you getting an exception, 
message does no arrive, something other?
Also it would be helpful if you showed your code for TextMessage.Streamed 
case because that's how large messages would show up. 
I don't know the specifics but there appears to be a buffer in Akka 
WebSockets client code: if the incoming message fits into this buffer in 
full it's sent to the client code as Strict message, but when the message 
is too large to fit in the buffer Akka switches to streaming mode: Streamed 
message is sent to client code, carrying a stream that will deliver the 
message contents in buffer-sized chunks.

Cheers,
aRafał


W dniu poniedziałek, 10 października 2016 08:21:14 UTC+2 użytkownik Narayan 
Kumar napisał:
>
>
>
> On Friday, October 7, 2016 at 7:52:03 PM UTC+5:30, √ wrote:
>>
>> Why are you assuming that it is a Strict message?
>>
>> On Fri, Oct 7, 2016 at 2:11 PM, Narayan Kumar  wrote:
>>
>>> Hi everyone,
>>> Actually i was trying to handle a Web Socket message for base64 encoded 
>>> string of 10mb file.but unable to handle it.
>>> is there any way to handle large message please suggest ?
>>>
>>> Here is the code:
>>>
>>> def mediaUploadHandler: Flow[Message, Message, _] = {
>>> val (accountSource, accountQueue) = sourceQueue
>>> Flow[Message]
>>>   .collect {
>>> case TextMessage.Strict(txt) ⇒ {
>>>   logger.info(s"${phoneNumber}: Got the request. Now 
>>> redirecting to account api ")
>>>   val userProfile = parse(txt).extractOpt[UserProfileJson]
>>>   println("user profile is ", userProfile)
>>> }
>>> 
>>> case _ => TextMessage(INVALID_ACTION)
>>>   }
>>>   .via(connectSource(accountSource)) // ... and route them through 
>>> the receiveNotification ...
>>>   .map {
>>>   case msg: String ⇒ {
>>> info(s"Huhh !! Why I am getting this message ${msg}")
>>> TextMessage.Strict(msg)
>>>   }
>>> }
>>>   }
>>>
>>>
>>> Thanks 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+...@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,
>> √
>>
>
>
>
> Actually i have applied both approach of akka-http websocket 
> "TextMessage.Strict(txt)" and "TextMessage.Streamed(stream)",but both 
> approach didn't work.
> is there is another approach to handle it please suggest ?
>
>
>
>
>
>
>
>  
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: Organizing Route Directives

[Rafał Krzewski]

I'm not familiar with Java API but my impression is that AllDirectives is a 
device for bringing all pre-defined directives in scope of your Route 
producing functions.
Routes themselves are values and you can combine them to produce more 
complex routes. For example you could have several classes extending 
AllDirectives containing methods that produce Route values.
Such methods could take other Routes as parameters, to support nesting and 
references to "services" needed to implement route's functionality 
(ActorRefs and so on).
Then you could have a function that constructs all the partial routes and 
wires them together to produce the root route of your application.

Hope that helps,
Rafał

W dniu środa, 5 października 2016 18:11:17 UTC+2 użytkownik 
jpste...@skydance.com napisał:
>
> Now that i'm finally getting the hang of creating routes for akka http i'm 
> discovering that I need a good way to organize everything. What is the 
> recommended way to organize custom directives for routes into different 
> files (specifically in Java)?
>
> Ideally i'd like to be able to define custom directives that handle 
> processing of my REST API in an increasingly more complex fashion. So the 
> primary route will capture large buckets of url's based on a sub-system and 
> then hand off the additional work to other directives defined in other 
> classes for further processing. However from what I can tell this isn't 
> possible, is it?
>
> If I put everything in one file I am afraid it's going to get crazy out of 
> hand with thousands of lines of code and possibly hundreds (ouch!) of 
> directives and the class structure of AllDirectives is a little unnerving 
> since it's one massive chain of single inheritance. That means i'd have to 
> constantly be refactoring my chain of inheritance in order to add new 
> systems to the API (more ouch!).
>
> How does everyone handle this organization?
>
> Jean-Philippe
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 cookie from HttpResponse

[Rafał Krzewski]

Here's an example that you can 
try: https://gist.github.com/rkrzewski/46641359761eaa605fd62191b96b4416 
(you can run it using akka.Main)

Cheers,
Rafał

W dniu środa, 17 sierpnia 2016 20:56:21 UTC+2 użytkownik Sarah Yin napisał:
>
> Thanks for your reply. However the set-cookie does not contain the cookie 
> value I'm looking for. 
>
> Here's the one I've implemented in python which can retrieve the cookie 
> value.
>
>> cookie_jar = cookielib.CookieJar() 
>> non_redirecting_opener = urllib2.build_opener(NoRedirectionProcessor, 
>> urllib2.HTTPCookieProcessor(cookie_jar))
>> response = non_redirecting_opener.open(request)
>> cookies = {cookie.name: cookie for cookie in cookie_jar}
>
>
>
> On Wednesday, August 17, 2016 at 6:59:52 AM UTC-7, Rafał Krzewski wrote:
>>
>> If you are acting as the client, you should be looking at Set-Cookie 
>> header in the response, no?
>>
>> import akka.http.scaladsl.model.headers._
>> val cookies: Seq[HttpCookie] = response.headers.collect {
>>case `Set-Cookie`(cookie) => cookie
>> }
>>
>> or if you are expecting exactly one
>>
>> val cookie: Option[HttpCookie] = 
>> response.header[`Set-Cookie`].map(_.cookie)
>>
>> (I'm shooting of the hip here, sorry if it doesn't compile ;))
>>
>> HTH,
>> Rafał
>>
>> W dniu środa, 17 sierpnia 2016 08:28:24 UTC+2 użytkownik Sarah Yin 
>> napisał:
>>>
>>> Hi Akka User List,
>>>
>>> I'm trying to retrieve a cookie from akka HttpReqeust and get a 
>>> HttpResponse as a response.
>>>
>>> However, in my response I cannot find the cookie values. 
>>>
>>> response.getHeader("Cookie")
>>>
>>> Just prints Option.Empty
>>>
>>> Has anyone got any idea how to retrieve cookie from HttpResponse? Thanks 
>>> in ad!
>>>
>>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 cookie from HttpResponse

[Rafał Krzewski]

If you are acting as the client, you should be looking at Set-Cookie header 
in the response, no?

import akka.http.scaladsl.model.headers._
val cookies: Seq[HttpCookie] = response.headers.collect {
   case `Set-Cookie`(cookie) => cookie
}

or if you are expecting exactly one

val cookie: Option[HttpCookie] = response.header[`Set-Cookie`].map(_.cookie)

(I'm shooting of the hip here, sorry if it doesn't compile ;))

HTH,
Rafał

W dniu środa, 17 sierpnia 2016 08:28:24 UTC+2 użytkownik Sarah Yin napisał:
>
> Hi Akka User List,
>
> I'm trying to retrieve a cookie from akka HttpReqeust and get a 
> HttpResponse as a response.
>
> However, in my response I cannot find the cookie values. 
>
> response.getHeader("Cookie")
>
> Just prints Option.Empty
>
> Has anyone got any idea how to retrieve cookie from HttpResponse? Thanks 
> in ad!
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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] List of defined rest api's in akka-http based application

[Rafał Krzewski]

Please note that route definitions may contain arbitrary code including 
calling methods that produce route fragments.
The only way to introspect the definitions is by using macros, but still I 
don't think it's possible to do correctly it in all cases.

Cheers,
Rafał

W dniu środa, 6 lipca 2016 07:51:34 UTC+2 użytkownik Yadukrishnan K napisał:
>
> Thanks.
>
> I had already read about the akka-http support for swagger. But was 
> wondering, if akka-http itself provide any methods to get the defined 
> api's. 
>
> On Monday, July 4, 2016 at 8:33:53 AM UTC+5:30, Siva Kommuri wrote:
>>
>> Hmm, by introspection - not sure. 
>>
>> You may want to look at swagger support for akka http. The definitions 
>> are explicit though. 
>>
>> Best wishes,
>> Siva on 6+
>>
>> On Jun 29, 2016, at 11:44 PM, Yadukrishnan K  wrote:
>>
>> Thats just akka-http example right. What I want is to get all the defined 
>> urls/services at runtime so that I can make a registry of all the services 
>> I have.
>>
>> On Thursday, June 30, 2016 at 11:29:48 AM UTC+5:30, Siva Kommuri wrote:
>>>
>>> Yes, please see: 
>>> http://doc.akka.io/docs/akka/2.4.7/scala/http/routing-dsl/index.html#long-example
>>>  
>>>
>>>
>>> On June 29, 2016 at 2:35:39 AM, K Yadukrishnan (yada...@gmail.com) 
>>> wrote:
>>>
>>> This may be a very stupid question.
>>>
>>> Is it possible to get all the defined rest services urls in a akka-http 
>>> based application ?
>>>
>>> For eg: Assume that I have Employee Rest, Department Rest, Company Rest 
>>> etc defined, each with say 5 types of urls.
>>>
>>> GET /employees
>>> GET /employees/{id}
>>> POST /employees
>>> GET /departments
>>> GET /departments/{id}
>>>
>>> etc
>>> etc
>>>
>>> In another application(say reporting-engine), I want to list out all the 
>>> possible rest url's for use. So the client can use all the available rest 
>>> services and build the required reports.
>>>
>>> Is there anyway in akka-http, that I can get all the defined urls and 
>>> their Methods ?
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to 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+...@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: Dedicated seed nodes for akka cluster

[Rafał Krzewski]

There are ways to boot up Akka cluster without dedicated seed node: 
whichever node comes up first becomes the seed of the cluster and lets in 
the other nodes. An external KV is used to perform the initial coordination.
Take a look at: https://github.com/hseeberger/constructr 
and https://github.com/rkrzewski/akka-cluster-etcd

Cheers,
Rafał

W dniu piątek, 18 marca 2016 00:13:51 UTC+1 użytkownik Christian 
Hoffmeister napisał:
>
> Hello,
>
> I am just starting to dive into akka-cluster and have a question regarding 
> the seed nodes:
>
> My test project consists of 4 projects so far:
>
> * PROTOCOL contains messaging case classes
> * API contains cluster node, that also exposes a rest api (akka-cluster + 
> akka-http)
> * AUTH contains cluster node for auth stuff (akka-cluster)
> * USERS contains cluster node to manage user data (akka-cluster)
>
> At the moment I just set one API and one AUTH instance as seed nodes 
> (could also have been some other nodes). Is it good practice to have 
> another special project (called SEED), that does not do anything in 
> particular,
> except for joining the cluster, to act as seed node?
>
> From my first thoughts, this might be a good idea, since this nodes would 
> have to be restarted less often then other nodes (that have business 
> logic). Basically only when updating infrastructure like host machine or 
> akka.
>
> Am I getting something wrong here?
>
> Greetings
> Christian
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 ActorPublisher without ActorSubscriber

[Rafał Krzewski]

Your actor is supposed to receive ActorPublisherMessage.Request message 
after the stream is materialized. At this point totalDemand should be > 0 
and you are allowed to call onNext

Can you show the code of your publisher actor?

Cheers,
Rafał

W dniu środa, 9 marca 2016 13:48:27 UTC+1 użytkownik Simão Mata napisał:
>
> Hello,
>
> I think I misunderstand the usage of ActorPublisher. I read the 
> documentation (
> http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.3/scala/stream-integrations.html#ActorPublisher)
>  
> but I cannot seem to understand how to use it.
>
> I am creating an ActorPublisher actor and creating a Source like this:
>
> val source = Source.actorPublisher(publisherProps)
>
> I then connect this source to a sink and run it: 
> source.runWith(Sink.ignore). But debugging the actor I can see that 
> totalDemand is always 0, so the actor never calls `onNext`. So what should 
> update the demand on the actor? Do I always have to connect an 
> ActorPublisher to an ActorSubscriber so that demand in ActorPublisher is 
> updated properly?
>
> Thank you.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 java 2.4.2] creating a flow sending elements of the stream to given actorRef and pushing results back to stream

[Rafał Krzewski]

You're welcome! I'm glad you managed to solve this puzzle :)

W dniu środa, 9 marca 2016 15:00:06 UTC+1 użytkownik paweł kamiński napisał:
>
> beware of singletons in spring :] be lazy be prototype ;]
> so updater ref for second connection was never created and then ask got 
> invalid ref or something like that because eventually messages were sent to 
> updater actor but from deadletter :)
>
> thanks for help :)
>
> On Wednesday, 9 March 2016 01:41:02 UTC+1, paweł kamiński wrote:
>>
>> thanks, for all help. 
>>
>> it is running for ever as I am testing concepts of updating a remote 
>> client asynchronously, in real time Updater will get updates from other 
>> actors and yes I will add supervision strategies.
>> Im running this app from unit tests that creates spring context and also 
>> http-serwer/actors along so maybe there is something funny going on. I ve 
>> never integrated akka with existing spring-based aps but this is just a 
>> proof of concept and I have almost identical app running both spring mvc 
>> with netty :) I ll dump logs to a file this way it should be easier to 
>> follow the flow.
>>
>> On Tuesday, 8 March 2016 23:33:38 UTC+1, Rafał Krzewski wrote:
>>>
>>> W dniu wtorek, 8 marca 2016 23:10:38 UTC+1 użytkownik paweł kamiński 
>>> napisał:
>>>>
>>>> but this is impossible to change concurrently as I log it and then pass 
>>>> to Pattern#ask. I just wonder why it is send from 
>>>> *akka://akka-system/deadLetters* and why *ReceiveTimeout* is not sent 
>>>> back to Updater...
>>>>
>>>> Oh, that's right! A message sent without specifying a sender (like when 
>>> you are invoking ActorRef.tell from outside an actor) originates from 
>>> deadLetters, but message from an ask should originate from /temp/$ 
>>>  Something really weird is going on here.
>>>
>>> Regarding the ReceiveTimeouts, The log entries are 25 minutes later, and 
>>> log format is different - I don't know what to make of that. Two different 
>>> program runs with configuration change in between? That would explain why 
>>> serial # of B1 actor is different. Otherwise I don't see why should it be 
>>> restarted, as the Updater actor appears to run "forever", unless you are 
>>> terminating it somehow from the outside (in the code not shown here). If 
>>> the actor crashed with an exception in receive, you'd notice that in the 
>>> log. Also you'd probably have to configure appropriate supervisionStrategy 
>>> in updater's actor parent to restart it.
>>>
>>>  
>>>
>>>> the application I try to put together is a proof of concept and there 
>>>> is no use to use scala at this point.
>>>>
>>>> Well, it's a matter of what you are comfortable using. It would be much 
>>> shorter in Scala, and easier to read for some people, but harder for others 
>>> :) Neither am I suggesting that rewriting it in Scala would fix the problem 
>>> at hand.
>>>
>>> Cheers,
>>> 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] Re: [akka java 2.4.2] creating a flow sending elements of the stream to given actorRef and pushing results back to stream

[Rafał Krzewski]

949 DEBUG 69545 --- 
> [akka-system-akka.actor.default-dispatcher-4] actors.RequestRouter : 
> Handling request. http://localhost/budgets?id=B12
> 2016-03-08 18:10:33.949  INFO 69545 --- 
> [akka-system-akka.actor.default-dispatcher-14] actors.Updater: 
> Actor[akka://akka-system/user/B1#857515287] : Received from 
> Actor[akka://akka-system/temp/$r0] new update request 'B1'
> 2016-03-08 18:10:33.949  INFO 69545 --- 
> [akka-system-akka.actor.default-dispatcher-4] actors.RequestRouter : 
> Using updater for B12 - Actor[akka://akka-system/user/B12#-1049418234].
> 2016-03-08 18:10:33.949  INFO 69545 --- 
> [akka-system-akka.actor.default-dispatcher-20] actors.Updater: 
> Actor[akka://akka-system/user/B1#857515287] : Received from 
> Actor[akka://akka-system/*deadLetters*] new update request 'B12'
>
> [INFO] [03/08/2016 18:34:28.709] 
> [akka-system-akka.actor.default-dispatcher-5] [akka://akka-system/user/B1] 
> Message [akka.actor.ReceiveTimeout$] from 
> Actor[akka://akka-system/deadLetters] to 
> Actor[akka://akka-system/user/B1#385306581] was not delivered. [2] dead 
> letters encountered. 
> [INFO] [03/08/2016 18:34:28.709] 
> [akka-system-akka.actor.default-dispatcher-5] [akka://akka-system/user/B1] 
> Message [akka.actor.ReceiveTimeout$] from 
> Actor[akka://akka-system/deadLetters] to 
> Actor[akka://akka-system/user/B1#385306581] was not delivered. [3] dead 
> letters encountered. 
>
> I wonder why I get message from *deadLetters *and why it is sent to* B1 
> *actor. 
> the result is that computed messages for B12 will be never sent back. also 
> requested timeouts messages are not delivered :/ I ve messed this up :)
>
> On Tuesday, 8 March 2016 14:20:16 UTC+1, paweł kamiński wrote: 
>
>> ok, I was playing around with this yest. there is no way to do that. 
>>
>> only mapAsync is a way to create a flow that pushes elements of the 
>> stream to 3rd party components such as actors. 
>> this is a bit confusing as there is a ActorPublisher that would be good 
>> fit here if only Flow had a construct like Source.actorPublisher() / Sink
>> .actorRef(). this way we could pass Props of publisher which would 
>> transform incoming messages into something else.
>>
>> On Monday, 7 March 2016 11:28:03 UTC+1, paweł kamiński wrote:
>>>
>>> yep, i'm now thinking about duplex flow so I can push incoming messages 
>>> to actorRef sink and then such actor would be a source. 
>>>
>>> I must say that constructing right flow is not an easy task if you do it 
>>> occasionally! :)
>>> maybe I ll share my findings once I get it working
>>>
>>> On Monday, 7 March 2016 10:43:26 UTC+1, Rafał Krzewski wrote:
>>>>
>>>> W dniu poniedziałek, 7 marca 2016 10:08:23 UTC+1 użytkownik paweł 
>>>> kamiński napisał:
>>>>
>>>>> thanks for response.
>>>>>
>>>>> well ask pattern is a way to go but I thought I could avoid it and use 
>>>>> only flow's connection.
>>>>>
>>>>> Akka gives you a rich choice of communication primitives and it's OK 
>>>> to mix and match them in a way that solves the problem at hand in most 
>>>> convenient way :)
>>>>  
>>>> Happy hacking!
>>>> 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] Re: change of Tech Lead

[Rafał Krzewski]

Twitter, very soon: "They told him to work on this new enterprise Java 
framework, so he flipped his s* and left! Death of Scala AND Akka imminent! 
Let's run around flailing our arms in panic!"

Seriously though, many thanks to Roland and best of luck with the new job!

Cheers,
Rafał 

W dniu poniedziałek, 7 marca 2016 18:42:32 UTC+1 użytkownik rkuhn napisał:
>
> Dear fellow hakkers,
>
> as of today I am passing on the baton of Akka Tech Lead @ Lightbend to 
> Patrik Nordwall. Don’t worry, I will stay around and keep working on Akka, 
> but it will no longer be my day job come April: I am co-founding actyx 
> —a new start-up in Munich that aims at bringing 
> reactive design principles to the IT behind industrial manufacturing—where 
> I will build and lead the engineering organization. It was always my plan 
> to solve concrete customer challenges once I have collected enough 
> experience with building the tools, and while I had not yet started looking 
> for an opportunity I could also not pass this one up when it presented 
> itself.
>
> Akka will be in good hands with Patrik and the rest of the team, he is as 
> passionate about distributed systems as I am and he is a much more 
> disciplined coder—not to mention that he joined the Akka team before any 
> other current member including myself. I am very grateful that I had the 
> chance to be part of this amazing team for the past 4.5 years and I have no 
> desire to leave this awesome community anytime soon.
>
> Regards,
>
> Roland
>
>
> Lightbend – Reactive apps on the JVM.
> twitter: @rolandkuhn
> 
>
>

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

[akka-user] Re: [akka java 2.4.2] creating a flow sending elements of the stream to given actorRef and pushing results back to stream

[Rafał Krzewski]

W dniu poniedziałek, 7 marca 2016 10:08:23 UTC+1 użytkownik paweł kamiński 
napisał:

> thanks for response.
>
> well ask pattern is a way to go but I thought I could avoid it and use 
> only flow's connection.
>
> Akka gives you a rich choice of communication primitives and it's OK to 
mix and match them in a way that solves the problem at hand in most 
convenient way :)
 
Happy hacking!
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] Re: [akka java 2.4.2] creating a flow sending elements of the stream to given actorRef and pushing results back to stream

[Rafał Krzewski]

Hej Paweł,

if I understand your use case correctly, mapAsync with an ask [1] inside 
should work just fine. You might want to introduce an coordinator actor 
that would deal with worker management, ie the HTTP flow sends message 
(using ask pattern) to coordinator, coordinator performs worker lookup / 
creation and forwards the message to worker, worker replies directly to the 
temporary actor handing the ask, thus completing the Future. In the next 
stage, just marshall the data to a HttpEntity and your're done.

Cheers,
Rafał

[1] 
http://doc.akka.io/japi/akka/2.4.2/akka/pattern/AskSupport.html#ask-akka.actor.ActorRef-java.lang.Object-akka.util.Timeout-


W dniu niedziela, 6 marca 2016 23:25:07 UTC+1 użytkownik paweł kamiński 
napisał:
>
> hi,
> I have a simple HTTP service that accepts connections and keeps them 
> alive. 
> Once client sends something I look-up actorRef (WORKER) based on 
> path/query of request and I would like to wait for response from such actor 
> so I can respond back to client. 
>
> this is server to server communication so there should be one connection 
> per machine but there will be situation where same path/query is sent by 
> more then one connection.
> (in other words one worker should be able to update more than one stream 
> created by accepted connection - if this is even possible).
> A worker can only produce result if other actor sent it data in first 
> place, worker cannot produce results by itself. I want a worker to 
> represent client in akka system. 
>
> The problem I am facing is that I cannot figure out how to create such 
> flow that gets HttpRequest and produces HttpResponse and in the middle 
> sends incoming request to actor and waits for response.
> so far I came with such code
>
> public void start() {
> Source serverSource = 
> Http
> .get(system)
> .bind(ConnectHttp.toHost("localhost", port), materializer);
>
> Flow failureDetection = 
> Flow
> .of(IncomingConnection.class)
> .watchTermination((_unused, termination) -> {
> termination.whenComplete((done, cause) -> {
> if (cause != null) {
> log.error("Connection was closed.", cause);
> }
> });
> return NotUsed.getInstance();
> });
>
> serverSource
> .via(failureDetection)
>
> // <--- send each new connection to actorRef
> .to(Sink.actorRef(connectionRouter, closeConnectionMsg)) 
> .run(materializer)
> .whenCompleteAsync((binding, failure) -> {
> if (failure != null) {
> log.error("Could not initialize connection.", failure);
> }
> }, system.dispatcher());
> }
>
>
> // ConnectionRouter receive definition
>
> receive(ReceiveBuilder
> .match(IncomingConnection.class, connection -> {
> Flow updateRequestFlow = Flow
>
> .of(HttpRequest.class)
>
> .map(request -> {
> String mime = request.getHeader(Accept.class)
>
> .map(HttpHeader::value)
>
> .orElse("application/json");
>
>
> if (!isAcceptable(mime)) {
>
> return HttpResponse.create()
>
> .withStatus(StatusCodes.NOT_ACCEPTABLE)
>
> .addHeader(RawHeader.create("Connection", 
> "close"))
>
> .addHeader(RawHeader.create("Content-Length", 
> "0"));
>
> }
>
>
> Query query = request.getUri().query();
>
> Optional idOp = query.get("id");
>
> if (!idOp.isPresent()) {
>
> return HttpResponse.create()
>
> .withStatus(StatusCodes.BAD_REQUEST)
>
> .addHeader(RawHeader.create("Connection", 
> "close"))
>
> .addHeader(RawHeader.create("Content-Length", 
> "0"));
>
> }
>
>
> String id = idOp.get();
>
> // <--- retrieve or create new worker based on ID (it is 
> limited set of ids)
>
> ActorRef worker = actorsMap.get(id);
>
>
> // NOW worker.tell(READY_TO_GET_DATA_MSG) should eventually 
> create some result that should be mapped to response
>
>
> byte[] bytes = toBytes(mime, RESULT_PRODUCED_BY_WORKER);
>
> String length = Integer.toString(bytes.length);
>
> return HttpResponse.create()
>
> .withStatus(StatusCodes.OK)
>
> .withEntity(HttpEntities.create(bytes))
>
> .addHeader(RawHeader.create("Connection", 
> "keep-alive"))
>
> 

[akka-user] Re: Stream Supervision.Stop handler

[Rafał Krzewski]

Hi Gary,

"completes with an error" in Reactive Streams sense. You might want to look 
at the 
specification https://github.com/reactive-streams/reactive-streams-jvm
The error can originate in the Source (any of the Sources in more complex 
stream graphs), or in any of the transformation steps. The information 
about the error travels downstream until it reaches the Sink (or sinks). 
Sinks usually provide a Future as their materialized value, and in case of 
completed with a Failure. This is how error manifests itself to the "world" 
outside of the stream. If your application's design is such that the stream 
is owned by an Actor and the Actor needs to restart itself in case of 
Stream's failure you need to "connect the wires" yourself.

Cheers,
Rafał

W dniu niedziela, 6 marca 2016 21:48:59 UTC+1 użytkownik Gary Struthers 
napisał:
>
> Stream supervision is similar but different to Actor supervision. I don't 
> see what I'm supposed to do when a stream triggers a Supervision.Stop. What 
> does it mean that a stream "completes with an error"? Where is the error? 
> If I create a stream in an Actor is the Actor the stream's supervisor? Or 
> how is it different?
>
> Thanks,
> Gary
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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.agent and multi-agent system

[Rafał Krzewski]

W dniu piątek, 4 marca 2016 05:25:34 UTC+1 użytkownik Manar Elkady napisał:
>
> Hi, 
> I want to know the contradiction between these sentences from the 
> documentation
>  "Agents are bound to a single storage location for their lifetime, and 
> only allow mutation of that location (to a new state) to occur as a result 
> of an action"and "The state of an Agent should be immutable."
>
> There is no contradiction. Agent is a sort of a mutable reference but the 
object referred to should be immutable by itself. Otherwise different 
threads could concurrently modify the object, with all possible adverse 
consequences. 
The general rule in Scala is that it's OK to have a val pointing to a 
mutable object (say, an ArrayBuffer) or a var pointing to an immutable 
object (say, a Seq), provided that you keep them exclusive to a single 
thread. However, when you find a var pointing to a mutable object, 
something is amiss.


One more question about the usage of a concrete subclass for the abstract 
> class Agent[T]. What does it mean? how can we use it?
>
>
I don't think it's designed to be subclassed. You can create instances 
using companion object's apply method and just use them, as scaladoc 
illustrates.
If I misunderstood your question, please elaborate.

Cheers,
Rafał


> Manar,
>
> On Monday, January 25, 2016 at 8:52:28 AM UTC+2, Manar Elkady wrote:
>>
>> Hi,
>>
>> While I am implementing a multi-agent system application, I investigate 
>> akka.agent.Agent and I didn't notice any relation between agent in akka and 
>> the well known multi-agent concepts. Could anyone has an idea about that?
>>
>>
>> Manar,
>>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 define materialized value

[Rafał Krzewski]

Arun,

a little correction:

val runnableGraph = 
source.viaMat(counter[Int])(Keep.right).toMat(sink)(Keep.both)

And subsequently:

val (counter, futureSum) = runnableGraph.run()

Graph outlets are always streams. You need to connect them to a Sink 
(through intervening Flows or more complex Graphs, as necessary) in order 
to create a RunnableGraph. Materialized values are the other things used to 
connect the RunnableGraph to the outside world that are *not* streams.

For example Sink.fold creates a stream element that is (obviously) a Sink. 
It does not have any stream outlets. However it provides a materialized 
value Future[U] that is completed when the Sink's inlet stream is 
exhausted. This is how a running stream can communicate it's successful 
completion or failure to the outside world.

Another example is Source.actorPublisher: you provide it with Props for an 
Actor that implements ActorPublisher contract. When materializing the 
stream, the Source will instantiate the Actor and return it's ActorRef as a 
materialized value. The Actor is internal to the stream but you can use the 
ActorRef as an interface from the outside world into the stream: send 
messages (using your own protocol) to be passed to the Source's outlet, 
according to demand from downstream. The tricky part is that such gateway 
Actor must manage buffering and/or backpressure on it's own!

Besides that, you can use materialized values to monitor stream execution 
from the outside, like in the Counter example above 
or https://github.com/akka/akka/pull/19836 or to interrupt a stream that 
would otherwise run for a long (or unlimited) 
time: 
https://github.com/rkrzewski/akka-cluster-etcd/blob/master/etcd-client/src/main/scala/pl/caltha/akka/streams/FlowBreaker.scala

Cheers,
Rafał

W dniu niedziela, 6 marca 2016 08:43:10 UTC+1 użytkownik Arun Sethia 
napisał:
>
> Thanks Rafal.
>
> Based on this I tried to make sample code, where I would like to count 
> number of elements being processed and their sum:
>
> val source = Source (1 to 5).filter(x=> x%2==0)
>
> val sink:Sink[Int, Future[Int]]=Sink.fold[Int,Int](0)(_ + _)
>
> val runnableGraph = source.via(counter[Int]).toMat(sink)(Keep.both)
>
> val result=runnableGraph.run()
>
>
> def counter[T]: Flow[T, T, Counter] = {
>   val internalCounter = new AtomicLong(0)
>   Flow[T].map{ elem ⇒
> internalCounter.incrementAndGet()
> elem
> }.mapMaterializedValue(_ ⇒ new Counter{
> override def get = internalCounter.get
>   })
> }
>
>
>
> 1. using Keep.both, result should able to return me count and sum, but it is 
> not?
>
> 2. How materialize values are different than "out"? I am not able to 
> visualize the difference between materialize values and out?
>
> Thanks 
> Arun
>
>
>
> On Saturday, March 5, 2016 at 6:02:56 PM UTC-6, Arun Sethia wrote:
>>
>> Hi,
>>
>> can some explain what does it mean of materialized value ? I have see 
>> documentation at 
>> http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.3/scala/stream-quickstart.html#transforming-and-consuming-simple-streams
>>  
>>
>> I am not sure how Flow can define materialize type, for example the 
>> following code has Input - Tweet, output - Int but Mat is Unit. I would 
>> like to see how someone can define Mat as Int or any example where Flow or 
>> source is defining Mat other than Unit.
>>
>> - val count: Flow[Tweet, Int, Unit] = Flow[Tweet].map(_ => 1)
>>
>>
>>
>> It is quite confusing for me to understand difference between "out"  and 
>> "Mat".
>>
>>
>> Thanks 
>>
>> As
>>
>>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 - Receiving a stream of messages after sending initial message

[Rafał Krzewski]

Hi Brandon,

I guess you are using the following method to respond WebSocket handshake:

UpgradeToWebSocket.handleMessagesWith(handlerFlow: Graph 
[FlowShape 
[Message 

, Message 
], 
_]): HttpResponse 


In this case, the flow is indeed one-to-one. For each incoming message only 
a single outgoing message is produced. However there other over variants 
that take a pair of streams:

UpgradeToWebSocket.handleMessagesWith(inSink: Graph 
[SinkShape 
[Message 
], 
_], outSource: Graph 
[SourceShape 
[Message 
], 
_]): HttpResponse 


This allows you to implement a many-to-one, one-to-many, unidirectional 
reader / writer or any arbitrary communication scheme you can think of. You 
could implement the logic in an Actor and then use a pair of ActorSubcriber 
+ ActorPublisher helpers to complete the required plumbing.

Here's an example of WebSocket usage in my toy 
project 
https://github.com/rkrzewski/akka-cluster-etcd/tree/master/examples/cluster-monitor/src/main/scala/pl/caltha/akka/cluster/monitor/frontend
 
(here the input and output channels serve different purposes and are 
independent of one another)

Cheers,
Rafał 

W dniu sobota, 5 marca 2016 18:24:43 UTC+1 użytkownik Brandon Bradley 
napisał:
>
> Hello,
>
> I have a websockets connection that continuously sends messages after I 
> send a particular message. I've followed the websockets client example. 
> But, I only get one message back. I believe this is because streams are 
> one-to-one. Is there a way to process messages received after sending an 
> initial message with akka-http? Or is this the wrong tool for the job.
>
> Cheers!
> Brandon Bradley
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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 define materialized value

[Rafał Krzewski]

Hi,
there are a few ways of doing that. Probably the simplest one is using 
Flow.mapMaterializedValue. Suppose you'd like to create a Flow that counts 
the elements that pass through it and makes the current count available 
through a "side channel":

  trait Counter {
def get: Long
  }

  def counter[T]: Flow[T, T, Counter] = {
val internalCounter = new AtomicLong(0)
Flow[T].map{ elem ⇒
  internalCounter.incrementAndGet()
  elem
 }.mapMaterializedValue(_ ⇒ new Counter{
   override def get = internalCounter.get
 })
  } 

Another way is using a GraphStageWithMaterializedValue while building a 
custom Flow / Sink / Source. Instead of returning a GraphStageLogic, like 
an ordinary GraphStage, you return a pair of GraphStageLogic and the 
materialized value.

Cheers,
Rafał

W dniu niedziela, 6 marca 2016 01:02:56 UTC+1 użytkownik Arun Sethia 
napisał:
>
> Hi,
>
> can some explain what does it mean of materialized value ? I have see 
> documentation at 
> http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.3/scala/stream-quickstart.html#transforming-and-consuming-simple-streams
>  
>
> I am not sure how Flow can define materialize type, for example the 
> following code has Input - Tweet, output - Int but Mat is Unit. I would 
> like to see how someone can define Mat as Int or any example where Flow or 
> source is defining Mat other than Unit.
>
> - val count: Flow[Tweet, Int, Unit] = Flow[Tweet].map(_ => 1)
>
>
>
> It is quite confusing for me to understand difference between "out"  and 
> "Mat".
>
>
> Thanks 
>
> As
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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-http complete either directive with status code parameter

[Rafał Krzewski]

Hi Constantin,

you got it _almost_ right! Just change the type of implicit from 
ToReponseMarshaller to ToEntityMarshaller and you are good to go.

RouteDirectives.complete expects a (m: ⇒ ToResponseMarshallable) but you 
are providing a (StatusCode, A) pair.
PredefinedToResponseMarshallers.fromStatusCodeAndValue can fix that, but it 
needs a ToEntityMarshaller[A] to fill the gap.

cheers,
Rafał

W dniu piątek, 4 marca 2016 14:01:50 UTC+1 użytkownik Constantin 
Gerstberger napisał:
>
> Hi,
>
> i' trying to build a custom directive which completes a *Future *of 
> *Either*. However, the following only works if i omit the status code 
> when completing the *Right* case (i.e. *complete(result)* ).
>
> def completeEither[A](successStatusCode: StatusCodes.Success, future: => 
> Future[Either[RequestError, A]])(implicit m: ToResponseMarshaller[A]) =
>   onSuccess(future) {
> case Right(result) =>
>   complete(successStatusCode -> result)
> case Left(BadRequest(message)) =>
>   complete(StatusCodes.BadRequest -> message)
> case Left(_) =>
>   complete(StatusCodes.InternalServerError)
>   }
>
>
> The compile error i get is: *Type mismatch, expected: 
> ToResponseMarshallable, actual: (StatusCodes.Success, A)*
> I understand what the error message means but not where it comes from. 
> Based on this post 
>  and due 
> to the implicit parameter, i'd assume that it should work.
>
> Could anyone explain what i'm doing wrong?
>
> Thanks & regards
> Constantin
>
>
>
>
>
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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: [stream] callback for stream lifecycle

[Rafał Krzewski]

There's an outstanding PR for a FlowMonitor stage that could be used for 
this purpose: https://github.com/akka/akka/pull/19836
You could also wrap a pair of those into a BidiFlow and combine their 
signals (Finished when both directions finish, Failed when a failure is 
signaled in either direction).

Cheers,
Rafał

W dniu piątek, 26 lutego 2016 21:35:51 UTC+1 użytkownik Ramin Alidousti 
napisał:
>
> Hi,
>
> I was wondering if I could register callbacks on a stream lifecycle. What 
> I'm trying to accomplish here is to detect when a stream completes either 
> successfully or with failure and take appropriate action.
>
> Thanks,
> Ramin
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to 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.