How can a final val be „nulled"? Unsafe? Reflection?
>
> Cheers
> Heiko
>
> --
>
> Heiko Seeberger
> Home: heikoseeberger.de
> Twitter: @hseeberger
> Public key: keybase.io/hseeberger
>
>
>
>
> Am 07.03.2018 um 19:23 schrieb Patrik Nordwall >:
e documentation is the import recommended? We should probably
> update that. Would you be able creating a PR fixing it? Thanks.
>
> /Patrik
>
> On Tue, Mar 6, 2018 at 10:44 PM, Jeff >
> wrote:
>
>> I suspected as much. So what would you suggest as for handling use
ontext is bound to the lifecycle of the actor.
>
> On Tue, Mar 6, 2018 at 8:37 PM, Jeff >
> wrote:
>
>> I have noticed an issue where if a future maps/flatmaps after actor
>> shutdown, a NullPointerException is thrown. I've narrowed it down to the
>> import
patcher is preferred.
Thanks
Jeff
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>&
Actually found a much simpler solution using Source.unfoldAsync.
On Thursday, February 22, 2018 at 6:54:54 PM UTC-8, Jeff wrote:
>
> My particular use case is a long poll where the id to be sent on the next
> request is returned from the previous request.
>
> On Thursday, Februar
t to achieve (sample code?)
>
> --
> Cheers,
> Konrad 'ktoso <http://kto.so>' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>
> On February 23, 2018 at 7:05:18, Jeff (jknigh...@gmail.com )
> wrote:
>
> Currently, Flow
hanks
Jeff
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>
Bumping this - what are the best practices about using anonymous actors to
modify shared state?
Thanks
Jeff
On Wednesday, December 27, 2017 at 4:51:04 PM UTC-8, Jeff wrote:
>
> I have a class that is read heavy with low contention on writes. I'd like
> to be able to access a p
I have a class that is read heavy with low contention on writes. I'd like
to be able to access a piece of shared mutable state outside of Actors. The
state itself (AnnouncementRegistry) is immutable. Since it is a single
writer, having a shared @volatile var between the actor and the class seems
Still trying to figure out how I can use the new RestartSink/Flow/Source to
retry an Http request in a Stream. Any thoughts?
On Thursday, October 5, 2017 at 12:29:07 PM UTC-7, Jeff wrote:
>
> I am trying to create a polling flow which feeds the results of the last
> update into the ne
bump
On Thursday, October 5, 2017 at 12:29:07 PM UTC-7, Jeff wrote:
>
> I am trying to create a polling flow which feeds the results of the last
> update into the next update (much like the SSE example here
> https://youtu.be/-7OyuTMgI1I). However, I'd like to add an exponent
I am trying to create a polling flow which feeds the results of the last
update into the next update (much like the SSE example
here https://youtu.be/-7OyuTMgI1I). However, I'd like to add an exponential
backoff on failed requests. The new RestartSource/Flow/Sink seems like the
correct fit, how
A Consul like service discovery client built on top of akka-http
--
>> 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-use
That's what I was leaning towards as well, since materialzers are fairly
lightweight. However, I've seen that statement prefaced with, "...right now" so
I wanted to make sure there wasn't some other way to share.
--
>> Read the docs: http://akka.io/docs/
>> Check the
How, exactly. You only have access to an ExtendedActorSystem inside of
createExtension()
--
>> 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.
I am building an akka extension, but there doesn't seem to be an elegant
way to pass in a shared Materializer. What would be the suggested way to
use a shared materializer between akka extensions and the main application?
--
>> Read the docs: http://akka.io/docs/
>> Ch
I'm embarrassed I forgot something so obvious. Much thanks!
On Tuesday, August 15, 2017 at 8:50:27 AM UTC-7, johannes...@lightbend.com
wrote:
>
> Hi Jeff,
>
> if you don't read the response bodies of all the responses, your pipeline
> will stall because the super
Quickly following up on this. My understanding of how MergeHub works leads
me to believe that all 100 requests in my example should fire, however only
8 of them do, and only 4 complete.
On Wednesday, August 9, 2017 at 4:53:18 PM UTC-7, Jeff wrote:
>
> I am getting behavior that I
4
started 1
finished 1
started 5
started 6
started 7
started 8
My understanding from the documentation is that Http().superPool() will
backpressure. However, after 8 iterations, nothing else happens. Thoughts?
Thanks
Jeff
--
>>>>>>>>>> Read the docs: http://akk
I didn't see much in the documentation, so I thought I'd ask. If I have a
Sink.actorRef and a Source.actorRef, and I combine them using
Flow.fromSinkAndSource, does this somehow propagate backpressure?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>>
My understanding from the documentation is that using Http.singleRequest
will fail requests when in a backpressure situation, while using a MergeHub
with the flow will in fact backpressure. Is that a correct understanding?
Jeff
On Thursday, July 13, 2017 at 4:46:39 AM UTC-7, johannes
ion and resolves the Promise.
On Wednesday, July 12, 2017 at 5:24:07 AM UTC-7, johannes...@lightbend.com
wrote:
>
> Hi Jeff,
>
> your API seems quite complex. I don't know the purpose of it so I cannot
> suggest anything but I'd try to simplify. :)
>
> That sai
Any thoughts?
On Thursday, July 6, 2017 at 2:23:50 PM UTC-7, Jeff wrote:
>
> Here is a strawman program which illustrates the issue I am having
>
> trait RequestBuilder {
> type Out
>
> def complete(p: Promise[Out]): Unit
> }
>
> def makeRequest(in: RequestBu
Here is a strawman program which illustrates the issue I am having
trait RequestBuilder {
type Out
def complete(p: Promise[Out]): Unit
}
def makeRequest(in: RequestBuilder): Source[(RequestBuilder, Promise[in.Out]),
Future[in.Out]] = {
val p = Promise[in.Out]
Source.single(in -> p).map
I am also running into a similar situation and have not found a solution
that is satisfactory
On Monday, May 30, 2016 at 2:03:55 PM UTC-7, Matthew wrote:
>
> Hi Leslie,
>
> Did you ever find a nice pattern for this? I ask because I'm doing
> something very similar and am currently unhappy with
0:53 PM UTC-7, Juan José Vázquez Delgado
wrote:
>
> I've faced a similar situation recently working on this example
> <https://github.com/juanjovazquez/scala-petclinic>. It's not easy but is
> definitely feasible. The bottom line is: run your own marshaller.
>
>
of the way there, but I still have to
> cheat occasionally...
>
> On Tue, Jun 13, 2017 at 12:44 PM, Jeff >
> wrote:
>
>> I am trying to learn tagless final style to remove concrete monads (ie
>> futures) from my code. I have come up with the following strawman
rete types intstead of F[_],
it would have worked. What is the best way to handle this to prevent
implementation details from leaking in?
Thanks
Jeff
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FA
n the configuration should be shown. Maybe I missed it. I dunno.
Thanks in advance for any insights.
Regards,
Jeff Henrikson
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>&
I am working my way through the websocket example and have a question about
nested streams. Currently I have this:
import akka.actor.ActorRef
import akka.http.scaladsl.model.ws.{BinaryMessage, TextMessage, Message}
import akka.stream.{OverflowStrategy, FlowShape}
import akka.stream.scaladsl.{Sin
Any solutions to this one yet? I'm getting the same error in a Play 2.4
app. During Global.onStop I call my subscribers onComplete function, but I
still see the Processor actor terminated abruptly error. Any ideas?
On Thursday, April 30, 2015 at 2:55:32 PM UTC-6, Samuel Tardieu wrote:
>
> Hi.
>
f the actor decides to send the
> message to another node)
>
> On Thu, Jul 16, 2015 at 4:51 AM, Jeff >
> wrote:
>
>> Is there any reason why I wouldn't want to pass a Promise to a (local)
>> ActorRef to be resolved? I know the Ask pattern exists, but I would li
Is there any reason why I wouldn't want to pass a Promise to a (local)
ActorRef to be resolved? I know the Ask pattern exists, but I would like to
avoid the cost of having to allocate PromiseActorRefs.
Thanks
Jeff
--
>>>>>>>>>> Read the docs: http://
advice on how I should be tracking down this issue?
Thanks in advance,
Jeff
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/ad
Sure, ticket is here https://github.com/akka/akka/issues/17750
On Tuesday, June 16, 2015 at 12:51:56 PM UTC-7, Patrik Nordwall wrote:
>
>
>
> On Tue, Jun 16, 2015 at 8:51 PM, Jeff >
> wrote:
>
>> So if my understanding is correct, expected-response-after and
>>
correct?
Thanks
Jeff
On Monday, June 15, 2015 at 7:40:35 AM UTC-7, Patrik Nordwall wrote:
>
> expected-response-after is used for starting failure detection when the
> first heartbeat message is not received as expected, e.g. when connection
> is broken from the beginning.
&g
Can somebody enlighten me on how these two settings interact? These two
settings seem to overlap.
Thanks
Jeff
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>&g
I took a page out of the stream-integrations documentation, and hooked a
simple ActorSubscriber up as a sink to a Flow. Something like:
class TestActorSubscriber extends ActorSubscriber {
override def postStop() = {
println("Stopped " + self.toString)
super.postStop
}
override def
I have an actor that I need to pass several actorRefs into (remote
services). Is there a best practice for doing this with type safety (so a
user doesn't accidentally pass the wrong actorRef)? Some options I've
considered are using scalaz Tags and native scala Value Classes.
--
>>
d
>
> 22 maj 2015 kl. 23:57 skrev Jeff >:
>
> Following up on this question, what are the best practices around creating
> anonymous actors, as long as you are not closing over context of a parent
> actor?
>
> On Friday, May 22, 2015 at 12:08:45 PM UTC-7, Jeff wrote:
>&
Following up on this question, what are the best practices around creating
anonymous actors, as long as you are not closing over context of a parent
actor?
On Friday, May 22, 2015 at 12:08:45 PM UTC-7, Jeff wrote:
>
> Is it bad practice to pass in the Receive pf to an actor as part
Is it bad practice to pass in the Receive pf to an actor as part of the
constructor arguments, assuming all vals it closes over are consts?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>
I thought there was something specific I was doing wrong in an application
I have deployed in development, which eventually needs to be production
ready.
Over time, the Akka actor system slowly consumes all available memory. I
assumed it was a memory leak that I introduced, but as it turns out
Having the debugging profile only suspend the current thread helped a lot,
thanks!
On Thursday, May 7, 2015 at 1:23:41 AM UTC-7, 何品 wrote:
>
> you could just pause the current thread.not all of them.cursive debugger
> could do that.
>
> 在 2015年5月7日星期四 UTC+8上午10:50:41，Jeff写道：
>
Every time I set a breakpoint in an actor involved with Actor Clustering,
the phi detector triggers and marks that node as Unreachable. Is there a
way to prevent this during debugging?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.
e transformation stages run under "test-dispatcher", or just the
last one? If I only want to apply the attributes to a single stage, should
I use .via()?
Thanks
Jeff
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>&g
This is pretty clever. Can this same trick be applied to a Sink that feeds
data into an external system?
On Friday, February 20, 2015 at 2:20:42 AM UTC-8, drewhk wrote:
>
> Hi Simon,
>
> One trick I like to use is to define a Source in terms of a PushPullStage.
> Now this sounds strange, since a
This is using 1.0-M5
On Monday, April 13, 2015 at 9:32:38 PM UTC-7, Jeff wrote:
>
> I am creating an ActorPublisher to encapsulate a kafka consumer. I am
> trying to bulkhead the actor behind a custom dispatcher (since the kafka
> consumer is blocking) with the following code
I am creating an ActorPublisher to encapsulate a kafka consumer. I am
trying to bulkhead the actor behind a custom dispatcher (since the kafka
consumer is blocking) with the following code:
val in =
Source[Array[Byte]](KafkaConsumerActor.props(consumer.createMessageStreamsByTopic(topic).head)
ting finding, we need to investigate.
>>
>> -Endre
>>
>> On Fri, Apr 10, 2015 at 3:38 AM, Jeff >
>> wrote:
>>
>>> I have been able to isolate the code that is running differently between
>>> the two different actor providers. Below is the
I am building an actor system that basically has a topology of spray ->
business logic actor -> slick. I initially built these using akka remote,
but have recently switch over to akka cluster. In testing these systems, I
have noticed that round trip calls through the system take half the time
u
sure each new data item update is applied atomically before
any new external ones enter the system?
Any insights would be appreciated.
- regards Jeff V
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the
ear term and deciding if I should implement a
DurableMailbox or spend more time trying to bend Persistence to work with
my stateless actor.
Thanks
-Jeff
On Monday, March 24, 2014 8:53:23 AM UTC-6, Patrik Nordwall wrote:
>
> The big difference is that when using akka-persistence the messages are
;weeks" (I know this sounds odd, but i dont have direct
access to the production systems and need to go through a couple layers of
IT folks in different geos and timezones.)
Anyhow, I just wanted to check on the options/alternatives that might not
be obvious. I'm a fan of getting on the l
We've had some recent "production issues" and it looks like this is the
exact issue biting us; (this results in a need to restart our appservers
rather periodically.)
The app is on akka 2.1.4.
I scanned the akka 2.1.x to 2.2.x migration guide a while ago (and also
just now), and it didn't seem
55 matches
Mail list logo
