[akka-user] Akka Clustering (2.2.3) on AWS

[tigerfoot]

Hello,

We're running a distributed app on AWS using an Akka cluster v2.2.3.
A typical config for one of the nodes is below:

akka {
loglevel = WARNING
stdout-loglevel = WARNING
loggers = ["akka.event.slf4j.Slf4jLogger"]
actor {
provider = "akka.cluster.ClusterActorRefProvider"
}
cluster {
seed-nodes = 
["akka.tcp://TestCluster@10.0.1.9:9010","akka.tcp://TestCluster@10.0.10.173:9011"]
auto-down = on
failure-detector.threshold = 12
acceptable-heartbeat-pause = 6 s
}
remote {
transport = "akka.remote.netty.NettyRemoteTransport"
netty.tcp {
port = 9010
}
}
}

The 2 cluster seeds are in different availability zones.  I read somewhere 
in the docs that bumping failure-detector.threshold to 
12 was recommended for AWS.

For a long time this setup worked pretty well, with only occasional (once 
monthly?) instances of one of the nodes falling out of the cluster.
As the system became busier this 'cluster-drop' has become a nightly 
occurrence.  CPU runs stable at around 20-30% on the box.
Memory is flat.

Any ideas what kinds of things can cause this?  Does my config look sane 
for an AWS deployment (m3.large instances)?
I'm launching a cluster soon on Akka 2.3.2, so I'm eager to see if there 
have been changes/improvements that would
help this as well.

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

Re: [akka-user] Akka 2.3.2 Released

[Ngoc Dao]

> I am missing akka-testkit 2.3.2 for Scala 2.11 from maven central.

Hi, can you release akka-cluster for Scala 2.11 too?

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

Re: [akka-user] Akka Persistence - Views with multiple processors

[Olger Warnier]

Based on all your remarks, I found the way to get this organised using the 
Views for scanning changes and thereafter starting an actor with the 
specific actorpath of the sharded eventsourced instance in order to process 
all changes (the meta-data option as you called it). As said, that solves 
the issues of storing data twice and keeps the whole application reasonably 
simple (no application level acknowledgements back and forth)

Thanks for your support, really helped me to get this nailed. (A raw 
version of this is working on my machine now)
Olger


On Tuesday, April 22, 2014 11:56:43 AM UTC+2, Patrik Nordwall wrote:
>
>
>
>
> On Tue, Apr 22, 2014 at 11:32 AM, Olger Warnier 
> 
> > wrote:
>
>>
>> On Monday, April 21, 2014 9:07:03 AM UTC+2, Patrik Nordwall wrote:
>>
>>> On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier wrote:

 On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:

> On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier wrote:
>
>> Hi Patrick, 
>>
>> Sounds like an interesting approach, storing some meta-data at the 
>> view may help to check / show the reliability of the system. 
>>
>> At this moment the events are sent to a processor per node that 
>> publishes the event (distributed pub sub) 
>>
>
> That sounds good, as well.
>  
>
>> When you talk about view, that's the akka-persistence view ? 
>>
>
> Yes, persistence.View and persistence.Processor
>  
>
>> So more or less, the sub processors could send messages to the View 
>> and when there is a Persist() around it, it will be stored. 
>>
>
> I'm not sure I understand what you mean here. Let me clarify my 
> proposal with an example. Let's say we have a User aggregate root with 
> some 
> profile information that can be updated. The user is represented by a 
> User 
> EventsourcedProcessor actor, which is sharded. On the query side we want 
> to 
> be able to search users by first and last name, i.e. we want to store all 
> users in a relational database table on the query side.
>
 Yup, great sample.  

>  
> The User actor persist FirstNameChanged, and inside the persist block 
> it sends a Persistent(FirstNameChanged) message to the AllUsers 
> Processor. 
> On the query side we have a AllUsersView connected to that processor. 
> When 
> AllUsersView receives FirstNameChanged it updates the db table.
>
 Indeed. In what way is the AllUsersView connected to that Processor ? 
 (in a distributed pub sub situation) 

>>>
>>> In a persistent 
>>> View you 
>>> define the processorId that it will read the persistent messages from. It 
>>> reads (replays) from the journal periodically, or when you send it a Update 
>>> message. You can have many views connected to the same processor. The 
>>> processor doesn't have to know anything about the views. In a distributed 
>>> setup you will use a distributed/replicated 
>>> journal and 
>>> thereby the view can be located on another machine than the processor.
>>>  
>>>
 (although, I have to understand in what way 'inside the persist block' 
 is to be interpreted.  

>>>
>>> Ah, I thought you were familiar with EventsourcedProcessor. Read up on 
>>> it in the docs:
>>> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing
>>> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing
>>>  
>>>
>> Clear, that's being followed, Understand your sentence now.  
>>
>>>   

>  
> To handle lost messages between User and AllUsers you might want to 
> send an acknowledgement from AllUsers to User, and have a retry mechanism 
> in User. I would implement that myself in User, but PersistentChannel 
> might 
> be an alternative.
>
 Is it possible todo persistent channels with the distributed pub sub 
 stuff that's available in akka ? 

>>>
>>> Yes, PersistentChannel requires a confirmation from the destination, so 
>>> if you wrap/forward the ConfirmablePersistent and send it via pub-sub it 
>>> should be fine. It will not work if you publish to multiple subscribers.
>>>
>>  
>> I need it with the publish. Is it possible to combine the 
>> DistributedPubSubMediator and the ReliableProxy in some kind of way to get 
>> guaranteed delivery (more or less) over pub sub ?
>>
>
> No, with multiple consumers you have to use something else. That is why 
> persistent Views are an attractive way of publishing the events.
>  
>
>>  (I've read the akka-dev thread on reliable messaging and the use of a MQ 
>> kind of thing for that, but I prefer to keep it clustered without a 
>> specific additional component in between)  
>>
>
> Yes, using an external message broker that has support for this is an 
> alternative.
>
> Cheers,
> Patrik
>  

Re: [akka-user] Will 'Cluster Singleton' always take maxHandOverRetries*retryInterval to initialise?

[Lawrence Wagerfield]

Thanks for clarifying Patrik, and thanks for pointing out the ticket (and 
also for implementing this feature !) :)

On Tuesday, April 22, 2014 6:43:27 PM UTC+1, Patrik Nordwall wrote:
>
>
>
>
> On Tue, Apr 22, 2014 at 5:53 PM, Lawrence Wagerfield <
> lawr...@dmz.wagerfield.com > wrote:
>
>> My question is the same as 'Cluster Singleton 
>> Nightmare'
>>  
>> - I just really want to clarify how this thread was left...
>>
>> Is it true that the singleton manager always takes 
>> `maxHandOverRetries*retryInterval` (seconds) before it spins up the 
>> underlying singleton?
>>
>
> Yes, that is true. We have a ticket to improve this: 
> https://github.com/akka/akka/issues/13869
> /Patrik 
>
>>
>> This seems like a long delay to add to the application startup time, 
>> assuming the application is only useful once this singleton is available.
>>  
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
> JOIN US. REGISTER TODAY! 
> Scala 
> Days 
> June 16th-18th, 
> Berlin 
>
>  

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

Re: [akka-user] akka streams infinite data source example

[Sam Halliday]

Thanks Patrik,

Well it sounds like everything is heading in the right direction, if
it is not already there yet. I'm very excited to see what will be in
the next milestone :-D

On 22 April 2014 12:08, Patrik Nordwall  wrote:
>
>
>
> On Mon, Apr 21, 2014 at 3:59 PM, Sam Halliday 
> wrote:
>>>
>>> On Monday, 21 April 2014 12:32:57 UTC+1, Patrik Nordwall wrote:

 I intend to read the documentation fully, but I was a little
 disappointed that the activator examples did not have a simple example with
 an (effectively) infinite data source that can only be polled in serial,
 with parallel (but controllably finite) consumers.

 Isn't that demonstrated with the random number generator source, and its
 slow consumers?
>>>
>>> I missed that one. How many consumers are there at any given moment?
>>>
>>> It has one consumer but two filter steps that can execute pipelined. You
>>> can attach several consumers with toProducer, and then start several flows
>>> from that. Backpressure works with multiple consumers also.
>>
>>
>>
>> OK great. I did actually see this example and that's not what I mean. I'd
>> really like to be able to specify (e.g. in runtime config files) how many
>> maximum threads can be running in the "filter(rnd => isPrime(rnd))" block.
>>
>> Say we want to do the filtering in parallel, using 2 cores. Imagine the
>> first random number that we get is really big and takes a few seconds to
>> check if it is prime. The second number is "3" and we instantly accept
>> it it would be preferable if this result were held back until the first
>> answer became available, but the free core still goes on to check the third
>> number.
>>
>> Alternatively, I can imagine situations where order does not matter at
>> all. This is all considered in the Observable pattern, so I should imagine
>> you have also included it :-)
>>
>> Does that make sense? Would it be tricky to update the primes example in
>> this way?
>
>
> This should be possible when we have all operators in place. Please create a
> ticket, so that it's not forgotten.
>
>>
>>
>> Adding a second flow is a very different thing. I think I'd need to read
>> the docs (and source code) in a lot more detail before understanding the
>> consequences for a particular Producer (e.g. does it replay from the start,
>> is it sending the same results to all flows, are all flows getting the same
>> order of events, etc). This is of less interest to me at the moment, but I
>> can see it being very important.
>>
>>
>>
>>>
>>> But Iterator[T] is a little too ill-defined near the end of the stream
>>> (that's why I created my own Producer in the RxJava playground). For
>>> example, does it block on hasNext or on next if it knows there are more
>>> elements that are not yet available, or does it close up and go home?
>>> Traditional Java APIs (such as Queues) would actually return early if a
>>> queue was exhausted, instead of waiting for a poison pill. In any case, if
>>> Flow can handle an Iterator that blocks (e.g. for I/O), it's probably good
>>> enough for most situations.
>>>
>>> Ah, I see what you mean. Blocking hasNext/next doesn't sound attractive
>>> to me. That should probably be another Producer, that can do the polling.
>>>
>>
>>
>> Now I'm confused whether Producer is a pull or push based source... in the
>> examples, I was getting the impression that it was very much a pull based
>> API (and would therefore have to block on some level, if data is not
>> available yet). Is it also a pusher?
>
>
> Yes. It gets a request from downstream consumer of X more elements. That
> doesn't mean that it replies immediately with X elements, but it
> asynchronously pushes up to X elements whenever it has them. Exactly how it
> "waits" for the elements itself is up to the implementation of the Producer.
>
>>
>>
>> The brain scanner project is an example of a pusher source... throttling
>> it doesn't make any sense unless it is acceptable to throw results away
>> (i.e. not collect them in time). So, yes, you are absolutely correct that a
>> blocking Iterator is not good here.
>
>
> Sure, it could be implemented as an actor that periodically poll the device,
> but it must still not send more elements downstream than what was requested.
> If it can't slow down the polling, it must buffer and finally throw away
> elements.
>
>>
>> However, for datasources (e.g. reading from a really big query result over
>> a SQL connection), the "next" or "hasNext" in an equivalent Iterator may
>> very well block and there is no way to get around this.
>
>
> Async database driver? Yeah, I know there are not many of those, and then
> you have to use blocking somewhere. Nothing wrong with that, just keep it
> managed. Akka streams are implemented with Actors, and thereby you can use a
> dedicated dispatcher for such things.
>
>>
>> Indeed, you will have the same problem with
>> Source.fromFile(...).readLines, exaggerated if the file is on a really slow
>> hard dr

Re: [akka-user] Reactive / Akka streams of ByteStrings

[Daniel Armak]

On Tue, Apr 22, 2014 at 1:42 PM, Patrik Nordwall
wrote:

> Yes, uncompressing processor must be able to buffer and send smaller
> chunks downstream. If it has a compression ratio of 10:1, and it gets
> demand from downstream of 1000 chunks it should request 100 chunks from its
> upstream. It can not know exactly, but it can do a fairly good guess, and
> even adapt dynamically.
>

IIUC, you expect each processor to be explicitly configured to know the
desired chunk size, for the entire stream or for each producer/consumer
pair separately. Or at least to try to preserve the input chunk size in its
output (which is not always the correct behavior).

What worries me is the lack of a generic interface to handle this setup. If
I get a Producer as a parameter, I have no way to communicate
to it what size chunks I need; I have to trust that whoever created the
actual producer implementation instance configured it correctly. I can't
enforce the constraints that the reactive streams SPI is supposed to
guarantee, such as not getting too much data as input.

It's also bad for separation of mechanism (processors) and policy (chunk
size). One day we'll have support for deploying an akka-stream on top of
akka-remoting, across physical nodes. The stream (materializer?) will want
to control chunk size and buffering policy, which should be different
between local and remote links. Without a standard interface, the
materializer wouldn't be able to tell a black-box Producer to give it
chunks of size X.

I expect projects will start creating local solutions to this problem (I
think akka-http will need one), and I hope eventually one solution will
become a standard library, but it surprises me that the Reactive Streams
designers don't think this is important enough to be part of the API . (As
an optional, but standardized, extra interface a Producer/Consumer can
implement.)

Thanks,

Daniel Armak

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

Re: [akka-user] Will 'Cluster Singleton' always take maxHandOverRetries*retryInterval to initialise?

[Patrik Nordwall]

On Tue, Apr 22, 2014 at 5:53 PM, Lawrence Wagerfield <
lawre...@dmz.wagerfield.com> wrote:

