JGroups concurrent stack and parallelizing messages from the same sender
by Manik Surtani
The concurrent stack has done a great job in parallelizing delivery of
messages from different senders, but is there a way to parallelize
this from the same sender as well? Now I know this doesn't make sense
in terms of JGroups messages (order needs to be maintained) but when
you consider moving up one level of abstraction in JBC, this causes a
bottleneck. Consider, for example:
1. Using sync replication and BR.
2. 3 threads on cache1, working on disjoint data sets (no contention
at all, writes can be in parallel).
3. When it comes to replication to the same buddy, the concurrent
stack on the receiver will queue the 3 commits.
4. All parallelization achieved in 2. above is wasted since the
transactions need to queue anyway.
Is there something we can do with custom message headers, etc. to
allow for parallel delivery of these messages? E.g., perhaps using a
"communication id", which could be a representation of a global
transaction? Bela, Vladimir, any thoughts?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years
MC style JDBCCacheLoader configuration
by Galder Zamarreno
Hi all,
Re: https://enterprise.redhat.com/issue-tracker/175979
While resolving this case, customer asked how to transform the given
JDBC CacheLoaderConfig section (see attached
mbean-cacheloaderconfig.xml) into MC style deployment. The result can be
found in the attached mc-cacheloaderconfig.xml.
I'd like to put this somewhere and I can think 3 places for it:
- wiki (my firm fav)
- jbc docu
- example deployment descriptor distributed with JBC and/or AS.
Wiki is probably the best place to put this type of example
configuration files as we're likely be asked to provide more like this
and it's the easiest way for people to contribute. Thoughts?
Staying on the same topic, while trying to create the MC version of that
configuration, I worked with a prototype that use <property> elements
for each of the cache loader configuration properties. However, this was
not really viable because it would require setter/getter for each and
every property, see attached mc-cacheloaderconfig-properties.xml.
Initially, before I came out with the final solution, I was thinking of
creating a JIRA to get the setter/getters created, but given the final
solution does not require any changes and fits well the purpose of
setProperties(), I don't think there's a need for a JIRA. Thoughts?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
16 years, 1 month
Announcing JBoss Cache 2.2.0 "Poblano"
by Manik Surtani
Exciting news! 2.2.0.BETA1 has been released. This is a very
interesting release for us, for a number of reasons:
* Big architectural change for the internals, where each API method is
implemented as a Command, which has the knowledge to perform and
rollback. Does away with the monolithic CacheImpl class.
* New interceptor structure means that implementations have strongly
typed callbacks for each Command invoked. No more casting to get
parameters, or switch statements based on MethodCall id.
* Both of the above translate to a much more straightforward code base
that is easier to read, modify and extend, but most importantly, unit
test.
* Still 100% backward compatible. And we have tests for this. Both
on a wire protocol level (Marshallers know how to map Commands to old-
style MethodCalls and vice versa) as for custom interceptor
implementations (the old Interceptor class still exists, with a
compatible invoke() method, and although deprecated now, still behaves
the same way it used to and plays nice with the new framework)
* No regressions when running with Hibernate trunk - need to verity
with EJB3 and HTTP session repl.
* A few new features implemented (see JIRA [1]), such as JBCACHE-1258
and JBCACHE-1320
* .... and, a nice surprise - some very tasty performance gains (in
double digits)! Mircea will follow up this email with benchmark
numbers and pretty pictures, sitting around a profiler sure pays
off. :-)
Download this and give it a try - this is a very big release for us,
and as much feedback as early as possible would help. Check it out
from SVN [2], check out the javadocs [3], and download and try out the
release in your applications! It is not up on sourceforge yet, but it
should go up shortly. In the meanwhile, you can grab the release from
our maven2 repository [4].
Cheers
Manik
[1] http://jira.jboss.org/jira/secure/ConfigureReport.jspa?versions=12311704&...
[2] http://anonsvn.jboss.org/repos/jbosscache/core/tags/2.2.0.BETA1
[3] http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs...
[4] http://repository.jboss.org/maven2/org/jboss/cache/jbosscache-core/2.2.0....
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 1 month
Hibernate testsuite bound to internals of JBoss Cache 2.X
by Manik Surtani
I just spotted this, trying to run the Hibernate test suite against a
snapshot of 2.2.0:
org
.hibernate
.test.cache.jbc2.functional.util.CustomClassLoaderCacheFactory uses an
internal class, CacheImpl.java, that no longer exists in 2.2.0.
Brian, I vaguely remember you mentioning this to me in the past,
should have provided a proper extension point at the time. Do you
know if it is just this test class that extends DefaultCacheFactory,
or do you know if this is extended in this manner in production code
as well - in any of the AS clustering projects?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 1 month