river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Moynihan <r...@calicojack.co.uk>
Subject Re: Concurrency and River
Date Mon, 01 Oct 2007 17:22:50 GMT
Bill Venners wrote:
> The Pragmatic Programmers recently published a book on Erlang, which  
> got a lot of people taking about Erlang. Erlang uses a shared nothing  
> model, with message passing between "processes" managed by "actors".  
> Processes can be implemented as threads I assume, or can be  
> distributed. One interesting thing about Erlang is that it tries to  
> unify the remote and local models, as far as I can tell. Not that  
> they haven't read a Note on Distributed Computing. I think that  
> instead of trying to make remote nodes look like local ones, they may  
> treat local ones as unreliable as remote ones.

It's a great book, and I'd recommended it to anyone interested in 
computing and concurrency etc...  Regardless of whether Erlang is 
suitable for all tasks, it's a very interesting language, and certainly 
a great language for particular problems/domains.

I'm no Erlang expert; but you're right about how Erlang treats 
processes.  It's main difference from Java+Jini is that it treats all 
communication between processes regardless of whether they are local or 
not as unreliable and asynchronous (i.e. non blocking).  Even when 
talking to a 'local node' if you want to be sure the node you are 
talking to received the message you sent then you need to implement an 
RPC mechanism.  Fortunately this is easily done, and from what I've seen 
is quite a common idiom implementable in a few lines.

For a long time I have wanted to remodel some of our use of Jini/RMI to 
be more similar to this model, i.e. to remove the RMI method calls 
between services and replace them with asynchronous messaging.  This 
might be another approach to abstracting between local/remote nodes
which could be an abstraction easily implemented by the proxies.

For us I think this makes sense, as we have designed some of our 
Services to be non-blocking, i.e. they append the message to a received 
queue and return instantly to the caller.  I'd be interested to hear if 
anyone else is doing this, and whether this sort of architecture is 
something that Jini/River could evolve to better support?

> I've been involved with a language called Scala lately, which has an  
> Erlang-like actors library. On the mailing list they keep talking  
> about issues with implementing remote actors. I as yet don't  
> understand these details either, but I keep getting this wierd  
> feeling that wheel reinvention is going on. They seem to be talking  
> about how to solve problems that Jini addressed almost 10 years ago.

I've only briefly glanced at Scala and didn't get to looking at Scala's 
actors, but if it's anything like Erlang I'd assume that their model is 
as I've described above (i.e. asynchronous, no guarantees etc...).  My 
guess is that they probably are solving *some* problems Jini has solved, 
but that Jini from the outside appears to be about synchronous 
RPC/RMI-like communication (even though it's not necessarily).

Erlang is great in how the environment allows you to code distributed 
code without worrying about the network at all.  And there is almost no 
configuration required (bar having a shared secret).  I'm guessing Scala 
want the same thing, and this need not preclude Jini, but I think you'd 
probably want to do what I've described above.

Other questions I think you'd need to answer would be Also, how does 
Jini's Lookup/Discovery fit in with this model, and would Scala actors 
really benefit from downloadable code?  If you take away downloadable 
code, implement your own asynchronous messaging and remove lookup and 
discovery, what benefits is Jini giving?

> So here's my question. I get the feeling that the trend to multi-core  
> architectures represents a disruptive technology shift that will  
> shake up the software industry to some extent. Does River have  
> something to offer here? If you expect the chips your software will  
> run on will have multiple cores, and maybe you don't know how many  
> until your program starts running, you'll want to organize your  
> software so it distributes processing across those cores dynamically.  
> Isn't JavaSpaces a good way to do that?

I don't have any practical experience with Javaspaces, but yes I think 
the Javaspace model is a good way to distribute processing for a certain 
class of problems.  From my perspective though it seems that Javaspaces 
are best suited to producer/consumer scenarios rather than as a 
messaging system where you want high throughput and low-latency (as I 
would assume is the case with Erlang/Scala Actors).

I'd be happy to hear other peoples views on this, particularly around 
asynchronous Jini etc...

Rick Moynihan
Software Engineer
Calico Jack LTD

View raw message