> My question is the same as 'Cluster Singleton 
> Nightmare'
> - I just really want to clarify how this thread was left...
>
> Is it true that the singleton manager always takes
> `maxHandOverRetries*retryInterval` (seconds) before it spins up the
> underlying singleton?
>

Yes, that is true. We have a ticket to improve this:
https://github.com/akka/akka/issues/13869
/Patrik

>
> This seems like a long delay to add to the application startup time,
> assuming the application is only useful once this singleton is available.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] Is there a way to restart an actor?

[Chanan Braunstein]

On Tuesday, April 22, 2014 12:00:12 PM UTC-4, Heiko Seeberger wrote:
>
> On Tue, Apr 22, 2014 at 5:32 PM, Chanan Braunstein <
> chanan.b...@pearson.com > wrote:
>
> I am stopping it with Akka.system().stop(actorRef);
>>
>
> Then you are stopping it. This won't restart the actor.
>

Right. After which I try to re-get the actor ref, but that doesnt work: 

Akka.system().stop(signalJActor);
signalJActor = null; 
signalJActor = Akka.system().actorOf(Props.create(SignalJActor.class), 
"signalJ");

 
>
>> I cannot use a supervisor here since it is right /user - if i were to add 
>> a supervisor above my already existing supervisor I would just have the 
>> same problem with the new actor. 
>>
>
> Really? Well, you could configure the supervisor strategy of the user 
> guardian with akka.actor.guardian-supervisor-strategy.
>

The problem with that is that Restart really isn't what I want to happen in 
all cases. (Could be, haven't thought about it though). The real issue 
seems to be a bug in Play (I think it is at least) I am just trying to work 
around it and force a restart in this one case. I suppose I can send it a 
message cause a particular type of exception and do a restart for that one 
particular case. I will try that.
 

>
> Heiko
>  
>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Heiko Seeberger
> Twitter: @hseeberger
> Blog: blog.heikoseeberger.name
>  

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

Re: [akka-user] Is there a way to restart an actor?

[Chanan Braunstein]

Ugh, I forgot, I cannot send it a message, that is the whole problem. Its 
lost in space so to speak.

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

Re: [akka-user] Akka 2.3.2 Released

[Erik van Oosten]

Thanks!
That worked.

Kind regards,
Erik.


Patrik Nordwall schreef op 22-04-14 09:36:




On Mon, Apr 21, 2014 at 9:31 PM, Erik van Oosten > wrote:


Hello,

Thanks for the new release.

I am missing akka-testkit 2.3.2 for Scala 2.11 from maven central.
Is this still forthcoming, or is akka-testkit replaced by some
other module?


It will be published soonish. I think latest published 
is akka-testkit_2.11.0-RC4/2.3.0.  Given binary 
compatibility that should work with Scala 2.11.0


/Patrik


Kind regards,
Erik.


Patrik Nordwall schreef op 09-04-14 15:16:


/Dear hAkkers,/

We—the Akka committers—are pleased to be able to announce the
availability of Akka 2.3.2. This is the second maintenance
release of the 2.3 branch. It contains fixes for several issues.

This release is backwards binary compatible with version 2.3.0
and 2.3.1 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.


  Migrating from Older Relases

When migrating an existing project from Akka 2.2.x please have a
look at our migration guide

.


  2.3.2 compared to 2.3.1:

  * 5 tickets closed
  * 66 files changed, 637 insertions(+), 174 deletions(-)
  * … and a total of 2 committers!

*Full list of fixed tickets:*

  * /3957/ EventsourcedProcessor must always reject external
Persistent messages
  * /3967/ Second node is unable to join a cluster, regression in
2.3.1
  * /3973/ joinSeedNodeProcess is not unique Exception at the
Cluster Startup
  * /3974/ Some address information was lost in the serialization
of persistent messages
  * /3975/ Check for invalid id extraction in Cluster Sharding


Credits

 commits added removed
 5 182 100 Patrik Nordwall
 2 283  38 Björn Antonsson


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

Website:

  * http://akka.io 

Maven repository:

  * http://repo.akka.io/releases

Binary distribution:

  * http://akka.io/downloads/

Documentation:

  * http://doc.akka.io/docs/akka/2.3.2/
  * http://doc.akka.io/api/akka/2.3.2/
  * http://doc.akka.io/japi/akka/2.3.2/

Issue tracker:

  * http://www.assembla.com/spaces/akka/

Mailing list:

  * https://groups.google.com/group/akka-user

Akka is released under the Apache V2 license.

/Happy hAkking!/


-- 


Patrik Nordwall
Typesafe  - Reactive apps on the JVM
Twitter: @patriknw

JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 
-- 
>> Read the docs: http://akka.io/docs/

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



-- 
Erik van Oosten

http://www.day-to-day-stuff.blogspot.com/

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

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

Re: [akka-user] Is there a way to restart an actor?

[Heiko Seeberger]

On Tue, Apr 22, 2014 at 5:32 PM, Chanan Braunstein <
chanan.braunst...@pearson.com> wrote:

I am stopping it with Akka.system().stop(actorRef);
>

Then you are stopping it. This won't restart the actor.


> I cannot use a supervisor here since it is right /user - if i were to add
> a supervisor above my already existing supervisor I would just have the
> same problem with the new actor.
>

Really? Well, you could configure the supervisor strategy of the user
guardian with akka.actor.guardian-supervisor-strategy.

Heiko


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



-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

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

[akka-user] Will 'Cluster Singleton' always take maxHandOverRetries*retryInterval to initialise?

[Lawrence Wagerfield]

My question is the same as 'Cluster Singleton 
Nightmare'
 
- I just really want to clarify how this thread was left...

Is it true that the singleton manager always takes 
`maxHandOverRetries*retryInterval` (seconds) before it spins up the 
underlying singleton?

This seems like a long delay to add to the application startup time, 
assuming the application is only useful once this singleton is available.

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

Re: [akka-user] Is there a way to restart an actor?

[Chanan Braunstein]

I am stopping it with Akka.system().stop(actorRef);

I cannot use a supervisor here since it is right /user - if i were to add a 
supervisor above my already existing supervisor I would just have the same 
problem with the new actor. 

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

Re: [akka-user] [akka-persistence] Curious about the best approach for handling 'non-replayable' events

[erich oliphant]

Thanks!

On Tuesday, April 22, 2014 3:42:22 AM UTC-4, Patrik Nordwall wrote:
>
> With 
> EventsourceProcessoryou
>  handle replayed events in receiveRecover.
>
> With 
> Processoryou
>  can query recoveryRunning.
>
> Regards,
> Patrik
>
>
> On Tue, Apr 22, 2014 at 12:01 AM, erich oliphant 
> 
> > wrote:
>
>> Hi, I'm just wondering what, when using the Eventsourcing,etc in 
>> akka-persistence, is the best way to handle events that shouldn't be 
>> replayed.  Or perhaps better expressed, letting event handlers know a 
>> replay is happening such that those who shouldn't act during a replay 
>> don't.  So that say a 'UserAdded' event would update a read/view model, but 
>> not send an email during a replay.  
>>
>> 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+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
> JOIN US. REGISTER TODAY! 
> Scala 
> Days 
> June 16th-18th, 
> Berlin 
>
>  

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

Re: [akka-user] Is there a way to restart an actor?

[Heiko Seeberger]

What's a stop command? Do you mean the `akka.actor.PoisonPill`? If so, this
will stop/kill/terminate the actor, not restart it. You can send
`akka.actor.Kill` which will make your actor blow up (fail) with
an `ActorKilledException`, so the supervisor kicks in. By default it would
also stop your actor, but you can change the supervisor strategy to
`SupervisorStrategy.Restart` for an `ActorKilledException`.

Heiko


On Tue, Apr 22, 2014 at 4:32 PM, Chanan Braunstein <
chanan.braunst...@pearson.com> wrote:

> Not even sure this make sense, but I am trying to work around a bug (I
> think) I found in play, see here:
> https://groups.google.com/forum/#!topic/play-framework/8eyfIVKvW3o
>
> To me that seems to be a bug, but in mean time I am trying to force that
> actor to restart. I tried sending it a stop command and asking for new
> ActorRef but same result. Is there any way I can work around this issue? Or
> maybe its not an issue and I am doing something wrong?
>
> Thanks,
> Chanan.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

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

[akka-user] Is there a way to restart an actor?

[Chanan Braunstein]

Not even sure this make sense, but I am trying to work around a bug (I 
think) I found in play, see 
here: https://groups.google.com/forum/#!topic/play-framework/8eyfIVKvW3o

To me that seems to be a bug, but in mean time I am trying to force that 
actor to restart. I tried sending it a stop command and asking for new 
ActorRef but same result. Is there any way I can work around this issue? Or 
maybe its not an issue and I am doing something wrong?

Thanks,
Chanan.

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

Re: [akka-user] Error in Eclipse

[Patrik Nordwall]

Hi B,

I can confirm that I can reproduce this issue. Eclipse JDT generates
different bytecode than javac. The modifier of the anonymous class is 8
(STATIC) for javac, but 0 for JDT. You might want to file a bug
reportto Eclipse.

/Patrik



On Mon, Apr 14, 2014 at 6:37 AM, Boney Sekh  wrote:

>
> Hi,
>
> I was trying use the recommended practice of having a creator as part of
> the untyped actors to have a compile time validation of the actor
> constructors.
> However running JUnits against such classes from *Eclipse *is giving me
> this error:
>
> java.lang.IllegalArgumentException: cannot use non-static local Creator to
> create actors; make it static (e.g. local to a static method) or top-level
> at akka.actor.Props$.create(Props.scala:112)
> at akka.actor.Props.create(Props.scala)
>
> This doesn't happen when using the command line javac (from Maven) or when
> using IntelliJ IDEA.
>
> Since there are many eclipse users in our group, I'd like to check if
> there is a way to work around this? Is this some sort of scala eclipse
> plugin issue?
>
> Also this seems to happen only when I use the Creator as an inline
> instance.
>
>
> This works:
> public static Props props( final String param1, final String param2) {
> return Props.create( new MyActorCreator( param1, param2) );
> }
>
> This fails in eclipse with the error above when running JUnits.
> public static Props props( final String param1, final String param2) {
> return Props.create( new Creator() {
>@Override
> public MyActorcreate() throws Exception {
> return new MyActor( param1, param2);
> }
> });
> }
>
> Any help would be appreciated.
>
> Cheers,
> B
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] Best way to communicate with an Actor?

