Re: preallocating memory used by javaspace

Dan Creswell <[email protected]> Sat, 2 Sep 2006 10:08:36 +0100
Newsgroups gmane.comp.java.sun.javaspaces
Message-ID <[email protected]>
Hmmm, so I still don't feel like I was entirely clear - let's keep it
simple:

My interest is in giving any user that wants to play with
Jini/JavaSpaces the _best_ possible solution to _their_ problem.

Thus I have a strong preference for completely understanding a user's
needs before I try and provide an answer.  For me this is part of being
professional.  I don't want to be prescribing a solution which turns out
to be a poor option.

And ethically speaking I would be very uncomfortable knowing I'd
recommended a poor option as the result of not listening to a user more
carefully.

Hope that's clear,

Dan.

Shay Hassidim wrote:
> Dan,
>
>
>
> Your question is in fact very good one.
>
> You should know that in the software industry you build a product on top
> of some specification and add your own flavor into it.
>
> Take for example IBM webshpere , BEA Weblogic and JBoss Application
> Servers. All these following the J2EE Spec. Are you sure all of them got
> the exact set of features?
>
> Same for Oracle , DB2 and MSSQL – all of them support SQL. Are you sure
> all of them got the exact features?
>
> Still, users do move between them. It is up to the architecture to
> decide which features he wants to use – but the basic core features are
> exactly the same.
>
>
>
> Jini/JavaSpace is a great technology and one of the most simplistic and
> powerful specs I have seen.
>
> Still , in order to build enterprise scale applications architects and
> develops need a product that cover their needs.
>
>
>
> This is what GigaSpaces all about – The core that is powerful JavaSpace
> implementation (that you can get for free as part of the community
> edition that includes in fact most of the options I listed below) and a
> sophisticated Service Grid using Jini and Rio that allows you to deploy
> your application into the Grid. The space will be started for you and
> injected into the Service itself. Your space entries and Application
> Services can be pure POJOs – no need to implement any interface to write
> entries into the space or to deploy your classes as Services.
>
>
>
> You may access the space using JavaSpaces , SQL , Map , JMS or JDBC with
> Java , C++ and C# utilizing GigaSpaces as Grid enabler using
> master/worker framework , Service Bus or a distributed Cache. All the
> above are wrapped with Spring templates to provide one common ground for
> developers to start with. This means you can use Standard Spring
> templates for all the above. To allow the In Memory Data Grid we
> interact implicitly with external data sources you can plug-in your
> database DAOs using Hibernate and allow the space to read data or write
> data into the database – in sync or async manner.
>
> See:
>
> http://www.gigaspaces.com/wiki/display/GS/5.1
>
>
>
> The above includes the latest info about our 5.1 release. See POJO ,
> Spring , CacheLoader/Store , Mirror , PONO , POCO and many more.
>
>
>
> In terms of performance – in general all APIs provide more or less the
> same performance – simply because they are built on top of the JavaSpace
> API that is the super set of all other API's. Quick performance numbers:
>
> In embedded mode Space API - 100K operations per second , strict remote
> mode 5K operations per second , send and forget remote mode 20K
> operations per second – All these for one space. For Map API users we
> got special optimization that allows us to provide local cache that
> provides the same performance as Hash table. The local cache is sync
> with the master space. You can scale and use the clustered partitioned
> space and start new services on the fly based on SLA to process the
> incoming requests to accommodate your needs – so there is no limit to
> the throughput you can get from the system.
>
>
>
> Why users would need to debate with the vendor locking question when
> they get exactly what they need , especially when all what GigaSpaces
> provides is build on top of industry standards and exposing only
> standard APIs? See the effort we put into supporting POJO both at the
> Data Grid layer and the Service Grid layer – No need to implement any
> special interfaces! Even not to implement the Entry interface to write
> entries to the space! The architect and developer fantasy becomes the
> reality!
>
>
>
> As part of my job I'm visiting customers and prospects around the world
> – when presenting the above I never got the vendor locking question.
>
>
>
> Hope the above clarifies our approach and answer your questions.
>
>
>
> Regards,
>
> Shay
>
>
>
>
>
> -----Original Message-----
> From: Dan Creswell [mailto:[email protected]]
> Sent: Friday, September 01, 2006 9:39 AM
> To: [email protected]
> Subject: Re: preallocating memory used by javaspace
>
>
>
> Hmmm,
>
>
>
> But aren't all of those specific to your product?  That would mean
> lock-in from a user perspective due to use of non-standard features.
>
> I'm not saying people shouldn't go that way but I'd like to get a clear
> understanding of what we're trying to achieve here before making any
> talking about implementation options.
>
> In particular, I'm worried about what performance expectations there
> might be, how important continued processing of requests is etc.
>
>
>
> Best,
>
>
>
> Dan.
>
>
>
> Shay Hassidim wrote:
>
>>  xaea ,
>
>>
>
>>
>
>>
>
>>  Take a look on the Cache Policy , Persistent space , CacheLoader ,
>
>>  CacheStore , Memory usage ,  Memory Control and Mirror Service at
>
>>  GigaSpaces.
>
>>
>
>>  Just search the help with the above:
>
>>
>
>>  www.gigaspaces.com/wiki
>
>>
>
>>
>
>>
>
>>  shay
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>  -----Original Message-----
>
>>
>
>>  From: Dan Creswell [mailto:[email protected]]
>
>>
>
>>  Sent: Wednesday, August 30, 2006 3:12 PM
>
>>
>
>>  To: [email protected]
>
>>
>
>>  Subject: Re: preallocating memory used by javaspace
>
>>
>
>>
>
>>
>
>>  Gregg Wonderly wrote:
>
>>
>
>> >  xaea alvein wrote:
>
>>
>
>> > > no, it's preallocate. i'm considering setting a "quota"/"capacity" for
>
>>
>
>> > > the
>
>>
>
>> > > space, so that the memory taken by it won't exceed some x MB. is it
>
>>
>
>> > > possible?
>
>>
>
>> >
>
>>
>
>> >  What will you expect the application to do when this limit is reached
>
>>
>
>> >  because of
>
>>
>
>> >  an imbalance between producers and consumers?
>
>>
>
>> >
>
>>
>
>>
>
>>
>
>>  Gregg is heading along the right lines so more generally:
>
>>
>
>>
>
>>
>
>>  When this quota is reached what would you wish to happen?
>
>>
>
>>
>
>>
>
>>  Should the space stop accepting more entry's?
>
>>
>
>>
>
>>
>
>>  Should the space swap to disk?
>
>>
>
>>
>
>>
>
>>  Should the space signal the application in some way?
>
>>
>
>>
>
>>
>
>>  Should the application do something to manage this situation itself
>
>>
>
>>  perhaps by adopting quota's within it's own code?  If not, why not?
>
>>
>
>>
>
>>
>
>>  What do you expect to happen to throughput in these circumstances?
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>  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