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

Before dispensing this sage advice, I didn't bother to check the code,
bad John, bad.

As it turns out towards the top of Outrigger's take multiple
implementation we find this code (which I am pretty sure I wrote, and if
I didn't I must have reviewed it)

    limit = Math.min(limit, takeLimit);
    EntryHandle[] handles = new EntryHandle[limit];

Where "limit" is the value passed into take and "takeLimit" is the value
of the takeMultipleLimit config entry. In a world of 64 bit VM and cheap
  semi-conductor memory allocating a 16,000,000,000+ byte array might
actually work, but its probably not a great idea (must have been
assuming that takeLimit would never get that big, probably started as
static final field, and then became configurable....).

Any way, the practical up shot, a takeMultipleLimit value of a few 100,
or even 1000 or so probably isn't too, too bad (though like I said once
you get in the 100+ range I am not sure how much going bigger helps),
but Interger.MAX_VALUE will often fail in practice.

John McClain - Sun Microsystems, Inc. wrote:
> James Grahn wrote:
>> John McClain - Sun Microsystems, Inc. wrote:
>>> 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?
>>
>> There was no question behind the question; thank you for your extensive
>> answer.
>
> No problem
>
>> 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.
>
>    o under some circumstances (as alluded to before) it seems very
>      large batches can be less efficient than smaller batches
>
>> and that will adhere to our expected behavior.
>
> What is the behavior you expect?
>


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