actor 内最好不要阻塞

1. 在使用 akka cluster singleton 时,我需要知道被创建的 singleton proxy 的 actorRef,通过绝对路径加 actorSelection 方法,应该很容易得到此 actor 的 actorRef

main() {
    system.actorOf(ClusterSingletonManager.props(Master.props(Duration(99, "second")), "active",
            PoisonPill, None), "master")

    context.system.actorSelection("user/master/active").resolveOne(4 second).await ! ParentGreeting

}

  

上面的程序会报异常,actor not found

但是对于普通的 actor,却没有问题

val actorRef: ActorRef = system.actorOf(Master.props(10 second), "standalone")

actorRef ! ParentGreetings

  

不知道原因

2.

对于1,我们假设 singleton actor 已经被创建,在 actor 内部获取自己的 actorRef

val core1: ActorRef = context.system.actorSelection("/user/master").resolveOne(Duration(10, "second")).await

val core2: ActorRef = context.system.actorSelection("/user/master/active").resolveOne(Duration(10, "second")).await

  

core1 成功得到(core1 是 clusterSingletonManager),core2 报错

3.

resolveOne 返回的是 Future[ActorRef],那么在 actor 内部尝试异步的方法

context.system.actorSelection("user/master/active").resolveOne(4 second).map(actor => actor ! ParentGreetings)

  

成功得到 actorRef 并且发送消息

解释:

对于2,3 我觉得可以理解成,resolveOne() 发送的 activity 消息给 singleton actor 后阻塞在那里,此次阻塞的不仅是这个语句,actor 自己也被阻塞了,它无法给自己再发一个消息,告诉自己的 activityId 信息,因此 resolveOne.await 等待 4 秒后,超时异常,actor not found 异常。

这种解释或许有道理,但是我觉得可能是错的,首先,我用的是 context.system,而不是 context 阻塞的应该不是当前 actor,曾经在stackoverflow 上看到过这个问题。其次,main 里的 resolveOne.await 总不会阻塞 actor 了吧,但它依然没有找到

时间: 2024-10-18 04:17:24

actor 内最好不要阻塞的相关文章

29、Java并发性和多线程-非阻塞算法

以下内容转自http://ifeve.com/non-blocking-algorithms/: 在并发上下文中,非阻塞算法是一种允许线程在阻塞其他线程的情况下访问共享状态的算法.在绝大多数项目中,在算法中如果一个线程的挂起没有导致其它的线程挂起,我们就说这个算法是非阻塞的. 为了更好的理解阻塞算法和非阻塞算法之间的区别,我会先讲解阻塞算法然后再讲解非阻塞算法. 阻塞并发算法 一个阻塞并发算法一般分下面两步: 执行线程请求的操作 阻塞线程直到可以安全地执行操作 很多算法和并发数据结构都是阻塞的.

js行内脚本可以随便用吗? 性能优化说:“别,注意点”

对于脚本的加载方式,很多人会选择外部加载的方式,但很时候却不得不使用行内脚本的方式,使用行内脚本有很多需要注意的地方,并不是用的越多越好, 你是否考虑到性能优化的问题,如果是,那请你在使用的时候注意以下这些问题,或许会帮助到你. ##行内脚本会阻塞并行下载影响加载性能,当行内脚本进行加载的使用,其他的资源下载就会阻塞停止,同时行内脚本也会影响到浏览器渲染. 解决方案:1.把行内脚本移动到底部进行加载 2.使用异步回调启动js的执行 3.使用script的defer属性(不常用,因为浏览器版本和兼

干货:Java并发编程必懂知识点解析(内附面试题)

本文大纲 1.并发编程三要素 原子性 原子,即一个不可再被分割的颗粒.在Java中原子性指的是一个或多个操作要么全部执行成功要么全部执行失败. 有序性 程序执行的顺序按照代码的先后顺序执行.(处理器可能会对指令进行重排序) 可见性 当多个线程访问同一个变量时,如果其中一个线程对其作了修改,其他线程能立即获取到最新的值. 2. 线程的五大状态 创建状态 当用 new 操作符创建一个线程的时候 就绪状态 调用 start 方法,处于就绪状态的线程并不一定马上就会执行 run 方法,还需要等待CPU的

