[akka-user][deprecated] Re: [akka-user] Announcing discuss.akka.io!

[Johan Andrén]

Sorry to hear that you dislike Discuss so much you won't be coming along 
there Alan.

I'd like to point out though that the decision to move to a forum was in 
fact not at something coming from a pointy haired boss but rather something 
we had discussed internally in the team for quite some while.

What we have found is that the lack of searching and categories and easy 
navigation on the mailing list made users, especially newcomers, ask the 
same questions over and over again. We in the core Akka team spend quite 
some time moderating and answering questions here and we want a tool where 
we (and others in the community ofc) can help as many users as possible 
with minimum effort. We think that the categories and tags etc. in discuss 
will help us do that. We also hope this will help reduce some of the noise 
in the Gitter channels.

In addition to that we also see synergies in bringing the Lagom and Play 
communities closer, this may be a bigger gain for those projects as they 
are to some extent built on top of Akka but it also brings benefits to the 
Akka community in growing it, hopefully leading to more people being able 
to help out and answer questions, that may previously have been lurking in 
the other two project mailing lists only.

I don't think this will change your mind, but felt that the picture you 
painted was a bit unfair and I wanted to clarify that this was a move 
driven by us engineers.

..
Johan Andrén
Akka Team

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>>>>>>>>> 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] ANNOUNCE: Akka 2.5.11 released

[Johan Andrén]

Dear hakkers,

We have just published a new patch release of Akka 2.5. This version 
contains a fix for a regression introduced in Akka 2.5.10 
<https://github.com/akka/akka/issues/24622> which made rolling upgrades of 
an Akka Cluster from version 2.5.9 to 2.5.10 impossible.

In total 2 issues were closed since 2.5.10. The complete list can be found 
on the 2.5.11 milestone on github 
<https://github.com/akka/akka/milestone/127?closed=1>. Credits For this 
release we had the help of 4 committers – thank you all very much!

commits  added  removed
  3197      104 Johan Andrén
  1 561 Filip
  1  45 Patrik Nordwall
  1  11 Ignasi Marimon-Clos
 

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.

Re: [akka-user] Cancel Actor job

[Johan Andrén]

I'm afraid we haven't gotten to porting it to Java yet.

--
Johan

On Monday, February 5, 2018 at 8:40:03 AM UTC+1, Richard Gong wrote:
>
> Thanks Johan. It looks very good. Is there any Java version? I found one 
> on git hub: 
> https://github.com/typesafehub/activator-akka-distributed-workers-java, 
> yet it's an old version 2 years ago and the api being used are obsoleted.
>>
>>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Want to always receive latest element in Sink

[Johan Andrén]

You should be able to allow a faster upstream to continue, while emitting 
the latest value whenever downstream is read with conflate like so:

Source(0 to 1000) 
  .throttle(10, 1.second, 1, ThrottleMode.shaping) // fast upstream
  .conflate((in, prev) => in) // keep the latest value
  .throttle(2, 1.second, 1, ThrottleMode.shaping) // slow downstream 
  .runForeach(println)


--

Johan

Akka Team


On Wednesday, February 7, 2018 at 1:56:11 PM UTC+1, Arnout Engelen wrote:
>
> Hello Saloni,
>
> I think it would be helpful to have a more realistic example than doing 
> "Thread.sleep(1000)" in the sink.
>
> Could we unpack what this sleep is intended to mimic in your 'real' 
> application? Is it for example doing CPU-intensive data parsing or perhaps 
> some kind of IO?
>
>
> Kind regards,
>
> Arnout
>
> On Thu, Jan 25, 2018 at 7:27 AM,  wrote:
>
>> Hello,
>>
>> We are having a requirement that if a consumer is slower than producer 
>> then discard all the elements that cannot be consumed and whenever the 
>> consumer gets ready, feed the latest element from producer.
>>
>> We tried an approach as follows:
>>
>> Source.actorRef(0, OverflowStrategy.dropHead)   // actor receives 
>>> data at every 10 milliseconds
>>
>> .runWith {
>>>println("data received")
>>>Thread.sleep(1000)   // mimic consumer processing data in 
>>> every 1 second
>>> }
>>
>>
>> We shrank the buffer size to 1 (minimal possible) with following settings
>>
>> private val actorMaterializerSettings = ActorMaterializerSettings(
>>> actorSystem).withInputBuffer(1, 1)
>>
>>
>> With this buffer size, Sink pulls data 1 to consume and data 2 to put in 
>> buffer at initialization.
>>
>> While data 1 is getting processed we are dropping data from producer.
>>
>> When data 1 gets processed after 1000 milliseconds (1 second) ideally I 
>> should receive data 10 (and drop 2 - 9 as consumer is slow) but instead I 
>> receive data 2 from the buffer. data 2 in our domain is extremely useless 
>> as it is stale.
>>
>> Is there a way to disable buffer at Sink totally and always pull latest 
>> data from 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.
>>
>
>
>
> -- 
> Arnout Engelen
> *Senior Software Engineer*
> E: arnout.enge...@lightbend.com
> T: https://twitter.com/raboofje
>
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Announcement: Akka 2.5.9 released and Akka 2.4.x End of Life

[Johan Andrén]

Dear hakkers,

We are pleased to announce a new patch release of Akka 2.5. This release 
mostly contains small fixes across the board and our continued work on Akka 
Typed. Some notable improvements and bug fixes in 2.5.9 are:

   - Update to Aeron 1.7.0 for Artery #24169 
   <https://github.com/akka/akka/issues/24169>
   - Optimizations of Cluster Sharding #24064 
   <https://github.com/akka/akka/issues/24270> and #24191 
   <https://github.com/akka/akka/issues/24191>
   - New top-level protobuf serializer for Address #24265 
   <https://github.com/akka/akka/issues/24265>
   - Provide a fail-fast on version number too low for libraries #24030 
   <https://github.com/akka/akka/issues/24030>
   - Graceful handover when cluster client receptionist shuts down #24179 
   <https://github.com/akka/akka/issues/24179>
   - Add overload with Function0 predicate to ReceiveBuilder #15446 
   <https://github.com/akka/akka/issues/15446>

A total of 42 issues were closed since 2.5.8. The complete list can be 
found on the 2.5.9 
<https://github.com/akka/akka/milestone/125?closed=1>milestone 
on github.
Akka 2.4.x End Of Life

Please be advised that Akka 2.4.x has reached its End Of Life (EOL) date as 
of 12/31/2017.

Upgrading to Akka 2.5.x from the 2.4.x series should be very simple, as 2.5 
keeps backwards binary compatibility, in accordance to our documented 
compatibility guidelines 
<http://doc.akka.io/docs/akka/current/scala/common/binary-compatibility-rules.html>
.

This especially means that guaranteed hotfixes for this branch will not be 
available after this point. We always recommend staying up to date with the 
latest release, which is currently Akka 2.5.9. When upgrading please make 
sure to utilize the migration documentation 
<https://doc.akka.io/docs/akka/current/project/migration-guide-2.4.x-2.5.x.html>
 as 
necessary.
Akka Typed

There are several breaking changes in the under-development “may change” 
Akka Typed module.

Our goal is to ship a production ready version of Akka Typed as soon as 
possible and therefore we have removed the new runtime implementation and 
initially only support running typed actors with the underlaying untyped 
actor system. See the Coexistence blog post 
<https://akka.io/blog/2017/05/06/typed-coexistence>.

Some major structural changes to Akka Typed have been done, such as 
splitting up in separate modules e.g. akka-actor-typed with package root 
akka.actor.typed, and akka-cluster-typedwith package akka.cluster.typed.

Akka Typed in 2.5.9 is not ready yet, and we will continue working on it 
the next few weeks with more expected breaking changes. If you are using 
Typed already and would prefer a single migration task you should stay on 
version 2.5.8 until we have completed these changes.
Credits

For this release we had the help of 24 committers – thank you all very much!

commits  added  removed
 18   7067 7853 Christopher Batey
  8717  576 Johan Andrén
  6   1101  966 Konrad `ktoso` Malawski
  6268   45 Patrik Nordwall
  5106   13 kerr
  4  5   21 Arnout Engelen
  3 43   16 Nafer Sanabria
  3  33 Philippus Baalman
  2  52 Ignasi Marimon-Clos
  11538 fredfp
  11052 lorenzhawkes
  1 39   29 Łukasz Drygała
  1 303 Pritam Kadam
  1  72 Sebastian Harko
  1  33 Sakthipriyan Vairamani
  1  33 Steffen Gebert
  1  22 Heiko Seeberger
  1  12 WangYifu
  1  11 Akinmolayan Olushola
  1  20 Josep Prat
  1  11 Shajahan Palayil
  1  11 Rebecca Grenier
  1  11 Manuel Bernhardt
  1  10 Ayush Mishra

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-Streams] MergePrioritized vs MergePreferred

[Johan Andrén]

That looks like a bug in MergePrioritized, please open an issue (if 
possible then a minimal repeater would be great).

--
Johan
Akka Team

On Friday, December 29, 2017 at 4:52:23 AM UTC+1, Sergii Sopin wrote:
>
> By using MergePreferred I mean sequence of them.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 osgi.ee capability expecting exact version=1.8.0_144 ?

[Johan Andrén]

Hi Brian,

I think this is accidental and I think we had the same accidental issue in 
Akka that was then fixed a while ago 
(https://github.com/akka/akka/issues/23795)

Please open a ticket in the Akka HTTP issue tracker for 
this. https://github.com/akka/akka-http/issues (and even better if you 
could make a PR fixing it)

--
Johan
Akka Team

On Thursday, December 7, 2017 at 7:01:29 PM UTC+1, Brian Kent wrote:
>
> Hello,
>
> I am using akka-http in an OSGi container. It looks like the bump from 
> 10.0.10 to 10.0.11 changed to a very specific Require-Capability: 
>
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> vs 
> Require-Capability: osgi.ee;filter:="(&(osgi.ee
> =JavaSE)(version=1.8.0_144))"
>
> I was wondering what is driving this change. It is causing me some 
> headaches in my OSGi setup and is keeping me from upgrading to .11.
>
> Thanks!
> Brian
>
> (using Scala 2.11, btw)
>

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

[akka-user] Akka 2.5.8 released!

[Johan Andrén]

Dear hakkers,

We are pleased to announce a new patch release of Akka 2.5. Some notable 
improvements and bug fixes in 2.5.8 are:

   - Memory leak fix and performance improvements for asynchronous 
   callbacks with feedback. #24046 
   <https://github.com/akka/akka/issues/24046> and #24109 
   <https://github.com/akka/akka/issues/24109>
   - Fix for Timer usage in PersistentActors #24076 
   <https://github.com/akka/akka/issues/24076>
   - A new Scala Sink for collecting arbitrary immutable collections #23917 
   <https://github.com/akka/akka/issues/23917> thanks to @nachinius 
   <https://github.com/nachinius>
   - Fix for dispatcher (and other) attributes on graphs created with 
   fromGraph #22911 <https://github.com/akka/akka/issues/22911>

A total of 38 issues were closed since 2.5.7. The complete list can be 
found on the 2.5.8 
<https://github.com/akka/akka/milestone/124?closed=1>milestone 
on github. Credits For this release we had the help of 23 committers – 
thank you all very much!

commits  added  removed
 11   1278  498 Johan Andrén
  9683   94 Patrik Nordwall
  5 23   11 Arnout Engelen
  4 59   36 Konrad `ktoso` Malawski
  3186   97 nachinius
  3116  149 Johannes Rudolph
  3 38   42 Christopher Batey
  2344   43 Richard Imaoka
  2 43   30 gosubpl
  2  72 Martynas Mickevičius
  1 51   51 Jonas Lantto
  1 654 ortigali
  1 32   32 Evgeny Veretennikov
  1 590 Heiko Seeberger
  1 352 mattsu
  1 263 Elijah Rippeth
  1 10   10 Philippus Baalman
  1 10   10 Lutz Huehnken
  1  77 Pavel Boldyrev
  1  36 Björn Antonsson
  1  22 Ivan Yurchenko
  1  11 Maciej Kaszubowski
  1  11 Oleg Skovpen

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: is Akka remoting good for communication to another Akka system ?

[Johan Andrén]

Akka Remoting is nowadays essentially there as an underlying layer for Akka 
Cluster, so use Akka Cluster instead of using Akka Remoting directly unless 
you have very specific reasons and a very good understanding of what 
problems you will have to solve when using remoting directly.

--
Johan
Akka Team

On Friday, December 1, 2017 at 2:47:10 PM UTC+1, gurpreet@gmail.com 
wrote:
>
> Johan,
>
> That means Akka remoting not useful for developers to build independent 
> component under one platform, so where we can use Akka remoting as you said 
> we should avoid !!.
>
> --
> Gurpreet
>
>
> On Friday, December 1, 2017 at 4:59:07 PM UTC+5:30, Johan Andrén wrote:
>>
>> Avoid using remoting directly and reach for Akka Cluster instead if you 
>> want to build a distributed system. 
>>
>> For isolated systems/services/microservices that you want connect a 
>> separate more explicit protocol (HTTP, gRPC or something along those lines) 
>> can be a better idea as it make a more clear cut between services and 
>> avoids the quite complicated task of making sure  each service to have a 
>> compatible version of Akka, Scala, third party libraries which could 
>> potentially force you to always deploy a new version of every service every 
>> time you want to upgrade one of them.
>>
>> --
>> Johan
>> Akka Team
>>
>> On Friday, December 1, 2017 at 11:50:26 AM UTC+1, Seoras Ashby wrote:
>>>
>>> akka remoting is fabulous for exchanging small messages. By default the 
>>> maximum-frame-size is 128000 bytes and messages larger than that size are 
>>> logged and dropped with akka.remote.OversizedPayloadException. You can tune 
>>> maximum-frame-size but you should keep it small since remoting is used for 
>>> core akka functionality such as cluster heartbeats. Larger messages will 
>>> hog the channel and cause problems. 
>>>
>>> If you have larger messages you either need to break them down into 
>>> smaller ones or look for an alternative protocol such as akka http or akka 
>>> streams.
>>>
>>> akka.remote.netty.tcp.maximum-frame-size
>>>
>>> If you google for 'akka maximum-frame-size' you'll find more background.
>>>
>>> Best wishes,
>>> Seoras
>>>
>>> On Friday, December 1, 2017 at 7:09:57 AM UTC, gurpreet@gmail.com 
>>> wrote:
>>>>
>>>> Guys,
>>>>
>>>> i am confused on akka remoting, need some good suggestions w.r.t Akka 
>>>> Remoting.
>>>>
>>>> I have multiple Akka system services running on different Machines, 
>>>> they are communication each other by using *Akka remoting*.
>>>> But i saw Akka's documentation, they are suggesting go for *akka-http* 
>>>> for communication. is it any problem with Akka-Remoting ? , if yes then 
>>>> how 
>>>> ?
>>>>
>>>>
>>>> Thanks,
>>>> Gurpreet
>>>>   
>>>>
>>>

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

[Johan Andrén]

Avoid using remoting directly and reach for Akka Cluster instead if you 
want to build a distributed system. 

For isolated systems/services/microservices that you want connect a 
separate more explicit protocol (HTTP, gRPC or something along those lines) 
can be a better idea as it make a more clear cut between services and 
avoids the quite complicated task of making sure  each service to have a 
compatible version of Akka, Scala, third party libraries which could 
potentially force you to always deploy a new version of every service every 
time you want to upgrade one of them.

--
Johan
Akka Team

On Friday, December 1, 2017 at 11:50:26 AM UTC+1, Seoras Ashby wrote:
>
> akka remoting is fabulous for exchanging small messages. By default the 
> maximum-frame-size is 128000 bytes and messages larger than that size are 
> logged and dropped with akka.remote.OversizedPayloadException. You can tune 
> maximum-frame-size but you should keep it small since remoting is used for 
> core akka functionality such as cluster heartbeats. Larger messages will 
> hog the channel and cause problems. 
>
> If you have larger messages you either need to break them down into 
> smaller ones or look for an alternative protocol such as akka http or akka 
> streams.
>
> akka.remote.netty.tcp.maximum-frame-size
>
> If you google for 'akka maximum-frame-size' you'll find more background.
>
> Best wishes,
> Seoras
>
> On Friday, December 1, 2017 at 7:09:57 AM UTC, gurpreet@gmail.com 
> wrote:
>>
>> Guys,
>>
>> i am confused on akka remoting, need some good suggestions w.r.t Akka 
>> Remoting.
>>
>> I have multiple Akka system services running on different Machines, they 
>> are communication each other by using *Akka remoting*.
>> But i saw Akka's documentation, they are suggesting go for *akka-http* 
>> for communication. is it any problem with Akka-Remoting ? , if yes then how 
>> ?
>>
>>
>> Thanks,
>> Gurpreet
>>   
>>
>

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

[Johan Andrén]

Dear hakkers,

We are happy to announce Akka Http 10.0.11, the eleventh release of the 
Akka Http 10.0 series. It marks the one year anniversary of the 10.0 
series. As a special present the community and Akka team worked together to 
add the long awaited akka-http-caching module inspired by spray-caching.

It also features a new implementation of the client pool infrastructure. 
This will allow us in the future to finally tackle many of the issues 
reported for the existing infrastructure like request timeouts, handling 
unread response entities, and other issues more easily.

In an ongoing behind-the-scenes effort, @jonas , 
@jlprat  and others continued to improve the 
structure of our documentation to consolidate Java and Scala documentation. 
This reduction in duplication of documentation content will allow us to 
make changes to the documentation more easily in the future. Thanks a lot!
New caching module, akka-http-caching

In a several month long effort members from the community and the Akka team 
discussed and implemented the long-awaited replacement of spray-caching. 
The new module akka-http-caching got quite an overhaul over spray-caching 
and is now backed by caffeine .

Thanks a lot, @tomrf1 , @jonas 
, @ben-manes , 
@ianclegg  for the fruitful discussions and 
for providing the implementation!

The caching API is currently marked with @ApiMayChange and thus may change 
based on feedback from real world usage. Some improvements are already 
planned to make it into future releases 
.
 
We hope further collaboration within the community will help us stabilize 
the API.

See the documentation 
 for 
more information.
Http Client Pool Infrastructure Rewrite

The existing host connection pool infrastructure has accrued quite a lot of 
issues that are hard to fix. Therefore, we decided to rewrite the old 
version which was based on a stream graph jungle with a new version 
implemented as a single GraphStage which will be easier to maintain. The 
new infrastructure already passes all the old tests and is now considered 
ready to be tested. The new implementation can be enabled with the feature 
flag akka.http.host-connection-pool.pool-implementation = new. One 
important feature that is available only with the new pool implementation 
is a new warning that will be shown if user code forgets to read or discard 
a response entity in time (which is one of the most prominent usage 
problems with our client API). If you experienced problems with the old 
implementation, please try out the new implementation and report any issues 
you find.

We hope to stabilize the new implementation as soon as possible and are 
going to make it the default in a future version.
Incompatible changes to akka.http.{java,scala}dsl.coding classes

To clean up internal code, we made a few incompatible changes to classes 
that were previously kept public accidentally. We now made those classes 
private and marked them as @InternalApi. Affected classes are 
akka.http.scaladsl.coding.DeflateDecompressorBase,
akka.http.scaladsl.coding.DeflateCompressor, and 
akka.http.scaladsl.coding.GzipCompressor. The actual codec APIs, Gzip and 
Deflate, are not affected. This is in violation with a strict reading of 
our binary compatibility guidelines. We still made that change for 
pragmatic reasons because we believe that it is unlikely that these classes 
have been used or extended by third parties. If this assumption turns out 
to be too optimistic and integration with third-party code breaks because 
of this, please let us know.
List of ChangesImprovementsakka-http-core
   
   - New host connection pool infrastructure (#1312 
   )
   - Allow disabling of parsing to modeled headers (#1550 
   )
   - Convert RFC references in documents in model classes to scaladoc (#1514 
   )
   - Allow configuration of default http and https ports (#1449 
   )
   - Remove unnecessary implicit materializer parameter in several 
   top-level Http entry point APIs (#1464 
   )
   - Add X-Forwarded-Proto and X-Forwarded-Host header models (#1377 
   )
   - Lookup predefined header parsers as early as possible (#1424 
   )

akka-http
   
   - Add multiple file upload directive (#1033 
   )
  

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

[Johan Andrén]

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] Re: FlowOps concat with Source.fromFuture behaviour

[Johan Andrén]

I opened https://github.com/akka/akka/issues/23044 a while ago to track the 
in my opinion surprising behaviour of concat doing an eager pull on the 
second input. As everything is fused by default nowadays, and you can add 
detach yourself, but you cannot remove detach when it's there, I think we 
should change the stage by removing the detach.

On Wednesday, October 25, 2017 at 12:01:41 PM UTC+2, Christopher Hunt wrote:
>
> Hey community,
>
> I've got a situation where there's a promise that, when completed, I'd 
> like to concat its value onto the *end* of any stream elements before it 
> i.e.:
>
> someSource.concat(Source.fromFuture(somePromise.future))
>
> What I'm noticing is that if the promise is completed then the promised 
> value doesn't wait for someSource to complete. Rather, it yields an element 
> near to the time that the promise was completed, seemingly ignoring any 
> further elements from someSource.
>
> This problem appears to be similar to 
> https://github.com/akka/akka/issues/22042, where flatMapConcat is 
> recommended. However, I'm not sure that flatMapConcat as its contract 
> appears to be different - I only want to concat elements when someSource is 
> complete. flatMapConcat appears to get called for each element from 
> someSource.
>
> Any further pointers in order to achieve the API description of concat in 
> conjunction with Source.fromFuture?
>
> Cheers,
> -C
>

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

[akka-user] Re: Multi-DC Clustering & Distributed Data

[Johan Andrén]

Hi Jeroen,

I saw now that you already commented on the ticket, but for completeness 
sake:

All nodes still participate in the same DD (unless you limit with 
akka.cluster.distributed-data.role)

We have ideas for optimising the gossip so that less inter-DC gossip 
happens, between fewer cross-DC pairs but nothing is implemented yet. 
Tracked by issue: https://github.com/akka/akka/issues/23249

--
Johan
Akka Team

On Monday, October 2, 2017 at 9:20:51 AM UTC+2, Jeroen Gordijn wrote:
>
> Hi,
>
> I read the release notes of 2.5.6 and saw the Multi-DC Clustering 
> 
>  
> which looks interesting. Going through the doc I see information about 
> Cluster Singleton and Cluster Sharding and how it behaves with this new 
> feature. I'm using Distributed Data and I am wondering if there are any 
> changes for that?
>
> More specific:
>
>- Do all nodes in all DC's still participate in the same DD, or is it 
>a DD set per DC?
>- If they still gossip all data to all nodes in all DC's: 
>- Is there a change in the gossip interval that differs between within 
>   DC and over DC?
>   - Do all nodes gossip to other DC? Or is it like the described in 
>   the failure detection that only the oldest nodes do it?
>   - Currently the gossip prefers reachable over unreachable nodes, 
>   does this now take unreachable DC into account?
>- Do you have any other info I missed with the questions above?
>
>
> Thanks in advance!
>
> Cheers,
>
> Jeroen
>

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

[Johan Andrén]

The "normal" way would be to have the same logic, but different 
unmarshalling, and this the unmarshalling infra takes care of, you'd use 
the entity directive 
https://doc.akka.io/docs/akka-http/10.0.10/scala/http/routing-dsl/directives/marshalling-directives/entity.html
 
and pass a super-marshaller created by passing the supported marshalers to 
`Unmarshalling.firstOf(json, text, binary)`. This isn't super obvious from 
the docs so there are some possible improvements here.

Here is a working sample that does exactly 
this: https://gist.github.com/johanandren/ab4b2df05004399298e900776690a0de

If you are not interested in this but actually want different logic to 
happen depending on the content type, then extracting the content type and 
matching is probably the way to go, note that you should still be able to 
make use of the unmarshalling infra for the individual sub-routes to get 
character encoding automagically handled.

--
Johan
Akka Team


On Monday, October 9, 2017 at 9:45:08 PM UTC+2, kr...@humio.com wrote:
>
> Hi,
>
> I've been trying to find an example that illustrates how to write a route 
> that follows different paths based on the Content-Type of a request.
>
> Clearly, I can extract the value of the "Content-Type" header, but then 
> there is the charset and everything to worry about in the resulting value.
>
> Basically I want to have a post { ... } rule, that do three different 
> things if the incoming data is text/plain (split it by newlines), 
> application/json (parse it as such). In both cases I would want to 
> unmarshall the data in the charset given by the client.  A third rule would 
> match the binary type application/x-vnd-foo would parse the incoming data 
> from ByteString.
>
> So how do I use all the akka niceties to write this "case statement" with 
> 3 different part-routes without having to extract and match the strings?
>
> The world seems to be full of examples of how to match 'Accept' rules to 
> response content types in akka, but nothing easy to find on the incoming 
> case.
>
> Thanks,
>
> Kresten
>
>

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

[Johan Andrén]

That seems to be an oversight, please open a ticket in the Akka HTTP issue 
tracker about the missing newHostConnectionPool variant that takes a 
ConnectionPoolSettings, thanks!

--
Johan
Akka Team

On Wednesday, October 11, 2017 at 1:42:34 PM UTC+2, Yoad Gidron wrote:
>
> I have been trying to use Akka HTTP Host Connection Pool in Java. 
> akka.http.javadsl.Http 
> class has 3 different signatures for the cachedHostConnectionPool() method. 
> After straggling with it for a while, I realised that one of these method 
> is using HTTPS, while the other 2 are using HTTP. There is nothing in the 
> method name or signature that implies that. Also, it ignores the protocol 
> that is defined in the ConnectHttp parameter. I find it strange, but maybe 
> I am missing something. 
> The issue is that only the HTTPS variant takes a ConnectionPoolSettings 
> parameter, so how would you control the settings for HTTP? Is it only in 
> configuration?  
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Implements CRDTs conters more than 100 000

[Johan Andrén]

>
> I have a big tree of business objects each of them contain counter and 
> threshold when threshold reach then object change its state.


