Re: [akka-user] FSM gets a message before a transition finishes?

[Konrad 'ktoso' Malawski]

Hello Eugene,

The scenario you have outlined can not happen - you’re safe from this kind of 
race thanks to the Actor’s properties.

The transition as well as calling the transition handlers for the new state are 
all still happening during Actor A’s receive, which means that it is guaranteed 
that the state will have changed to S2 before the next message is processed.

You can track this flow by looking into FSM.scala and track the flow from 
receive thorough through processMsg right to makeTransition and 
handleTransition.

If you need more tips let me know — happy hacking!



-- 
Konrad 'ktoso' Malawski
hAkker - Typesafe, 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Visualisation of running system

[Konrad 'ktoso' Malawski]

Hello there,
The Console is in deed EndOfLife-ing.
The Typesafe Activator is on it’s way to support more and more actor tracing 
etc. Currently it does a little bit already, though it’s currently not a 
production solution.

Thanks to EOLing the console multiple community projects have appeared around 
tracing,
I’m aware of Kamon: http://kamon.io and AkkaTracing: 
https://github.com/levkhomich/akka-tracing

// Was not able to try them out yet.

I hope that helps (a bit) :-)

-- 
Konrad 'ktoso' Malawski
hAkker - Typesafe, 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Testing that an actor throws an exception

[Konrad 'ktoso' Malawski]

How about extracting the actor’s behaviour to a trait, and test that trait for 
the expected throw behaviour using plain old ScalaTest `intercept[Exception] { 
… }`, would it make sense in your case or are the interactions “very relying on 
the thing being an actor”?

Having that said, it’s just my personal preference to test like this.
So other options are… 
   a) what you described already, preparing a special parent actor
   b) overriding `aroundReceive(…)` in the tested actor, since it’s “around”, 
you can have your `intercept[…]` code there. (Feels a bit weird though.)

I hope one of these options fits you! :-)

-- 
Konrad 'ktoso' Malawski
hAkker - Typesafe, 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Is it possible to use EventsourcedProcessor with FSM[S, D]?

[Konrad 'ktoso' Malawski]

Thanks, your feedback is well appreciated!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

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

[Konrad 'ktoso' Malawski]

Cześć Adam :-)


- is it reasonable (thinking about reactive streams in general) to have an 
actor which produces elements on-demand (instead of providing a 
collection/iterator/() = as is currently supported)? As far as I understand 
the current implementation, subscribers explicitly ask publishers for more 
elements (through Subscription.requestMore) - so it seems it would be possible 
to pass such a request to an actor and ask for the given amount of elements. Is 
there any chance to get actor producers in some future releases, or there are 
no such plans currently?
Yes, definitely! We currently do support it (on release-2.3-dev, it’s pretty 
new) via:

```
/**
   * Define the sequence of elements to be produced by the given closure.
   * The stream ends normally when evaluation of the closure results in
   * a [[akka.stream.Stop]] exception being thrown; it ends exceptionally
   * when any other exception is thrown.
   */
  def apply[T](f: () ⇒ T): Flow[T]
```

Which generates an `Actor` backed producer for you (that will call your 
function), or if you need complete control you can implement a `Producer[T]` 
and give it to `Flow`:

```
/**
   * Construct a transformation of the given producer. The transformation steps
   * are executed by a series of [[org.reactivestreams.api.Processor]] instances
   * that mediate the flow of elements downstream and the propagation of
   * back-pressure upstream.
   */
  def apply[T](producer: Producer[T]): Flow[T]
```

These should be enough to implement what you’re after.

Disclaimer
Please note that the spec ( 
https://github.com/reactive-streams/reactive-streams ) is under heavy 
discussions and development at this moment.
Our current impl is still targeting the previous version, differences include 
for example dropping the Producer interface in favour of only keeping 
`Publisher` etc.
Also known as: This is still is changing a lot :-)



- another thing is if the streams are thought to be more local, or remote as 
well? There's currently the TCP stream implementation, which I guess would 
indicate remote as well (and in such scenarios the need for backpressure arises 
quite naturally, maybe even more than in locally), but do you plan to develop 
this somehow? E.g. when there would be multiple consumers for a single 
producer, a useful component would be a load-balancer which takes into account 
the backpressure information. 

We’re currently focused on in-jvm implementations, though 
multi-language-and-runtime are definitely on the reactive-streams’ radar: 
https://github.com/reactive-streams/reactive-streams/issues/45
Let’s first nail the in-vm implementation to then move on to the bigger picture 
(personal opinion here), but there’s so many people involved and loads of 
excitement around it, so we’ll see ;-)
As for Akka, we’re currently mostly focused on getting akka-http (which will be 
stream based) out of the door, and optimise it, the rest comes next.


I hope this helps!
// So... what Producer are you implementing? :-)



-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

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

[Konrad 'ktoso' Malawski]

Hello Lawrence!
No additional callback is provided, but there is a nice pattern that 
effectively provides the same functionality:

Please check the section of the docs about recovery status: 
http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html#recovery-status
If you’d keep the “last msg” around, and then you get your “FIRST” msg, you 
know recovery has finished and you can run your logic.

I hope this helps, happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

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

[Konrad 'ktoso' Malawski]

Hello Oskar, 
based on the two key datapoints from your email: FSM testing + at 
akka.testkit.CallingThreadDispatcher.dispatch(CallingThreadDispatcher.scala:208)
I deduce that you are using TestActorRef (well you’re probably using TestFSMRef 
as suggested by the FSM docs, which also IS-A TestActorRef), which is cool for 
testing one actor in isolation, yet it won’t work nicely when you test 
interaction between actors, because it’s using the CallingThreadDispatcher. 
These abstractions allow to very easily test “one actor”, yet at the trade of 
of effectively being single threaded (sic!), which is why you’re running into 
deadlocks. 

So while these patterns and classes are good for synchronous testing, they 
won’t play well if you have any kind of bigger interaction going on between 
actors. Please use the plain TestKit instead, like explained in the 
“Asynchronous Integration Testing with TestKit section of the docs.



I hope this helps, happy hakking!



-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

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

[Konrad 'ktoso' Malawski]

Glad I could help! Happy hakking!
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

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

[Konrad 'ktoso' Malawski]

Uhm, I don’t think it ever had streams in it, hm! :-)
The streams are in active development and are located in the release-2.3-dev 
branch.
Slightly hidden we know, on the other hand, it’s very aggressively changing, so 
that may be a good thing…

Anyhow, you’re free to give it a spin! Feedback is also very welcome.
Happy hakking!


-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

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

[Konrad 'ktoso' Malawski]

No worries, https://github.com/akka/akka/tree/release-2.3-dev/akka-stream
Happy hakking :-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

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

[Konrad 'ktoso' Malawski]

Yes it does remove dead actors.

In 2.3.x this is implemented using the now deprecated `isTerminated` calls on 
the actor refs (impl is in ActorClassification).

And in 2.4.x (not yet released, but the feature is implemented already) the 
clean up happens via DeathWatch (so we’re able to avoid calling `isTerminated` 
all the time). The change required making the bus require an ActorSystem - 
which should not be a problem, since you’re most of the time implementing actor 
based apps anyway with these - migration guide here.

Happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello Peter,
nope, while the new event-bus is not itself an actor, is uses an actor to 
handle subscription / unsubscription / death in an asynchronous way.
It’s an interesting thought, but we have not done enough benchmarking (yet), to 
know if it’s a viable option.

The primary driver for this change was to get rid of the deprecated 
`isTerminated` use.
I have created a reminder ticket to investigate optimising the buses deeper: 
https://github.com/akka/akka/issues/15415 (this was part of a larger issue, but 
deserves a task of it’s own I guess).

Thanks for the interest and please feel free to share usage patterns!
On 20 June 2014 at 19:45:47, Peter Lappo (peter.la...@gmail.com) wrote:

Interesting. Does that mean the EventBus is an actor in 2.4.x and easier to 
extend?

On Friday, 20 June 2014 17:59:09 UTC+1, Konrad Malawski wrote:
Yes it does remove dead actors.

In 2.3.x this is implemented using the now deprecated `isTerminated` calls on 
the actor refs (impl is in ActorClassification).

And in 2.4.x (not yet released, but the feature is implemented already) the 
clean up happens via DeathWatch (so we’re able to avoid calling `isTerminated` 
all the time). The change required making the bus require an ActorSystem - 
which should not be a problem, since you’re most of the time implementing actor 
based apps anyway with these - migration guide here.

Happy hakking!

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

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

[Konrad 'ktoso' Malawski]

Hello Hannes,
Well noticed - we have not yet ported this functionality over to the 
PersistentActor (in `2.3.4`).

Progress on this task can be tracked here: 
https://github.com/akka/akka/issues/15279
I hope you can wait a bit for it, but we definitely would like to provide this 
(I like FSM a lot myself).
-- 

Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello Wolfgang,
thanks for reporting your findings!

Yes, the 1st thing you mention is indeed a typo and has been fixed in this PR: 
https://github.com/akka/akka/pull/15486

The 2nd thing, snapshots, should indeed be updated, I’ve created an issue and 
marked it as community-contrib: https://github.com/akka/akka/issues/15508
If you’re free or someone would like to help us out time-wise, we would very 
much welcome a pull request to fix this :-)

Thanks again for reporting, happy hakking!

-- 

Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

It of course “depends”, but I would advocate for “1 aggregate (as in DDD) == 1 
actor”.

Because it fits so nicely:
* An aggregate (an user for example) is a domain boundary
* An actor naturally enforces this even more so, because it is an asynchronous 
boundary

A lot of aggregates is *not* a problem in this thinking because:
* Let’s assume you have  users in your system.
* Not all users are using the system all the time = you can kill actors that 
represent users that have not been active since an hour etc.
* Thus, the number of actually running actors will be lower. 
* If this user comes back, you simply start the actor, it does the replay (or 
from snapshot, that you did before killing it) and is ready to rock and roll.

That’s the general idea.
And I think the design becomes very clear if you keep the 1:1 mapping.

I hope this helps!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

That’s currently not supported.
Streams are a very fresh module, and we’re still working to get the in-jvm 
semantics and APIs *right* before we go distributed.


-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

As Endre already highlighted, we have a different focus than the 
specialised-for-big-data frameworks.

Our focus is to get the back-pressure semantics and common API among library 
implementors right (the reactive streams API).
There’s a lot of discussions around these still happening at 
https://github.com/reactive-streams/reactive-streams if you’re interested.
The spec is still evolving actively.

APIs will continue to be improved of course and we are well aware of 
Spark/Storm/Scalding (with the last one I’ve spent a lot of time ;-)).

If you think we’re missing any fundamental combinators please check if they’re 
already in our todo’s or open a ticket: 
https://github.com/akka/akka/issues?labels=t%3Astreampage=1state=open

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Thanks for reporting Wolfgang!
We’ll look into this.

On 14 July 2014 at 12:47:42, Wolfgang F. (wolfgang.fri...@hotmail.com) wrote:

I added the issue https://github.com/akka/akka/issues/15535


Am Montag, 14. Juli 2014 11:24:28 UTC+2 schrieb Konrad Malawski:
Thanks for reporting, Wolfgang!
Looks like a bug indeed, would you mind creating an issue with these details on 
our issue tracker?

https://github.com/akka/akka/issues?labels=t%3Astreamstate=open


On Mon, Jul 14, 2014 at 10:37 AM, Wolfgang F. wolfgan...@hotmail.com wrote:
Hi

I found a small bug in the implementation of the ActorProducer.

I created an Actor (which has the ActorProducer implemented)
I did not use the actor (I just created it)
When now the system is shutdown the following exception occurs

Exception:

java.lang.NullPointerException: null
    at 
akka.stream.actor.ActorProducer$class.aroundPostStop(ActorProducer.scala:237) 
~[akka-stream-experimental_2.10-0.3.jar:na]
    at 
com.jd.hddoc.dispatcher.com.api.ConsumerProducerActor.aroundPostStop(ConsumerProducerActor.scala:7)
 ~[classes/:na]
    at 
akka.actor.dungeon.FaultHandling$class.akka$actor$dungeon$FaultHandling$$finishTerminate(FaultHandling.scala:210)
 ~[akka-actor_2.10-2.3.3.jar:na]

It caused because the state isActive returns true but subscribes is 
uninitialized

Sample:

class ProducerActor() extends  ActorProducer[Int] {...}

    ...
   val system = ActorSystem(serverSystem, serverConf)
   val sourceAndDestination = system.actorOf(Props[ProducerActor])
   system.shutdown()
    ...

Regards

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



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

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

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

[Konrad 'ktoso' Malawski]

Hello Asterios,
It’s not a very good idea to use actor messaging to send such huge messages 
using akka’s remote messaging.
Reason being - you’ll delay other messages until the huge one has been pumped 
through the network.

Actor messages should ideally be in kilobyte ranges.

1) In your case I would store these files in a distributed filesystem (do you 
have HDFS in your cluster for example?) that is optimised to deal with such 
data (because akka-actor is optimised for fast small message transfer, not huge 
files) and send the location to the receiver, so it can decide to pull the work 
(the data) when it’s ready to do so. 

Wins: You don’t clog the actor system; The receiver is free to pull the data 
when it’s ready; and you use an optimised storage system for this kind of data.

2) If you want to stick to actor messages, you could chunk up the data so you 
don’t clog the connection. See: http://www.eaipatterns.com/MessageSequence.html

3) One other approach would be to use akka-io to deal with the file transfer. 
The receiving end would need more work here.


-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Yes it will degrade, because you’ll clog the connection between system `A` and 
`B` while pumping through LargeMessage,
and the other waiting SmallMessages won’t get through while the large one is 
being written.

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Thanks a lot, I’ll have a look at it today :-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello again,
yeah, it would be a different stream, so you loose any ordering guarantees.

But how about spinning up an Actor, that will serve as an adapter for your “non 
actors” to talk with the event stream?
That would be the cleanest I believe. You could even make it a typed actor ( 
http://doc.akka.io/docs/akka/2.3.4/scala/typed-actors.html ),
so the non-actors won’t even know that they’re talking with an actor.

How does that sound? :-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Yes, I agree this should be mentioned explicitly - I have created this issue to 
track this: https://github.com/akka/akka/issues/15569

By the way, we are thinking of offering a TestKit for akka-persistence.
I think it would be a neat addition (would make prepping journal state before 
your tests easier) but we have not discussed it in detail yet, let me know if 
you have a wish list for that kind of utility so we’ll keep them in mind :-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

If I've got a persistence store using one particular persistence plugin and I 
want to change to another, what would I have to do?
I can see I could run a utility program that opened the old store and sent the 
messages to another processor to persist them, but can I run with 2 different 
plugins at the same time?
Currently you cannot have 2 journals in 1 actor system. You’d have to run 2 
actor systems (can be the same jvm) and configure them differently.

We are prepared in the current sources to extend this, so each actor could get 
it’s own journal implementation (grep for `journalFor` if curious), so we’ll 
get to it at some point :-)

I noticed we don’t have a ticket for it currently, would you mind opening one? 
https://github.com/akka/akka/issues?direction=desclabels=t%3Apersistencepage=1sort=updatedstate=open

Thanks in advance!



 And what if I want to serialise differently in the second store?
In the above example you have 2 systems, so it’s easy.

Currently serialisation is configured per actor system too, so this is an open 
question for a time when we implement multiple journals in one actor system - 
only then this problem will appear.


Thanks for the feedback!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

I had a reply prepped yesterday but lost the draft (argh offline editing!).
Back to the topic though:

First of all, thank you very much for the elaborate reply. I guess I'll 
get hacking away at some prototypes soon and so some performance testing close 
to our use-case. Looking forward to it, too :-)

Great to hear, let us know about your findings please :-)


