Re: preallocating memory used by javaspace

Shay Hassidim wrote:
> Dan,
>
>
>
> Let's review again the roots of our discussion:
>
> xaea alvein /- /Mon, 28 Aug 2006 11:36:58/: "is it possible to
> preallocate memory used by javaspace? can anyone give me some code on
> how to do that?"/
>
> The basic answer here is that Java –Xmx setting should be used to define
> to max memory the JavaSpace can consume and have a simple code that
> calculates the Entry size. See:
>
> http://martin.nobilitas.com/java/sizeof.html -
> http://martin.nobilitas.com/java/SizeOf.jar
>
> http://www.javaworld.com/javaworld/javaqa/2003-12/02-qa-1226-sizeof.html
>
>
>
> Still , this is just the tip of the iceberg when coming down to a
> complete solution. In reality very small amount of users will settle
> with the –Xmx setting and calculating the Entry size.
>

A complete solution to what problem?

All you've had requested so far is a way to restrict the amount of
memory used by a space implementation.

>
>
> They would like the space to evict data based on some policy into some
> durable media , in some cases users would expect to get some sort of
> notification for this event. Some of them would like to utilize multiple
> JVMs to run their JavaSpace and have the # of JVMs X –Xmx value to act
> as the max memory to be used. In other cases, users would like to pull
> the evicted data (expired entries) from a database based on existing
> database model or let the space to write the evicted data into RDBMS for
> better survivability and recoverability.
>
>

Sorry, I just don't agree.  We have not at any point had a statement
that says that any of what you're talking about above is _required_.

In fact, thus far, all we've had is a statement that there's a need to
control the amount of memory used by the space.  No statements have been
made in terms of application behaviour nor has there even been a reason
provided for why limiting is required.

Nor has there been a statement of what kind of machine the solution is
destined to run on.  What if it were a diskless node and everything were
running in memory? Eviction makes little sense then as there's nowhere
to evict to.  All you could do is jettison Entry's which doesn't sound
desirable to me but might be for this scenario but, as yet, we haven't
had a statement made on that either.

In conclusion, I think you are making a large number of assumptions few
of which can be justified based on the available data presented in the
conversation thus far.

>
> As you have just correctly wrote we would like to provide users "_best_
> possible solution to _their_ problem." – More than this we "don't want
> to be prescribing a solution which turns out to be a poor option".
>

No, I'm stating that that is my intention and that is why I'm suggesting
we listen carefully to the user and make sure we understand what problem
we are solving before we propose actions/solutions.

At this stage, I'm unclear on what your intentions are.

>
>
> Based on our experience at GigaSpaces there is no one right solution ,
> but from what we see in most cases the preferred architecture is the SBA.
>
> With this approach users moving from this centric architecture:
>

Who said anything about users moving from one architecture to another?
I certainly didn't and that's not part of the original question from
Xaea Alvein either.

Best,

Dan.

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