This may also be a reason why Distrubed Data isn't a perfect fit to your 
problem, the CRDTs are eventually consistent, that means that the counter 
could have +n added separately on every node of your cluster but the other 
nodes does not see this right away, if you want to make sure you act on the 
threshold being reached only once and act differently for all requests 
after that it will not be possible with Distriubted Data but you would 
rather need to represent each entity as an actor (perhaps together with 
sharding) to achieve consistency.

--
Johan
Akka Team

On Thursday, October 12, 2017 at 10:04:06 PM UTC+2, Patrik Nordwall wrote:
>
> Might be some misunderstanding of terminology here. The quote from the 
> documentation is about Distributed Data. In last post I read it as you talk 
> about an actor tree. Anyway, in distributed Data you would use many 
> ORCounterMap as top level entries, and each such map would hold a number of 
> named counters. E.g. 1 maps with 100 counters each. If it actually 
> scales to these numbers is something you have to try.
>
> /Patrik
> tors 12 okt. 2017 kl. 15:08 skrev Hsnamed :
>
>> Yes , i saw that limitation and yes i have 1m top entities.  As example , 
>> there are four level of tree
>>
>> 1 - Category of markets groups
>> 2 - Markets group
>> 3 - Market - eg. Derivative
>> 4 - selection in market 
>>
>> Each market may have one or more positions .
>> If counter of selection reaches threshold - position change the state e.g 
>> diactivated
>>
>> I think about it as create actor system which equals the tree, because 
>> increments must be ordered  in selection context.
>>
>>
>>
>>
>>
>> четверг, 12 октября 2017 г., 15:41:14 UTC+3 пользователь Konrad Malawski 
>> написал:
>>>
>>> It’s as the docs explain: 
>>>
>>> It is not intended for *Big Data*. The number of top level entries 
>>> should not exceed 10. When a new node is added to the cluster all these 
>>> entries are transferred (gossiped) to the new node. The entries are split 
>>> up in chunks and all existing nodes collaborate in the gossip, but it will 
>>> take a while (tens of seconds) to transfer all entries and this means that 
>>> you cannot have too many top level entries. The current recommended limit 
>>> is 10. We will be able to improve this if needed, but the design is 
>>> still not intended for billions of entries.
>>> It depends on your data architecture though.
>>> Are you sure it would be 1 million actual top level entries?
>>>
>>> -- 
>>> Cheers,
>>> Konrad 'ktoso ' Malawski
>>> Akka  @ Lightbend 
>>>
>>> On October 12, 2017 at 21:24:37, Hsnamed (hsn...@gmail.com) wrote:
>>>
>> Hello, how can i implement 1 million CRDTs counters to use akka without 
>>> big disadvantage ? 
>>>
>>> I have a big tree of business objects each of them contain counter and 
>>> threshold when threshold reach then object change its state.
>>>
>>> Tree have more than 1 million objects. Does it possible to implements 
>>> using akka ? 
>>>
>>> Thanks for advices.
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>>
>>>
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails 

[akka-user] Re: Is there an Akka stream mapAsync equivalent for yielding a Source?

[Johan Andrén]

flatMapConcat or flatMapMerge is likely what you're looking for.

--
Johan
Akka Team

On Thursday, September 28, 2017 at 8:28:52 AM UTC+2, Christopher Hunt wrote:
>
> Hey everyone,
>
> Given that mapAsync yields a Future, I was looking for a similar type of 
> stage that yields a Source instead. My goal is to direct the flow's input 
> to an in-process actor and then have that actor feedback its reply as a 
> Source (the reply is most certainly a stream).
>
> Thanks for any guidance.
>
> Kind regards,
> Christopher
>

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

[Johan Andrén]

Hi,

We do not build a zip with all artifacts anymore as they are all published 
to Maven central. 

The "normal" way of using the library is through a build tool such as 
Maven, SBT or Gradle that will handle downloading the artefacts for you.

--
Johan
Akka Team

On Friday, September 22, 2017 at 8:11:57 AM UTC+2, axy...@gmail.com wrote:
>
> Hello ...  This is dumb, but after an hour of Googling™ around, I cannot 
> find any Windows install file for the latest Akka (for Scala), which 
> appears to be 2.5.4 .  If there's a link to it on the release announcement
>   http://akka.io/blog/news/2017/08/10/akka-2.5.4-released  then I'm 
> missing it.  I'm coming back to Akka after a while, my old installer was 
>  akka_2.11-2.4.1.zip  from late 2015.
>
> 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] Re: how can write and read async with socket (councurent) ?

[Johan Andrén]

You can see samples of the two APIs in the docs here:

Actor based API:
http://doc.akka.io/docs/akka/current/scala/io-tcp.html

Stream based API:
http://doc.akka.io/docs/akka/current/scala/stream/stream-io.html

If you are looking for info how to use the Java NIO APIs that is better 
sought after elsewhere.

--
Johan
Akka Team


On Wednesday, September 20, 2017 at 12:14:12 PM UTC+2, tech land wrote:
>
> And question this ?
> how i can write 'socket.write' asynchronously
> I must use the Future:
> for example :
>   Fututr{ socket.write(ByteString(date.toString("yy/MM/dd")) ++ EOL)} And 
> get callback ? 
> Or not It is not necessary and itself asynchronusly?
> ---
> On Thu, Sep 14, 2017 at 5:43 PM Akka Team  wrote:
>
>> The Akka IO API is actor based and a bit more low level, requiring more 
>> boilerplate, the streams one is a higher level API which fits some problems 
>> (and mindsets) very well. Performance will likely not differ much so try 
>> both and use the one you find easiest to understand and achieve what you 
>> want with.
>>
>> --
>> Johan
>> Akka Team
>>
>> On Wed, Sep 13, 2017 at 4:01 PM,  wrote:
>>
>>> Someone who can help me ???
>>>
>>> On Saturday, September 2, 2017 at 3:53:20 PM UTC+4:30, 
>>> techlan...@gmail.com wrote:
>>>
 hi every one 
 I'm using akka 2.5.x how can call Socket async for read and write 
 ?(what is the best solution)
 i need many connection concurrency for send email this is sample code 
 java ?

 public boolean sendEmail(String data, String from, String to,String 
 subject)
 throws IOException {
 Socket socket;
 InputStream inn;
 OutputStream outt;
 BufferedReader msg;
 socket = new Socket(mailHost, SMTP_PORT);
 if (socket == null) {
 return false;
 }
 inn = socket.getInputStream();
 outt = socket.getOutputStream();
 in = new BufferedReader(new InputStreamReader(inn));
 out = new PrintWriter(new OutputStreamWriter(outt), true);
 if (inn == null || outt == null) {
 log("Failed to open streams to socket.");
 return false;
 }
 String initialID = in.readLine();
 out.println("HELO " + localhost.getHostName());
 String welcome = in.readLine();
 out.println("MAIL From:<" + from + ">");
 String senderOK = in.readLine();
 out.println("RCPT TO:<" + to + ">");
 String recipientOK = in.readLine();
 out.println("DATA");
 out.println("From:Ehsan test<"+from+">");
 out.println("To:Ehsan uni<"+to+">");
 out.println("Cc:khodam <"+to+">");
 out.println("Subject:"+subject);
 Date d=new Date();
 out.println("Date:"+d.toString());
 // this body of email 
 out.println(data);
 out.println(".");
 // end of email 
 String acceptedOK = in.readLine();
 out.println("QUIT");
 return true;
 }
 }
 how can implement with akka ?
 how can write and read async ?
 could help me for this solution


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

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

[akka-user] Re: akka typed actor, slow "ask" with time exponentially increasing by the number of messages

[Johan Andrén]

400 asks in 5 seconds should be nowhere near the number of 
asks/request-responses you can run through a single typed actor. Likely 
something in your logic or in how you measure is not quite right. 
As a reference, with a naive ping-pong test I can do around ~170 asks per 
ms on my machine.

Profiler showing the scheduler as cpu hotspot means your system isn't 
really doing anything.

If you want more help, please share the complete microbenchmark.

--
Johan
Akka Team

On Friday, August 25, 2017 at 10:09:46 AM UTC+2, Kostas kougios wrote:
>
> Did a quick test commenting out the blocking .awaitFor(). So there was no 
> blocking call. But still it is too slow.
>

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

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

[Johan Andrén]

In many cases it may be a sign that something is wrong when there are no 
subscribers, for example because topic name was misspelled etc. Just like 
how other messages ending up in dead letter could indicate a problem but 
might be normal. 

It is also useful when debugging, if for example a subscription has not yet 
been gossiped to a node when a message is published to a topic. 

The feature was added in 2.4.5, here's the 
issue: https://github.com/akka/akka/issues/19009

I think we'd be open for a PR making this configurable, keeping the current 
behaviour as default. If you're not up for that then adding a dummy 
subscriber sounds like a possible solution.

--
Johan 
Akka Team

On Saturday, July 22, 2017 at 4:02:35 PM UTC+2, Rafał Sumisławski wrote:
>
> Hi,
>
> I was surprised to discover that the DistributedPubSub does not simply 
> forward a published message to all (0 or more) subscribers for a given 
> topic. There's a special case implemented to send the message to the 
> DeadLetter in case there are no subscribers for that topic (
> https://github.com/akka/akka/blob/9d2bec7f232b628cc087231af75e457072823e61/akka-cluster-tools/src/main/scala/akka/cluster/pubsub/DistributedPubSubMediator.scala#L716).
>  
> Sending these messages to DeadLetter makes it look like it's something 
> wrong, while IMO it's a perfectly valid and common use case for 
> publish-subscribe pattern to have 0 or more subscribers. I see value of 
> this behaviour during debugging, but it's strange that it's a default and 
> as far as I can see it can't be disabled. 
>
> What is the reason why DistributedPubSub is implemented this way?
>
> What is the best way to avoid published messages ending up in the 
> DeadLetter? Currently I'm spawning a fake subscriber actor (usually one per 
> node) for each topic I plan to publish some messages to.
>
> Best Regards
> Rafał
>

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

[akka-user] ANNOUNCE: Akka HTTP 10.0.4 released

[Johan Andrén]

Dear hakkers,

we — the Akka HTTP committers — are happy to announce the availability of 
the forth maintenance release of Akka HTTP 10.0.

This release is a monthly maintenance release which contains mostly bug 
fixes and smaller improvements.

We strongly recommend updating from 10.0.3 which introduced a regression 
that an Akka HTTP server can leak memory over time which will lead to OOM 
eventually. See #851  for 
more information.

In other news, the Akka Http Team 
 welcomes @jlprat 
 as an Akka Http committer!
List of ChangesImprovementsAKKA-HTTP-CORE
   
   - Http message and header parser now also accepts LF as end of line (as 
   recommended in the spec) (#106 
   )

AKKA-HTTP
   
   - HttpApp now directly extends from Directives (#875 
   )
   - Added HttpApp.startServer(host, port) for even simpler startup. (#873 
   )

AKKA-HTTP2-SUPPORT
   
   - Multiplexer infrastructure was rewritten to support plugable 
   StreamPrioritizer (not yet surfaced in user API) (f06ab40 
   )

DOCUMENTATION
   
   - New documentation page about how to deal with the client-side 
   max-open-requests exception (39f36dd 
   )
   - Lots of small cleanups and improvements

Bug fixesAKKA-HTTP-CORE
   
   - Fix a regression introduced in 10.0.3 that might lead to memory 
   leaking after a server connection has been closed. (#851 
   )
   - Fix the infamous “Cannot push/pull twice” bug which occurred in 
   relation with 100-Continue requests (like any kind of uploads of POST 
   requests done with curl) (#516 
   )

BUILD + TESTING INFRASTRUCTURE
   
   - Updated Akka dependency to Akka 2.4.17. (#858 
   )
   - Use .dilated for tests for better stability. (#194 
   )
   - Fix MiMa to actually check compatibility against the latest released 
   versions. (#870 )
   - Throughout the code base @InternalApi, @ApiMayChange, and @DoNotInherit 
annotations 
   have been added to give hints about the stability of interfaces. (#727 
   )

Binary Compatibility

Akka 10.0.x is backwards binary compatible 
 
with 
previous 10.0.x releases and Akka 2.4.x. This means that the new JARs are a 
drop-in replacement for the old one (but not the other way around) as long 
as your build does not enable the inliner (Scala-only restriction). It 
should be noted that Scala 2.12.x is is not binary compatible with Scala 
2.11.x.

Akka-Http will be binary and source compatible with the upcoming Akka 2.5 
release.
Credits

In this release we have closed 14 tickets 
, with the help of 
8 contributors– thank you all very much!

The complete list of closed tickets can be found on the 10.0.4 milestone 
 on github.

commits  added  removed
 12   1311  180 Johannes Rudolph
  9608  217 Josep Prat
  7272  588 Jonas Fonseca
  1 72   46 Gaëtan Rizio
  1  33 Elliot Wright
  1  40 Adam Anderson
  1  22 Nafer Sanabria
  1  11 Jordan Gwyn

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 with ActorPublisher Integration Serialization Issue

[Johan Andrén]

Looks like you have accidentally closed over a running stream in some 
object you are trying to send across the network/between nodes.

--
Johan
Akka Team

On Friday, February 17, 2017 at 9:59:39 AM UTC+1, T Z wrote:
>
> Hi,
>
> Does anyone have any idea on the cause of this error? I am integrating an 
> ActorPublisher into my streaming/chunk source response back to the client 
> but this exception is thrown. It looks to be an auto-generated message 
> within Akka Pub-Sub. Any help is greatly appreciated!
>
>  2017-02-17 08:34:52,408 
> ERROR[DelphiEngine-akka.actor.default-dispatcher-22] EndpointWriter - 
> Failed to serialize remote message [class 
> akka.stream.actor.ActorPublisher$Internal$Subscribe] using serializer 
> [class akka.serialization.JavaSerializer]. Transient association error 
> (association remains live)
>  akka.remote.MessageSerializer$SerializationException: Failed to serialize 
> remote message [class akka.stream.actor.ActorPublisher$Internal$Subscribe] 
> using serializer [class akka.serialization.JavaSerializer].
>   at akka.remote.MessageSerializer$.serialize(MessageSerializer.scala:61)
>   at 
> akka.remote.EndpointWriter$$anonfun$serializeMessage$1.apply(Endpoint.scala:895)
>   at 
> akka.remote.EndpointWriter$$anonfun$serializeMessage$1.apply(Endpoint.scala:895)
>   at scala.util.DynamicVariable.withValue(DynamicVariable.scala:58)
>   at akka.remote.EndpointWriter.serializeMessage(Endpoint.scala:894)
>   at akka.remote.EndpointWriter.writeSend(Endpoint.scala:786)
>   at akka.remote.EndpointWriter$$anonfun$4.applyOrElse(Endpoint.scala:761)
>   at akka.actor.Actor$class.aroundReceive(Actor.scala:497)
>   at akka.remote.EndpointActor.aroundReceive(Endpoint.scala:452)
>   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 scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
>   at 
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
>   at 
> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
>   at 
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>  Caused by: java.io.NotSerializableException: 
> akka.stream.impl.fusing.ActorGraphInterpreter$BoundarySubscriber
>   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
>   at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
>   at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
>   at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
>   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
>   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
>   at 
> akka.serialization.JavaSerializer$$anonfun$toBinary$1.apply$mcV$sp(Serializer.scala:321)
>   at 
> akka.serialization.JavaSerializer$$anonfun$toBinary$1.apply(Serializer.scala:321)
>   at 
> akka.serialization.JavaSerializer$$anonfun$toBinary$1.apply(Serializer.scala:321)
>   at scala.util.DynamicVariable.withValue(DynamicVariable.scala:58)
>   at akka.serialization.JavaSerializer.toBinary(Serializer.scala:321)
>   at akka.remote.MessageSerializer$.serialize(MessageSerializer.scala:47)
>   ... 17 common frames omitted
>

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

[akka-user] ANNOUNCE: Akka 2.3.16 released

[Johan Andrén]

*Dear hAkkers,*

We—the Akka committers—are pleased to be able to announce the availability 
of Akka 2.3.16. This is the 16th maintenance release of the 2.3 branch. 
This release contains three bugfixes:

   - Wraparound issue with the scheduler causing it to stop function 
   correctly 20424 
   - Issue in ConsistentHashingRouter causing problems for DNS resolution 
   in Akka 20263 
   - Backport of a serialization issue around scala.Option in Akka 
   Persistence 16659 

The complete list of closed tickets can be found in the 2.3.16 github 
issues milestone 
.

Akka 2.3.16 is released for Scala 2.10 and 2.11. This release is backwards 
binary compatible with all previous 2.3.x versions which means that the new 
JARs are a drop-in replacement for the old one (but not the other way 
around) as long as your build does not enable the inliner (Scala-only 
restriction). Always make sure to use at least the latest version required 
by any of your project’s dependencies.
Additional Release Details

The artifacts comprising this release have been published to 
https://oss.sonatype.org/content/repositories/releases/ and also to Maven 
Central. In addition, we adopted the sbt standard of encoding the Scala 
binary version in the artifact name, i.e. the core actor package’s 
artifactId is “akka-actor_2.10” or “akka-actor_2.11”, respectively.
Credits

commits added removed
  250   5 Patrik Nordwall
  1   139  26 Roland Kuhn

*Happy hAkking!*

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

[Johan Andrén]

Even if you use loopback (127.0.0.1) for the two actor systems to 
communicate, communication is done through remoting, with messages being 
serialized etc. just like if they were on "real remote hosts". 

If you want to do it to get real world latencies/throughputs like with 
separate physical nodes communicating over a physical network then internal 
networking between virtual machines will likely not give you identical 
behaviour.

--
Johan 
Akka Team

On Monday, October 17, 2016 at 6:48:33 PM UTC+2, Rob Crawford wrote:
>
> Docker containers -- each JVM gets their own container, Docker will handle 
> the networking between them.
>
> On Monday, October 17, 2016 at 1:33:44 AM UTC-4, Joseph Mansigian wrote:
>>
>>
>> Hello,
>>I would like to develop an Akka actor based application that has 
>> actors that span the Internet.  It would be very convenient for me if I 
>> could do the early stages of this development all on one machine.  I would 
>> like to have two JVM running on one machine but have the actor systems and 
>> actors on these two JVM be remote to each other, not local actors,  and 
>> have these remote actors be addressable exactly as they would be if they 
>> were across the world from each other ( location transparency ) except they 
>> would use a real remote host in the path instead of 127.0.0.1.  I want to 
>> accomplish a fan out to anywhere on the Internet without rewriting any 
>> Scala code although config or deployment info changes are certainly Okay.
>>
>> >  Can I work this way?
>>
>> >  If I can work this way what are any special constraints because I am 
>> on one machine?  I feel I understand remoting pretty well from Akka 
>> documentation but still not averse to re-reading if I know what to look for.
>>
>> > Do you have any good examples of a project like this or a tutorial 
>> discussion of a project? 
>>
>>
>> Thank you for helping,  Joe
>>
>

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

[Johan Andrén]

Hi Carl,

I think that underscore in a hostname actually is not valid, if you look at 
RFC 952, the definition host hostname boils down to:

  ::= [*[]]


Which means a letter followed by zero or more letters, digits or hyphens 
ending with a letter or a digit. I think docker actually has been changed 
to not use underscore (I think this ticket is about 
that https://github.com/docker/docker/issues/22057)

--
Johan
Akka Team

On Saturday, October 15, 2016 at 8:13:08 PM UTC+2, Carl Pulley wrote:
>
> Interestingly, AddressFromURIString is also used in 
> akka.cluster.ClusterSettings - and so seeding using DNS names with 
> underscores in their hostnames is also problematic (especially as in my 
> example use cases I don't have any control over the choice of the DNS name).
>
> Is this an intended design decision (if so, I'd like to understand this 
> decision better please) or should this be considered a bug/issue?
>
> Many thanks,
>
>   Carl.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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-scala template dependency not found by Lightbend Activator, so compile fails

[Johan Andrén]

The artifact voldemort.store.compress h2-lzf 1.0 is on maven central, so 
that sounds like problems for sbt accessing the internet (or at least maven 
central) from your computer, proxy config, firewall?

--
Johan
Akka Team

On Friday, September 30, 2016 at 1:16:43 PM UTC+2, Egor Kraev wrote:
>
> Hi,
>
> I downloaded Lightbend Activator from here http://akka.io/downloads/  and 
> tried to load the template akka-stream-scala as indicated here 
> http://www.lightbend.com/activator/template/akka-stream-scala 
> 
> .
>
> When I try to compile that inside Activator, I get 
>
>- [error] (*:update) sbt.ResolveException: unresolved dependency: 
>voldemort.store.compress#h2-lzf;1.0: not found
>
> every time - any idea how to fix that?
>
> Running activator-1.2.7 and Java jdk-8u102 on Windows 10 Home.
>
> Thanks a lot,
> E.
>
>

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

[Johan Andrén]

There are some tricks you could do with HOCON to reuse the first 
configuration but change just some specifics.

You should be able to do something like this:

myapp.mailbox-small {
  mailbox-type = "akka.dispatch.BoundedMailbox"
  mailbox-capacity = 1
  mailbox-push-timeout-time = 1s
}

myapp.mailbox-medium = ${myapp.mailbox-small}
myapp.mailbox-medium.mailbox-capacity = 5

For more details, see the Typesafe Config library docs here: 
https://github.com/typesafehub/config#uses-of-substitutions

--
Johan


On Monday, September 19, 2016 at 11:09:37 AM UTC+2, Mehmet Cem Güntürkün 
wrote:
>
> Btw I have one more question, is this the right way to define mailboxes 
> for actors, I mean I create a mailbox type like this:
>
> bounded-mailbox {
>  mailbox-type = "akka.dispatch.BoundedMailbox"
>  mailbox-capacity = 1
>  mailbox-push-timeout-time = 1s
> }
>
>
> and set mailbox type to actors:
>
>   /singletestactorone {
>mailbox = bounded-mailbox
>   }
>
>   /singletestactortwo {
>mailbox = bounded-mailbox
>   }
>   
>   /singletestactorthree {
>mailbox = bounded-mailbox
>   }
>
>
>
> but if I have a couple of actors have same mailbox type but different 
> mailbox sizes, should I create new mailbox types for each size?
>
> 8 Eylül 2016 Perşembe 15:47:39 UTC+3 tarihinde Akka Team yazdı:
>>
>> Hi Mehmet,
>>
>> Easiest would be to select the mailbox with props:
>>
>> system.actorOf(Props[TestActor]
>>   .withMailbox("bounded-mailbox") // here
>>   .withRouter(FromConfig),
>>   "groupedtestactor")
>>
>> But you could also do it purely from config with a deployment section 
>> like this:
>>
>> "/groupedtestactor/*" {
>>   mailbox = bounded-mailbox
>> }
>>
>> Since the pool will create the routees as children this configures all 
>> direct children of the router to use the bounded-mailbox
>>
>> --
>> Johan
>> Akka Team
>>
>>
>> On Fri, Aug 26, 2016 at 2:53 PM, Mehmet Cem Güntürkün <
>> mehmetcem...@gmail.com> wrote:
>>
>>>
>>> Hello everyone,
>>>
>>> When I try to set a bounded mailbox to routees of RoundRobinPool, Akka, 
>>> kind of ignores the configuration parameter.
>>>
>>>
>>> Here is the sample for configuration:
>>>
>>>
>>> bounded-mailbox {
>>>   mailbox-type = "akka.dispatch.BoundedMailbox"
>>>   mailbox-capacity = 1
>>>   mailbox-push-timeout-time = 1s
>>> }
>>>
>>> akka.actor.deployment {
>>>   /singletestactor {
>>> mailbox = bounded-mailbox
>>>   }
>>>
>>>   /groupedtestactor {
>>> mailbox = bounded-mailbox
>>>
>>> router = round-robin-pool
>>> nr-of-instances = 5
>>>   }
>>> }
>>>
>>>
>>> and Here is the test code:
>>>
>>>
>>> object MailboxTest {
>>>   def main(args: Array[String]): Unit = {
>>> val actorSystem = ActorSystem()
>>> val singleTestActor = actorSystem.actorOf(Props[TestActor], 
>>> "singletestactor")
>>> for (i <- 1 to 10) {
>>>   singleTestActor ! Hello(i)
>>> }
>>>
>>>
>>> val groupedTestActor = 
>>> actorSystem.actorOf(Props[TestActor].withRouter(FromConfig, 
>>> "groupedtestactor")
>>> for (i <- 1 to 1000) {
>>>   groupedTestActor ! Hello(i)
>>> }
>>>   }
>>> }
>>>
>>> class TestActor extends Actor {
>>>   def receive = {
>>> case Hello(i) => {
>>>   println(s"Hello($i) - begin!")
>>>   Thread.sleep(1)
>>>   println(s"Hello($i) - end!")
>>> }
>>>   }
>>> }
>>>
>>> case class Hello(i: Int)
>>>
>>>
>>>
>>> Am I doing something wrong or there is no way to do that?
>>> Mehmet - 
>>>
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to 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.
>>>
>>
>>
>>
>> -- 
>> Akka Team
>> Lightbend  - Reactive apps on the JVM
>> Twitter: @akkateam
>>
>

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

[akka-user] Re: Deploying akka cluster on Clever Cloud/Heroku

[Johan Andrén]

Hi Juan,

As far as I know (a bit dated knowledge) Heroku does not allow generic TCP 
communication to the nodes at all, only HTTP on a port that you get from 
the $PORT environment variable, which will be routed from the public 
address through Herokus HTTP routing infrastructure, so I'm afraid that if 
it is still like this it makes it impossible to run Akka Cluster on Heroku.

There seems to be something nowadays called Private Spaces nowadays which 
gives you a private virtual network between your nodes. If that really 
allows connections from any of your nodes to any other on whatever TCP port 
you like you will be able to run Akka Cluster in such an environment 
(https://devcenter.heroku.com/articles/dynos#private-spaces-runtime-networking) 

--
Johan
Akka Team


On Tuesday, September 20, 2016 at 6:23:12 AM UTC+2, equipo...@gmail.com 
wrote:
>
> Hello everyone,
> Currently, the project I am working on can be divided into a web frontend 
> that uses Play! framework and several backend nodes that are developed in 
> Akka. The goal was to set them up on different apps/dynos, so I would be 
> able to scale the frontend horizontally and vertically, as well as manage 
> the backend nodes. These backend nodes have no http interface and merely do 
> the jobs that are sent to them by the frontend and return them. I set up an 
> akka cluster to communicate between the nodes, and also to set up ssl 
> between them. Locally, everything worked perfectly, but when I tried to 
> deploy on Clever Cloud, I found out that the only way they can communicate 
> is throught HTTP on port 80, and my cluster is communicating through TCP on 
> port 2551. I tried setting up port 80 on the remoting configuration to 
> listen on it, but it doesn't seem to work as my app appears to be non 
> responsive. I started reading up on what could be done, and the only 
> solution I found was to use RabbitMQ, and, as I understand it, that would 
> mean that I would have to give up on using akka cluster and rewire the 
> communications and security protocols, now to be used by this message 
> broker. I would like to know if anyone has encountered a similar situation 
> and has found a configuration that works so I can keep using akka cluster, 
> or if I am missing something.
> Thanks in advance.
> Juan CABALLERO
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 Karaf: No configuration setting found for key 'akka.version'

[Johan Andrén]

The reason you get that error is what the big red warning in the docs:


"Akka's configuration approach relies heavily on the notion of every 
module/jar having its own reference.conf file, all of these will be 
discovered by the configuration and loaded. Unfortunately this also means 
that if you put/merge multiple jars into the same jar, you need to merge 
all the reference.confs as well. Otherwise all defaults will be lost and 
Akka will not function."


When merging the jar files of many Akka modules reference.conf must be each 
of the reference.conf in the modules merged into a single file and included 
in the superjar (how this is done with the maven plugin you mention I 
cannot say). 

Your application config should be put in application.conf.

--
Johan
Akka Team

On Tuesday, September 20, 2016 at 4:51:56 PM UTC+2, Daniele Ascione wrote:
>
> Hi Johan, thank you so much for your answer!
>
> I read the section of the doc that you said, but I could not resolve my 
> issue. 
> I think that the problem doesn't come from configuration files (but i may 
> be wrong).
> I'll try to explain what I mean better: in this example [ 
> http://www.lightbend.com/activator/template/akka-sample-main-java ] with 
> source code [ 
> https://github.com/akka/akka/tree/master/akka-samples/akka-sample-main-java 
> ], 
>
> you can run akka (from main) even if you don't write any application.conf 
> , just accepting default configurations. But if I try to do the same 
> thing starting the bundle (that is, putting no conf files in the jar) with 
> the activator I wrote, I have this exception:
>
> Caused by: com.typesafe.config.ConfigException$Missing: No configuration 
> setting found for key 'akka'
>   at com.typesafe.config.impl.SimpleConfig.findKeyOrNull(SimpleConfig.java
> :152)[327:com.example.akka-poc-bundle:0.0.1]
>at com.typesafe.config.impl.SimpleConfig.findKey(SimpleConfig.java:145
> )[327:com.example.akka-poc-bundle:0.0.1]
>  at com.typesafe.config.impl.SimpleConfig.findOrNull(SimpleConfig.java:172
> )[327:com.example.akka-poc-bundle:0.0.1]
>   at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:184
> )[327:com.example.akka-poc-bundle:0.0.1]
> at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:189)[
> 327:com.example.akka-poc-bundle:0.0.1]
> at com.typesafe.config.impl.SimpleConfig.getString(SimpleConfig.java:
> 246)[327:com.example.akka-poc-bundle:0.0.1]
>at akka.actor.ActorSystem$Settings.(ActorSystem.scala:168)[
> 327:com.example.akka-poc-bundle:0.0.1]
> at akka.actor.ActorSystemImpl.(ActorSystem.scala:522)[327:com.
> example.akka-poc-bundle:0.0.1]
>  at akka.actor.ActorSystem$.apply(ActorSystem.scala:142)[327:com.
> example.akka-poc-bundle:0.0.1]
>  at akka.actor.ActorSystem$.apply(ActorSystem.scala:126)[327:com.example.
> akka-poc-bundle:0.0.1]
>  at akka.osgi.OsgiActorSystemFactory.createActorSystem(
> OsgiActorSystemFactory.scala:32)[327:com.example.akka-poc-bundle:0.0.1]
>   at akka.osgi.ActorSystemActivator.start(ActorSystemActivator.scala:42)[
> 327:com.example.akka-poc-bundle:0.0.1]
>   at org.apache.felix.framework.util.SecureAction.startActivator(
> SecureAction.java:697)[org.apache.felix.framework-5.4.0.jar:]
>at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)[org
> .apache.felix.framework-5.4.0.jar:]
>  ... 16 more
>
>
>
> Il giorno martedì 20 settembre 2016 15:57:33 UTC+2, Johan Andrén ha 
> scritto:
>>
>> Hi Daniele,
>>
>> Read this section of the docs! 
>>
>> http://doc.akka.io/docs/akka/2.4/general/configuration.html#when-using-jarjar-onejar-assembly-or-any-jar-bundler
>>
>> --
>> Johan Andrén
>> Akka Team
>>
>> On Tuesday, September 20, 2016 at 3:44:58 PM UTC+2, Daniele Ascione wrote:
>>>
>>> I looked in the Akka User List for a long time, but I coudn't find 
>>> anything which helped me in this situation. Sorry if this is a duplicated 
>>> answer.
>>> I'm trying to create an akka "Hello World" bundle (inspired by the this 
>>> example 
>>> <https://github.com/akka/akka/tree/master/akka-samples/akka-sample-main-java>),
>>>  
>>> and I'm trying to start it in Karaf.
>>> I wrote this *activator *in java: 
>>> public class AkkaActivator extends ActorSystemActivator {
>>>
>>> ActorSystem actorSystem; 
>>> ActorRef actorRef;
>>> @Override
>>> public void configure(BundleContext context, ActorSystem system) {
>>> Config regularConfig = ConfigFactory.load();
>>> String sysName = system.name();
>>> ActorSystem.apply(sysName, regularConfig);
>>> actorRef = system.actorOf(Props.create

[akka-user] Re: Using Akka in Karaf: No configuration setting found for key 'akka.version'

[Johan Andrén]

Hi Daniele,

Read this section of the docs! 
http://doc.akka.io/docs/akka/2.4/general/configuration.html#when-using-jarjar-onejar-assembly-or-any-jar-bundler

--
Johan Andrén
Akka Team

On Tuesday, September 20, 2016 at 3:44:58 PM UTC+2, Daniele Ascione wrote:
>
> I looked in the Akka User List for a long time, but I coudn't find 
> anything which helped me in this situation. Sorry if this is a duplicated 
> answer.
> I'm trying to create an akka "Hello World" bundle (inspired by the this 
> example 
> <https://github.com/akka/akka/tree/master/akka-samples/akka-sample-main-java>),
>  
> and I'm trying to start it in Karaf.
> I wrote this *activator *in java: 
> public class AkkaActivator extends ActorSystemActivator {
>
> ActorSystem actorSystem; 
> ActorRef actorRef;
> @Override
> public void configure(BundleContext context, ActorSystem system) {
> Config regularConfig = ConfigFactory.load();
> String sysName = system.name();
> ActorSystem.apply(sysName, regularConfig);
> actorRef = system.actorOf(Props.create(HelloWorld.class), "helloWorld");
> system.actorOf(Props.create(Terminator.class, actorRef), "terminator");
> }
>
> }
>
>  , which I deployed in a jar using the maven-bundle-plugin 
> <http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html>
> .
> I wrote also a *reference.conf* file which is inserted by maven plugin in 
> the root of the created jar. The file is the following one:
>   
> akka {
>   loglevel = INFO
> }
>
>
> All the code is avaible in this repo 
> <https://bitbucket.org/audhumla/akka-osgi/overview>.
> When I try to start the bundle from karaf, I obtain the following 
> exception:
>
> 2016-09-20 15:20:15,560 | ERROR | nsole user karaf | ShellUtil 
>| 44 - org.apache.karaf.shell.core - 4.0.5 | Exception caught 
> while executing command
> org.apache.karaf.shell.support.MultiException: Error executing command on 
> bundles:
> Error starting bundle 327: Activator start error in bundle 
> com.example.akka-poc-bundle [327].
> at 
> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
> at 
> org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:69)[24:org.apache.karaf.bundle.core:4.0.5]
> at 
> org.apache.karaf.bundle.command.BundlesCommand.execute(BundlesCommand.java:54)[24:org.apache.karaf.bundle.core:4.0.5]
> at 
> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:83)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:480)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:406)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:182)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:119)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:94)[44:org.apache.karaf.shell.core:4.0.5]
> at 
> org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:270)[44:org.apache.karaf.shell.core:4.0.5]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_91]
> Caused by: java.lang.Exception: Error starting bundle 327: Activator start 
> error in bundle com.example.akka-poc-bundle [327].
> at 
> org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:66)[24:org.apache.karaf.bundle.core:4.0.5]
> ... 12 more
> Caused by: org.osgi.framework.BundleException: Activator start error in 
> bundle com.example.akka-poc-bundle [327].
> at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)[24:org.apache.karaf.bundle.core:4.0.5]
> at 
> org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:64)[24:org.apache.karaf.bundle.core:4.0.5]
> ... 12 more
> Caused by: com.t