So what you suggest is that the serializer first deserializes a stored event 
forgivingly, without throwing an exception for for example dropping removed 
field and initializing new fields with 0/null/default values, and then I 
compare the version and apply additional conversion logic? Or do you mean 
something more complex like storing a dehydrated version of the event and 
re-hydrating it every time an event is loaded from storage, promoting it to the 
latest version in this process?

This very much depends on what serialiser you use, because they inherently 
support some kind of schema evolution.

I’ve been mostly using protocol buffers in my career. There, what you do is: 
mostly use optional fields so these can be null, and you have to be prepped for 
this anyway.
And then you can reserve some space for extensions, using that you’re able to 
apply this trick: http://www.indelible.org/ink/protobuf-polymorphism/
Because of how proto works, renames are safe for example - because it’s not 
using the name in the binary format, but the ID. etc etc… 
This should give you a feel how “bound” your evolution strategies will become 
to the serialisation format.

Other basic tips are nicely summarised here: 
http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
Again though, dig deeper into the details of each serialisation format before 
you decide to go for it (we don’t really have a “use that one” opinion on this).

Other serialisation formats, such as Simple Binary Encoding (designed to be low 
latency envs - check benchmarks) support this via keeping version numbers in 
the message header:
https://github.com/real-logic/simple-binary-encoding/wiki/Message-Versioning
In essence - version number = some number of extension fields, you cannot 
delete fields in this one.

One other format I’d like to point to here is Cap n’ Proto (same author as 
original protobufs AFAIK), and their description on this (as it’s listing it up 
quite nicely what is safe and what is not):
http://kentonv.github.io/capnproto/language.html#evolving_your_protocol


Summing up… These strategies allow you to change your events and stay 
compatible with the same type - to still be able to deserialise.
If you however at some point make some huge change, and need to get events B 
but you have events A serialised, or you need to add additional data you can 
add another layer 
that would promote A events to B events, and then emit them to the actor. This 
gets more complicated, but the point is - you’re not doomed even if you have to 
do bigger changes (try to avoid this ofc ;-)).

I know I’ve just grown your to-read list by quite a bit, but I hope this helps! 
:-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Nope.

Please ask the ebean guys about helping out with this one - I had no idea what 
ebean is until this email :-)
Have a great weekend!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello there,
Ah, much better when able to communicate in full sentences without 140 chars 
limit! ;-)
( https://twitter.com/mrt1nz/status/492676432410447872 ) 

So, now that it’s spelled out as full sentences, I’ll gladly dig into your 
points:

1) 
Has been already proposed and accepted in 
https://github.com/akka/akka/issues/15004,
including your +1, so I guess you’re aware that it’s in our backlog.

The module is experimental and published “early” exactly in order to gather,
and implement these features before stabilising the APIs.

So it’s coming, we simply have not yet gotten to implementing it - it’s holiday 
season, which isn’t helping development speed :-)

2) 
For the benefit of the discussion, example in EventStore: 
http://geteventstore.com/blog/20130707/catch-up-subscriptions-with-the-event-store/

One thing to keep in mind here is that some Journals would have no problem 
implementing this, such as Kafka or EventStore - because it’s a built in 
mechanism to “subscribe to something” in them… See Martin’s Kafka journal and 
how one can subscribe to a event stream there: 
https://github.com/krasserm/akka-persistence-kafka#journal-topics On the other 
hand implementing this in other Journals would be pretty painful / inefficient 
(cassandra, hbase, …).

We were playing around with some ideas to expose optional db specific journal 
functionalities. This would be a good candidate for this.

This request seems to depend on these things by the way: 
* changes in the journal plugins (we some changes there anyway 
https://github.com/krasserm/akka-persistence-kafka#journal-topics ),
* views over “tags (as this would essentially be a view over “all”),
* and lastly reactive-streams (views exposed as streams of events).


Thanks for your feedback and keep in mind that no-one said that this module is 
“done”.
It’s still experimental and this kind of feature requests are exacly what we 
need and will have to provide to make it stable and usable in all kinds of apps.

Lastly, would you mind creating a ticket for the 2) feature?
Thanks in advance, have a nice weekend :-)

-- 

Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello Greg,
This question is basically the same as last week: 
https://groups.google.com/forum/#!topicsearchin/akka-user/combining$20Akka$20Persistence$20with$20Akka$20Scheduling/akka-user/CLRF6LP2G18

Suggestions have not changed since then :-)
Try akka-quartz-scheduler or write a large scheduling system on your own.
Not liking quartz shouldn’t really be the reason of avoiding a library that 
solves the problem you need to be solved… :-)

—  k
On 28 July 2014 at 04:05:55, Greg Flanagan (ventis...@gmail.com) wrote:

I'm building a reporting backend where users can schedule a report to be run 
weeks / months in advanced. I've used Quartz in the past for this kind of 
things but my use case isn't that complex and I think I can get away with just 
using the akka scheduler (plus I just don't like Quartz and would like to avoid 
the dependency if I can). My only requirement is that the user gives me a date 
time instant that they want the report to run, so I can easily figure out the 
delay to give the akka scheduler in seconds. Also I don't need need any 
guarantees about the report running at exactly the correct instant, it could be 
off by even an hour and I would be fine. My concerns are if the akka scheduler 
can even handle scheduling something this far in advanced, I imagine that it 
has a hard limit on whatever the max integer is. Also, I'm not sure what the 
best approach would be to handle jvm restarts or crashes. In this case I would 
need to have some sort of persistence so that the scheduler could be restarted. 
Is this something that akka persistence could help me with or have to roll 
something myself?

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

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

[Konrad 'ktoso' Malawski]

That’s another nice to have improvement, please create an issue Rohit.
Currently you would have to implement this on your own.

— k

On 26 July 2014 at 19:41:10, ahjohannessen (ahjohannes...@gmail.com) wrote:

I think it would be useful to have a setting a la keep-at-most-nr-snapshots. 
I believe that is beneficial for all users, you should create an issue at 
github :)

On Saturday, July 26, 2014 9:08:39 AM UTC+1, Rohit Kumar Gupta wrote:
Hello,

I am using akka persistence (akka 2.3.4  play 2.3.1) in my akka based 
ProductCluster. I am taking snapshot every 10 secs in the master process. What 
I notice is that, the snapshot folder keep growing and becomes huge. As I 
understand that once I take a snapshot I don't need the older snapshots (except 
for later debugging/postmortem). How can I configure akka to do this 
automatically. I know that PersistentActor has api deleteMessages that takes a 
selection criteria.

Any pointers will be helpful.

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

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

[Konrad 'ktoso' Malawski]

Please open an issue on our github issue tracker, 
https://github.com/akka/akka/issues
Thanks a lot!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi everyone,
thanks for your feedback and ideas.

So the stream / view on multiple persistentIds (or “tags” - would solve Greg’s 
example case) is coming, we just have not yet have had the time to work on it.
One thing that ties in into them is reactive streams. We would like to expose 
these event streams as akka streams.
Esp. since they provide they provide things like merge / filter / tee which I 
believe would help a lot in these kinds of event streams :-)

From the streams point of view abstracting if it’s polling or DB-side 
initiated events the APIs won’t have to change.
I do agree / like Martin’s suggestion that in “normal dbs” (no events when 
someone does an insert) we should be able to implement this with some 
housekeeping done by the plugins.

One question about EventStore, in the case of reading from multiple replication 
groups is the ordering based simply on write-timestramp not-descending order?
The timestamp is obviously skewed a bit (multiple servers/clocks do writes) but 
in the apps you work with would this be ok as source of ordering in case of the 
“all events” stream?


PS: Most of the team is on holiday this week, it’s reasonable to expect they’ll 
chime in some time next week.
-- 

Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

- a total order per persistenceId based on sequence numbers (= partial ordering 
in the all events stream) is a must have IMO.
- ordering based on timestamps should be an application level concern (= 
timestamps in application-defined events and (re-)ordering done by application)
Agreed, seqNrs are at our core and we’ll stick to them (partial ordering will 
be in for sure, was thinking if more was needed by app implementors). Bringing 
in timestamps “in some case” would be inconsistent with the rest of persistence 
anyway, so pushing it into user land sounds good. 

Actually, since we want to expose this as reactive streams the timestamp 
ordering could be expressed as `merge(streams, userLandProvidedOrdering)` (we 
don’t have this yet)… Tempting idea, looking forward to trying out different 
things there.


- mid/long-term goal: causal ordering (allows moving from eventual consistency 
to causal consistency). See also Don't Settle For Eventual Consistency.
Thanks! Have not read that one yet - looks very interesting. 
Will catch up with it today :-)

— k

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

[Konrad 'ktoso' Malawski]

Hi George!
I’ll start with the infameous “it depends”, but let’s get into a more 
constructive answer :-)

As updateState is not really something akka forces you to do - it’s simply a 
pattern we’ve found to be useful.
The core of it is “a method which you can call from both `receiveCommand` and 
`receiveRecover`”.
I’d split methods in terms of “does interactions with outside world and should 
not be triggered on recovery” and “does not trigger interactions with outside 
world”.
But for example if you create child actors as part of your domain logic, you 
will want to trigger this during replay - to be ready for an incoming request 
which needs them etc.

I for one would not put much logic into events. I tend to keep them as simple 
as markers that “stuff happened” - when actions need to be made, I’d use actors 
to do them. Putting a require() or two in there may be ok, but I wouldn’t put 
more complicated stuff into an event - it’s some actor that would “perform” the 
work.

As for commenting Martin’s quote, by Command he means “incoming message” (as 
does our PersistentActor#receiveCommand), and by Event he means “the event that 
the Persistent Actor has persisted, as effect of that incoming command”. This 
means: command comes in, apply some logic to it, store “result” of that logic 
as event (SignedUp / UserNameTaken etc.), and act upon this event (once it’s 
persisted safely). So the logic leads to storing of events.

I hope this helps, feel free to ask more or give examples of what you’d need :-)

Happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Yup, exactly :-)

Happy hakking!

On 3 August 2014 at 20:34:29, Soumya Simanta (soumya.sima...@gmail.com) wrote:

Thanks Konard. I'll stick with 2.3.4 for now and upgrade once I have more 
experience and need in the future. 

On Sunday, August 3, 2014 12:06:34 PM UTC-4, Konrad Malawski wrote:
Hello Soumya,
If you’re just getting started, stick to the released versions - such as 2.3.4 
:-)

Also, persistence is developed and updated as part of the 2.3 release cycle, 
new features will be available within 2.3 - no need to rush to 2.4 just yet :-)



While we do publish (timestamped) snapshots to repo.akka.io I don’t see why you 
would need to use it unless specifically testing against some fix introduced in 
HEAD.

The cassandra plugin (and anyone who implemented the 2.3.4 API) is binary 
compatible with 2.3.4 and source compatible with 2.3.x.
This is only because persistence is an experimental module, and under active 
development (and adjustments based on community feedback),
normally we do guarantee 2.3.x modules to be binary compatible within 2.3, but 
not with 2.4.

​


On Sun, Aug 3, 2014 at 2:18 PM, Soumya Simanta soumya@gmail.com wrote:
I want to get started with Akka persistence. 

Do I need to upgrade to akka 2.4 to be able to use the latest Akka persistence 


com.typesafe.akka %% akka-persistence-experimental % 2.4-SNAPSHOT


OR will it work with akka 2.3.x as well ? 

Also, I want to use a Cassandra journal using 
https://github.com/krasserm/akka-persistence-cassandra

The build.sbt uses akk-persistence-experimental 2.3.4
  com.typesafe.akka %% akka-persistence-experimental % 2.3.4,


Does this mean that the Cassandra driver won't work with the latest version of 
akka-persistence ?




Thanks
-Soumya

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



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

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

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

[Konrad 'ktoso' Malawski]

Within the JVM it’s dead easy to integrate between languages… :-) Random fact: 
I’ve actually used Scala code from JRuby on Rails some years ago. An outline on 
how to do this is on my blog: 
http://www.blog.project13.pl/index.php/fun/1497/teaching-jruby-talk-with-scala-on-rails/
 And as you can see, it’s pretty easy, not sure if feasible nowadays though as 
Play is getting pretty good in the developer productivity area :-) (We did 
not end up using JRuby/Scala on Rails in the project I was working on (and went 
full Scala), by the way, but it was an interesting though short experiment).

Coming back to the questions though… in order for this to happen to (open up 
the cluster for “any language” client), 
we’ll need to re-think (?), stabilise, document and publish our remoting 
protocol, as well as (probably) change our serialisation format used. 
Such protocol would be accessible from any language – producing the bytes is 
the the one of the smaller problems actually, once we’d set on a serialisation 
format.
There have been some rough ideas, but are currently focusing on tasks at hand 
(persistence, streams, akka-http etc).

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

 wrote:
Hi Lawrence,
In general, exactly one entity in a distributed system should be responsible 
for deciding about success / failure,
otherwise there always will be a race of some kind.

In your case though, the problem arrises because the service actor does not 
know if the transaction actor has completed the work,
so how about sending the response back through the transaction actor?

Also, in your case, can the transaction actor fail after sending it's response 
to the client actor, how would that happen (with a NonFatal exception)?
I'd expect it to do `client ! stuff; context stop self`, is that not the case?



On Thu, Aug 7, 2014 at 8:59 AM, Lawrence Wagerfield 
lawr...@dmz.wagerfield.com wrote:
I have problem that involves synchronising outbound messages from a parent 
actor and its child actor. This particular problem is with regards to 
forwarding failure messages to clients. 

Here is the example: 

I have a service actor that receives a request from a client actor.

The service actor creates a new child transaction actor to deal with said 
request, which then response directly to the client actor after performing the 
work.

If the transaction actor fails, it is stopped by the service actor which then 
sends a failure report to the client actor.

The problem is the client actor must now support receiving failures after 
receiving the response it is actually interested in - otherwise the potential 
'post-workload' failures from the transaction actor may deadletter, or worse, 
be misinterpreted by the client actor (i.e. a failure for a subsequent 
transaction).

I have considered an approach whereby the client actor must wait for the 
transaction actor to terminate before safely continuing, since after that 
point, it can be guaranteed that no more messages will be received.

Is there a common solution to this problem?

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



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

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



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

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



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

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

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

Re: [akka-user] akka-persistence (2.3.4) and serialization

[Konrad 'ktoso' Malawski]

Hi Michael,
yes, the TCK is not published yet – it will be as part of the 2.3.5 release.
If you would like to use it before that you can publishLocal from the 
akka-persistence-tck-experimental project from the release-2.3 branch.

Good luck with your plugin!

On 11 August 2014 at 08:29:22, Michael Reardon (reard...@gmail.com) wrote:

I looks like the TCK has not made it up to Maven-land yet, or is that just me? 
I'm been looking here: http://central.maven.org/maven2/com/typesafe/akka/ 

Incidentally, I've starting cobbling together a persistence plugin for CouchDB, 
so I too will be sorting out handling json with Akka Serializer. I've not 
noticed anyone using CouchDB with Akka Persistence yet, but if someone else has 
I'd love to hear about it.

Thanks,
Mike Reardon

On Tuesday, August 5, 2014 3:54:56 AM UTC-7, Konrad Malawski wrote:
By the way, implementing storage plugins is not so hard :-)
Take a look at the docs: 
http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#storage-plugins
(I'm linking to snapshot here because in in 2.3.5 (coming soon) persistence 
includes an persistence plugin TCK – so you can verify if your plugin really 
works with this out of the box set of tests :-))


On Tue, Aug 5, 2014 at 12:51 PM, Konrad Malawski kt...@typesafe.com wrote:
Hi Yann,
since we provide user implementable Journal APIs to which we send 
PersistentRepr we (as in Akka) don't really have control over the format of how 
a journal plugin will decide to store this data.
This is by design, since we want to be de-coupled from any database specifics 
in the APIs. In HBase I store a whole lot of data in the row key, an SQL 
journal would probably utilise separate columns for the persistenceId and the 
sequenceNr etc.

