Comments on: HotSwap Code using Scala and Actors http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/ Down To The Bone Sat, 19 Jul 2008 20:03:20 +0000 http://wordpress.org/?v=2.0.2 by: Jason http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16134 Fri, 21 Dec 2007 06:48:10 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16134 <p>for another way to hotswap code you might look at <a href="http://www.zeroturnaround.com/javarebel/" rel="nofollow">javarebel</a></p> for another way to hotswap code you might look at javarebel

]]> by: Jonas http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16132 Fri, 21 Dec 2007 05:58:30 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16132 <p>Thanks David. I didn't know that. Very cool.</p> Thanks David. I didn’t know that. Very cool.

]]> by: David Pollak http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16127 Fri, 21 Dec 2007 04:25:02 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16127 <p>You can achieve even more hot swapping:</p> <p>def loop(cmd: PartialFunction[Any, Unit]) { react( { case HotSwap(newCmd) =&#62; println("hot swapping code...") loop(newCmd) } orElse cmd) }</p> <p>react() takes a PartialFunction as a parameter and does pattern matching against the PartialFunction. PartialFunctions can be composed with the orElse method. Thus, you can pass in different cmd's and change what the Actor does.</p> You can achieve even more hot swapping:

def loop(cmd: PartialFunction[Any, Unit]) { react( { case HotSwap(newCmd) => println(”hot swapping code…”) loop(newCmd) } orElse cmd) }

react() takes a PartialFunction as a parameter and does pattern matching against the PartialFunction. PartialFunctions can be composed with the orElse method. Thus, you can pass in different cmd’s and change what the Actor does.

]]> by: Jonas http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16095 Thu, 20 Dec 2007 14:49:59 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16095 <p>Thanks for the correction Rickard. I was fooled by the fact that the enclosing object only has one single val so initialization appeared to be done lazily when first reading the val. Corrected the blog post.</p> Thanks for the correction Rickard. I was fooled by the fact that the enclosing object only has one single val so initialization appeared to be done lazily when first reading the val. Corrected the blog post.

]]> by: Rickard http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16094 Thu, 20 Dec 2007 14:41:48 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16094 <p>Great article, Jonas! Just wanted to point out that a Scala 'val' is not lazily initialised. All vals are initialised when the class is created (or, for objects, when the object first is used). You can define a 'lazy val', though, for lazy val initialisation.</p> Great article, Jonas! Just wanted to point out that a Scala ‘val’ is not lazily initialised. All vals are initialised when the class is created (or, for objects, when the object first is used). You can define a ‘lazy val’, though, for lazy val initialisation.

]]> by: Jonas http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16092 Thu, 20 Dec 2007 13:36:11 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16092 <blockquote> “avoiding all of the latter one’s problems with deadlocks, live locks, race conditions, thread starvation etc. “ This is just not true. It is very easy to write a race condition with message passing. </blockquote> <p>Of course. You are right. Sloppy writing. Sorry. Thanks for catching it. Will change the post.</p> “avoiding all of the latter one’s problems with deadlocks, live locks, race conditions, thread starvation etc. “ This is just not true. It is very easy to write a race condition with message passing.

Of course. You are right. Sloppy writing. Sorry. Thanks for catching it. Will change the post.

]]> by: Jonas http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16091 Thu, 20 Dec 2007 13:32:46 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16091 <p>the_dormant, thanks for your comments.</p> <blockquote> so far, this solution is not different from: class Server{ InnerServer inner; public void setServer(InnerServer inner){ this.inner = inner; } public String status(){ return inner.status() } } you send your bytecode to a class which loads and instanciates your inner class with a different class loader, updates your inner server and voilà. </blockquote> <p>It is different in that this is an extremely complicated solution compared to the 3 lines of code that I had to add to support this in Scala. Also, using class loader tricks like that could lead to unforeseen problems. Then I think a solution like the aspect hotdeploy/undeploy, based on runtime instrumentation and uninstrumentation, that I implemented in AspectWerkz would be a better solution to this specific problem. However, far from a simple one. </p> <blockquote> Therefore, I’m not sure that scala Actors solves the main issue of hotswapping, even though it makes it easy to do so. </blockquote> <p>True. But that was not the point for the post. The point was to show an interesting usage of the Scala Actors library and the simplicity and beauty achieved with message-passing and pattern matching.</p> the_dormant, thanks for your comments.