[akka-user] Re: Documentation questions: akka-http

[Johan Andrén]

Hi,

The format: ON/OFF are directives to our code auto-formatter to not touch 
the code inside of that, for example when we have carefully laid it out to 
be a nice and readable sample.

All the samples are compiled as a part of our ci setup, and again when we 
make a release so if it didn't compile we wouldn't have been able to 
compile it.
Note that for example the latest IntelliJ seems to have problems resolving 
the implicit conversion needed for it to work, so even though it compiles 
IntelliJ may show a squiggly red line and warning about type mismatch.

--
Johan
Akka Team

On Thursday, September 15, 2016 at 8:56:42 PM UTC+2, mniel...@gmail.com 
wrote:
>
> In the "spray" documentation (
> http://doc.akka.io/docs/akka/2.4/scala/http/common/json-support.html#akka-http-spray-json)
>  
> a couple of the examples show the following:
>
> // format:  OFF
>
> followed by
>
> //format:  ON
>
> What are those comments intended to convey?  
>
> I keep worrying that I'm missing something significant.
>
> Also, on http://doc.akka.io/docs/akka/2.4/scala/http/introduction.html an 
> example shows the following code, which doesn't compile:
>
>  case None   => complete(StatusCodes.NotFound)
>
> The following change allows it to compile:
>
>  case None   => complete((StatusCodes.NotFound,"Too bad"))
>
>
>
>
>

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

[akka-user] [ANNOUNCE] Akka 2.4.9 Released!

[Johan Andrén]

Dear hAkkers,

We—the Akka committers—are pleased to be able to announce the availability 
of Akka 2.4.9. We would like to thank everyone who tested the Release 
Candidates, such that now we’re confident in releasing this version. This 
version is focused on Akka HTTP and Akka Streams performance improvements 
as well as introducing the entity streaming feature which we’ll discuss 
below but also contains bugfixes and general improvements.

Highlights of the performance improvements include:

   - Overall Akka HTTP throughput and transfer rate has been improved by 
   30-40%
   - Performance is on-par or better than Spray.
  - Matching it both in raw throughput as well as latency distribution 
  across a spectrum of request rates.
  - We measured an overall improvement of ~14% over Spray
   - Short lived connections throughput, which remains to be the worst-case 
   scenario for Akka HTTP thought remains rare in the real world (due to 
   connection pooling), has been doubled.
   - Given our EC2 infrastructure (m4.2xlarge instances) the server 
   currently reaches a maximum of ~160.000 “ping / pong” requests per second 
   (measured using 100 concurrent connections).

While we did not have the chance to benchmark using dedicated boxes this 
time, based on experience from previous Spray benchmark rounds we expect 
the top throughput to be much higher on actual hardware than it is on EC2. 
One might want to remind remind oneself the good old post about Spray’s 
benchmarking results <http://spray.io/blog/2013-05-24-benchmarking-spray/> back 
in 2013 when it won a benchmarking round, achieving 30k reqs/sec on EC2 
(m1.large) and 197k reqs/sec on dedicated i7 machines (using 256 
connections).

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

This release also features a new feature that we think Streaming API 
authors will be delighted to see: EntityStreamingSupport. It makes 
marshalling of Akka Streams into/from HTTP requests and responses as simple 
as adding enabling streaming and calling complete(tweets), given tweets was 
a Source[Tweet, _]. Learn more about it in the Entity Streaming section of 
the documentation 
<http://doc.akka.io/docs/akka/2.4/java/http/routing-dsl/source-streaming-support.html>
.

The Akka HTTP API has remained largely unchanged, though the usual 
experimental module incompatibility caveat still remains so upgrading 
should be simple. You may want to refer to the migration guide 
<http://doc.akka.io/docs/akka/2.4/scala/http/migration-guide-2.4.x-experimental.html>,
 
as some classes moved to more appropriate places.

With the release of Akka 2.4.9 we would like to announce that we’ll soon be 
going forward with marking Akka HTTP a stable module! While doing so, there 
is a number of improvements and re-organisation we will want to apply 
during this process. Please read the proposal in akka/akka-meta#27 
<https://github.com/akka/akka-meta/issues/27>, which includes splitting 
Akka HTTP into its own repository and other changes to ease its maintenance 
and evolution. This process will be very open and we would like to invite 
you to help us in it, as we’d love to see Akka HTTP become more and more 
driven by the community. It is somewhat of an an experiment we’re embarking 
on and it needs your participation to become really successful.

Credits:
Commits added removed
   4057721754 Konrad Malawski
   231107 422 Johan Andrén
9 833 305 Endre Sándor Varga
8 878 419 Hawstein
8 215 112 Nafer Sanabria
5 217  76 Patrik Nordwall
4 132  10 Stefano Bonetti
3 175  25 Richard Imaoka
2   4  11 matsu-chara
2  57  25 Ian Clegg
2  55  22 Alexander Golubev
2   5   5 abesanderson
2  12   2 Schmitt Christian
2   4   4 kenji yoshida
1   7   2 Alexei
1   8   0 Adam Warski
1   1   1 Morton Fox
1  20   0 Harit Himanshu
1  25   0 Lev Khomich
1 203  52 svezfaz
1   1   1 Yaroslav Klymko
1   7   1 Mike Bryant
1  37  22 priyanka
1 202   1 Richard S. Imaoka
1   1   1 Todd Ginsberg
1  12   3 Abe Sanderson
1   6   6 Thomas Szymanski
1 246   7 Peter Barron
1   1   0 Vadim Semenov
1   6   6 Kirill Plyashkevich
1   2   2 Josep Prat
1   5   5 Lukasz Kusek
1   2   3 Jacek Kunicki
1  41

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

[Johan Andrén]

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

--
Johan

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

[akka-user] Re: No configuration setting found for key 'akka.version' when running jar-with-dependencies

[Johan Andrén]

Hi Dean,

You must make sure all the reference.conf files are concatenated into one 
file if you want to put all the akka modules inside one jar like that.

This is described in the docs you linked 
to: 
http://doc.akka.io/docs/akka/current/general/configuration.html#When_using_JarJar__OneJar__Assembly_or_any_jar-bundler

--
Johan
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 Java TCP client , Sink.ignore()

[Johan Andrén]

Hi Chhil,

If you do not care about any incoming data from the TCP server Sink.ignore 
should be fine (it will accept but discard any data from the server).

--
Johan
Akka Team

On Friday, July 29, 2016 at 12:48:52 PM UTC+2, murtuza chhil wrote:
>
>
> Hi,
>
> I am an Akka newbie trying to get my head around streams.
>
> In the following working snippet, if I have a netcat server running I can 
> get the client to send the bytes across.
>
> The sink.ignore that I added is simply because I needed a sink to connect 
> to to run the graph. Is that really needed and how would I run something 
> without it because as I see it, 
> I have a source and a the flow created by the Tcp.get(), that should 
> be sufficient to send the data. 
>
> Did have a look at the TCpEcho example, but I want to do it without the 
> runfold.
>
> ```
> Flow flow = 
> Tcp
> .get(system).outgoingConnection("127.0.0.1", 6000);
> Source clientSource = Source.single(ByteString
> .fromString("Chhil"));
> clientSource.via(flow).to(Sink.ignore()).run(mat);
> ```
>
> -chhil
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Trying to mimic socket level programming , connect client and then send data if connection is available

[Johan Andrén]

Hi Chhil,

The flow returned by outgoingConnection materializes into a 
CompletionStage which will be failed if the connection 
fails, so that is where you can implement your error handling for the 
initial connection. You would have to keep the materialized value when you 
construct the flow though, so that it is returned from run(). 

You can read more about materialized values 
here: 
http://doc.akka.io/docs/akka/2.4/java/stream/stream-composition.html#materialized-values
 
and TCP with streams here: 
http://doc.akka.io/docs/akka/2.4/java/stream/stream-io.html#stream-io-java  

In general, read as much of the streams docs as you can to get a good 
understanding of how Akka Streams work, trial and error with streams + tcp 
will hurt!

--
Johan
Akka Team

On Monday, August 1, 2016 at 7:20:23 AM UTC+2, murtuza chhil wrote:
>
> Hello,
>
> I am a newbie trying to understand Akka Streams.
>
> Coming from regular socket programming I am trying to mimic a client 
> connection and have the following runnable graph.
>
> Flow 
> flow = Tcp
> .get(system).outgoingConnection("127.0.0.1", 6000);
> Source clientSource = Source.single(ByteString
> .fromString("XYZ"));
>
> clientSource.via(flow).to(Sink.ignore()).run(mat);
>
> ​
>
> This works fine when used with the samples in the doc, where the source is 
> attached that has a list and there is a server listening and we run the 
> source->flow->sink through a materializer.
>
> But this is not a typical use case, typically one would attempt to connect 
> to a server,  and either it connects or fails. If connected send data that 
> will be made available and if connection fails, have the ability to backoff.
>
>
> Currently I don't know how to access the error when a server is not 
> available and want to establish a connection before data is available.
> Don't know how to prevent connections every time data is sent, I 
> understand why it happens, but don't know how to reuse a materialized flow 
> that has already connected.
> What I am trying to get my head around is how does one run a graph without 
> any source data and get a completable future that tells me if it succeeded 
> or not.
> Then I want to use the same connection to send data later using the source.
>
> I have attempted with a runfold and that give me the akka TCP Exception 
> when the server is not availble, but I simply want to forward the data from 
> the source without manipulation.
>
> There was another thread that I had started 
> https://groups.google.com/d/msg/akka-user/1ztizMy9FnI/U9toR-cOBgAJ, would 
> appreciate if someone responds to it. 
>
> Any pointers or snippets would be greatly appreciated. Yes I am not used 
> to this paradigm of programming but trying to figure it out.
>
> -chhil
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Error about download akka proj from github and open it as a proj in intellij

[Johan Andrén]

Hi Leo,

What IntelliJ version and how did you open/import the Akka into IntelliJ? 
Make sure you have the latest as that works best, and just use Open make 
IntelliJ load the project.

IntelliJ doesn't quite understand the Akka build files in that it will give 
those red warning lines in the .sbt files because of not understanding what 
is available on the sbt project classpath or something like that. It should 
however work fine to open the project, let the IntelliJ Scala plugin do 
it's thing reading the sbt build into an IntelliJ project.

At some point when IntelliJ broke it's own project files I have had to 
close IntelliJ delete the generated .idea directory and open the project 
anew to make IntelliJ re-parse the sbt build, maybe this helps.

--
Johan

On Thursday, July 21, 2016 at 12:48:57 PM UTC+2, Leo Wolf wrote:
>
> By the way, the error shows this message:
>
>
> 
>
>
> Very thanks for the help!
>
>
> Leo Wolf於 2016年7月21日星期四 UTC+8下午6時46分13秒寫道：
>>
>> Hi Konrad,
>>
>> Thank you for getting back to me.
>> I have create a scala test file under Akka-http-sprayjson and the path is 
>> "/akka/akka-http-marshallers-scala/akka-http-spray-json/src/main/scala/akka/http/scaladsl/marshallers/sprayjson/UploadHandler.scala",
>>  
>> and package it as package akka.http.scaladsl.marshallers.sprayjson
>> , but some strange error shown:
>>
>>
>> 
>>
>> But the whole same scala file in a new project using sbt to include the 
>> normal akka library , I mean something like "com.typesafe.akka" %% 
>> "akka-http-experimental" 
>> % akkaVer withSources() withJavadoc(),is OK:
>>
>>
>> 
>>
>>
>>
>> And I do not really know why these errors occurred...
>>
>>
>>
>> Konrad Malawski於 2016年7月21日星期四 UTC+8下午4時25分16秒寫道：
>>>
>>> Hi Leo,
>>> what PR are you working on?
>>>
>>> But I found out there are lots of errors in build.sbt in every 
>>> directory. For instance,
>>>
>>> For the most part you can ignore these if intellij doesn't pick them up.
>>>
>>> The import into intellij from sbt feature works properly.
>>>
>>> And, I create a test.scala in akka.http.scaladsl.server.Directives, but 
>>> I found out I can't import akka.http.scaladsl.marshallers.sprayjson because 
>>> I can't find the directory below the menu:
>>>
>>>
>>> 
>>>
>>>
>>> "Akka-http" does not depend on "Akka-http-sprayjson", so it's not 
>>> available there.
>>> "Akka-http-sprayjson" does depend on "Akka HTTP" though, so in that 
>>> project you have all you need to write your test.scala
>>>
>>> Hope this helps
>>>
>>> -- konrad
>>>
>>

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

[akka-user] Re: Pass Future to Sink.ignore, how do I know it's completed

[Johan Andrén]

You can go from a stream of Future[T] to a stream of T by using mapAsync that 
way your stream will actually complete when the last future completes, 
Sink.ignore will materialize into a Future[Done] which completes when the 
stream completes, so those two in combination should be one solution.

--
Johan

On Thursday, July 21, 2016 at 11:50:13 PM UTC+2, Gary Struthers wrote:
>
> My Sink receives a Future. I don't want to do anything with it so I use 
> Sink.ignore but then I don't know when it's completed and that I need to 
> know. Should I write a custom Sink or does the API already have a solution 
> for this?
>
> 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: [cluster] why Connection refused.

[Johan Andrén]

There is not enough information to say anything certain about your problem. 
"Connection refused" means there is a route to that host but it was not 
possible to connect to the given port, it could for example be because of a 
internal firewall or a firewall between the systems, or if you use docker 
that the port you bind to is internal and maps to another port number on 
the actual network.

--
Johan

On Friday, July 22, 2016 at 11:35:17 AM UTC+2, 2817...@qq.com wrote:
>
> two nodes are cluster, but when starting , they all are following log:
>
> node akka.tcp://opendaylight-cluster-data@172.18.118.43:2550
> 07-21-16:23:01 2016-07-21 16:23:01,391 | WARN  | lt-dispatcher-16 | 
> ReliableDeliverySupervisor   | 167 - com.typesafe.akka.slf4j - 2.3.10 | 
> Association with remote system [akka.tcp://
> opendaylight-cluster-data@172.18.118.42:2550] has failed, address is now 
> gated for [5000] ms. Reason: [Association failed with [akka.tcp://
> opendaylight-cluster-data@172.18.118.42:2550]] Caused by: [Connection 
> refused: /172.18.118.42:2550]
>
>
> node akka.tcp://opendaylight-cluster-data@172.18.118.42:2550
> 07-21-16:23:04 2016-07-21 16:23:04,541 | WARN  | ult-dispatcher-4 | 
> ReliableDeliverySupervisor   | 167 - com.typesafe.akka.slf4j - 2.3.10 | 
> Association with remote system [akka.tcp://
> opendaylight-cluster-data@172.18.118.43:2550] has failed, address is now 
> gated for [5000] ms. Reason: [Association failed with [akka.tcp://
> opendaylight-cluster-data@172.18.118.43:2550]] Caused by: [Connection 
> refused: /172.18.118.43:2550]
>
>  "seed-nodes" : [ "akka.tcp://opendaylight-cluster-data@172.18.118.42:2550
> ",
>   "akka.tcp://opendaylight-cluster-data@172.18.118.43:2550" ]
>
> That could be some reason? 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] Creating Actor w/ Props having Value Class Argument(s)

[Johan Andrén]

Hi Kevin,

