Re: Implementation of take (multiple) in Jini starter kit

James Grahn wrote:
> John McClain - Sun Microsystems, Inc. wrote:
>> James Grahn wrote:
>>> We'll most likely change the setting to Integer.MAX_VALUE since our
>>> processes usually have ample memory,
>>
>> The other considerations besides memory in the client are :
>>
>>    o if the client can incrementally process the entries
>>      then using a smaller batch size (either via takeMultipleLimit
>>      or maxEntries) can increase the concurrency of your system.
>
> True.   In those situations, maxEntries should be used to parallelize
> the system.

Yep, and probably a better solution than setting takeMultipleLimit since
it is likely the client will understand the trade-off here better than
Outrigger (though you could imagine some cases where you wanted to
centrally mange the limit and takeMultipleLimit would be a way to do -
though perhaps not a great way). To the extent the default value of
takeMultipleLimit was set to 100 for this reason it probably reflects
some overly paternalistic tendencies on my part.

> However, in sequential portions of the code which demand all entries
> matching a template be removed from space, it is intuitive to perform
> that operation as a take multiple.
>
>>    o under some circumstances (as alluded to before) it seems very
>>      large batches can be less efficient than smaller batches
>
> Also true.   We'll need to keep this in mind as a possible optimization.
>   The maxEntries parameter can be used for that optimization when it
> proves necessary, correct?

Yep. The my "paternalistic tendencies" would apply here to, though not
as much.

>>> and that will adhere to our expected behavior.
>>
>> What is the behavior you expect?
>
> That take multiple will take maxEntries entries from the space if
> maxEntries exist (allowing for other things like availability, timeouts,
> etc).   Integer.MAX_VALUE is a reasonable limit on this, since we should
> have far fewer entries in space than that.
>
> We expected that behavior because the maxEntries parameter seemingly
> allows for the previously mentioned optimizations without any need to
> change the configuration.   We had not anticipated an external
> configuration setting would override the maxEntries parameter (despite
> the javadoc proviso).

FWIW, the trade-off in my head was (and I am more just musing than
defending here...it has been observed that I like to hear my self talk....):

   o RPC-type calls that are to return arbitrary large chunks of data
     are problematic (memory, latency, etc.) for both the client and
     server,

   o from a spec perspective it is very hard to say "10 is safe, but
     11" might not be (or isn't)",

   o in any concurrent container (like spaces) the notion of getting
     "all" of anything is suspect, and

   o give how I expected most people to use batch variant of take
     forcing clients to put their takes in a loop doesn't seem like
     a big deal.

Having said that, it does cause a problem for clients that know there
are 10 entries in the space and they would like to be able to get them
all out in one atomic call w/o bothering with a transaction. Though I
wonder in reality how likely is it that you know there are at most 10
entries, transactions aren't an option, and the removal of the 10
entries has to be atomic on the space (as opposed to globally in your
application but managed at a higher level than individual space ops).


--
BTW, if you want to reply to this message, please direct your reply
to the list, thanks

John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

         - David Brooks

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html