[Chanan Braunstein]

There could be a few ways you can get the ActorRefs X,Y,Z to "someactor" 
you could, for example, create a message from SomeActor to the parent of 
X,Y,Z (in this example it would /users) and ask it to return the ActorRefs. 
Then you would save them in someactor and use them to talk to X,Y,Z.

I ended up going a different route, and decided not to save the ActoRefs in 
"someactor". Since in my case /users is a singleton I send it messages to 
route to the children. It uses its getChild and children functions to route 
to one or more actors under it as needed.

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

Re: [akka-user] Strange behavior with Akka Tcp

[Patrik Nordwall]

On Fri, Apr 11, 2014 at 8:32 PM, Chris Baxter  wrote:

> I'm using the latest release of Akka (2.3.2) and I've been playing around
> with the Tcp Api a bit, trying to get familiar with how it works.  In doing
> so, I've been writing a little Memcached binary client.  This usage of Tcp
> is a little different then the examples in the docs in that the connection
> is kept alive and never closed (unless the peer closes the connection in
> which a reconnect will happen).  In my little prototype, I'm using the Ack
> based back-pressure solution.  I also recently switched to pullMode for
> reads because I found that when I didn't, so many reads were coming when I
> was hammering it with load that it took forever to receive the write ack
> thus delaying the next write and slowing throughput down.  When I switched
> to pullMode, things sped up, but now I'm running into a strange issue where
> I eventually do not receive an Ack for one of the writes that I made which
> pretty much kills the flow as it's the acks that keep data flowing from my
> memcached node actor into the connection actor.  I enabled trace logging
> and more often then not, when this happens, I see this is the log as the
> last log message from the selection handler:
>
> [DEBUG] [04/11/2014 14:11:02.281] [couch-akka.actor.default-dispatcher-22]
> [akka://couch/system/IO-TCP/selectors/$a/0] Wrote [0] bytes to channel
>
> I can post my code if need be, but I just wanted to first see if anyone
> else has ever seen this behavior.
>
Yes, please post the code.
/Patrik



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



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] GSoC project mentoring

[Patrik Nordwall]

Hi Szymon,

Thanks for your request. Unfortunately the Akka team is unable to mentor
any GSoC at the moment.

Regards,
Patrik


On Thu, Apr 17, 2014 at 9:35 AM, Szymon Matejczyk wrote:

> Hi guys,
>
> I want to take part in Google Summer of Code(https://www.google-
> melange.com/gsoc/homepage/google/gsoc2014) to develop a graph library
> that will have rich interface as Scala-graph (scala-graph.org) while
> using some low level structures as Twitter's Cassovary (
> https://github.com/twitter/cassovary) to achieve better performance. On
> top of it, I would like to integrate it with Akka to allow distributed
> computations. I would like to allow user to define a division of graph to
> subgraphs, computing semi-results for subgraphs (distributed) and merging
> results gathered from the subgraphs.
>
> Unfortunately, I was unable to find mentor in the Scala team, but was
> suggested to ask here. Maybe someone from the Akka team can help?
>
> I prepared detailed plan of my work, I've been already working on similar
> stuff (used scala-graph, contributed to Cassovary), so I don't need a lot
> of technical help.
>
> If you is interested, I can send complete application to GSoC.
>
> Cheers,
> Szymon
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] akka streams infinite data source example

