Hey Akka Stream'ers,
Is there a simple way to await the completion of stream?
If I have a source that is not yet connected, I can pipe it throw a
Sink.fold() to materialize it to Future. This allows me to wait
for the stream to complete. But what if I already have a sink and it
doesn't materia
I have this basic client test. It works way better in 2.4.2-RC2 than ever
before, however I still get an error during cleanup:
[akka.actor.ActorSystemImpl(HttpClient)] Outgoing request stream error (akka
.stream.AbruptTerminationException)
Seems like there's a akka-http/streams bug here, or a u
Sorry, I guess the question doesn't make sense since I'm dealing with a
stream of paths rather than one. I can certainly create a composite source
as follows.
def intervalLinesForPath(path: Path): Source[String, Future[Long]] = {
val file = path.toFile
val fileSource: Source[ByteStri
+1 here as well. I've been waiting in anger for akka-http to catch up to
spray in terms of performance and have verified some great leaps in recent
builds. Thanks guys! If there really is a 6-7x speedup waiting to fall
into place (after bug fixing), that would be amazing (and worth the wait).
I'm trying to capture a file read in a reusable Flow as follows. But I'm
scratching my head about how to capture the materialized value. As it
stands the signature of result is Flow[Path, String, Unit] rather than
Flow[Path, String, Future[Long]]. I've tried various combinations of viaMat
and mapMa
That is correct. You must start the manager on every node.
/Patrik
mån 8 feb. 2016 kl. 19:21 skrev :
> Ok.. long story short it works. I didn't know you had to run the
> following ClusterSingletonManager actor creation/definition code on every
> node in the cluster. I thought running that on only
Ok.. long story short it works. I didn't know you had to run the
following ClusterSingletonManager actor creation/definition code on every
node in the cluster. I thought running that on only one node would be
sufficient and it would take care of being able to move that clustered
actor around ok
Ok, my bad it works the first time the singleton is started up, but when
that node fails/stops (the node running the singleton actor that supervises
many children (that the cluster singleton proxies talk to), then it fails
to be re-created again on the cluster w/ its children
a) startup cluster
I owe Endre a response about the documentation.
It's good.
One thing that might help would be if the section on operator fusion
described both .withAttributes(asyncBoundary) and x.viaAsync() with more
diagrams like the one shown, perhaps also including a groupBy for good
measure.
If I understand
Tried that, all i get from the proxy client side is this repeated over and
over
[ClusterSingletonProxy] Trying to identify singleton at
[akka.tcp://coredata-default@192.168.0.208:2552/user/MY_CLUSTERED_SINGLETON
/singleton/ITS_CHILD]
On Monday, February 8, 2016 at 12:46:37 AM UTC-7, Patrik
Sorry, I skimmed your question a little too quickly.
If you want to have a one to one with clients and actors, there is no
built in abstraction that makes it super easy, but it is possible using
Source.actorRef and Sink.actorRef. Here is an example which
is Scala but should point you in the right
thanks for a prompt response.
client is great, but i need server side implementation. and as i see, new
server side docs still show the same basic request-response example.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/
Hi,
We have recently merged shiny new docs for the websocket client API,
they will be in the next release. If you are in a hurry you can find them
in master here:
https://github.com/akka/akka/blob/master/akka-docs/rst/java/http/client-side/websocket-support.rst
https://github.com/akka/akka/blob/m
hi hackers,
i am looking for a *java* api based solution for websocket push
functionality. clients will create websocket connections and server will
push them messages periodically.
as far as i understand it, i was planning to create an actor for each
socket created, so that messages sent to
I created the issue, thanks!
https://github.com/akka/akka/issues/19713
>
>
--
>> 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/gro
It might or might not be a problem. I am just pointing out the effects of
buffer. There are at lest three different approaches possible here:
- no buffers at all, keep the pipeline fused: polling only happens on
need, and always returns fresh data:
poller.throttle.mapConcat(identity)
- want pr
How is that a problem? OP only wanted to make sure that the external system
wasn't polled too often.
On Mon, Feb 8, 2016 at 12:20 PM, Endre Varga
wrote:
> Ah, you meant Backpressure. But then what I originally said is true. Just
> think about it:
>
> - buffer requests
> - buffer is enough to c
Ah, you meant Backpressure. But then what I originally said is true. Just
think about it:
- buffer requests
- buffer is enough to contain the next batch emitted by mapConcat
- buffer hence stores some result
- downstream now asks for next batch, but 3 hours later
- emitted result is now 3 hou
What? How would anything be dropped if buffer has Backpressure as
OverflowStrategy?
On Mon, Feb 8, 2016 at 11:56 AM, Endre Varga
wrote:
>
>
> On Mon, Feb 8, 2016 at 11:53 AM, Viktor Klang
> wrote:
>
>> If the Buffer has Backpressure as overflow strategy I don't see how it
>> decouples upstream
On Mon, Feb 8, 2016 at 11:53 AM, Viktor Klang
wrote:
> If the Buffer has Backpressure as overflow strategy I don't see how it
> decouples upstream from downstream.
>
That is a dangerous move though, since you put the buffer *after* the
mapConcat, so this means that dropping will be independent o
If the Buffer has Backpressure as overflow strategy I don't see how it
decouples upstream from downstream.
On Mon, Feb 8, 2016 at 11:52 AM, Endre Varga
wrote:
>
>
> On Sun, Feb 7, 2016 at 9:49 PM, Viktor Klang
> wrote:
>
>>
>>
>> On Sun, Feb 7, 2016 at 2:17 PM, wrote:
>>
>>> Hi Victor,
>>> tha
On Sun, Feb 7, 2016 at 9:49 PM, Viktor Klang wrote:
>
>
> On Sun, Feb 7, 2016 at 2:17 PM, wrote:
>
>> Hi Victor,
>> thank you for your reply and here are my remarks :
>>
>> Point 1. You have a source of "events" and the only way you know if there
>> are any events, is if you ask for events
>>
>>
Hi,
On Fri, Feb 5, 2016 at 4:05 PM, Hao Ren wrote:
> Hi Endre,
>
> Thank you for the clarification.
>
> The version of akka http is v2.0.3:
> http://mvnrepository.com/artifact/com.typesafe.akka/akka-http-experimental_2.10
> I know it's a quite old version. We have to use it since our stack is
Hi Endre,
Thank you for the clarification.
The version of akka http is
v2.0.3:
http://mvnrepository.com/artifact/com.typesafe.akka/akka-http-experimental_2.10
I know it's a quite old version. We have to use it since our stack is based
on scala 2.10.
I have tried to create a project which is in
Hello,
I've run into an issue that unless a cluster aware router is
(programmatically) created immediately after application startup, it never
gets any routees.
In my scenario, I had an actor, which created a router when it received
some kind of init message. All the messages sent to that rou
25 matches
Mail list logo
