You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Bill Venners <bv...@artima.com> on 2007/09/29 17:07:52 UTC
Concurrency and River
Hi All,
I've been observing some wailing and gnashing of teeth lately in
various programming communities around what to do about the rise of
multi-core processors.
For example, the Python folks recently had some heated debate on
Artima, for example, about something called the Global Interpreter
Lock or GIL that in some way limits the concurrency potential of
CPython. I don't quite understand the details, but there sure seemed
to be some fear that if Python didn't make multi-threading easier, it
may become less relevant.
Brian Goetz has brought up that we may have frog-boiled ourselves
into an bad situation by adopting the model of shared state with
locks in Java. In general the shared state/locks model makes
concurrent programs difficult to reason about, but in particular this
approach to concurrency isn't composable. You can't safely combine
different modules without understanding the details of what they do
with locks and how they will interact.
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.
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.
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 think what it might mean is that you treat another core on the same
box running a worker thread the same as a worker thread across the
network. That way you have a uniform programming model, and when you
run out of cores, you just add more boxes and you get more worker
nodes. So it would be the opposite of the concept targeted by the
Note. Yes, you would use objects through a uniform interface, and
whether or not that object is implemented locally or remotely would
be an implementation detail of the object. But what you'd assume is
not that the thing is local (a thread on another core of the same
box) but remote.
Anyway, I was curious what everyone here thought. It may be a way to
position River in people's minds, give it a marketing story.
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
Hi Gregg,
On Oct 1, 2007, at 9:37 AM, Gregg Wonderly wrote:
> Bill Venners wrote:
>> Anyway, I was curious what everyone here thought. It may be a way
>> to position River in people's minds, give it a marketing story.
>
> I think this is a reasonable analogy to use. Some will still argue
> about the locking that occurs in the JavaSpaces server etc. But, I
> think there is some meat to the argument that the design of
> parallel systems should be thought of as a distributed computing
> problem.
>
I'm not sure what you mean about "the locking that occurs in the
JavaSpaces server," but if you mean that JavaSpaces is implemented
using shared state and locks, that's OK. When you send a message to
an actor there's locking and shared state going on in the actor's
message queue. What's important is that clients of the actors don't
need to explicitly lock anything. Client programmers can think at a
higher level of abstraction, and the model is composable. I think
such things would be true of a JavaSpaces compute grid model.
One complaint I can imagine is that you'd be using processes instead
of threads, except that you could have a single worker process with
many worker threads each operating independently. Even a master
thread could be doing the work of the master in the same process,
also independently. What people might find a bit odd is that
JavaSpaces itself is in a different process, and you have to go over
TCP/IP to pass jobs and results back and forth between master and
worker threads, even when those threads are in the same process.
But I think the answer to that could be that this is how you make it
possible to just add another box and scale horizontally when you need
more workers. One thing that is apparently true about actors, and
again sorry I don't understand this model very well as yet, is that
if your program works on one box it will work on many. That's a
pretty useful feat. In the case of JavaSpaces, what it would mean is
that you treat all objects the same whether they are remote or local,
because you treat them all as if they are remote. So you handle
partial failure of a different core on the same CPU, which is pretty
unlikely to ever happen. But it is worth hit, because when you do
that you can indeed just add more boxes with more cores and your app
scales.
Anyway, I was just speaking last week to a high-level director of
software at a large enterprise. I mentioned Jini and asked if he'd
heard of it. He said, "Oh yes, that's about writing software on
devices, right?" Jini has a new name now, River, so perhaps there's
an opportunity for a new marketing story. I have noticed that there
has been a lot of concern in the software community recently about
the coming proliferation of multi-core architectures. It smells like
a disruptive technology is coming, and that may be an opportunity to
explain River in a way that makes people feel it could help them
solve a real problem that they expect to be facing very soon.
Bill
Re: Concurrency and River
Posted by Gregg Wonderly <gr...@wonderly.org>.
Bill Venners wrote:
> Anyway, I was curious what everyone here thought. It may be a way to
> position River in people's minds, give it a marketing story.
I think this is a reasonable analogy to use. Some will still argue about the
locking that occurs in the JavaSpaces server etc. But, I think there is some
meat to the argument that the design of parallel systems should be thought of as
a distributed computing problem.
Gregg Wonderly
Re: Concurrency and River
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Bill and list:
Emphatically yes. See comments below.
Cheers,
Greg.
On Sat, 2007-09-29 at 11:07, Bill Venners wrote:
> Hi All,
>
> I've been observing some wailing and gnashing of teeth lately in
> various programming communities around what to do about the rise of
> multi-core processors.
> <snip>
> 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?
>
On a recent project that was doing substantial of data analysis and
corellation, the client had a radically overspeced (for two years ago)
server to deploy on. Dual Xeon with Hyperthreading and 4GB of memory.
With the hyperthreading, Windows Task Manager showed four processors.
In the two years I had been watching this particular server on other
projects, I had never seen two processors spiked simultaneously, and I
had never seen a sustained period of utilization over 10-15%.
I decided that for this analysis-heavy project, I was going to make
those dual processors warm up! I built the application as a data-flow
engine using Javaspaces, and simply set the number of concurrent workers
on the spaces high enough to load the processors (aside; since the
workers would often be waiting on entries to be completed by other
workers, it's not quite as simple as nworkers=ncpus). I figured it was
just an added bonus that I could add more workers on a different node if
necessary. I actually tested additional nodes and found that yes, they
did improve throughput, but we didn't need it in this case.
Anyway, when you hit the application with a query, you definitely see
all four CPU tracks go to 100%. Unfortunately, they only stay at 100%
about 25% of the time; the rest of the time they're waiting for the
Oracle database on another machine.
But definitely, Javaspaces is a good way to get all your cores working.
It may be that for smaller data packets, you might want to optimize the
communications (i.e. do some kind of in-memory communications rather
than going through the TCP/IP stack), but I suspect you'd have to have
very small packets for that to make much of a difference.
>
> Anyway, I was curious what everyone here thought. It may be a way to
> position River in people's minds, give it a marketing story.
>
Agreed; it's a decent hook.
--
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com
Re: Concurrency and River
Posted by Gregg Wonderly <gr...@wonderly.org>.
Mark Brouwer wrote:
> I haven't come to the part yet where they show how to transfer 'state'
> contained by a crashed or broken process to one that is going to use
> fixed code or where data structures significantly changed. I won't be
> disappointed though when it turns out there are some limitations about
> what can be achieved, because in general when people have surgery they
> are suspended as well.
I don't know about the Erlang software model, but I do know about certain
telephone switching systems, which use the fact that the already have support
for switching between duplex hardware elements as the starting point. They just
boot the new software on the "other side", but it stops short of starting to
touch the hardware. When the "software upgrade" switch over occurs, code
running on the "switched to" side, checks the version of the code on the
"switched from" side, and then performs data migration using cross memory access
primatives and structural templates appropriate for the "other sides" version.
So, if you use replication as a means for solving software scaling horizontally
(and hardware reliability as a result) you then might also have the choice to
use the same mechanisms to solve bugs in a running system.
I use Jini based discovery connectivity to do software upgrades in this fashion,
as I am sure many others in the community do as well. The question is, what
latency in such an operation, can a system tolerate. The less latancy is
tolerable, the more direct the switch needs to "appear to be". With dynamic
service references such as we use in many Jini based applications, it is
possible to "transactially" role from one service instance to another,
instantaneously.
Gregg Wonderly
Re: Concurrency and River
Posted by Mark Brouwer <ma...@cheiron.org>.
Rick Moynihan wrote:
> It's claimed that these properties have led to Erlang systems being
> created with 99.9999999% (9 9's) reliability.
Marketing at its best :-) From the Armstrong thesis: "For the Ericsson
AXD301 the only information on the long-term stability of the system
came from a power-point presentation showing some figures claiming that
a major customer had run an 11 node system with a 99.9999999%
reliability, though how these figure had been obtained was not
documented."
In his case studies chapter he mentions there have been various process
crashes although they have been able to upgrade the code to fix those
problems, and I must admit this is certainly impressive. Some
characteristics (just functions) in Erlang makes upgrading of code so
much easier than e.g. is possible with classes in Java.
I haven't come to the part yet where they show how to transfer 'state'
contained by a crashed or broken process to one that is going to use
fixed code or where data structures significantly changed. I won't be
disappointed though when it turns out there are some limitations about
what can be achieved, because in general when people have surgery they
are suspended as well.
--
Mark
Re: Concurrency and River
Posted by Rick Moynihan <ri...@calicojack.co.uk>.
Dan Creswell wrote:
> I've yet to see exactly how Erlang does failure detection of processes.
> I guess there might be some timeout value somewhere in respect of
> messages reaching a destination etc but I've not seen a description of
> this aspect of Erlang.
Failure detection in Erlang appears to occur, less at the message level
than at the process level. All processes whether local or remote are
typically seen as being unreliable.
> Further whilst Erlang might do failure detection (of a form) solving the
> issues of failure are the difficult bit and I'm less convinced Erlang
> offers much here. For example, one solution to failure is replication
> and it appears you are (unsurprisingly) left to do that for yourself
> right now. Putting my high-performance hat on I'd also point out that
> replication has recognized limits especially when it's done with
> transactions which leads to even more esoteric solutions that are
> largely about appropriate architecture/interactions and less about
> shared-nothing or message passing.
Erlang/OTP and failure handling are a *BIG* thing in Erlang, and are
touted as one of it's main strengths along with concurrency. Again, I'd
reiterate I don't have much practical experience with Erlang, but it
does seem to have a lot to offer in this regard.
Erlang/OTP provide a notion of supervisor processes and supervision
trees. Where failure/crashing of a process is detected by it's
supervisor who can then handle the failure appropriately (usually by
logging the error, or restarting the process according to a particular
restart strategy). Hand in hand with this is Erlang's dynamic code
updates, which mean that when part of a system crashes or fails you can
fix the error and deploy the fix to the live system, restarting *JUST*
the process that failed in a graceful manner.
It's claimed that these properties have led to Erlang systems being
created with 99.9999999% (9 9's) reliability.
--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/
Re: Concurrency and River
Posted by Thor Wolpert <th...@lunartek.com>.
A timely article?
http://www.theserverside.com/tt/knowledgecenter/knowledgecenter.tss?
l=ConcurrencyTestingJavaApps&asrc=EM_NLN_2350350&uid=2626495
Cheers,
Thor HW
On 4-Oct-07, at 9:21 AM, Bill Venners wrote:
> Hi Mark,
>
> On Oct 4, 2007, at 2:53 AM, Mark Brouwer wrote:
>
>> Hi Bill,
>>
>> Your posting related to your intentions with SuiteRunner and
>> Jini/JavaSpaces made me think a bit more about the relation
>> between Java
>> and Scala, so I have some additional questions.
>>
>> Mark Brouwer wrote:
>>
>>> Also Scala is lacking a strong security model which, if you take
>>> code
>>> mobility into account, seems to be a necessity.
>>
>> I think I talked BS here, and I need some help to really try to
>> understand the relation between Scala en Java the Platform and verify
>> whether I made an incorrect statement.
>>
>> The reason why I said Scala is lacking a strong security model was
>> because when I first read about Scala the language (over a year
>> ago) I
>> read about Scala for the JVM and .Net and that Scala the language
>> could
>> easily integrate with Java en C#.
>>
>> So for me Scala represented:
>>
>> the language
>> the class libraries written in Scala (packages scala.)
>> the VM (either .Net or JVM)
>>
>> At that time I found no notion of a security model in the
>> documentation
>> or the API. But now that I looked better I even can't find a String
>> class or IO libraries etc. in the class libraries. When looking at
>> some
>> examples and reading some documentation I noticed that a string
>> resolves
>> to java.lang.String and that the Java libraries are almost used for
>> everything low level (networking, IO, etc.).
>>
> java.lang is imported automatically in any Scala source file, as in
> Java. So when you say String you get java.lang.String.
>
>> Am I correct that Scala the environment actually represents:
>>
>> the language
>> the class libraries written in Scala
>> the class libraries as specified for the Java Platform
>> the JVM (I can't find a reference for .net anymore on
>> http://www.scala-lang.org/)
>>
>> Or in other words is a requirement for Scala that Java the class
>> libraries is available. If that is the case it seems Scala
>> inherits the
>> Java security model by default and I would qualify it to be on
>> par, i.e.
>> having a strong security model. Although I don't know whether in that
>> case 'Scala the class libraries' also call into
>> SecurityManager/AccessController to protect certain operations.
>>
> Scala is compiled to Java bytecodes. I don't know of anything it
> offers in its libraries that would need to call the access
> controller. Scala is a thin layer on top of the Java API. The main
> libraries you use instead of Java libraries are Scala's
> collections. But to read from a file you use java.io.FileReader or
> what not. To read from a socket you'd use java.net.Socket, etc.
>
>> If the above assumption is true and the integration of Scala and
>> Java is
>> seamless then one could argue that everything that is available to
>> Java
>> is available to Scala. Wouldn't that mean that there are a huge
>> number
>> of web frameworks, unit test frameworks and also distributed
>> technologies available to Scala. Or is it the case that while they
>> are
>> available there is some idiom mismatch when being used in Scale
>> and that
>> for that reason you want to have a pure Scala SuiteRunner, one
>> that will
>> rely though on a lot of calls into the Java class libraries.
>>
> That's correct. Scala is binary compatible with the Java API and
> JVMs and any Java library or framework out there. The only thing it
> isn't compatible with is tools that work directly with Java soruce
> code. What Scala is not compatible with is that Scala code isn't
> valid Java code.
>
> There is also a version of Scala that compiles to .NET, but the
> LAMP team stopped supporting it many versions ago. It is open
> source, so its future depends on someone picking it up and
> continuing it. But Martin Odersky and his team is focused on the JVM.
>
>> The reason why I also ask is that e.g. Seven is a great
>> development and
>> deployment Platform for Jini services that solves a great bunch of
>> things that are quite hard to arrange yourself (code mobility and
>> configuration only a few of them) and if there could be Scala
>> version of
>> the JSC API that runs on top of the Java version I think the Scala
>> environment would have a another nice distributed computing platform
>> which could cooperate between any other Jini service, either
>> implemented
>> in pure Java or a mixture of Scala and Java.
>>
>> I can even imagine that there can be layers over the current net.jini
>> utilities as part of the River project that would bring them into the
>> Scala idiom.
>
> Yes, I call that "scalifying" your API. That's sort of what I'm
> doing with SuiteRunner. In the old Java SuiteRunner, to test
> whether a method throws an exeception, you write:
>
> try {
> someMethod("hi", null, "there");
> fail();
> }
> catch (NullPointerException e) {
> // expected
> }
>
> In Scala you can wrap such boilerplate code in a method and pass in
> a closure. So with the new SuiteRunner you can just write:
>
> expectNPE {
> someMethod("hi", null, "there")
> }
>
> This makes the API easier to read and use. Another example is
> java.math.BigInteger. Scala does define a scala.BigInt class that
> "scalifies" BigInteger. To use BigInteger, you would write:
>
> x.multiply(factorial(x.subtract(BigInteger.ONE)))
>
> whereas with Scala's BigInt you can write:
>
> x * factorial(x - 1)
>
> Since SuiteRunner didn't get much adoption in the past, instead of
> just Scalafying it, which means I'd wrap the Java API with a Scala
> layer, I decided to go ahead and just transform it to Scala
> completely. People who were using the old Java SuiteRunner can
> still continue to use the last release, but the new version may not
> run tests written for the old version without some changes, though
> in fact most of them would probably still continue to work.
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
>
>
>
>
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
Hi Mark,
On Oct 4, 2007, at 2:53 AM, Mark Brouwer wrote:
> Hi Bill,
>
> Your posting related to your intentions with SuiteRunner and
> Jini/JavaSpaces made me think a bit more about the relation between
> Java
> and Scala, so I have some additional questions.
>
> Mark Brouwer wrote:
>
>> Also Scala is lacking a strong security model which, if you take code
>> mobility into account, seems to be a necessity.
>
> I think I talked BS here, and I need some help to really try to
> understand the relation between Scala en Java the Platform and verify
> whether I made an incorrect statement.
>
> The reason why I said Scala is lacking a strong security model was
> because when I first read about Scala the language (over a year ago) I
> read about Scala for the JVM and .Net and that Scala the language
> could
> easily integrate with Java en C#.
>
> So for me Scala represented:
>
> the language
> the class libraries written in Scala (packages scala.)
> the VM (either .Net or JVM)
>
> At that time I found no notion of a security model in the
> documentation
> or the API. But now that I looked better I even can't find a String
> class or IO libraries etc. in the class libraries. When looking at
> some
> examples and reading some documentation I noticed that a string
> resolves
> to java.lang.String and that the Java libraries are almost used for
> everything low level (networking, IO, etc.).
>
java.lang is imported automatically in any Scala source file, as in
Java. So when you say String you get java.lang.String.
> Am I correct that Scala the environment actually represents:
>
> the language
> the class libraries written in Scala
> the class libraries as specified for the Java Platform
> the JVM (I can't find a reference for .net anymore on
> http://www.scala-lang.org/)
>
> Or in other words is a requirement for Scala that Java the class
> libraries is available. If that is the case it seems Scala inherits
> the
> Java security model by default and I would qualify it to be on par,
> i.e.
> having a strong security model. Although I don't know whether in that
> case 'Scala the class libraries' also call into
> SecurityManager/AccessController to protect certain operations.
>
Scala is compiled to Java bytecodes. I don't know of anything it
offers in its libraries that would need to call the access
controller. Scala is a thin layer on top of the Java API. The main
libraries you use instead of Java libraries are Scala's collections.
But to read from a file you use java.io.FileReader or what not. To
read from a socket you'd use java.net.Socket, etc.
> If the above assumption is true and the integration of Scala and
> Java is
> seamless then one could argue that everything that is available to
> Java
> is available to Scala. Wouldn't that mean that there are a huge number
> of web frameworks, unit test frameworks and also distributed
> technologies available to Scala. Or is it the case that while they are
> available there is some idiom mismatch when being used in Scale and
> that
> for that reason you want to have a pure Scala SuiteRunner, one that
> will
> rely though on a lot of calls into the Java class libraries.
>
That's correct. Scala is binary compatible with the Java API and JVMs
and any Java library or framework out there. The only thing it isn't
compatible with is tools that work directly with Java soruce code.
What Scala is not compatible with is that Scala code isn't valid Java
code.
There is also a version of Scala that compiles to .NET, but the LAMP
team stopped supporting it many versions ago. It is open source, so
its future depends on someone picking it up and continuing it. But
Martin Odersky and his team is focused on the JVM.
> The reason why I also ask is that e.g. Seven is a great development
> and
> deployment Platform for Jini services that solves a great bunch of
> things that are quite hard to arrange yourself (code mobility and
> configuration only a few of them) and if there could be Scala
> version of
> the JSC API that runs on top of the Java version I think the Scala
> environment would have a another nice distributed computing platform
> which could cooperate between any other Jini service, either
> implemented
> in pure Java or a mixture of Scala and Java.
>
> I can even imagine that there can be layers over the current net.jini
> utilities as part of the River project that would bring them into the
> Scala idiom.
Yes, I call that "scalifying" your API. That's sort of what I'm doing
with SuiteRunner. In the old Java SuiteRunner, to test whether a
method throws an exeception, you write:
try {
someMethod("hi", null, "there");
fail();
}
catch (NullPointerException e) {
// expected
}
In Scala you can wrap such boilerplate code in a method and pass in a
closure. So with the new SuiteRunner you can just write:
expectNPE {
someMethod("hi", null, "there")
}
This makes the API easier to read and use. Another example is
java.math.BigInteger. Scala does define a scala.BigInt class that
"scalifies" BigInteger. To use BigInteger, you would write:
x.multiply(factorial(x.subtract(BigInteger.ONE)))
whereas with Scala's BigInt you can write:
x * factorial(x - 1)
Since SuiteRunner didn't get much adoption in the past, instead of
just Scalafying it, which means I'd wrap the Java API with a Scala
layer, I decided to go ahead and just transform it to Scala
completely. People who were using the old Java SuiteRunner can still
continue to use the last release, but the new version may not run
tests written for the old version without some changes, though in
fact most of them would probably still continue to work.
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: Concurrency and River
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Bill,
Your posting related to your intentions with SuiteRunner and
Jini/JavaSpaces made me think a bit more about the relation between Java
and Scala, so I have some additional questions.
Mark Brouwer wrote:
> Also Scala is lacking a strong security model which, if you take code
> mobility into account, seems to be a necessity.
I think I talked BS here, and I need some help to really try to
understand the relation between Scala en Java the Platform and verify
whether I made an incorrect statement.
The reason why I said Scala is lacking a strong security model was
because when I first read about Scala the language (over a year ago) I
read about Scala for the JVM and .Net and that Scala the language could
easily integrate with Java en C#.
So for me Scala represented:
the language
the class libraries written in Scala (packages scala.)
the VM (either .Net or JVM)
At that time I found no notion of a security model in the documentation
or the API. But now that I looked better I even can't find a String
class or IO libraries etc. in the class libraries. When looking at some
examples and reading some documentation I noticed that a string resolves
to java.lang.String and that the Java libraries are almost used for
everything low level (networking, IO, etc.).
Am I correct that Scala the environment actually represents:
the language
the class libraries written in Scala
the class libraries as specified for the Java Platform
the JVM (I can't find a reference for .net anymore on
http://www.scala-lang.org/)
Or in other words is a requirement for Scala that Java the class
libraries is available. If that is the case it seems Scala inherits the
Java security model by default and I would qualify it to be on par, i.e.
having a strong security model. Although I don't know whether in that
case 'Scala the class libraries' also call into
SecurityManager/AccessController to protect certain operations.
If the above assumption is true and the integration of Scala and Java is
seamless then one could argue that everything that is available to Java
is available to Scala. Wouldn't that mean that there are a huge number
of web frameworks, unit test frameworks and also distributed
technologies available to Scala. Or is it the case that while they are
available there is some idiom mismatch when being used in Scale and that
for that reason you want to have a pure Scala SuiteRunner, one that will
rely though on a lot of calls into the Java class libraries.
The reason why I also ask is that e.g. Seven is a great development and
deployment Platform for Jini services that solves a great bunch of
things that are quite hard to arrange yourself (code mobility and
configuration only a few of them) and if there could be Scala version of
the JSC API that runs on top of the Java version I think the Scala
environment would have a another nice distributed computing platform
which could cooperate between any other Jini service, either implemented
in pure Java or a mixture of Scala and Java.
I can even imagine that there can be layers over the current net.jini
utilities as part of the River project that would bring them into the
Scala idiom.
--
Mark
Re: Concurrency and River
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Bill,
In advance sorry for the lengthy response, but your postings cover a lot
of areas.
Bill Venners wrote:
> Concurrency may be difficult to reason about in general, but some models
> are more difficult than others. Some models make it impossible to trip
> in certain ways, just as it is impossible in Java bytecodes to free a
> pointer to memory twice. As I understand it, Erlang prevents deadlock by
> only allowing threads to interact via messages. Transactional memory can
> still produce starved threads that keep retrying and keep getting rolled
> back, but the app as a whole will make progress because some threads
> will be getting stuff done. Java's basic model of synchronization is a
> bit more like a mine field, because you have to understand the whole
> application, including everything libraries are doing with locks and
> callbacks and such, to be sure there are no potential deadlocks. And
> that's really hard to do by analysis, and it is hard to detect problems
> via testing because they can happen quite rarely.
I agree with your notion above, although I really wonder to what extent
models employed by Erlang or other functional languages and
'asynchronous message libraries' move the difficulties involved with
parallel/distributed programming to another place, a place that might be
equally hard to reason about by the average programmer.
My involvement with functional languages (besides XSLT) has not extended
beyond the trivial cases which might give you a feeling of victory. As
Dan mentioned I think there are a lot of people pursuing a silver bullet
here and while getting older, I found that most shiny things turn into
rusty old pieces the longer you work with them.
While reading the Erlang book I was constantly thinking where do I leave
my state that must be accessible by other processes and how can I query
it. Probably not strange when you learned programming as an 11 years old
with BBC Basic (this will earns me some credits by the English people I
guess) with integrated assembler for the MOS 6502, then C and then Java
so I have to realign a lot of brain cells. Although it might be that a
nice mixture of functional and imperative programming (such as Scala) is
the way to go.
I think it would be interesting to see somebody implement the equivalent
of e.g. ServiceDiscoveryManager in Erlang or Scala and see whether that
would be really easier to implement and reason about. If that is the
case it would argue in favor share-nothing message passing.
> If you have a JavaSpaces client that looks at how many CPUs or cores it
> has to work with when it starts up, and fires up one master thread and
> enough worker threads to keep all those cores busy, assuming each thread
> is an independent guy that only communicates with other threads over the
> network via a JavaSpace, then those threads can't deadlock. (Though I
> supposed you could design a JavaSpace protocol that could hang them up.)
> I'm not trying to promote Erlang's approach, only to point out that it
> is getting a lot of buzz, because people are thinking about multi-core.
Sometimes I wonder whether the exposure of Erlang is only due to
multi-core. SMP machines are out for a long time already as are
multi-core CPUs. I can't withdraw myself from the impression that in
general a lot of languages are getting a lot of attention because Java
has become the new COBOL and there is so much API/technologies, etc. in
the Java world that people are longing for newer grounds where they can
explore and comprehend the complete landscape and make a difference.
More than 10 year of Java experience and I seem to know less than after
the first year of Java which frustrates me at times. And it is clear
that Java is probably too static for a lot of purposes given all the
bytecode manipulation and reflection going on these days which often can
be handled by some dynamic language much more elegant. And at the same
time Java is doing rather bad (in market acceptance) in the areas it was
designed for and for which the strong security model and mobile code
really made sense and which seems to be what really sets it apart from
other languages/platforms.
Note also that distributed Erlang (messaging) is based on a trusted
environment while the original Jini goals were an untrusted environment.
I have no idea yet of the exact code mobility characteristics of Erlang
but it will be interesting to see how they will be dealing with that.
Also Scala is lacking a strong security model which, if you take code
mobility into account, seems to be a necessity.
> I'm not sure how NUMA would affect things, but local versus remote
> JavaSpaces solves this problem very elegantly, and has for a long time.
> The change in the status quo is that the rise of multi-core means more
> people will be trying to figure out how to do this kind of parallel
> processing than before. To exploit multi-core, you have to figure out
> how to partition your app so that you can do parallel processing. You
> have to find the parallelism. If you actually can do that, you next have
> to figure out how to implement it. The opportunity I see for River is a
> marketing one, to simply try and promote the idea that JavaSpaces can be
> used to solve this kind of problem. So when people face the problem
> someday, they'll think of JavaSpaces.
I think that by definition most client-server applications are already
designed with parallelism in mind, although maybe many of them put the
actual handling of that towards the database and work through
database transactions. These systems must have been exposed to SMP
systems because after all the Sun E10000 with 64 CPUs is already more
than 10 years old and in that time I even worked with an E450 that had 4
CPUs and I've seen a lot of 8 CPU boxes in banks. So for many of us this
is not really new and I think for those working with Jini parallelism is
like a second nature, which doesn't mean it is easy, the contrary.
What we see though is that a lot of single threaded applications that
were able to get 100% CPU utilizations are not able to take advantage of
all those cores and for them it will require a shift in thinking.
Although for many applications I think it is enough to think of a
problem as a local parallelization problem versus a distributed
parallelization problem and doubt whether JavaSpaces is the best way to
go. So I'm hesitating to submit a Wide Finder implementation
based on a (local) JavaSpace to Tim Bray ;-)
> Is it still called JavaSpaces? Jini isn't called Jini anymore. What
> about JavaSpaces?
I guess so, JavaSpaces still represent the JavaSpace specification. As
the incubator reports mention "River is aimed at the development and
advancement of the Jini technology core infrastructure" I also think
Jini is still alive and kicking although still not a noun, so I think it
is not correct to state that Jini isn't called Jini anymore.
--
Mark
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
Hi Dan,
On Oct 1, 2007, at 12:26 PM, Dan Creswell wrote:
>> Brian Goetz has brought up that we may have frog-boiled ourselves
>> into
>> an bad situation by adopting the model of shared state with locks in
>> Java. In general the shared state/locks model makes concurrent
>> programs
>> difficult to reason about, but in particular this approach to
>> concurrency isn't composable. You can't safely combine different
>> modules
>> without understanding the details of what they do with locks and how
>> they will interact.
>>
>
> That's just about the consequences of shared state with concurrent
> access be it using locks or transactional memory etc.
>
> And I think in general concurrency is difficult to reason about
> even in
> message based systems with shared nothing because you still have
> issues
> of failure to deal with including how that might impact message
> delivery.
>
Concurrency may be difficult to reason about in general, but some
models are more difficult than others. Some models make it impossible
to trip in certain ways, just as it is impossible in Java bytecodes
to free a pointer to memory twice. As I understand it, Erlang
prevents deadlock by only allowing threads to interact via messages.
Transactional memory can still produce starved threads that keep
retrying and keep getting rolled back, but the app as a whole will
make progress because some threads will be getting stuff done. Java's
basic model of synchronization is a bit more like a mine field,
because you have to understand the whole application, including
everything libraries are doing with locks and callbacks and such, to
be sure there are no potential deadlocks. And that's really hard to
do by analysis, and it is hard to detect problems via testing because
they can happen quite rarely.
If you have a JavaSpaces client that looks at how many CPUs or cores
it has to work with when it starts up, and fires up one master thread
and enough worker threads to keep all those cores busy, assuming each
thread is an independent guy that only communicates with other
threads over the network via a JavaSpace, then those threads can't
deadlock. (Though I supposed you could design a JavaSpace protocol
that could hang them up.)
>> 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.
>>
>
> I've yet to see exactly how Erlang does failure detection of
> processes.
> I guess there might be some timeout value somewhere in respect of
> messages reaching a destination etc but I've not seen a description of
> this aspect of Erlang.
>
> Further whilst Erlang might do failure detection (of a form)
> solving the
> issues of failure are the difficult bit and I'm less convinced Erlang
> offers much here. For example, one solution to failure is replication
> and it appears you are (unsurprisingly) left to do that for yourself
> right now. Putting my high-performance hat on I'd also point out that
> replication has recognized limits especially when it's done with
> transactions which leads to even more esoteric solutions that are
> largely about appropriate architecture/interactions and less about
> shared-nothing or message passing.
>
I'm not trying to promote Erlang's approach, only to point out that
it is getting a lot of buzz, because people are thinking about multi-
core.
>> 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.
>>
>> 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 think what it might mean is that you treat another core on the same
>> box running a worker thread the same as a worker thread across the
>> network. That way you have a uniform programming model, and when
>> you run
>> out of cores, you just add more boxes and you get more worker
>> nodes. So
>> it would be the opposite of the concept targeted by the Note. Yes,
>> you
>> would use objects through a uniform interface, and whether or not
>> that
>> object is implemented locally or remotely would be an implementation
>> detail of the object. But what you'd assume is not that the thing is
>> local (a thread on another core of the same box) but remote.
>>
>
> Hmmmm, so the uniform model concept is nice and cleans out one
> difficulty but there are some others lying around in this which I
> reckon
> are in need of consideration:
>
> (1) A number of multi-core systems are threatening to head towards
> NUMA
> type architectures where the cost of comms is in part related to the
> number of memory spaces you have to hop.
>
> (2) There's at least some (significant?) difference between comms
> performance across processors in the same box versus across a network
> and therefore the protocols you design and what you pass around in
> messages might be somewhat different.
I'm not sure how NUMA would affect things, but local versus remote
interfaces usually get into considering chatty versus chunky designs.
So my feeling was that if you really are going to just only ever want
to exploit multiple cores on one box, JavaSpaces would be overkill
because you can reasonably rule out partial failure. In the case when
someone wants to exploit multiple cores, but also either distribute
processing across the network as well, or at least leave the door
open, make it easy to distribute across the network in the future,
that JavaSpaces has a compelling solution.
I can imagine J2EE people all over the place in a few years
scratching their heads about how they will take advantage of multiple
cores for tasks they need done. Will they run a separate J2EE app
server on each core? Seems like they could run one app server with
multiple threads on each box. But then how do you distribute tasks to
those threads? JMS doesn't have a take semantic. I suppose they could
install a load balancer in front of a cluster, and have a master
server firing jobs into the load balancer.
JavaSpaces solves this problem very elegantly, and has for a long
time. The change in the status quo is that the rise of multi-core
means more people will be trying to figure out how to do this kind of
parallel processing than before. To exploit multi-core, you have to
figure out how to partition your app so that you can do parallel
processing. You have to find the parallelism. If you actually can do
that, you next have to figure out how to implement it. The
opportunity I see for River is a marketing one, to simply try and
promote the idea that JavaSpaces can be used to solve this kind of
problem. So when people face the problem someday, they'll think of
JavaSpaces.
Is it still called JavaSpaces? Jini isn't called Jini anymore. What
about JavaSpaces?
Thanks.
Bill
Re: Concurrency and River
Posted by Mark Brouwer <ma...@cheiron.org>.
Bill Venners wrote:
> Hi Mark,
>
> On Oct 3, 2007, at 2:16 PM, Mark Brouwer wrote:
>
>>> To speed up unit testing, my idea has been that I keep a SuiteRunner
>>> server VM running at all time while developing, and when I run tests
>>> what I actually do is feed jobs to that server. This way I could
>>> avoid starting up a new JVM each time I want to run a test. So what
>>> seems to make sense is to embed a JavaSpace inside that SuiteRunner
>>> server.
>>
>> Assuming you keep the SuiteRunner JVM running and submit suites through
>> a JavaSpace you will likely run into what I think a lot of people also
>> consider the hard parts of working with Jini/RMI (and often overlooked)
>> namely that you must make sure that you will be able to provide as a
>> codebase annotation all classes your test suites will depend on.
>> Assuming people are able to do that you will likely run into the fact
>> the JVM that is about to (re)execute the testsuites has those JAR files
>> cached (you can also prevent from using JAR files though).
>>
> Wouldn't the JVM not cache JARs if the HTTP response header says
> cache-control: no cache?
No, at least the default jar: protocol handler for the Sun JRE has a JAR
file cache works the way I mentioned, for the IBM JRE as well, which
makes me believe that this is true for every Java licensee.
When a class loader requires a JAR file to obtain the class definition
or some other resource it will go through the JAR protocol handler, with
an exception I deal with later, and when the JAR file has been
downloaded once it will reuse the cached (local) JAR file.
This behavior can be understood from the class loader perspective in
which you don't want to download a remote JAR file for each time you
want to obtain a class definition and for which consistency of classes
relative to each other is important. The default jar: protocol handler
and cache logic ignores cache-control directives and performs no checks
for If-Modified-Since.
This is exactly the reason why in many application servers you often run
into problems with the application server not seeing updated classes
when they act as a Jini client. Although I won't go to deep into the
details and don't want to make a marketing pitch but Seven provides a
platform that does solve a lot of these things by deploying a jar:
protocol handler for which there is a 2 layer cache in which one layer
of the cache is bound to the class loader (and any child class loaders)
that uses cached JAR files from a common JAR file pool that is populated
with all JAR files to be downloaded and that keeps track of different
versions (check If-Modified-Since, etc.). When a new class loader tree
is created it will see the latest consistent collection of JAR files
even while other class loader might see an older but also consistent
view of the JAR files. This cache is also persistent in that it can
survive JVM restarts so in case the mobile code is no longer available
over the network you can still continue to work as if it is there (this
is required to make your services/clients less dependent on the
availability of mobile code). Also it provides in immense speedup in
case you have minimal bandwidth such as over the Internet or when you
have only a T1 connection to your data center.
The jar: protocol handler could be modified to work in other
environments although for various reasons recently I went for a tighter
integration to the class loader creation logic and container provided
persistence. But principles and techniques can be applied for any
container. It is however not possible to do this is in a generic way
(that I know of) for the Java Platform (otherwise I think it would have
been done I guess) for it is closely tied to the life-cycle of the
components you deploy in your environment.
>> There are ways to solve some of these problems by making sure you end up
>> with a different codebase annotation each time or configuring e.g. a
>> smart jar: protocol handler (you can find one in the Seven source code)
>> for your JVM that doesn't caches JAR files but is able to verify
>> whether a newer JAR file is available and will use the newer JAR files
>> for new class loaders created.
>>
> I suppose there could also be a local mode in which classes are loaded
> off the local disk through a new URLClassLoader created each run. This
> is what SuiteRunner does now. This is probably what most developers
> would want to do at their workstations.
Correct, in local mode you don't have that particular problem because
the URLClassLoader doesn't use the jar: protocol handler logic when it
detects it is dealing with a file URL. In that case it will perform some
optimizations and use the JAR file directly. Note that this is an
implementation detail of the current URLClassLoader implementations I
found in the field.
However on Windows you might run into another nasty problem when you
have a long running JVM. When JAR files are used by URLClassLoader on
Windows a file lock is obtained by the JVM that will only be released
when the JVM exits. The consequence of this is that while your JVM is
running you won't be able to overwrite the JAR files by e.g. your build
process on Windows.
For this reason Seven transforms all URLs that have the file protocol
and that are used for server side class loaders into a custom dfile
protocol so that this optimization by URLClassLoader doesn't take place
and when I dispose a class loader (explicitly or through GC) I
explicitly close the underlying JAR files.
As you can see proper handling of class evolution is a very painful
exercise and my experience is that most environments don't bring much
help to their developers. I know of people that work with Seven in
development in which they have their containers running for weeks (even
months) and in which they have upgraded various services in the
container hundreds of times and that they see updates made to mobile
code of other services in the network (no Seven deployed Jini services).
SuiteRunner in the typical case is started each time for running a set
of test suites, in your posting you indicate you want to have it running
as long lasting process. I think you should be aware of these cases then.
It can be sorted out, but it is a complicated matter, but principles I
applied in the Jini Service Container can be applied of course in any
other framework/platform. For more information and pointers into the
code feel free to ask questions.
> I'd forgotten about that. Hmm. Since you kind of made a little fork,
> would it be alright with you if I didn't make new releases of the Java
> SuiteRunner going forward?
That is OK with me, you were so kind to relicense to ALv2 just for me so
I can evolve when needed.
--
Mark
Re: Concurrency and River
Posted by Tom White <to...@gmail.com>.
I had some success distributing JUnit tests using JavaSpaces as a part
of my ComputeFarm project (https://computefarm.dev.java.net/). It's
been a couple of years, but I think the ideas and code may still be
relevant. See https://computefarm.dev.java.net/samples.html for a
short description.
Cheers,
Tom
On 04/10/2007, Bill Venners <bv...@artima.com> wrote:
> Hi Mark,
>
> On Oct 3, 2007, at 2:16 PM, Mark Brouwer wrote:
>
> >> To speed up unit testing, my idea has been that I keep a
> >> SuiteRunner server VM running at all time while developing, and
> >> when I run tests what I actually do is feed jobs to that server.
> >> This way I could avoid starting up a new JVM each time I want to
> >> run a test. So what seems to make sense is to embed a JavaSpace
> >> inside that SuiteRunner server.
> >
> > Assuming you keep the SuiteRunner JVM running and submit suites
> > through
> > a JavaSpace you will likely run into what I think a lot of people also
> > consider the hard parts of working with Jini/RMI (and often
> > overlooked)
> > namely that you must make sure that you will be able to provide as a
> > codebase annotation all classes your test suites will depend on.
> > Assuming people are able to do that you will likely run into the fact
> > the JVM that is about to (re)execute the testsuites has those JAR
> > files
> > cached (you can also prevent from using JAR files though).
> >
> Wouldn't the JVM not cache JARs if the HTTP response header says
> cache-control: no cache?
>
> > There are ways to solve some of these problems by making sure you
> > end up
> > with a different codebase annotation each time or configuring e.g. a
> > smart jar: protocol handler (you can find one in the Seven source
> > code)
> > for your JVM that doesn't caches JAR files but is able to verify
> > whether a newer JAR file is available and will use the newer JAR files
> > for new class loaders created.
> >
> I suppose there could also be a local mode in which classes are
> loaded off the local disk through a new URLClassLoader created each
> run. This is what SuiteRunner does now. This is probably what most
> developers would want to do at their workstations.
>
> > I do wonder whether in general people have unit tests that really take
> > a long time to run, I have only a few that take a long time to
> > complete
> > and these are for testing concurrency utilities such a thread pools,
> > blocking queues, etc. Parallelism helps a lot here because the tests
> > themselves are not consuming any significant CPU most of the time, but
> > there is no need to distribute these, local parallelization is good
> > enough.
> >
> Well, I know there are companies who make money selling solutions
> that make builds run faster. This would be a tool that makes tests
> run faster. As cores multiply, it makes sense to me to exploit them
> to make tests run faster on developer's boxes. Need not be
> distributed to other boxes. Although on a continuous integration
> server, distribution might make sense. On a developer's box, you
> don't need to run every test every time, but on the continuous
> integration server you do, repeatedly. If you can speed up the cycles
> by adding a few old computers to the grid, I think people would see
> that as a good thing.
>
> > BTW I'm still using your modified SuiteRunner code to make it use
> > PreferredClassProvider/PreferredClassLoader, control the codebase
> > annotation for serving JAR files of mobile code from an integrated
> > HTTP
> > server and have written a Ant task for it, as well as a JUnit XML
> > reporter so you can use the Ant junitreport. I needed those changes to
> > have it act as a proper Jini client that was able to serve mobile code
> > to the services I test through SuiteRunner. Everything is available
> > through the Cheiron project under the ALv2, if you have any questions
> > you know where to find me for I think I've solved some of the problems
> > you might run into.
> I'd forgotten about that. Hmm. Since you kind of made a little fork,
> would it be alright with you if I didn't make new releases of the
> Java SuiteRunner going forward?
>
> Bill
>
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
Hi Mark,
On Oct 3, 2007, at 2:16 PM, Mark Brouwer wrote:
>> To speed up unit testing, my idea has been that I keep a
>> SuiteRunner server VM running at all time while developing, and
>> when I run tests what I actually do is feed jobs to that server.
>> This way I could avoid starting up a new JVM each time I want to
>> run a test. So what seems to make sense is to embed a JavaSpace
>> inside that SuiteRunner server.
>
> Assuming you keep the SuiteRunner JVM running and submit suites
> through
> a JavaSpace you will likely run into what I think a lot of people also
> consider the hard parts of working with Jini/RMI (and often
> overlooked)
> namely that you must make sure that you will be able to provide as a
> codebase annotation all classes your test suites will depend on.
> Assuming people are able to do that you will likely run into the fact
> the JVM that is about to (re)execute the testsuites has those JAR
> files
> cached (you can also prevent from using JAR files though).
>
Wouldn't the JVM not cache JARs if the HTTP response header says
cache-control: no cache?
> There are ways to solve some of these problems by making sure you
> end up
> with a different codebase annotation each time or configuring e.g. a
> smart jar: protocol handler (you can find one in the Seven source
> code)
> for your JVM that doesn't caches JAR files but is able to verify
> whether a newer JAR file is available and will use the newer JAR files
> for new class loaders created.
>
I suppose there could also be a local mode in which classes are
loaded off the local disk through a new URLClassLoader created each
run. This is what SuiteRunner does now. This is probably what most
developers would want to do at their workstations.
> I do wonder whether in general people have unit tests that really take
> a long time to run, I have only a few that take a long time to
> complete
> and these are for testing concurrency utilities such a thread pools,
> blocking queues, etc. Parallelism helps a lot here because the tests
> themselves are not consuming any significant CPU most of the time, but
> there is no need to distribute these, local parallelization is good
> enough.
>
Well, I know there are companies who make money selling solutions
that make builds run faster. This would be a tool that makes tests
run faster. As cores multiply, it makes sense to me to exploit them
to make tests run faster on developer's boxes. Need not be
distributed to other boxes. Although on a continuous integration
server, distribution might make sense. On a developer's box, you
don't need to run every test every time, but on the continuous
integration server you do, repeatedly. If you can speed up the cycles
by adding a few old computers to the grid, I think people would see
that as a good thing.
> BTW I'm still using your modified SuiteRunner code to make it use
> PreferredClassProvider/PreferredClassLoader, control the codebase
> annotation for serving JAR files of mobile code from an integrated
> HTTP
> server and have written a Ant task for it, as well as a JUnit XML
> reporter so you can use the Ant junitreport. I needed those changes to
> have it act as a proper Jini client that was able to serve mobile code
> to the services I test through SuiteRunner. Everything is available
> through the Cheiron project under the ALv2, if you have any questions
> you know where to find me for I think I've solved some of the problems
> you might run into.
I'd forgotten about that. Hmm. Since you kind of made a little fork,
would it be alright with you if I didn't make new releases of the
Java SuiteRunner going forward?
Bill
Re: Concurrency and River
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Bill,
With the risk this gets too much a discussion Erlang versus Scala
versus Java, nevertheless I think it ain't that harmful to have these
discussions here given the fact that distribution and parallelization
are subjects that go hand in hand with Jini.
Bill Venners wrote:
> Hi Dan,
>
> On Oct 1, 2007, at 12:26 PM, Dan Creswell wrote:
>
>> Hi Bill,
>>
>> I think your idea is an interesting one and certainly and I think the
>> lessons learnt from Jini would be valuable in this area though I'm not
>> sure that Jini in its current incarnation is the correct base to start
>> from. That of course might provide us with a target to evolve
>> towards.....or perhaps we start a side-project for this work, who knows?
>>
> I spoke with Allen Holub a couple hours ago about actors, and one of the
> things I learned was that actors don't really have a parallel processing
> story. Actors have little message queues, and they sit there processing
> and sending messages to other actors, so if you were to, say, model
> compute workers as actors, you'd still have the problems of dividing the
> work up and figuring out how to send jobs as messages to the worker
> actors, deal with failure, etc.
From the above and my reading of actors in Scala it seems a messaging
library can be utilized in Java for this purpose and just using queues
and immutable objects ain't that different, although the Scala syntax
probably providers a smoother integration. But if Java gets closures it
will be possible to make a lot of code look more beautiful, the huge
amount of boilerplate code in my code e.g. to restore the security
context, perform privileged operations, introduce final variables to
access variables outside anonymous classes is indeed appalling at times.
One thing that I consider a drawback in Scala compared to Erlang e.g. is
that actors are not cheap in Scala either as they are implemented on top
of a thread pool. In the Armstrong thesis I referred to earlier it seems
the ATM switch was modeled in a way that each connection (of which can
be over a 100000) had a large number of processes associated with it
(they even ran into the limitations that earlier versions of Erlang/OTP
didn't handle over a million processes) while that would not be possible
with Scala or Java for that matter.
> To speed up unit testing, my idea has been that I keep a SuiteRunner
> server VM running at all time while developing, and when I run tests
> what I actually do is feed jobs to that server. This way I could avoid
> starting up a new JVM each time I want to run a test. So what seems to
> make sense is to embed a JavaSpace inside that SuiteRunner server.
Assuming you keep the SuiteRunner JVM running and submit suites through
a JavaSpace you will likely run into what I think a lot of people also
consider the hard parts of working with Jini/RMI (and often overlooked)
namely that you must make sure that you will be able to provide as a
codebase annotation all classes your test suites will depend on.
Assuming people are able to do that you will likely run into the fact
the JVM that is about to (re)execute the testsuites has those JAR files
cached (you can also prevent from using JAR files though).
There are ways to solve some of these problems by making sure you end up
with a different codebase annotation each time or configuring e.g. a
smart jar: protocol handler (you can find one in the Seven source code)
for your JVM that doesn't caches JAR files but is able to verify
whether a newer JAR file is available and will use the newer JAR files
for new class loaders created.
I do wonder whether in general people have unit tests that really take
a long time to run, I have only a few that take a long time to complete
and these are for testing concurrency utilities such a thread pools,
blocking queues, etc. Parallelism helps a lot here because the tests
themselves are not consuming any significant CPU most of the time, but
there is no need to distribute these, local parallelization is good enough.
BTW I'm still using your modified SuiteRunner code to make it use
PreferredClassProvider/PreferredClassLoader, control the codebase
annotation for serving JAR files of mobile code from an integrated HTTP
server and have written a Ant task for it, as well as a JUnit XML
reporter so you can use the Ant junitreport. I needed those changes to
have it act as a proper Jini client that was able to serve mobile code
to the services I test through SuiteRunner. Everything is available
through the Cheiron project under the ALv2, if you have any questions
you know where to find me for I think I've solved some of the problems
you might run into.
--
Mark
Distrubited testing - was:Re: Concurrency and River
Posted by Zsolt Kúti <ku...@cetelem.hu>.
Here is a reference to an article that could be unnoticed for
this thread's readers:
http://weblogs.java.net/blog/robogeek/archive/2005/11/a_patent_for_th.html
"It's a pretty cool package that is (unfortunately) available
only inside Sun. The patent tells the story but you have to read
quite a long ways past an impressive list of claims before you
get to it.
The Distributed Test Framework (DTF) is the software in question.
...
We've been using DTF successfully for several years now and
gotten a lot of mileage out of it.
...
Hopefully the patents are narrowly enough defined so it doesn't
stop too many of y'all from implementing your own systems."
It seems adding distrubiuted capabilities based on Jini to well
known testing frameworks (be it JUnit or TestNG) besides its
practical value may also bear with marketing value.
Zsolt
Ps.: Interesting thread(s), BTW!
Tue, 2 Oct 2007 17:06:53 -0700: Látszólag Bill Venners véste
elektronokba/apparently Bill Venners carved into e-lectrons:
> Hi Dan,
>
> On Oct 1, 2007, at 12:26 PM, Dan Creswell wrote:
>
> > Hi Bill,
> >
> > I think your idea is an interesting one and certainly and I
> > think the lessons learnt from Jini would be valuable in this
> > area though I'm not sure that Jini in its current incarnation
> > is the correct base to start from. That of course might
> > provide us with a target to evolve towards.....or perhaps we
> > start a side-project for this work, who knows?
> >
> I spoke with Allen Holub a couple hours ago about actors, and
> one of the things I learned was that actors don't really have a
> parallel processing story. Actors have little message queues,
> and they sit there processing and sending messages to other
> actors, so if you were to, say, model compute workers as
> actors, you'd still have the problems of dividing the work up
> and figuring out how to send jobs as messages to the worker
> actors, deal with failure, etc.
>
> Back in 1993 I was trying to figure out how to use JUnit to
> write the ServiceUI conformance test kit, required by the JDP,
> and became frustrated. I ended up creating a test framework
> called SuiteRunner. I released it open source, but stopped at
> around version 0.8. As soon as I got it far enough to serve our
> purposes at Artima, I could see no value out of trying to
> promote it as an alternative to JUnit. One of the things I had
> imagined doing with it someday, if it ever made sense, was
> making it distribute test jobs via a Javaspaces compute grid.
> Unit tests are embarrassingly parallelizable, and people sit
> around waiting for them to run sequentially. With the rise of
> multi- core, this may start to seem pretty wasteful. A year or
> two after I released SuiteRunner to the public, Cedric Beust
> released TestNG, and his reasoning included many of the same
> frustrations I had had with JUnit. TestNG does have some kind
> of ability to distribute testing jobs to other programmers
> workstations, but doesn't seem to use Jini and I'm not sure how
> well his distribution strategy actually works.
>
> I started porting SuiteRunner to Scala in part as a way to
> learn Scala and in part because we want to write tests in Scala
> at Artima. Also, since it is early in Scala history, I figured
> there's a chance SuiteRunner could become the de facto standard
> testing tool for Scala programmers. And since multi-core is
> coming, I thought if I made this new version of SuiteRunner
> ready for multi-core from the beginning, it might serve a real
> need people in the Java community will soon have that JUnit
> doesn't address.
>
> To speed up unit testing, my idea has been that I keep a
> SuiteRunner server VM running at all time while developing, and
> when I run tests what I actually do is feed jobs to that
> server. This way I could avoid starting up a new JVM each time
> I want to run a test. So what seems to make sense is to embed a
> JavaSpace inside that SuiteRunner server.
>
> I actually wasn't thinking about SuiteRunner when I brought up
> the multi-core marketing opportunity a few days ago, but now I
> realize it may be a good example. The SuiteRunner server could
> look up how many CPUs are available and use that info to decide
> how many threads to fire up. My rough idea is that to run a
> suite of tests, a client would put a run job in the space. Some
> thread in the server would remove that job and partition it
> into suite jobs that go back into the space. Worker threads
> that remove suites from the space and execute the tests in
> them, sending reports to reporters. A reporter could put report
> entries into the space for the client to use, in some cases.
> The worker threads could use Jini discovery to find such
> spaces, so that if multiple programmers are sitting on the same
> subnet each running SuiteRunner servers, they could all use
> each other's spare CPU cycles to speed unit testing up.
>
> The more programmers I could get to use this tool, the more
> programmers would "get" Jini and JavaSpaces I think. Because
> all Java programmers should really be doing unit testing. If it
> were the de facto standard in the Scala community, Scala
> programmers would reach for it by default. Java programmers
> might be convinced to use it so they can at least write unit
> tests in Scala, or take advantage of multiple cores or their
> coworkers spare compute cycles. It might be especially
> compelling for Java folks if it could distribute JUnit and
> TestNG tests too.
>
> What do all of you think of this idea, and what advice would
> you have for me as far as what JavaSpace implementation to use?
> Blitz advertises that it can be embedded. Do you think that
> would be the best JavaSpace option for this use case?
>
> Thanks.
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
>
>
>
>
>
--
Kúti Zsolt - Hitelnet fejlesztés
---------------------------------------------
Zsolt Kúti - Hitelnet development
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
Hi Jeff,
On Oct 3, 2007, at 1:38 PM, Jeff Ramsdale wrote:
>> I had forgotten we talked about this several years ago with regards
>> to CruiseControl. How did your effort to distribute JUnit tests with
>> Jini and CruiseControl work out?
>
> Well, by the time I neared release I realized I'd done a lot of things
> wrong, or at least less than optimally. It was my first Jini project,
> and it showed. However it did (mostly) work and others have kept the
> code current (big thanks to Dan Rollo). My new designs (never
> implemented) involved JavaSpaces, but never went so far as to
> parallelize the running of TestCases. The goal of the project was
> really to parallelize builds on different platforms. Without realizing
> it I'd reimplemented some of the features of Rio regarding
> identification of a node's capabilities.
>
OK.
>> Anyway, the assumption in your response seems to be that if something
>> (such as Scala and SuiteRunner) isn't mainstream today that it will
>> never be mainstream. If that's true in general there's not much point
>> in trying to market Jini, because Jini isn't mainstream today either.
>
> I wouldn't want to suggest Scala and SuiteRunner won't ever be
> mainstream, but I don't think we should necessarily depend on their
> becoming so. Clearly Jini isn't mainstream and if we want it to be we
> should try to minimize the unfamiliar dependencies. (Think Jini
> configuration here. As brilliant as it might be many potential users
> are confused by it. There should be an easier starting point.)
>
Agreed.
>> My situation is that unlike the old days when I could take a few
>> weeks off full time to code up the ServiceUI API if I felt like it, I
>> don't have time to do stuff today that Artima doesn't have a chance
>> to make money from. I didn't really transform into a greedy person. I
>> hired people. I have to meet payroll now and that really changes your
>> perspective about what you need to do with your time. Some of you may
>> miss the old me, and I do too honestly, but that's how it is these
>> days. I have felt bad that I haven't had much time to contribute to
>> this project, and have been on the lookout for ways I could
>> contribute to River that also had potential to help bring revenue to
>> Artima.
>
> I completely understand. I used to have some funding to work on
> Jini.org and I no longer do. Time is hard to come by. In any case, I
> wasn't meaning to suggest SuiteRunner and Scala be left out of the
> loop--I think your argument for trying to position SuiteRunner as the
> de facto standard for Scala is a great idea. I was only suggesting
> that most Java users wouldn't want be be required to use those
> technologies to try out the distributed build technology. I could see
> a situation where the most advanced features required some
> understanding of Scala and/or SuiteRunner--that would be good for you
> and your business. But I'd hook 'em with a straight-up JUnit
> connection.
>
I see your point. The requirements for the new SuiteRunner should
include that it can be used to parallelize JUnit and TestNG tests.
SuiteRunner was always a bit more about running tests than writing
them, and always allowed you to run JUnit 3 tests. We did some
enhancements when JUnit 4 came along to support that, and that works,
but never made a release, and then I decided to go Scala.
>> The missing context in my previous post is that I've made a business
>> bet on Scala. Artima will be publishing a Scala tutorial, and later
>> possibly other Scala books, and offer other educational materials.
>> And we're going to use Scala to write our software internally. I
>> started rewriting SuiteRunner in Scala because I want to use it
>> internally at Artima, and because I want to use it as a talking
>> point, an example, to promote better software practice in the context
>> of Scala at conferences.
>
> Sounds great!
>
>> What I realized yesterday is that with multi-core coming, if I
>> architected the new SuiteRunner from day one as a Jini-based
>> distributed system that can also scale gracefully down to one box,
>> then I could also talk about Jini and JavaSpaces at those
>> conferences, and help spread the word about River a bit while I'm
>> spreading the word about Scala. I think that with multi-core coming,
>> it honestly makes a lot of sense to architect SuiteRunner this way
>> anyway. How would I parallelize tests if I didn't use JavaSpaces? I
>> wouldn't even know where to begin.
>
> I think in the context of this conversation I'd like to make the point
> that multi-core is HERE, no longer "coming". You have to work to buy a
> machine that isn't multi-core this days. Just saw a number of Brian
> Goetz sessions on the No Fluff conference circuit, and he made that
> point loud and clear.
>
> I agree with your point above!
>
Well, you can get 2 cores today easily. But what's going to be
interesting is when it is 4, 8, 16, 32, ..., 128 cores etc. With two
cores you don't get that much more throughput compared to 32 cores,
for parallelizable work. "Make test run 10 times faster" is more
compelling than "Make tests run 1.5 times faster." I don't get the
feeling people worry they are wasting CPUs today, but a few years
from now, that may be on the forefront of their minds. The marketing
goal with respect to River should be that JavaSpaces is one of the
things they automatically think about when they want to exploit
parallelism.
Bill
>> SuiteRunner was always a JUnit runner. It runs JUnit tests. But that
>> didn't help make it interesting to folks. Cedric Beust did get some
>> uptake with TestNG because he kept adding features and tirelessly
>> promoting it. But JUnit has improved since 1993, and I don't see a
>> compelling reason for Java programmers to switch from JUnit even to
>> TestNG honestly, and certainly not to the Java SuiteRunner. But the
>> Scala community doesn't really have a de facto standard testing tool
>> yet, and so I think there's a good chance I can get folks to use the
>> new SuiteRunner. It is a smaller community than the Jini community,
>> even, but to the extent Scala is adopted, SuiteRunner would then ride
>> that wave. I do agree with you that SuiteRunner would need to
>> continue to run JUnit tests as well, and also should be able to run
>> TestNG tests, so people can hook their legacy tests into it if they
>> start using Scala for writing tests.
>
> Good to hear. I think there's a lot of interest in unit testing and
> TDD currently. Should really help build demand for what you're
> offering.
>
>> Another thing that perhaps Artima could help with is I'd be open to
>> publishing a Jini book if we could figure out a way to market it. My
>> understanding has been that mainstream publishers won't touch Jini,
>> and that there isn't even a book that describes Jini 2.0. Is that
>> still the case? For example, a book focused on how to exploit multi-
>> core processors with JavaSpaces might hit a nerve a year from now. So
>> if anyone has a Jini book idea or an desire to contribute to one,
>> please contact me privately.
>
> Jan Newmarch did update his book last year:
> <http://www.apress.com/book/view/1590597168>
>
> Not to say there wouldn't be a market for another, particularly if it
> took a different slant. Might be an opportunity to play on the Apache
> River name too.
>
> Thanks for the conversation--good topic!
>
> Jeff
>
>> Thanks.
>>
>> Bill
>> ----
>> Bill Venners
>> President
>> Artima, Inc.
>> http://www.artima.com
>
Re: Concurrency and River
Posted by Jeff Ramsdale <je...@gmail.com>.
Hi Bill,
On 10/3/07, Bill Venners <bv...@artima.com> wrote:
> Hi Jeff,
<snip />
> I had forgotten we talked about this several years ago with regards
> to CruiseControl. How did your effort to distribute JUnit tests with
> Jini and CruiseControl work out?
Well, by the time I neared release I realized I'd done a lot of things
wrong, or at least less than optimally. It was my first Jini project,
and it showed. However it did (mostly) work and others have kept the
code current (big thanks to Dan Rollo). My new designs (never
implemented) involved JavaSpaces, but never went so far as to
parallelize the running of TestCases. The goal of the project was
really to parallelize builds on different platforms. Without realizing
it I'd reimplemented some of the features of Rio regarding
identification of a node's capabilities.
> Anyway, the assumption in your response seems to be that if something
> (such as Scala and SuiteRunner) isn't mainstream today that it will
> never be mainstream. If that's true in general there's not much point
> in trying to market Jini, because Jini isn't mainstream today either.
I wouldn't want to suggest Scala and SuiteRunner won't ever be
mainstream, but I don't think we should necessarily depend on their
becoming so. Clearly Jini isn't mainstream and if we want it to be we
should try to minimize the unfamiliar dependencies. (Think Jini
configuration here. As brilliant as it might be many potential users
are confused by it. There should be an easier starting point.)
> My situation is that unlike the old days when I could take a few
> weeks off full time to code up the ServiceUI API if I felt like it, I
> don't have time to do stuff today that Artima doesn't have a chance
> to make money from. I didn't really transform into a greedy person. I
> hired people. I have to meet payroll now and that really changes your
> perspective about what you need to do with your time. Some of you may
> miss the old me, and I do too honestly, but that's how it is these
> days. I have felt bad that I haven't had much time to contribute to
> this project, and have been on the lookout for ways I could
> contribute to River that also had potential to help bring revenue to
> Artima.
I completely understand. I used to have some funding to work on
Jini.org and I no longer do. Time is hard to come by. In any case, I
wasn't meaning to suggest SuiteRunner and Scala be left out of the
loop--I think your argument for trying to position SuiteRunner as the
de facto standard for Scala is a great idea. I was only suggesting
that most Java users wouldn't want be be required to use those
technologies to try out the distributed build technology. I could see
a situation where the most advanced features required some
understanding of Scala and/or SuiteRunner--that would be good for you
and your business. But I'd hook 'em with a straight-up JUnit
connection.
> The missing context in my previous post is that I've made a business
> bet on Scala. Artima will be publishing a Scala tutorial, and later
> possibly other Scala books, and offer other educational materials.
> And we're going to use Scala to write our software internally. I
> started rewriting SuiteRunner in Scala because I want to use it
> internally at Artima, and because I want to use it as a talking
> point, an example, to promote better software practice in the context
> of Scala at conferences.
Sounds great!
> What I realized yesterday is that with multi-core coming, if I
> architected the new SuiteRunner from day one as a Jini-based
> distributed system that can also scale gracefully down to one box,
> then I could also talk about Jini and JavaSpaces at those
> conferences, and help spread the word about River a bit while I'm
> spreading the word about Scala. I think that with multi-core coming,
> it honestly makes a lot of sense to architect SuiteRunner this way
> anyway. How would I parallelize tests if I didn't use JavaSpaces? I
> wouldn't even know where to begin.
I think in the context of this conversation I'd like to make the point
that multi-core is HERE, no longer "coming". You have to work to buy a
machine that isn't multi-core this days. Just saw a number of Brian
Goetz sessions on the No Fluff conference circuit, and he made that
point loud and clear.
I agree with your point above!
> SuiteRunner was always a JUnit runner. It runs JUnit tests. But that
> didn't help make it interesting to folks. Cedric Beust did get some
> uptake with TestNG because he kept adding features and tirelessly
> promoting it. But JUnit has improved since 1993, and I don't see a
> compelling reason for Java programmers to switch from JUnit even to
> TestNG honestly, and certainly not to the Java SuiteRunner. But the
> Scala community doesn't really have a de facto standard testing tool
> yet, and so I think there's a good chance I can get folks to use the
> new SuiteRunner. It is a smaller community than the Jini community,
> even, but to the extent Scala is adopted, SuiteRunner would then ride
> that wave. I do agree with you that SuiteRunner would need to
> continue to run JUnit tests as well, and also should be able to run
> TestNG tests, so people can hook their legacy tests into it if they
> start using Scala for writing tests.
Good to hear. I think there's a lot of interest in unit testing and
TDD currently. Should really help build demand for what you're
offering.
> Another thing that perhaps Artima could help with is I'd be open to
> publishing a Jini book if we could figure out a way to market it. My
> understanding has been that mainstream publishers won't touch Jini,
> and that there isn't even a book that describes Jini 2.0. Is that
> still the case? For example, a book focused on how to exploit multi-
> core processors with JavaSpaces might hit a nerve a year from now. So
> if anyone has a Jini book idea or an desire to contribute to one,
> please contact me privately.
Jan Newmarch did update his book last year:
<http://www.apress.com/book/view/1590597168>
Not to say there wouldn't be a market for another, particularly if it
took a different slant. Might be an opportunity to play on the Apache
River name too.
Thanks for the conversation--good topic!
Jeff
> Thanks.
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
Hi Jeff,
On Oct 2, 2007, at 10:55 PM, Jeff Ramsdale wrote:
>
> I agree with much of what you're saying, but I wonder if by the end
> you were distracted by a number of interesting things you've been
> playing with lately. This thread started out about the marketing pitch
> that can be made for Apache River but ended up way far out of the
> mainstream.
>
> I think the idea of a distributed JUnit server is compelling (see
> http://www.jini.org/files/meetings/ninth/Cruisecontrol/
> Cruisecontrol.pdf)
> and could be a wonderful pitch for Jini. But if that introduction
> requires Scala and SuiteRunner it's no longer accessible to most folk
> and thus not effective as marketing copy. You do mention at the end
> that people could distribute JUnit tests, but that really needs to be
> the starting point if getting the gospel out is what we're going for.
> In other words, if Scala and SuiteRunner are better ways of doing
> things then I'm all for them, but you can't require them in pursuit of
> the goal of wide adoption.
>
I had forgotten we talked about this several years ago with regards
to CruiseControl. How did your effort to distribute JUnit tests with
Jini and CruiseControl work out?
Anyway, the assumption in your response seems to be that if something
(such as Scala and SuiteRunner) isn't mainstream today that it will
never be mainstream. If that's true in general there's not much point
in trying to market Jini, because Jini isn't mainstream today either.
My situation is that unlike the old days when I could take a few
weeks off full time to code up the ServiceUI API if I felt like it, I
don't have time to do stuff today that Artima doesn't have a chance
to make money from. I didn't really transform into a greedy person. I
hired people. I have to meet payroll now and that really changes your
perspective about what you need to do with your time. Some of you may
miss the old me, and I do too honestly, but that's how it is these
days. I have felt bad that I haven't had much time to contribute to
this project, and have been on the lookout for ways I could
contribute to River that also had potential to help bring revenue to
Artima.
The missing context in my previous post is that I've made a business
bet on Scala. Artima will be publishing a Scala tutorial, and later
possibly other Scala books, and offer other educational materials.
And we're going to use Scala to write our software internally. I
started rewriting SuiteRunner in Scala because I want to use it
internally at Artima, and because I want to use it as a talking
point, an example, to promote better software practice in the context
of Scala at conferences.
What I realized yesterday is that with multi-core coming, if I
architected the new SuiteRunner from day one as a Jini-based
distributed system that can also scale gracefully down to one box,
then I could also talk about Jini and JavaSpaces at those
conferences, and help spread the word about River a bit while I'm
spreading the word about Scala. I think that with multi-core coming,
it honestly makes a lot of sense to architect SuiteRunner this way
anyway. How would I parallelize tests if I didn't use JavaSpaces? I
wouldn't even know where to begin.
SuiteRunner was always a JUnit runner. It runs JUnit tests. But that
didn't help make it interesting to folks. Cedric Beust did get some
uptake with TestNG because he kept adding features and tirelessly
promoting it. But JUnit has improved since 1993, and I don't see a
compelling reason for Java programmers to switch from JUnit even to
TestNG honestly, and certainly not to the Java SuiteRunner. But the
Scala community doesn't really have a de facto standard testing tool
yet, and so I think there's a good chance I can get folks to use the
new SuiteRunner. It is a smaller community than the Jini community,
even, but to the extent Scala is adopted, SuiteRunner would then ride
that wave. I do agree with you that SuiteRunner would need to
continue to run JUnit tests as well, and also should be able to run
TestNG tests, so people can hook their legacy tests into it if they
start using Scala for writing tests.
Another thing that perhaps Artima could help with is I'd be open to
publishing a Jini book if we could figure out a way to market it. My
understanding has been that mainstream publishers won't touch Jini,
and that there isn't even a book that describes Jini 2.0. Is that
still the case? For example, a book focused on how to exploit multi-
core processors with JavaSpaces might hit a nerve a year from now. So
if anyone has a Jini book idea or an desire to contribute to one,
please contact me privately.
Thanks.
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: Concurrency and River
Posted by Jeff Ramsdale <je...@gmail.com>.
Hi Bill,
I agree with much of what you're saying, but I wonder if by the end
you were distracted by a number of interesting things you've been
playing with lately. This thread started out about the marketing pitch
that can be made for Apache River but ended up way far out of the
mainstream.
I think the idea of a distributed JUnit server is compelling (see
http://www.jini.org/files/meetings/ninth/Cruisecontrol/Cruisecontrol.pdf)
and could be a wonderful pitch for Jini. But if that introduction
requires Scala and SuiteRunner it's no longer accessible to most folk
and thus not effective as marketing copy. You do mention at the end
that people could distribute JUnit tests, but that really needs to be
the starting point if getting the gospel out is what we're going for.
In other words, if Scala and SuiteRunner are better ways of doing
things then I'm all for them, but you can't require them in pursuit of
the goal of wide adoption.
Jeff
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
Hi Dan,
On Oct 1, 2007, at 12:26 PM, Dan Creswell wrote:
> Hi Bill,
>
> I think your idea is an interesting one and certainly and I think the
> lessons learnt from Jini would be valuable in this area though I'm not
> sure that Jini in its current incarnation is the correct base to start
> from. That of course might provide us with a target to evolve
> towards.....or perhaps we start a side-project for this work, who
> knows?
>
I spoke with Allen Holub a couple hours ago about actors, and one of
the things I learned was that actors don't really have a parallel
processing story. Actors have little message queues, and they sit
there processing and sending messages to other actors, so if you were
to, say, model compute workers as actors, you'd still have the
problems of dividing the work up and figuring out how to send jobs as
messages to the worker actors, deal with failure, etc.
Back in 1993 I was trying to figure out how to use JUnit to write the
ServiceUI conformance test kit, required by the JDP, and became
frustrated. I ended up creating a test framework called SuiteRunner.
I released it open source, but stopped at around version 0.8. As soon
as I got it far enough to serve our purposes at Artima, I could see
no value out of trying to promote it as an alternative to JUnit. One
of the things I had imagined doing with it someday, if it ever made
sense, was making it distribute test jobs via a Javaspaces compute
grid. Unit tests are embarrassingly parallelizable, and people sit
around waiting for them to run sequentially. With the rise of multi-
core, this may start to seem pretty wasteful. A year or two after I
released SuiteRunner to the public, Cedric Beust released TestNG, and
his reasoning included many of the same frustrations I had had with
JUnit. TestNG does have some kind of ability to distribute testing
jobs to other programmers workstations, but doesn't seem to use Jini
and I'm not sure how well his distribution strategy actually works.
I started porting SuiteRunner to Scala in part as a way to learn
Scala and in part because we want to write tests in Scala at Artima.
Also, since it is early in Scala history, I figured there's a chance
SuiteRunner could become the de facto standard testing tool for Scala
programmers. And since multi-core is coming, I thought if I made this
new version of SuiteRunner ready for multi-core from the beginning,
it might serve a real need people in the Java community will soon
have that JUnit doesn't address.
To speed up unit testing, my idea has been that I keep a SuiteRunner
server VM running at all time while developing, and when I run tests
what I actually do is feed jobs to that server. This way I could
avoid starting up a new JVM each time I want to run a test. So what
seems to make sense is to embed a JavaSpace inside that SuiteRunner
server.
I actually wasn't thinking about SuiteRunner when I brought up the
multi-core marketing opportunity a few days ago, but now I realize it
may be a good example. The SuiteRunner server could look up how many
CPUs are available and use that info to decide how many threads to
fire up. My rough idea is that to run a suite of tests, a client
would put a run job in the space. Some thread in the server would
remove that job and partition it into suite jobs that go back into
the space. Worker threads that remove suites from the space and
execute the tests in them, sending reports to reporters. A reporter
could put report entries into the space for the client to use, in
some cases. The worker threads could use Jini discovery to find such
spaces, so that if multiple programmers are sitting on the same
subnet each running SuiteRunner servers, they could all use each
other's spare CPU cycles to speed unit testing up.
The more programmers I could get to use this tool, the more
programmers would "get" Jini and JavaSpaces I think. Because all Java
programmers should really be doing unit testing. If it were the de
facto standard in the Scala community, Scala programmers would reach
for it by default. Java programmers might be convinced to use it so
they can at least write unit tests in Scala, or take advantage of
multiple cores or their coworkers spare compute cycles. It might be
especially compelling for Java folks if it could distribute JUnit and
TestNG tests too.
What do all of you think of this idea, and what advice would you have
for me as far as what JavaSpace implementation to use? Blitz
advertises that it can be embedded. Do you think that would be the
best JavaSpace option for this use case?
Thanks.
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: Concurrency and River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Hi Bill,
I think your idea is an interesting one and certainly and I think the
lessons learnt from Jini would be valuable in this area though I'm not
sure that Jini in its current incarnation is the correct base to start
from. That of course might provide us with a target to evolve
towards.....or perhaps we start a side-project for this work, who knows?
Bill Venners wrote:
> Hi All,
>
> I've been observing some wailing and gnashing of teeth lately in various
> programming communities around what to do about the rise of multi-core
> processors.
>
> For example, the Python folks recently had some heated debate on Artima,
> for example, about something called the Global Interpreter Lock or GIL
> that in some way limits the concurrency potential of CPython. I don't
> quite understand the details, but there sure seemed to be some fear that
> if Python didn't make multi-threading easier, it may become less relevant.
>
> Brian Goetz has brought up that we may have frog-boiled ourselves into
> an bad situation by adopting the model of shared state with locks in
> Java. In general the shared state/locks model makes concurrent programs
> difficult to reason about, but in particular this approach to
> concurrency isn't composable. You can't safely combine different modules
> without understanding the details of what they do with locks and how
> they will interact.
>
That's just about the consequences of shared state with concurrent
access be it using locks or transactional memory etc.
And I think in general concurrency is difficult to reason about even in
message based systems with shared nothing because you still have issues
of failure to deal with including how that might impact message delivery.
> 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.
>
I've yet to see exactly how Erlang does failure detection of processes.
I guess there might be some timeout value somewhere in respect of
messages reaching a destination etc but I've not seen a description of
this aspect of Erlang.
Further whilst Erlang might do failure detection (of a form) solving the
issues of failure are the difficult bit and I'm less convinced Erlang
offers much here. For example, one solution to failure is replication
and it appears you are (unsurprisingly) left to do that for yourself
right now. Putting my high-performance hat on I'd also point out that
replication has recognized limits especially when it's done with
transactions which leads to even more esoteric solutions that are
largely about appropriate architecture/interactions and less about
shared-nothing or message passing.
> 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.
>
> 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 think what it might mean is that you treat another core on the same
> box running a worker thread the same as a worker thread across the
> network. That way you have a uniform programming model, and when you run
> out of cores, you just add more boxes and you get more worker nodes. So
> it would be the opposite of the concept targeted by the Note. Yes, you
> would use objects through a uniform interface, and whether or not that
> object is implemented locally or remotely would be an implementation
> detail of the object. But what you'd assume is not that the thing is
> local (a thread on another core of the same box) but remote.
>
Hmmmm, so the uniform model concept is nice and cleans out one
difficulty but there are some others lying around in this which I reckon
are in need of consideration:
(1) A number of multi-core systems are threatening to head towards NUMA
type architectures where the cost of comms is in part related to the
number of memory spaces you have to hop.
(2) There's at least some (significant?) difference between comms
performance across processors in the same box versus across a network
and therefore the protocols you design and what you pass around in
messages might be somewhat different.
> Anyway, I was curious what everyone here thought. It may be a way to
> position River in people's minds, give it a marketing story.
>
Very best,
Dan.
Re: Concurrency and River
Posted by Rick Moynihan <ri...@calicojack.co.uk>.
Bill Venners wrote:
> I think JavaSpaces offers an understandable way to distribute
> processing across multiple cores. Actors do too, but it is a
> different model and that's OK. There's a lot of buzz these days about
> actors and Erlang in the context of multi-core CPUs, but no one is
> talking about JavaSpaces in that same context.
Agreed. I think Javaspaces is a good model for this, and that it might
be a good opportunity for River to market itself to those who want to
exploit multiple machines/cores.
My points were really just to highlight the differences in the models.
I also completely agree with your discussion in a different response in
this thread about "chatty versus chunky designs". And I guess I could
recharacterise my point by saying that Javaspaces seem better suited to
the chunky designs, where as Actors tend to favour chattier models.
Rick.
Re: Concurrency and River
Posted by Bill Venners <bv...@artima.com>.
On Oct 1, 2007, at 10:22 AM, Rick Moynihan wrote:
>
>> 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...
>
Just to clarify, I don't mean using Jini/JavaSpaces to do
asynchronous messaging like actors. I mean using the master/worker
pattern with JavaSpaces to distribute processing to threads on
multiple cores as well as multiple CPUs.
My comparison to actors is merely that they promote that you write
your app in a certain way such that local and remote is treated the
same, I think. The lowest common denominator there is remote. If you
treat everything as if it were local, then you run into the problems
described in A Note on Distributed Computing. But if you treat
everything as remote, your only problem is you add complexity to code
that really will in practice be local. But the app should work.
I think JavaSpaces offers an understandable way to distribute
processing across multiple cores. Actors do too, but it is a
different model and that's OK. There's a lot of buzz these days about
actors and Erlang in the context of multi-core CPUs, but no one is
talking about JavaSpaces in that same context.
Is JavaSpaces still called JavaSpaces?
Bill
Re: Concurrency and River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Gregg Wonderly wrote:
> Rick Moynihan wrote:
>> 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).
>
> One of the primary arguments I get for Jini in places that I've tried to
> hype it, is that it requires Java. Now this is from the same crowds
> that are happy that SOAP requires XML, or that REST requires(or is) HTTP
> servers. So, I'm not sure how they justify, to themselves the
> requirement of one technology that is at a programming language level as
> been worse than a technology that is at the network
> layer/transport/encoding level which still makes it have to be everywhere.
>
> Many of the arguments are about the fact that they believe that they'll
> have to rewrite all of the existing apps to exploit Jini technologies.
> I guess they think that they can just rewrite "parts" of their
> applications to use "XML"/SOAP for messaging, or HTTP for transfers.
>
> For me, this gets back to some of the issues that we haven't provided
> concrete examples for. I.e. we don't have an example use of a JERI
> ILFactory that does something besides native method invocation. We
> probably need to demonstrate how one might talk to a Javaspace, from
> .NET using SOAP for example. The point of such an example would be to
> demonstrate that it's possible. It might also be interesting to do an
> HTTP ILFactory that provided the translation from method calls to HTTP
> POST operations. For me, this is not exciting, nor do I need it. But,
> we do have people in the community which are doing cool things to put
> Jini into the web services world.
>
> Somehow we need to help people understand that Jini no longer requires
> RMI on both ends, let alone Java. Without traceable examples with well
> thoughtout scenarios and great documentation, I don't know how to make
> the point.
>
I don't know that you can make the point ever - see half the reason for
the rebellion against Java in these cases is the "we might need to
integrate anything with anything else sometime, somehow somewhere"
philosophy.
Basically they're all assuming that using any Java-only solution between
two Java things is bad because there might one day need to be a link to
some other non-Java system. The fact that they don't know what that
system might look like and that there are a million ways to solve that
problem better than forcing lowest common denominator interfaces
everywhere (a la CORBA, no offence to Waldo intended) goes
ignored/un-noticed.
Fundamentally the people you are arguing with are pursuing heavenly,
silver bullet, one size fits all dreams and your treading on those
dreams (slight W.B. Yeats mis-quote) will be stiffly resisted with
endless unfathomable, unreasoned, meaningless rhubarb. And there's no
winning that battle. These people will just have to build another
borked system, and another, and another until maybe (unlikely) they'll
realize that some more principled thought is required.
> I've tried and tried to no avail, and I'm ready to throw in the towel on
> being able to make the point with the arguments I can muster.
>
It's not all doom and gloom - the trick is to develop a few simple
verbal discussion tools that allow you to quickly determine whether the
audience is friendly/thinking. Then you can either continue the
discussion or find something better to do with your time.
> Gregg Wonderly
>
Dan.
Re: Concurrency and River
Posted by Gregg Wonderly <gr...@wonderly.org>.
Rick Moynihan wrote:
> 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).
One of the primary arguments I get for Jini in places that I've tried to hype
it, is that it requires Java. Now this is from the same crowds that are happy
that SOAP requires XML, or that REST requires(or is) HTTP servers. So, I'm not
sure how they justify, to themselves the requirement of one technology that is
at a programming language level as been worse than a technology that is at the
network layer/transport/encoding level which still makes it have to be everywhere.
Many of the arguments are about the fact that they believe that they'll have to
rewrite all of the existing apps to exploit Jini technologies. I guess they
think that they can just rewrite "parts" of their applications to use "XML"/SOAP
for messaging, or HTTP for transfers.
For me, this gets back to some of the issues that we haven't provided concrete
examples for. I.e. we don't have an example use of a JERI ILFactory that does
something besides native method invocation. We probably need to demonstrate how
one might talk to a Javaspace, from .NET using SOAP for example. The point of
such an example would be to demonstrate that it's possible. It might also be
interesting to do an HTTP ILFactory that provided the translation from method
calls to HTTP POST operations. For me, this is not exciting, nor do I need it.
But, we do have people in the community which are doing cool things to put
Jini into the web services world.
Somehow we need to help people understand that Jini no longer requires RMI on
both ends, let alone Java. Without traceable examples with well thoughtout
scenarios and great documentation, I don't know how to make the point.
I've tried and tried to no avail, and I'm ready to throw in the towel on being
able to make the point with the arguments I can muster.
Gregg Wonderly
Re: Concurrency and River
Posted by Rick Moynihan <ri...@calicojack.co.uk>.
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
http://www.calicojack.co.uk/