If you scroll down a bit from where you linked into the docs you can see 
the variations of prop factory methods and how to make it work with a value 
class 
(http://doc.akka.io/docs/akka/current/scala/actors.html#Value_classes_as_constructor_arguments)

Reflection is used when you do not provide a factory function to props but 
rather a class name and a list of constructor parameters. If all you have 
is a class name and a bunch of objects, the only way you can invoke a 
constructor is through reflection (or possibly a macro)

Both variations have their shortcomings, factory functions are hard to 
serialize and can easily close over surrounding scope by mistake, class + 
objects serializes fine but looses a bit of type safety - you won't know 
until runtime if you put the wrong number or wrong types of arguments in 
the list.

--
Johan

On Saturday, July 23, 2016 at 4:35:30 AM UTC+2, Kevin Meredith wrote:
>
> Thanks for the minimal example, Konrad. 
>
> On a side note, why is it necessary to use reflection (or possibly a 
> macro) in order to construct an Actor? 
>
> On Wednesday, July 20, 2016 at 11:48:15 AM UTC-4, Konrad Malawski wrote:
>>
>> This basically demonstrates the core of the problem:
>>
>> scala> class Meter(val m: Int) extends AnyVal
>> defined class Meter  
>> // in runtime you have *no way* to check if it's an AnyVal extending class 
>> or not. We would have to use macros. (scala reflection is a bit iffy...)
>>
>> scala> val m = new Meter(12)
>> m: Meter = Meter@c
>>
>> scala> class Act(m: Meter)
>> defined class Act
>>
>> scala> classOf[Act].getDeclaredConstructors.head
>> res23: java.lang.reflect.Constructor[_] = public Act(int)
>> // constructor takes int as you can see
>> // it is the ONLY constructor this class has - you can't pass in a Meter 
>> instance.
>>
>> scala> classOf[Act].getDeclaredConstructors.head.newInstance(new Integer(12))
>> res24: Any = Act@572db5ee
>>
>> scala> classOf[Act].getDeclaredConstructors.head.newInstance(new 
>> Meter(12).asInstanceOf[Object])
>> java.lang.IllegalArgumentException: argument type mismatch
>>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>   at 
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>   at 
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>   ... 32 elided
>> // NOPE.
>>
>>
>> // because if effectively is exactly the same as:
>> scala> class Act2(m: Int)
>> defined class Act2
>>
>> scala> classOf[Act2].getDeclaredConstructors.head
>> res27: java.lang.reflect.Constructor[_] = public Act2(int)
>>
>> scala>  classOf[Act].getDeclaredConstructors.head.newInstance(new 
>> Integer(12))
>> res28: Any = Act@50f65fe0
>>
>> scala>  classOf[Act].getDeclaredConstructors.head.newInstance(new 
>> Meter(12).asInstanceOf[Object])
>> java.lang.IllegalArgumentException: argument type mismatch
>>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>   at 
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>   at 
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>   ... 32 elided
>>
>>
>> So we’d be forced into guesswork about “hmmm! it has one field, maybe if 
>> we take the field out of that instance it will work!”. Which is weird, so 
>> we choose not to do this.
>>
>> If you have a solution to this problem I’d love to hear it :-)
>>
>>
>>
>> -- 
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 20 July 2016 at 17:29:15, Kevin Meredith (kevin.m@gmail.com) 
>> wrote:
>>
>> Hi Konrad - 
>>
>> Could you please give me an example that demonstrates the "so we can't 
>> ..."?
>>
>> >AnyVal is a Scala compiler optimisation, so we can't figure out the 
>> right constructor (always / safely) in runtime.
>>
>> Thanks
>>
>> On Wednesday, July 20, 2016 at 9:44:33 AM UTC-4, Konrad Malawski wrote: 
>>>
>>> Because the type (wrapper) is not there at runtime.
>>> AnyVal is a Scala compiler optimisation, so we can't figure out the 
>>> right constructor (always / safely) in runtime.
>>>
>>> A resolution would be to "if thing has one field, and that value matches 
>>> we use that field" which could lead to very weird behaviour sometimes.
>>>
>>> -- 
>>> Konrad `ktoso` Malawski
>>> Akka  @ Lightbend 
>>>
>>> On 20 July 2016 at 15:40:08, Kevin Meredith (kevin.m@gmail.com) 
>>> wrote:
>>>
>>> Looking at the Akka docs 
>>>  for creating 
>>> an Actor:
>>>
>>> The recommended approach to create the actor Props is not supported for 
>>> cases when the actor constructor takes value classes as arguments.
>>>
>>> Please 

[akka-user] Re: No message received on remote node in Akka Cluster with DistributedPubSub

[Johan Andrén]

Hi Victor,

The cluster node roles feature is described in the docs 
here: http://doc.akka.io/docs/akka/2.4.8/java/cluster-usage.html#node-roles

I can't see how that would cause distributed pub sub to not work in such a 
way unless you also configured akka.cluster.pub-sub.role with a value. 
Maybe you rather have a race condition where node 2 haven't registered its 
listener, and or that it is registered has not been gossiped to node 1 yet 
when you try to sen the message from it. 

--
Johan

