Re: [castor-dev] Clustering with Castor / Castor Version 1.0?

[Werner Guttmann]

Vincent,

Just out of interest, how would you plan to implement the 'broadcast' ?

Werner

PS If I remember this thread correctly, I think numerous suggestions had been given re: the implementation of
clustering, one of them being e.g. the use of JavaGroups (hhtp:www.javagroups.com). But in any case, this will need
quite a lot of refactoring as the implementation of clustering should be part of Castor JDO itself, and not have to rely
on a mechanism that's outisde as suggested by your solution.

On Thu, 24 Jul 2003 19:42:11 -0400, Techeira, Vincent X -ND wrote:

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