[Patrik Nordwall]

On Mon, Apr 21, 2014 at 3:59 PM, Sam Halliday wrote:

> On Monday, 21 April 2014 12:32:57 UTC+1, Patrik Nordwall wrote:
>>>
>>> I intend to read the documentation fully, but I was a little
>>> disappointed that the activator examples did not have a simple example with
>>> an (effectively) infinite data source that can only be polled in serial,
>>> with parallel (but controllably finite) consumers.
>>>
>>> Isn't that demonstrated with the random number generator source, and its
>>> slow consumers?
>>>
>> I missed that one. How many consumers are there at any given moment?
>>
>> It has one consumer but two filter steps that can execute pipelined. You
>> can attach several consumers with toProducer, and then start several flows
>> from that. Backpressure works with multiple consumers also.
>>
>
>
> OK great. I did actually see this example and that's not what I mean. I'd
> really like to be able to specify (e.g. in runtime config files) how many
> maximum threads can be running in the "filter(rnd => isPrime(rnd))" block.
>
> Say we want to do the filtering in parallel, using 2 cores. Imagine the
> first random number that we get is really big and takes a few seconds to
> check if it is prime. The second number is "3" and we instantly accept
> it it would be preferable if this result were held back until the first
> answer became available, but the free core still goes on to check the third
> number.
>
> Alternatively, I can imagine situations where order does not matter at
> all. This is all considered in the Observable pattern, so I should imagine
> you have also included it :-)
>
> Does that make sense? Would it be tricky to update the primes example in
> this way?
>

This should be possible when we have all operators in place. Please create
a ticket , so that it's not forgotten.


