Hi guys; I'm sorry for replying to this old thread but I'm curious about
this.
I was the same problem (CLOSE_WAIT connections); I searched and found this
(old) thread; but the solution is weird, and not possible for my case, then
I searched and found another/better (in my opinion) solution: I
Sounds like you need to ping the maintainers of akka-persistence-inmemory
/Patrik
On Wed, Nov 16, 2016 at 2:13 AM, Richard Rodseth wrote:
> We are seeing some baffling behaviour in a unit test (using
> akka-persistence-inmemory).
>
> The test starts actor A and actor B
+1 to what Justin said, read more here
http://doc.akka.io/docs/akka/2.4/scala/cluster-usage.html#Downing
On Wed, Nov 16, 2016 at 2:24 PM, Justin du coeur wrote:
> On Wed, Nov 16, 2016 at 7:33 AM, Chinmay Raval
> wrote:
>
>> As Guido Medina suggested,
Viktor,
Here's what I came up with:
https://gist.github.com/julianhowarth/7287a6e6eaf665dd79307aaff6164cd8
Performance-wise, with some very casual testing I can't detect much, if
any, overhead over the original. Checked with both the vanilla case where
each inbound messaga corresponds to one
In case anyone comes across the same problem the correct answer is that the
uuid:signature portion needs to be base64 encoded as a whole to be
compliant.
On Wednesday, November 16, 2016 at 11:51:59 AM UTC-8, jpste...@skydance.com
wrote:
>
> Hi,
>
> I am using akka-http in which I have
Hi there,
Read the docs on stopping actors please:
http://doc.akka.io/docs/akka/snapshot/scala/actors.html#Stopping_actors
E.g. it'd be context.stop(self) inside the actor.
The order in which you shut things down also does not really make much
sense:
- you shut down the entire actor system,
- but