Announcing JBoss Cache 2.2.0 "Poblano"

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.jbos
s.org/jira/secure/ConfigureReport.jspa?versions=12311704&
;sections=1&sections=2&sections=3&style=html&
;selectedProjectId=10051&reportKey=pl.net.mamut%3Areleas
enotes&Next=Next
[2] http://anonsvn.jboss.org/repos/jbosscache/core/ta
gs/2.2.0.BETA1
[3] http://w
ww.jboss.org/file-access/default/members/jbosscache/freezone
/docs/2.2.0.BETA1/apidocs/index.html
[4] http://repository.jboss.org/maven2
/org/jboss/cache/jbosscache-core/2.2.0.BETA1

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org

_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

And benchmark results:
http://wiki.jboss.org/auth/wiki/en/Jbc210vsJbc220Per
formance

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.jbos
s.org/jira/secure/ConfigureReport.jspa?versions=12311704&
;sections=1&sections=2&sections=3&style=html&
;selectedProjectId=10051&reportKey=pl.net.mamut%3Areleas
enotes&Next=Next 
>
> [2] http://anonsvn.jboss.org/repos/jbosscache/core/ta
gs/2.2.0.BETA1
> [3] 
> http://w
ww.jboss.org/file-access/default/members/jbosscache/freezone
/docs/2.2.0.BETA1/apidocs/index.html 
>
> [4] 
> http://repository.jboss.org/maven2
/org/jboss/cache/jbosscache-core/2.2.0.BETA1 
>
>
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manikjboss.org
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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!

Why is it that async performance has been improved much more
than sync?

Mircea Markus wrote:
> And benchmark results:
> http://wiki.jboss.org/auth/wiki/en/Jbc210vsJbc220Per
formance
>
> 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.jbos
s.org/jira/secure/ConfigureReport.jspa?versions=12311704&
;sections=1&sections=2&sections=3&style=html&
;selectedProjectId=10051&reportKey=pl.net.mamut%3Areleas
enotes&Next=Next 
>>
>> [2] http://anonsvn.jboss.org/repos/jbosscache/core/ta
gs/2.2.0.BETA1
>> [3] 
>> http://w
ww.jboss.org/file-access/default/members/jbosscache/freezone
/docs/2.2.0.BETA1/apidocs/index.html 
>>
>> [4] 
>> http://repository.jboss.org/maven2
/org/jboss/cache/jbosscache-core/2.2.0.BETA1 
>>
>>
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manikjboss.org
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-devlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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/Jbc210vsJbc220Per
formance
>>
>> 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.jbos
s.org/jira/secure/ConfigureReport.jspa?versions=12311704&
;sections=1&sections=2&sections=3&style=html&
;selectedProjectId=10051&reportKey=pl.net.mamut%3Areleas
enotes&Next=Next
>>> [2] http://anonsvn.jboss.org/repos/jbosscache/core/ta
gs/2.2.0.BETA1
>>> [3] http://w
ww.jboss.org/file-access/default/members/jbosscache/freezone
/docs/2.2.0.BETA1/apidocs/index.html
>>> [4] http://repository.jboss.org/maven2
/org/jboss/cache/jbosscache-core/2.2.0.BETA1
>>>
>>> -- 
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> manikjboss.org
>>>
>>>
_______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-devlists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-devlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Good work guys )

Mircea Markus wrote:
> And benchmark results:
> http://wiki.jboss.org/auth/wiki/en/Jbc210vsJbc220Per
formance
> 
> 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.jbos
s.org/jira/secure/ConfigureReport.jspa?versions=12311704&
;sections=1&sections=2&sections=3&style=html&
;selectedProjectId=10051&reportKey=pl.net.mamut%3Areleas
enotes&Next=Next 
>>
>> [2] http://anonsvn.jboss.org/repos/jbosscache/core/ta
gs/2.2.0.BETA1
>> [3] 
>> http://w
ww.jboss.org/file-access/default/members/jbosscache/freezone
/docs/2.2.0.BETA1/apidocs/index.html 
>>
>> [4] 
>> http://repository.jboss.org/maven2
/org/jboss/cache/jbosscache-core/2.2.0.BETA1 
>>
>>
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manikjboss.org
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-devlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

-- 
Galder Zamarreņo
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev