Done: https://github.com/akka/akka/issues/16104
I will look into creating a fix for it.
Cheers,
Jeroen
Op zaterdag 18 oktober 2014 16:55:50 UTC+2 schreef Patrik Nordwall:
Hi Jeroen,
Sounds like a bug to me. Please create a github issue. Thanks for the
sample. If you know how to fix it a
Hi Richard,
I don't know from where the resolve of unknown path originates. I would
guess it is something from deserialization.
It is logged at debug level. Is the result still correct?
Are you using Akka 2.3.6?
Regards,
Patrik
On Sat, Oct 18, 2014 at 8:58 PM, Richard Rodseth
On Mon, Oct 13, 2014 at 9:11 PM, Behrad behr...@gmail.com wrote:
Thank you Martynas,
2014-10-13 16:30 GMT+03:30 Martynas Mickevičius
martynas.mickevic...@typesafe.com:
Hi Behrad,
On Sat, Oct 11, 2014 at 10:12 PM, Behrad Zari behr...@gmail.com wrote:
I want to dispatch messages
Hi Mani,
I don't know what can cause this. Do you see the same thing if you schedule
less jobs, like 100 instead of 3?
The worker actor in the sample is only accepting one job at a time, so if
the execution time is about the same for each job you should see roughly
same number of jobs
Hi Prakhyat,
I can't comment on ahjohannessen proposal, but in general it is difficult
to create a view that aggregates the event streams of many persistent actor
instances, and it is also difficult to create a persistent view for each
persistent actor when you don't know the identifiers up
Hi Vadim,
How do you poll the shard region?
Do you have a small sample that we can use to reproduce the problem?
/Patrik
On Fri, Oct 17, 2014 at 10:15 PM, haghard haghar...@gmail.com wrote:
Hi Konrad
Sorry for missing context, now I'll try to give it to you
I have a cluster with two types
I had a hunch about this one that the sending-out may be racy, such that
the singleton has migrated but sharding didn't yet notice the problem...
Just a hunch though, didn't investigate completely if this could happen.
Wouldn't retrying to send this initial count people message make sense
anyway
HI Endre,
sorry for my late feedback, I was ill last week..
I followed your suggestions (and many others also, see my email from
10.Okt), but neither of them works, sorry.. heartbeat messages are not
processed with my-cluster-dispatcher.. At the end I tried with this
Hi Patrik,
Thanks for your inputs.
Views will be updated. Can we get a look on the design of how view will be
implemented in future?
Is there any possibility the current class akka.persistence.PersistentView
will be renamed or removed. I am asking from the perspective of migration.
What will
Hey everyone,
I've recently needed a retry mechanism for failed messages and after a
bit of searching I've noticed that the recommended way would be to spawn
a new child actor for each message that needs to be retried, restart it
through supervision and have the child actor reschedule, in
Hello Akka-team,
I ran into a problem this morning using akka-stream_2.10.0.7 with Scala
version 2.10.3.
When I try to receive multiple files at a time, some randoms exception are
thrown within the classloader. After two successive tries, everything is
fine.
I attached one of the stacktrace.
Hi Hamid,
Your configuration looks correct. I think you are fooled by the SLF4J
logging. The thread you see in the log is not the thread of the actor that
emitted the log event. You must use the %X{akkaSource} variable in the
logging pattern to see that. See:
On Mon, Oct 20, 2014 at 2:03 PM, Prakhyat Mallikarjun prakhyat...@gmail.com
wrote:
Hi Patrik,
Thanks for your inputs.
Views will be updated. Can we get a look on the design of how view will be
implemented in future?
There is nothing more than the famous Akka Persistence on the Query
Thanks for reporting. You can follow the progress of this issue here
https://github.com/akka/akka/issues/16109 and here
https://github.com/scala-graph/scala-graph/issues/21.
/Patrik
On Mon, Oct 20, 2014 at 5:26 PM, Xavier Bucchiotty xbucchio...@xebia.fr
wrote:
Hello Akka-team,
I ran into a
Thanks Rafal!
--net=host worked just fine. The links you provided are great and
informative :)
On Wednesday, October 15, 2014 12:41:03 AM UTC+3, Rafał Krzewski wrote:
The problem arises because the IP where actor system binds itself and the
IP where the messages actually arrives from the
Hello,
Is it possible to define a base class for actors that will provide some
default behaviors? For example I create a MyAbstractActor that handles
MyMessage type. Someone on my team can then extend that class and handle
some other types as well. Somewhat like AbstractPersistentActor handles
Hi Konrad,
Thanks so much for your reply! I might need to clarify a little more here.
The time when I said I removed the akka.actor.deployment section out of
the akka.actor path, everything else stopped working, because my router
actors were configured in that section. Also it was not clear
One easy way is to extend UntypedActor, override whatever methods you need
with final methods and provide your own callback methods for overriding by
sub classes.
The slightly messy part of this is that you’ll be forced to provide
callback method names with different names (e.g.
18 matches
Mail list logo