It is up to the journal plugin to decide how the data will be fit into the 
database (if you're mongo, just slap a json document into the collection and 
it'll work fine – etc) – which is why my answer here is to implement a Journal 
plugin that would store the data in a way you see fit – just setting the 
serialiser won't be enough since the plugin may still do wrapping, and we can't 
force people to not do so, since perhaps it's exactly what they need.
If your case is strong enough to really need full human readability, writing a 
small plugin shouldn't be to big of a price to pay :-)

Related question: which database are you targeting?

I hope you see my point and this helps in the long run!

--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

  



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

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

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

[Konrad 'ktoso' Malawski]

-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) 
~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:70)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) 
~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) 
~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) 
~[netty-3.9.0.Final.jar:na]
        at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) 
~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
 ~[netty-3.9.0.Final.jar:na]
        at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) 
~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
 ~[netty-3.9.0.Final.jar:na]
        at 
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
 ~[netty-3.9.0.Final.jar:na]
        at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
~[na:1.7.0_51]
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
~[na:1.7.0_51]
 
--
 Read the docs: http://akka.io/docs/
 Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello there,
as Patrik redirected – we’ve talked a lot about this and are aiming to provide 
better views.

There already exists integration with Kafka 
https://github.com/krasserm/akka-persistence-kafka#journal-topics developed by 
Martin Krasser,
it adresses some of the points raised actually.

Similarily there already exists an EventStore akka-persistence plugin: 
https://github.com/EventStore/EventStore.Akka.Persistence.
The big thing is that we would like to update the plugin API to such that would 
allow plugins to “do more” on the read side of things (Patrik linked to the 
“improved Views” proposal already).

Thanks for the interest and ideas!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi guys,
Have you seen the http://www.scala-sbt.org/sbt-native-packager/index.html sbt 
plugin?
The sbt guys are pouring loads of effort into making apps easily packagable 
using that plugin.
So instead of having a custom akka plugin we’d rather recommend that one.

I created an issue for linking to the native packager in the docs 
https://github.com/akka/akka/issues/15677

Cheers!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi Barak,
It’s currently not possible to use FSM with PersistentActors.
We do want to provide this before persistence goes stable, here’s the ticket 
for tracking it: https://github.com/akka/akka/issues/15279

I was already playing around with implementing it, but sadly it requires a bit 
more work.


-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

It’s a naming thingy.

PersistentView is our concrete implementation of something that reads events 
given a persistenceId”.
Current discussions involve making PersistentView more usable and powerful, as 
the current impl does not cover many use cases.

Projections in general are simply “the read side”. Could be a persistent view, 
or anything else that given some events projects the data onto some other value 
like the average for example (think “projection” as in maths).

Read up on DDD concepts, it should help you follow these discussions:
* 
http://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_2?ie=UTF8qid=1408523383sr=8-2keywords=ddd
* 
http://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=sr_1_1?ie=UTF8qid=1408523383sr=8-1keywords=ddd
* http://msdn.microsoft.com/en-us/library/jj554200.aspx

Cheers.

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Have anything changed in this matter?

https://spark.apache.org/

Happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi Dave,
we certainly want to provide a proper stream-testkit once streams “go stable”, 
here’s a ticket for it: https://github.com/akka/akka/issues/15748
Currently we are reworking the API parts of akka-streams, so the testkit won’t 
be shipped in the next minor, but it’s sure to come at some point.

Feel free to add comments and use cases to that issue, we welcome feedback and 
ideas!


-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Glad you were able to figure it out. 
Indeed tweaking the dispatchers is very often the way in such situations, the 
exact settings are very dependent on the actual workloads ofc.

Happy hakking! 

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

It would be easier to perform this using log analysis. 
[Prakhyat] Yes. We have this in mind as one of the alternative. But it 
wont provide performance metrics.

I don’t agree.
You would get SOME performance metrics this way – the time from start of 
request to various stages of your processing pipeline.
You can graph and analyse this. Relate these numbers with the load generated 
during a concrete test run etc. You can also see how it relates to your “200” 
response times etc etc.

There certainly is value and data to be gained from such benchmarks.
As always, to perform a proper benchmark you need to put some effort into it.

Hope this point of view helps.

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

I get where you're coming from. People may rely on test with TestActor 
ref and not do the proper actor specs. Those IT specs are mandatory.

Exactly, you’ve defined it way better than I did by going into the nitty-gritty 
details actually :-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

In general there should be no difference, like I mentioned a few times already.
If you’re really really worried about any performance – you cannot just assume 
things and will have to measure, anything you “care enough” about.

— konrad

On 13 September 2014 at 19:28:32, Prakhyat (prakhyat...@gmail.com) wrote:

Konrad,

Thanks again. Will keep this in mind.

From benchmarking, did you mean, micro benchmarking using caliper or jmh?

Or benchmarking runtime performance of overall poc code? If yes, then same poc 
has to be implemented separately  in both scala and java, followed by 
performance tests on each implementation. That's the only way as I fathom.

-prakhyat m m

Sent from my iPhone

On 13-Sep-2014, at 22:44, Konrad Malawski kt...@typesafe.com wrote:

Language choice should have marginal (collection conversions will happen for 
example) has marginal impact on performance here.

If you really care you should benchmark things :-)

--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe


--
 Read the docs: http://akka.io/docs/
 Check the FAQ: 
 http://doc.akka.io/docs/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/1k3JedN0p7w/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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello Andrew,
you might find “the Reaper” pattern of interest to you: 
http://letitcrash.com/post/30165507578/shutdown-patterns-in-akka-2

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi Jens,
No, this is currently not possible. You can only have one journal per actor 
system,
so currently you’d have to have multiple actor systems (or maybe other 
nodes=acorsystems handling other types of writes).

In theory we have prepared a hook for this and could eventually work on it, but 
it’s not within the short term plans for now: 
https://github.com/akka/akka/issues/15587


-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi John,
We want to use sharding and Akka persistence.
So far we have only used an in memory implementation for Akka 
persistence but now want to implement a proper storage solution.
Glad to hear that!

We have noticed that Akka is persisting the the shard co-ordinators in 
addition to our persistent actors.
Do you know why it needs to do this ?
It’s because the node on which the shard coordinator is running might die and 
then it must be able to be reconstructed at some different node.
The state that is required for this is persisted using akka-persistence.

Are there other Akka internal classes that use Akka persistence as well 
?
No, it’s just the ClusterSingleton and ClusterSharding (in akka-contrib), which 
we’ll want to promote out of contrib soon.

Hope this helps, 
Happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi Dan!
Event sourcing systems like to think in terms of never delete anything”. It’s 
basically auditing for free as well as the power to replay and analyse 
the entire history of your application.

In such systems snapshots are only used ot make recovery faster - not to drop 
the proceeding data,
which is why we don’t automatically delete preceding events when a snapshot 
succeeds. 
You can delete them by reacting to a snapshot succcess by issuing an 
deleteMessages(toSequenceNr = lastseqnr).

Hope this helps!

— Konrad

On 30 October 2014 at 09:23:44, Dan Ellis (d...@danellis.me) wrote:

Does a journal continue to grow in size forever, even if you're using 
snapshots? Presumably, once a snapshot is stored, the events preceding it are 
no longer needed. Are they kept? If so, is it possible to purge 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 http://groups.google.com/group/akka-user.  
For more options, visit https://groups.google.com/d/optout.  
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hello there,
Have you read this section of the docs? 
http://doc.akka.io/docs/akka/2.3.6/java/untyped-actors.html#creating-actors-with-props
context is a method available to Actors, it starts “child actors”, and not “top 
level actors” (it’s cheaper - do this).

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Viktor +1,
and search.maven.org also helps on htat frmot 
http://search.maven.org/#artifactdetails%7Ccom.typesafe.akka%7Cakka-actor_2.11%7C2.3.6%7Cjar

Happy hakking!

— ktoso
On 7 November 2014 at 23:41:08, √iktor Ҡlang (viktor.kl...@gmail.com) wrote:

Hi Hannes,

The docs are fantastic: 
http://doc.akka.io/docs/akka/2.3.6/intro/getting-started.html

:-)

On Fri, Nov 7, 2014 at 11:38 PM, Hannes dub...@gmail.com wrote:
Is there any way to add Akka as Gradle dependency to a project?
--
 Read the docs: http://akka.io/docs/
 Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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.



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

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

[Konrad 'ktoso' Malawski]

You’ll have to block then.
Consider using Actors instead if you can.

— k 

On 17 November 2014 at 13:51:29, Syd Gillani (s.zeeshangill...@gmail.com) wrote:

Alright, but I would like to send the result to an API ( a method in an 
external class). Is there any way for it. Cheers


Syd


On Monday, 17 November 2014 12:35:42 UTC+1, Konrad Malawski wrote:
Have you looked into our pipeTo pattern? It allows to send the result of a 
Future to an Actor, without having to block on the result:


import static akka.pattern.Patterns.pipe;

 
final ActorRef alice = ???;
final FutureObject future = ???;

pipe(future, ec).to(alice);

Alice can receive the value and do things with it.
More info in the docs: 
http://doc.akka.io/docs/akka/2.3.7/java/untyped-actors.html#Ask__Send-And-Receive-Future

-- k 

On Mon, Nov 17, 2014 at 12:22 PM, Syd Gillani s.zeesha...@gmail.com wrote:
Thanks Konrad,
The issue with the mapping is that I won't be able to send the results to an 
external class -- that is exactly my case. I need to send the result of the 
future to an external class which will perform some other computation and so. 
I knew about the await method, but as It is described in the documentation (not 
a preferred approach  ), so I was hesitant to use it. Cheers

Syd




On Monday, 17 November 2014 12:10:16 UTC+1, Konrad Malawski wrote:
Hi Syd,
your code samples are not valid Java (well, the first one could be if testVar 
would be a field, but that's unsafe instead maybe use `AtomicReference` and 
`set` it from the completion?).
OnComplete has a `void` method so you cannot return from it.

Instead of taking things out of the future like this you can either:
1) keep mapping (transfroming the value):


future.map(new Function1Object, Object(){
  @Override public Object apply(Object v1) {
return null;
  }
}, ec);
never getting out of this transformation - this way you can chain all 
transformations you need.

2) Await on the result of the future (we discourage this) as it will block the 
thread that you're calling await from:


FutureObject future = null;
Object o = scala.concurrent.Await.result(future, Duration.apply(100, 
TimeUnit.DAYS))

Hope this helps, happy hakkionmg!

On Mon, Nov 17, 2014 at 11:36 AM, Syd Gillani s.zeesha...@gmail.com wrote:
Hi,

I wanted to ask if there is any way to map the internal variables to the 
external java ones. For instance, for the following method

String testVar=null;


future.onComplete(new OnCompleteObject(){
        public void onComplete(Throwable t, Object result){
     
         testVar=(String) result;
      
        }
    }, ec);


I have tried the following method to get the results by calling onSuccess

future.onComplete(new OnCompleteObject(){
        public void onComplete(Throwable t, Object result){
     
       return result;
      
        }
    }, ec);


future.onSuccess(new ResultString(), ec);


However I am kept on getting the error (cannot cast the Result class to a 
partial function ).  Cheers



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



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe


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



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe


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

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

Re: [akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[Konrad 'ktoso' Malawski]

Hi Maxim,
We fixed a very similar bug in akka-streams 0.11, but it does not seem that’s 
the exact place that your stacktrace is coming from…
Here’s the issue we fixed in 0.11 = https://github.com/akka/akka/issues/16263

Would you mind giving more background on what you’ve been using and when this 
appeared?
Are you using akka streams?
Which version of akka etc are you using?

Thanks for the additional info, let’s try looking into it.

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

It would be really nice to get an idea of the timeline. 

When it’s done” ;-) I’m sorry, but we’re not able to commit to these features 
nor dates for them as of now. It’s something we look into and is very tempting 
to implement.
For now though we’re all focused on getting streams out the door (1.0) and 
stabilising persistence 2.4 in the beginning of 2015, can’t guarantee anything 
beyond that.


Also ideas about how it can be integrated into a current system would 
be really helpful. 

It would be a replacement of the transport layer of akka for starters. Or 
simply use some of their tricks in our code (NIO hacks).
It does a bunch of more things (it’s log) which we could use for things, but no 
plans yet.
The future will be very interesting :-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Here’s all you need to know on how to implement your own journal plugin: 
http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#journal-plugin-api
Here are the existing plugins: akka.io/community#plugins-to-akka-persistence

happy hakking
On 20 November 2014 at 16:41:07, Soumya Simanta (soumya.sima...@gmail.com) 
wrote:

My understanding is Akka Persistence uses LevelDB as the default journal. I 
want to evaluate another KV store that similar to LevelDB. How easy/hard is it 
to replace the LevelDB with the new KV store. The store is written in C. I'm 
assuming Akka persistence calls LevelDB API using a wrapper (JNI?) over the 
native LevelDB interface. Correct? 

Thanks
-Soumya



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

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

[Konrad 'ktoso' Malawski]

Not quite sure what you are referring to with basically the feature 
did not pull it's weight so it was discontinued”?

Are you saying that the akka-camel module is orphaned?



Not camel, amqp.
It was a module long time ago in the 1.x series: 
http://doc.akka.io/docs/akka-modules/1.3.1/modules/amqp.html
Camel continues to be very useful on oh-so-many cases.

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Thanks, we’ll look into it!

On 21 November 2014 at 16:35:23, Oscar Broman (oscar.bro...@gmail.com) wrote:

Alright, I have created the issue here: 
https://github.com/akka/akka/issues/16363

Thank you for the replies.

On Sunday, November 16, 2014 1:42:48 AM UTC+1, Oscar Broman wrote:
Hello!

I've been messing around with akka-streams lately and ran into some problems. 
I'm not sure where to go from this point.

I have a TCP connection to an external data feed, in which I can subscribe to a 
wide variety of real-time data. What exactly will be subscribed to changes 
during runtime.

Messages from the external feed can land in one or many actors, and these 
actors have varying lifespans. Where the messages end up depend on their type 
and different types of information inside them.

How would I do this? From what I gather, using a FlexiRoute means I cannot add 
output ports after it has been materialized.

At one point the stream could look like this:

         tcp io
           |
  transform(chop at LF)
           |
    map(_.utf8String)
           |
  map(FeedMessageParser(_)) // data is now Option(FeedMessage)
           |
   filter(_ != None)
           |
          /|\
         / | \
        /  |  \
       /   |   \
      /    |    \
     /     |     \
    /      |      \
 TYPE=1  ID=3   TYPE=4,ID=4 // different prerequisites decide where the data 
flows next
   |       |      / \
   |       |     /   \
   |       |     |   |
   |       |     |   |
   |       |     |   |
  sub1     |     |   |
         sub2    |   |
               sub3 sub4


How do I do this best? Should I take a step back and look over my options, or 
is there a way to tame the river?
--
 Read the docs: http://akka.io/docs/
 Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

https://github.com/rkuhn/akka/tree/wip-g%C3%A5lbma-step1/akka-typed

Again to remind everyone, zero guarantees about that branch and it’s contents, 
it’s mostly a research thing currently and quite some time away still.

— k 

On 20 November 2014 at 18:15:01, Владимир Морозов (greenhos...@gmail.com) wrote:

In one of threads 
(https://groups.google.com/forum/#!searchin/akka-user/Best$20way$20to$20integrate$20akka$20into$20a$20legacy$2Fexisting$20app/akka-user/SDHSJxjNYSY/cZgAdUklC28J)
 user Akka team write 
Typed actors are no longer recommended, we will eventually phase them out
I already have application that use TypedActors inside, application grow up, 
but if Akka Team stop TypedActors improvement - my be I need to rewrite my 
application?
I choose TypedActors because return types of all calls check at compile time.

Any opinions or recommendation?

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

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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] dependency between tests when using ImplicitSender and forget to consume a response with any of the expect-methods

