Hi there,
I am just a newbie on Akka, but as far as I know, you have to expect to not
recive a new call to onPull until you push something. So you need an
external "agent" to wake up your GraphStage. One option is to use a timer
that each time it is executed, it queries the database and, if som
On Thu, Sep 8, 2016 at 12:42 AM, wrote:
> On Wednesday, September 7, 2016 at 3:16:57 PM UTC-7, Guido Medina wrote:
>>
>> By induction you can conclude that messages order is guaranteed when
>> sending sequentially (in the same thread) by using the following assertions:
>>
>>- Messages sent to
Hi Guys:
Are you still working on the GPU support for Akka?
I think it will be very useful if Akka can support GPU computing now. We
can see how hot the deep learning is recently and it also shows that GPU
indeed outperforms CPU in terms of these kind of simple but massive
computing for the
I am reading an HTTP Response stream from a URL. The response runForeach
returns a stream of small chunks. I want to increase the chunk size.
I have an application.conf file where I experimented with the following
(increasing default values), but nothing changed. Wasn't sure which config
par
Can anyone help me with this please?
I have the following in my route:
val result = (requestHandler ?
RequestHandler.AskForStatus).mapTo[PimpedResult[(StatusCode,
Result[StatusDTO])]]
onSuccess(result) {
case _ => complete(result)
}
The mapTo is really just to assist my debugging. The result c
On Wednesday, September 7, 2016 at 3:16:57 PM UTC-7, Guido Medina wrote:
>
> By induction you can conclude that messages order is guaranteed when
> sending sequentially (in the same thread) by using the following assertions:
>
>- Messages sent to any local actor go immediately to their destina
By induction you can conclude that messages order is guaranteed when
sending sequentially (in the same thread) by using the following assertions:
- Messages sent to any local actor go immediately to their destination
inbox hence order is preserved because of sequential execution - JMM rule
On Wed, Sep 7, 2016 at 3:47 PM, Patrik Nordwall
wrote:
> The documentation is talking about actor pairs, because you normally send
> messages from an actor. In this example you don't send them from an actor,
> but that doesn't matter. The tell methods are called in a specific order
> since you in
On Wed, Sep 7, 2016 at 7:51 PM, wrote:
> Sorry for not understanding yet. The message ordering link cited earlier
> seems to me to be suggesting that ultimately programs in general can only
> have reliable message passing by having business logic that deals with it.
> The section from that link s
+1 Guido.
We use Kafka for this purpose.
On Wednesday, September 7, 2016 at 5:34:09 AM UTC-6, Guido Medina wrote:
>
> Short answer is no, no, no, you need to interconnect the DCs using some
> recoverable mechanism otherwise your cluster will suffer.
> In other words, don't form Akka clusters amo
On Wed, Sep 7, 2016 at 2:15 PM, Aristoula Goulia
wrote:
> So I have a RepositoryWorker(for now it is only one) and one supervisor
> that watches the one worker.
> 1.In my current implementation all the requests (retrieve,store) pass fom
> the supervisor and the supervisor propagates the requests
I am new to akka and just looking at the supervisor and strategies and
trying to get my head around on how to apply this on my RepositoryActor.
Basically I am looking for areas of improvement in my current
implementation since I have minimal experience.
So I have a RepositoryWorker(for now it is
Sorry for not understanding yet. The message ordering link cited earlier
seems to me to be suggesting that ultimately programs in general can only
have reliable message passing by having business logic that deals with it.
The section from that link says:
*for a given pair of actors, messages se
Artery is at in milestone 3 (m3), you are welcome to use as I believe it
is in an extremely good shape but I would pursue both,
as it will only require you a day of work (as a newbie) in configuration
and dependencies, no code changes will be required:
http://search.maven.org/#artifactdetails%7
IMO Artery won't help much if using Java Serialization.
Java Serialization is notoriously slow.
On Wed, Sep 7, 2016 at 5:50 PM, Guido Medina wrote:
> Artery is at in milestone 3 (m3), you are welcome to use as I believe it
> is in an extremely good shape but I would pursue both,
> as it will on
Dear Guido,
Thanks a lot for you answer.
We have already improved our concurrency model, using multiple instances
for each actor, that now work in parallel using multiple dispatcher.
Now we have not so much time to release our product to the client.
What do you suggest to focus our efforts on?
Hi Guys,
Is there somewhere an example of stateful BidiFlow ?
--
>> 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
-
I think the line that might cause confusion here is
inbox.send(greeter, new Greet());
The inbox can be seen as a "mediator" and therefore perceived as it might
not preserve ordering. For this reason I would prefer to write it as:
greeter.tell(new Greet(), inbox.getRef());
That is exactly how in
Hi Dagny,
The Akka Streams tests for the built in stages could perhaps be useful to
see various strategies for testing. You can find those sources here:
https://github.com/akka/akka/tree/master/akka-stream-tests/src/test/scala/akka/stream/scaladsl
--
Johan
Akka Team
On Fri, Sep 2, 2016 at 8:08 P
Hi Victor,
As far as I can see there is no way to guarantee that you will know if a
message was discarded in the process step in any other way than writing
your own custom stage.
You could for example create a stage that will record incoming messages
before sending to process, and then also plug
Short answer is no, no, no, you need to interconnect the DCs using some
recoverable mechanism otherwise your cluster will suffer.
In other words, don't form Akka clusters among multiple DCs.
HTH,
Guido.
On Wednesday, September 7, 2016 at 12:27:54 PM UTC+1, Guy Sela wrote:
>
> Hi,
>
> I saw this
Hmm, as an example, look at end of it and try to share a mutable message.
Create a message with an ArrayList and send it to several actors,
then try to modify and iterate over such list and you will probably
(eventually) get a concurrent modification exception.
That's one example I can think of,
Hi Carmen,
The following might not have a specific example but will probably help you
seeing in details the design concepts behind Akka combined with the Java
Memory Model,
most of the aspects you have mentioned are avoided but maybe there is a way
to reproduce one or two by contradicting the a
Hi,
I saw this question about AKKA across data
centers: https://groups.google.com/forum/m/#!topic/akka-user/rMq-jP2O4j0
Since this question is from 2011, I wanted to know if there are any updates
about it.
I'm considering using AKKA's distributed-pub-sub across multi-geographical
sites.
http:/
Messages can be slow when being sent remotely from node A to node B,
current Akka remote will give you a top of 100k msg/sec best scenario and
that depending on the message size,
there is a new Akka remote (Akka artery which is a rewrite of Akka remote)
on the way so that shouldn't discourage you
In the introduction chapter of Akka this is explained in details, how Akka
takes care of it,
I suggest you go there to learn the exact details:
http://doc.akka.io/docs/akka/2.4.10/general/message-delivery-reliability.html#Discussion__Message_Ordering
HTH,
Guido.
On Tuesday, September 6, 2016
Hi,
We have a GraphStage[SourceShape[?]] with a simple OutHandler which does
the following:
1. Finds a document in MongoDB
2. Pushes that document to the outlet using push()
It's possible that the source will not find any documents in the DB at a
given moment, but new documents may be ar
Hi,
You can also try Akka Kryo serialization extension, it has proven to be
very efficient so far so you don't have to write your own serialization.
Kryo offers you automatic, manual (by you listing explicitly) registration
of the classes and both.
It is a very matured extension and its backed
Dear hAkkers,
We—the Akka committers—are pleased to be able to announce the availability
of Akka 2.4.10. This is mostly a bugfix release with a couple of new
features. Most notable changes are:
- An addition of MergeHub and BroadcastHub which enables dynamic fan-in
and fan-out streams. Find
29 matches
Mail list logo
