JBCACHE-1156 - configuration profiles
by Manik Surtani
Brian,
I had a look at what you checked in for this; it looks pretty good,
but why a package called 'registry'? This tends to make me think of
other things, like a component registry, perhaps something related to
DI even.
Regarding the methods you have, around getCacheNames, getCache,
releaseCache, etc., I wonder whether this should be a part of the
DefaultCacheFactory.
The bit on profiles - the ConfigurationRegistry as you called it -
makes sense to be separate though, since this is where profiles can be
saved/shared.
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
17 years, 11 months
Default JGroups configs
by Manik Surtani
Any idea why the default configs still are:
public String getDefaultClusterConfig()
{
return "UDP(mcast_addr=224.0.0.36;mcast_port=55566;ip_ttl=32;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=1000;num_initial_members=2):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.NAKACK
(gc_lag=50;retransmit_timeout=600,1200,2400,4800):" +
"UNICAST(timeout=600,1200,2400,4800):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"FRAG(frag_size=8192):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true):" +
"pbcast.STATE_TRANSFER";
}
instead of using STREAMING_STATE_TRANSFER and FLUSH instead of
STATE_TRANSFER? Any good reasons not to change it?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
18 years
Re: [jbosscache-dev] JDBCCacheLoader drop table - true by default??
by Galder Zamarreno
Might be worth adding an attention note in the Release Notes of JBC 2.1
to indicate the change of default behavior too, thoughts?
Mircea Markus wrote:
> This changed in cache 2.1 - I've updated the wiki accordingly.
> Galder Zamarreno wrote:
>>
>>
>> Manik Surtani wrote:
>>> From AdjListJDBCCacheLoaderConfig.setProperties():
>>>
>>> prop = props.getProperty("cache.jdbc.table.drop");
>>> this.dropTable = (prop == null || Boolean.valueOf(prop));
>>>
>>> Surely this isn't intended? The impact of this is that if someone
>>> using a JDBCCacheLoader doesn't specify cache.jdbc.table.drop =
>>> false, the table is dropped every time the cache is stopped!! So
>>> much for persistent state! :-)
>>
>> faq: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheTroubleshooting
>>
>> hehehehe, i once had a support case on this, hence me adding this to a
>> wiki :)
>>
>>>
>>> Thoughts?
>>> --
>>> Manik Surtani
>>>
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
18 years
JDBCCacheLoader drop table - true by default??
by Manik Surtani
From AdjListJDBCCacheLoaderConfig.setProperties():
prop = props.getProperty("cache.jdbc.table.drop");
this.dropTable = (prop == null || Boolean.valueOf(prop));
Surely this isn't intended? The impact of this is that if someone
using a JDBCCacheLoader doesn't specify cache.jdbc.table.drop =
false, the table is dropped every time the cache is stopped!! So
much for persistent state! :-)
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
18 years
MUX issues with JGroups 2.6.Beta1 and JBoss Cache
by Manik Surtani
Guys,
As you may know I finally have Hudson behaving reasonably well,
running the JBC test suite off trunk. To do this I've had to disable
all MUX related tests since these caused the test suite to deadlock.
I haven't delved further as to why, but will be doing so today. I
haven't tried rolling back to JG 2.5 as a control test (since code
changes have now been introduced, adding a few dependencies on JG
2.6's API), but again stuff I will be investigating later.
Just an early heads-up.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
18 years
Support for JBoss JTA and pluggable TM testing complete
by Jason T. Greene
Everyone,
I have added support for JBoss JTA standalone in Core Cache. To enable
it simply define transactionManagerLookupClass to be "JBossStandalone
JTAManagerLookup".
I have also modified our testsuite to support a pluggable TM. This
includes a new testing profile for JBossJTA. When adding future tests
that you would like to be included in this profile, make sure you put
them in the "transaction" group. This can be ran as follows:
mvn -Ptransaction-jbossjta
It is very important that all new tests be TM portable (I have already
fixed the existing ones). So, unless you are explictly testing a
specific TM, you should use the following techniques when using
transactions:
1. Configure the transaction manager using
TransactionSetup.getManagerLookup like so:
cache.getConfiguration().setTransactionManagerLookupClass(TransactionSetup.getManagerLookup());
2. Obtain UserTransaction from TransactionSetup.getUserTransaction();
3. Obtain the transaction manager, if you need it, from the cache:
cache.getConfiguration().getRuntimeConfig().getTransactionManager();
Alternatively, if there is no cache in your test, you can use
TransactionSetup:
TransactionSetup.getTransactionManager();
4. Always use TransactionManager.commit()/setRollbackOnly()/rollback()
where possible. Calling Transaction.commit() and Transaction.rollback()
does _not_ clear the Transaction associated with the current thread.
According to the spec future begin() calls must fail, so if you do this
it becomes your job to clear the thread (using suspend). Alot of test
code did not do this properly, which was fine with
DummyTransactionManager, but broke any spec compliant TM.
-Jason
18 years
Hudson view of JBoss Cache builds
by Manik Surtani
This is now a public URL.
http://hudson.jboss.org/hudson/view/JBoss%20Cache/
It does regular builds and right now just publishes the 1.4.x branch.
QA is working on getting the builds from trunk (pojo and core, JDK
1.5 and JDK 1.6) published here too - they expect to have it up there
by the end of the week.
We're getting there. :-)
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
18 years
Re: [jbosscache-commits] JBoss Cache SVN: r4530 - core/trunk/src/test/java/org/jboss/cache/multiplexer.
by Jason T. Greene
Mircea,
Instead of commenting out, you can do:
@Test(enabled=false)
This allows us to track disabled tests in the future, although surefire
doesn't help us with that at the moment.
-Jason
jbosscache-commits(a)lists.jboss.org wrote:
> Author: mircea.markus
> Date: 2007-10-03 11:27:38 -0400 (Wed, 03 Oct 2007)
> New Revision: 4530
>
> Modified:
> core/trunk/src/test/java/org/jboss/cache/multiplexer/BadMuxConfigTest.java
> Log:
> temporarly commented a test that was hanging
>
> Modified: core/trunk/src/test/java/org/jboss/cache/multiplexer/BadMuxConfigTest.java
> ===================================================================
> --- core/trunk/src/test/java/org/jboss/cache/multiplexer/BadMuxConfigTest.java 2007-10-02 19:10:37 UTC (rev 4529)
> +++ core/trunk/src/test/java/org/jboss/cache/multiplexer/BadMuxConfigTest.java 2007-10-03 15:27:38 UTC (rev 4530)
> @@ -60,9 +60,10 @@
>
> public void testValidMuxConfig() throws Exception
> {
> - muxHelper.configureCacheForMux(cache);
> -
> - checkStart(false, true);
> + //todo this test hangs on forever. Uncomment it and make it work...
> +// muxHelper.configureCacheForMux(cache);
> +//
> +// checkStart(false, true);
> }
>
> public void testMissingMuxChannelFactory() throws Exception
>
> _______________________________________________
> jbosscache-commits mailing list
> jbosscache-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-commits
18 years