>
> Adding a second flow is a very different thing. I think I'd need to read
> the docs (and source code) in a lot more detail before understanding the
> consequences for a particular Producer (e.g. does it replay from the start,
> is it sending the same results to all flows, are all flows getting the same
> order of events, etc). This is of less interest to me at the moment, but I
> can see it being very important.
>
>
>
>
>> But Iterator[T] is a little too ill-defined near the end of the stream
>> (that's why I created my own Producer in the RxJava playground). For
>> example, does it block on hasNext or on next if it knows there are more
>> elements that are not yet available, or does it close up and go home?
>> Traditional Java APIs (such as Queues) would actually return early if a
>> queue was exhausted, instead of waiting for a poison pill. In any case, if
>> Flow can handle an Iterator that blocks (e.g. for I/O), it's probably good
>> enough for most situations.
>>
>> Ah, I see what you mean. Blocking hasNext/next doesn't sound attractive
>> to me. That should probably be another Producer, that can do the polling.
>>
>>
>
> Now I'm confused whether Producer is a pull or push based source... in the
> examples, I was getting the impression that it was very much a pull based
> API (and would therefore have to block on some level, if data is not
> available yet). Is it also a pusher?
>

Yes. It gets a request from downstream consumer of X more elements. That
doesn't mean that it replies immediately with X elements, but it
asynchronously pushes up to X elements whenever it has them. Exactly how it
"waits" for the elements itself is up to the implementation of the
Producer.


>
> The brain scanner project is an example of a pusher source... throttling
> it doesn't make any sense unless it is acceptable to throw results away
> (i.e. not collect them in time). So, yes, you are absolutely correct that a
> blocking Iterator is not good here.
>

Sure, it could be implemented as an actor that periodically poll the
device, but it must still not send more elements downstream than what was
requested. If it can't slow down the polling, it must buffer and finally
throw away elements.


> However, for datasources (e.g. reading from a really big query result over
> a SQL connection), the "next" or "hasNext" in an equivalent Iterator may
> very well block and there is no way to get around this.
>

Async database driver? Yeah, I know there are not many of those, and then
you have to use blocking somewhere. Nothing wrong with that, just keep it
managed. Akka streams are implemented with Actors, and thereby you can use
a dedicated dispatcher for such things.


> Indeed, you will have the same problem with
> Source.fromFile(...).readLines, exaggerated if the file is on a really slow
> hard drive (or a network drive).
>

Yes, there will most likely be special producers for working with files.

/Patrik


>
> Best regards,
> Sam
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https:

Re: [akka-user] Reactive / Akka streams of ByteStrings

[Patrik Nordwall]

On Mon, Apr 21, 2014 at 2:26 PM, Daniel Armak  wrote:

> Hi Patrik,
>
> That can be done, but what bothers me is the potential lack of
> standardization. Every programmer will solve this problem all over again
> for each stream they build. Even if particular Reactive Streams
> implementations offer generic tools, they won't be compatible across
> implementations or languages, which is the whole point of Reactive Streams.
>
> Any processor in a stream that emits new ByteStrings needs to know the
> allowed or preferred min/max size to emit. E.g., an uncompressing processor
> that expands a 1kb input to a 1MB input may need to avoid sending the whole
> 1MB as a single ByteString (or you end up with zip bombs).
>

Yes, uncompressing processor must be able to buffer and send smaller chunks
downstream. If it has a compression ratio of 10:1, and it gets demand from
downstream of 1000 chunks it should request 100 chunks from its upstream.
It can not know exactly, but it can do a fairly good guess, and even adapt
dynamically.

I might over-simplify this. Thoughts, anyone else?

Regards,
Patrik


> The output size to use depends on the processor that comes after it (and
> not just on global per-stream settings). Some consumers can process any
> size input very quickly, so if you have a big ByteString in memory, you
> should send it over to free your own buffer. Others may need to buffer
> their input and this can consume a lot of extra memory - e.g. if the
> pipeline is based on byte arrays and splitting these means making copies.
> (ByteStrings mostly avoid copying, but what about non-Scala implementations
> that you need to work with, things like Netty?) Some processors might
> require exactly sized input chunks (e.g. encryption), and you may want to
> make sure the buffering/chunking is done once (in the producer) and not
> twice (in both producer and consumer) for efficiency.
>
> All of this argues for a way for byte stream producers/consumers to
> communicate directly about their preferences.
>
> Also, even if the programmer is going to specify the correct sizes
> manually for each producer, those producers still have to be configurable
> in this way. This is something I feel would benefit greatly from a
> standardized approach.
>
> Without it, I'm afraid that a lot of the idioms, examples, and library
> functions that will evolve around reactive streams won't be applicable to
> byte streams. Generic buffering/chunking idioms, like collecting up to X
> items, or buffering and batching them, need a 'flatMap'-like transformation
> to apply to byte streams.
>
> I think the way forward is to propose optional 'byte stream' interfaces
> extending the Producer/Consumer ones and see what sticks - but this has to
> wait for Akka Streams to mature. In particular, I feel akka-http will have
> to solve this problem somehow. E.g., if I write a spray server and I have
> an HttpResponsePart producer, how do I know what size ByteStrings to send
> to the consumer that ships these out to the network?
>

> Daniel
>
>
> On Mon, Apr 21, 2014 at 2:50 PM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>>
>>
>> 20 apr 2014 kl. 00:32 skrev Daniel Armak :
>>
>> Hi,
>>
>> How would I use reactive streams in general, and/or akka streams in
>> particular, to represent a stream of binary data? I'm thinking of all
>> binary streams that don't have a natural division into chunks of a fixed
>> (small) size; you can divide them into chunks any way you want and all
>> processors in the pipeline will still work. Like downloading a big file
>> over HTTP, decompressing and saving it to disk.
>>
>> The natural representation is a stream of ByteString (or byte[] in Java).
>> But each ByteString can be arbitrarily large.
>>
>>
>> Can it? Wouldn't it be good if a ByteString producer has a chunk size
>> limit as part of its contract? Then a chunk corresponds to 1 element.
>>
>> /Patrik
>>
>> It's no good to tell the producer I'm willing to accept one more element,
>> if I have no idea what size it's going to be. Maybe the producer is reading
>> from a 100MB ByteString it already has in memory, and the easiest thing for
>> it to do (i.e. the easiest way for a programmer to code the producer) is to
>> send all of the data as one element. What I really want is to tell it how
>> many more bytes (or characters, etc) I'm willing to accept, but in the
>> current reactive streams API that would require sending each byte in a
>> separate call to onNext.
>>
>> Some of the implementations might address this scenario, but it seems to
>> me that this will be a common use case and so standardization and
>> interoperability would be of value.
>>
>> I'm sure this has all been thought of. What's the recommended usage
>> pattern?
>>
>> -
>>
>> Also, some processors do have a natural chunk size (e.g. compression,
>> encryption, network packet transmission). This size will rarely match the
>> size of the incoming chunks (if only because different processors in

Re: [akka-user] Akka Persistence - Views with multiple processors

[Patrik Nordwall]

On Tue, Apr 22, 2014 at 11:32 AM, Olger Warnier  wrote:

>
> On Monday, April 21, 2014 9:07:03 AM UTC+2, Patrik Nordwall wrote:
>
>> On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier  wrote:
>>>
>>> On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
>>>
 On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier wrote:

> Hi Patrick,
>
> Sounds like an interesting approach, storing some meta-data at the
> view may help to check / show the reliability of the system.
>
> At this moment the events are sent to a processor per node that
> publishes the event (distributed pub sub)
>

 That sounds good, as well.


> When you talk about view, that's the akka-persistence view ?
>

 Yes, persistence.View and persistence.Processor


> So more or less, the sub processors could send messages to the View
> and when there is a Persist() around it, it will be stored.
>

 I'm not sure I understand what you mean here. Let me clarify my
 proposal with an example. Let's say we have a User aggregate root with some
 profile information that can be updated. The user is represented by a User
 EventsourcedProcessor actor, which is sharded. On the query side we want to
 be able to search users by first and last name, i.e. we want to store all
 users in a relational database table on the query side.

>>> Yup, great sample.
>>>

 The User actor persist FirstNameChanged, and inside the persist block
 it sends a Persistent(FirstNameChanged) message to the AllUsers Processor.
 On the query side we have a AllUsersView connected to that processor. When
 AllUsersView receives FirstNameChanged it updates the db table.

>>> Indeed. In what way is the AllUsersView connected to that Processor ?
>>> (in a distributed pub sub situation)
>>>
>>
>> In a persistent 
>> View you
>> define the processorId that it will read the persistent messages from. It
>> reads (replays) from the journal periodically, or when you send it a Update
>> message. You can have many views connected to the same processor. The
>> processor doesn't have to know anything about the views. In a distributed
>> setup you will use a distributed/replicated 
>> journal and
>> thereby the view can be located on another machine than the processor.
>>
>>
>>> (although, I have to understand in what way 'inside the persist block'
>>> is to be interpreted.
>>>
>>
>> Ah, I thought you were familiar with EventsourcedProcessor. Read up on it
>> in the docs:
>> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing
>> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing
>>
>>
> Clear, that's being followed, Understand your sentence now.
>
>>
>>>

 To handle lost messages between User and AllUsers you might want to
 send an acknowledgement from AllUsers to User, and have a retry mechanism
 in User. I would implement that myself in User, but PersistentChannel might
 be an alternative.

>>> Is it possible todo persistent channels with the distributed pub sub
>>> stuff that's available in akka ?
>>>
>>
>> Yes, PersistentChannel requires a confirmation from the destination, so
>> if you wrap/forward the ConfirmablePersistent and send it via pub-sub it
>> should be fine. It will not work if you publish to multiple subscribers.
>>
>
> I need it with the publish. Is it possible to combine the
> DistributedPubSubMediator and the ReliableProxy in some kind of way to get
> guaranteed delivery (more or less) over pub sub ?
>

No, with multiple consumers you have to use something else. That is why
persistent Views are an attractive way of publishing the events.


> (I've read the akka-dev thread on reliable messaging and the use of a MQ
> kind of thing for that, but I prefer to keep it clustered without a
> specific additional component in between)
>

Yes, using an external message broker that has support for this is an
alternative.

Cheers,
Patrik


>
>
 That is the most straight forward solution. The drawback is that
 FirstNameChanged is stored twice. Therefore I suggested the meta-data
 alternative. User sends Persistent(UserChangedNotification(processorId)))
 to the AllUsers Processor. When AllUsersView receives
 UserChangedNotification it creates a child actor, a View for the
 processorId in the UserChangedNotification, if it doesn't already have such
 a child. That view would replay all events of the User and can update the
 database table. It must keep track of how far it has replayed/stored in db,
 i.e. seqNr must be stored in the db. The child View can be stopped when it
 becomes inactive.

>>> Will that work with a sharded cluster ? (and a 'View' may be running on
>>> another node)
>>>
>>
>> yes
>>
>>
>>>
>>>

 That alternative is more complicate

Re: [akka-user] BalancingDispatcher Broadcast message bug.

[Patrik Nordwall]

On Thu, Apr 17, 2014 at 7:47 AM, Roland Kuhn  wrote:

>
> 16 apr 2014 kl. 23:26 skrev √iktor Ҡlang :
>
> Hi Vitaly,
>
> On Wed, Apr 16, 2014 at 11:24 PM, vitaly tamazyan 
> wrote:
>
>> Good point, thanks!
>> I think this corner case should be noted in the documentation on
>> Broadcast messages, because now it says:
>> "A Broadcast message can be used to send a message to *all* of a
>> router's routees.
>> When a router receives aBroadcast message, it will broadcast that
>> message's *payload* to all routees, no matter how that router would
>> normally route its messages.
>>
>> It is hard to connect a problem with routing to the type of dispatcher.
>>
>
> But the above is still true. It sends the message to all routees, and
> since they share the same mailbox, you get N messages in that mailbox, and
> those messages will be processed on a first-come-first-served basis.
>
>
> I think there is an opportunity here to improve the BalancingDispatcher in
> not allowing the Broadcast message ;-) Any takers?
>

Ticket created: https://github.com/akka/akka/issues/15030


>
> Regards,
>
> Roland
>
>
>
>>
>>
>> четверг, 17 апреля 2014 г., 0:03:10 UTC+3 пользователь √ написал:
>>>
>>> Hi Vitaly,
>>>
>>> Actors who have a BalancingDispatcher are sharing the same mailbox
>>> instance.
>>> Your observed behavior is perfectly expected.
>>>
>>>
>>> On Wed, Apr 16, 2014 at 11:00 PM, vitaly tamazyan 
>>> wrote:
>>>
 When I try to tell a Broadcast message to routees with
 BalancingDispatcher, I get strange behavior -- some actors get the
 message twice, and some -- not at all.
 Same thing happens if  I manually iterate through routee's  actorRefs and
 send a message directly to them. This I believe is not right.
 When I use another types of dispatchers, everything works as expected.
 tested on akka 2.2.4, java 7, linux mint 16

 See example code below:

 public void test() {
 ActorSystem system = ActorSystem.create("test");

 Props routeeProps = Props.create(Worker.class).
 withDispatcher("akka.workerDispatcher");

 List routees = new ArrayList<>();

 for (int i = 16; i > 0; i--) {
 ActorRef actor = system.actorOf(routeeProps, "Worker" + i);
 routees.add(actor);
 }

 ActorRef workers = system.actorOf(
 Props.empty().withRouter(RoundRobinRouter.create(
 routees)
 .withDispatcher("akka.managerDispatcher")),"Workers");

 for (int i = 0; i < 10; i++) {
 workers.tell(new Broadcast("test" + i), null);
 }
 }


 public class Worker extends UntypedActor {
 private LoggingAdapter logger = 
 Logging.getLogger(getContext().system().eventStream(),
 this);
 private Random r = new Random();

 @Override
 public void onReceive(Object message) throws Exception {
 logger.debug(getSelf().path().name() + "  " + message);
 Thread.sleep(100 * r.nextInt(10)); // emulate load
 }
 }


 *application.conf*

  akka {
  workerDispatcher {
executor = "thread-pool-executor"
type = BalancingDispatcher
}

  managerDispatcher {
   executor = "thread-pool-executor"
   type = Dispatcher
   }

  loggers = ["akka.event.slf4j.Slf4jLogger"]
   loglevel="DEBUG"

   log-dead-letters-during-shutdown = off
  }

 *output:*
 .
 23:43:04.234 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker3  test9
 23:43:04.333 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker5  test9
 23:43:04.334 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker1  test9
 23:43:04.335 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker13  test9
 23:43:04.336 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker9  test9
 23:43:04.433 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker6  test9
 23:43:04.434 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker7  test9
 23:43:04.435 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker16  test9
 *23:43:04.633 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker14  test9*
 23:43:04.637 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker4  test9
 23:43:04.733 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker5  test9
 23:43:04.734 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker10  test9
 23:43:04.735 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker1  test9
 *23:43:04.736 [test-akka.actor.default-dispatcher-4] DEBUG Worker -
 Worker14  test9*
 

Re: [akka-user] SmallestMailboxPool vs BalancingPool

[Patrik Nordwall]

Hi Rob,


On Fri, Apr 18, 2014 at 10:12 AM, Rob Bakker
wrote:

> Hi
>
> I'm looking at the different routers and was wandering why would I use the
> *SmallestMailboxPool*, now that the *BalancingPool *is introduced?
> I can't think of any situation that the *SmallestMailboxPool *will work
> better than the *BalancingPool*?
>

That is a good question and I'm trying to think of a reason why we have
"always" had those two alternatives. They are operating in very different
ways, and for certain high load usage you might notice some better
performance of one or the other. That must be measured for the application
specific scenario. However, I can't see a compelling reason to use
SmallestMailboxPool. Should we remove it? Thoughts, anyone else?

One thing that BalancingPool can't handle (in intended way) is sending
Broadcast message to all routees.

Regards,
Patrik


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



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] Akka Persistence - Views with multiple processors

