|
| Re: About granularity... [message #589565 is a reply to message #589547] |
Mon, 24 October 2005 19:33  |
 Scott Lewis
Messages: 1038
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
|
|
|
Powered by
FUDForum. Page generated in 0.01910 seconds
] 
Search
Help
Register
Login
Home