On Friday, July 22, 2016 at 12:21:30 PM UTC+2, Victor Ho wrote:
>
> The issue is resolved when I make the "roles" in cluster conf to be empty 
> instead of having the same value in both Java processes (node).
>
> Before:
>   cluster {
> roles = ["fitting"]
>
> After
>   cluster {
> roles = []
>
> Can anyone give me some pointers on the meaning of roles and the proper 
> usage in a cluster?
>
> Thanks.
>
>
> On Friday, July 22, 2016 at 5:35:16 PM UTC+8, Victor Ho wrote:
>>
>> Hi,
>>
>> I have a Akka cluster setup locally on one machine, with 2 nodes running 
>> on 2 java processes participating into one cluster. The different java 
>> processes (nodes) listen on different TCP ports.
>>
>> I am able to startup and see the nodes joining the cluster, however, when 
>> I have the "orchestrator" node "DistributedPubSubMediator.Send" a message 
>> to the "mediator" actor, the target remote actor never received the message.
>>
>> Can anyone help give some pointers on how to trouble shoot such issue?
>>
>> Attaching the akka application.conf. The highlights:
>>   actor.provider = "akka.cluster.ClusterActorRefProvider"
>>
>>   remote {
>>  enabled-transports = ["akka.remote.netty.tcp"]
>>  netty.tcp {
>>hostname = 127.0.0.1
>>port = 9095
>>  }
>>   }
>>
>>   extensions = ["akka.cluster.pubsub.DistributedPubSub"]
>>
>> For the 2 nodes, one runs on port *9095*, and one runs on port *9080*
>>
>> From the log:
>> [INFO] [07/22/2016 13:42:40.024] [main] [akka.remote.Remoting] Starting 
>> remoting
>> [INFO] [07/22/2016 13:42:40.305] [main] [akka.remote.Remoting] Remoting 
>> started; listening on addresses :[akka.tcp://ClusterSystem@127.0.0.1:9095
>> ]
>> [INFO] [07/22/2016 13:42:40.306] [main] [akka.remote.Remoting] Remoting 
>> now listens on addresses: [akka.tcp://ClusterSystem@127.0.0.1:9095]
>> [INFO] [07/22/2016 13:42:40.317] [main] 
>> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] - Starting up...
>> [INFO] [07/22/2016 13:42:40.390] [main] 
>> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] - Registered cluster JMX MBean 
>> [akka:type=Cluster]
>> [INFO] [07/22/2016 13:42:40.390] [main] 
>> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] - Started up successfully
>> [INFO] [07/22/2016 13:42:45.442] 
>> [ClusterSystem-akka.actor.default-dispatcher-15] 
>> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] - Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] is JOINING, roles [fitting]
>> [INFO] [07/22/2016 13:42:46.426] 
>> [ClusterSystem-akka.actor.default-dispatcher-16] 
>> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] - Leader is moving node 
>> *[akka.tcp://ClusterSystem@127.0.0.1:9095 
>> ] to [Up]*
>> [INFO] [07/22/2016 13:42:49.604] 
>> [ClusterSystem-akka.actor.default-dispatcher-19] 
>> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] - Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9080] is JOINING, roles [fitting]
>> [INFO] [07/22/2016 13:42:50.420] 
>> [ClusterSystem-akka.actor.default-dispatcher-14] 
>> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
>> ClusterSystem@127.0.0.1:9095] - Leader is moving node 
>> *[akka.tcp://ClusterSystem@127.0.0.1:9080 
>> ] to [Up]*
>>
>> Node membership in the cluster looks fine, but the message sending is not 
>> successful.
>>
>> Code sending to remote actor with path "worker"
>>
>> private ActorRef mediator = 
>> DistributedPubSub.get(getContext().system()).mediator();
>>
>> boolean localAffinity = true;
>> mediator.tell(new DistributedPubSubMediator.Send("/user/
>> *worker*", message, localAffinity), getSelf());
>>
>> Code worker actor telling itself to mediator
>> actorSystem.actorOf(Props.create(FittingActor.class), "worker");
>>
>> ActorRef mediator = 
>> DistributedPubSub.get(getContext().system()).mediator();
>> // register to the path
>> mediator.tell(new DistributedPubSubMediator.Put(getSelf()), 
>> getSelf());
>>
>>

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

[akka-user] Re: LevelDB journal plugin and its dispatcher usage

[Johan Andrén]

Hi Muthukumaran,

Please note that using the LevelDB journal is meant for testing, learning 
persistence etc, and not for production, for production you should use a 
real database (Cassandra is a popular distributed example).

--
Johan

On Sunday, July 17, 2016 at 5:00:13 PM UTC+2, Muthukumaran Kothandaraman 
wrote:
>
> Hi, 
>
> I am using a single persistence actor as per example here - 
> http://www.lightbend.com/activator/template/akka-sample-persistence-java#code/src/main/java/sample/persistence/PersistentActorExample.java
>
> I am using plain java serialization and not any snapshotting since I just 
> wanted to evaluate how the dispatcher of LevelDB journal plugin is being 
> used before I could think of other optimizations. 
>
>
> Observation :
> ==
>
> Connected the profiler by sending 6K commands to the actor to see how the 
> plugin dispatcher is being used. What I observed was that there were 2 
> threads allocated for plugin dispatcher as following. But only one of the 
> thread was being used and not both. 
> Is this behavior specific to LevelDB plugin. For production, I am planning 
> to use Cassandra plugin. But just wanted to understand if observed behavior 
> is due to some sort of "single-writer" enforcement (if any) by LevelDB
>
>
> example-akka.persistence.dispatchers.default-plugin-dispatcher-6 - always 
> idle and gets terminated even before the program completes
> example-akka.persistence.dispatchers.default-plugin-dispatcher-7 - always 
> busy
>
>
> Am I missing something crucial to ensure that all threads of plugin 
> dispatcher is used ?
>
>
> Conf File used 
> ===
>
> I am using the following application.conf for your reference 
>
> akka.persistence.journal.plugin = "akka.persistence.journal.leveldb"
> akka.persistence.snapshot-store.plugin = 
> "akka.persistence.snapshot-store.local"
>
> akka.persistence.journal.leveldb.dir = "target/example/journal"
> akka.persistence.snapshot-store.local.dir = "target/example/snapshots"
>
> akka.persistence.journal.leveldb.native = false
>
>
> Regards
> Muthu
>
>

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

[Johan Andrén]

Hi Debashish,

I'd guess it is because of the Source.empty which will complete the 
outgoing stream, there is a halfClosed property you can set when binding to 
allow the socket to stay alive even after the writing side close.

--
Johan

On Saturday, July 16, 2016 at 11:20:50 AM UTC+2, debasish wrote:
>
> Just to give some more context on the error that I get .. I get the 
> following when the client side connects to this service ..
>
> [INFO] [07/16/2016 14:46:40.274] 
> [front_office-akka.actor.default-dispatcher-2] 
> [akka://front_office/system/IO-TCP/selectors/$a/0] Message 
> [akka.io.Tcp$Write] from 
> Actor[akka://front_office/user/StreamSupervisor-3/$$a#576189595] to 
> Actor[akka://front_office/system/IO-TCP/selectors/$a/0#332685076] was not 
> delivered. [1] dead letters encountered. This logging can be turned off or 
> adjusted with configuration settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
>
>
> Thanks.
>
> On Saturday, July 16, 2016 at 1:12:57 PM UTC+5:30, debasish wrote:
>>
>> Hello -
>>
>> I have migrated to akka-streams 2.4.4 from 1.0. The following snippet of 
>> code (part of a larger application) used to work properly in 1.0 but fails 
>> in 2.4.4 ..
>>
>>   def run(): Unit = {
>> implicit val mat = ActorMaterializer()
>>
>> val summarizer = system.actorOf(Props[Summarizer])
>>
>> logger.info(s"Receiver: binding to $host:$port")
>>
>> Tcp().bind(host, port).runForeach { conn =>
>>   val receiveSink = 
>> conn.flow
>> .via(Framing.delimiter(ByteString("\n"), maximumFrameLength = 
>> 4000, allowTruncation = true)).map(_.utf8String)
>> .map(_.split(","))
>> .mapConcat(Transaction(_).toList)
>> 
>> .to(Sink.fromSubscriber(ActorSubscriber[Transaction](summarizer)))
>>
>>   Source.empty.to(receiveSink).run()  // ##
>> }
>>
>> import system.dispatcher
>> system.scheduler.schedule(0.seconds, 30.seconds, summarizer, 
>> LogSummaryBalance)
>>   }
>>
>> The problem is in the line marked // ##. When the client connects to this 
>> service, I get different types of errors every time .. e.g. Broken Pipe, 
>> Connection reset by peer etc. May be some race condition as the errors 
>> differ every time. 
>>
>> Do I need to do anything different for the new version ?
>>
>> Any help ?
>>
>> Thanks.
>>
>> -- 
>> Debasish Ghosh
>> http://manning.com/ghosh2
>> http://manning.com/ghosh
>>
>> Twttr: @debasishg
>> Blog: http://debasishg.blogspot.com
>> Code: http://github.com/debasishg
>>
>

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

[Johan Andrén]

Any interaction with the "out" actor should probably be inside your 
HandlerClass actor, I'd call that ChatConnection or something more 
descriptive. If more actors wants to interact with it you should create 
protocol for those actions and keep the actual interaction with "out" 
inside that ChatConnection, so if you want a registry of all current 
connections for example, that would be another actor that each 
ChatConnection interacts with through messages.

As you are a Lightbend customer, let's continue this through the support 
channel.

--
Johan

On Tuesday, July 5, 2016 at 4:12:03 PM UTC+2, ani...@egnaroinc.com wrote:
>
> I have a chat application developed in Akka and Scala using Play framework 
> WebSockets.
> I want to make it as an Api based service. For connection , i have used 
> the similar block from official documentaton as:
>
>
> object HandlerClass {
>  
>def props(out: ActorRef) = {
>   
>Props(new SocketHandlerClass(out))
>
> }
>
>   }
>
>
>
> def socket = WebSocket.accept[JsValue, JsValue] { request =>
>
> ActorFlow.actorRef(out =>
> HandlerClass.props(out) )
>   }
>
>
>
> I want to know if someone uses my chat system as an Api, how can i return 
> the 'out' actor, so that he/she can have the control over different 
> connections through different actors. Actually , it does not seem possible 
> to return the 'out' actor here. I also wanted to know how the incoming 
> message can also be captured before going for the 'SocketHandlerClass'?
>

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

[Johan Andrén]

Hard to say, what are you putting in your assembly jar, every akka module, 
if so I guess it could be the new Java DSL, but 9M sounds like a lot.

Make a diff of the contents of your respective assembly jars and see what 
is different. 
Maybe you can filter out things that you do not need if it is a problem for 
you.

--
Johan Andrén
Akka Team, Lightbend Inc.

On Saturday, June 4, 2016 at 11:35:54 AM UTC+2, xiefei wrote:
>
> Just upgrade my project from akka 2.4.3 to 2.4.7, the assembly jar gets 9M 
> bigger. 
> This is really a huge difference for a patch version update. 
> I am wondering what is the cause of this inflation. 
>
> On Friday, June 3, 2016 at 11:52:21 PM UTC+8, Johan Andrén wrote:
>>
>> Dear hakkers,
>>
>> we—the Akka committers—are proud to announce a new patch release of Akka 
>> 2.4. This release contains a number of minor improvements and fixes spread 
>> out across many of the Akka modules and the documentation. Some noteworthy 
>> changes in the 2.4.7 release are:
>>
>>- A resource leak in remoting fixed, and this also solved a problem 
>>when quickly reconnecting a cluster node multiple times in a sequence (
>>#20523 <https://github.com/akka/akka/issues/20523>, #20639 
>><https://github.com/akka/akka/issues/20639>)
>>- Easy usage of a circuit breaker from the HTTP routing DSLs (#20198 
>><https://github.com/akka/akka/issues/20198>)
>>- Akka persistence now has got a timeout for recovery events (#20698 
>><https://github.com/akka/akka/issues/20698>)
>>
>> The full list of changes since the last milestone is available under the 
>> 2.4.7 
>> milestone on github 
>> <https://github.com/akka/akka/issues?q=milestone%3A2.4.7+is%3Aclosed> for 
>> your reference.
>>
>> *Credits*
>>
>> Thanks to the Community! For this release we had the help of 32 
>> committers Special thanks for all contributions to the Java DSL 
>> documentation (#20466 <https://github.com/akka/akka/issues/20466>), it 
>> is great to see so many new contributors!
>>
>> Commits added removed
>>12 480 238 Patrik Nordwall
>> 8 421  64 Konrad Malawski
>> 41046  64 Hawstein
>> 3 122  17 Endre Sándor Varga
>> 3  59  12 Jan Pustelnik
>> 3 132   8 Johan Andrén
>> 2 196   5 Fabian Gutierrez
>> 2 403 474 Alexander Golubev
>> 2 242   7 Felipe Fernández
>> 2 624  11 Stefano Bonetti
>> 2  29  17 Jan Ypma
>> 2   4 186 Daniel Moran
>> 1   7   2 Erol Staveley
>> 1 128 128 Johan Andrén
>> 1   1   1 David Knapp
>> 1  33   1 Patryk Jażdżewski
>> 1  75  14 qian miao
>> 1 238   8 John Zhang
>> 1  91  31 zhxiaog
>> 1  60   5 Robert Budźko
>> 1  54  18 drewhk
>> 126852155 Björn Antonsson
>> 1  63  28 Richard Imaoka
>> 1   0  10 Jakub Kozłowski
>> 1   5   5 Yegor Andreenko
>> 1   1   1 Saeed Zarinfam
>> 1  26  23 Björn Antonsson
>> 1  42  42 2beaucoup
>> 1   9   6 Heiko Seeberger
>> 1 236  26 tjugo
>> 1  24   2 David Piggott
>> 1  18   3 Konstantin Fedorov
>>
>> Thanks a lot to every single one of you!
>>
>> 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] ANNOUNCE: Akka 2.4.7 Released

[Johan Andrén]

Dear hakkers,

we—the Akka committers—are proud to announce a new patch release of Akka 
2.4. This release contains a number of minor improvements and fixes spread 
out across many of the Akka modules and the documentation. Some noteworthy 
changes in the 2.4.7 release are:

   - A resource leak in remoting fixed, and this also solved a problem when 
   quickly reconnecting a cluster node multiple times in a sequence (#20523 
   <https://github.com/akka/akka/issues/20523>, #20639 
   <https://github.com/akka/akka/issues/20639>)
   - Easy usage of a circuit breaker from the HTTP routing DSLs (#20198 
   <https://github.com/akka/akka/issues/20198>)
   - Akka persistence now has got a timeout for recovery events (#20698 
   <https://github.com/akka/akka/issues/20698>)

The full list of changes since the last milestone is available under the 2.4.7 
milestone on github 
<https://github.com/akka/akka/issues?q=milestone%3A2.4.7+is%3Aclosed> for 
your reference.

*Credits*

Thanks to the Community! For this release we had the help of 32 committers 
Special thanks for all contributions to the Java DSL documentation (#20466 
<https://github.com/akka/akka/issues/20466>), it is great to see so many 
new contributors!

Commits added removed
   12 480 238 Patrik Nordwall
8 421  64 Konrad Malawski
41046  64 Hawstein
3 122  17 Endre Sándor Varga
3  59  12 Jan Pustelnik
3 132   8 Johan Andrén
2 196   5 Fabian Gutierrez
2 403 474 Alexander Golubev
2 242   7 Felipe Fernández
2 624  11 Stefano Bonetti
2  29  17 Jan Ypma
2   4 186 Daniel Moran
1   7   2 Erol Staveley
1 128 128 Johan Andrén
1   1   1 David Knapp
1  33   1 Patryk Jażdżewski
1  75  14 qian miao
1 238   8 John Zhang
1  91  31 zhxiaog
1  60   5 Robert Budźko
1  54  18 drewhk
126852155 Björn Antonsson
1  63  28 Richard Imaoka
1   0  10 Jakub Kozłowski
1   5   5 Yegor Andreenko
1   1   1 Saeed Zarinfam
1  26  23 Björn Antonsson
1  42  42 2beaucoup
1   9   6 Heiko Seeberger
1 236  26 tjugo
1  24   2 David Piggott
1  18   3 Konstantin Fedorov

Thanks a lot to every single one of you!

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-Http perf difference chunked vs non-chunked

[Johan Andrén]

I'd recommend you to use wireshark and look at how the JDK http client you 
are using actually is sending the data, also, let us know if you can get 
the same result but using other http clients. curl and wget comes to mind.

--
Johan

On Wednesday, June 1, 2016 at 11:42:04 AM UTC+2, daleksan wrote:
>
> Apologies for the delay. Project attached. Turns out google won't allow 
> zip attachments containing executables so I had to remove all gradle 
> executables from the project :-(
>
> Thank you
>
>  David 
>

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

[akka-user] Re: ANNOUNCE: Akka 2.4.6 Released!

[Johan Andrén]

It will be available on maven central shortly!

--
Johan Andrén
Akka Team, Lightbend Inc.

On Sunday, May 22, 2016 at 10:32:05 PM UTC+2, Thành Bùi Việt wrote:
>
> Dear Akka Team,
>
> Please publish version 2.4.6 for scala 2.12.0-M4.
>
> Thanks!
>
> On Thursday, May 19, 2016 at 11:06:43 PM UTC+7, Johan Andrén wrote:
>>
>> *Dear hakkers,*
>>
>> soon after releasing Akka 2.4.5 
>> <http://akka.io/news/2016/05/17/akka-2.4.5-released.html> with the new 
>> Routing DSL for Java it was discovered (thanks relgames 
>> <https://github.com/relgames>) that the akka-http-experimental artifact 
>> was incomplete (#20556 <https://github.com/akka/akka/issues/20556>), and 
>> the missing class files did in fact make parts of the high-level server 
>> APIs unusable.
>>
>> We are therefore with some urgency releasing a new minor update, Akka 
>> 2.4.6, to correct this.
>>
>> The small list of changes since 2.4.5 is available under the 2.4.6 
>> <https://github.com/akka/akka/issues?q=milestone%3A2.4.5> milestone on 
>> github for your reference.
>>
>> 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] ANNOUNCE: Akka 2.4.6 Released!

[Johan Andrén]

*Dear hakkers,*

soon after releasing Akka 2.4.5 
 with the new 
Routing DSL for Java it was discovered (thanks relgames 
) that the akka-http-experimental artifact was 
incomplete (#20556 ), and the 
missing class files did in fact make parts of the high-level server APIs 
unusable.

We are therefore with some urgency releasing a new minor update, Akka 
2.4.6, to correct this.

The small list of changes since 2.4.5 is available under the 2.4.6 
 milestone on 
github for your reference.

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: ANNOUNCE: Akka 2.4.5 Released!

[Johan Andrén]

Hi Antti, 

That was an unintentional consequence of a change to the build. We have now 
published it to maven central and are making sure it is in the next release 
by default.

Thanks for letting us know about it!
--
Johan Andrén
Akka Team, Lightbend Inc.

On Wednesday, May 18, 2016 at 2:38:49 PM UTC+2, Antti Nevala wrote:
>
> Great work. 
>
> Any reason why akka-osgi module is not included in the release?
>
> -Antti
>
> On Tuesday, May 17, 2016 at 1:01:47 PM UTC+3, Johan Andrén wrote:
>>
>> *Dear hakkers,*
>>
>> we—the Akka committers—are proud to announce a new minor release of Akka, 
>> 2.4.5 that contains some pretty major news for those of you who are using 
>> Akka HTTP with Java.
>>
>> *Rise of the “New” Java Routing DSL*
>>
>> This release contains the long-awaited “new” Routing DSL for Java 
>> <http://doc.akka.io/docs/akka/2.4.5/java/http/routing-dsl/index.html>, 
>> which is an initiative started a few months ago by Jan Ypma (jypma 
>> <https://github.com/jypma>) in which the Java and Scala DSLs were to be 
>> made more similar to each other. This has a number of benefits: simplifying 
>> the learning curve of either APIs, actually achieving feature parity 
>> between the APIs, and also a more Java8 feel thanks to the intense use of 
>> lambda expressions. Also, numerous issues were found and fixed during the 
>> transition – be sure to upgrade if you found problems in the old DSL.
>>
>> Today, we announce that the API has been completed, and except minor 
>> changes we do not expect to do any large refactorings like this one – we’re 
>> on our road to a stable Routing API. This sadly means that the changes are 
>> rather wide-spread, and migrating from old to new may feel like learning an 
>> entire new API (which it is). If you run into trouble migrating contact us 
>> via the mailing list or gitter chat; customers may of course ask for help 
>> via the Lightbend support portal.
>>
>> You will notice that directives documentation 
>> <http://doc.akka.io/docs/akka/2.4.5/java/http/routing-dsl/directives/alphabetically.html>
>>  is 
>> complete, however lacking code examples in some cases. We would like to ask 
>> for your help in finishing the docs by adding code examples – these efforts 
>> can be coordinated as part of the #20466 
>> <https://github.com/akka/akka/issues/20466> ticket.
>>
>> *Other important fixes and improvements:*
>>
>>- The cluster client and the cluster client receptionist now allow 
>>for subscribers to which the changes to the current set of contacts or 
>>clients will be announced. (#20446 
>><https://github.com/akka/akka/issues/20446>)
>>- FileIO streams factory methods using java.nio.Path added and the 
>>old File (#20390 <https://github.com/akka/akka/issues/20390>)
>>- A bug in the Akka scheduler making it stop running scheduled events 
>>in a long lived actor system (#20424 
>><https://github.com/akka/akka/issues/20424>), thanks to ecartner 
>><https://github.com/ecartner> for finding and reproducing this issue
>>- Registration of custom MediaTypes for Akka HTTP (#20397 
>><https://github.com/akka/akka/issues/20397>)
>>
>> The full list of changes since the last milestone is available under the 
>> 2.4.5 <https://github.com/akka/akka/issues?q=milestone%3A2.4.5> milestone 
>> on github for your reference.
>>
>> *Credits*
>>
>> Thanks to the Community! For this release we had the help of 48 
>> committers. Special thanks to Jan Ypma for his involvement in the 
>> development of the new Java routing DSL.
>>
>> Commits added removed
>>34   117084371 Konrad Malawski
>>3232052924 Johan Andrén
>>13 429 251 Patrik Nordwall
>> 7 889  96 Endre Sándor Varga
>> 7 180 223 2beaucoup
>> 6  67 114 Bernard Leach
>> 4 554 125 Robert Budźko
>> 4  37   5 poojadshende
>> 3 210 159 Daniel Moran
>> 3 331 175 Samuel Tardieu
>> 3  67  33 Nafer Sanabria
>> 2  29   3 Oleksii
>> 2  16  12 Tim Harper
>> 2  14  14 atemerev
>> 2  86  43 zhxiaog
>> 2  97  88 andreaTP
>> 2  14   1 Alexander Temerev
>> 239954059 Jan Ypma
>> 2  83  24 Ganeshwara Herawan Hananda Putra
>> 2 168   8 David Knapp
>> 1 169  20 Rémy-Christophe Schermesser
>

[akka-user] ANNOUNCE: Akka 2.4.5 Released!

[Johan Andrén]

*Dear hakkers,*

we—the Akka committers—are proud to announce a new minor release of Akka, 
2.4.5 that contains some pretty major news for those of you who are using 
Akka HTTP with Java.

*Rise of the “New” Java Routing DSL*

This release contains the long-awaited “new” Routing DSL for Java 
<http://doc.akka.io/docs/akka/2.4.5/java/http/routing-dsl/index.html>, 
which is an initiative started a few months ago by Jan Ypma (jypma 
<https://github.com/jypma>) in which the Java and Scala DSLs were to be 
made more similar to each other. This has a number of benefits: simplifying 
the learning curve of either APIs, actually achieving feature parity 
between the APIs, and also a more Java8 feel thanks to the intense use of 
lambda expressions. Also, numerous issues were found and fixed during the 
transition – be sure to upgrade if you found problems in the old DSL.

Today, we announce that the API has been completed, and except minor 
changes we do not expect to do any large refactorings like this one – we’re 
on our road to a stable Routing API. This sadly means that the changes are 
rather wide-spread, and migrating from old to new may feel like learning an 
entire new API (which it is). If you run into trouble migrating contact us 
via the mailing list or gitter chat; customers may of course ask for help 
via the Lightbend support portal.

You will notice that directives documentation 
<http://doc.akka.io/docs/akka/2.4.5/java/http/routing-dsl/directives/alphabetically.html>
 is 
complete, however lacking code examples in some cases. We would like to ask 
for your help in finishing the docs by adding code examples – these efforts 
can be coordinated as part of the #20466 
<https://github.com/akka/akka/issues/20466> ticket.

*Other important fixes and improvements:*

   - The cluster client and the cluster client receptionist now allow for 
   subscribers to which the changes to the current set of contacts or clients 
   will be announced. (#20446 <https://github.com/akka/akka/issues/20446>)
   - FileIO streams factory methods using java.nio.Path added and the old 
   File (#20390 <https://github.com/akka/akka/issues/20390>)
   - A bug in the Akka scheduler making it stop running scheduled events in 
   a long lived actor system (#20424 
   <https://github.com/akka/akka/issues/20424>), thanks to ecartner 
   <https://github.com/ecartner> for finding and reproducing this issue
   - Registration of custom MediaTypes for Akka HTTP (#20397 
   <https://github.com/akka/akka/issues/20397>)

The full list of changes since the last milestone is available under the 
2.4.5 <https://github.com/akka/akka/issues?q=milestone%3A2.4.5> milestone 
on github for your reference.

*Credits*

Thanks to the Community! For this release we had the help of 48 committers. 
Special thanks to Jan Ypma for his involvement in the development of the 
new Java routing DSL.

Commits added removed
   34   117084371 Konrad Malawski
   3232052924 Johan Andrén
   13 429 251 Patrik Nordwall
7 889  96 Endre Sándor Varga
7 180 223 2beaucoup
6  67 114 Bernard Leach
4 554 125 Robert Budźko
4  37   5 poojadshende
3 210 159 Daniel Moran
3 331 175 Samuel Tardieu
3  67  33 Nafer Sanabria
2  29   3 Oleksii
2  16  12 Tim Harper
2  14  14 atemerev
2  86  43 zhxiaog
2  97  88 andreaTP
2  14   1 Alexander Temerev
239954059 Jan Ypma
2  83  24 Ganeshwara Herawan Hananda Putra
2 168   8 David Knapp
1 169  20 Rémy-Christophe Schermesser
12570   3 Felix Satyaputra
1   2   3 Anil Gursel
1  10   7 kerr
1   1   1 Paweł Jurczenko
11044  30 leonidb
1  27   6 Stefano Bonetti
1  61   0 Oleksii Tkachuk
1   2   0 杨博 (Yang Bo)
1   2   2 Derek Wickern
1  18  14 Andrea Peruffo
1 610  34 Christopher Hunt
1  20   2 Mark van der Tol
1 129 134 hepin1989(虎鸣)
1   5   7 Leonid Bakaleynik
1  39   3 svezfaz
1   1   1 Alexey Noskov
1  11   0 jsuchenia
1 731  23 Rodolphe BELOUIN
1  10   4 Björn Antonsson
1   9   2 mumutu
1  74   0 Giovanni Caporaletti
1  51  77 Viktor Klang
1 285 123 Michał Kiędyś
1  61  33 Michał Płachta
1  23  13 Martynas Mickevicius
1  16   3 Priyanka Chordia
1   6   9 tpfeifer

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

[akka-user] Re: Akka Stream, Framing with GraphStage instead of PushPullStage: messages get lost

[Johan Andrén]

Hi again,

Yes, the fix was for the new FrameParser and not the old one. 

I cannot see any changes in the working example in your last message, but I 
have opened a ticket and a PR that it would be great if you could have a 
look at and confirm that it is the fix you applied:
https://github.com/akka/akka/pull/20522

--
Johan Andrén
Akka Team, Lightbend Inc.

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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, Framing with GraphStage instead of PushPullStage: messages get lost

[Johan Andrén]

Hi Qux,

I think it may be a bug in the sample, I think absorbTermination() in 
onUpstreamFinnish should be replaced with if (isAvailable(out)) run() but 
now nothing is done, If you can confirm that this solves the problem I'll 
fix the samples. Thanks.

--
Johan Andrén
Akka Team, Lightbend Inc.

On Thursday, May 12, 2016 at 2:25:54 PM UTC+2, Qux wrote:
>
>
>1. Hi,
>
> I have a Problem with Framing. I tried to build the ping-pong-example from 
> http://doc.akka.io/docs/akka/2.4.4/java/stream/stream-graphs.html. If I 
> run it over TCP, Messages get lost:
>
> trait Message
>> case class Ping(id: Int) extends Message
>> case class Pong(id: Int) extends Message
>> def toBytes(msg: Message): ByteString = {
>>   implicit val order = ByteOrder.LITTLE_ENDIAN
>>   msg match {
>> case Ping(id) =>
>>   ByteString.newBuilder.putByte(1).putInt(id).result()
>> case Pong(id) =>
>>   ByteString.newBuilder.putByte(2).putInt(id).result()
>>   }
>> }
>> def fromBytes(bytes: ByteString): Message = {
>>   implicit val order = ByteOrder.LITTLE_ENDIAN
>>   val it = bytes.iterator
>>   it.getByte match {
>> case 1 => Ping(it.getInt)
>> case 2 => Pong(it.getInt)
>> case other => throw new RuntimeException(s"parse error: expected 1|2 got 
>> $other")
>>   }
>> }
>> val codec = BidiFlow.fromFunctions(toBytes _, fromBytes _)
>> val framing = BidiFlow.fromGraph(create() { b =>
>>   implicit val order = ByteOrder.LITTLE_ENDIAN
>>
>>   def addLengthHeader(bytes: ByteString) = {
>> val len = bytes.length
>> ByteString.newBuilder.putInt(len).append(bytes).result()
>>   }
>>   class FrameParser extends GraphStage[FlowShape[ByteString, ByteString]] {
>> // this holds the received but not yet parsed bytes
>> val in = Inlet[ByteString]("FrameParser.in")
>> val out = Outlet[ByteString]("FrameParser.out")
>> override val shape = FlowShape.of(in, out)
>>
>> override def createLogic(inheritedAttributes: Attributes): 
>> GraphStageLogic = new GraphStageLogic(shape) {
>>
>>   // this holds the received but not yet parsed bytes
>>   var stash = ByteString.empty
>>   // this holds the current message length or -1 if at a boundary
>>   var needed = -1
>>
>>   setHandler(out, new OutHandler {
>> override def onPull(): Unit = {
>>   if (isClosed(in)) run()
>>   else pull(in)
>> }
>>   })
>>   setHandler(in, new InHandler {
>> override def onPush(): Unit = {
>>   val bytes = grab(in)
>>   stash = stash ++ bytes
>>   run()
>> }
>> override def onUpstreamFinish(): Unit = {
>>   if (stash.isEmpty) completeStage()
>>   // wait with completion and let run() complete when the
>>   // rest of the stash has been sent downstream
>> }
>>   })
>>   private def run(): Unit = {
>> if (needed == -1) {
>>   // are we at a boundary? then figure out next length
>>   if (stash.length < 4) {
>> if (isClosed(in)) completeStage()
>> else pull(in)
>>   } else {
>> needed = stash.iterator.getInt
>> stash = stash.drop(4)
>> run() // cycle back to possibly already emit the next chunk
>>   }
>> } else if (stash.length < needed) {
>>   // we are in the middle of a message, need more bytes,
>>   // or have to stop if input closed
>>   if (isClosed(in)) completeStage()
>>   else pull(in)
>> } else {
>>   // we have enough to emit at least one message, so do it
>>   val emit = stash.take(needed)
>>   stash = stash.drop(needed)
>>   needed = -1
>>   push(out, emit)
>> }
>>   }
>> }
>>   }
>>
>>   val outbound = b.add(Flow[ByteString].map(addLengthHeader))
>>   val inbound = b.add(Flow[ByteString].via(new FrameParser))
>>   BidiShape.fromFlows(outbound, inbound)
>> })
>>
>> val protocol = codec atop framing
>>
>> val server = Tcp().bind("127.0.0.1", 0).to(Sink.foreach {
>>   conn =>
>> conn.flow.join(protocol.reversed).join(Flow[Message].map {
>>   case Ping(id) => Pong(id)
>>   case Pong(id) => Ping(id)
>>   case other => println("error");

[akka-user] Re: Akka Remoting Ports

[Johan Andrén]

Hi Abud,

That's how TCP sockets work, you connect to a specific port, but the 
source-port your connection "comes from" is chosen randomly. See for 
example this SO question for someone asking the same question but about 
browser 
connections: 
http://stackoverflow.com/questions/21253474/source-port-vs-destination-port

--
Johan Andrén
Akka Team, Lightbend Inc.

On Tuesday, May 10, 2016 at 3:29:03 PM UTC+2, enovo...@gmail.com wrote:
>
> Hi,
> I have two remote actor systems deployed on two different cloud platforms, 
> one deployed on Google (port 80) and the other one on AWS (port 2552). I am 
> managing AWS machine only,  Google machine is being managed by client.
> I am instantiating connection from AWS actor to Google actor, sending a 
> message and receiving results back. I want to block all unnecessary ports, 
> so i added two rules to firewall
> 1. Allowed outbound connection to port 80  (to connect to remote actor)
> 2. Allowed incoming connection to port 2552 (to receive data back from 
> remote actor)
>
> Blocked all other ports, as soon as i block other ports, application stops 
> connecting with remote actor. I have verified that actor system is 
> listening at port 2552 (  [akka.tcp://Client@amd-machine:2552]  ).
>
> It turns out that connection is using some dynamic ports for AWS deployed 
> actor,  here are the logs of traffic captured using tcpdump command:
>
> 16:05:46.811270 IP 10.0.2.15.56756 > 102.150.24.190.80: Flags [S], seq 
> 1968780725, win 29200, options [mss 1460,sackOK,TS val 6205965 ecr 
> 0,nop,wscale 7], length 0
> 16:05:46.849800 IP 102.150.24.190.80 > 10.0.2.15.56756: Flags [S.], seq 
> 2602112001, ack 1968780726, win 65535, options [mss 1460], length 0
> 16:05:46.849841 IP 10.0.2.15.56756 > 102.150.24.190.80: Flags [.], ack 1, 
> win 29200, length 0
> 16:05:46.850027 IP 10.0.2.15.56756 > 102.150.24.190.80: Flags [F.], seq 1, 
> ack 1, win 29200, length 0
> 16:05:46.850164 IP 102.150.24.190.80 > 10.0.2.15.56756: Flags [.], ack 2, 
> win 65535, length 0
>
> where
> 102.150.24.190.80 is Google actor address 
> 10.0.2.15.56756 is AWS actor address 
> as can be seen from above logs, that actor system is picking some dynamic 
> port for remote communication. 
>
> Could anybody please help me understand why dynamic port is being used 
> when actor system is listening at port 2552, and how can i make sure 
> dynamic port is not used?
>
> Regards
> Abud
>
>
>
>
>
>

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

[Johan Andrén]

Hi Durga,

I'm not sure. Please open a ticket describing what you think should be 
added and we can take the discussion there, thanks!

--
Johan Andrén
Akka Team, Lightbend Inc.


On Wednesday, May 4, 2016 at 12:22:07 PM UTC+2, Durga Prasana wrote:
>
> Hi Johan,
>
> That should work. However, solving it this way would mean non-DRY 
> implementation throughout a graph's stages. Soon, users would want to get 
> insight into how each of their stage is processing & that insight could be 
> some derived info (which can only be determined in specific stage 
> correspondingly). In such scenario it becomes imperative that stages have 
> provision for users to plug-in their own custom metric / stat recorder. 
> (while some out-of-the-framework stats support exists as default) 
>
> Can we submit this ask as a feature / improvement request onto akka ?
>
> Thanks,
>
>
> On Friday, 29 April 2016 13:38:47 UTC+5:30, Durga Prasana wrote:
>>
>> Hi,
>>
>> We're using akka-streams to process a stream of messages, which result in 
>> some actions.
>> Now, we need to find the number of messages being processed by the stream 
>> (well, not that plain vanilla, actually each message has a set of 
>> attributes, say, m_type, m_cmp, m_origin, ...).
>>
>> One solution would be to have a counter in one of the stages that would 
>> keep track of that & update.
>> Other I'm hinted from the akka-docs could be the `M` materialized values 
>> of the stream (that we seldom use currently). However, I'm not so sure, how 
>> to start a runnable-graph once, & then keep on invoking the materialized 
>> value at each interval of let's say 5 mins (to kind of find messages 
>> processed so far) ?
>>
>>
>> We need the stream running continuously, so, doing a someGraph.run again 
>> and again doesn't make sense to find the materialized value at various 
>> intervals.
>>
>> http://doc.akka.io/docs/akka/2.4.4/scala/stream/stream-quickstart.html#reactive-tweets
>>
>> Would be thankful for some guidance here.
>>
>> Thanks,
>> Durga
>>
>

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

[Johan Andrén]

Tim,

Great to hear!

Note that all mutable state should go in the GraphStageLogic, as the 
GraphStage is a blueprint that you can create once and materialize multiple 
time.

--
Johan Andrén
Akka Team, Lightbend Inc.

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

[Johan Andrén]

Hi Durga,

One way would be to keep those stats in an actor, and have a branch that 
sends that data to it.

Something like this:

val statsActorSink = Sink.actorRef(refToStatsActor, Done)
regularSource.alsoTo(statsActorSink).via(regularProcessingFlow).to(regularSink)

This will send every event in the stream to the actor for calculating 
stats. 
You can then query that actor or periodically publish the stats somewhere 
from it depending on what you need.

--
Johan Andrén
Akka Team, Lightbend Inc.


On Friday, April 29, 2016 at 10:08:47 AM UTC+2, Durga Prasana wrote:
>
> Hi,
>
> We're using akka-streams to process a stream of messages, which result in 
> some actions.
> Now, we need to find the number of messages being processed by the stream 
> (well, not that plain vanilla, actually each message has a set of 
> attributes, say, m_type, m_cmp, m_origin, ...).
>
> One solution would be to have a counter in one of the stages that would 
> keep track of that & update.
> Other I'm hinted from the akka-docs could be the `M` materialized values 
> of the stream (that we seldom use currently). However, I'm not so sure, how 
> to start a runnable-graph once, & then keep on invoking the materialized 
> value at each interval of let's say 5 mins (to kind of find messages 
> processed so far) ?
>
>
> We need the stream running continuously, so, doing a someGraph.run again 
> and again doesn't make sense to find the materialized value at various 
> intervals.
>
> http://doc.akka.io/docs/akka/2.4.4/scala/stream/stream-quickstart.html#reactive-tweets
>
> Would be thankful for some guidance here.
>
> Thanks,
> Durga
>

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

[Johan Andrén]

Hi Radi,

The UntypedActorWithUnrestrictedStash does not enforce a concrete mailbox 
but the chosen mailbox must still implement 
akka.dispatch.DequeBasedMessageQueueSemantics. This is missing from the 
Java API docs I'm afraid, I have opened a ticket to fix 
that: https://github.com/akka/akka/issues/20447

--
Johan Andrén
Akka Team, Lightbend Inc.

On Friday, April 29, 2016 at 4:00:36 PM UTC+2, Radi Radichev wrote:
>
> Hi,
>
> I'm trying to create an UntupedActorWithStash in java, and for my use case 
> I need to use a UnboundedPriorityMailbox. I have created my actor to extend 
> UntypedActorWithUnrestrictedStash and implementing 
> RequiresMessageQueue, I also create 
> my actor with a dispatcher which has the PriorityMailbox as mailbox type. 
> However every time I try to create my actor I get the error:
>
> akka.actor.ActorInitializationException: DequeBasedMailbox required, got: 
> akka.dispatch.UnboundedPriorityMailbox$MessageQueue
>
> What am I missing here? I thought the UntypedActorWithUnrestrictedStash 
> does not enforce a queue type?
>
> Basically what I'm trying to achieve is:
>
> I have an aggregator actor which broadcasts a message to a whole load of 
> other actors and changes it's context to start to listen to replies from 
> those other actors. The actor replies to the sender of the original message 
> if all the replies are collected or if a scheduled timeout message is 
> received. So my plan is to use the priority mailbox to set the timeout 
> priority to higher than the other replies, and thus force the actor to 
> either return all the replies or just the replies which it got when it 
> received a timeout.
>
> Any advice here?
>
> Thanks,
> Radi Radichev
>

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

[Johan Andrén]

Hi Abe,

Can you repeat this? 

The only explanation I can think of is that there was one node added (the 
first) and then removed, causing actor c1 and c2 to be added but then 
removed.

--
Johan Andrén
Akka Team, Lightbend Inc.


On Tuesday, April 26, 2016 at 6:32:14 PM UTC+2, Abe Sanderson wrote:
>
> I am doing some experimenting using cluster aware round robin pool 
> routers.  I started to see some issues with dropped messages under heavy 
> load, and went digging around in logs and in the akka code.  With the 
> cluster setup of 3 nodes, 2 instance per node, 6 total instance, I can see 
> in logs creation for 6 routees, but the names seemed off a bit:
>
> /user/client/c3
> /user/client/c4
> /user/client/c5
> /user/client/c6
> /user/client/c7
> /user/client/c8
>
>
> I was worried that possibly c1 and c2 were created, but were removed for 
> some reason and the routers never updated the remote references.  However, 
> I can't see any thing in logs that shows the creation.  No lifecycle 
> messages showing these routees associated to remote nodes, nothing about 
> another node starting up, no dead letter references.  Looking at the code, 
> there is an atomic counter for the name on routee creation:
>   override private[akka] def newRoutee(routeeProps: Props, context: 
> ActorContext): Routee = {
> val name = "c" + childNameCounter.incrementAndGet
> val ref = context.asInstanceOf[ActorCell].attachChild(
>   local.enrichWithPoolDispatcher(routeeProps, context), name, 
> systemService = false)
> ActorRefRoutee(ref)
>   }
>
> I am totally confounded on this.  Anybody have insight?
>

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

[Johan Andrén]

Hi Tim,

In the example code you backpressure on overflow, detecting back pressure 
is tricky as it is about detecting lack of demand flowing upstream, which 
could be caused by other reasons than the buffer overflowing.

I think that if you really need to know if the buffer is full it the best 
way would be to create a custom buffering GraphStage that signals that. 

In general you should prefer the GraphStage API to using the 
ActorSubscriber and ActorPublisher abstractions unless you explicitly need 
an actor for some reason - they will force an async boundary on you and is 
easier to get wrong than the GraphStage API which explicitly deals with 
demand.

--
Johan Andrén
Akka Team, Lightbend Inc.

On Saturday, April 30, 2016 at 12:51:33 AM UTC+2, Tim Harper wrote:
>
> A pretty common thing I've to do is to call a (non-blocking, brief) 
> callback in the event of an overflow. Usually to send a quick message to 
> the logger.
>
> Here's how I normally solve the problem:
>
>   val (input, completed) = Source.actorRef[Int](0, 
> OverflowStrategy.dropNew).
> conflate { (prior, overflown) =>
>   println(s"dropping overflown ${overflown}")
>   prior
> }.
> buffer(10, OverflowStrategy.backpressure).
> async.
> toMat(Sink.foreach { n =>
>   println(n)
>   Thread.sleep(100)
> })(Keep.both).
> run
>
>   (1 to 50).foreach { n =>
> input ! n
> println(s"sent ${n}")
> Thread.sleep(10)
>   }
>
>
> (full source here 
> <https://gist.github.com/timcharper/74e1182badd8458d723bca4c8641280f>)
>
> But this is rather verbose. Is there a more concise way to have support 
> behavior?
>
> Another problem with this approach is that I'm creating two async 
> boundaries being created (after the actorRef, and then after the conflate); 
> that's less efficient than I'd prefer.
>
> Is the best way to do this is to create a custom ActorSubscriber ?
>
> Tim
>

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

[akka-user] Re: Parallel runnable graphs

[Johan Andrén]

Hi Arun,

There isn't really a right or wrong per se, it depends on what models your 
problem domain best. In some cases that will be one stream doing 10 things 
in parallell and in some cases it will be 10 separate streams doing things 
in parallell. 

If you expect to aggregate some information, if any of the operations on 
the streams should interact across the streams, or if one failure should 
fail all the streams that would be good reasons to choose one stream over 
many.

Side note: I guess you included the sample graph just as an example, but if 
your graph is that simple there is no need at all to use the GraphDSL, just 
use the Flow API instead: 'Source(start to 
end).map(_.toString).to(Sink.foreach(x => println(s"$name: $x"))'

--
Johan Andrén
Akka Team, Lightbend Inc.

On Monday, April 25, 2016 at 7:08:40 PM UTC+2, Arun wrote:
>
> Hi,
>
> Need suggestion, I need to run parallel multiple source graphs, for 
> example I have created this sample code where I am creating 10 graphs and 
> running them parallel. 
>
> Is this right approach or should I create multiple source inside a graph 
> and run them parallel in one graph?
>
>
> def createGraph(start: Int, end: Int, name: String) = {
>   RunnableGraph.fromGraph(GraphDSL.create() {
> implicit builder =>
>   import GraphDSL.Implicits._
>   val s = Source(start to end)
>   val f = Flow[Int].map[String](x => x.toString)
>   val sink = Sink.foreach[String](x => println(name + ":" + x))
>
>   val t = builder.add(s)
>
>   val flow1 = builder.add(f)
>
>   t ~> flow1 ~> sink
>
>   ClosedShape
>   })
> }
>
>
> (1 to 10).map(x => createGraph(x, x + 10, "g" + x)).map(_.run())
>
>
> Thanks & Regards,
>
> Arun
>
>

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

[Johan Andrén]

Hi Morten,

Maybe this blog post I wrote recently can be of use to you figure it out:
https://markatta.com/codemonkey/blog/2016/04/18/chat-with-akka-http-websockets/

Cheers
--
Johan Andrén
Akka Team, Lightbend Inc.


On Tuesday, April 26, 2016 at 8:54:09 PM UTC+2, Morten Lund wrote:
>
> I'm new to AKKA Streams. (Using Akka v 2.4.4) I am trying to create a 
> Websocket which can push new notifications to subscribed clients. My 
> strategy is to implement a ActorPublisher, which I later can send a message 
> to, and then get it pushed to clients.
>
> To get started I copied an example of a ActorPublisher:
>
> case class Tick()
> class TickActor extends ActorPublisher[Int] {
>   import scala.concurrent.duration._
>
>   implicit val ec = context.dispatcher
>
>   val tick = context.system.scheduler.schedule(1 second, 1 second, self, 
> `Tick())`
>
>   var cnt = 0
>   var buffer = Vector.empty[Int]
>
>   override def receive: Receive = {
> case Tick() => {
>   cnt = cnt + 1
>   if (buffer.isEmpty && totalDemand > 0) {
> onNext(cnt)
>   }
>   else {
> buffer :+= cnt
> if (totalDemand > 0) {
>   val (use,keep) = buffer.splitAt(totalDemand.toInt)
>   buffer = keep
>   use foreach onNext
> }
>   }
> }
>   }
>
>   override def postStop() = tick.cancel()}
>
> My problem is that I don't know how to use it as source.
>
> I have tried the following:
>
> val source: Source[Strict, ActorRef] = 
> Source.actorPublisher(Props[TickActor]).map(i => TextMessage(i.toString))
>   optionalHeaderValueByType[akka.http.scaladsl.model.ws.UpgradeToWebSocket]() 
> {
> case Some(upgrade) =>
>   complete(
> upgrade.handleMessagesWithSinkSource(Sink.ignore,source))
> case None =>
>   reject(akka.http.scaladsl.server.ExpectedWebSocketRequestRejection)
>   }
>
> But when I connect with a client I get the following ClassCastException: 
> java.lang.ClassCastException: java.lang.Integer cannot be cast to 
> scala.runtime.Nothing$
>
> If I change the Source to:
>
> val src: Source[Strict, NotUsed] = Source.fromIterator(() => 
> Iterator.continually(ThreadLocalRandom.current.nextInt()))
>   .filter(i => i > 0 && i % 2 == 0).map(i => TextMessage(i.toString))
>
> It runs just fine.
>
> I struggling a bit connecting the dots, so hopefully you can lead me in 
> the correct direction.
>

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

[Johan Andrén]

Hi Mike,

There currently is no such stage, something like dynamic pub-sub (we have some 
ideas that you can read about in this ticket: 
https://github.com/akka/akka/issues/19478 
<https://github.com/akka/akka/issues/19478>), so to do that you would have to 
either write your own stage for it or do it with actors (but then you loose 
backpressure).

--
Johan Andrén
Akka Team, Lightbend Inc.
 

> 20 apr. 2016 kl. 09:58 skrev Mike Limansky <mike.liman...@gmail.com>:
> 
> Hi Johan,
> 
>   I meant I'd like to merge data from all incoming connections to one output.
> 
> 
> 
> вторник, 19 апреля 2016 г., 21:50:18 UTC+3 пользователь Johan Andrén написал:
> Hi Mike,
> 
> The problem is that you create one outgoing connection, but you cannot use 
> that more than once. If you move that logic to create a new outgoing 
> connection on every new incoming it will work better, so that would be inside 
> of your foreach.
> 
> Please take a look at the docs for doing IO with Streams here: 
> http://doc.akka.io/docs/akka/2.4.4/scala/stream/stream-io.html#Streaming_TCP 
> <http://doc.akka.io/docs/akka/2.4.4/scala/stream/stream-io.html#Streaming_TCP>
>  
> (I think that will answer most of your questions)
> 
> --
> Johan Andrén
> Akka Team, Lightbend Inc.
> 
> On Tuesday, April 19, 2016 at 5:44:27 PM UTC+2, Mike Limansky wrote:
> Hi all,
> 
>   I'm very new to Akka Streams, trying to get the ideas behind the streams 
> and how to use them. I'd like to make a very simple thing: to connect two TCP 
> server sockets, but I get stuck with that.
> 
>   If I have server and client connections, it more or less clear for me:
> 
>   val conn = Tcp().bind("localhost", 1234)
>   val out = Tcp().outgoingConnection("localhost", 2345)
>  
>   val handler = Sink.foreach[Tcp.IncomingConnection] { c =>
> println("Got connection from " + c.remoteAddress)
> c.handleWith(out)
>   }
> 
>   conn.to(handler).run()
> 
> 
>   This working for one connection. Could anybody give me a clue how to get it 
> work with more that one incoming connections (I suppose I need to use Merge, 
> or Source.combine)?
> 
>   And the second question. As I understand this works in one direction (from 
> server socket to client). How can I use BidiFlow in such situation?
> 
>   Finally, If I have two server connections I have no idea how to achieve 
> same result. Should I use mutable state to store incoming connections?
>  
> --
> BR,
> Mike.
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/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 a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/AvFbNTKMEdo/unsubscribe 
> <https://groups.google.com/d/topic/akka-user/AvFbNTKMEdo/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> akka-user+unsubscr...@googlegroups.com 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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

Re: [akka-user] Re: What config affects the number of threads for an ActorSystem?

[Johan Andrén]

It was more this specific section of the docs I was hoping you'd notice:


   1. # Configuration for the fork join pool
   2. fork-join-executor {
   3. # Min number of threads to cap factor-based parallelism number to
   4. parallelism-min = 2
   5. # Parallelism (threads) ... ceil(available processors * factor)
   6. parallelism-factor = 2.0
   7. # Max number of threads to cap factor-based parallelism number to
   8. parallelism-max = 10
   9. }
   10. 
   

Note how the parallelism-max is a cap, the actual number is calculated by 
multiplying the number of cores with the parallelism-factor and then 
capping it with the min and max to arrive at the actual number on a given 
computer.

The specific number of 50 is hard to say anything concrete about without 
more info, but note that you will have a number of threads in the JVM not 
being dispatcher threads and even some unrelated to Akka. The dispatcher 
threads are easy to recognize as they are named 
"[systemname]-actor.default-dispatcher-[n]".

--
Johan Andrén
Akka Team, Lightbend Inc.


On Tuesday, April 19, 2016 at 4:16:05 PM UTC+2, Steve Rehrauer wrote:
>
> Thanks, Johan.
>
> I did see that page, but if I understand the dispatcher config, the actor 
> name you can define can't be a pattern?  We define many actors without 
> simple names like "myActor".  In order to define a dispatcher for these 
> actors, I presume I'd need to make a code change to use that dispatcher 
> when the actors are created?
>
> Long term, that's what I'll want to do.  Short term, I was hoping to find 
> a pure config way to fix this.  Would be happy to override the default 
> dispatcher's config, if that were possible, for a short-term fix.
>
>

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

[Johan Andrén]

Yet another thing to test could be to pre-fuse your Request => Response 
flow, first, and then run that with autoFusing turned on or off. Locally I 
get the best improvement with pre-fusing and no autoFusing. Looks like this:

  implicit val materializer = 
ActorMaterializer(ActorMaterializerSettings(system))

val routes = 
  path("benchmark") {
get {
  complete("ok")
}
  }

val flow: Flow[HttpRequest, HttpResponse, NotUsed] = routes

val prefused = Fusing.aggressive(flow)

Http().bindAndHandle(
  handler = Flow.fromGraph(prefused),
  interface = "localhost",
  port = 9000)

--
John Andrén
Akka Team, Lightbend Inc.


On Monday, April 18, 2016 at 9:11:10 PM UTC+2, Johan Andrén wrote:
>
> One thing that could be interesting to try out if you want to achieve as 
> high throughput as possible where each new request is a new connection with 
> the current akka-http version is to disable autoFusing (which is pretty 
> costly). That can be done when you create the materializer like this: 
>
>   
> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>
> This will of course come at the cost where persistent connections get a 
> performance hit instead.
>
> --
> John Andrén
> Akka Team, Lightbend Inc.
>  
>
> On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>>
>> Adam, thanks!
>>
>> Very informative. I also have found handy to use almost empty response to 
>> estimate the whole request-response chain itself (starting from now 
>> abandoned tiscaf [1] and rising rps up to almost 90K on humble workstation 
>> :) ).
>>
>> [1] http://gaydenko.com/scala/tiscaf/httpd/
>>
>

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

[Johan Andrén]

One thing that could be interesting to try out if you want to achieve as 
high throughput as possible where each new request is a new connection with 
the current akka-http version is to disable autoFusing (which is pretty 
costly). That can be done when you create the materializer like this: 

  ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))

This will of course come at the cost where persistent connections get a 
performance hit instead.

--
John Andrén
Akka Team, Lightbend Inc.
 

On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>
> Adam, thanks!
>
> Very informative. I also have found handy to use almost empty response to 
> estimate the whole request-response chain itself (starting from now 
> abandoned tiscaf [1] and rising rps up to almost 90K on humble workstation 
> :) ).
>
> [1] http://gaydenko.com/scala/tiscaf/httpd/
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: ActorSystem.terminate() couldn't fully terminate the system

[Johan Andrén]

Hi Emily,

That specific stack trace is just the threadpool parking the thread waiting 
for work, the if there is a thread that is occupied with something, it 
would show some of your application classes and methods in it's stack trace.

Are you using the latest Cassandra driver? Any special configuration for 
cassandra? It sounds unlikely, but of course not impossible, that there 
would be something in the Cassandra driver blocking and stopping your actor 
system from stopping.

--
John Andrén
Akka Team, Lightbend Inc.

On Monday, April 18, 2016 at 7:55:14 PM UTC+2, Yan Pei wrote:
>
> I've simplified the Application to test this scenario by just printing out 
> simple message inside the AbstractPersistentActorWithAtLeastOnceDelivery 
> actor but with cassandra configuration inside application.conf.
>
> After changing the persistence from the cassandra to leveldb, the 
> system.terminate() works well. 
>
> So looks like the cassandra diver is the blocking tread.
>
> Should I do anything before calling system.terminate() once I enable the 
> cassandra configuration?
>
> Thanks,
> Emily
>
>
> On Monday, April 18, 2016 at 10:59:08 AM UTC-5, Johan Andrén wrote:
>>
>> Hi Emily,
>>
>> If an actor is blocking a thread and never returns it to the ActorSystem 
>> cannot do much about it, and if you try to terminate the ActorSystem it 
>> will never complete terminating. 
>>
>> Blocking a thread could be actual processing that never stops or just 
>> takes a very long time, being stuck reading or writing some blocking 
>> resource, etc. You should be able to see what is going on by connecting to 
>> the JVM and taking a thread dump - this should show at least one thread 
>> having a call stack into one of your actors.
>>
>> --
>> Johan Andrén
>> Akka Team, Lightbend Inc.
>>
>>
>> On Monday, April 18, 2016 at 5:53:17 PM UTC+2, Yan Pei wrote:
>>>
>>> ActorSystem.terminate() works well with certain number of actors inside 
>>> the system.
>>>
>>> Once I increase the actor number, the system().terminate() couldn't 
>>> terminate the system, the application just hung on there and I have to 
>>> manually kill it.
>>> (running from Eclipse)
>>>
>>> From the log it's trying to:
>>> [DEBUG] [04/18/2016 10:44:58.530] 
>>> [ActorSystemmainaroraid1-akka.actor.default-di
>>> spatcher-2] [EventStream] shutting down: StandardOutLogger started
>>>
>>> Anyone knows what's going on?
>>>
>>> Thanks very much!
>>> Emily
>>>
>>

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

[Johan Andrén]

Hi Steve,

Did you have a look at the docs about dispatcher configuration?
http://doc.akka.io/docs/akka/2.4.2/scala/dispatchers.html#default-dispatcher

--
Johan Andrén
Akka Team, Lightbend Inc.


On Sunday, April 17, 2016 at 3:29:49 PM UTC+2, Steve Rehrauer wrote:
>
> I have an application that doesn't specify a custom dispatcher.
>
> We see the number of threads maxing out at 50, and would like to increase 
> it.
>
> This doesn't seem to line up with any of the default config I see in 
> Akka?  I see 
>
>  akka.actor.default-dispatcher.fork-join-executor.parallelism-max = 64
>
> and I've tried raising this particular config, but still don't see more 
> than 50 active threads.
>
> How can I affect this?
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: ActorSystem.terminate() couldn't fully terminate the system

[Johan Andrén]

Hi Emily,

If an actor is blocking a thread and never returns it to the ActorSystem 
cannot do much about it, and if you try to terminate the ActorSystem it 
will never complete terminating. 

Blocking a thread could be actual processing that never stops or just takes 
a very long time, being stuck reading or writing some blocking resource, 
etc. You should be able to see what is going on by connecting to the JVM 
and taking a thread dump - this should show at least one thread having a 
call stack into one of your actors.

--
Johan Andrén
Akka Team, Lightbend Inc.


On Monday, April 18, 2016 at 5:53:17 PM UTC+2, Yan Pei wrote:
>
> ActorSystem.terminate() works well with certain number of actors inside 
> the system.
>
> Once I increase the actor number, the system().terminate() couldn't 
> terminate the system, the application just hung on there and I have to 
> manually kill it.
> (running from Eclipse)
>
> From the log it's trying to:
> [DEBUG] [04/18/2016 10:44:58.530] 
> [ActorSystemmainaroraid1-akka.actor.default-di
> spatcher-2] [EventStream] shutting down: StandardOutLogger started
>
> Anyone knows what's going on?
>
> Thanks very much!
> Emily
>

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

[Johan Andrén]

In general you should seldom have to write your own stages as there is a very 
rich set of built in stages provided. For example if you have a 
request-response you want to perform with an actor you can use mapAsync to 
interact with the actor from a stream. Something like this:

val myProcessingActor: ActorRef = ???
val mySource: Source[Thing, NotUsed] = ???

val responses: Source[Response, NotUsed] = 
  mySource.mapAsync(1)(thing => (myProcessingActor ? 
Request(thing)).mapTo[Response])

responses.runForeach(println)

The first parameter to mapAsync specifies the maximum number of concurrent 
ongoing requests, if there is only one actor there is no need to allow more 
than 1 concurrent outstanding request as they will just queue up in the actor 
mailbox if you do.

When you materialize a stream using run it will be running inside one or more 
actors, but that is an internal implementation detail and the only part of that 
you will see is having to provide an ActorSystem to the ActorMaterializer which 
is needed to materialize a flow.

--
Johan Andrén
Akka Team, Lightbend Inc.


> 17 apr. 2016 kl. 04:35 skrev Guofeng Zhang <guofen...@gmail.com>:
> 
> Johan,
> 
> I read it, but Integration with actors is only a stub part. There is no 
> sample to demo how to do it. Is there any link or akka-stream test cast to 
> demo how to do it in detail?
> 
> Another question, the doc says that for a stream there are actors created to 
> run the stream. so if I use akka-stream, shall still need to coding actors 
> for a stream?
> 
> Thanks for your reply very much!
> 
> Guofeng
> 
> 
> 
> 
> On Sat, Apr 16, 2016 at 2:16 AM, Johan Andrén <johan.and...@typesafe.com 
> <mailto:johan.and...@typesafe.com>> wrote:
> Hi Goufeng,
> 
> I would recommend you to read up on GraphStage rather than the 
> ActorSubscriber and ActorPublisher as it is a much more straight forward way 
> to create custom stages. You can find a pretty thorough walkthrough of how it 
> works and nice code samples in Java for GraphStage in the docs here: 
> http://doc.akka.io/docs/akka/2.4.4/java/stream/stream-customize.html 
> <http://doc.akka.io/docs/akka/2.4.4/java/stream/stream-customize.html>
> 
> --
> Johan Andrén
> Akka Team, Lightbend Inc.
> 
> 
> 
> On Wednesday, April 13, 2016 at 8:58:45 AM UTC+2, Guofeng Zhang wrote:
> Hi,
> 
> I am learning akka-stream, so I want to understand the low-level detail. I 
> found the following post is very useful for my case:
> http://bryangilbert.com/blog/2015/02/04/akka-reactive-streams/ 
> <http://bryangilbert.com/blog/2015/02/04/akka-reactive-streams/>
> 
> In this post, the processor is defined in Scala as the following:
> class DoublingProcessor extends ActorSubscriber with 
> ActorPublisher[BigInteger] { }
> 
> My question is:
>  How to define the above process in Java?
> 
> Thanks for your help.
> 
> Guofeng
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/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 Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/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 receive

[akka-user] Re: akka-stream: How to define a Processor in Java

[Johan Andrén]

Hi Goufeng,

I would recommend you to read up on GraphStage rather than the 
ActorSubscriber and ActorPublisher as it is a much more straight forward 
way to create custom stages. You can find a pretty thorough walkthrough of 
how it works and nice code samples in Java for GraphStage in the docs 
here: http://doc.akka.io/docs/akka/2.4.4/java/stream/stream-customize.html

--
Johan Andrén
Akka Team, Lightbend Inc.



On Wednesday, April 13, 2016 at 8:58:45 AM UTC+2, Guofeng Zhang wrote:
>
> Hi,
>
> I am learning akka-stream, so I want to understand the low-level detail. I 
> found the following post is very useful for my case:
> http://bryangilbert.com/blog/2015/02/04/akka-reactive-streams/
>
> In this post, the processor is defined in Scala as the following:
> class DoublingProcessor extends ActorSubscriber with 
> ActorPublisher[BigInteger] { }
>
> My question is:
>  How to define the above process in Java?
>
> Thanks for your help.
>
> Guofeng
>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Why does TestKit maintain the same ActorSystem between tests?

[Johan Andrén]

Hi Spencer,

ActorSystems are semi-expensive, starting the dispatcher thread pool etc. 
on startup so this is the rationale for sharing one throughout the test. 
TestKit is built around this and will require a single actor system 
throughout the test. As there are no ties to any specific testing framework 
in the akka testkit there isn't anything shipped with it that hooks up 
before-and-after style hooks - those would be test framework specific. Most 
of the tools that make up testkit is however not dependent on TestKit but 
can be used stand-alone. Starting your actor system is one line of code, 
and shutting it down is one line (TestKit.shutdownActorSystem(system)) so 
hooking it into any test framework should not be much work.
For ScalaTest you can read about using BeforeAndAfter here: 
http://www.scalatest.org/user_guide/sharing_fixtures#beforeAndAfter 
especially the "Calling loan fixture-fixture methods" section where the 
ActorSystem would be what you loan into each test case.

In general if you keep your actors loose coupled and keep them from knowing 
about the absolute paths to other actors tests will be isolated enough even 
if they share actor system that they can even run simultaneously. Some 
times you need isolation though, I wouldn't say that in itself is a smell. 
If no single actor in your entire app can be tested without being isolated 
it may be something to think twice about though.

I hope this helps!
--
Johan Andrén
Akka Team, Lightbend Inc.

On Thursday, April 14, 2016 at 9:06:21 PM UTC+2, Spencer Judge wrote:
>
> I started writing some tests using the TestKit, and it's quite nice - but 
> I quickly realized the ActorSystem persists between tests. This seems a bit 
> odd to me, since it introduces potential coupling between the order of test 
> execution and their results. It doesn't feel like what I would expect the 
> default behavior to be.
>
> Is there a particular reason for this? Is the fact that I want to reset my 
> system between each test a smell? I want to do this in my particular test 
> class because I am testing persistence.
>
> Lastly, is there an easy way to change the behavior?
> I found this old thread:
> https://groups.google.com/forum/embed/#!topic/akka-user/-Cvf9K5P0a0
>
> Which has a solution, albeit a somewhat complicated one. It seems like 
> this would be a very good thing to be able to do simply, without needing to 
> create and destroy a new ActorSystem for every test manually (ex: have a 
> "reset system" method I can call in test teardown). I'm wondering if 
> there's an easier way to do it today.
>
> Thank you!
> Spencer
>

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

[akka-user] Re: Akka Persistence: Where do the execution of the Command Goes when it is not simply a state update

[Johan Andrén]

Hi Maatary,

What you persist should be a domain event and contain all information you 
need to replay that change, so if you need to fetch data from an external 
service then it is very likely that the event should contain that data, or 
the result of a calculation with that data. You do not however update the 
state using that data (or calculation result) until you have persisted it 
and know that it will be replayed if the actor is restarted. So in 
pseudocode:

case FetchLastHistoryChangeSet =>
  val data = otherService()
  // it is ok to read the internal state here, for the calculation
  val resultOfCalculation = calculate(data)
  persist(EventHappened(resultOfCalculation)) { event => 
// but this is the only place it is ok to change the internal state
updateState(event.resultOfCalculation) 
  }


I hope this helps
--
Johan Andrén
Akka Team, Lightbend Inc.



On Thursday, April 7, 2016 at 6:09:36 AM UTC+2, Maatary Okouya wrote:
>
> Just for clarification: Where do the execution of a command goes, when the 
> execution is not simply a state update (like in most examples found online)
>
> For instance, in my case,
>
>- 
>
>The *Command* is *FetchLastHistoryChangeSet* which consist in fetching 
>the last history changeset from an external service based on where we left 
>off last time. In other words the time of the newest change of the 
> previous 
>history ChangeSet Fetched.
>- 
>
>The *Event* would be *HistoryChangeSetFetched(changeSet, time)*. In 
>correlation to what has been said above, the time should be that of the 
>newest change of the newly history ChangeSet Fetched (as per the command 
>event currently being handled)
>
> Now in all example that i see, it is always: (i) *validating the command*, 
> then, (ii) *persisting the event*, and finally (iii) *handling the event*.
>
> It is in *handling the event* that i have seen custom code added in 
> addition to the updatestate logic. Where, the custom code is usually added 
> after the update state function. But this custom is most of the time about 
> sending message back to the sender, or broadcasting it to the event bus.
>
> As per my example, it is clear that i need to do quite few operation to 
> actually call*Persist(HistoryChangeSetFetched(changeSet, time))*. Indeed 
> i need the new changeset, and the time of the newest change of it.
>
> The only way i see it possible is to do the fetch in the *validating the 
> command*
>
> That is:
>
> case FetchLastHistoryChangeSet => val changetuple = 
> ValidateCommand(FetchLastHistoryChangeSet); 
> persit(HistoryChangeSetFetched(changetuple._1, changetuple._2)) { 
> historyChangeSetFetched =>
>   updateState(historyChangeSetFetched)}
>
> Where the ValidateCommand(FetchLastHistoryChangeSet)
>
> would have as logic, to read last changeSet time (newest change of the 
> changeSet), fetch a new changeset based on it, if it exist, get the time of 
> its newest change, and return the tuple.
>
> My question is, is that how it is supposed to work. Validating command can 
> be something as complex as that ? i.e. actually executing the command ?
>
>

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

[Johan Andrén]

Hi Yan,

Messages in the actor mailbox, that is has not yet been processed by the 
actor, when a persistent actor stops or crashes are lost. To provide 
stronger guarantees that no message that has been sent from one actor to 
another is lost you will have to use 
UntypedPersistentActorWithAtLeastOnceDelivery, so you were on the right 
track. You can find an example of how to implement such an actor in the 
docs 
here: 
http://doc.akka.io/docs/akka/2.4.2/java/persistence.html#At-Least-Once_Delivery

--
Johan Andrén
Akka Team, Lightbend Inc.

On Thursday, March 31, 2016 at 6:34:58 PM UTC+2, Yan Pei wrote:
>
> I am new to AKKA. I did some researches but don't find the answer I 
> wanted. Maybe I don't know what keywords to search for.
>
> The scenario is we are trying to use akka persistence cassandra plugin to 
> save the incoming messages to cassandra in case the Actor is stopped or the 
> server is down, the unprocessed message can be recovered and being process 
> again.
>
> I've extended from AbstractPersistentActorWithAtLeastOnceDelivery and 
> things were working well. But that approach doesn't work with Actors with 
> Router.
>
> Then I changed back to use UntypedPersistentActor, but I don't know how to 
> only recover the messages which hasn't been processed. 
>
> I might now understandd the UntypedPersistentActor very well.
>
> Please give me any suggestions on how to use UntypedPersistentActorto to 
> recover the unprocessed messages.
>
> Thanks very much!
> Yan
>

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

[akka-user] Re: [akka java 2.4.2] Akka HTTP client oncomplete callback

[Johan Andrén]

Hi Johannes,

First I would recommend you to upgrade to the latest Akka Stream, 2.4.3 if 
possible, it contains many fixes and improvements over the version you seem 
to be using (OutputStreamSink is a private, internal API nowadays).
The corresponding method in the newer versions is 
StreamConverters.fromOutputStream(creator) and it materializes into a 
CompletionStage[IOResult] which completes when the OutputStream is closed. 
To get the materialized value out of the stream you would do source.

Secondly it will not be safe to use Piped Input/OutputStream as they 
require that usage is bound to one specific thread each, which the 
StreamConverters will not guarantee.

This is how you would do something like what you are asking for with Akka 
2.4.3:

ActorSystem system = ActorSystem.create();
Materializer mat = ActorMaterializer.create(system);

CompletionStage responseFuture =

Http.get(system).singleRequest(HttpRequest.create("http://example.com;), mat);

CompletionStage done = responseFuture.thenCompose(response -> {

Source<ByteString, Object> source = response.entity().getDataBytes();

// note that it is not safe/correct to create the outputstream outside of 
the
// lambda/creator given to fromOutputStream
Sink<ByteString, CompletionStage> sink =

StreamConverters.fromOutputStream(HttpClientExample::someApiReturningANewOutputStream);

// just to make the type clear, ofc you can just return it
CompletionStage completionStage = source.toMat(sink, 
Keep.right()).run(mat);

return completionStage;
});


done.thenAccept((result) -> {
if (result.wasSuccessful())
System.out.println("Done, wrote " + result.getCount() + " bytes");
else
System.out.println("Failed: " + result.getError().getMessage());
});


I hope this helps
--
Johan Andrén
Akka Team, Lightbend Inc.


On Wednesday, March 30, 2016 at 11:51:13 AM UTC+2, Johannes Berg wrote:
>
> Hi!
>
> I have a streaming Akka HTTP client request that I would want to register 
> an oncomplete callback on (in addition to the streaming which is working 
> fine) which is called when the complete request-response is done. There 
> doesn't seem to be anything in the Akka HTTP API directly (only toStrict 
> method but I can't use that as I need to stream this) but I guess I can be 
> looking at when the Akka stream is completed, right? If the stream is 
> completed, is the full HTTP request-response completed then (all sockets 
> closed and other resources released)?
>
> I'm very new to Akka streams but how can I register an oncomplete callback 
> on an Akka stream in Java?
>
> This is roughly what I'm doing and I would want an oncomplete callback 
> when it's all done streaming.
>
> Future response_future = Http.get(system).singleRequest(
> HttpRequest.create(url), am);
> Future<Source<ByteString, ?>> source_future = response_future.map(new 
> Mapper<HttpResponse, Source<ByteString, ?>>() {
> public Source<ByteString, ?> apply(HttpResponse response) {
> return response.entity().getDataBytes();
> }
> }, system.dispatcher());
>
> source_future.flatMap(new Mapper<Source<ByteString, ?>, Future>() 
> {
> public Future apply(Source<ByteString, ?> source) {
> PipedOutputStream output = new PipedOutputStream();
> InputStream input = new PipedInputStream(output);
>
> source.to(OutputStreamSink.create(new akka.japi.function.Creator<
> OutputStream>() {
> public OutputStream create() {
> return output;
> }
> })).run(am);
>
> //doing stuff with input
>
> //how to register oncomplete callback?
> source.onComplete ???
> }
> }, system.dispatcher());
>
> Anyone have any good suggestions?
>
> Thanks,
> Johannes
>

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

[Johan Andrén]

Hi,

There are some APIs for inspecting the cluster sharding state that may be 
useful for you (mentioned here: 
http://doc.akka.io/docs/akka/2.4.3/scala/cluster-sharding.html#Inspecting_cluster_sharding_state)
 
which would allow you to create your own monitoring solution or hook into 
some third party monitoring API.

--
Johan Andrén
Akka Team, Lightbend Inc.

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

[Johan Andrén]

Here is an adaptation of the Scala sample, but in Java:

import akka.NotUsed;
import akka.actor.*;
import akka.http.javadsl.model.ws.Message;
import akka.http.javadsl.model.ws.TextMessage;
import akka.http.javadsl.server.HttpApp;
import akka.http.javadsl.server.Route;
import akka.japi.pf.ReceiveBuilder;
import akka.stream.OverflowStrategy;
import akka.stream.javadsl.Flow;
import akka.stream.javadsl.Sink;
import akka.stream.javadsl.Source;

import java.util.Optional;

public class WebSocketServer {
  private static final class Router extends HttpApp {

private final ActorSystem system;

public Router(ActorSystem system) {
  this.system = system;
}

public Route createRoute() {
  return route(
path("test").route(
  get(handleWebSocketMessages(createWebSocketFlow()))
)
  );
}

private Flow<Message, Message, NotUsed> createWebSocketFlow() {
  ActorRef actor = system.actorOf(Props.create(AnActor.class));

  Source<Message, NotUsed> source = Source.actorRef(5, 
OverflowStrategy.fail())
.map((outgoing) -> (Message) TextMessage.create(outgoing.message))
.mapMaterializedValue(destinationRef -> {
  actor.tell(new OutgoingDestination(destinationRef), 
ActorRef.noSender());
  return NotUsed.getInstance();
});

  Sink<Message, NotUsed> sink = Flow.create()
.map((msg) -> new Incoming(msg.asTextMessage().getStrictText()))
.to(Sink.actorRef(actor, PoisonPill.getInstance()));


  return Flow.fromSinkAndSource(sink, source);
}

  }




public static void main(String[] args) {
ActorSystem actorSystem = ActorSystem.create();

Router router = new Router(actorSystem);
router.bindRoute("127.0.0.1", 8082, actorSystem);
}

  static class Incoming {
public final String message;
public Incoming(String message) {
  this.message = message;
}
  }

  static class Outgoing {
public final String message;
public Outgoing(String message) {
  this.message = message;
}
  }

  static class OutgoingDestination {
public final ActorRef destination;
OutgoingDestination(ActorRef destination) {
  this.destination = destination;
}
  }

  static class AnActor extends AbstractActor {

private Optional outgoing = Optional.empty();

public AnActor() {
  receive(ReceiveBuilder.match(
OutgoingDestination.class, (msg) -> outgoing = 
Optional.of(msg.destination)
  ).match(
Incoming.class, (in) -> outgoing.ifPresent((out) -> out.tell(new 
Outgoing("got it"), self()))
  ).build());
}
  }
}


Hope this helps.

--
Johan Andrén
Akka Team, Lightbend Inc.

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

[Johan Andrén]

This might be a bug, I have opened a ticket about it 
(https://github.com/akka/akka/issues/19957)

Thanks for letting us know!
--
Johan Andrén
Akka Team, Lightbend Inc.

On Saturday, March 5, 2016 at 6:24:37 PM UTC+1, Brandon Bradley wrote:
>
> This is a good question! I was wondering the same thing.
>
> On Wednesday, March 2, 2016 at 7:07:31 PM UTC-6, Filipp Eritsian wrote:
>>
>> Hello all,
>>
>> Hoping someone can shed some light on the following!
>>
>> I am using the example provided with the documentation:
>>
>> object WebSocketClient extends App {
>>
>>   implicit val system = ActorSystem("test")
>>   implicit val fm = ActorMaterializer()
>>
>>   import system.dispatcher
>>
>>   val incoming: Sink[Message, Future[Done]] =
>> Sink.foreach[Message] {
>>   case message: TextMessage.Strict =>
>> println(message.text)
>> }
>>
>>   val outgoing = Source.single(TextMessage(""))
>>
>>   val webSocketFlow = 
>> Http().webSocketClientFlow(WebSocketRequest("ws://localhost:9001/stats"))
>>
>>   val (upgradeResponse, closed) = outgoing
>> .viaMat(webSocketFlow)(Keep.right)
>> .toMat(incoming)(Keep.both)
>> .run()
>>
>>   val connected = upgradeResponse.flatMap { upgrade =>
>> if (upgrade.response.status == StatusCodes.OK)
>>   Future.successful(Done)
>> else if (upgrade.response.status == StatusCodes.SwitchingProtocols)
>>   Future.successful(Done)
>> else
>>   throw new RuntimeException(s"Connection failed: 
>> ${upgrade.response.status}")
>>   }
>>
>>   connected.onComplete(println)
>>   closed.foreach(_ => println("*** closed ***"))
>> }
>>
>>
>> The web socket client seems to close the http connection after about 6 
>> seconds. Any way to make the connection stay open? The server I am using 
>> just publishes stats every second, continuously.
>>
>> Server log:
>> [DEBUG] [03/03/2016 08:52:30.343] 
>> [websockets-akka.actor.default-dispatcher-3] 
>> [akka://websockets/system/IO-TCP/selectors/$a/0] New connection accepted
>> [DEBUG] [03/03/2016 08:52:36.534] 
>> [websockets-akka.actor.default-dispatcher-2] 
>> [akka://websockets/system/IO-TCP/selectors/$a/1] Closing connection due to 
>> IO error java.io.IOException: Broken pipe
>>
>> Cheers,
>> Filipp
>>
>

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

[Johan Andrén]

Hi Shayan,

No this is not possible to configure the akka http client to do this, you 
will have to implement retries of such requests in your own application 
logic.

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Thursday, February 11, 2016 at 10:40:48 PM UTC+1, sha...@gearzero.com 
wrote:
>
> Akka nation,
>
> I know the documentation says retries in Host-Level Client-Side API happen 
> for idempotent requests which excludes POST requests. But there are times 
> you have to use POST even though your request is are idempotent requests 
> (e.g. large parameter size, binary parameters, etc). Is there a way to 
> alter retry logic to also include POST requests?
>
> Thanks,
> Shayan
>
>

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

[Johan Andrén]

The Java graph DSL isn’t that different, the squiggly arrows (~>) corresponds 
to builder.via and you might
need to manually perform some more builder.add calls to add stages than the 
Scala code does, but you
should be able to create something pretty much like it with Java.

The docs on the Java GraphDSL can be found here:
http://doc.akka.io/docs/akka/2.4.2-RC2/java/stream/stream-graphs.html 
<http://doc.akka.io/docs/akka/2.4.2-RC2/java/stream/stream-graphs.html>

In the sample I gave you the Flow<Message, Message, ?> is created by first 
returning a FlowShape from the
block that creates the graph (in Scala the last value is returned, no return 
statement needed), and then passing the
resulting Graph<FlowShape<Message, Message,…>> to Flow.fromGraph.

If it wasn’t for the fact that we needed to pass the outgoing message actorref 
to the connection-actor we could
have just used Flow.fromSinkAndSource(sink, source) to construct it.

—
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

> 9 feb. 2016 kl. 13:51 skrev ash.ta <ata...@gmail.com>:
> 
> hey johan,
> 
> thanks for explanation.
> my main problem is that i don't know scala and the example is pretty much 
> gibberish for me.
> can you give me a hint about the flow point where sink and source can be 
> called with actorref creation?
> i mean, your java example shows 
> handleWebsocketMessages()
> 
> which receives a mthode returning 
> 
> Flow<Message, Message, ?>
> 
> where and how sink and source can be bound to this flow?
> 
> thanks again.
> 
> 
>  
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/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 a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/qWw79unk_tw/unsubscribe 
> <https://groups.google.com/d/topic/akka-user/qWw79unk_tw/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> akka-user+unsubscr...@googlegroups.com 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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

Re: [akka-user] Re: websockets with akka-http *java*

[Johan Andrén]

Sorry, I skimmed your question a little too quickly.

If you want to have a one to one with clients and actors, there is no
built in abstraction that makes it super easy, but it is possible using
Source.actorRef and Sink.actorRef. Here is an example which
is Scala but should point you in the right direction:

https://github.com/johanandren/scala-stockholm-cluster-message-broker/blob/master/src/main/scala/WebServer.scala#L69

Sink.actorRef will take an ActorRef and simply direct messages to it so getting 
incoming messages to an actor 
is easy (you can also use actorRefWithAck and be able to provide backpressure). 
Source.actorRef will however
materialize into an actorRef that when you send messages to it, it will emit 
them. The trick is to get the materialized
actorRef into the flow, and send it to your connection actor as a message. 
(Another alternative would be to send it as
a message from mapMaterializedValue if you have the actorref for your 
connection actor in scope).

I hope this helps!
--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

> 8 feb. 2016 kl. 16:40 skrev ash.ta <ata...@gmail.com>:
> 
> thanks for a prompt response.
> client is great, but i need server side implementation. and as i see, new 
> server side docs still show the same basic request-response example. 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/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 a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/qWw79unk_tw/unsubscribe 
> <https://groups.google.com/d/topic/akka-user/qWw79unk_tw/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> akka-user+unsubscr...@googlegroups.com 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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] ANNOUNCE: Akka 2.4.2-RC2

[Johan Andrén]

*Dear hakkers,*

we—the Akka committers—are proud to announce the SECOND RELEASE CANDIDATE 
for the upcoming release of Akka 2.4.2. The main change in the upcoming 
Akka 2.4.2 release is that it includes Streams & HTTP, with the 
akka-stream, akka-stream-testkit, akka-parsing, and akka-http-core modules 
no longer being marked “experimental”. In comparison to Streams & HTTP 2.0 
the main changes are:

   - significant performance improvement for HTTP handling, now reaching 
   roughly 75% of Spray’s performance—this is not the end of the performance 
   work, we have only just begun
   - replacement of all uses of the Unit type (represented as BoxedUnit in 
   Java) with the more descriptive types akka.Done (for signaling successful 
   completion) and akka.NotUsed (for materialization results of stages that do 
   not produce a value)
   - usage of Java 8 types in the Java DSLs: java.util.Optional instead of 
   scala.Option and java.util.concurrent.CompletionStage instead of 
   scala.concurrent.Future

Especially the second and third point mean that porting code from Streams & 
HTTP 2.0 to Akka 2.4.2 will require some mechanical source code changes, 
please refer to the migration guide 
<http://doc.akka.io/docs/akka/2.4.2-RC1/scala/stream/migration-guide-2.0-2.4-scala.html>
 for 
the details.

Closed issues since the RC1 can be found here 
<https://github.com/akka/akka/issues?utf8=%E2%9C%93=is%3Aissue+milestone%3A2.4.2+closed%3A%3E%3D2016-01-26>
.

Note that there still are known bugs in RC2, for a full list see here 
<https://github.com/akka/akka/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.4.2>

We intend to release version 2.4.2 as soon as we are confident that it is 
reasonably bug free and the documentation is top notch as well: we are 
aware that the getting started experience for Streams & HTTP is not perfect 
in places and there are some features that are entirely missing—stay tuned 
for updates and please let us know of anything you find to be suboptimal.

*Credits*

Thanks to the Community! For this release we had the help of 12 committers.

Please see the announcement for more details: 
http://akka.io/news/2016/02/02/akka-2.4.2-RC2-released.html
--

Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

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

[Johan Andrén]

I think the namespaces in your config are incorrect, deployment config for 
an actor should 
be under "akka.actor.deployment" (described in the docs here: 
http://doc.akka.io/docs/akka/2.4.1/general/configuration.html#Actor_Deployment_Configuration)
and the dispatcher you refer to from your actor is actually under 
akka.actor.function-scheduler-dispatcher
in your sample but you then refer to it only by the last name in the path 
"function-scheduler-dispatcher". 

I think what you intend would be:

akka.actor.deployment {
  /function-scheduler {
dispatcher = function-scheduler-dispatcher
  }
}
 
function-scheduler-dispatcher {
   ... dispatcher config ...
}


I hope this helps
--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle


On Friday, January 29, 2016 at 1:42:33 AM UTC+1, Ian Nowland wrote:
>
> Hello,
>
> I'm trying to configure an ActorSystem, but no matter what I do, seem to 
> be getting the default dispatcher. Here's what I've got going on:
>
> val customConf = ConfigFactory.parseString(
>   """
> |akka {
> |
> |  actor{
> |
> |/function-scheduler {
> |  dispatcher = function-scheduler-dispatcher
> |}
> |
> |function-scheduler-dispatcher {
> |  type = Dispatcher
> |  executor = "fork-join-executor"
> |  fork-join-executor {
> |# Min number of threads
> |parallelism-min = 2
> |# available processors * factor
> |parallelism-factor = 4.0
> |# Max number of threads
> |parallelism-max = 32
> |  }
> |}
> |  }
> |
> |}
>   """.stripMargin)
>
> val system:ActorSystem = 
> ActorSystem("function-scheduler",ConfigFactory.load(customConf))
> import system.dispatcher
>
> def scheduleOnce(delayTime: Long)(f:() => Unit):Unit = {
>   import scala.language.postfixOps
>   system.scheduler.scheduleOnce(delayTime milliseconds) {
> f()
>   }
> }
>
> As you can see, what I'm trying to do is use a scheduler to be able to 
> schedule arbitrary tasks. The problem is that everything I've tried in that 
> customConf still results in system using the akka.actor.default-dispatcher. 
> I definitely don't understand how the configuration stuff works, but my 
> theory is that I'm configuring the dispatcher that would be used for 
> created ActorRefs if I was to call something like:
>
> val myActor = 
> system.actorOf(Props[MyActor].withDispatcher("function-scheduler-dispatcher"),
>  
> "myactor1")
>
> rather than configuring the system itself.
>

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

Re: [akka-user] ANNOUNCE: Akka 2.4.1-RC1 (including streams and http)

[Johan Andrén]

Hi Jacob,

Yes, GitHub master is where we work on what will be Akka 2.4.2.

getStageActorRef has been renamed to getStageActor and the signature has 
changed somewhat.

The online API Scaladoc can be found here: http://doc.akka.io/api/akka/2.4.2-RC1
--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

> 28 jan. 2016 kl. 05:36 skrev Jakob Odersky <ja...@odersky.com>:
> 
> Is the GitHub master up to date? My project worked perfectly with
> streams experimental 2.0.2 but is unable to compile with 2.4.2-RC1.
> 
> Specifically, I am implementing a custom stage and referring to
> `akka.stream.stage.GraphStageLogic.getStageActorRef`. With the lastest
> RC, the compiler fails: "not found: value getStageActorRef", yet the
> latest source code checkout says it's there
> https://github.com/akka/akka/blob/master/akka-stream/src/main/scala/akka/stream/stage/GraphStage.scala
>  
> <https://github.com/akka/akka/blob/master/akka-stream/src/main/scala/akka/stream/stage/GraphStage.scala>.
> Am I missing something? Also, is there an online API scaladoc
> available?
> 
> thanks,
> --Jakob
> 
> On Tue, Jan 26, 2016 at 7:55 AM, Johan Andrén <johan.and...@typesafe.com 
> <mailto:johan.and...@typesafe.com>> wrote:
>> Darn.
>> 
>> Announcement subject is wrong, 2.4.2 RC-1 of course, not 2.4.1!
>> 
>> --
>> Johan Andrén
>> Typesafe -  Reactive apps on the JVM
>> Twitter: @apnylle
>> 
>> 
>> On Tuesday, January 26, 2016 at 1:39:48 PM UTC+1, Johan Andrén wrote:
>>> 
>>> Dear hakkers,
>>> 
>>> we—the Akka committers—are proud to announce the FIRST RELEASE CANDIDATE
>>> for the upcoming release of Akka 2.4.2. The main change in this release is
>>> that it includes Streams & HTTP, with the akka-stream, akka-stream-testkit,
>>> akka-parsing, and akka-http-core modules no longer being marked
>>> “experimental”. In comparison to Streams & HTTP 2.0 the main changes are:
>>> 
>>> significant performance improvement for HTTP handling, now reaching
>>> roughly 75% of Spray’s performance—this is not the end of the performance
>>> work, we have only just begun
>>> replacement of all uses of the Unit type (represented as BoxedUnit in
>>> Java) with the more descriptive types akka.Done (for signaling successful
>>> completion) and akka.NotUsed (for materialization results of stages that do
>>> not produce a value)
>>> usage of Java 8 types in the Java DSLs: java.util.Optional instead of
>>> scala.Option and java.util.concurrent.CompletionStage instead of
>>> scala.concurrent.Future
>>> 
>>> Especially the second and third point mean that porting code from Streams
>>> & HTTP 2.0 to Akka 2.4.2 will require some mechanical source code changes,
>>> please refer to the migration guide for the details. While the core team was
>>> concentration on these sweeping changes some community members; Alexander
>>> Golubev, Stefano Galarraga, Gilad Hoch and @2beaucoup to name a few, got
>>> busy contributing new functionality and improving the existing one:
>>> 
>>> Automatic and manual reset of the BackoffSupervisor
>>> CircuitBreaker implemented as an Actor pattern
>>> Noisy logging of cluster heartbeats now silenced but available through a
>>> config setting
>>> A rare bug where a node joining a cluster crashed before join completed
>>> and then not being able to connect after restart was fixed
>>> Option to eagerly initialize persistence plugins
>>> Improved OSGi manifests for HTTP and streams
>>> New stream combinators added: batch, batchWeighted, reduce and
>>> watchTermination.
>>> HTTP - server side request timeouts added
>>> Connection pools no longer fail if they are limited to a single connection
>>> New directives to turn a posted form to maps and sequences
>>> 
>>> We intend to release version 2.4.2 as soon as we are confident that it is
>>> reasonably bug free and the documentation is top notch as well: we are aware
>>> that the getting started experience for Streams & HTTP is not perfect in
>>> places and there are some features that are entirely missing—stay tuned for
>>> updates and please let us know of anything you find to be suboptimal.
>>> 
>>> Binary Compatibility
>>> 
>>> Akka 2.4.x is backwards binary compatible with previous 2.3.x versions
>>> (exceptions listed below). This means that the new JARs are a drop-in
>>> replacement for the old one (but not the other way around) as long as 

[akka-user] Re: ANNOUNCE: Akka 2.4.1-RC1 (including streams and http)

[Johan Andrén]

Darn. 

Announcement subject is wrong, 2.4.2 RC-1 of course, not 2.4.1!

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Tuesday, January 26, 2016 at 1:39:48 PM UTC+1, Johan Andrén wrote:
>
> *Dear hakkers,*
>
> we—the Akka committers—are proud to announce the FIRST RELEASE CANDIDATE 
> for the upcoming release of Akka 2.4.2. The main change in this release is 
> that it includes Streams & HTTP, with the akka-stream, akka-stream-testkit, 
> akka-parsing, and akka-http-core modules no longer being marked 
> “experimental”. In comparison to Streams & HTTP 2.0 the main changes are:
>
>- significant performance improvement for HTTP handling, now reaching 
>roughly 75% of Spray’s performance—this is not the end of the performance 
>work, we have only just begun
>- replacement of all uses of the Unit type (represented as BoxedUnit 
>in Java) with the more descriptive types akka.Done (for signaling 
>successful completion) and akka.NotUsed (for materialization results of 
>stages that do not produce a value)
>- usage of Java 8 types in the Java DSLs: java.util.Optional instead 
>of scala.Option and java.util.concurrent.CompletionStage instead of 
>scala.concurrent.Future
>
> Especially the second and third point mean that porting code from Streams 
> & HTTP 2.0 to Akka 2.4.2 will require some mechanical source code changes, 
> please refer to the migration guide 
> <http://doc.akka.io/docs/akka/2.4.2-RC1/scala/stream/migration-guide-2.0-2.4-scala.html>
>  for 
> the details. While the core team was concentration on these sweeping 
> changes some community members; Alexander Golubev, Stefano Galarraga, Gilad 
> Hoch and @2beaucoup to name a few, got busy contributing new functionality 
> and improving the existing one:
>
>- Automatic and manual reset of the BackoffSupervisor
>- CircuitBreaker implemented as an Actor pattern
>- Noisy logging of cluster heartbeats now silenced but available 
>through a config setting
>- A rare bug where a node joining a cluster crashed before join 
>completed and then not being able to connect after restart was fixed
>- Option to eagerly initialize persistence plugins
>- Improved OSGi manifests for HTTP and streams
>- New stream combinators added: batch, batchWeighted, reduce and 
>watchTermination. 
>- HTTP - server side request timeouts added
>- Connection pools no longer fail if they are limited to a single 
>connection
>- New directives to turn a posted form to maps and sequences
>
> We intend to release version 2.4.2 as soon as we are confident that it is 
> reasonably bug free and the documentation is top notch as well: we are 
> aware that the getting started experience for Streams & HTTP is not perfect 
> in places and there are some features that are entirely missing—stay tuned 
> for updates and please let us know of anything you find to be suboptimal.
>
> Binary Compatibility
>
> Akka 2.4.x is backwards binary compatible with previous 2.3.x versions 
> (exceptions listed below). This means that the new JARs are a drop-in 
> replacement for the old one (but not the other way around) as long as your 
> build does not enable the inliner (Scala-only restriction). It should be 
> noted that Scala 2.11.x is is not binary compatible with Scala 2.10.x, 
> which means that Akka’s binary compatibility property only holds between 
> versions that were built for a given Scala 
> version—akka-actor_2.11-2.4.2-RC1.jar is compatible with 
> akka-actor_2.11-2.3.14.jar but not with akka-actor_2.10-2.3.14.jar.
>
> Binary compatibility is *not* maintained for the following:
>
>- akka-testkit, akka-multi-node-testkit and akka-persistence-tck
>- experimental modules:
>   - akka-persistence-query-experimental
>   - akka-distributed-data-experimental
>   - akka-typed-experimental
>   - akka-http-experimental
>   - akka-http-testkit-experimental
>   - akka-http-spray-json-experimental
>   - akka-http-xml-experimental
>   - akka-http-jackson-experimental
>- features, classes, methods that were deprecated in 2.3.0 or earlier 
>and removed in 2.4.x
>
> Credits
>
> Thanks to the Community! For this release we had the help of 32 
> committers. For the full list of stats see the announcement on the web 
> site: http://akka.io/news/2016/01/26/akka-2.4.2-RC1-released.html
>
> Special thanks to Alexander Golubev for his involvement in the development 
> of Akka Stream.
>
> Happy hakking!
>
> – The Akka Team
>

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

[akka-user] ANNOUNCE: Akka 2.4.1-RC1 (including streams and http)

[Johan Andrén]

*Dear hakkers,*

we—the Akka committers—are proud to announce the FIRST RELEASE CANDIDATE 
for the upcoming release of Akka 2.4.2. The main change in this release is 
that it includes Streams & HTTP, with the akka-stream, akka-stream-testkit, 
akka-parsing, and akka-http-core modules no longer being marked 
“experimental”. In comparison to Streams & HTTP 2.0 the main changes are:

   - significant performance improvement for HTTP handling, now reaching 
   roughly 75% of Spray’s performance—this is not the end of the performance 
   work, we have only just begun
   - replacement of all uses of the Unit type (represented as BoxedUnit in 
   Java) with the more descriptive types akka.Done (for signaling successful 
   completion) and akka.NotUsed (for materialization results of stages that do 
   not produce a value)
   - usage of Java 8 types in the Java DSLs: java.util.Optional instead of 
   scala.Option and java.util.concurrent.CompletionStage instead of 
   scala.concurrent.Future

Especially the second and third point mean that porting code from Streams & 
HTTP 2.0 to Akka 2.4.2 will require some mechanical source code changes, 
please refer to the migration guide 

 for 
the details. While the core team was concentration on these sweeping 
changes some community members; Alexander Golubev, Stefano Galarraga, Gilad 
Hoch and @2beaucoup to name a few, got busy contributing new functionality 
and improving the existing one:

   - Automatic and manual reset of the BackoffSupervisor
   - CircuitBreaker implemented as an Actor pattern
   - Noisy logging of cluster heartbeats now silenced but available through 
   a config setting
   - A rare bug where a node joining a cluster crashed before join 
   completed and then not being able to connect after restart was fixed
   - Option to eagerly initialize persistence plugins
   - Improved OSGi manifests for HTTP and streams
   - New stream combinators added: batch, batchWeighted, reduce and 
   watchTermination. 
   - HTTP - server side request timeouts added
   - Connection pools no longer fail if they are limited to a single 
   connection
   - New directives to turn a posted form to maps and sequences

We intend to release version 2.4.2 as soon as we are confident that it is 
reasonably bug free and the documentation is top notch as well: we are 
aware that the getting started experience for Streams & HTTP is not perfect 
in places and there are some features that are entirely missing—stay tuned 
for updates and please let us know of anything you find to be suboptimal.

Binary Compatibility

Akka 2.4.x is backwards binary compatible with previous 2.3.x versions 
(exceptions listed below). This means that the new JARs are a drop-in 
replacement for the old one (but not the other way around) as long as your 
build does not enable the inliner (Scala-only restriction). It should be 
noted that Scala 2.11.x is is not binary compatible with Scala 2.10.x, 
which means that Akka’s binary compatibility property only holds between 
versions that were built for a given Scala 
version—akka-actor_2.11-2.4.2-RC1.jar is compatible with 
akka-actor_2.11-2.3.14.jar but not with akka-actor_2.10-2.3.14.jar.

Binary compatibility is *not* maintained for the following:

   - akka-testkit, akka-multi-node-testkit and akka-persistence-tck
   - experimental modules:
  - akka-persistence-query-experimental
  - akka-distributed-data-experimental
  - akka-typed-experimental
  - akka-http-experimental
  - akka-http-testkit-experimental
  - akka-http-spray-json-experimental
  - akka-http-xml-experimental
  - akka-http-jackson-experimental
   - features, classes, methods that were deprecated in 2.3.0 or earlier 
   and removed in 2.4.x

Credits

Thanks to the Community! For this release we had the help of 32 committers. 
For the full list of stats see the announcement on the web site: 
http://akka.io/news/2016/01/26/akka-2.4.2-RC1-released.html

Special thanks to Alexander Golubev for his involvement in the development 
of Akka Stream.

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: send a broadcast message

[Johan Andrén]

Not sure what you mean with "all actors in a system context", but if it is
the broadcast to all routees of a router that you initially wanted to do, 
then you can still do that, just that you need to use .route instead of !
to send your message wrapped with akka.routing.Broadcast.

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Monday, January 18, 2016 at 9:01:34 AM UTC+1, Manar Elkady wrote:
>
> Thanks, Johan,  for illustration, but do you mean that there is no way to 
> broadcast messages to all actors in a system context?
>
> Manar
>
>
> On Sunday, January 17, 2016 at 4:40:52 PM UTC+2, Johan Andrén wrote:
>>
>> Hi Manar,
>>
>> To send messages using a Router you would use the .route(message, sender) 
>> method
>> and not ! (this is because the router isn't an actor)
>>
>> For more details about how routers work, look in the docs here:
>> http://doc.akka.io/docs/akka/2.4.1/scala/routing.html
>>
>> --
>> Johan Andrén
>> Typesafe -  Reactive apps on the JVM
>> Twitter: @apnylle
>>
>> On Saturday, January 16, 2016 at 12:05:01 PM UTC+1, Manar Elkady wrote:
>>>
>>>
>>> Hi,
>>>
>>> In my application, I'd like to broadcast a time unit every 2 sec to all 
>>> actors instances of Worker. The time unit is sent by the master to all the 
>>> worker
>>> I am trying to send a broadcast message to set of workers by the master 
>>> actor, but it doesn't work with me. I attach my test code here. There is a 
>>> compile error in the line 
>>>  router ! Broadcast("any message") 
>>> "Error: value is not a member of akka.routing.Router" Could anyone tell 
>>> me what is the problem here.
>>>  
>>>
>>> import akka.actor._
>>> import akka.routing.{ ActorRefRoutee, RoundRobinRoutingLogic, Router }
>>> import akka.routing.Broadcast
>>> import akka.routing.Router
>>> import akka.routing.RouterActor
>>>
>>> object Messages{
>>>  object Work
>>>  object Terminated
>>> }
>>>
>>> object MainRouterDriver extends App {
>>>   import Messages._
>>>   // an actor needs an ActorSystem
>>> val system = ActorSystem("HelloSystem")
>>> // create and start the actor
>>> val routingMaster = system.actorOf(Props[Master], name = "helloactor")
>>> // send the actor two messages
>>> routingMaster ! Work
>>>   
>>> }
>>>
>>> class Worker extends Actor{
>>>   def receive = {
>>> case _ =>
>>> println("Hi I am a Worker")
>>>   }
>>>   
>>>   
>>> }
>>> class Master extends Actor {
>>>   var router = {
>>>   val routees = Vector.fill(5) {
>>>   val r = context.actorOf(Props[Worker])
>>>   context watch r
>>>   ActorRefRoutee(r)
>>> }
>>>   akka.routing.Router(RoundRobinRoutingLogic(), routees)
>>>   }
>>> def receive = {
>>> case Work =>
>>>  router ! Broadcast("any message") 
>>> 
>>>   }
>>>
>>> }
>>>
>>>
>>>
>>>
>
>

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

[Johan Andrén]

Manar,

I would say that isn’t the regular use case for routers.

Built into the actor system there is an event bus which might be a better fit.

Actors can register to the event bus that they are interested in events of a 
specific type. This way you can publish the TimeUnit message from one place 
without knowing what actors should receive it, the actors themselves will be 
responsible to subscribe when they start up.

You can read more about the event bus in the docs here:
http://doc.akka.io/docs/akka/2.4.1/scala/event-bus.html

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

> 18 jan. 2016 kl. 10:03 skrev Manar Elkady <m.elk...@fci-cu.edu.eg>:
> 
> Johan,
> 
> Please forgive me for not illustrative question because I am a newcomer to 
> akka. I will illustrate to you what I mean.
> 
> I have three different actors types (actor1, actor2, actor3) in my 
> application and each one of them has different state and behaviors while 
> communicating with each other. Initially, I created set of instances from 
> each actor type. To synchronize the actions taken by them during the 
> application running I want broadcast a Time_Unit message to all instances of 
> these actors  by a controller actor. 
> 
> I decided to use routers because I don't have other options to broadcast 
> messages. Is there any other way to do that?
> 
> Manar,
>   
> 
> On Monday, January 18, 2016 at 10:10:13 AM UTC+2, Johan Andrén wrote:
> Not sure what you mean with "all actors in a system context", but if it is
> the broadcast to all routees of a router that you initially wanted to do, 
> then you can still do that, just that you need to use .route instead of !
> to send your message wrapped with akka.routing.Broadcast.
> 
> --
> Johan Andrén
> Typesafe -  Reactive apps on the JVM
> Twitter: @apnylle
> 
> On Monday, January 18, 2016 at 9:01:34 AM UTC+1, Manar Elkady wrote:
> Thanks, Johan,  for illustration, but do you mean that there is no way to 
> broadcast messages to all actors in a system context?
> 
> Manar
> 
> 
> On Sunday, January 17, 2016 at 4:40:52 PM UTC+2, Johan Andrén wrote:
> Hi Manar,
> 
> To send messages using a Router you would use the .route(message, sender) 
> method
> and not ! (this is because the router isn't an actor)
> 
> For more details about how routers work, look in the docs here:
> http://doc.akka.io/docs/akka/2.4.1/scala/routing.html 
> <http://doc.akka.io/docs/akka/2.4.1/scala/routing.html>
> 
> --
> Johan Andrén
> Typesafe -  Reactive apps on the JVM
> Twitter: @apnylle
> 
> On Saturday, January 16, 2016 at 12:05:01 PM UTC+1, Manar Elkady wrote:
> 
> Hi,
> 
> In my application, I'd like to broadcast a time unit every 2 sec to all 
> actors instances of Worker. The time unit is sent by the master to all the 
> worker
> I am trying to send a broadcast message to set of workers by the master 
> actor, but it doesn't work with me. I attach my test code here. There is a 
> compile error in the line 
>  router ! Broadcast("any message") 
> "Error: value is not a member of akka.routing.Router" Could anyone tell me 
> what is the problem here.
>  
> 
> import akka.actor._
> import akka.routing.{ ActorRefRoutee, RoundRobinRoutingLogic, Router }
> import akka.routing.Broadcast
> import akka.routing.Router
> import akka.routing.RouterActor
> 
> object Messages{
>  object Work
>  object Terminated
> }
> 
> object MainRouterDriver extends App {
>   import Messages._
>   // an actor needs an ActorSystem
> val system = ActorSystem("HelloSystem")
> // create and start the actor
> val routingMaster = system.actorOf(Props[Master], name = "helloactor")
> // send the actor two messages
> routingMaster ! Work
>   
> }
> 
> class Worker extends Actor{
>   def receive = {
> case _ =>
> println("Hi I am a Worker")
>   }
>   
>   
> }
> class Master extends Actor {
>   var router = {
>   val routees = Vector.fill(5) {
>   val r = context.actorOf(Props[Worker])
>   context watch r
>   ActorRefRoutee(r)
> }
>   akka.routing.Router(RoundRobinRoutingLogic(), routees)
>   }
> def receive = {
> case Work =>
>  router ! Broadcast("any message") 
> 
>   }
> 
> }
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>

[akka-user] Re: send a broadcast message

[Johan Andrén]

Hi Manar,

To send messages using a Router you would use the .route(message, sender) 
method
and not ! (this is because the router isn't an actor)

For more details about how routers work, look in the docs here:
http://doc.akka.io/docs/akka/2.4.1/scala/routing.html

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Saturday, January 16, 2016 at 12:05:01 PM UTC+1, Manar Elkady wrote:
>
>
> Hi,
>
> In my application, I'd like to broadcast a time unit every 2 sec to all 
> actors instances of Worker. The time unit is sent by the master to all the 
> worker
> I am trying to send a broadcast message to set of workers by the master 
> actor, but it doesn't work with me. I attach my test code here. There is a 
> compile error in the line 
>  router ! Broadcast("any message") 
> "Error: value is not a member of akka.routing.Router" Could anyone tell me 
> what is the problem here.
>  
>
> import akka.actor._
> import akka.routing.{ ActorRefRoutee, RoundRobinRoutingLogic, Router }
> import akka.routing.Broadcast
> import akka.routing.Router
> import akka.routing.RouterActor
>
> object Messages{
>  object Work
>  object Terminated
> }
>
> object MainRouterDriver extends App {
>   import Messages._
>   // an actor needs an ActorSystem
> val system = ActorSystem("HelloSystem")
> // create and start the actor
> val routingMaster = system.actorOf(Props[Master], name = "helloactor")
> // send the actor two messages
> routingMaster ! Work
>   
> }
>
> class Worker extends Actor{
>   def receive = {
> case _ =>
> println("Hi I am a Worker")
>   }
>   
>   
> }
> class Master extends Actor {
>   var router = {
>   val routees = Vector.fill(5) {
>   val r = context.actorOf(Props[Worker])
>   context watch r
>   ActorRefRoutee(r)
> }
>   akka.routing.Router(RoundRobinRoutingLogic(), routees)
>   }
> def receive = {
> case Work =>
>  router ! Broadcast("any message") 
> 
>   }
>
> }
>
>
>
>

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

[Johan Andrén]

Hi Henrik,

I think this sounds like a good fit for persistance together with sharding.

If you use sharding you will not "know" where the sharded actors are, but 
address them with their id. Your
controllers will however need to get their hands on the ShardRegion to send 
messages to the sharded actors.
The shard region will be a local actor and does not move around so it is 
pretty much safe to look it up during 
the bootstrap of your controller and then keep that ActorRef for all your 
interaction.

One reason why it could be an idea to think about moving away from spring 
to akka-http in the future is that
spring will block one thread until the request is done, so you will have to 
block it to wait for the reply from your
sharded actor, and keeping that thread from taking other requests. While 
akka-http is asynchronous all the way
and will allow the "controller" to return the thread pool and then react on 
the reply from the sharded actor.

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Thursday, January 14, 2016 at 10:40:44 AM UTC+1, Henrik Johansson wrote:
>
> Hi,
>
> We have finally gotten around to try to migrate a fairly standard Spring 
> REST application to Akka. It will be using the Java API (scala knowledge is 
> moderate at best) and we could need some advice around the approach.
>
> The initial thought was to keep using the Spring based REST API i.e. keep 
> all controllers and client facing API/Json serialization and use Akka 
> persistance and sharding for our entities. Why we think this would be good 
> is that we have quite well defined entities where the identity is explicit 
> and guaranteed to be unique. We are also fond of the eventsourcing model. 
> The idea is also that querying the entity for its current state would 
> simple be a matter of rendering its current state and thus saving a trip to 
> the database and result in better performance. We are talking perhaps 
> single digit millions of these entities.
>
> Where we find that we lack explicit understanding is how we get hold of 
> the actors from the controllers (or whatever service actually performs 
> actor interactions). Looking up persistent actors (without sharding for 
> simplicity) using Patterns.ask seems to work but we are unclear as to 
> whether or not that is the way to do it. Should we do that whenever we need 
> to get hold of an entity and is there any (significant) overhead? We would 
> prefer not to cache the actors and it seems counterintuitive as well since 
> actors target locations can change. Also maintaining invalidations seems a 
> hassle.
>
> Any help and advice would be greatly appreciated. Caveats and gotchas etc 
> also very welcome.
>
> Thanks,
> Henrik
>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Unusual race condition when using TestActorRef.create

[Johan Andrén]

Hi Mike,

expectMsgClass contains a default timeout, maybe that is too short for your 
actor
to do its thing. You could try with the overload of the method that takes a 
duration
to say how long it will take before you consider it as did-not-arrive. 

Could this perhaps solve your problem?

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Friday, January 8, 2016 at 3:49:11 PM UTC+1, Michael Patel wrote:
>
> Hi Guys, 
>
> We're using Akka 2.4.1 in one of our Java projects at work and i'm trying 
> to understand an unusual case which causes our tests infrequently fail when 
> run as part of our maven multithreaded build. 
>
> Here's a gist which describes what the test is doing 
>
> https://gist.github.com/patelm5/4e4f82e62ccd230a00cf#file-gistfile1-java
>
> The Actor under test is simply performing a forward in the receive, using 
> some dynamic property to get an actor selection ( in this case its 74 ). 
>
>
> Here's what a successful run logs : 
>
> 14:19:29.863 [main] INFO  org.mikeyp.ForwardingActor - started forwarding 
> actor fowarding from akka://LookupActorTest1/user/lookup-source-74 -> 
> akka://LookupActorTest1/system/LookupActorTest2-1
> 14:19:30.364 [main] WARN  org.mikeyp.LookupActor - Started onReceive 
> Thread main, Dispatcher is class akka.testkit.CallingThreadDispatcher
> 14:19:30.373 [main] WARN  org.mikeyp.ForwardingActor - forwarding message 
> given to me akka://LookupActorTest1/user/lookup-source-74 to actor 
> akka://LookupActorTest1/system/LookupActorTest2-1, thread main, dispatcher 
> is akka.testkit.CallingThreadDispatcher@1827a871
> 14:19:30.375 [main] WARN  org.mikeyp.AbstractActorTest - Shutting it down
> 14:19:30.381 [LookupActorTest1-akka.actor.default-dispatcher-4] INFO 
>  org.mikeyp.ForwardingActor - stopped forwarding actor  fowarding from 
> akka://LookupActorTest1/user/lookup-source-74 -> 
> akka://LookupActorTest1/system/LookupActorTest2-1
>
> Curiously, under certain conditions ( usually a maven multithreaded build 
> ) the logging output differs slightly and prints 
>
> 10:17:56.918 [main] INFO  org.mikeyp.ForwardingActor - started forwarding 
> actor [akka://ActorTest99/user/lookup-source-74] -> 
> [akka://ActorTest99/system/ActorTest100-199]
> 10:17:56.918 [main] WARN  org.mikeyp.LookupActor - Started onReceive 
> Thread main, Dispatcher is class akka.testkit.CallingThreadDispatcher
> [INFO] [01/08/2016 10:17:56.920] 
> [ActorTest99-akka.actor.default-dispatcher-5] 
> [akka://ActorTest99/user/lookup-source-74] Message 
> [org.mikeyp.LookupResponse] from 
> Actor[akka://ActorTest99/system/ActorTest100-199#1098554928] to 
> Actor[akka://ActorTest99/user/lookup-source-74] was not delivered. [2] dead 
> letters encountered. This logging can be turned off or adjusted with 
> configuration settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> 10:18:00.995 [main] WARN  org.mikeyp.AbstractActorTest - Shutting it down
>
> The dead letter obviously causes the test to fail, but why is there a dead 
> letter ? 
>
> If the actor had stopped, presumably my log message would have fired in my 
> forwarding actor. So I suspected that it might be to do with the actor not 
> being ready to receive messages somehow, despite the preStart method having 
> already been called. Is there a case where this can happen that i'm not 
> aware of, reading the documentation suggests this shouldn't be the case ? 
>  I was able to make the build very stable by adding a short wait after 
> creating the actor, which I suppose I could replace with an ask of some 
> kind to check it's ready. I'd just like to understand if this is necessary 
> in the test. 
>
> Cheers, 
> Mike. 
>

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

[Johan Andrén]

Hi Ujjwala,

An image is binary data, so you should not transform your bytes into 
strings. What you probably want is to get your image bytes from "another 
api"
as either one ByteString (it will then all be in your server memory at 
once, so
this might be bad) or a stream of chunks, a Source[ByteString, Any] which 
you
send back as http resonse body. 

Maybe this is enough to lead you in the right direction?

def getImageBytesFromOtherApi(): Source[ByteString, Unit] = ??? // call 
your other api and get the bytes

val route =
  pathEndOrSingleSlash {
get {
  complete(HttpResponse(
StatusCodes.OK,
// media type needs to be the type of the image of course!
entity = HttpEntity(MediaTypes.`image/jpeg`, 
getImageBytesFromOtherApi())
  ))
}
  }

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

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

[Johan Andrén]

Hi Jeff,

Since what you want to do is materialize a stream on each such binary 
message,
the case block does not happen upon creation of your Flow or even upon 
materialization
of it, you will need access to the materializer inside of it.

I don't think you have any other option than to make materializer available 
in your apply
method, from a method parameter for example.

Side note: I see you are still on an old version of akka streams, please 
try to
upgrade to 2.0.x as soon as you can, it contains many fixes and 
improvements!

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Monday, December 14, 2015 at 10:54:18 PM UTC+1, Jeff wrote:
>
> I am working my way through the websocket example and have a question 
> about nested streams. Currently I have this: 
>
> import akka.actor.ActorRef
> import akka.http.scaladsl.model.ws.{BinaryMessage, TextMessage, Message}
> import akka.stream.{OverflowStrategy, FlowShape}
> import akka.stream.scaladsl.{Sink, Source, FlowGraph, Flow}
>
> object ChatFlow {
>   def apply(userId: Long, channel: Long, rabbitActor: ActorRef): 
> Flow[Message, Message, ActorRef] =
> Flow.fromGraph(FlowGraph.create(Source.actorRef[RabbitActor.Message](5, 
> OverflowStrategy.fail)) { implicit b =>
>   rabbitSource =>
> import FlowGraph.Implicits._
>
> // for now, ignore all content coming from the websocket
> val fromWebsocket = b.add(Sink.foreach[Message] {
>   case TextMessage.Strict(content) => println(content)
> //  case bm: BinaryMessage => bm.dataStream.runWith(Sink.ignore)
> })
>
> // translate rabbit messages into socket messages
> val toWebSocket = b.add(Flow[RabbitActor.Message] map {
>   case _ => TextMessage(s"test")
> })
>
> // when this stream is materialized, register it with rabbitmq
> val websocketMaterialized = b.materializedValue map { actor =>
>   RabbitActor.UserJoined(userId, channel, actor)
> }
>
> val rabbitMQSink = Sink.actorRef[RabbitActor.Message](rabbitActor, 
> RabbitActor.UserLeft(userId, channel))
>
> websocketMaterialized ~> rabbitMQSink
> rabbitSource ~> toWebSocket
>
> FlowShape(fromWebsocket.inlet, toWebSocket.outlet)
> })
> }
>
>
> My question is about the commented out BinaryMessage. bm.dataStream is a 
> Source, and the docs say I should drain this stream to clear the socket. 
> How would I do that in this scenario without passing in a materializer?
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Deadlock in a flow with a cycle?

[Johan Andrén]

Hi Kaspar,

Worst case scenario is that all 100 fails, they will then loop around the
retry loop until you filter them out, during this time no elements from s
will be consumed but the stream will not dead lock thanks to the preferred
merge that is unfair and ignores s if there are elements coming from 
the feedback loop.

As the elements will be processed sequentially and retried it might
take a long while before a new element from s is consumed upon
failures (it will need to wait for the next 99 * 1s of delay 9 times).

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle


On Thursday, December 17, 2015 at 10:07:11 PM UTC+1, hbf wrote:
>
> Hey everybody,
>
>
> I'm trying to convince myself that a flow I'm building with Akka Streams 
> is deadlock-free. Here's what I'm trying to do:
>
>- I have an infinite source *s* of some kind of requests *r1, r2, ... 
> *that I 
>need "execute". 
>- In case such an execution fails, I'd like to wait a bit (1s, say) 
>and try again. 
>- If a request cannot be executed for 10 times, it will be dropped. 
>
> To keep resource consumption bounded, I thought I'd limit the number of 
> requests (to 100, say). So when there are around 100 requests in the 
> pipeline, the pipeline should not ask the source *s* for new elements but 
> just continue retrying until we have again only 99 or fewer requests.
>
>
> I implemented this pseudo code:
>
>
>s ~> PreferredMerge~> Delay ~> buffer(100) ~> ExecuteRequest ~> 
> Broadcast ~> Report
>
> PreferredMerge.pref()  <~  RetriedOnceMore<~  FilterFail<~ 
> Broadcast
>
>
> Here, the source *s* emits Retry(request, retryCount) objects. These 
> enter a PreferredMerge stage on the un-preferred port, get delayed (using 
> a mapAsync) and then buffered. ExecuteRequest executes the request. The 
> result of this goes to a broadcast, one of whose outputs emits results 
> (succeeded or failed). In FilterFail, requests that failed for less than 
> 10 times are kept and get their retryCount incremented in RetriedOnceMore 
> before 
> they enter the PreferredMerge stage on the preferred port.
>
>
> This works. But could it deadlock?
>
>
> – Kaspar
>

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

[Johan Andrén]

Hi,

It sounds like you basically want to implement your own little web framework
on top of akka-http?

In that case it is probably best to skip the high level server API and build
on top of the low level server side API instead, you can find an overview 
here:
http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0.1/java/http/server-side/low-level-server-side-api.html#request-response-cycle

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Thursday, January 7, 2016 at 1:07:30 PM UTC+1, ash.ta wrote:
>
> hi hakkers,
>
> i'm working *JAVA* akka-http based app.
> i was planning to create a generic handler that handles all common stuff 
> and only  exposes a method for custom logic implementation.
> my problem is that handlers that will derive from it in the future will 
> use different types of inputs. some will expect to receive json in a post 
> body,
> others will look for specific params arriving in get and so on.
> the only examples i find make use of RequestVals, which in its turn is 
> initialized in a "server class", out of handlers' scope.
> this means that each time a new handler needs to be implemented i'll have 
> to edit that "server class".
>
> my question is if there is any way to access and manage httprequest 
> related data within handlers scope in a generic manner?
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Asking a node to leave using akka-cluster command-line tool.

[Johan Andrén]

Hi Joseph,

Cluster state changes are not allowed when we do not
know for sure that the cluster has got a consistent view
of the cluster state, this could make it impossible to leave
the cluster until those nodes are marked DOWN or become
reachable again.

Could this be what is causing your problems
or was the cluster in good shape before you tried to leave
using the command line tool?

(http://doc.akka.io/docs/akka/2.4.1/common/cluster.html#Gossip_Convergence)

I would take a look at the cluster state after issuing leave
to see what is going on, you can do that with the same tool
and "cluster-status".

I hope this helps!
--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Tuesday, January 12, 2016 at 2:03:24 PM UTC+1, jos...@evernym.us wrote:
>
> Hi,
>
> I have a 2-node akka cluster. When deploying updated code, the nodes are 
> restarted one after the other with some time gap in between. This seems to 
> be causing Unreachable/Quarantine issues. So, I want to ask each node to 
> LEAVE the cluster before it is restarted. I am using the akka-cluster 
> command-line tool for this.
>
> joseph@gw01:~$ akka-cluster app01.stg  leave akka.tcp:
> //sys...@app01.stg:2551
> Scheduling akka.tcp://sys...@app01.stg:2551 to LEAVE cluster
> joseph@gw01:~$ akka-cluster app02.stg  leader
> Checking leader status
> akka.tcp://system@app01:2551
>
>
>
> It says that it's Scheduling to LEAVE the cluster, but doesn't actually 
> leave the cluster. I tried asking both the Leader and non-leader to leave, 
> but they don't leave even after half an hour.
> Is there some way I can get them to leave immediately?
> Is there some restriction that the Leader cannot leave the cluster? I 
> expected that it would transfer leadership to the other node and leave.
>
> Thanks.
> Joseph
>

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

[Johan Andrén]

Hi Francesco,

In general the GraphStage is meant to encapsulate smaller
graph transformations than sub-graphs and the flow API and 
GraphDSL is the way to go combine graphs. So, one thing 
might be to reconsider if perhaps your GraphStage is doing
too many things at one time and you could separate concerns
into smaller parts which can then more freely be combined.

If you have already considered this but feel sure about your
design, then the materializer is available inside your graph stage
logic through the materializer method.

It would be very interesting to hear about the use case!

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Monday, December 7, 2015 at 4:37:52 PM UTC+1, Francesco Di Muccio wrote:
>
> Hi,
>
> in all the other stages it is possible to get the Materializer from the 
> LifecycleContext to materialize sub-graphs, but in GraphStage it isn't 
> possible, is it by design? 
>
> What is the best way to materialize a sub-graph within a GraphStage? For 
> now my solution is to use a Materializer passed as an implicit parameter to 
> the stage.
>
> Regards,
> Francesco.
>

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

[akka-user] Re: Multiple tcp connections initiated from a server to another

[Johan Andrén]

Hi Jie Tang,

Regarding the discussion about having two connections from A to B, it might 
be a bug, please continue that in the thread that was already discussing 
this. 
(https://groups.google.com/forum/#!searchin/akka-user/connections/akka-user/GYkFfR_ISUI/LCuMDW0wDgAJ)

About the app you describe, it is hard to tell if can be improved without 
knowing more about the requirements and the system is supposed to do.

One thing to think about though, when you create a remote death watch you 
create a very tight coupling with the remote system, 
if there is a problem with the connection to the other system it will be 
marked as quarantined and it cannot come back from that state
but must be restarted. This is probably not what you want for your system, 
or at least something will have thought about
seriously before accepting.

akka-cluster handles such problems better and can allow nodes coming back 
from being unreachable.

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle


On Wednesday, December 30, 2015 at 5:15:16 PM UTC+1, jie tang wrote:
>
> Hi ,all :
> Process A connects to process B via Akka Remote.
> There are two kinds of actors in process A:
> (1)A single monitor actor watches a single manager actor in process B
> If the monitor actor doesn't hold the ActorRef of the manager 
> actor, it sends a Identify message to process B via AskableActorSelection 
> every 10 seconds.
> If the monitor actor gets ActorIdentity message, it holds the 
> ActorRef of the manager actor and watches it
> If the monitor actor gets the Terminated message of the manager 
> actor, it resends Identify Message periodically until it gets ActorIdentity 
> message.
> (2)Many client actors dynamically created.
> Every client actor sends a message to the monitor actor in its 
> preStart method.
>  If the monitor actor holds the ActorRef of the manager actor in 
> Process B, it forwards the messages to the manager actor
> The manager actor creates a server actor for every client actor 
> and returns the ActorRef of the server actor to the client actor
> The client actor watches its server actor and talks to the server 
> actor directly.
> If the client gets Terminated message of the server, it suicides.
>
>
> When process B restarts to update, there may be two tcp connections 
> initiated from process A. I turned on akka log:
> (1)Process A
> Sending remote message ActorSelection(Identify(...))
> (2)Process B
> Receives  message ActorSelection(Identify(...))
> Sending message ActorIdentity(...)
> But Process A's log doesn't show "receives ActorIdentity message"
>
> I guess the issue is about two tcp connections initiated from the same 
> process. 
> Is it a bug? 
> What I should do to avoid or work around that?
> Or I can improve the communcation pattern between process A and 
> process B ?
>
>Thanks very much.
> 
>

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