JBCACHE-928 (lifecycle state)
by Manik Surtani
Brian,
What would the use case of getState() be? Is this for use by the MC
and other mechanisms to manage the cache via JMX?
I guess what I'm asking is, where does this need to reside? In the
Cache, CacheSPI or JMX interface? And also, what statii are we
looking for? I have a simple boolean "started" at the moment, but
this could change to an enum of {CREATED, STARTED, STOPPED,
DESTROYED} ...
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 8 months
RE: [jbosscache-dev] Finalizing JBCACHE-840
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> 3) I want to finish up JBCACHE-840 tomorrow and hookup CC to
> test all non-local test with tcp jgroups stack as well.
> Should I simply add another target such as
> all-unit-test-tcp-cc? How do we tell CC to make another
> testsuite run and make a report for it?
>
Have a look at tests-clustering-all-stacks in the AS testsuite
build.xml. It basically re-runs all the tests with a different config,
and info about the config is appended to the name of the test report so
the 2nd run doesn't overwrite the 1st. I'm sure what you'd do would be
different, but you can probably gets some ideas from there.
- Brian
18 years, 8 months
Finalizing JBCACHE-840
by Vladimir Blagojevic
Hey,
We recently talked about cleaning up our META-INF directory. I changed
almost all our non-local junit tests to use unit-test-cache-service.xml
file. Here is the list of configuration files and their use:
buddyreplication-service.xml
o.j.c.buddyreplication.BuddyReplicationConfigTest.java
cache-config.xml
o.j.c..pojo.collection.CachedListTxTest.java
hibernate-recommended-config.xml,interopCurAsync-service.xml,
interopCurSync-service.xml, interopPrevAsync-service.xml,
interopPrevSync-service.xml, interopPrevSync-service.xml,
invalidationAsync-service.xml, invalidationSync-service.xml,
oodb-service.xml,node1.xml, node2.xml,
optimal-for-large-cluster-http-session-repl.xml,
replAsync-optimistic-service.xml,
replAsyncSharedCacheLoader-service.xml,
replSync-ChainingCacheLoader-service.xml,
replSync-ClusteredCacheLoader-service.xml,
replSync-eviction-service.xml, replSync-optimistic-service.xml,
singleton-nopush-service.xml, singleton-push-service.xml
not used
local-*.xml, mixedPolicy-eviction-service.xml, optimistic-eviction.xml,
policyPerRegion-eviction-service.xml, tree-service.xml
used in eviction tests
pojocache-passivation-service.xml
used in pojo cache tests and examples
replAsync-service.xml
used in old src code base
replSync-service.xml
used in examples, TreeCacheView2, CacheFactoryTest
Questions:
1) Can we safely remove files that are not used? Should we keep some? If
yes, which ones?
2) Can we somehow reuse local-*.xml and other files used in eviction
tests and thus keep a few files instead of so many? Any volunteers?
3) I want to finish up JBCACHE-840 tomorrow and hookup CC to test all
non-local test with tcp jgroups stack as well. Should I simply add
another target such as all-unit-test-tcp-cc? How do we tell CC to make
another testsuite run and make a report for it?
18 years, 8 months
CacheFactoryTest
by Vladimir Blagojevic
Any particular reason to have o.j.c.f.CacheFactoryTest is in src tree?
18 years, 8 months
RE: Problems with DefaultCacheFactory
by Brian Stansberry
Manik Surtani wrote:
<SNIP />
>>
>>> The reason why I want to make sure we reset RuntimeConfig and clone
>>> Configuration is if we have 2 cache instances in the same JVM, we
>>> may need cache-specific instances of more than just the NodeFactory.
>>>
>>
>> OK, that's fine, but
>>
>> 1) reset() should limit itself to objects that are clearly meant to
>> be cache-specific (which is what you did w/ #5 above).
>> 2) I don't think cloning the configuration is the responsibility of
>> the CacheFactory. It's the responsibility of the caller. As we
>> explore use cases for reusing configurations, we may come up with
>> some classes that help manage configurations for people, e.g. a
>> ConfigurationFactory similar to JChannelFactory. Those classes could
>> be responsible for cloning.
>
> Fair enough as well, we would have to make sure this is
> clearly documented. I'd still want to force a reset on the
> NodeFactory though; a NodeFactory should not exist before a
> Cache does. Will look into it for BETA1.
>
+1. Something like that is for sure a proper responsibility of the
CacheFactory.
>>
>> A problem here is TransactionManager, JChannelFactory and MBeanServer
>> are kind of neither fish nor fowl. They can reasonably be injected
>> into the cache and IMHO should be if the environment supports that.
>> If the environment doesn't support that, we have stuff like
>> TransactionManagerLookup to substitute for the missing IOC framework.
>
> Again, I see what you mean - an IOC framework is sorely
> missed, maybe at some stage we ought to bring the MC into the JBC
> core.
>
>>
>> Another thing to consider is whether we want the cache to have the
>> ability to look up the multiplexer in JMX, or whether that becomes
>> the task of some other integration layer (e.g. CacheJmxWrapper) that
>> updates the Configuration and builds the cache. If we remove that
>> from the cache then:
>>
>> a) JChannelFactory is only available from external injection -- i.e.
>> the cache doesn't add it to its own Configuration.
>> b) Not sure, but I think we don't need MBeanServer anymore.
>
> +1 from me on this; I'm all for the simplicity.
>
http://jira.jboss.com/jira/browse/JBCACHE-934
>>
>> That would leave only TransactionManager as the "neither fish nor
>> fowl" type.
>>
>> - Brian
18 years, 8 months
RE: Problems with DefaultCacheFactory
by Brian Stansberry
Copying the dev list, which I should have done yesterday once I went far
beyond "Have you tagged Alpha2 yet/" :-)
Manik Surtani wrote:
> On 10 Jan 2007, at 04:21, Brian Stansberry wrote:
>
>> Have you tagged Alpha2 yet?
>>
>
> Yes but I got this patch in.
>
Thanks much. Lets me use it in the AS. :-)
>> DefaultCacheFactory is making it impossible to properly construct a
>> cache from the microcontainer. Internally it's cloning the config,
>> and Configuration.clone() is resetting the RuntimeConfig. This makes
>> it impossible to build a Configuration+RuntimeConfig and then create
>> a cache from it.
>>
>> I don't think the factory should clone configs, or at least should
>> expose the flag that turns it off. The comments around it indicate a
>> concern about different caches using the same Configuration and
>> stepping on each other. IMHO, that's not a proper concern of the
>> factory -- that's something that needs to be managed by the caller
>> of the factory.
>>
>> TBH, I've kind of forgotten the purpose of the factory :-). The
>> caches in the AS are all being instantiated by CacheJmxWrapper. I
>> could easily replace the factory call there with one to new CacheImpl
>> (Configuration).
>
> :-) See http://jira.jboss.com/jira/browse/JBCACHE-930
>
> We should force all cache and node instance creation to go
> through the factory, so we have a dedicated layer where all
> construction takes place.
>
OK. Definitely one way or the other is good -- factory but able to
directly construct was confusing. :P
>> But that won't work for the Tomcat cache, which uses PojoCache.
>> PojoCache internally is using the DefaultCacheFactory to build its
>> cache (Ben that's why I cc'd you.)
>>
>> So, possibilities I see are:
>>
>> 1) CacheJmxWrapper and PojoCache just call new CacheImpl
>> (Configuration). 2) DefaultCacheFactory doesn't clone.
>> 3) CacheFactory is changed to add a createCache method that exposes
>> whether to clone. 4) Configuration.clone() doesn't call reset() on
>> the RuntimeConfig. 5) RuntimeConfig.reset() only clears the
>> NodeFactory field (I don't see why the other fields it clears need
>> to be cleared).
>>
>
> I've gone with 5 instead, for the time being. Let's revisit
> and fix this properly for BETA1.
>
Sounds good.
> Just to clarify though, I was under the impression the
> runtime configuration was generated by the cache, by
> attaching various runtime subsystems that are built based on
> the configuration XML such as the TM. The reason we exposed
> it is so that such systems could be overridden/injected at
> runtime by the MC. So it would just need to be a sequence of events
> that change:
>
> 1) create cache
> 2) start cache
> 3) inject specific subsystems such as the TM
>
> Does it not work this way with the MC?
>
No, the MC builds up the entire Configuration structure and then injects
it into the bean that instantiates the cache (bean is either a
CacheFactory instance or an instance CacheJmxWrapper, which internally
uses the CacheFactory).
In order to have the runtime objects available when needed, the sequence
would need to be:
1) Create config bean x- runtime objects
2) Use config to instantiate cache bean
3) Inject runtime objects into config bean
4) Call create() on cache bean
5) Call start() on cache bean
I don't see how the MC could possibly manage that sequence, since it
requires weaving together operations on 2 different beans (really 3
beans, since step #2 has a factory involved.) If we used
CacheJmxWrapper, and added properties to it for the runtime objects, it
could have that sequence hard coded, but that's a nasty hack.
> The reason why I want to make sure we reset RuntimeConfig and
> clone Configuration is if we have 2 cache instances in the
> same JVM, we may need cache-specific instances of more than just the
> NodeFactory.
>
OK, that's fine, but
1) reset() should limit itself to objects that are clearly meant to be
cache-specific (which is what you did w/ #5 above).
2) I don't think cloning the configuration is the responsibility of the
CacheFactory. It's the responsibility of the caller. As we explore use
cases for reusing configurations, we may come up with some classes that
help manage configurations for people, e.g. a ConfigurationFactory
similar to JChannelFactory. Those classes could be responsible for
cloning.
A problem here is TransactionManager, JChannelFactory and MBeanServer
are kind of neither fish nor fowl. They can reasonably be injected into
the cache and IMHO should be if the environment supports that. If the
environment doesn't support that, we have stuff like
TransactionManagerLookup to substitute for the missing IOC framework.
Another thing to consider is whether we want the cache to have the
ability to look up the multiplexer in JMX, or whether that becomes the
task of some other integration layer (e.g. CacheJmxWrapper) that updates
the Configuration and builds the cache. If we remove that from the
cache then:
a) JChannelFactory is only available from external injection -- i.e. the
cache doesn't add it to its own Configuration.
b) Not sure, but I think we don't need MBeanServer anymore.
That would leave only TransactionManager as the "neither fish nor fowl"
type.
- Brian
18 years, 8 months
RE: [jbosscache-dev] JBCACHE-9
by Vladimir Blagojevic
Absolutely. Resolved with comments.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Wednesday, January 10, 2007 5:37 AM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] JBCACHE-9
>
> This old-timer has been duped and closed, IIRC? Vlad, Brian,
> could you confirm?
>
> http://jira.jboss.com/jira/browse/JBCACHE-9
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
18 years, 8 months
Re: ALPHA2
by Manik Surtani
FYI, upgraded to the latest snapshot of JBoss Retro and I still see
this. Disabling jdk1.4 compat for ALPHA2, will need to fix this for
BETA1.
And just great - there's no JIRA project set up for JBoss Retro. I'm
gonna post on JBoss-dev about this.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 7 Jan 2007, at 09:29, Ben Wang wrote:
> Hmmn... I have tried for 3 different machines (2 xp and 1 linux,
> cluster01) with fresh co. They produce the same error:
>
> jbossretro:
> [mkdir] Created dir: /home/bwang/jboss/JBossCache/output/classes14
> [retro] Exception in thread "main" java.lang.NullPointerException
> [retro] at org.jboss.ant.tasks.retro.Weaver.rewriteEnum
> (Weaver.java:580)
> [retro] at org.jboss.ant.tasks.retro.Weaver.doWeave
> (Weaver.java:463)
> [retro] at org.jboss.ant.tasks.retro.Weaver.compileFile
> (Weaver.java:415)
> [retro] at org.jboss.ant.tasks.retro.Weaver.weave
> (Weaver.java:328)
> [retro] at org.jboss.ant.tasks.retro.Weaver.main
> (Weaver.java:110)
>
> So what's different?
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Sunday, January 07, 2007 2:07 AM
> To: Ben Wang
> Subject: Re: ALPHA2
>
> No, it shouldn't have any errors. What do you see? Do you have a
> fresh chkout?
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 6 Jan 2007, at 04:04, Ben Wang wrote:
>
>> OK, all set. But I have noticed that build.sh dist produces error for
>> jboss-retro. Is there something else that I need to do there?
>>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Friday, January 05, 2007 11:55 PM
>> To: Ben Wang
>> Subject: ALPHA2
>>
>> Ben,
>>
>> Could you please update tasks in JIRA targeted for 2.0.0.ALPHA2?
>> Either move them to BETA1 or 2, or close them. Keep in mind the
>> release dates for BETA1 and BETA2, I want to try and stick with
>> these.
>>
>> Thanks,
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>>
>>
>
>
18 years, 8 months