彻底理解同步 异步 阻塞 非阻塞

IO操作 IO分两阶段(一旦拿到数据后就变成了数据操作,不再是IO): 1.数据准备阶段 2.内核空间复制数据到用户进程缓冲区(用户空间)阶段 在操作系统中,程序运行的空间分为内核空间和用户空间. 应用程序都是运行在用户空间的,所以它们能操作的数据也都在用户空间. 阻塞IO和非阻塞IO的区别在于第一步发起IO请求是否会被阻塞: 如果阻塞直到完成那么就是传统的阻塞IO,如果不阻塞,那么就是非阻塞IO. 一般来讲: 阻塞IO模型.非阻塞IO模型.IO复用模型(select/poll/epoll).信

深入了解 Scala 并发性

2003 年,Herb Sutter 在他的文章 “The Free Lunch Is Over” 中揭露了行业中最不可告人的一个小秘密,他明确论证了处理器在速度上的发展已经走到了尽头,并且将由全新的单芯片上的并行 “内核”(虚拟 CPU)所取代.这一发现对编程社区造成了不小的冲击,因为正确创建线程安全的代码,在理论而非实践中,始终会提高高性能开发人员的身价,而让各公司难以聘用他们.看上去,仅有少数人充分理解了 Java 的线程模型.并发 API 以及 “同步” 的含义,以便能够编写同时提供安全

第二章 有什么理由使用Async异步编程

p { display: block; margin: 3px 0 0 0; } --> 写在前面 在学异步,有位园友推荐了<async in C#5.0>,没找到中文版,恰巧也想提高下英文,用我拙劣的英文翻译一些重要的部分,纯属娱乐,简单分享,保持学习,谨记谦虚. 如果你觉得这件事儿没意义翻译的又差,尽情的踩吧.如果你觉得值得鼓励,感谢留下你的赞,在今后每一次应该猛烈突破的时候,不选择知难而退.在每一次应该独立思考的时候,不选择随波逐流,应该全力以赴的时候,不选择尽力而为,愿爱技术的园

并发计算模型BSP与SEDA

1    BSP批量同步并行计算 BSP(Bulk Synchronous Parallel)批量同步并行计算用来解决并发编程难的问题.名字听起来有点矛盾,又是同步又是并行的.因为计算被分组成一个个超步(super-step),超步内并行计算并且结点间不能通信.在超步之间设置同步栅栏(barrier synchronization),计算完成后相互通信,全部完成后才能继续下一个超步. 2 SEDA阶段式事件驱动架构 SEDA(staged event-driven architecture)分阶

《GCD 实现同步锁》-07-多线程

@MicroCai 2015-03-03 23:18 字数 6539 阅读 202 Effective Objective-C Notes:GCD 实现同步锁 Archives iOS <Effective Objective-C Notes>系列博文整理自<Effective Objective-C 2.0> 如果您觉得我的博客对您有帮助,请通过关注我的新浪微博  MicroCai 支持我,谢谢! 本文名为<GCD 实现同步锁>,内容不止于锁.文章试图通过 GCD 同

libgsc(Game Server Communication Library)(五)

这个版本基本上达到了我最早想要的效果: 简洁, 直观, 无锁, 并行, 高效.   高效不一定是运行时的效率,  更多的是开发效率.  也就是最少的bug 产生可能性, 最快的代码实现. 代码实际上在2月份就基本完工了,  等到经历了一个html5的游戏后, 感觉应该差不多了.  不太可能再有大的改动.  另外, 也添加了一些功能. 这些功能也导致我重新修改了通信协议. 一起汇总如下: 1.  Actor的调度/通信的基本原理未变,  依然是基于epoll, pipe. 只是管道上的通信仅仅作为