You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by Oliver Plohmann <ol...@objectscape.org> on 2011/06/18 11:39:07 UTC
Server-side execution and JavaSpaces
Hello,
the idea of Linda tuple spaces is to have a passive central space where
clients can add or remove data. The client cannot invoke any server-side
execution. This programming model is very well suited for a wide range
of applications. But I'm asking myself whether it would make sense to
allow for some server-side execution for certain exceptional cases where
this makes sense. I guess this is some kind of perennial discussion ...
Let's give an example. Lately, I was prototyping a a little stm
framework. After a while I asked myself how to implement the commit of
a transaction. Well, you change some atomic variable for all affected
data in the transaction and then the new values become visible at once.
Then I asked myself how you would implement that when developing a
distributed stm system using JavaSpaces. The easiest way would be to
send the change list of the transaction to the server and execute the
code on the server-side to process the changes and change the atomic
variable when doing the commit. But this cannot be done, because there
is no way to spawn some server-side thread in JavaSpaces. Then, I have
to do the commit on the client-side. This will necessarily result in a
lot more traffic between the client and the central tuple space.
Now someone might say, that GigaSpaces or whatever system supports
optimistic locking and therefore to implement a distributed stm system
with GigaSpaces or whatever would be no problem. The point is here that
a distributed stm system is only an example of why server-side execution
might be justified in certain circumstances. You can find other examples
for things for which some JavaSpaces implementation has no direct
support and you are confronted with the same question whether there
should be an option to do some server-side execution in JavaSpaces.
So my point is merely "philosophical". If I were the owner of JavaSpaces
I would try to make sure that the clean and elegant programming model of
Linda tuple spaces won't fall apart and let things remain the way they
are. But the question whether some server-side execution makes sense
still bothers me. What do you think?
Regards, Oliver
www.objectscape.org
Re: Server-side execution and JavaSpaces
Posted by Oliver Plohmann <ol...@objectscape.org>.
I forgot to mention: a JavaSpaces05.writeIfAbsent method would be nice as well ...
Sent from my iPad
www.objectscape.org
Am 23.06.2011 um 10:25 schrieb Dan Creswell <da...@gmail.com>:
> Hi Oliver,
>
> There have been a number of experiments in this direction previously,
> some of them listed elsewhere. Blitz JavaSpaces, GigaSpaces and indeed
> Coherence (completely unrelated but relevant) all have more or less
> experimental mechanisms used in various scenarios which prove that
> such a feature is useful.
>
> Specifically with Jini, the difficulty is how to manage the lifecycle
> of such code:
>
> (1) Does one install it statically at startup of the JavaSpaces
> service or go more dynamic?
> (2) If one goes with the dynamic option, how does one deal with
> security (it's quite simple for a single-user, more complicated with
> multiple users)? Does one even need security?
> (3) How does one manage the increased memory usage and CPU of such a
> solution? How might that be made to scale?
>
> If we want to take this forward then, I would suggest we need to
> define an over-arching set of needs/policy then we can look at all the
> stuff that's been done historically and
> cherry-pick/mix-and-match/innovate our way to a solution. I would
> imagine we ought to be aiming to come up with a standard interface
> that perhaps extends JavaSpace05.
>
> Cheers,
>
> Dan.
>
> On 18 June 2011 10:39, Oliver Plohmann <ol...@objectscape.org> wrote:
>> Hello,
>>
>> the idea of Linda tuple spaces is to have a passive central space where
>> clients can add or remove data. The client cannot invoke any server-side
>> execution. This programming model is very well suited for a wide range of
>> applications. But I'm asking myself whether it would make sense to allow for
>> some server-side execution for certain exceptional cases where this makes
>> sense. I guess this is some kind of perennial discussion ...
>>
>> Let's give an example. Lately, I was prototyping a a little stm framework.
>> After a while I asked myself how to implement the commit of a transaction.
>> Well, you change some atomic variable for all affected data in the
>> transaction and then the new values become visible at once. Then I asked
>> myself how you would implement that when developing a distributed stm system
>> using JavaSpaces. The easiest way would be to send the change list of the
>> transaction to the server and execute the code on the server-side to process
>> the changes and change the atomic variable when doing the commit. But this
>> cannot be done, because there is no way to spawn some server-side thread in
>> JavaSpaces. Then, I have to do the commit on the client-side. This will
>> necessarily result in a lot more traffic between the client and the central
>> tuple space.
>>
>> Now someone might say, that GigaSpaces or whatever system supports
>> optimistic locking and therefore to implement a distributed stm system with
>> GigaSpaces or whatever would be no problem. The point is here that a
>> distributed stm system is only an example of why server-side execution might
>> be justified in certain circumstances. You can find other examples for
>> things for which some JavaSpaces implementation has no direct support and
>> you are confronted with the same question whether there should be an option
>> to do some server-side execution in JavaSpaces.
>>
>> So my point is merely "philosophical". If I were the owner of JavaSpaces I
>> would try to make sure that the clean and elegant programming model of Linda
>> tuple spaces won't fall apart and let things remain the way they are. But
>> the question whether some server-side execution makes sense still bothers
>> me. What do you think?
>>
>> Regards, Oliver
>>
>>
>> www.objectscape.org
>>
>>
Re: Server-side execution and JavaSpaces
Posted by Oliver Plohmann <ol...@objectscape.org>.
Hi Jeff,
I like this idea. I actually once had a similar idea. I have already
thought a bit about what issues one might have to take care about...
Infinispan does not have user events like JavaSpaces where your listener
gets notified upon a write. It has internal events for its internal
organisation. But they cannot be listened to by the user application. At
least this was true for JBossCache and I guess that Infinispan behaves
in the same way. So you would have to add your own facade in front of
Infinispan where upon an add to the cache tree the respective
user-defined listener is notified.
Then you have to think about how clients exchange messages with the
server-side Infinispan cache. One idea would be to use JMS. Something
similar already exists named ActiveSpaces:
http://www.theserverside.com/discussions/thread.tss?thread_id=27274 One
issue that strucks my mind is that the JMS transaction boundary ends
where the Inifinispan transaction boundary starts. Let's say the sending
client expects a return receipt, the Inifispan transaction finished
successfully, but sending the receipt back to the client through JMS
failed. Now the client things that the transmission was unsuccessful,
although the Infinispan transaction was successful. Maybe I'm not right
here. I don't know enough about JMS to know for sure. But this makes me
think.
A JavaSpaces implementation has already been implemented on top of
Terracotta: http://www.semispace.org Now Terracotta is owned by Software
AG and you now have to pay for a license if you want to run your
application on an server array... Something like this could also happen
with Infinispan.
Developing another JavaSpaces implementation would be a great "research
vehicle" to learn a lot of things. What makes me think is whether to
extend the JavaSpaces approach in some way that not only distributed
systems can be build with clients that work together in a coordinated
way as with JavaSpaces, but also processing large amounts of data can be
done (MapReduce, Hadoop, etc.). But I know whether these are different
things that should be handled by a different kind of systems ...
Just a quick writeup of some things that crossed my mind when I read
Jeff's proposal...
Cheers, Oliver
On 01.07.2011 20:32, Jeff Ramsdale wrote:
> Infinispan ( http://infinispan.org ) is a clustered cache technology,
> similar to Coherence that scales up and down dynamically and has a
> Map/Reduce capability. I've thought a JavaSpaces implementation built
> on top of it would be pretty compelling.
>
> -jeff
Re: Server-side execution and JavaSpaces
Posted by Jeff Ramsdale <je...@gmail.com>.
Infinispan ( http://infinispan.org ) is a clustered cache technology,
similar to Coherence that scales up and down dynamically and has a
Map/Reduce capability. I've thought a JavaSpaces implementation built
on top of it would be pretty compelling.
-jeff
On Fri, Jul 1, 2011 at 11:15 AM, Oliver Plohmann <ol...@objectscape.org> wrote:
>
>> Hi Oliver,
>>
>> ...
>>
>> Specifically with Jini, the difficulty is how to manage the lifecycle
>> of such code:
>>
>> (1) Does one install it statically at startup of the JavaSpaces
>> service or go more dynamic?
>> (2) If one goes with the dynamic option, how does one deal with
>> security (it's quite simple for a single-user, more complicated with
>> multiple users)? Does one even need security?
>> (3) How does one manage the increased memory usage and CPU of such a
>> solution? How might that be made to scale?
>
> Hi Dan,
>
> it would be nice if a JavaSpaces-like interface could be found, e.g. a future can be seen as a JavaSpaces-like blocking read. Do a write with an Entry object that can be executed on the server-side. When you want to execute it, do a JavaSpace05.read(Entry entry, ...) to execute it and wait till the result has been returned. Similarly, implement a polymorphic variant of JavaSpace05.notify(Entry entry, ...) to invoke the executable object on the server side and notify some listener when the execution has terminated.
>
> (3) is a real problem, I think. If you just add a feature to execute some task on the server-side it will not scale. The case I found where I could justify server-side execution is an exceptional case (developing a stm system on top of JavaSpaces and not developing an "ordinary distributed application"). So you could go with a solution that does not scale and the user is left with the responsibility to handle this feature with care. Similarly, a programming language that offers a lot of features for meta programming leaves responsibility with the developers only to make use of this features when really justifiable.
>
> If you are looking for a scalable solution, on the other hand, just adding scalability by its own (which is difficult enough) might be too simply an approach. Eventually, you have to think about extending the JavaSpaces programming model with some coherent server-side programming model à la Coherence, Hadoop, etc. Well, thinking about it, if I understand things right with Terracotta users define all kind of server-side active objects (objects that consume cpu power on the server-side) and just don't worry about the server bogging down. The user is told just to add another machine to the server array and that's basically it. So, there are many things to think about. Maybe, just wait for David Gelernter to show up with a simple coherent immediately convincing solution and we are fine ;-). Actually, coming to think about it ... If I were GigaSpaces I would think about enhancing GigaSpaces in a way that it can also be used for things like Google MapReduce, Hadoop, etc. while remaining consistent with the fundamental tuple-space approach. You have to play in that league or 90% of todays distributed applications are implemented with some other technology (the Internet has changed things here). There is a reason Terracotta acquired EhCache ...
>
> (1) I believe most users would prefer to implement some class that implements Runnable they can invoke at run-time. Just my 5 cents.
>
> (2) This is again a difficukt issue. As I'm just an ordinary application developer with some interest in distributed systems I better leave this one to the big system shots ...
>
> Regards,
> Oliver
>
>> If we want to take this forward then, I would suggest we need to
>> define an over-arching set of needs/policy then we can look at all the
>> stuff that's been done historically and
>> cherry-pick/mix-and-match/innovate our way to a solution. I would
>> imagine we ought to be aiming to come up with a standard interface
>> that perhaps extends JavaSpace05.
>>
>> Cheers,
>>
>> Dan.
>>
>> On 18 June 2011 10:39, Oliver Plohmann <ol...@objectscape.org> wrote:
>>> Hello,
>>>
>>> the idea of Linda tuple spaces is to have a passive central space where
>>> clients can add or remove data. The client cannot invoke any server-side
>>> execution. This programming model is very well suited for a wide range of
>>> applications. But I'm asking myself whether it would make sense to allow for
>>> some server-side execution for certain exceptional cases where this makes
>>> sense. I guess this is some kind of perennial discussion ...
>>>
>>> Let's give an example. Lately, I was prototyping a a little stm framework.
>>> After a while I asked myself how to implement the commit of a transaction.
>>> Well, you change some atomic variable for all affected data in the
>>> transaction and then the new values become visible at once. Then I asked
>>> myself how you would implement that when developing a distributed stm system
>>> using JavaSpaces. The easiest way would be to send the change list of the
>>> transaction to the server and execute the code on the server-side to process
>>> the changes and change the atomic variable when doing the commit. But this
>>> cannot be done, because there is no way to spawn some server-side thread in
>>> JavaSpaces. Then, I have to do the commit on the client-side. This will
>>> necessarily result in a lot more traffic between the client and the central
>>> tuple space.
>>>
>>> Now someone might say, that GigaSpaces or whatever system supports
>>> optimistic locking and therefore to implement a distributed stm system with
>>> GigaSpaces or whatever would be no problem. The point is here that a
>>> distributed stm system is only an example of why server-side execution might
>>> be justified in certain circumstances. You can find other examples for
>>> things for which some JavaSpaces implementation has no direct support and
>>> you are confronted with the same question whether there should be an option
>>> to do some server-side execution in JavaSpaces.
>>>
>>> So my point is merely "philosophical". If I were the owner of JavaSpaces I
>>> would try to make sure that the clean and elegant programming model of Linda
>>> tuple spaces won't fall apart and let things remain the way they are. But
>>> the question whether some server-side execution makes sense still bothers
>>> me. What do you think?
>>>
>>> Regards, Oliver
>>>
>>>
>>> www.objectscape.org
>>>
>>>
>
Re: Server-side execution and JavaSpaces
Posted by Oliver Plohmann <ol...@objectscape.org>.
> Hi Oliver,
>
> ...
>
> Specifically with Jini, the difficulty is how to manage the lifecycle
> of such code:
>
> (1) Does one install it statically at startup of the JavaSpaces
> service or go more dynamic?
> (2) If one goes with the dynamic option, how does one deal with
> security (it's quite simple for a single-user, more complicated with
> multiple users)? Does one even need security?
> (3) How does one manage the increased memory usage and CPU of such a
> solution? How might that be made to scale?
Hi Dan,
it would be nice if a JavaSpaces-like interface could be found, e.g. a future can be seen as a JavaSpaces-like blocking read. Do a write with an Entry object that can be executed on the server-side. When you want to execute it, do a JavaSpace05.read(Entry entry, ...) to execute it and wait till the result has been returned. Similarly, implement a polymorphic variant of JavaSpace05.notify(Entry entry, ...) to invoke the executable object on the server side and notify some listener when the execution has terminated.
(3) is a real problem, I think. If you just add a feature to execute some task on the server-side it will not scale. The case I found where I could justify server-side execution is an exceptional case (developing a stm system on top of JavaSpaces and not developing an "ordinary distributed application"). So you could go with a solution that does not scale and the user is left with the responsibility to handle this feature with care. Similarly, a programming language that offers a lot of features for meta programming leaves responsibility with the developers only to make use of this features when really justifiable.
If you are looking for a scalable solution, on the other hand, just adding scalability by its own (which is difficult enough) might be too simply an approach. Eventually, you have to think about extending the JavaSpaces programming model with some coherent server-side programming model à la Coherence, Hadoop, etc. Well, thinking about it, if I understand things right with Terracotta users define all kind of server-side active objects (objects that consume cpu power on the server-side) and just don't worry about the server bogging down. The user is told just to add another machine to the server array and that's basically it. So, there are many things to think about. Maybe, just wait for David Gelernter to show up with a simple coherent immediately convincing solution and we are fine ;-). Actually, coming to think about it ... If I were GigaSpaces I would think about enhancing GigaSpaces in a way that it can also be used for things like Google MapReduce, Hadoop, etc. while remaining consistent with the fundamental tuple-space approach. You have to play in that league or 90% of todays distributed applications are implemented with some other technology (the Internet has changed things here). There is a reason Terracotta acquired EhCache ...
(1) I believe most users would prefer to implement some class that implements Runnable they can invoke at run-time. Just my 5 cents.
(2) This is again a difficukt issue. As I'm just an ordinary application developer with some interest in distributed systems I better leave this one to the big system shots ...
Regards,
Oliver
> If we want to take this forward then, I would suggest we need to
> define an over-arching set of needs/policy then we can look at all the
> stuff that's been done historically and
> cherry-pick/mix-and-match/innovate our way to a solution. I would
> imagine we ought to be aiming to come up with a standard interface
> that perhaps extends JavaSpace05.
>
> Cheers,
>
> Dan.
>
> On 18 June 2011 10:39, Oliver Plohmann <ol...@objectscape.org> wrote:
>> Hello,
>>
>> the idea of Linda tuple spaces is to have a passive central space where
>> clients can add or remove data. The client cannot invoke any server-side
>> execution. This programming model is very well suited for a wide range of
>> applications. But I'm asking myself whether it would make sense to allow for
>> some server-side execution for certain exceptional cases where this makes
>> sense. I guess this is some kind of perennial discussion ...
>>
>> Let's give an example. Lately, I was prototyping a a little stm framework.
>> After a while I asked myself how to implement the commit of a transaction.
>> Well, you change some atomic variable for all affected data in the
>> transaction and then the new values become visible at once. Then I asked
>> myself how you would implement that when developing a distributed stm system
>> using JavaSpaces. The easiest way would be to send the change list of the
>> transaction to the server and execute the code on the server-side to process
>> the changes and change the atomic variable when doing the commit. But this
>> cannot be done, because there is no way to spawn some server-side thread in
>> JavaSpaces. Then, I have to do the commit on the client-side. This will
>> necessarily result in a lot more traffic between the client and the central
>> tuple space.
>>
>> Now someone might say, that GigaSpaces or whatever system supports
>> optimistic locking and therefore to implement a distributed stm system with
>> GigaSpaces or whatever would be no problem. The point is here that a
>> distributed stm system is only an example of why server-side execution might
>> be justified in certain circumstances. You can find other examples for
>> things for which some JavaSpaces implementation has no direct support and
>> you are confronted with the same question whether there should be an option
>> to do some server-side execution in JavaSpaces.
>>
>> So my point is merely "philosophical". If I were the owner of JavaSpaces I
>> would try to make sure that the clean and elegant programming model of Linda
>> tuple spaces won't fall apart and let things remain the way they are. But
>> the question whether some server-side execution makes sense still bothers
>> me. What do you think?
>>
>> Regards, Oliver
>>
>>
>> www.objectscape.org
>>
>>
Re: Server-side execution and JavaSpaces
Posted by Dan Creswell <da...@gmail.com>.
Hi Oliver,
There have been a number of experiments in this direction previously,
some of them listed elsewhere. Blitz JavaSpaces, GigaSpaces and indeed
Coherence (completely unrelated but relevant) all have more or less
experimental mechanisms used in various scenarios which prove that
such a feature is useful.
Specifically with Jini, the difficulty is how to manage the lifecycle
of such code:
(1) Does one install it statically at startup of the JavaSpaces
service or go more dynamic?
(2) If one goes with the dynamic option, how does one deal with
security (it's quite simple for a single-user, more complicated with
multiple users)? Does one even need security?
(3) How does one manage the increased memory usage and CPU of such a
solution? How might that be made to scale?
If we want to take this forward then, I would suggest we need to
define an over-arching set of needs/policy then we can look at all the
stuff that's been done historically and
cherry-pick/mix-and-match/innovate our way to a solution. I would
imagine we ought to be aiming to come up with a standard interface
that perhaps extends JavaSpace05.
Cheers,
Dan.
On 18 June 2011 10:39, Oliver Plohmann <ol...@objectscape.org> wrote:
> Hello,
>
> the idea of Linda tuple spaces is to have a passive central space where
> clients can add or remove data. The client cannot invoke any server-side
> execution. This programming model is very well suited for a wide range of
> applications. But I'm asking myself whether it would make sense to allow for
> some server-side execution for certain exceptional cases where this makes
> sense. I guess this is some kind of perennial discussion ...
>
> Let's give an example. Lately, I was prototyping a a little stm framework.
> After a while I asked myself how to implement the commit of a transaction.
> Well, you change some atomic variable for all affected data in the
> transaction and then the new values become visible at once. Then I asked
> myself how you would implement that when developing a distributed stm system
> using JavaSpaces. The easiest way would be to send the change list of the
> transaction to the server and execute the code on the server-side to process
> the changes and change the atomic variable when doing the commit. But this
> cannot be done, because there is no way to spawn some server-side thread in
> JavaSpaces. Then, I have to do the commit on the client-side. This will
> necessarily result in a lot more traffic between the client and the central
> tuple space.
>
> Now someone might say, that GigaSpaces or whatever system supports
> optimistic locking and therefore to implement a distributed stm system with
> GigaSpaces or whatever would be no problem. The point is here that a
> distributed stm system is only an example of why server-side execution might
> be justified in certain circumstances. You can find other examples for
> things for which some JavaSpaces implementation has no direct support and
> you are confronted with the same question whether there should be an option
> to do some server-side execution in JavaSpaces.
>
> So my point is merely "philosophical". If I were the owner of JavaSpaces I
> would try to make sure that the clean and elegant programming model of Linda
> tuple spaces won't fall apart and let things remain the way they are. But
> the question whether some server-side execution makes sense still bothers
> me. What do you think?
>
> Regards, Oliver
>
>
> www.objectscape.org
>
>
Re: Server-side execution and JavaSpaces
Posted by Tom Hobbs <tv...@googlemail.com>.
I can't say I've explored it at all, certainly not beyond thinking "wouldn't
be interesting if I could..."
Certainly the methods you describe would probably work, I just need to find
the time to experiment.
Cheers,
Tom
Grammar and spelling have been sacrificed on the altar of messaging via
mobile device.
On 22 Jun 2011 16:59, "Greg Trasuk" <tr...@stratuscom.com> wrote:
>
> On Wed, 2011-06-22 at 04:38, Tom Hobbs wrote:
>> Hi Oliver,
>>
>> actually, I think you've picked up on something very interesting. It's
>> something that I've been kicking around in my head for a while. I have
more
>> general ideas though.
>>
>> One of the things I've used javaspaces for has been to contain discrete
>> items if work that are then picked up by workers for execution, a
standard
>> pattern for sure. I think that there's mileage in modifying that pattern
so
>> the implementation of the workers is bundled into the entry of the space.
>>
>
> Entries can contain objects, yes? Couldn't that object have a method
> called execute() or something similar? Then you could have generic
> workers that simply wait for an entry and call the execute() method on a
> contained object.
>
> For that matter, there is a mechanism to register a listener on the
> Javaspace. Is there any reason why such a listener has to be an
> exported proxy to a remote listener? Couldn't it be just an instance of
> some class that implements the notify() method, but then does something
> locally on the space?
>
> Cheers,
>
> Greg.
>
>> That looks a little like a distributed Executor to me. Would you be
>> interested in putting together a Jira issue to track this as a River
>> enhancement?
>>
>> Cheers,
>>
>> Tom
>>
>> Grammar and spelling have been sacrificed on the altar of messaging via
>> mobile device.
>>
>> On 19 Jun 2011 13:18, "Gregg Wonderly" <ge...@cox.net> wrote:
>> > The work I did on my griddle.dev.java.net project was to allow this
kind
>> of thing to happen.
>> >
>> > With griddle, data and keys are separated and comparison is
programmable.
>> There is iterator and executor support on the server side, with executors
>> just returning an iterator.
>> >
>> > It was just some exploratory work, but it dis function in the testing I
>> did with it. It probably is not packed in a way for production use, yet.
>> >
>> > Gregg Wonderly
>> >
>> > Sent from my iPhone
>> >
>> > On Jun 18, 2011, at 4:39 AM, Oliver Plohmann <ol...@objectscape.org>
>> wrote:
>> >
>> >> Hello,
>> >>
>> >> the idea of Linda tuple spaces is to have a passive central space
where
>> clients can add or remove data. The client cannot invoke any server-side
>> execution. This programming model is very well suited for a wide range of
>> applications. But I'm asking myself whether it would make sense to allow
for
>> some server-side execution for certain exceptional cases where this makes
>> sense. I guess this is some kind of perennial discussion ...
>> >>
>> >> Let's give an example. Lately, I was prototyping a a little stm
>> framework. After a while I asked myself how to implement the commit of a
>> transaction. Well, you change some atomic variable for all affected data
in
>> the transaction and then the new values become visible at once. Then I
asked
>> myself how you would implement that when developing a distributed stm
system
>> using JavaSpaces. The easiest way would be to send the change list of the
>> transaction to the server and execute the code on the server-side to
process
>> the changes and change the atomic variable when doing the commit. But
this
>> cannot be done, because there is no way to spawn some server-side thread
in
>> JavaSpaces. Then, I have to do the commit on the client-side. This will
>> necessarily result in a lot more traffic between the client and the
central
>> tuple space.
>> >>
>> >> Now someone might say, that GigaSpaces or whatever system supports
>> optimistic locking and therefore to implement a distributed stm system
with
>> GigaSpaces or whatever would be no problem. The point is here that a
>> distributed stm system is only an example of why server-side execution
might
>> be justified in certain circumstances. You can find other examples for
>> things for which some JavaSpaces implementation has no direct support and
>> you are confronted with the same question whether there should be an
option
>> to do some server-side execution in JavaSpaces.
>> >>
>> >> So my point is merely "philosophical". If I were the owner of
JavaSpaces
>> I would try to make sure that the clean and elegant programming model of
>> Linda tuple spaces won't fall apart and let things remain the way they
are.
>> But the question whether some server-side execution makes sense still
>> bothers me. What do you think?
>> >>
>> >> Regards, Oliver
>> >>
>> >>
>> >> www.objectscape.org
>> >>
>
Re: Server-side execution and JavaSpaces
Posted by Jeff Ramsdale <je...@gmail.com>.
I did some experimentation with a distributed ExecutorService that
used a JavaSpace to implement Master/Worker behind a more familiar
java.util.concurrent framework. It's built on Rio, not raw Jini and
it's very rough: https://bitbucket.org/jramsdale/completion-service
My implementation used the Entry to contain a user-provided
Runnable/Callable that watching workers could grab and execute.
Even the name of the project is wrong as I initially envisioned it as
a CompletionService, not an ExecutorService.
-jeff
On Wed, Jun 22, 2011 at 9:55 AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> On Wed, 2011-06-22 at 04:38, Tom Hobbs wrote:
>> Hi Oliver,
>>
>> actually, I think you've picked up on something very interesting. It's
>> something that I've been kicking around in my head for a while. I have more
>> general ideas though.
>>
>> One of the things I've used javaspaces for has been to contain discrete
>> items if work that are then picked up by workers for execution, a standard
>> pattern for sure. I think that there's mileage in modifying that pattern so
>> the implementation of the workers is bundled into the entry of the space.
>>
>
> Entries can contain objects, yes? Couldn't that object have a method
> called execute() or something similar? Then you could have generic
> workers that simply wait for an entry and call the execute() method on a
> contained object.
>
> For that matter, there is a mechanism to register a listener on the
> Javaspace. Is there any reason why such a listener has to be an
> exported proxy to a remote listener? Couldn't it be just an instance of
> some class that implements the notify() method, but then does something
> locally on the space?
>
> Cheers,
>
> Greg.
>
>> That looks a little like a distributed Executor to me. Would you be
>> interested in putting together a Jira issue to track this as a River
>> enhancement?
>>
>> Cheers,
>>
>> Tom
>>
>> Grammar and spelling have been sacrificed on the altar of messaging via
>> mobile device.
>>
>> On 19 Jun 2011 13:18, "Gregg Wonderly" <ge...@cox.net> wrote:
>> > The work I did on my griddle.dev.java.net project was to allow this kind
>> of thing to happen.
>> >
>> > With griddle, data and keys are separated and comparison is programmable.
>> There is iterator and executor support on the server side, with executors
>> just returning an iterator.
>> >
>> > It was just some exploratory work, but it dis function in the testing I
>> did with it. It probably is not packed in a way for production use, yet.
>> >
>> > Gregg Wonderly
>> >
>> > Sent from my iPhone
>> >
>> > On Jun 18, 2011, at 4:39 AM, Oliver Plohmann <ol...@objectscape.org>
>> wrote:
>> >
>> >> Hello,
>> >>
>> >> the idea of Linda tuple spaces is to have a passive central space where
>> clients can add or remove data. The client cannot invoke any server-side
>> execution. This programming model is very well suited for a wide range of
>> applications. But I'm asking myself whether it would make sense to allow for
>> some server-side execution for certain exceptional cases where this makes
>> sense. I guess this is some kind of perennial discussion ...
>> >>
>> >> Let's give an example. Lately, I was prototyping a a little stm
>> framework. After a while I asked myself how to implement the commit of a
>> transaction. Well, you change some atomic variable for all affected data in
>> the transaction and then the new values become visible at once. Then I asked
>> myself how you would implement that when developing a distributed stm system
>> using JavaSpaces. The easiest way would be to send the change list of the
>> transaction to the server and execute the code on the server-side to process
>> the changes and change the atomic variable when doing the commit. But this
>> cannot be done, because there is no way to spawn some server-side thread in
>> JavaSpaces. Then, I have to do the commit on the client-side. This will
>> necessarily result in a lot more traffic between the client and the central
>> tuple space.
>> >>
>> >> Now someone might say, that GigaSpaces or whatever system supports
>> optimistic locking and therefore to implement a distributed stm system with
>> GigaSpaces or whatever would be no problem. The point is here that a
>> distributed stm system is only an example of why server-side execution might
>> be justified in certain circumstances. You can find other examples for
>> things for which some JavaSpaces implementation has no direct support and
>> you are confronted with the same question whether there should be an option
>> to do some server-side execution in JavaSpaces.
>> >>
>> >> So my point is merely "philosophical". If I were the owner of JavaSpaces
>> I would try to make sure that the clean and elegant programming model of
>> Linda tuple spaces won't fall apart and let things remain the way they are.
>> But the question whether some server-side execution makes sense still
>> bothers me. What do you think?
>> >>
>> >> Regards, Oliver
>> >>
>> >>
>> >> www.objectscape.org
>> >>
>
>
Re: Server-side execution and JavaSpaces
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Wed, 2011-06-22 at 04:38, Tom Hobbs wrote:
> Hi Oliver,
>
> actually, I think you've picked up on something very interesting. It's
> something that I've been kicking around in my head for a while. I have more
> general ideas though.
>
> One of the things I've used javaspaces for has been to contain discrete
> items if work that are then picked up by workers for execution, a standard
> pattern for sure. I think that there's mileage in modifying that pattern so
> the implementation of the workers is bundled into the entry of the space.
>
Entries can contain objects, yes? Couldn't that object have a method
called execute() or something similar? Then you could have generic
workers that simply wait for an entry and call the execute() method on a
contained object.
For that matter, there is a mechanism to register a listener on the
Javaspace. Is there any reason why such a listener has to be an
exported proxy to a remote listener? Couldn't it be just an instance of
some class that implements the notify() method, but then does something
locally on the space?
Cheers,
Greg.
> That looks a little like a distributed Executor to me. Would you be
> interested in putting together a Jira issue to track this as a River
> enhancement?
>
> Cheers,
>
> Tom
>
> Grammar and spelling have been sacrificed on the altar of messaging via
> mobile device.
>
> On 19 Jun 2011 13:18, "Gregg Wonderly" <ge...@cox.net> wrote:
> > The work I did on my griddle.dev.java.net project was to allow this kind
> of thing to happen.
> >
> > With griddle, data and keys are separated and comparison is programmable.
> There is iterator and executor support on the server side, with executors
> just returning an iterator.
> >
> > It was just some exploratory work, but it dis function in the testing I
> did with it. It probably is not packed in a way for production use, yet.
> >
> > Gregg Wonderly
> >
> > Sent from my iPhone
> >
> > On Jun 18, 2011, at 4:39 AM, Oliver Plohmann <ol...@objectscape.org>
> wrote:
> >
> >> Hello,
> >>
> >> the idea of Linda tuple spaces is to have a passive central space where
> clients can add or remove data. The client cannot invoke any server-side
> execution. This programming model is very well suited for a wide range of
> applications. But I'm asking myself whether it would make sense to allow for
> some server-side execution for certain exceptional cases where this makes
> sense. I guess this is some kind of perennial discussion ...
> >>
> >> Let's give an example. Lately, I was prototyping a a little stm
> framework. After a while I asked myself how to implement the commit of a
> transaction. Well, you change some atomic variable for all affected data in
> the transaction and then the new values become visible at once. Then I asked
> myself how you would implement that when developing a distributed stm system
> using JavaSpaces. The easiest way would be to send the change list of the
> transaction to the server and execute the code on the server-side to process
> the changes and change the atomic variable when doing the commit. But this
> cannot be done, because there is no way to spawn some server-side thread in
> JavaSpaces. Then, I have to do the commit on the client-side. This will
> necessarily result in a lot more traffic between the client and the central
> tuple space.
> >>
> >> Now someone might say, that GigaSpaces or whatever system supports
> optimistic locking and therefore to implement a distributed stm system with
> GigaSpaces or whatever would be no problem. The point is here that a
> distributed stm system is only an example of why server-side execution might
> be justified in certain circumstances. You can find other examples for
> things for which some JavaSpaces implementation has no direct support and
> you are confronted with the same question whether there should be an option
> to do some server-side execution in JavaSpaces.
> >>
> >> So my point is merely "philosophical". If I were the owner of JavaSpaces
> I would try to make sure that the clean and elegant programming model of
> Linda tuple spaces won't fall apart and let things remain the way they are.
> But the question whether some server-side execution makes sense still
> bothers me. What do you think?
> >>
> >> Regards, Oliver
> >>
> >>
> >> www.objectscape.org
> >>
Re: Server-side execution and JavaSpaces
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi Oliver,
actually, I think you've picked up on something very interesting. It's
something that I've been kicking around in my head for a while. I have more
general ideas though.
One of the things I've used javaspaces for has been to contain discrete
items if work that are then picked up by workers for execution, a standard
pattern for sure. I think that there's mileage in modifying that pattern so
the implementation of the workers is bundled into the entry of the space.
That looks a little like a distributed Executor to me. Would you be
interested in putting together a Jira issue to track this as a River
enhancement?
Cheers,
Tom
Grammar and spelling have been sacrificed on the altar of messaging via
mobile device.
On 19 Jun 2011 13:18, "Gregg Wonderly" <ge...@cox.net> wrote:
> The work I did on my griddle.dev.java.net project was to allow this kind
of thing to happen.
>
> With griddle, data and keys are separated and comparison is programmable.
There is iterator and executor support on the server side, with executors
just returning an iterator.
>
> It was just some exploratory work, but it dis function in the testing I
did with it. It probably is not packed in a way for production use, yet.
>
> Gregg Wonderly
>
> Sent from my iPhone
>
> On Jun 18, 2011, at 4:39 AM, Oliver Plohmann <ol...@objectscape.org>
wrote:
>
>> Hello,
>>
>> the idea of Linda tuple spaces is to have a passive central space where
clients can add or remove data. The client cannot invoke any server-side
execution. This programming model is very well suited for a wide range of
applications. But I'm asking myself whether it would make sense to allow for
some server-side execution for certain exceptional cases where this makes
sense. I guess this is some kind of perennial discussion ...
>>
>> Let's give an example. Lately, I was prototyping a a little stm
framework. After a while I asked myself how to implement the commit of a
transaction. Well, you change some atomic variable for all affected data in
the transaction and then the new values become visible at once. Then I asked
myself how you would implement that when developing a distributed stm system
using JavaSpaces. The easiest way would be to send the change list of the
transaction to the server and execute the code on the server-side to process
the changes and change the atomic variable when doing the commit. But this
cannot be done, because there is no way to spawn some server-side thread in
JavaSpaces. Then, I have to do the commit on the client-side. This will
necessarily result in a lot more traffic between the client and the central
tuple space.
>>
>> Now someone might say, that GigaSpaces or whatever system supports
optimistic locking and therefore to implement a distributed stm system with
GigaSpaces or whatever would be no problem. The point is here that a
distributed stm system is only an example of why server-side execution might
be justified in certain circumstances. You can find other examples for
things for which some JavaSpaces implementation has no direct support and
you are confronted with the same question whether there should be an option
to do some server-side execution in JavaSpaces.
>>
>> So my point is merely "philosophical". If I were the owner of JavaSpaces
I would try to make sure that the clean and elegant programming model of
Linda tuple spaces won't fall apart and let things remain the way they are.
But the question whether some server-side execution makes sense still
bothers me. What do you think?
>>
>> Regards, Oliver
>>
>>
>> www.objectscape.org
>>
Re: Server-side execution and JavaSpaces
Posted by Gregg Wonderly <ge...@cox.net>.
The work I did on my griddle.dev.java.net project was to allow this kind of thing to happen.
With griddle, data and keys are separated and comparison is programmable. There is iterator and executor support on the server side, with executors just returning an iterator.
It was just some exploratory work, but it dis function in the testing I did with it. It probably is not packed in a way for production use, yet.
Gregg Wonderly
Sent from my iPhone
On Jun 18, 2011, at 4:39 AM, Oliver Plohmann <ol...@objectscape.org> wrote:
> Hello,
>
> the idea of Linda tuple spaces is to have a passive central space where clients can add or remove data. The client cannot invoke any server-side execution. This programming model is very well suited for a wide range of applications. But I'm asking myself whether it would make sense to allow for some server-side execution for certain exceptional cases where this makes sense. I guess this is some kind of perennial discussion ...
>
> Let's give an example. Lately, I was prototyping a a little stm framework. After a while I asked myself how to implement the commit of a transaction. Well, you change some atomic variable for all affected data in the transaction and then the new values become visible at once. Then I asked myself how you would implement that when developing a distributed stm system using JavaSpaces. The easiest way would be to send the change list of the transaction to the server and execute the code on the server-side to process the changes and change the atomic variable when doing the commit. But this cannot be done, because there is no way to spawn some server-side thread in JavaSpaces. Then, I have to do the commit on the client-side. This will necessarily result in a lot more traffic between the client and the central tuple space.
>
> Now someone might say, that GigaSpaces or whatever system supports optimistic locking and therefore to implement a distributed stm system with GigaSpaces or whatever would be no problem. The point is here that a distributed stm system is only an example of why server-side execution might be justified in certain circumstances. You can find other examples for things for which some JavaSpaces implementation has no direct support and you are confronted with the same question whether there should be an option to do some server-side execution in JavaSpaces.
>
> So my point is merely "philosophical". If I were the owner of JavaSpaces I would try to make sure that the clean and elegant programming model of Linda tuple spaces won't fall apart and let things remain the way they are. But the question whether some server-side execution makes sense still bothers me. What do you think?
>
> Regards, Oliver
>
>
> www.objectscape.org
>