so far, this solution is not different from: class Server{ InnerServer inner; public void setServer(InnerServer inner){ this.inner = inner; } public String status(){ return inner.status() } } you send your bytecode to a class which loads and instanciates your inner class with a different class loader, updates your inner server and voilà.

It is different in that this is an extremely complicated solution compared to the 3 lines of code that I had to add to support this in Scala. Also, using class loader tricks like that could lead to unforeseen problems. Then I think a solution like the aspect hotdeploy/undeploy, based on runtime instrumentation and uninstrumentation, that I implemented in AspectWerkz would be a better solution to this specific problem. However, far from a simple one.

Therefore, I’m not sure that scala Actors solves the main issue of hotswapping, even though it makes it easy to do so.

True. But that was not the point for the post. The point was to show an interesting usage of the Scala Actors library and the simplicity and beauty achieved with message-passing and pattern matching.

]]> by: Asd http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16087 Thu, 20 Dec 2007 11:33:55 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16087 <p>"avoiding all of the latter one’s problems with deadlocks, live locks, race conditions, thread starvation etc. "</p> <p>This is just not true. It is very easy to write a race condition with message passing.</p> “avoiding all of the latter one’s problems with deadlocks, live locks, race conditions, thread starvation etc. “

This is just not true. It is very easy to write a race condition with message passing.

]]> by: the_dormant http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16086 Thu, 20 Dec 2007 11:32:05 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16086 <p>I was given this requirement for HotSwapping the code in a distributed java system, I didn't resist the temptation to show them how it's easily done with Erlang, but I think the 2 main reasons that make this easy in Erlang are : 1) Erlang vm can update the code of a module without raising any issue (JVM can do it too using JDPA but you can't change the structure of your classes- add/remove methods - and you have to enable JDPA even though it seems to not have consequences on the overall performance ), The other way to do it is using a different class loader and throwing it away when done, but you have to be very careful.<br /> 2) Immutability in Erlang makes natural/obligatory the use of tail recursion or looping with your "State of The Wrold" as a parameter (you always keep a handle on your global state) and this is the Actor Model behavior by definition. so far, this solution is not different from: <code></p> <p>class Server{ InnerServer inner; public void setServer(InnerServer inner){ this.inner = inner; } public String status(){ return inner.status() } } </p> <p></code> you send your bytecode to a class which loads and instanciates your inner class with a different class loader, updates your inner server and voilà. Therefore, I'm not sure that scala Actors solves the main issue of hotswapping, even though it makes it easy to do so.</p> I was given this requirement for HotSwapping the code in a distributed java system, I didn’t resist the temptation to show them how it’s easily done with Erlang, but I think the 2 main reasons that make this easy in Erlang are : 1) Erlang vm can update the code of a module without raising any issue (JVM can do it too using JDPA but you can’t change the structure of your classes- add/remove methods - and you have to enable JDPA even though it seems to not have consequences on the overall performance ), The other way to do it is using a different class loader and throwing it away when done, but you have to be very careful.
2) Immutability in Erlang makes natural/obligatory the use of tail recursion or looping with your “State of The Wrold” as a parameter (you always keep a handle on your global state) and this is the Actor Model behavior by definition. so far, this solution is not different from:

class Server{ InnerServer inner; public void setServer(InnerServer inner){ this.inner = inner; } public String status(){ return inner.status() } }

you send your bytecode to a class which loads and instanciates your inner class with a different class loader, updates your inner server and voilà. Therefore, I’m not sure that scala Actors solves the main issue of hotswapping, even though it makes it easy to do so.

]]> by: Stephan Schmidt http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16083 Thu, 20 Dec 2007 10:50:33 +0000 http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors/#comment-16083 <p>Very good post, thanks.</p> <p>Since reading Erlang books and doing a little Scala development, I wondered if actors are cooperative multitasking versus preemtive multitasking in the thread model? Just wondering.</p> <p>Peace -stephan</p> Very good post, thanks.

Since reading Erlang books and doing a little Scala development, I wondered if actors are cooperative multitasking versus preemtive multitasking in the thread model? Just wondering.

Peace -stephan

]]>