Thanks for looking into this Johan!
On Friday, March 11, 2016 at 1:49:38 AM UTC+11, Akka Team wrote:
>
> After looking closer at this, the reason is that when the Source
> completes, the socket gets closed and this is because websockets do not
> really support half-closed mode, where only one di
I've got a scheduler test that seems to reproduce what I'm seeing in my
application. On my Macbook I was unable to place the test inside
LightArrayRevolverSchedulerSpec because the total test time went over 60s
and triggered all sorts of alarms and what not. So I just created a new
spec class a
A pretty common thing I've to do is to call a (non-blocking, brief)
callback in the event of an overflow. Usually to send a quick message to
the logger.
Here's how I normally solve the problem:
val (input, completed) = Source.actorRef[Int](0,
OverflowStrategy.dropNew).
conflate { (prior,
This is the latest version of akka for java 7.
On Friday, April 29, 2016 at 3:18:55 PM UTC-4, Patrik Nordwall wrote:
>
> There can be several reasons, but a good start is to use latest Akka
> version.
> tors 28 apr. 2016 kl. 21:13 skrev Guido Medina >:
>
>> Hi Ben,
>>
>> As my experience goes N
There can be several reasons, but a good start is to use latest Akka
version.
tors 28 apr. 2016 kl. 21:13 skrev Guido Medina :
> Hi Ben,
>
> As my experience goes Netty 3 doesn't get much love, issues are barely
> fixed,
> like I mentioned before I'm running my own Netty 3.10.6 built internally,
>
So it's this code we are talking about:
def enqueue(receiver: ActorRef, handle: Envelope): Unit =
if (pushTimeOut.length >= 0) {
if (!queue.offer(handle, pushTimeOut.length, pushTimeOut.unit))
receiver.asInstanceOf[InternalActorRef].provider.deadLetters.tell(
DeadL
Patric,
The problem was gone if I send lots of messages.
Thanks,
Yan
On Thursday, April 28, 2016 at 5:21:11 AM UTC-5, Patrik Nordwall wrote:
>
> what does your persistent actor look like?
>
> On Mon, Apr 25, 2016 at 7:23 PM, Yan Pei >
> wrote:
>
>> Got another issue.
>>
>> The logic is very
Thanks Patrik.
So you agree that setting timeout to 0 will block the sender when using a
local receiver? Do you think I should contribute an update to the
documentation?
The code I'm working on has inherited Akka because it's based on another
application, but my code is a Kafka consumer. So it
Hi,
I'm trying to create an UntupedActorWithStash in java, and for my use case
I need to use a UnboundedPriorityMailbox. I have created my actor to extend
UntypedActorWithUnrestrictedStash and implementing
RequiresMessageQueue, I also create
my actor with a dispatcher which has the PriorityMai
Thanks for the suggestion Guido. I had already looked at the Docker
documentation for Akka remote configuration, but unfortunately it doesn't
answer my question.
I should clarify at this point that although I was using Docker when I
first noticed the behaviour in question, I then replicated it
Hi everyone
I am a PhD student researching on self-healing system. Does anyone know
some existing Akka applications that are fault tolerant and self-healing ?
Self-healing means the system can detect, isolate and recover faults within
the system.
Thanks.
--
>> Read the docs:
Did you look at the Docker documentation for Akka remote configuration?
http://doc.akka.io/docs/akka/current/java/remoting.html#Akka_behind_NAT_or_in_a_Docker_container
HTH,
Guido.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka
Blocking the sender is a bad for scalability and can even result in
deadlocks or starvation if you aren't careful. It's also not location
transparent, i.e. it will not work for remote receiver.
If you can't loose messages you should implement a resend-ack protocol for
at least once delivery, or ma
Hi,
We're using akka-streams to process a stream of messages, which result in
some actions.
Now, we need to find the number of messages being processed by the stream
(well, not that plain vanilla, actually each message has a set of
attributes, say, m_type, m_cmp, m_origin, ...).
One solution w
14 matches
Mail list logo
