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