Hey Tek1, Can you weigh in on the expireCache questions I posed. I'm specifically looking at what's necessary to run current Castor 0.9.5 CVS HEAD in a clustered environments. My leading idea is to use a stateless session bean running in each VM to notify it's peers via broadcast to expire their cache for specific objects. Can you make any other suggestions?
Vincent -----Original Message----- From: tek1 [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Clustering with Castor / Castor Version 1.0? At 15:04 03/05/30 -0500, you wrote: > > > > Thanks for explaining how JavaGroups works. Just registering the JDO to > > JavaGroup sounds fairly straight forward. Just trying to get a picture of > > how clustering can be implemented in Castor... So each JDO would fire off > > a "CacheEvent" (types could be OBJECT_ADDED, OBJECT_MODIFIED_, > > OBJECT_REMOVED) to JavaGroups, and each JDO's "CacheListener" would be > > registered with JavaGroups and listen for "CacheEvent"s, and update their > > local cache appropriately, depending on the CacheEvent? > >Yep. The only issue would be synchronizing the CacheEvents so that if >two Castor instances have modified versions of the "same" object and >fire off CacheEvents simultaneously, then you would need a way of >choosing which one to accept and which one to throw out. Hmmm... good point. I'll have to sleep on that one! :) In the meantime, I just created a really rough diagram (hand-written!) of one possible image of the Castor clustering functionality. It's *really* rough (obviously, I'm not an artist!), but perhaps it can serve as an initial diagram to work off of. We can work on a Visio or other computer-generated drawing later, of course. :) I attached it as a .gif (for file size reasons), but if you want the printable .pdf version, let me know. Does Castor have any similar diagrams for explaining how it works? It could help more people understand the overall architecture, which in turn might lead them to be a contributor... > > >Yes. Once we hit Castor 0.9.6 we'll be on the fast track to 1.0. My goal > > >is for 0.9.7->1.0 to be only bug fixes, additional test cases, and > > >documentation. No feature develepmont. 0.9.6 will be the last release > > >with new features, which is why we're moving slowly to that point > > >because there are still features we're trying to finish up. > > > > > >Actually we're ready to do a new release, so hopefully I'll find the > > >time this weekend to do it. > > > > So is the next release (possibly this weekend) 0.9.6, skipping 0.9.5? > >Now we won't skip 0.9.5, as there are still a number of features, for >example the JAXB compatibility layer for Castor XML. Does the JAXB layer currently exist in 0.9.4.3? If not, could the minor bug fixes in 0.9.4.3 be wrapped up, do a 1.0 release, and then release Castor 1.1 with the JAXB compatibility? Is JAXB-compatibility absolutely necessary to use Castor? A ROADMAP text file could be included with the 1.0 release stating the JAXB-compatibility is planned for the 1.1 release, and clustering for 2.0, etc. > > so, then could bug fixes for 0.9.6 be wrapped up and released as 1.0? Bug > > fixes could always be released as 1.0.1, 1.0.2, etc. Again, 1.0 milestone > > is a big psychological mark, especially since the Castor releases are not > > as frequent (i.e. monthly, roughly the case with JBoss). > >Recently we've been trying to do a Castor release bi-monthy (every two >months) but sometimes this gets pushed out if the core developers >haven't had much spare time to finish the tasks they wanted to get done >for a particular release. Completely understood. :) >It's definately psychological though. I know that "1.0" means a lot in >terms of management. To me though, 1.0 means we've finished all that we >wanted to for the 1.0 release, we've documented as much as we're going >to document and we've done as much testing as we feel necessary so that >we've created what we feel is a stable, mature product. True, but is there a "1.0 Features" document that states JAXB and other certain features were planned for the 1.0 release? If not, then the current Castor seems fairly stable enough for a 1.0 release. Regarding documentation, I did notice that the API javadocs were missing for org.exolab.castor.persist.spi.LogInterceptor (actually the whole org.exolab.castor.persist package). >yes...we won't get all the bugs, so we'll have to do 1.0.1 and 1.0.2 >releases, but I wouldn't want to do implement a bunch of new features >right before 1.0 and then say we can always do a 1.0.1 release...because >1.0 should have gone through at least a few releases of only bug fixes >so that users know that we've not sacrificed the stability of the >product. I completely agree! :) >If we come up with some new features after the eventual 0.9.6 release, >those features will go into a 1.1 branch. How about any features that do not currently exist in 0.9.4.3, be planned for the 1.1 branch (as mentioned above)? > > I noticed in a > > previous article that someone mentioned Castor never having released 1.0 > > despite it being around for a while. > >Yeah I saw that too...but the number of Castor users continues to grow, >not decline, so while there are a number of areas that we could improve >upon, such as getting to 1.0 quickly, we're still building a free >product that a large number of people want to use. Yes, the Castor community is continuing to grow. I was happy when Lance set up the WIKI also, which should also help in the adoption of Castor. > > Releasing 1.0 will definitely give > > Castor a better image, that it is capable of production use. Are there any > > major outstanding bugs preventing a sooner 1.0 release? > >You can take a peak in Bugzilla. Will do. Bugzilla is a great product, but I suggested JIRA before because it's a little easier on the eyes. :) >What we really need to do is set the full roadmap to 1.0. The problem is >that people's time for contributing to the project changes on a weekly >(if not daily) basis. So setting hard deadlines is difficult. And if you >release a deadline, people will expect you to stick to it, even on an >open source project. But I think a roadmap in terms of features and >milestones would be nice so that people can see the progress to 1.0 >being made without needing actual hard dates. Completely understood. > > Other than that, are there are real Castor killers? > >I'm not sure why anyone would want to kill Castor, hopefully improve it >instead of kill it. I meant "bugs" that would prevent Castor 1.0 from being released... Tourjours, Vive le Castor! (The little French that I still remember from my high school days...) :) Have a great weekend! :) ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
