Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » About granularity...
About granularity... [message #589547] Mon, 24 October 2005 06:39 Go to next message
Didier Villevalois is currently offline Didier Villevalois
Messages: 86
Registered: July 2009
Member
Hi,

I'm starting with ECF. I run into the apis and examples. I'm now trying
to implement my stuff on it.

My goal is to make a distributed process graph for my application.
Processes are just java objects that do some stuff.

There will be ui-enabled containers for users to manipulate the
processes and headless containers. Both types of containers may run the
processes. There will be policies ("workspaces") to manage the processes
in different manners.

As i've seen in examples, granularity of shared objects is always high.
I mean there are never lots of small objects shared in containers. Do i
mistake ? So do container implementations can/have to scale well when
such a situation ? Or should i make a hub like shared object to
transport object changes for all graph nodes (as in graphshare) rather
than have a shared object for every node of the graph ?

Thanks in advance for your help.
Didier.
Re: About granularity... [message #589565 is a reply to message #589547] Mon, 24 October 2005 15:33 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 964
Registered: July 2009
Senior Member
Hi Didier,

Ptitjes wrote:
> Hi,
>
> I'm starting with ECF. I run into the apis and examples. I'm now trying
> to implement my stuff on it.
>
> My goal is to make a distributed process graph for my application.
> Processes are just java objects that do some stuff.
>
> There will be ui-enabled containers for users to manipulate the
> processes and headless containers. Both types of containers may run the
> processes. There will be policies ("workspaces") to manage the processes
> in different manners.
>
> As i've seen in examples, granularity of shared objects is always high.

Yes. So far, the granularity of shared objects has been relatively
high. One reason for this is that the current implementation of a
provider that supports shared objects (the generic provider and the jms
provider...still unavailable on eclipse.org but hopefully not for long),
has assumed/used a thread-and-msg-queue-per-shared object.

This design choice for these providers is just that, however...a design
choice. It would be very desireable, for example, to have a provider
that was based upon a thread pool-for-all-shared objects...like, for
example, one based upon SEDA: http://www.eecs.harvard.edu/~mdw/proj/seda/

Using such a model would mean that the scalability in terms of the
number of shared objects would be much larger. I (Scott) have
contemplated implementing a SEDA-based provider several times, but
unfortunately not had the time to do so.


> I mean there are never lots of small objects shared in containers. Do i
> mistake ?

There could be as there are no built-in limits...but as discussed above
the scalability of the current implementation would be limited.

So do container implementations can/have to scale well when
> such a situation ?

Yes...you've anticipated the discussion above.

Or should i make a hub like shared object to
> transport object changes for all graph nodes (as in graphshare) rather
> than have a shared object for every node of the graph ?

I would think that lacking a much more scalable provider (which would
also make an excellent project) that using the graphshare approach would
make sense.

BTW, there is work going on by Peter Nehrer and Boris Bokowski to create
a new API for sharing complex data graphs...called 'datashare'. This
work is ongoing right now, so your input and desires would be important
to get into their thinking.

>
> Thanks in advance for your help.

No problem. Hope we can help further.

Scott
Previous Topic:Can I contribute to ECF
Next Topic:Sun Enterprise Server
Goto Forum:
  


Current Time: Fri Apr 18 06:49:25 EDT 2014

Powered by FUDForum. Page generated in 0.04399 seconds