[Konrad 'ktoso' Malawski]

We actually often find this rather useful - for example, if there comes a 
response from the previous test case which I did not expect,
it could fail the 2nd test as an unexpected message may come in. This helps to 
make sure there’s no spurious and additional messages sent around.
So yes, when using ImplicitSender, the assumption is that you want to make sure 
you expect all messages.

If however you want to have the tests separated completely - don’t use implicit 
sender and use test probes instead:
http://doc.akka.io/docs/akka/snapshot/scala/testing.html#using-multiple-probe-actors

Both styles make complete sense and come down to your personal testing style - 
we use both styles to test Akka itself actually.

— ktoso



On 21 November 2014 at 22:41:24, Florian Witteler 
(florian.witte...@googlemail.com) wrote:

Hi!

I was bitten by some special behaviour when testing my actorSystem with the 
help of the ImplicitSender trait.

I have two testmethods. In each of them, I send a message to an actor wrapped 
in a TestActorRef.
In the first testcase, I don't consume the answer of the actor with one of 
TestKit's expect-Methods, because I check its state directly 
(testActorRef.underlyingActor)
This causes the 2nd testcase to fail, because the first message was still in 
the receiving mailbox.

Here is an example.
https://gist.github.com/FloWi/55572324f2d3adb3d51b

Do you have any suggestion on how to make the tests independent of each other?
Or am I just using the ImplicitSender in a wrong way? (every answer must be 
consumed)

Any insights are appreciated!

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

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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] dependency between tests when using ImplicitSender and forget to consume a response with any of the expect-methods

[Konrad 'ktoso' Malawski]

Thanks; you too!
Happy hakking!

— konrad

On 23 November 2014 at 00:51:45, Konrad 'ktoso' Malawski 
(konrad.malaw...@typesafe.com) wrote:

We actually often find this rather useful - for example, if there comes a 
response from the previous test case which I did not expect,
it could fail the 2nd test as an unexpected message may come in. This helps to 
make sure there’s no spurious and additional messages sent around.
So yes, when using ImplicitSender, the assumption is that you want to make sure 
you expect all messages.

If however you want to have the tests separated completely - don’t use implicit 
sender and use test probes instead:
http://doc.akka.io/docs/akka/snapshot/scala/testing.html#using-multiple-probe-actors

Both styles make complete sense and come down to your personal testing style - 
we use both styles to test Akka itself actually.

— ktoso



On 21 November 2014 at 22:41:24, Florian Witteler 
(florian.witte...@googlemail.com) wrote:

Hi!

I was bitten by some special behaviour when testing my actorSystem with the 
help of the ImplicitSender trait.

I have two testmethods. In each of them, I send a message to an actor wrapped 
in a TestActorRef.
In the first testcase, I don't consume the answer of the actor with one of 
TestKit's expect-Methods, because I check its state directly 
(testActorRef.underlyingActor)
This causes the 2nd testcase to fail, because the first message was still in 
the receiving mailbox.

Here is an example.
https://gist.github.com/FloWi/55572324f2d3adb3d51b

Do you have any suggestion on how to make the tests independent of each other?
Or am I just using the ImplicitSender in a wrong way? (every answer must be 
consumed)

Any insights are appreciated!

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

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

[Konrad 'ktoso' Malawski]

A surprising way to use the Journal I’d say but yeah, it would work.

— k 

On 24 November 2014 at 12:23:35, Soumya Simanta (soumya.sima...@gmail.com) 
wrote:



On Monday, November 24, 2014 3:29:33 AM UTC-5, Konrad Malawski wrote:

On Mon, Nov 24, 2014 at 5:50 AM, Soumya Simanta soumya@gmail.com wrote:
Also, doesn't snapshotting every message effectively means now your snapshot is 
your log/journal ? 
Please correct me if that is not correct.

That's more of a naming thing I'd say, but yes.

So in essence you can just read the latest message from the log/journal and 
there won't be a need to keep a snapshot. Correct?
 
--
 Read the docs: http://akka.io/docs/
 Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

You don’t remove things in an event sourced application.
You mark as deleted.

A
B
C
DEL-A
DEL-B
D
DEL-C

— konrad

On 24 November 2014 at 14:08:37, Karthik Chandraraj (ckarthi...@gmail.com) 
wrote:

The reason why I used snapshot instead of persist message is, I need to remove 
the message from the queue on processing it.
In case of snapshot, I will just remove it from the linked queue and save the 
snapshot.
How can I achieve the same using persist message?

For ex:
Consider I have received the 5 messages
A,B,C,D,E and I have persisted them.

Now another actor is reading this queue and processing A, once it is done, I 
need to remove it from the queue.
How can I remove the persisted message A? so that after restart or jvm crash, I 
won't process the message again?


On Saturday, November 22, 2014 3:30:48 PM UTC+5:30, Akka Team wrote:
Just use persist() to persist messages.
Snapshotting should not be used for every message - it should be used once in a 
while.

— konrad


On Fri, Nov 21, 2014 at 7:40 AM, Karthik Chandraraj ckart...@gmail.com wrote:
Hi,

As per the suggestion, I implemented a QueueActor, which will saveSnapshot for 
every message it receives or removed. And then a ProcessActor, which will read 
the message from the QueueActor to process it.

Is this the right way to implement durable mailbox with akka-persistence?
Problem I see with this approach is, for every message, the data is written to 
the file. Can we achieve durability only with this performance hit?

Thanks,
C.Karthik


On Thursday, November 13, 2014 7:58:01 PM UTC+5:30, Martynas Mickevičius wrote:
Hi Karthik,

akka-persistence does not replace but supersede durable mailboxes. That means 
if one wants to have an Actor that does not loose messages upon being killed 
then sender must use AtLeastOnce delivery trait (or some other means of 
durability with akka-persistence or not) to deliver messages to that Actor.

Let me know if that helped.

On Wed, Nov 12, 2014 at 2:03 PM, Karthik Chandraraj ckart...@gmail.com wrote:
Consider there are 100 messages in the mailbox and the actor is processing the 
first.
If the process is killed, what happens to the 99 messages?

When I was searching about this, I came across durable mailboxes, but the doc 
says 'durable mailboxes superseded by akka-persistence'. 
When I went though akka persistence, it said the actor state can be persisted, 
it doesn't talk about mailboxes? using akka-persistence, actors state can be 
stored, but what about messages that are in the mailbox and not received?

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



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



--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

Re: [akka-user] Akka streams - stability

[Konrad 'ktoso' Malawski]

We’ll announce when it’s “stable stable” ;-)
No huge changes planned, but there still may be a few here and there.

Issue tracker is github, as for the rest of Akka as well: 
https://github.com/akka/akka/issues?q=is%3Aopen+is%3Aissue+label%3At%3Astream

Happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

[Konrad 'ktoso' Malawski]

Hi David,
correct - maven can run ScalaTest tests just as well as it can run junit / 
testng.

Think of it this way: 
Akka’s TestKit is like a set of methods / “matchers”, like fest-assert in java 
land.
You don’t run fest-assert / hamcrest “tests”, you just use them in your junit / 
testng tests.
The same applies to Akka’s testkit - it’s not the runner, just a set of methods 
that help testing async / actor based code.

Here’s info on getting scalatest to run under maven: 
http://www.scalatest.org/user_guide/using_the_scalatest_maven_plugin


happy hakking!

— k 
On 3 December 2014 at 01:12:04, David (davidlu...@gmail.com) wrote:

Thank you ktoso.

I am coming from a pure Java background where my group is comfortable with a 
set of junit tests that can get run in our Continuous Integration Build.

In our first Akka/Scala project, we are looking for something in the Scala/Akka 
world that can where our CI can automatically run tests that we write ( I 
looked at TestKit first ).

So I wrote some simple tests but then my next question was, How do I get maven 
to run this?

Actually, you're comments have made me search further online while I write this 
and I am now guessing that another way of putting what you said is that

Maven can kick off ScalaTest tests, where these tests use TestKit to do 
synchronous tests/get underlying actor variables, etc.

http://doc.akka.io/docs/akka/2.0.1/scala/testkit-example.html

Is this correct?


On Tuesday, December 2, 2014 6:47:26 PM UTC-5, Konrad Malawski wrote:
Hello David,
I'm not sure what you mean since Akka's TestKit is just an utility class which 
you can use to write your own asynch actor tests.
It's not a test runner etc - we use ScalaTest to run tests for example but you 
could as well use Specs2 - TestKit does not depend on any of the frameworks.

Let me know if you'd need more hints or if this solves your problem

On Wed, Dec 3, 2014 at 12:34 AM, David david...@gmail.com wrote:
Hi, I am searching for a pom.xml file that triggers Akka Scala TestKit tests.

Something like

mvn test will cause my TestKit tests to execute.

Has anyone successfully done this?

Most of the projects I have downloaded from Github use SBT/Specs2.

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



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

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

[Konrad 'ktoso' Malawski]

And one minute afterwards… 1.0-M1 released!

See details in the announcement email :-)


Happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

On 4 December 2014 at 18:11:17, Akka Team (akka.offic...@gmail.com) wrote:

Hi Tom,

There wasn't a fully operating Http Client in 0.11 only some initial parts. 
Please wait for the 1.0-M1 version which comes with a fresh new API and a 
proper client. The new version is just around the corner ;)

-Endre

On Thu, Dec 4, 2014 at 4:27 PM, Tom Eccles eccles@gmail.com wrote:
I'm trying to use Akka HTTP to write an HttpClient to send a single request and 
receive a response. My current approach is the following method, having set up 
an OutgoingConnection:

  private def sendRequest(request: HttpRequest, connection: 
Http.OutgoingConnection): Future[HttpResponse] = {
    Source(List(request - 
'NoContext)).runWith(Sink(connection.requestSubscriber))
    
Source(connection.responsePublisher).map(_._1).runWith(Sink.head[HttpResponse])
  }

In the resulting TCP stream, I see the client send the HTTP request as 
expected, immediately followed by a TCP [FIN, ACK] packet. This causes the 
server to immediately reply with its own [FIN, ACK], closing the connection 
without sending a response.

Am I using the OutgoingConnection wrong, or is this a problem with Akka HTTP?

Strangely, I do get an HttpResponse when making requests to servers running 
with Akka HTTP - they respond despite the early FIN.
--
 Read the docs: http://akka.io/docs/
 Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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 Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Event Sourcing with eventual consistency guarantees

[Konrad 'ktoso' Malawski]

Hi Stefan,
Systems like you describe definitely *are* implemented in terms of persisting 
events.

I would highly recommend these following videos / papers as a holiday-read”:
* Eric Evans (Dad of DDD) about modeling to such constraints WITH thinking of 
time and WITHOUT transactions http://www.ustream.tv/recorded/46744749
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

On 25 December 2014 at 21:39:24, Stefan Schmidt (stsme...@gmail.com) wrote:

Hi guys,

I am currently prototyping a new app which involves transferring money between 
various accounts. On a very high level I have a system account (which is used 
to collect fees), one account for each member in the platform (many of them), 
and group accounts. Money needs to be moved on a frequent basis from member 
accounts (M) to group accounts (G) and the system account (S). 

Traditionally a transaction like this would be accomplished atomically:

tx start
  - read M account to check for sufficient funds
  - deduct money from M account
  - add money to S account
  - add money to G account
tx end

I know already that the system account S will be involved in most of these 
transactions and eventually become a bottleneck in the platform. Another 
requirement in the platform is to have all money movements fully auditable, 
which is a very common requirement. 

So using event sourcing and CQRS comes to mind to solve this problem. Initially 
my thinking is to have a single persistent actor for each member account (M), a 
persistent actor for the system account (S) and a single persistent actor for 
each group account (G). Each will store events related to their respective 
accounts and offer different views (to keep the balance, monitor fraudulent 
behaviour, statistics, etc).

In addition I would like to have a persistent actor to persist the overarching 
transaction events (lets call it TX actor), mostly for bookkeeping  statistics 
via its views. The idea is that a 'transaction' starts with this TX actor which 
then issues money transfer commands to all account actors involved (M, G, S), 
monitors their responses and either persists his own event of the successful 
transfer or issues a compensation commands in case something goes wrong).

Because there will be a large number of members in the platform I would like to 
use Akka clustering where the persistent actors may live on different nodes. I 
have played with hash based routing and cluster sharding to address the single 
writers per account. 

My problem at the moment is to figure out how each transaction can become 
eventually consistent (say within a few seconds) in a clustered environment 
like this where there are multiple points of failure. Obviously I need to 
ensure that a transaction cannot leave the system in an inconsistent state and 
potential manual compensations are also subject to their own errors.

I guess my question is if anyone has used Akka persistence / event sourcing / 
CQRS for handling financial transactions in a clustered environment? If so can 
you share some experiences or ideas, especially around ensuring (eventual) 
consistency?

It seems like event sourcing is a good solution to overcome some of the 
bottlenecks which a SQL database will create (especially where there is one 
very contentious resource (account S)) but there is are not many reports out 
there where people have used ES specifically for money handling (perhaps for 
good reason ;)).

Thanks in advance.

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

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

[Konrad 'ktoso' Malawski]

Hit command-enter too soon by accident before finishing my email - sorry! 
Here’s the rest.

To read:
And also Pet Helland’s (at that time at Amazon) legendary Life Beyond 
Distributed Transactions”

In general though. What you described as a transaction is in fact a series of 
events _plus_ a so called “Process Manager”.
This is DDD terminology, you’ll find more about thise in Books around Domain 
Driven Design or some of Vaughn’s talks ( I did not fully watch this one, but 
topic wise seems to be just what you’re asking https://vimeo.com/104021785 ).
So in essence, there is a persistent entity, which “takes care to drive the 
operations to their end”, for example it sees that this and that “transaction” 
(or simply “process”) did not succeed, maybe some message was lost, or maybe 
some server was down and we couldn’t proceed etc. So for furher reading on 
process managers I’ll refer to The “CQRS Journey” which I think you should go 
over while thinking about your business, esp. this chapter on “Sagas 
http://msdn.microsoft.com/en-us/library/jj591569

While we’re discussing this, please remember that money transactions don’t 
always offer full guarantees anyway.
Typical examples here being ATMs which can be not connected at all times, and 
*may* give out 50 bucks without checking if you really can because it’s *low 
risk* and they can block your account afterwards (hello eventual consistency!) 
anyway if you did in fact overdraw. However the same logic does not apply if 
you’re trying to get a few k out of an ATM, that won’t be as “low risk” of 
course, so the checks will have to be run before handing out the monies.

So instead of transactions, we can (just like real people) keep a process 
running and react to things happening around it,
and if we failed - take compensating actions - by always appending data + 
making sure *global* invariants are perserved (check Eric Evan’s talk I liked 
for awesame examples of this).

I hope this helps!
Merry x-mas hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

On 25 December 2014 at 21:39:24, Stefan Schmidt (stsme...@gmail.com) wrote:

Hi guys,

I am currently prototyping a new app which involves transferring money between 
various accounts. On a very high level I have a system account (which is used 
to collect fees), one account for each member in the platform (many of them), 
and group accounts. Money needs to be moved on a frequent basis from member 
accounts (M) to group accounts (G) and the system account (S). 

Traditionally a transaction like this would be accomplished atomically:

tx start
  - read M account to check for sufficient funds
  - deduct money from M account
  - add money to S account
  - add money to G account
tx end

I know already that the system account S will be involved in most of these 
transactions and eventually become a bottleneck in the platform. Another 
requirement in the platform is to have all money movements fully auditable, 
which is a very common requirement. 

So using event sourcing and CQRS comes to mind to solve this problem. Initially 
my thinking is to have a single persistent actor for each member account (M), a 
persistent actor for the system account (S) and a single persistent actor for 
each group account (G). Each will store events related to their respective 
accounts and offer different views (to keep the balance, monitor fraudulent 
behaviour, statistics, etc).

In addition I would like to have a persistent actor to persist the overarching 
transaction events (lets call it TX actor), mostly for bookkeeping  statistics 
via its views. The idea is that a 'transaction' starts with this TX actor which 
then issues money transfer commands to all account actors involved (M, G, S), 
monitors their responses and either persists his own event of the successful 
transfer or issues a compensation commands in case something goes wrong).

