On 2 May 2008, at 13:26, Vladimir Blagojevic wrote:
Refactoring that you have done and the current architecture should
be documented in a paper. Could be used in architecture
documentation and as a starting point for potential contributors.
Very cool stuff Manik and Mircea!
Thanks. We plan stick this up on a wiki with UML diagrams as well as
starting points on how to enhance and extend so new features can
easily be developed.
Why is it that async performance has been improved much more than
sync?
Our theory is that the "real" performance gain in JBC is represented
by the async numbers since a large part of the sync numbers involves
blocking on JGroups replication messages, and the time taken on these
should be exactly the same in both versions of JBC tested. With async
this doesn't come into the picture and the comparison is more "pure".
Really excited to see what we can do with MVCC now on top of this -
the biggest bottlenecks, as always is still locking. :-)
Mircea Markus wrote:
> And benchmark results:
>
http://wiki.jboss.org/auth/wiki/en/Jbc210vsJbc220Performance
>
> Manik Surtani wrote:
>> 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
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org