Hi,
I trying akka-http (version 10.x) by creating a small API who generate UUID
on demand. For a bulk UUID creation (ex: */uuid1/5000* to get 5000 UUID
v1), I would like to return a chunked response to avoir building a list of
item on memory.
>From Play 2.5 I usually using final Source so
Hi Thibault,
I do this kind of thing with Source.fromIterator(...) passing it an
iterator obtained from a java stream.
In your case, it would look something like:
Source source = Source.fromIterator( () ->
Stream.generate( ()->
UUID.randomUUID()
).iterator()
).take(n);
th
Hi Thibault,
if you have the body of the response already as a Source,
you can create a response with a chunked entity from it like this:
HttpResponse.create()
.withEntity(HttpEntities.create(contentType, source))
Johannes
On Thursday, April 20, 2017 at 9:56:47 AM UTC+2, Thibault Meyer wrote
Hi,
thanks for your response. It working very well !
Le jeudi 20 avril 2017 12:02:53 UTC+2, Johannes Rudolph a écrit :
>
> Hi Thibault,
>
> if you have the body of the response already as a Source,
> you can create a response with a chunked entity from it like this:
>
> HttpResponse.create()
That is a simple and good solution. If the entity ids are known you can do
the heartbeating from an actor running on each node, or from a Cluster
Singleton, instead of from the clients.
I know something similar is used in Lagom for keeping the read side
processors alive.
/Patrik
ons 19 apr. 2017
Thanks for your responses. It working very well !
Le jeudi 20 avril 2017 12:02:53 UTC+2, Johannes Rudolph a écrit :
>
> Hi Thibault,
>
> if you have the body of the response already as a Source,
> you can create a response with a chunked entity from it like this:
>
> HttpResponse.create()
> .wi
Thanks, Patrik. The server-side approach is a neat alternative.
Cheers,
Andrew
On Thursday, 20 April 2017 12:50:40 UTC+1, Patrik Nordwall wrote:
>
> That is a simple and good solution. If the entity ids are known you can do
> the heartbeating from an actor running on each node, or from a Cluster
I agree - if you control the client then a client-side heartbeat is a good
approach. I haven't had quite that requirement for the actors to always be
instantiated but I have had a couple semi-related requirements.
In one case we basically did the same heartbeat on the server side (we had
a poo
Hi Guys,
I have been working for a replacement to the deprecated PersistentView. At
the moment for the newcomers is very complex to build a view that wants to
replay messages from different persistence ids. I have written a library
that allows creating a view that is not bound to a specific pers