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

Fri Jul 10 12:20:24 EDT 2009

Manik Surtani wrote:
> 
> 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
> 

Yep, for sure there should be coordination. There's obviously overlap 
when it comes to ISPN-126. ISPN-127, maybe some; provisioning an AS 
instance is different from provisioning an Infinispan instance, although 
there are of course similar problems.

The AS folks will be meeting the week after next in Westford. Charles 
Crouch will be there from the jopr team. First topic on the agenda is 
cluster management.

IMO, the tricky stuff in AS clustering management is things like 1) 
rolling redeploys 2) correctly managing configuration data that 
typically is consistent cluster-wide but doesn't have to be 3) applying 
configuration updates properly across a cluster. The graphical 
representation of cluster status is easier. Provisioning falls in the 
middle.

>> 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!  :)
> 

:) 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.

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.

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?

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