Patrik,
Any suggestions towards implementing the flow control in remote connections?
Regards,
Vishnu
On Friday, 19 June 2015 11:47:14 UTC+5:30, Vishnu Sharavan Nag wrote:
>
> Thanks Patrik. I'll look into it.
>
> On Wednesday, 17 June 2015 17:51:56 UTC+5:30, Patrik Nordwall wrote:
>>
>> I would
Patrik,
Thanks for investigating! You saved me a few hours off my Monday as I
was going to go through this in detail and put together a minimal test
case :-)
Unfortunately, your conclusion seems to be pretty damning. It might just
be this one turbofilter that is incompatible with akka, but its li
You could try searching on GitHub.
For example, here is a search for projects with "Akka" in the description,
ordered by "number of
stars":
https://github.com/search?o=desc&q=akka+in%3Adescription&s=stars&type=Repositories&utf8=%E2%9C%93
(See https://help.github.com/articles/searching-repositori
I think one of the keys here is that the materialized value (the
Future[Long] in this case) is not an element, per se, so it won't get
streamed inline.
In other words, don't expect to do a broadcast/zip to get the materialized
values.
You'll need to capture the materialized value when the stream
All the method of the services uses it expect for one :)
On Sun, Jun 21, 2015 at 3:36 AM Roland Kuhn wrote:
> If the ActorSystem is not needed for the initialization of the service
> then why do you pass it in the constructor? You could just pass it into
> those methods that need it instead. Or
On Sun, Jun 21, 2015 at 4:04 PM, Sam Halliday
wrote:
> Everything is DEBUG, and this is akka 2.3.11.
>
ok
We log these (and all other things) with
Logger(logClass, logSource).debug("{}", message.asInstanceOf[AnyRef])
"{}" is the part that the duplicate filter will use to identify the log
messa
Everything is DEBUG, and this is akka 2.3.11.
On Sunday, 21 June 2015 15:03:48 UTC+1, Patrik Nordwall wrote:
>
> What akka.loglevel are you using?
>
> I guess that you see the changed behavior in 2.4-M1 compared to 2.3.11.
>
> In 2.4 we have added a check in LoggingReceive that it will only be act
What akka.loglevel are you using?
I guess that you see the changed behavior in 2.4-M1 compared to 2.3.11.
In 2.4 we have added a check in LoggingReceive that it will only be active
if the loglevel is DEBUG.
if (context.system.eventStream.logLevel >= Logging.DebugLevel) {
/Patrik
On Thu, Jun 1
Thanks Konrad!
Creating such small apps is also my plan but I fear that it might not be as
objective as I want. That is why I want to test some existing application.
Cheers,
Krzysztof
W dniu sobota, 20 czerwca 2015 19:45:31 UTC+2 użytkownik Konrad Malawski
napisał:
>
> Hej Krzysiek,
> Wouldn't
If the ActorSystem is not needed for the initialization of the service then why
do you pass it in the constructor? You could just pass it into those methods
that need it instead. Or split up the service into two parts along this line.
Regards,
Roland
> 21 jun 2015 kl. 02:08 skrev Maatary Okouy
Hi Brian & Greg,
the bind-host capability does indeed not solve the whole problem, but it is
what is needed from Akka to enable you to do so (as you have done, thanks for
sharing!). It might make sense to create small libraries that simplify the
process for the various clouds out there, but in
Hi Jakub,
I see what you are saying, but that only makes sense for linear 1:1
transformations (and possibly filter()). If we were to add something like this
then it would need to work with all stream combinators including custom stages
etc., because otherwise it would just be a big pile of junk
The signal you are looking for is onComplete, meaning that this kind of «the
stream has completed» semantics is already built into Akka Streams by way of
Reactive Streams. The only thing you need is a KafkaSource that you can
externally shut down (via its materialized value); if the source you a
13 matches
Mail list logo
