当我的基于Akka 1.2的应用程序尝试使用超过500个左右的网格节点时,我收到以下警告:
Jan 05, 2012 1:36:43 PM org.jboss.netty.util.internal.SharedResourceMisuseDetector
WARNING: You are creating too many HashedWheelTimer instances.
HashedWheelTimer is a shared resource that must be reused across the application, so that only a few instances are created.
我将更深入地研究Akka代码,以找出HashedWheelTimer的使用位置以及我应该做些什么来避免创建太多的.虽然我正在这样做,但我想我会在这里发布警告以防专家中的一位专家可能能给我一两个可能缩小并加速搜索的指针,好吗？
使用Akka 1.3-RC6,我得到以下异常:
Jan 12, 2012 1:24:38 PM org.jboss.netty.util.HashedWheelTimer
WARNING: An exception was thrown by TimerTask.
org.jboss.netty.channel.ChannelException: Failed to open a socket.
at org.jboss.netty.channel.socket.nio.NioClientSocketChannel.newSocket(NioClientSocketChannel.java:49)
at org.jboss.netty.channel.socket.nio.NioClientSocketChannel.<init>(NioClientSocketChannel.java:83)
at org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory.newChannel(NioClientSocketChannelFactory.java:139)
at org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory.newChannel(NioClientSocketChannelFactory.java:86)
at org.jboss.netty.bootstrap.ClientBootstrap.connect(ClientBootstrap.java:218)
at org.jboss.netty.bootstrap.ClientBootstrap.connect(ClientBootstrap.java:188)
at akka.remote.netty.ActiveRemoteClient.connect(NettyRemoteSupport.scala:470)
at akka.remote.netty.ActiveRemoteClientHandler$$anonfun$channelClosed$1$$anon$4.run(NettyRemoteSupport.scala:599)
at org.jboss.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:519)
at org.jboss.netty.util.HashedWheelTimer$Worker.notifyExpiredTimeouts(HashedWheelTimer.java:440)
at org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:379) …我正在尝试用Akka和Scala构建一个高性能的分布式系统.
如果请求昂贵(和无副作用)计算的消息到来,并且之前已经请求了完全相同的计算,我想避免再次计算结果.如果先前请求的计算已经完成并且结果可用,我可以缓存它并重新使用它.
然而,可以请求重复计算的时间窗口可以是任意小的.例如,对于所有实际目的,我可以在同一时刻获得一千或一百万条消息请求相同的昂贵计算.
据称有一种名为Gigaspaces的商业产品可以处理这种情况.
但是,目前似乎没有框架支持在Akka处理重复的工作请求.鉴于Akka框架已经可以访问通过框架路由的所有消息,看起来框架解决方案在这里可能很有意义.
以下是我为Akka框架提出的建议:1.创建一个特征来指示要遵循以下缓存方法的消息类型(例如,"ExpensiveComputation"或类似的东西).2.智能地(散列等)识别在用户可配置的时间窗口内由(相同或不同的)演员接收的相同消息.其他选项:选择要用于此目的的最大内存缓冲区大小,取决于(比如LRU)替换等.Akka还可以选择仅缓存处理成本高昂的消息的结果; 如果需要,可以再次重新处理花费很少时间处理的消息; 无需浪费宝贵的缓冲空间来缓存它们及其结果.3.当识别出相同的消息(在该时间窗口内接收,可能"在同一时刻")时,避免不必要的重复计算.框架会自动执行此操作,实际上,重复的消息永远不会被新的actor接收以进行处理; 他们会默默地消失,并且处理过一次的结果(无论该计算是在过去已经完成,还是在当时正在进行)将被发送给所有适当的接收者(如果已经可用,则立即发送,如果没有,则完成计算).请注意,即使"回复"字段不同,也应认为消息相同,只要它们表示的语义/计算在其他方面都相同即可.还要注意,计算应该是纯粹的功能,即没有副作用,因为建议的缓存优化工作并且根本不改变程序语义.
如果我的建议与Akka的做事方式不兼容,和/或如果你看到一些强烈的理由为什么这是一个非常糟糕的主意,请告诉我.
谢谢,太棒了,斯卡拉
我正在考虑使用Akka 2.0建立计算网格的以下两种方法:
一个.让一个中央路由器节点知道所有工作节点(即它们正在运行的主机和端口),跟踪它们的状态,并为它们分配工作.工作人员对中央路由器的位置一无所知,他们只接收计算请求,计算结果并将其发送回请求的发送方.
要么
湾 有一个中央路由器节点,它不了解所有计算网格工作者的位置(即他们运行的主机和端口).工作人员都知道中央路由器,他们在启动时向中央路由器注册.一旦他们注册,路由器会跟踪他们的状态(向上或向下),并为他们分配工作.
显然,这两种方法都有一些可以更好地适应不同用例和场景的专家和骗局.鉴于即将推出的Akka 2.1 API,我对Akka社区更喜欢哪种方法感兴趣？换句话说,哪种方法可能更适合Akka 2.1将提供的Clustering API？
我查看了Akka 2.0 RC2文档,该文档简要讨论了将在Akka 2.1中提供的聚类功能,但目前尚未发布太多细节.我希望能从社区中的Akka专家那里获得更好的见解.