That's great! I changed it to def and it works. lazy val might be better.
Thanks a lot.
On Friday, December 18, 2015 at 3:39:21 AM UTC-6, Patrik Nordwall wrote:
>
> That might be an issue with startup ordering. Try to make it lazy.
>
> You can configure another serializer for akka.actor.ActorRef,
I think your emitFeedback() method should look like this:
def emitFeedback(): Unit = {
grab(feedback) match {
case Some(e) => {
feedbackEmitting += 1
flowingCount += 1
emit(out,
Posted a question on SO:
http://stackoverflow.com/questions/34363966/testing-akka-typed-behavior
On Friday, December 18, 2015 at 12:53:51 PM UTC-5, Andriy Drozdyuk wrote:
>
> How would I test that a given behavior sends the messages I expect?
>
> Say, three messages of some type, one after the ot
Can I use the TestProbe from regular Akka?
http://doc.akka.io/api/akka/current/index.html#akka.testkit.TestProbe
Maybe I can write my own...
On Friday, December 18, 2015 at 12:53:51 PM UTC-5, Andriy Drozdyuk wrote:
>
> How would I test that a given behavior sends the messages I expect?
>
> Say,
I've been working on some relatively complicated Akka streams flows, large
enough to make more sense when composed, and I've been a bit frustrated as
to how to do localized error handling, as the current mechanism is attached
to materialization. I'd post code, but I don't have approval for open
How would I test that a given behavior sends the messages I expect?
Say, three messages of some type, one after the other... Is there something
like expectMsg... but synchronous maybe?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.a
> The only Actor that can supervise another Actor must be the one that has
created it, anything else would be rather pointless because only the parent
can react to the termination of its child Actor by re-creating it.
I wasn't suggesting that something other than a parent supervising the
child.
Or use a negative value for without limit ;)
On Fri, Dec 18, 2015 at 3:25 PM, Konrad Malawski <
konrad.malaw...@typesafe.com> wrote:
> Yeah, you can use .withSizeLimit(Long.MaxValue), which is pretty much
> infinite in this context,
> It's around 9223 petabytes, pumping so much in a single http c
Yeah, you can use .withSizeLimit(Long.MaxValue), which is pretty much infinite
in this context,
It's around 9223 petabytes, pumping so much in a single http connection is
rather unlikely :-)
It could be made simpler I guess though withNoLimit hm... Would you open a
ticket on github about it ple
BTW is there a way to set infinite on a specific entity? I set put this in
my application conf "max-content-length = infinite", but it seems
reasonable to do this only for the entities where it makes sense.
WithSizeLimit takes a long and although I could use Long.MaxValue, it
doesn't state infi
Hi Konrad,
thanks for you answer. This explains a lot and makes sense. Configuring
'infinite' fixes my issue. The new error description makes it a lot easier.
One thing I do notice is that the CPU keeps running high whenever I kill
'curl'. Is there something I should do to close the stream? Sus
It's a feature. (yes, really) :-)
Allow me to explain; Akka HTTP always opts on the safe side of things.
For example, if you write an endpoint that can get POST data, and someone (an
attacker) sends you data and it never ends sending...
You do want to kill that connection as soon as you notice so
Same code with akka-streams 1.0 works fine.
Is this a bug?
Regards,
Jeroen
Op donderdag 17 december 2015 22:16:17 UTC+1 schreef Jeroen Gordijn:
>
> Hi all,
>
> I'm running into an EntityStreamSizeException when streaming data from a
> streaming response I got by calling another endpoint.. It is
Thanks for your reply, Patrik!
We use a setup with auto-down after 10 seconds, so I think that is not
possible. I will do the test again, however, and watch out for any
warnings when the nodes goes down (leaves the cluster).
Anders
On 18 December 2015 at 10:55, Patrik Nordwall wrote:
> Sounds s
Sounds strange. Were the members removed correctly after the rolling
restart? No dangling unreachable?
/Patrik
On Tue, Dec 15, 2015 at 11:32 AM, Anders Båtstrand
wrote:
> Dear group
>
> We are using Akka 2.3.14 (unable to use Java 8 for now), and sometime when
> we do a rolling restart in our c
You must save a snapshot before deleting otherwise the delivery ids will be
messed up.
Support for snapshots is provided by getDeliverySnapshot and
setDeliverySnapshot. The AtLeastOnceDeliverySnapshot contains the full
delivery state, including unconfirmed messages. If you need a custom
snapshot f
Hi Henry,
> 18 dec 2015 kl. 07:29 skrev Henry Mai :
>
> > User can install supervision that catch and for example resume, which can
> > result in that the in-memory state is different from what is actually
> > stored.
>
> Sure, the user can catch all Throwables, but my statement was that it do
That might be an issue with startup ordering. Try to make it lazy.
You can configure another serializer for akka.actor.ActorRef, e.g.
akka.actor.serialization-bindings {
"akka.actor.ActorRef" = java
}
/Patrik
On Thu, Dec 17, 2015 at 6:54 PM, wrote:
As a related question: is it possible to
Hi Andriy,
yes, it would be cool to be able to spend some more time on Akka Typed, but
Streams & HTTP still have priority.
To answer your question: Behaviors are just that, behaviors. You can compose
them, transform them, etc. and none of these actions make them into Actors. The
only call that
19 matches
Mail list logo
