[jboss-cluster-dev] [Fwd: Re: Infinispan in JBoss AS]

[Manik Surtani]

On 9 Jul 2009, at 17:11, Brian Stansberry wrote:

> The list bounced Jason's post so I'm forwarding it to the list until  
> he can join.
>
> -------- Original Message --------
> Subject: Re: Infinispan in JBoss AS
> Date: Thu, 09 Jul 2009 11:01:19 -0500
> From: Jason T. Greene <jason.greene at redhat.com>
> To: Brian Stansberry <brian.stansberry at redhat.com>
> CC: cluster-dev <jboss-cluster-dev at lists.jboss.org>
> References: <4A560E20.4080404 at redhat.com>
>
> A major initiative for AS6 is getting cluster management capabilities
> into the core AS (instead of relying on a disparate JON group  
> feature).

I know this should be a separate thread, but isn't building two  
separate management mechanisms counter-intuitive?  E.g., I was hoping  
JOPR could provide standalone cluster/grid management for Infinispan  
as well.  I am in Stuttgart next week to speak at their JUG and am  
hoping to catch up with Heiko Rupp to discuss this stuff.

https://jira.jboss.org/jira/browse/ISPN-126
https://jira.jboss.org/jira/browse/ISPN-127

> This involves a lot of rethinking of how we do metadata processing and
> management of that metadata (in particular having management updates
> apply to all nodes). This is a large effort, and will definitely  
> suck up
> Brian and Paul's time (in addition to the boot-time and other issues).
> As much as I would love to see infinispan take over, I don't think it
> would be a good idea to run both JBC and infinispan as it would make
> integration  more complex, and IMO lead to user confusion and support
> problems.

+100.  The thought of AS6 shipping with both Infinispan and JBC gives  
me the creeps!  :)

> I would much rather see us drop FIELD if Infinispan could not
> handle that use-case.
>
> So, IMO we need to either wait for the JPA/delta framework, or drop
> FIELD.

If need be I can bump up prio on the JPA/fine grained API for  
Infinispan (e.g., over the memcached/client-server module) which will  
make it quite likely for the end of this (calendar) year.

> In any case I think the starting point is to satisfy the
> hibernate guys with a good second level cache impl. That will  
> definitely
> get community usage faster than AS6 integration will.

This is already WIP.  Chris Bredesen volunteered to do it and has a  
prototype in place already.  I expect this to be ready when we have  
our first GA.

>
> Brian Stansberry wrote:
>> The topic of Infinispan integration into the AS has come up; seems  
>> like things are far enough along to start thinking about it.
>> Let's assume for now that AS 6.0.0 will be out at toward the end of  
>> Q2 next year. Whether I mean Q2 calendar 2010 or Q2 Red Hat FY2011  
>> is deliberately left vague. ;)  Anyway, that date is just my rough  
>> impression, could be earlier, could be later. My wisdom and  
>> experience tells me not much earlier. :)
>> I'll be very blunt and honest here. I love Infinispan; I want it in  
>> AS 6, but for Paul and I getting it in needs to be a lower priority  
>> than continuing working the long-standing cluster management/ 
>> deployment issues. Where getting Infinispan in sits relative to  
>> Paul and I working on other general AS 6 goals (faster startup,  
>> better embedded support) I'll let Jason comment.
>> The upshot of the above paragraph is I don't think it's right to  
>> count on a lot of cycles from Paul or I on this until probably  
>> after Christmas. And even then it needs to be maybe a 25-33% of our  
>> combined time thing.
>> OK, I'm done shucking and jiving. ;)
>> The big question is what to do about POJO Cache. Some options:
>> 1) Infinispan comes up with the discussed JPA-style replacement.  
>> TBH, I think that's too big a task for the timeframes/resources  
>> involved.
>> 2) We continue to use JBC/POJO Cache for FIELD granularity web  
>> session replication.
>> I hate to say it but I think #2 probably makes more sense.
>> The issue w/ #2 is how to manage both JBC and Infinispan instances.  
>> The AS has its own impl of the JBC CacheManager interface. It's  
>> actually a subinterface that exposes equivalent methods to  
>> CacheManager that return a POJO Cache.  The AS and EJB3 code uses  
>> this subinterface, so for those we have a lot of freedom to change  
>> things.  The Hibernate/JPA integrations w/ JBC and Infinispan use  
>> the JBC/Infinispan interfaces directly, and I don't want to change  
>> that in the AS. So, anyway, this is something we'd need to sort  
>> out, which doesn't seem like it would be that hard.
>> The other big area is adapting from buddy replication to DIST. I  
>> think the big task there is just going to be testing. Rewrite white- 
>> box/gray-box tests that assume BR etc.
>
>
> -- 
> Jason T. Greene
> JBoss, a division of Red Hat
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> jboss-cluster-dev mailing list
> jboss-cluster-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org