On 6 Jun 2008, at 14:05, Brian Stansberry wrote:
Manik Surtani wrote:
> On 5 Jun 2008, at 13:39, Brian Stansberry wrote:
>> The regions are created/registered after start(); i.e. after the
>> point shown in the logs. This is why I think it might just be a
>> configuration mistake that's been in AS 5 all along; just wasn't
>> exposed due to JBCACHE-1358. (In AS 4 there is no cacheloader
>> Perhaps w/ region-based marshalling I shouln't use <preload>/</
>> preload>. A nice fix to http://jira.jboss.com/jira/browse/JBCACHE-1009
>> would include logic to defer the preload until regions are
> Yes, agreed. And this is not necessarily overly complex to do
> When preloading stuff from cache loader:
> 1) Loop through all Fqns to be preloaded.
> 2) For each Fqn being preloaded, if any state is regionalised
> (i.e., a non-null region) check if the region is activated. If so,
> proceed as normal, if not skip.
> When a region is actvated:
> 1) Check if the region is a sub-region of any "preload" Fqns
> specified in your cache loader cfg.
> 2) If so, attempt to preload that Fqn, but only for regions that
> match the one being activated. Skip others.
> I wonder if it is worth fixing JBCACHE-1009 in 2.2.0. It would
> warrant another CR in 2.2.0 though. Thoughts? Votes on this?
Per your comment on lazy loading being a virtue, I don't think I
need this for AS 5. It's a nice idea though.
lol! Ok, then I'd rather leave this out for 2.2.0. Would prefer not
to change too much at this stage.
Re: another CR, probably should have one anyone so I can put it in
the AS hudson runs for a couple days before it goes GA. I can't put
in a snapshot anymore -- illegal.
Ok, before your AM tomorrow. :-)
>> TBH, I don't see why I want
<preload>/</preload> at all for this
> Yes - isn't lazy loading a virtue here anyway? :-)
Well, I like to just throw random stuff in my configs in order to
exercise all the code paths. ;)
if it helps build a better product ... ;)
> And re: 2.1.1.GA, since JBCACHE-1358 is an obvious bug in JBC, I
> may port this fix to 2.1.X which will cause future 2.1.X releases
> to break in the same way.
> Manik Surtani
> Lead, JBoss Cache
Lead, AS Clustering
JBoss, a division of Red Hat
Lead, JBoss Cache