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

James Grahn wrote:
> Hello all,
> I recently noticed that the starter kit implementation of take on
> JavaSpace05 returns only 100 entries at a time.
>
> The javadoc does allow for this behavior: "an implementation may chose to
> take fewer entries from the space than the maximum available or the maximum
> allowed by maxEntries", but why was a limit of 100 chosen in the implementation?

100 was picked as a semi-arbitrary value. Like many arbitrary values it
is configurable, see the docs for the "takeMultipleLimit" configuration
entry.

I can't claim exhaustive research went in to picking 100 as the default
value for takeMultipleLimit, but it dates back to some limited
experiments I ran a number of years ago when we were first looking into
batching.  Generally the experiments showed cost of a remote call that
sends or receives n entries is a + b * n.  Batching can be a big benefit
because b is often a few times smaller than a.  The experiments I ran
suggested that a was ~ 5*b, your mileage *will* differ, but if you
assumed a = 5*b was generally applicable then having takeMultipleLimit =
100 is at worst %5 less efficient than a larger value for takeMultipleLimit.

Also as it turns out b isn't constant, as n get large b gets larger too.
If memory serves at some point b gets large enough that it is actually
cheaper to do multiple calls. In the experiment I think peak efficiency
was reached at around a few hundred entries.

Put these two together and the thought goes 100 is unlikely to be too
big, but big enough that making takeMultipleLimit much larger is
unlikely make things much faster. Having said that what the optimal
batch size is going to depends on your network, entries, and CPUs so if
you really care about the "right" batch size some experiments of your
own may be in order.

Having said all that, for me the main motivation for the phrase "an
implementation may chose to take fewer entries from the space than the
maximum available or the maximum allowed by maxEntries" was so the space
could protect itself from have to load all the entries into memory so it
could ship them back to the client, given that Outrigger keeps all of it
entries in memory its quite possible that Interger.MAX_VALUE (we use an
array internally so takeMultipleLimit has to be an int) would be a safe
value for takeMultipleLimit and assume that the client would use
maxEntries to make sure it wasn't trying to take "too many".

Hope this helps. Was there a question behind the question?

--
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