Because there will be a large number of members in the platform I would like to 
use Akka clustering where the persistent actors may live on different nodes. I 
have played with hash based routing and cluster sharding to address the single 
writers per account. 

My problem at the moment is to figure out how each transaction can become 
eventually consistent (say within a few seconds) in a clustered environment 
like this where there are multiple points of failure. Obviously I need to 
ensure that a transaction cannot leave the system in an inconsistent state and 
potential manual compensations are also subject to their own errors.

I guess my question is if anyone has used Akka persistence / event sourcing / 
CQRS for handling financial transactions in a clustered environment? If so can 
you share some experiences or ideas, especially around ensuring (eventual) 
consistency?

It seems like event sourcing is a good solution to overcome some of the 
bottlenecks which a SQL database will create (especially where there is one 
very contentious resource (account S

Re: [akka-user] Running a stream inside an Actor ?

[Konrad 'ktoso' Malawski]

Hello Soumya!
For materializing a stream from within another Actor you should use the 
ImplicitFlowMaterializer helper trait we provide:
https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/scaladsl/ImplicitFlowMaterializer.scala
This saves you from a number of pitfals around closing over “not the 
materializer I expected” etc.

As for actually running - I wouldn’t use the wording “inside an actor”, as the 
stream is a bunch of actors itself - and they’re not child actors of the actor,
but of the stream materializer. Instead let’s use the wording of “materializing 
a stream from within an actor”.

I just noticed we didn’t (yet!) document this trait. We’ll add it to the docs 
which we will be still improving after the holiday-break..

Happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

On 26 December 2014 at 05:00:18, Soumya Simanta (soumya.sima...@gmail.com) 
wrote:

My understanding is that a running stream is a bunch of actors underneath 
executing the flow. Assuming this to be true, is there any restriction or 
concerns of running a stream inside a normal Akka actor ? 

Thanks
-Soumya


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

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

[Konrad 'ktoso' Malawski]

Hi Soumya,
I don’t think what you’ll end up measuring this way will be very useful. I 
mean, between the completion of the future and the triggering of the map there 
are multiple asynchronous boundaries… So you won’t be measuring how fast the 
set operation was, but how much time was between these asynchronous boundaries 
- which could have been backpressured by the way.

I suggest directly wrapping the set call with your measurement logic instead - 
since that is what you want to measure it seems.

By the way, we do have a “timed” element, in our extras section: 
https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/extra/Timed.scala
 You can `import Timed._` and then use it as shown here: 
https://github.com/akka/akka/blob/release-2.3-dev/akka-stream-tests/src/test/scala/akka/stream/extra/FlowTimedSpec.scala
It’s a rather old element and I’m not sure if we’ll be keeping it, but you can 
use it as a source of inspiration in case you end up needing that kind of 
measurement.



On 26 December 2014 at 05:46:55, Soumya Simanta (soumya.sima...@gmail.com) 
wrote:


This is related to this thread but sufficiently different that I decided to 
create new thread. Hope that's okay. 

I would like to create a histogram of latency of a large number of set 
operations ( set returns a Future[Boolean]) using LatencyUtils 

 Basically I need to start recording the time before the set operation (inside 
mapAsyncUnordered(k = redis.set(k + rnd, message))) and then somehow record 
the end time in a map operation( .map( //record the end time here) after this. 
I'm having a hard time trying to figure this out. 

My understanding is that the even though the mapAsyncUnordered doesn't maintain 
the order of operations the map following the mapAsynUnordered will maintain 
the order from the previous stage because of TCP maintaining the order. Is this 
correct? 


val redis = RedisClient(localhost)

val random1 = UUID.randomUUID().toString

def insertValues(rnd: String): Flow[Int, Boolean] = {
    Flow[Int].mapAsyncUnordered(k = redis.set(k + rnd, message)).map( //record 
the end time here)
}

val blackhole = BlackholeSink

val maxSeq = 500
val seqSource = Source( () = (1 to maxSeq).iterator )
val streamWithSeqSource = 
seqSource.via(insertValues(random1)).runWith(blackhole)


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

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

[Konrad 'ktoso' Malawski]

Hello there,
You’re interested in akka-remoting - 
doc.akka.io/docs/akka/current/scala/remoting.html
It allows to spawn actors on remote nodes.

For starters: read up that documentation (remoting), and maybe have a look at 
the cluster http://doc.akka.io/docs/akka/current/scala/cluster-usage.html

And yes, you can of course send messages between actors on different nodes.

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

On 31 December 2014 at 06:23:49, Krishna Kadam (shrikrishna.kad...@gmail.com) 
wrote:

Hi all,


      I am a student, trying to horizontally scale a tool. I just want to know 
that, Can we have a ActorSystem  defined on a node and some of the actors from 
the same actor system deployed on the multiple nodes just for execution? and 
how I can do this?

And also Can I return the data updated by the actors deployed on nodes to the 
node1 in the architecture?


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

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

[Konrad 'ktoso' Malawski]

Hi Jacek,
As the name implies, japi is the java api, you’re not meant to be using those 
if you’re using Scala - just use the normal scala APIs.
The Scala Routing DSL cannot be reused directly by Java since it’s using all 
kinds of Scala types which simlpy do not look as nice in Java.
Akka HTTP (and Akka in general) aims to provide both languages with equally 
awesome DSLs, thus if things do not look great in Java, they
may require a separate DSL which in turn can Java-native types everywhere etc. 
to make it feel “right” for a Java developer.

For example Akka Streams also has two separate DSLs. This is in order to 
maximise the user’s happieness when working with it from either Java or Scala,
we simply can apply “what a Scala/Java developer would expect here” and provide 
the best possible DSL for each.

The Java Routing DSL is in the works, some tests are here: 
https://github.com/akka/akka/blob/release-2.3-dev/akka-http-java8-tests/src/test/java/akka/http/server/japi/HandlerBindingTest.java
It’s looks a bit different than the Scala one, which is because Java is not 
Scala and we’re unable to apply all the tricks we can apply in Scala Land for 
the Java DSL.

Please note that this is a major improvement over spray, since it never had a 
Java DSL – with Akka HTTP even Java users will be able to use it :-)

Cheers,

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

On 4 January 2015 at 14:08:16, Jacek Laskowski (jacek.japila...@gmail.com) 
wrote:

Hi,

It appears to be first step of Java routing API [1] with just a single commit 
(perhaps squashed earlier to make it look so). What's Java routing API? How is 
this different from Scala's one if any?

[1] 
https://github.com/akka/akka/commits/release-2.3-dev/akka-http-java/src/main/scala/akka/http/server/japi/HttpApp.scala

Jacek

On Sunday, January 4, 2015 1:34:56 PM UTC+1, Jacek Laskowski wrote:
Hi,

Thanks for the hint, Björn. I've been pursuing the idea and used japi.HttpApp, 
but ended up with the following compilation error:

[error]  found   : akka.http.server.scala.Route
[error]     (which expands to)  akka.http.server.RequestContext = 
scala.concurrent.Future[akka.http.server.RouteResult]
[error]  required: akka.http.server.japi.Route


Before going any further, I'd love figuring out what's the intent of the japi 
package and how the seemingly alike types - scala.Route and japi.Route - 
compare. Where should they be used?

Jacek

On Wednesday, December 10, 2014 2:54:16 PM UTC+1, Björn Antonsson wrote:
Hi Stevo,

There is no direct equivalent to the spray.routing.HttpService. The closest is 
probably the akka.http.server.japi.HttpService and 
akka.http.server.japi.HttpApp.

B/

On 9 December 2014 at 16:04:57, Stevo Slavić (ssl...@gmail.com) wrote:

Hello Akka community,

In akka-http, is there an equivalent to spray.routing.HttpService?

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

-- 
Björn Antonsson
Typesafe – Reactive Apps on the JVM
twitter: @bantonsson

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

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send 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] How to disable TLSv1 when I configure "akka.remote.netty.ssl.security.protocol" property as TLSv1.2.

[Konrad 'ktoso' Malawski]

That seems like a good catch indeed!
Thanks for finding this.

I've made an issue and PR for it: 
https://github.com/akka/akka/issues/21077
https://github.com/akka/akka/pull/21078

If reviewed by team we could include this patch very soon.

Thanks for reporting!

-- Konrad

W dniu czwartek, 28 lipca 2016 09:36:59 UTC+2 użytkownik 
yinzho...@gmail.com napisał:
>
> Thank you first for your reply :)
>
> I add TLSv1 to jdk.tls.disabledAlgorithms of JRE java.security file, in 
> this way I can resolve the problem, but the modify will globally affect, 
> for example there is a java app needs TLSv1.
> Otherwise, I have tried "jdk.tls.client.protocols" system property, but it 
> does not achieve the desired effect.
>
> I have tried to invoke "setEnabledProtocols" method 
> of javax.net.ssl.SSLEngine class on my java test code, it can achieve the 
> desired effect.
> The relevant AKKA source code of akka.remoting as follow:
> case Some(context) ⇒
> log.debug("Using client SSL context to create SSLEngine ...")
> new SslHandler({
>   val sslEngine = context.createSSLEngine
>   sslEngine.setUseClientMode(true)
>   sslEngine.setEnabledCipherSuites(settings.SSLEnabledAlgorithms.
> toArray)
>   sslEngine.setEnabledProtocols(Array("TLSv1.2"))   =>  Add this 
> line can resovle my problem, but I don't want to modify AKKA source code 
> :(
>   sslEngine
>
> Is there a way to set ssl option without modify AKKA source code?
> Thank you.
>
>
> 在 2016年7月27日星期三 UTC+8上午4:02:45，Will Sargent写道：
>>
>> You can set the "jdk.tls.client.protocols" system property to set options 
>> for the JVM -- this is a feature that is only available in JDK 1.8 though.
>>
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols
>>
>> Otherwise, you would have to set the security 
>> property jdk.tls.disabledAlgorithms to add TLSv1 specifically.
>>
>>
>> Will Sargent
>> Engineer, Lightbend, Inc.
>>
>>
>> On Tue, Jul 26, 2016 at 1:12 AM,  wrote:
>>
>>> Configure file as follow:
>>> # Protocol to use for SSL encryption, choose from:
>>> # Java 6 & 7:
>>> #   'SSLv3', 'TLSv1'
>>> # Java 7:
>>> #   'TLSv1.1', 'TLSv1.2'
>>> protocol = "TLSv1.2"
>>>
>>>
>>> When I use nmap to scan, I find that TLSv1 is enabled:
>>> D:\softwares\nmap-7.12>nmap -p  --script=ssl* x.x.x.x --unprivileged
>>>
>>>
>>> Starting Nmap 7.12 ( https://nmap.org ) at 2016-07-26 15:33 
>>> °?′óà÷2?±ê×?ê±??
>>> Nmap scan report for x.x.x.x
>>> Host is up (1.0s latency).
>>> PORT STATE  SERVICE
>>> /tcp open unknown
>>> | ssl-enum-ciphers:
>>> |  TLSv1.0:
>>> |ciphers:
>>> |  TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) -A
>>> |compressors:
>>> |  NULL
>>> |cipher preference: indeterminate
>>> |cipher preference error: Too few ciphers supported
>>> |  TLSv1.1:
>>> |ciphers:
>>> |  TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) -A
>>> |compressors:
>>> |  NULL
>>> |cipher preference: indeterminate
>>> |cipher preference error: Too few ciphers supported
>>> |  TLSv1.2:
>>> |ciphers:
>>> |  TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) -A
>>> |compressors:
>>> |  NULL
>>> |cipher preference: indeterminate
>>> |cipher preference error: Too few ciphers supported
>>> |_ least strength: A
>>> MAC Address: xx:xx:xx:xx:xx:xx
>>>
>>>
>>> Nmap done: 1 IP address (1 host up) scanned in 3.88 seconds
>>>
>>>
>>> D:\softwares\nmap-7.12>
>>>
>>> I want to disable TLSv1. Any method?
>>> Thank you.
>>>
>>>
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

[akka-user] [ANNOUNCE] Akka 2.4.9-RC1 Released! (Akka HTTP Performance and Entity Streaming)

[Konrad 'ktoso' Malawski]

Dear hAkkers,

We—the Akka committers—are pleased to be able to announce the availability 
of Akka 2.4.9-RC1. 

This version is focused on Akka HTTP performance improvements as well as 
introducing the entity streaming feature which we’ll discuss below. 

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

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

We would like to encourage Akka HTTP users to try out this Release 
Candidate and provide feedback or report regressions if you find any. 

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. A stable 2.4.9 should 
follow shortly after we’ve gathered some community feedback.
Next steps for Akka HTTP

Having that said, we’ll want to officially announce the end-of-life of 
Spray and confidently request users to upgrade to Akka HTTP. 

Yes, this means we’ll soon be lifting the experimental flag from Akka HTTP. 

The exact timeline for this is yet to be decided, as we want to discuss 
with the community about the best way to go about this.

The other question that is on everyone’s minds is one about HTTP/2.

We’d like to announce that we’ll spend some time working on an HTTP/2 
Proof-of-Content within a few months. 

You can follow our sprint plans on akka-meta be up to date about our sprint 
plans and progress.


Credits:

commits added removed

  3957531748 Konrad `ktoso` Malawski

  11 693 239 Johan Andrén

   7 828 295 Endre Sándor Varga

   6 776 410 Hawstein

   5 171  81 Nafer Sanabria

   2   4   4 kenji yoshida

   2  55  22 Alexander Golubev

   2 111   3 Stefano Bonetti

   2  41  12 Richard Imaoka

   1  25   0 Lev Khomich

   1  41  15 Łukasz Dubiel

   1  54  22 Ian Clegg

   1  37  22 priyanka

   1  53  18 Nikolay Donets

   1 202   1 Richard S. Imaoka

   1   2   3 Jacek Kunicki

   1   2   2 abesanderson

   1   7   2 Alexei

   1   6   6 Thomas Szymanski

   1   1   0 Vadim Semenov

   1 246   7 Peter Barron

   1  16   7 Tim Harper

   1  40   0 Ivan Lorenz

   1   1   1 Morton Fox

   1   1   1 Yaroslav Klymko

   1   2   2 Alexandre Tamborrino

   1  20   0 Harit Himanshu



In this patch release we closed 43 tickets, and got the help from 24 
contributors, thanks a lot! 

The complete list of closed tickets can be found in the 2.4.9-RC1 milestone 
<https://github.com/akka/akka/milestone/91?closed=1> on GitHub. 

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 subscr

[akka-user] [ANNOUNCE] Akka 2.4.9-RC2 released!

[Konrad 'ktoso' Malawski]

Dear hAkkers,

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

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

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

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

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


Credits:

commits added removed

   2 147 134 Konrad Malawski

   2   5  10 Endre Sándor Varga

   2  22   8 Johan Andrén

   1   1   1 Todd Ginsberg

   1   2   2 skchrko


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

Happy hakking!


-- 

Akka team


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

[akka-user] Re: Akka http vs Spray performance

[Konrad 'ktoso' Malawski]

Figured I should link to the 2.4.9 annoucement from this old thread (as it 
shows up high in google).
In 2.4.9 we did quite some improvements, annoucement here:
http://akka.io/news/2016/08/19/akka-2.4.9-released.html  


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

Happy hakking!

-- Konrad

W dniu środa, 27 maja 2015 12:44:49 UTC+1 użytkownik zergood napisał:
>
> I've done little benchmarks to compare spray and akka-http performance. I 
> use default jvm and akka settings. So you can see that there is 
> an significant performance difference between it.
>
> code:
> spray https://gist.github.com/zergood/18bae0adc2e774c31233. 
> akka-http https://gist.github.com/zergood/53977efd500985a34ea1.
>
> versions:
> spray 1.3.3 
> akka-http 1.0-RC3
> scala 2.11.6
> java 1.8
>
> wrk output for spray:
> Running 1m test @ 
> http://127.0.0.1:8080/dictionaries/hello/suggestions?ngr=hond
>   30 threads and 64 connections
>   Thread Stats   Avg  Stdev Max   +/- Stdev
> Latency 2.14ms9.82ms  78.22ms   98.22%
> Req/Sec 2.55k   609.68 4.22k78.12%
>   4322357 requests in 1.00m, 614.20MB read
> Requests/sec:  72044.97
> Transfer/sec: 10.24MB
>
> wrk output for akka-http:
> Running 1m test @ 
> http://127.0.0.1:3535/dictionaries/hello/suggestions?ngr=hond
>   30 threads and 64 connections
>   Thread Stats   Avg  Stdev Max   +/- Stdev
> Latency 5.39ms6.82ms 108.07ms   92.80%
> Req/Sec   454.43126.73   679.00 77.77%
>   811836 requests in 1.00m, 115.36MB read
> Requests/sec:  13531.62
> Transfer/sec:  1.92MB
>
> Is there any akka-http config options to increase performance to the same 
> level as spray?
>

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

[Konrad 'ktoso' Malawski]

Seems like double posted the same question?
Please don't double post the same question :-)

I answered in that 
thread: https://groups.google.com/forum/#!topic/akka-user/7VqlP1w_CN8

-- 
Konrad
Akka Team

W dniu piątek, 14 października 2016 09:02:59 UTC+2 użytkownik regis leray 
napisał:
>
> I'm trying to implement the pause/resume in akka stream.
> The current implementation, is buffering all elements into an List if the 
> valve is in mode "close", if not we are pushing elements like the default 
> behavior.
>
> When we are resuming the flow by calling the materialize value 
> switch.open, we change the mode to open and pushing all buffered elements.
> Currently im suspecting this code to be the problem
>
> val switch = new ValveSwitch {
>   override def open: Unit = {
> mode = ValveMode.Open
> println(s"pushing $bufferedElement, out is available ? 
> ${isAvailable(out)}")
>
> bufferedElement.foreach(push(out, _))
> bufferedElement = Option.empty
>   }
>
> ...
>
> }
>
>
> In my unit test when the switch is changing close to open, the Sink never 
> receive the elements
>
> "A closed valve" should "emit only 3 elements after it has been open" in {
>   val (valve, probe) = Source(1 to 5)
> .viaMat(new Valve(ValveMode.Closed))(Keep.right)
> .toMat(TestSink.probe[Int])(Keep.both)
> .run()
>
>   probe.request(2)
>   probe.expectNoMsg()
>
>   valve.open // we are pushing the buffered elements
>   probe.expectNext shouldEqual 1 // this assert is failing !
>   probe.expectNext shouldEqual 2
>
> }
>
>
> Any help would be really appreciated
>
> Here
> https://gist.github.com/regis-leray/013dfe030159bcd890ca0d5cd440c938
>
>
> Le jeudi 13 octobre 2016 12:52:58 UTC-4, regis leray a écrit :
>>
>> Hi, 
>>
>> I'm trying to implements a way to control a flow (start/stop), nothing 
>> was implemented yet in the core of akka-stream
>>
>> My current implementation looks like this.
>>
>> trait ValveSwitch {
>>   def open: Unit
>>   def close: Unit
>> }
>>
>> class Valve[A](mode: ValveMode = ValveMode.Open) extends 
>> GraphStageWithMaterializedValue[FlowShape[A, A], ValveSwitch] {
>>
>>   override val shape = FlowShape(Inlet[A]("valve.in"), 
>> Outlet[A]("valve.out"))
>>
>>   override def createLogicAndMaterializedValue(inheritedAttributes: 
>> Attributes): (GraphStageLogic, ValveSwitch) = {
>> val logic = new ValveGraphStageLogic(shape, mode)
>> (logic, logic.switch)
>>   }
>>
>>   private class ValveGraphStageLogic(shape: Shape, var mode: ValveMode) 
>> extends GraphStageLogic(shape){
>> import shape._
>>
>> var bufferedElement = List.empty[A]
>>
>> val switch = new ValveSwitch {
>>   override def open: Unit = {
>> mode = ValveMode.Open
>> println(s"pushing $bufferedElement, out is available ? 
>> ${isAvailable(out)}")
>> bufferedElement.foreach(push(out, _))
>> bufferedElement = List.empty
>>   }
>>
>>   override def close: Unit = {
>> mode = ValveMode.Closed
>>   }
>> }
>>
>> setHandler(in, new InHandler {
>>   override def onPush(): Unit = {
>> val element = grab(in) //acquires the element that has been 
>> received during an onPush
>> println(s"${mode} on push called with $element")
>> if (mode == ValveMode.Open) {
>>   push(out, element) //push directly the element on the out port
>> } else {
>>   bufferedElement = bufferedElement :+ element
>> }
>>   }
>> })
>>
>> setHandler(out, new OutHandler {
>>   override def onPull(): Unit = {
>> println("on pull called")
>> pull(in) //request the next element on in port
>>   }
>> })
>>   }
>> }
>>
>> trait ValveMode
>>
>> object ValveMode {
>>   case object Open extends ValveMode
>>   case object Closed extends ValveMode
>> }
>>
>> 
>>
>> My current unit test is failing. due to the fact when i open the valve, i 
>> never received the previous message.
>> It seems even if i push the element through ( valve.open ) the sink 
>> never receive the element
>>
>> class ValveSpec extends FlatSpec {
>>
>>   implicit val system = ActorSystem()
>>   implicit val materializer = ActorMaterializer()
>>   implicit val executionContext = materializer.executionContext
>>
>>
>>   "A closed valve" should "emit only 3 elements after it has been open" 
>> in {
>> val (valve, probe) = Source(1 to 3)
>>   .viaMat(new Valve(ValveMode.Closed))(Keep.right)
>>   .toMat(TestSink.probe[Int])(Keep.both)
>>   .run()
>>
>> probe.request(1)
>> probe.expectNoMsg()
>>
>> valve.open
>> probe.expectNext(1)
>>
>> probe.request(2)
>> probe.expectNext(2, 3)
>>
>> probe.expectComplete()
>>   }
>> }
>>
>>
>> Here the gist 
>> https://gist.github.com/regis-leray/013dfe030159bcd890ca0d5cd440c938
>>
>

-- 
>>  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 - implements Pause/Resume

[Konrad 'ktoso' Malawski]

Please read this:
- http://blog.akka.io/integrations/2016/08/29/connecting-existing-apis 
- and this: http://doc.akka.io/docs/akka/2.4/scala/stream/stream
-customize.html

Specifically, your trigger should be implemented as async-callback, as it 
comes from the outside but should "wake up" the stage to be able to push 
data again.
In your current setup it never "wakes up" since all pulls/pushes have been 
processed - the stage has no idea it should do something once you called 
open.

-- Konrad

W dniu piątek, 14 października 2016 09:03:54 UTC+2 użytkownik regis leray 
napisał:
>
> Hi,
>
> Im currently trying to implement a valve Graph to manage pause/resume. We 
> can control the behavior of the graph by using the MaterializeValue
>
> trait ValveSwitch {
>   def open: Unit
>   def close: Unit
> }
>
>
> Current implementation of the valve
>
> class Valve[A](mode: ValveMode = ValveMode.Open) extends 
> GraphStageWithMaterializedValue[FlowShape[A, A], ValveSwitch] {
>
>   override val shape = FlowShape(Inlet[A]("valve.in"), Outlet[A]("valve.out"))
>
>   override def createLogicAndMaterializedValue(inheritedAttributes: 
> Attributes): (GraphStageLogic, ValveSwitch) = {
> val logic = new ValveGraphStageLogic(shape, mode)
> (logic, logic.switch)
>   }
>
> }
>
>
> The current implementation is pretty simple, each time we are receiving a 
> onPull demand we are requesting by doing pull(in).
> When a onPush demand is received we are checking the current state 
> - if Open we are doing the default behavior by doing push(out,element)
> - if Close we are putting the element into a queue
>
> private class ValveGraphStageLogic(shape: Shape, var mode: ValveMode) extends 
> GraphStageLogic(shape){
>   import shape._
>
>   var bufferedElement = List.empty[A]
>
>   val switch = new ValveSwitch {
> override def open: Unit = {
>   mode = ValveMode.Open
>   println(s"pushing $bufferedElement, out is available ? 
> ${isAvailable(out)}")
>
>   bufferedElement.foreach(push(out, _))
>   bufferedElement = List.empty
> }
>
> override def close: Unit = {
>   mode = ValveMode.Closed
> }
>   }
>
>   setHandler(in, new InHandler {
> override def onPush(): Unit = {
>   val element = grab(in) //acquires the element that has been received 
> during an onPush
>   println(s"${mode} on push called with $element")
>   if (mode == ValveMode.Open) {
> push(out, element) //push directly the element on the out port
>   } else {
> bufferedElement = bufferedElement :+ element
>   }
> }
>   })
>
>   setHandler(out, new OutHandler {
> override def onPull(): Unit = {
>   println("on pull called")
>   pull(in) //request the next element on in port
> }
>   })
> }
>
>
> When we are resuming the valve my using the switch.open, we are pushing 
> the element
>
> override def open: Unit = {
>
>   mode = ValveMode.Open
>   println(s"pushing $bufferedElement, out is available ? ${isAvailable(out)}")
>
>   bufferedElement.foreach(push(out, _))
>   bufferedElement = List.empty
> }
>
>
> The Current test is failing
>
> "A closed valve" should "emit only 3 elements after it has been open" in {
>   
> val (valve, probe) = Source(1 to 5)
> .viaMat(new Valve(ValveMode.Closed))(Keep.right) //the current valve by 
> default is closed, dont push any message
> .toMat(TestSink.probe[Int])(Keep.both)
> .run()
>
>   probe.request(2)
>   probe.expectNoMsg()
>
>   valve.open //open the valve should emit the previous
>
>
>   probe.expectNext shouldEqual 1 //we never receive the element
>   probe.expectNext shouldEqual 2
>
>   probe.request(3)
>   probe.expectNext shouldEqual 3
>   probe.expectNext shouldEqual 4
>   probe.expectNext shouldEqual 5
>
>   probe.expectComplete()
> }
>
>
> Here the console log
>
> on pull called
> Closed on push called with 1
> pushing Some(1), out is available ? true
>
> Expected OnNext(_), yet no element signaled during 3 seconds
> java.lang.AssertionError: Expected OnNext(_), yet no element signaled during 
> 3 seconds
> at 
> akka.stream.testkit.TestSubscriber$ManualProbe.expectNext(StreamTestKit.scala:268)
> at 
> akka.stream.testkit.TestSubscriber$ManualProbe.expectNext(StreamTestKit.scala:259)
> at 
> com.omsignal.omrun.orchestration.rest.ValveSpec$$anonfun$1.apply(ValveSpec.scala:44)
> at 
> com.omsignal.omrun.orchestration.rest.ValveSpec$$anonfun$1.apply(ValveSpec.scala:34)
>
>
> I'm suspecting the current code to have an issue when we are resuming the 
> valve, it doesnt seems the push really works
>
> val switch = new ValveSwitch {
> override def open: Unit = {
>   mode = ValveMode.Open
>   println(s"pushing $bufferedElement, out is available ? 
> ${isAvailable(out)}")
>
>   bufferedElement.foreach(push(out, _))
>   bufferedElement = Option.empty
> }
>
> override def close: Unit = {
>   mode = ValveMode.Closed
> }
>   }
>
>
> There is definitively something i dont catch up, if anyone 

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

[Konrad 'ktoso' Malawski]

Dear hakkers,

We are proud to announce the first Release Candidate of the Akka HTTP's 
"fully stable" release–the only missing, bit was the Routing DSLs, which we 
now deem stable enough to support for an extended period of time.


This release marks the first of the 3.0.0 series of this project and 
signifies a large step in terms of confidence in the library, as well as 
the move of Akka HTTP into its own repository. From now on Akka HTTP will 
be versioned separately from Akka “core”. This has been discussed at large 
with the community on akka-meta , and the 
akka-http  repositories on github. 
Thank you very much for your input!

For more background why this move, please read “Akka HTTP - stable, growing 
and tons of opportunity ” on 
akka-meta. While preparing In the meantime we have delivered a 
Proof-of-Concept of HTTP/2 for Akka HTTP and plan to continue this work 
later this year–community help is very much welcome on this front as well.

The documentation from now on will be available here: 

Some noteworthy changes in the *3.0.0-RC1* (since it's move out from 
2.4.11) release are:


   - 
   
   New lightbend/paradox powered documentation
   - 
  
  This will allow us to aggregate it together with Akka and other 
  documentation, as well as link more easily to ScalaDoc pages
  - 
  
  Akka HTTP documentation will from now on live here: 
  http://doc.akka.io/docs/akka-http/current/index.html
  - 
  
  We’ll work on a better theme for it very soon.
  - 
   
   Multipart is now correctly Binary MediaType (instead of WithOpenCharset) 
   #398 
   - 
   
   A new designated mailing-list and page for any critical security issues 
   that might come up has been created: 
   http://doc.akka.io/docs/akka-http/current/security.html 
   - 
  
  Please follow the linked mailing list if you have production Akka 
  systems, so you’ll be the first to know in case a security issue is found 
  and fixed in Akka.
  

The plan regarding releasing a stable 3.0.0 is to wait a little bit for 
community feedback on the release candidates, and call a stable one no 
longer than a few weeks from now. We’re eagerly awaiting your feedback and 
can’t wait to ship the stable version of all of Akka HTTP’s modules!

Credits

A total 15 issues were closed since 2.4.11, most of the work was moving 
source code, documentation and issues to their new places.

The complete list of closed issues can be found on the 3.0.0-RC1 
 milestone on 
github.

For this release we had the help of 14 committers – thank you!

A special thanks to Jonas Fonseca  who did a 
tremendously awesome job at migrating all the docs from sphinx 
(restructuredtext) to paradox (markdown), contributing features that the 
Akka docs needed to upstream Paradox–thanks a lot!

Credits:

commits added removed

  10   22489   24696 Jonas Fonseca

  101927 256 Johannes Rudolph

  10 849 412 Konrad Malawski

   4 448 136 Robert Budźko

   2  37  37 Bernard Leach

   2 107   7 Richard Imaoka

   2  26  24 Jakub Kozłowski

   1 145 101 Jan @gosubpl

   1 108 114 Derek Wyatt

   1  45  33 Wojciech Langiewicz

   1  49   0 @2beaucoup

   1   6   6 Markus Hauck

   1   1   1 Ian Forsey

   1   1   1 Johan Andrén


Happy hakking!

– The Akka Team

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

[akka-user] ANNOUNCE: Akka 2.4.14 released!

[Konrad 'ktoso' Malawski]

Dear hakkers,

We are proud to announce the fourteenth maintenance release of Akka 2.4 
which contains a number of improvements and bugfixes.


Some notable changes are:

   - When reading snapshots fails for a persistent actor it will now cause 
   recovery failure #21842 
   - Performance improvements for the LocalSnapshotStore #20821 
   
   - Attributes on flatMapConcat/flatMapMerge now propagated to the inner 
   streams #21743 
   - Methods around actor selection returning Java CompletionStages #21726 
   
   - gzip/deflate Flows have been moved to Akka-Streams from Akka HTTP, so 
   that they can be used in any streaming application #21395 
   
   
Akka HTTP

Akka HTTP is not part of this release as it has moved to it’s own 
repository and will be released as soon as possible, as Akka 10.0.0. 

Keep your eyes our for an announcement about it *very soon*.
Skip Akka 2.4.13, due to uncovered regression

Please note that the 2.4.13 release contained a bug in the ByteStringParser 
that 
we noticed immediately after releasing, and decided to not announce that 
version - please upgrade immediately to 2.4.14 instead (or higher, as new 
versions become available). We will invest in strengthening 
downstream-dependency testing throughout the coming sprints, to avoid such 
issue from happening again.
Credits

A total 39 issues were closed since 2.4.12. The complete list of closed 
issues can be found on the 2.4.14 milestone on github 
.

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

Credits:
commits  added  removed
 12432  231 Patrik Nordwall
  9726  141 Johannes Rudolph
  6189   64 Johan Andrén
  5 20  862 Konrad Malawski
  5464  107 drewhk
  5 71   45 Björn Antonsson
  3650   24 Olli Helenius
  2 64   88 Hawstein
  2 80   33 Richard Imaoka
  2 67   18 Andy Chung
  2 39   14 Nafer Sanabria
  2 24   26 Martynas Mickevičius
  1 431 Vsevolod (Seva) Belousov
  1 332 Alexander Gavrilov
  1 256 Wojciech Grajewski
  1  8   14 Cédric Chantepie
  1  77 kenji yoshida
  1  64 Andrey Kuznetsov
  1  72 ortigali
  1  11 Marc Piechura

*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 HTTP 10.0.0 – fully stable release!

[Konrad 'ktoso' Malawski]

Dear hakkers,

Today, we are proud and happy to announce the immediate availability of the 
fully stable version of Akka HTTP – 10.0.0, charmingly code named “X” by 
@jonas on gitter!

Please note that while the version number changed significantly, the actual 
surface APIs did not by much. The akka-http-core module was already stable 
back in Akka 2.4, so it remained binary compatible, and the sources for 
akka-http are almost completely compatible with those that were shipped as 
Akka 2.4.11 – you should not have any trouble upgrading.


>From here-on the Akka HTTP releases will respect binary compatibility, as 
expected from stable Akka modules. We will also try out a novel way of 
introducing new APIs, by shipping them in the stable modules however 
marking them as “experimental” or “not-sure-if-we-keep-them” so you’d be 
able to opt-in into those on a case-by case basis. This idea is under 
discussion in the Consider @Experimental / @ApiMayChange markers on APIs 
 issue on github.


Along with the new version, and stability of all of the modules, we expect 
the community to quickly catch up with releasing the various support 
projects for the new version, such as akka-http-cors 
, akka-sse 
, akka-http-session 
, akka-json 
. This includes cross 
releases for Scala 2.12, for which Akka HTTP is now available as well.
Documentation

The documentation  is available 
under a separate directory under doc.akka.io, and will follow the following 
scheme: doc.akka.io/docs/akka-http/[version]/, the usual “current” symlink 
is also available and we recommend using that if linking to Akka 
documentation from external sites such as stack overflow or blogs.

The documentation has moved to the Lightbend Paradox 
 tool, which allows us to write 
documentation using extended markdown, instead of restructuredtext which we 
found was making it difficult for first time contributors. Thanks a lot, 
@jonas , who contributed the biggest part of the 
conversion!


We are currently working on a redesign of the documentation pages, so they 
will soon get a shiny new look. Please bear with us during the transition 
period. Other projects, like Alpakka, Reactive Kafka have also already 
adopted Paradox, and Akka itself will soon follow as well. We will be able 
to provide very interesting features thanks to Paradox, keep your eyes 
peeled for them soon.


As always, help is very welcome, and if you find a part of the 
documentation you’d like to see improved, please open tickets or send in 
pull requests 
 directly, 
thanks in advance!
Versioning

Akka HTTP from here-on will be versioned separately from Akka “core”. The 
original purpose of these projects sharing their version number was that 
Akka HTTP was evolving and providing many real-world requirements for the 
Akka Streams implementation, thus they were developed together. Now that 
both projects are stable, we want to be able to move them more 
independently.


The version scheme will follow semantic versioning, breaking changes will 
only be made in major releases (i.e. the next one being 11.0.0). However we 
will also introduce a new way of marking experimental APIs released inside 
existing modules – for a discussion on this please see the issue 
akka/akka-http#3 .

The -experimental suffix has now been dropped for all of Akka HTTP’s 
module. During the transition period make sure not to transitively depend 
on old artifacts that still carry the suffix (like akka-http-experimental). 
Otherwise, you could end up with multiple versions of the same classes on 
the classpath.


This version of Akka HTTP depends on Akka *2.4.14*, since some critical 
fixes and improvements were made in the recent version of Akka.
Community

We consider ourselves very lucky that we have such vibrant and helpful 
community around Akka, and Akka HTTP specifically. In recent months we 
started to include more community members in our github teams for the 
various projects (reactive-kafka , 
alpakka , akka-http), and plan on 
continuing to do so. If you’re interested in becoming part of our extended 
teams, please read: Akka HTTP - stable, growing and tons of opportunity 
 on akka-meta and keep hakking 
:-)
Credits

A total 22 issues were closed since the last release candidate, most of the 
work has been fixes, stability improvements and preparing for the upcoming 
stable release.

The complete list of closed issues since the split from 

Re: [akka-user] Persistence Query and Sharding

[Konrad “ktoso” Malawski]

*Eventually* all events with the given tag.
Note also that that stream is infinite, unlike the “currentEventsByTag”
which is finite and whatever was currently visible by that tag when it was
reading.

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 1 August 2017 at 01:26:27, Moritz Schallaböck (
moritz.schallabo...@agido.com) wrote:

Hi,

I'm wondering if a persistence query running in a sharded environment sees
the events from all shards, or just the "local" shards.

Using the Cassandra Journal Plugin.

Say I have 3 cluster shards, each (for argument's sake) running in their
own VM:
- shard 1
- shard 2
- shard 3

Furthermore I have one persistent actor each:
- shard 1: actor A
- shard 2: actor B
- shard 3: actor C

Now each actor persists an event and tags it:
- shard 1: actor A: persist(Tagged(MyEvent("A"), Set("Tag1"))
- shard 2: actor B: persist(Tagged(MyEvent("B"), Set("Tag1"))
- shard 3: actor C: persist(Tagged(MyEvent("C"), Set("Tag1"))

Now, when I run a persistence query in shard 1:
- readJournal.eventsByTag("Tag1")

Does it see "A", "B", "C"? Or just "A"? Something else entirely?

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

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

Re: [akka-user] akka-1.3.1.xsd schema location

[Konrad “ktoso” Malawski]

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


—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

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

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

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


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

The schema definitions in the configuration file are:

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

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

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

thank you,

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

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

Re: [akka-user] Flow.fromSinkAndSource and backpressure

[Konrad “ktoso” Malawski]

Hi Jeff,

Alexey, that’s not correct, back-pressure works there - because it has to:
it is enforced by the reactive-streams protocol that we follow by heart in
Akka streams.

Yes, back-pressure works, the one sentence explanation would be:
“independently on each side of the newly constructed flow”.

So if the Sink you created that Flow from does not pull, no one will be
able to push data into that “Flow”.
Similarly, your Source, that created this Flow’s “output”, is not pulled
“from” it is not allowed to push data - it is being back-pressured.

Since completion was mentioned, indeed completion does not carry over from
one end to the other,
since they’re intentionally separate here. If you want to bind the
completion events use Flow.fromSinkAndSourceCoupled.

Happy hakking!

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 2 August 2017 at 15:31:16, Alexey Shuksto (seig...@gmail.com) wrote:

Nope. More so, completion of one of them would not cause completion of
another and flow 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.

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

[Konrad “ktoso” Malawski]

Good point, I missed that word in the question - thanks and sorry about
that :)
A full clarification was still useful I hope though, cheers!

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 2 August 2017 at 15:45:51, Alexey Shuksto (seig...@gmail.com) wrote:

Hi Konrad,

Jeff was asking about 'backpressure propagation'. From my understanding
that means that when source wasn't pulled, sink would not pull. And that's
not how it works as you already mentioned.

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

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

Re: [akka-user] Akka cluster on Hadoop YARN

[Konrad “ktoso” Malawski]

There has not been much interest in that from what I can cell.
Rather people are using k8s, marathon/mesos etc to run Akka applications
nowadays.

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 15 August 2017 at 12:03:14, Juan Rodríguez Hortalá (
juan.rodriguez.hort...@gmail.com) wrote:

Hi all,

In a previous thread (
https://groups.google.com/forum/#!searchin/akka-user/yarn%7Csort:relevance/akka-user/ylV2tD5uuq8/8c3EN69ehrwJ)
there was a discussion about running Akka cluster on top of YARN. That
thread is quite old, and has been inactive for some years. Do you know if
someone has made progress with that?

Thanks,

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

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

Re: [akka-user] Performance of Akka-Http 2.5.4

[Konrad “ktoso” Malawski]

When wanting to discuss any benchmarks, please share actual code as
otherwise it's impossible to comment on what you're actually benchmarking.
Same goes for benchmark setup, you did not explain how the benchmark was
run and what network it was on etc.

We have continuously confirmed same performance as the netty 4 backend in
play apps, as well as beating spray in performance. Also, you're not
comparing apples to apples it fbyou comprare raw netty without any DSLs to
a high level routing API that Akka provides - thus, please share code.

On August 11, 2017 at 22:53:21, Jakub Kahovec (jakub.kaho...@gmail.com)
wrote:

> Hi,
>
> we've done recently a little research regarding the performance of current
> JVM based HTTP servers (and Nginx for comparison)  and as regards the
> results of Akka-Http we were rather unpleasantly surprised.
>
> Here are the presumptions for the benchmark:
>
>- Single handler handling GET /benchmark returns HTTP 200 OK with
>payload benchmark and HTTP headers Date, Server, Content-Type and
>Content-Length.
>- Using mostly default settings, change them only when it's obvious
>that the default settings do not work well in the benchmark.
>- We are interested in the maximum number of requests per second and
>latencies.
>- Three rounds, first is warmup and the rest try to test the
>frameworks under different loads (each test 60 seconds)
>-
>   - Warmup - ./wrk -t38 -c50 -d60s --latency
>   http://benchmark-server/benchmark
>   - Round 1 - ./wrk -t38 -c500 -d60s --latency
>   http://benchmark-server/benchmark
>   - Round 2 - ./wrk -t38 -c1000 -d60s --latency
>   http://benchmark-server/benchmark
>
> Hardware : client and benchmark machines: 40 CPUs (Intel(R) Xeon(R) CPU
> E5-2630L v4 @ 1.80GHz), 64GB of RAM
>
> Results:
>
> Warmup
>
> | metric  | nginx | akka-http | colossus  | finagle   | http4s
>| netty | spring| vertx |
> |---  |---|---|---|---|---
>  |---|---|---|
> | req/s** | 377627.54 | 161957.96 | 341140.06 | 271592.28 |
> 147829.99 | 337583.43 | 149290.22 | 356968.36 |
> | latency avg | 99.18μs   | 656.77μs  | 386.72μs  | 579.93μs  |
> 8.28ms| 336.11μs  | 21.98ms   | 345.04μs  |
> | latency 75th| 98.00μs   | 255.00μs  | 115.00μs  | 149.00μs  |
> 248.00μs  | 131.00μs  | 250.00μs  | 101.00μs  |
> | latency 99th| 149.00μs  | 815.00μs  | 271.00μs  | 820.00μs  |
> 156.60ms  | 198.00μs  | 846.85ms  | 188.00μs  |
> | cpu idle %  | 90| 36| 76| 61| 13
>  | 75| 57| 76|
>
>
> Round 1
>
> | metric  | nginx | akka-http | colossus   | finagle   | 
> http4s
>| netty  | spring| vertx |
> |---  |---|---|--- |---
> |---|--- |---|---|
> | req/s   | 988019.69 | 245979.16 | 1007300.12 | 460936.09 |
> 149288.46 | 1021265.73 | 258088.17 | 990153.39 |
> | latency avg | 642.29μs  | 3.31ms| 831.16μs   | 4.49ms|
> 122.44ms  | 2.12ms | 9.57ms| 1.96ms|
> | latency 75th| 537.00μs  | 2.79ms| 572.00μ
>

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

[Konrad “ktoso” Malawski]

And it is listed under Alpakka projects too :-)
http://developer.lightbend.com/docs/alpakka/current/external-connectors.html#camel


— Konrad


On 12 July 2017 at 15:06:01, 'Martin Krasser' via Akka User List (
akka-user@googlegroups.com) wrote:

Hi Andreas,

the replacement for akka-camel is the Streamz
 project with its Camel DSL for Akka
Streams
.
It allows you to use any Camel component
 with Akka Streams for both
inbound and outbound message exchanges. There is a Scala and Java API.

Best Regards,
Martin

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

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

[Konrad “ktoso” Malawski]

Hi there,
you do realize that UDP, the protocol itself, does not guarantee delivery
of anything?
It absolutely may and will in practice drop packets - it is designed to do
exactly that.

Start reading about UDP here
https://en.wikipedia.org/wiki/User_Datagram_Protocol and take it from there
to networking books and articles.

In short, if you’re suprised that UDP “dropped”, you should likely not be
using UDP at all :-)

— Konrad


On 13 July 2017 at 21:34:17, Madabhattula Rajesh Kumar (mrajaf...@gmail.com)
wrote:

Hi,

I am using Akka Streams to read the messages from UDP port and write into
the filesystem. It is not able to read all messages. Some messages are
dropping.

I have found one example program in the github.

https://github.com/jpthomasset/akka-udp-stream

val source = UdpSource(new InetSocketAddress("127.0.0.1", 9876), 100)
val result = source.map(x =>
x.data.decodeString("UTF-8")).runWith(lineSink(filePath))
import system.dispatcher
result.onComplete { _ => system.terminate() }

def lineSink(filename: String): Sink[String, Future[IOResult]] = {
Flow[String]
  .map(s => ByteString(s + "\n"))
  .toMat(FileIO.toFile(new File(filename)))(Keep.right)
  }

*Do we need to increase the "maxBufferSize" to receive all messages from
UDP?*

Please let me know how to receive all messages?

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

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

Re: [akka-user] Re: withSupervisionStrategy passed a japi Function but compiler complains that its expecting a scala Function1

[Konrad “ktoso” Malawski]

As I replied above, it has been fixed in later versions of Akka - you have
not stated what version you’re using.
Please upgrade to the latest, they’re all binary backwards compatible so
you can bump the Akka version.

— Konrad


On 26 October 2016 at 21:31:29, Konrad Malawski (
konrad.malaw...@lightbend.com) wrote:

Well that's exactly the thing we fixed.
As you've found in the docs.

We'll release a stable this week, please upgrade then.

-- 
Konrad `ktoso` Malawski
Akka <http://akka.io> @ Lightbend <http://lightbend.com>

On 26 October 2016 at 13:29:52, murtuza chhil (chil...@gmail.com) wrote:

Still looking for an answer to this, if anyone can point out whats wrong
and how to get it done.
I was looking at some HTTP docs and there was a fix in there and wonder if
the problem is related

http://doc.akka.io/docs/akka-http/current/java/http/migration-guide/migration-guide-2.4.x-3.0.x.html#akka-http-2-4-11-3-0-0

"The Java DSL for the following directives pathPrefixText,
rawPathPrefixTest, rawPathPrefix, pathSuffix
accidentally used the Scala function type instead of the
java.util.function.Function"

-chhil

On Thursday, October 20, 2016 at 10:33:03 PM UTC+5:30, murtuza chhil wrote:
>
> Having trouble setting up withSupervisionStrategy for the materializer.
>
> I get a compile time error of
>
>   Error:(30, 23) java: no suitable method found for 
> withSupervisionStrategy(akka.japi.function.Function<java.lang.Throwable,akka.actor.SupervisorStrategy.Directive>)
> method 
> akka.stream.ActorMaterializerSettings.withSupervisionStrategy(scala.Function1<java.lang.Throwable,akka.stream.Supervision.Directive>)
>  is not applicable
>   (argument mismatch; 
> akka.japi.function.Function<java.lang.Throwable,akka.actor.SupervisorStrategy.Directive>
>  cannot be converted to 
> scala.Function1<java.lang.Throwable,akka.stream.Supervision.Directive>)
> method 
> akka.stream.ActorMaterializerSettings.withSupervisionStrategy(akka.japi.function.Function<java.lang.Throwable,akka.stream.Supervision.Directive>)
>  is not applicable
>   (argument mismatch; 
> akka.japi.function.Function<java.lang.Throwable,akka.actor.SupervisorStrategy.Directive>
>  cannot be converted to 
> akka.japi.function.Function<java.lang.Throwable,akka.stream.Supervision.Directive>)
>
> It for some reason is confusing the method that would be used for scala
> (expecting a function1).
> How do I get this to compile using java?
>
> import akka.NotUsed;import akka.actor.ActorSystem;import 
> akka.actor.SupervisorStrategy;import akka.japi.function.Function;import 
> akka.stream.ActorAttributes;import akka.stream.ActorMaterializer;import 
> akka.stream.IOResult;import akka.stream.Supervision;import 
> akka.stream.javadsl.*;import akka.util.ByteString;import scala.Function1;
> import java.io.File;import java.util.concurrent.CompletionStage;
> /**
>  * Created by Murtuza on 10/19/2016.
>  */public class EventFilter {
>
> public static void main(String[] args) {
>
> State filteredState = new State("ok");
> ActorSystem system = ActorSystem.create("system");
> ActorMaterializer mat = ActorMaterializer.create(system);
> Function<Throwable,SupervisorStrategy.Directive> decider = thr 
> ->SupervisorStrategy.resume();
>
> mat.settings().withSupervisionStrategy(decider);
>
> }
>
> Below supervisionStrategy expects a Function1 unlike for the mat which
> expects a japi function
>
>
> Flow<String, Event, NotUsed> parse = Flow.of(String.class)
> .map(x -> {
> //System.out.println(LogStreamProcessor.parseLineEx(x).get());
> return LogStreamProcessor.parseLineEx(x).get();
>
> }).withAttributes(ActorAttributes.supervisionStrategy(...));
>
> So I am kinda confused on passing the strategy.
>
> Any help will be greatly appreciated.
>
> -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.

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

Re: [akka-user] Re: Akka Typed and MDC

[Konrad “ktoso” Malawski]

The "power mode” ;-)


On 11 July 2017 at 00:02:12, Justin du coeur (jduco...@gmail.com) wrote:

Oh, sweet -- ExtensibleBehavior looks enormously useful...

On Mon, Jul 10, 2017 at 9:29 AM, Konrad 'ktoso' Malawski <ktos...@gmail.com>
wrote:

> Once I wrote the response I though that for using the library directly
> you'll also want to know about the possibility to implement:
>
>
> /**
>  * Extension point for implementing custom behaviors in addition to the 
> existing
>  * set of behaviors available through the DSLs in 
> [[akka.typed.scaladsl.Actor]] and [[akka.typed.javadsl.Actor]]
>  */
> abstract class ExtensibleBehavior[T] extends Behavior[T] {
>   /**
>* Process an incoming [[Signal]] and return the next behavior. This means
>* that all lifecycle hooks, ReceiveTimeout, Terminated and Failed messages
>* can initiate a behavior change.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveSignal(ctx: ActorContext[T], msg: Signal): Behavior[T]
>
>   /**
>* Process an incoming message and return the next behavior.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveMessage(ctx: ActorContext[T], msg: T): Behavior[T]
>
> }
>
>
> In which way you should be able to "wrap" any other behaviour and to the
> MDC clear in the right place hm...
>
> Anyway, like I said, not a solved problem yet.
>
> -- 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.
>

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

Re: [akka-user] How to download and install newest Akka

[Konrad “ktoso” Malawski]

Akka is just a Scala/Java library, you’d use it like any other Scla/Java
library.
So you could add it as dependency in your maven file, or first learn how to
use sbt: http://www.scala-sbt.org/ and to the same there.

Akka dependencies are listed on http://akka.io/docs/

Happy hakking

— Konrad


On 8 July 2017 at 16:59:30, Eras Rasmuson (eras.rasmu...@gmail.com) wrote:


Ok. I would want to use Akka with Scala and its tools (like sbt), but i am
a novice with Scala.

Is it possible to get Akka from GitHub ?
https://github.com/akka/akka


Eras


lauantai 8. heinäkuuta 2017 0.01.18 UTC+3 Justin du coeur kirjoitti:
>
> I think you're misunderstanding what Akka is -- there's nothing that you
> "download and install", at least not usually.  It's a library, that you use
> in the context of a larger program.  How you link it into that program
> depends on how you're writing that program -- what language and tools you
> are going to be using.  But the download process is generally handled by
> your build tools: it's quite rare to download Akka manually...
>
> On Fri, Jul 7, 2017 at 4:38 PM, Eras Rasmuson  wrote:
>
>> Hi
>>
>> I have not found a clear guidance how to download and install newest
>> (full) version of Akka (to Windows).
>>
>> Could anyone give a hint how to do that ?
>>
>> PS. I have only found:
>> http://dev.lightbend.com/start/?group=akka=akka-quickstart-scala
>>
>> 
>> Eras
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>> current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
"Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

Re: [akka-user] Use of high performance bounded mail box.

[Konrad “ktoso” Malawski]

The current default, more than anything, is bound to be the default since
it was the default since the inception of Akka and going for a bounded one
by default now could make some users unhappy.

Having that said, we're actively looking forward to pick a bounded impl for
Akka Typed. Then people come to it with new expectations and it's easier
for us to justify the change.

We also have looked at a number of such impala, including benchmarks etc
and they're definitely very cool.

So it's not that we don't want to, rather it is a question when we do :)

On July 15, 2017 at 17:33:12, Unmesh Joshi (unmeshjo...@gmail.com) wrote:

> Hi,
>
> We had some custom requirements for building a logging library wrapper for
> our project. The project includes multiple subsystems, each developing
> components which are essentially actors. All modules/actors are supposed to
> be using our logging interface.
> After some research, we found neopersist library (
> https://github.com/nestorpersist/logging) which seems to fit our needs.
> One of the key aspects of this library is the use of LoggingActor which
> handles all the logging events.
> Conceptually, this should perform pretty well, and comparable to log4j
> async appender.
> We ran some performance tests similar to the ones for log4j 2 as described
> here https://logging.apache.org/log4j/2.x/performance.html.
> As we expected, the bottleneck was the unbounded mailbox for Actors. The
> performance tests with jmh were just too slow and throughput was too low
> after a few iterations.
> We changed our mailbox configuration to use  NonBlockingBoundedMailbox,
> and performance then was comparable to AsyncAppender of log4j 2.
> Log4j2 AsyncAppender uses lmax disruptor.
>
> So the question is, why isn't some variant of bounded mail default in akka?
> Was there any thought/discussion happened to use lmax disruptor based mail
> box implementation? and why was it not done?
>
> Thanks,
> Unmesh
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [akka-user] Akka Typed API discussion

[Konrad “ktoso” Malawski]

Hi Bryan,
The forum differs a bit depending on what you want to chat about.

Do you have a few issues to talk about and they’re specific enough (and
potentially could have an actionable outcome I’d assume/hope)? Then
http://github.com/akka/akka would be the best, one ticket per specific
issue, not to get all into the same one :)

We also have http://github.com/akka/akka-meta for more abstract
discussions, ideological etc ;-)

Or here is also find, if it’s one specific thing that you think requires a
lot more discussion before it can be formulated into an more or less
actionable ticket.

Hope this helps.

I’d suggest to keep it here or on issues, from what it sounds; chat is not
as good for deeply pondering an API and well thought out debate, emails or
issues work there a bit better :)

Thanks!

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 18 July 2017 at 15:59:11, Bryan Murphy (br...@murphynet.id.au) wrote:

Where is the best place to discuss the Akka Typed API ?
I am hoping it is still open to change as I have some (reasonably lengthy)
comments and suggestions to make so I want to make sure I give them in the
correct forum.
Is it here, a gitter channel, a github issue or somewhere else ?

Thanks

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

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

[akka-user] Re: Akka Typed and MDC

[Konrad 'ktoso' Malawski]

Akka Typed is still not quite "done" so missing or undecided upon APIs may 
still be here and there.
That's one of them, so I opened a ticket to discuss and decide what to do 
about it in Typed.

https://github.com/akka/akka/issues/23326

Having that said, you can always just directly use the logging library that 
you're using (and in fact this may be what we'll end up recommending with 
Typed... we'll see).

-- Konrad

On Saturday, July 8, 2017 at 4:15:01 AM UTC+9, Qux wrote:
>
> Hi,
>
> Whats the best way to get a DiagnosticActorLogging for Typed Actors?
>
> For untyped Actors we have this:
>
> public abstract class ActorBase extends AbstractActor {
> protected final DiagnosticLoggingAdapter logger = Logging.getLogger(this);
>
>
> @Override
> public void aroundReceive(PartialFunction receive, 
> Object msg) {
> try {
> ActorLoggingHelper.setMdc(msg, logger);
> super.aroundReceive(receive, msg);
> } finally {
> ActorLoggingHelper.clearMdc(logger);
> }
> }
> }
>
>
> Would be great if something similar is possible for the new Typed Actors 
> as well.
>
> Samuel
>

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

[Konrad 'ktoso' Malawski]

Once I wrote the response I though that for using the library directly 
you'll also want to know about the possibility to implement:


/**
 * Extension point for implementing custom behaviors in addition to the existing
 * set of behaviors available through the DSLs in [[akka.typed.scaladsl.Actor]] 
and [[akka.typed.javadsl.Actor]]
 */
abstract class ExtensibleBehavior[T] extends Behavior[T] {
  /**
   * Process an incoming [[Signal]] and return the next behavior. This means
   * that all lifecycle hooks, ReceiveTimeout, Terminated and Failed messages
   * can initiate a behavior change.
   *
   * The returned behavior can in addition to normal behaviors be one of the
   * canned special objects:
   *
   *  * returning `stopped` will terminate this Behavior
   *  * returning `same` designates to reuse the current Behavior
   *  * returning `unhandled` keeps the same Behavior and signals that the 
message was not yet handled
   *
   * Code calling this method should use [[Behavior$]] `canonicalize` to replace
   * the special objects with real Behaviors.
   */
  @throws(classOf[Exception])
  def receiveSignal(ctx: ActorContext[T], msg: Signal): Behavior[T]

  /**
   * Process an incoming message and return the next behavior.
   *
   * The returned behavior can in addition to normal behaviors be one of the
   * canned special objects:
   *
   *  * returning `stopped` will terminate this Behavior
   *  * returning `same` designates to reuse the current Behavior
   *  * returning `unhandled` keeps the same Behavior and signals that the 
message was not yet handled
   *
   * Code calling this method should use [[Behavior$]] `canonicalize` to replace
   * the special objects with real Behaviors.
   */
  @throws(classOf[Exception])
  def receiveMessage(ctx: ActorContext[T], msg: T): Behavior[T]

}


In which way you should be able to "wrap" any other behaviour and to the 
MDC clear in the right place hm...

Anyway, like I said, not a solved problem yet.

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

Re: [akka-user] Akka-Typed MutableBehavior: return type of onMessage

[Konrad “ktoso” Malawski]

Exactly the same.
Becoming an different behavior.

On July 19, 2017 at 0:16:18, Mushtaq Ahmed (mushta...@gmail.com) wrote:

> Actor.immutable returning Behaviour[T] makes sense as it uses recursion to
> return updated state or Actor.stopped etc.
>
> But in MutableBehavior, I end up using this pattern a lot.
>
> override def onMessage(msg: Msg): Behavior[Msg] = {
> msg match {
> case M1 => //unit returning action
> case M2 => //unit returning action
> }
> this
> }
>
>
> Which makes me wonder what use cases are helped by onMessage returning
> Behaviour type (instead of Unit). Any thoughts?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [akka-user] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Konrad “ktoso” Malawski]

Dispatchers are documented
http://doc.akka.io/docs/akka/current/scala/dispatchers.html
ForkJoinPool based.

Stages get fused so it’s a bit more tricky than that.

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 28 July 2017 at 05:49:20, Caoyuan (dcaoy...@gmail.com) wrote:

BTW, Viktor, what's the implementation of the default dispatcher for TCP
IO, Flow/GraphStage? Are there any special dispatchers that are pinned to
fixed thread pool?

On Thu, Jul 27, 2017 at 1:44 PM Caoyuan  wrote:

>
>
> On Thursday, July 27, 2017 at 12:47:39 PM UTC-7, √ wrote:
>>
>> Very consistent. What's the current bottleneck?
>>
>
> Not too much so far. The major decision of ChanaMQ design is that each
> message is an actor and each queue is an actor etc. So the scalability on
> number of CPU cores or cluster nodes should be well. I can see the CPU
> cores usages are balanced very well.
>
> The only issue is the fluctuated of send/receive rate under some cases,
> I'll try to figure out whether the cause is from client side or ChanaMQ
> server side.
>
>
>
>> On Thu, Jul 27, 2017 at 7:52 PM, Caoyuan  wrote:
>>
>>> Below is the latency in ms when applying 1-publishers - 100-consumers:
>>>
>>>
>>>   "max-latency":15.044784,
>>>   "min-latency":13.960142,
>>>   "avg-latency":14.623772,
>>>   "p95-latency":14.830327,
>>>   "p99-latency":14.884950,
>>>
>>> On Monday, July 24, 2017 at 11:30:04 PM UTC-7, √ wrote:

 Cool. What does the p90 and p99 look like?

 --
 Cheers,
 √

 On Jul 25, 2017 12:19 AM, "Caoyuan"  wrote:

> I've got some preliminary benchmarks. As the maximized distributed
> design of ChanaMQ. It's bit lagging behind RabbitMQ when applying a few
> publishers/consumers, but will be on par with RabbitMQ when applying lots
> of publishers/consumers.
>
> Attached are benchmarks on my dual Intel Xeon E5620@2.4GHz
>
> ChanaMQ is designed as a plain Akka sharding cluster, so it should
> scale out well, although I do not yet take a serious test on it.
>
> --
> Cheers
> Caoyuan Deng
>
> On Monday, July 24, 2017 at 12:36:27 AM UTC-7, √ wrote:
>>
>> Cool! What kind of scalability profile are you getting?
>>
>> On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:
>>
>>> Hi,
>>>
>>> We are developing an AMQP messaging broker - ChanaMQ, which is based
>>> on Akka actors and Akka streaming.
>>>
>>> It's currently under Alpha phase, but with lots of AMQP 0-9-1
>>> features implemented, including ack, persistent (Cassandra only so far) 
>>> etc.
>>>
>>> Methods/Features are not supported yet:
>>>
>>>- Connection.SecureOk
>>>- Channel.Flow
>>>- Exchange.Bind / Exchange.Unbind
>>>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>>>- Access.Request
>>>- Tx.Select / Tx.Commit / Tx.Rollback
>>>- Confirm.Select
>>>- ...
>>>
>>> For more information, please visit:
>>>
>>> https://github.com/qingmang-team/chanamq
>>>
>>> Regards,
>>>
>>> Caoyuan Deng
>>> Qingmang  - Your magazine on mobile
>>> Twitter: @dcaoyuan
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>>