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

Fri Jul 10 13:04:46 EDT 2009

<SNIP />

> :) It doesn't that much give me the creeps, other than long-term  
> maintainability and support issues. We're talking about different  
> implementations of an SPI; neither JBC nor Infinispan are first  
> class citizens in the AS. Re: maintainability and support, we're  
> talking community AS here. I'd have no  problem w/ a JBC-based FIELD  
> in an AS 6.0 marked as a deprecated and replace with an Infinispan  
> based FINE or something in a 6.1/2.

It was maintenance/backward compat that creeped me out.  But yes, I  
suppose you are talking about the community version here. I'd hate to  
see a hybrid setup like this sneak its way in to EAP 6.

> Don't get me wrong; I don't *like* such an approach.
>
>>> I would much rather see us drop FIELD if Infinispan could not
>>> handle that use-case.
>>>
>
> That's an option too. I've been burned before pulling features for a  
> while while waiting for the next technology to support them, so I'm  
> cautious. But it's an option. I see very little evidence for much  
> usage of FIELD.
>
>>> 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.
>
> TBH, I'd much prefer that Infinispan focuses on what's right for  
> standalone Infinispan and not on getting into the AS. AIUI, that was  
> the strategy.

Well they both need to happen.  The reason why I prioritised the  
client/server module over fine grained repl/JPA is simply that it was  
designed earlier and has had more thought in it.

> We shouldn't assume a delta framework in Infinispan gets rid of the  
> FIELD web session issue. Right now the AS integration layer for  
> FIELD is probably the simplest of the SESSION/ATTRIBUTE/FIELD set  
> since it's just a matter of putting objects into PojoCache and  
> walking away. That wouldn't be the case with a delta framework,  
> since the session management layer would have to coordinate.
>
> Maybe that's no big deal. It's just that I'm not going to promise  
> that Paul and I will develop that for AS 6. Jason's spelled out the  
> priorities; FIELD isn't one. If higher priorities consume the  
> resources, then...
>
>>> 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.
>
> Cool. I know he's been making progress.
>
>
> Let's step back and question some assumptions -- at least my  
> assumptions. ;)
>
> ASSUMPTION: Infinispan needs to replace JBC in AS 6.0.0 or it can't  
> until AS 7.0.0.
>
> Is that true? Could the switch happen in whatever 6.x minor release  
> we feel comfortable?

Like I said I'm more concerned about EAP since this is where the  
support/maintenance/backward-compat issues are going to be.

> a) We replaced the JMS server from EAP 4.2 to 4.3. So there's  
> precedent for big changes.
> b) For stuff like web sessions, sfsbs, HA-JNDI, what cache we use is  
> an internal implementation detail. Changing it affects configuration  
> for power-users, but I'd argue changing configs for power users is  
> within the scope of a minor release.
> c) For Hibernate/JPA, there's one place in persistence.xml where  
> people  specify a JBC-specific Hibernate RegionFactory impl. But we  
> could probably make a simple compatibility layer that allows that to  
> work, in which case we're again down to configuration changes for  
> power users.
> d) Custom uses of JBC by end users.  The end user would just have to  
> provide JBC jars themselves.
> e) Management tools. We just don't change to Infinispan until a  
> release cycle where we have time to make the necessary management  
> tool changes. Although I doubt it's as simple as that.
>
>>>
>>> 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
>
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat

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