be consumed more than once (in other
word, the entity stream might be materialized more than once), e.g. by a
badly coded outer directive. I’m not really worried that this will happen
(without my tests catching it), but if there’s a better way I’d like to
know about it.
Thanks,
--
Daniel
Not with Future.sequence. You could, however, write something like this:
def toTry()(implicit ec: ExecutionContext): Future[Try[T]] = fut map
Success.apply recover { case NonFatal(e) => Failure(e) }
futures map (toTry(_)) onComplete { ... }
Daniel Armak
On Mon, Jul 21, 2014 at 8:30 PM, G
Er, just to point out the obvious mistake in my previous email, it should
be:
Future.sequence(futures map (toTry(_))) onComplete { ... }
Daniel Armak
On Mon, Jul 21, 2014 at 9:21 PM, Greg Flanagan wrote:
> nice, that did the trick. thanks!
>
>
> On Monday, July 21, 2014 10:52
Alternatively, if what you want is really to produce the input elements
(returning a Flow[T]) and only add a side-effecting operation, you can
implement it using `map`.
Daniel Armak
On Thu, Jul 24, 2014 at 11:35 AM, Akka Team wrote:
> Hi Eric,
>
> There is a foreach method that doe
ereas Play is a *web* framework. It includes support for lots of
web-related features that aren't part of HTTP as such.
Daniel Armak
On Tue, Oct 14, 2014 at 12:11 PM, Prakhyat Mallikarjun <
prakhyat...@gmail.com> wrote:
> Hi Konrad,
>
> I am aware of these posts.
>
> Si
Right, I forgot spray doesn't have a Java API. Sorry about not making that
clearer.
Daniel Armak
On Tue, Oct 14, 2014 at 5:46 PM, Richard Rodseth wrote:
> I think he's considering Play even for pure REST, because he can use it
> from Java, and Akka-HTTP is not ready.
>
>
that provided a generic implementation of RS, would you have used
it? What would you want from such a library?
Thanks,
--
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>
Publisher[T], with
the subscription management and back-pressure implemented in the library.
It's a good fit for me, but would it be good for others? I don't know.
Daniel Armak
On Wed, Oct 29, 2014 at 12:29 PM, Akka Team wrote:
>
>
> On Wed, Oct 29, 2014 at 11:17 AM, Roland Ku
complexity. If I wrote a v2 I would use different interfaces, with cheap
but explicit adaptors to RS available on request. In practice I only need
RS to bridge to other implementations.
--
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>&g
hat
you, or anyone, would choose to implement RS directly. I'm pretty sure the
RS specification authors didn't intend for that to happen :-)
Daniel Armak
On Wed, Oct 29, 2014 at 3:02 PM, Michał Kiędyś wrote:
> Hi Daniel,
>
> I made my anwser below. Your opinion is valuable
other cannot?
Thanks!
--
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>&
I can't comment on akka-http, but here's my understanding of the HTTP spec.
It's certainly legal to send a response before receiving the request
entity, but the client isn't obligated to start reading the response before
it finishes sending the request. And if the server closes the connection
w
way that would make it easier to migrate to RS in the future.
Thanks!
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>>
nd maybe this is just an unsolved difficult problem. So how
do mature actor-based projects handle these issues? How can I have the
benefits of both actors and static typing?
TIA for any insight.
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/
he patterns and philosophy and grew to
> love it so much that I wrote a book about it (the first one, I think) and
> now code in Scala and Akka every single day. Your mileage may vary :)
>
>
> On Friday, March 7, 2014 5:10:23 PM UTC-5, Daniel Armak wrote:
>>
>> Hello,
>&
dealing with.
But I'm taking your advice to heart. I'll try to use pure actors until I
have more of a sense of how problematic various issues are.
Thanks!
Daniel Armak
On Sat, Mar 8, 2014 at 8:59 PM, Derek Wyatt wrote:
> On 8 March 2014 13:31, Daniel Armak wrote:
>
>&g
t;
> As you see, without receiving a reply from an actor, the provable type of
> an actor is usually Nothing, or something useless. Only replies can convey
> the *possible* type of an actor, and even that cannot be guaranteed if
> there are concurrent senders.
>
> -Endre
>
>
e window of time.
>
> -Endre
>
>
> On Sun, Mar 9, 2014 at 8:31 PM, Daniel Armak wrote:
>
>> Part of the difficulty I'm experiencing is that most of the time I want
>> to write code that is definitely local - a set of actors that are
>> guaranteed to run on t
On Thu, Mar 13, 2014 at 11:27 PM, Roland Kuhn wrote:
> Futures very cleanly model local dataflow. Actors very cleanly model
> distribution and concurrency. My guess is that if you try to create an
> abstraction in-between then it will have the disadvantages of both and the
> advantages of neither
On Fri, Mar 14, 2014 at 12:16 AM, Roland Kuhn wrote:
> The idea with actors is that they shall remain responsive whenever
> possible. Another way to look at it is that the internal queue (or stash)
> should be limited, and when it overflows you might want to send a negative
> reply right away. Fo
at you mean?
Will the HTTP module not necessarily be available in 2.4, and if so, would
it be delayed until 2.5 (a really long time in the future) or maybe
released separately after 2.4? And what would that mean for the new
reactive streams module - is it tied to the HTTP module?
Tha
Would that include the new reactive streams?
On Tue, Apr 8, 2014 at 9:25 PM, √iktor Ҡlang wrote:
> Hi Daniel,
>
> On Tue, Apr 8, 2014 at 8:10 PM, Daniel Armak wrote:
>
>> On Tue, Apr 8, 2014 at 5:22 PM, Roland Kuhn wrote:
>>
>>> The release of Akka 2.4 is q
"Cast" does seem to have the potential for confusion. How about "a company
of actors", or maybe "troupe"?
On Tue, Apr 15, 2014 at 11:43 PM, Justin du coeur wrote:
> On Tue, Apr 15, 2014 at 4:16 PM, √iktor Ҡlang wrote:
>
>> "A cast of actors"?
>>
>
> Heh. Aside from the word "cast" invoking a bit
is is a more complex scenario, so I
expect it will be left to each implementation to introduce its own patterns.
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>&
write a spray server and I have
an HttpResponsePart producer, how do I know what size ByteStrings to send
to the consumer that ships these out to the network?
Daniel
On Mon, Apr 21, 2014 at 2:50 PM, Patrik Nordwall
wrote:
>
>
> 20 apr 2014 kl. 00:32 skrev Daniel Armak :
>
> Hi,
>
>
s is important enough to be part of the API . (As
an optional, but standardized, extra interface a Producer/Consumer can
implement.)
Thanks,
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check t
Hi Patrik,
I will do so when I have time to write up my case (on the RS generic
level), in the next few days.
Thanks!
Daniel
On Wed, Apr 23, 2014 at 12:36 PM, Patrik Nordwall wrote:
>
>
>
> On Tue, Apr 22, 2014 at 8:26 PM, Daniel Armak wrote:
>
>> On Tue, Apr 22, 20
I finally created a ticket here, if anyone wants to track this. Let the RS
committers decide.
https://github.com/reactive-streams/reactive-streams/issues/47
On Thu, Apr 24, 2014 at 10:26 PM, Daniel Armak wrote:
> Hi Patrik,
>
> I will do so when I have time to write up my case (
would just compete for CPU, but maybe I was
wrong? Alternatively, would it make sense to use ExecutionContext.global as
the ActorSystem dispatcher's underlying executor?
I'm using akka 2.2.3 with scala 2.10.4.
Thanks,
Daniel Armak
--
>>>>>>>>>> Read th
definitely do some "real" benchmarking, I just haven't had time yet.
And I thought to ask meanwhile if there were any known pitfalls, or large
differences between the two ECs' default configurations?
Thanks,
Daniel Armak
On Wed, May 21, 2014 at 9:59 PM, √iktor Ҡlang wrote:
>
Isn't that what .view.slice does?
Daniel Armak
On Thu, Jun 5, 2014 at 4:34 PM, √iktor Ҡlang wrote:
> Hi,
>
> This sounds plausible to me:
>
> Create an interface that wraps a section of the float array and pass an
> instance of that section into the actor when i
If they only need readonly access, then why does it matter if the views are
overlapping?
Daniel Armak
On Thu, Jun 5, 2014 at 8:01 PM, Marco Luca Sbodio
wrote:
> Hi,
>
> thank you for your suggestion, but I think I this is not applicable to my
> case for two reasons:
>
> - I
received a `Terminated` message saying your actor died, it didn't
handle that the message and so died with a DeathPactException.
Again, it's possible I'm misunderstanding your case if it's not in fact
similar to the ones discussed at that ticket, but it looks the same as them
to me
Hi,
If I use akka-remoting (not cluster), and I don't send any PossiblyHarmful
messages (so no remote actor creation or watching), can the association
ever be quarantined?
Thanks,
--
Daniel Armak
--
>>>>>>>>>> Read the docs: http://akka.io/
se actors, where the Cluster would
be inappropriate.
Thanks,
Daniel Armak
On Wed, Feb 24, 2016 at 6:55 PM, Konrad Malawski
wrote:
> Yeah, for example if irrecoverable loss of system messages happens.
> In general death watch on Actors using remoting can in failure scenarios
> (see above) l
35 matches
Mail list logo