[Olger Warnier]

On Monday, April 21, 2014 9:07:03 AM UTC+2, Patrik Nordwall wrote:
>
> On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier 
> > wrote:
>>
>> On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
>>
>>> On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier wrote:
>>>
 Hi Patrick, 

 Sounds like an interesting approach, storing some meta-data at the view 
 may help to check / show the reliability of the system. 

 At this moment the events are sent to a processor per node that 
 publishes the event (distributed pub sub) 

>>>
>>> That sounds good, as well.
>>>  
>>>
 When you talk about view, that's the akka-persistence view ? 

>>>
>>> Yes, persistence.View and persistence.Processor
>>>  
>>>
 So more or less, the sub processors could send messages to the View and 
 when there is a Persist() around it, it will be stored. 

>>>
>>> I'm not sure I understand what you mean here. Let me clarify my proposal 
>>> with an example. Let's say we have a User aggregate root with some profile 
>>> information that can be updated. The user is represented by a User 
>>> EventsourcedProcessor actor, which is sharded. On the query side we want to 
>>> be able to search users by first and last name, i.e. we want to store all 
>>> users in a relational database table on the query side.
>>>
>> Yup, great sample.  
>>
>>>  
>>> The User actor persist FirstNameChanged, and inside the persist block it 
>>> sends a Persistent(FirstNameChanged) message to the AllUsers Processor. On 
>>> the query side we have a AllUsersView connected to that processor. When 
>>> AllUsersView receives FirstNameChanged it updates the db table.
>>>
>> Indeed. In what way is the AllUsersView connected to that Processor ? (in 
>> a distributed pub sub situation) 
>>
>
> In a persistent 
> View you 
> define the processorId that it will read the persistent messages from. It 
> reads (replays) from the journal periodically, or when you send it a Update 
> message. You can have many views connected to the same processor. The 
> processor doesn't have to know anything about the views. In a distributed 
> setup you will use a distributed/replicated 
> journal and 
> thereby the view can be located on another machine than the processor.
>  
>
>> (although, I have to understand in what way 'inside the persist block' is 
>> to be interpreted.  
>>
>
> Ah, I thought you were familiar with EventsourcedProcessor. Read up on it 
> in the docs:
> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing
> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing
>  
>
Clear, that's being followed, Understand your sentence now.  

>  
>>
>>>  
>>> To handle lost messages between User and AllUsers you might want to send 
>>> an acknowledgement from AllUsers to User, and have a retry mechanism in 
>>> User. I would implement that myself in User, but PersistentChannel might be 
>>> an alternative.
>>>
>> Is it possible todo persistent channels with the distributed pub sub 
>> stuff that's available in akka ? 
>>
>
> Yes, PersistentChannel requires a confirmation from the destination, so if 
> you wrap/forward the ConfirmablePersistent and send it via pub-sub it 
> should be fine. It will not work if you publish to multiple subscribers.
>
 
I need it with the publish. Is it possible to combine the 
DistributedPubSubMediator and the ReliableProxy in some kind of way to get 
guaranteed delivery (more or less) over pub sub ? (I've read the akka-dev 
thread on reliable messaging and the use of a MQ kind of thing for that, 
but I prefer to keep it clustered without a specific additional component 
in between)  


>>> That is the most straight forward solution. The drawback is that 
>>> FirstNameChanged is stored twice. Therefore I suggested the meta-data 
>>> alternative. User sends Persistent(UserChangedNotification(processorId))) 
>>> to the AllUsers Processor. When AllUsersView receives 
>>> UserChangedNotification it creates a child actor, a View for the 
>>> processorId in the UserChangedNotification, if it doesn't already have such 
>>> a child. That view would replay all events of the User and can update the 
>>> database table. It must keep track of how far it has replayed/stored in db, 
>>> i.e. seqNr must be stored in the db. The child View can be stopped when it 
>>> becomes inactive.
>>>
>> Will that work with a sharded cluster ? (and a 'View' may be running on 
>> another node)
>>
>
> yes
>  
>
>>  
>>
>>>  
>>> That alternative is more complicated, and I'm not sure it is worth it.
>>>
>> From a solution perspective, using the distributed pub sub, maybe with 
>> persistent channels is what will do. 
>>
>> Most of my questions have todo with using akka-persistence as a full 
>> fledged DDD framework, not too hard without the sharding (although a view 
>> for every aggregate root instance se

Re: [akka-user] How to discover in akka-camel that my endpoint is not available?

[Patrik Nordwall]

Hi Jedrek,


On Thu, Apr 17, 2014 at 5:10 PM, Jedrek Fulara  wrote:

> Hello,
>
> I am using akka-camel (in scala) to connect to RabbitMQ. I would like to
> make my app more robust, i.e. reconnect to the queue after connection
> failures. However, when I switch my RabbitMQ server off, I do not get any
> exception in my akka actor, I just stop receiving the messages. When I turn
> the server on again, I don't start receiving messages again (thus, I reason
> that akka-camel does not reconnect on its own). Is there a way to detect
> that the queue is not available?
>

