tag:blogger.com,1999:blog-22587889.post3013795989207953349..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Scaling out messaging applications with Scala Actors and AMQPAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-22587889.post-58783748578737546812009-12-10T10:14:15.916+05:302009-12-10T10:14:15.916+05:30can you call loop recursively like you do? it'...can you call loop recursively like you do? it's a tail recursion, but does scala actually optimizes it away? i thought you were supposed to use Actor#loopIttay Drorhttps://www.blogger.com/profile/06786072335349487451noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-59955054664227501312008-08-05T11:39:00.000+05:302008-08-05T11:39:00.000+05:30@carlos: Scala uses 2 types of actors - one based ...<I>@carlos:</I> Scala uses 2 types of actors - one based on OS threads and the other based on class abstractions (event based actors). The thread based ones map 1:1 to OS threads, are heavyweight, do not scale. While the event based ones are lightweight and can be spawned in millions much like Erlang processes. Please have a look at http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf for details of implementation.<BR/><BR/>But the summary is that, event-based actors are executed in a thread pool, which gets automatically resized in case all threads are blocked due to blocking operations. Hence there is a chance that the thread pool cannot be resized due to system limitations, while all actors call blocking operations.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-59641233952306152032008-08-05T00:59:00.000+05:302008-08-05T00:59:00.000+05:30I'm not totally clear that Scala would use one thr...I'm not totally clear that Scala would use one thread per actor if you are doing IO. Could you comment on that? If you have blocking IO I cannot see a way that on thread per actor could work.<BR/><BR/>That of course doesn't invalidate the actor model at all, is just a limitation of the underlying java platform. I guess you can use NIO in any case.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-75201065217086219222008-07-31T12:01:00.000+05:302008-07-31T12:01:00.000+05:30@carlos: RabbitMQ is implemented in Erlang and has...<I>@carlos:</I> RabbitMQ is implemented in Erlang and has all the wonderful scalability characteristics that OTP offers viz. seamless distribution, fault tolerance, process supervisors etc. I suggested using Scala actors at the application layer, since Scala actors scale much more than native Java threads. Scala actors are event based and use much more finer grained concurrency techniques. It is not thread-per-actor model and hence scales better.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-62277829782039613572008-07-30T22:16:00.000+05:302008-07-30T22:16:00.000+05:30HiNice article, I've been looking for alternatives...Hi<BR/><BR/>Nice article, I've been looking for alternatives to our activemq based solutions and RabbitMQ seems something really worth to look at.<BR/><BR/>ActiveMQ is limited by the inherent thread limitations of java and so, though it can process high volumes of messages, it is limted to the amount of simultaneous client.<BR/><BR/>Would the same limitations apply to your Scala actors? Would that limit the client's scalability?Carlos Quirozhttps://www.blogger.com/profile/05424249133012786442noreply@blogger.com