Is the Producer or Consumer actor not restarted or stopped?

Regards,
Patrik


>
> When I use a standard RabbitMQ client (in .NET, however), then I
> immediately get an exception after shutting down the server.
>
>
> regards,
> Jedrek
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] [akka-persistence] Curious about the best approach for handling 'non-replayable' events

[Patrik Nordwall]

With 
EventsourceProcessoryou
handle replayed events in receiveRecover.

With 
Processoryou
can query recoveryRunning.

Regards,
Patrik


On Tue, Apr 22, 2014 at 12:01 AM, erich oliphant
wrote:

> Hi, I'm just wondering what, when using the Eventsourcing,etc in
> akka-persistence, is the best way to handle events that shouldn't be
> replayed.  Or perhaps better expressed, letting event handlers know a
> replay is happening such that those who shouldn't act during a replay
> don't.  So that say a 'UserAdded' event would update a read/view model, but
> not send an email during a replay.
>
> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] Akka 2.3.2 Released

[Patrik Nordwall]

On Mon, Apr 21, 2014 at 9:31 PM, Erik van Oosten wrote:

>  Hello,
>
> Thanks for the new release.
>
> I am missing akka-testkit 2.3.2 for Scala 2.11 from maven central.
> Is this still forthcoming, or is akka-testkit replaced by some other
> module?
>

It will be published soonish. I think latest published
is akka-testkit_2.11.0-RC4/2.3.0. Given binary compatibility that should
work with Scala 2.11.0

/Patrik


>
> Kind regards,
> Erik.
>
>
> Patrik Nordwall schreef op 09-04-14 15:16:
>
>  *Dear hAkkers,*
>
> We—the Akka committers—are pleased to be able to announce the availability
> of Akka 2.3.2. This is the second maintenance release of the 2.3 branch. It
> contains fixes for several issues.
>
> This release is backwards binary compatible with version 2.3.0 and 2.3.1
> 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.
> Migrating from Older Relases
>
> When migrating an existing project from Akka 2.2.x please have a look at
> our migration 
> guide
> .
> 2.3.2 compared to 2.3.1:
>
>- 5 tickets closed
>- 66 files changed, 637 insertions(+), 174 deletions(-)
>- … and a total of 2 committers!
>
> *Full list of fixed tickets:*
>
>- *3957* EventsourcedProcessor must always reject external Persistent
>messages
>- *3967* Second node is unable to join a cluster, regression in 2.3.1
>- *3973* joinSeedNodeProcess is not unique Exception at the Cluster
>Startup
>- *3974* Some address information was lost in the serialization of
>persistent messages
>- *3975* Check for invalid id extraction in Cluster Sharding
>
> Credits
>
> commits added removed
> 5 182 100 Patrik Nordwall
> 2 283  38 Björn Antonsson
>
>  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”.
>
> Website:
>
>- http://akka.io
>
> Maven repository:
>
>- http://repo.akka.io/releases
>
> Binary distribution:
>
>- http://akka.io/downloads/
>
> Documentation:
>
>- http://doc.akka.io/docs/akka/2.3.2/
>- http://doc.akka.io/api/akka/2.3.2/
>- http://doc.akka.io/japi/akka/2.3.2/
>
> Issue tracker:
>
>- http://www.assembla.com/spaces/akka/
>
> Mailing list:
>
>- https://groups.google.com/group/akka-user
>
> Akka is released under the Apache V2 license.
>
> *Happy hAkking!*
>
>  --
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
> JOIN US. REGISTER TODAY! 
>  Scala 
> Days 
>  June 16th-18th, 
> Berlin 
>   --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Erik van Oostenhttp://www.day-to-day-stuff.blogspot.com/
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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

Re: [akka-user] akka-kafka consumer

[Patrik Nordwall]

Thanks for sharing, Scott. Please add it to the community
pageif you like.
/Patrik


On Mon, Apr 21, 2014 at 9:20 PM, Scott Clasen wrote:

> Since there were a few kafka related questions here lately, figured I
> would factor this code out of some stuff I'm doing in case it's of use to
> others.
>
> https://github.com/sclasen/akka-kafka
>
> The consumer does explicit management of committing offsets, and allows
> actor based async processing of messages from kafka while keeping an upper
> bound on the maximum number of in-flight messages.
>
> Happy to accept PRs, issues, etc. version 0.0.2 is in maven central.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! 
Scala 
Days 
June 16th-18th, 
Berlin 

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