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(a)redhat.com&gt; To: Brian Stansberry <brian.stansberry(a)redhat.com&gt; CC: cluster-dev <jboss-cluster-dev(a)lists.jboss.org&gt; References: <4A560E20.4080404(a)redhat.com&gt; A major initiative for AS6 is getting cluster management capabilities into the core AS (instead of relying on a disparate JON group feature).

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.

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.

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.

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev

:) 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev > -- > Manik Surtani > manik(a)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 wrote: > <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. My preference is that we just drop HTTP field from AS6, for the following reasons: 1. It's barely used today (main because the following point) 2. It's a hassle to enable (requires aop precompiling your code) 3. There are other options available (putting leaner objects/ primitives in the session) 4. The use-case is going to be less common with the modern EE6 frameworks (@SessionScoped 299 beans, and @StatefulSession ejb3 beans) In any case, we probably definitely don't want it in EAP6 since we then have to support it for 5 years.

IMO We should focus on getting Infinispan doing normal replication for AS6, and we can always add it in a 6.x release. It's also fine if that 6.x release becomes a EAP 6.1. So let's not rush this.

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

On 10 Jul 2009, at 18:14, Jason T. Greene wrote: > Manik Surtani wrote: >> 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 > > Where we draw the line was a topic discussed recently with the JON > team. The consensus was that the management APIS of the AS need to > encompass a cluster/domain, while JOPR manages multiple > clusters/domain. There is no duplication here because both management > views (jopr or embedded jopr) expose the same capabilities using the > same central control point (the as profile service management api). > > This is for the following reasons: > > 1) The embedded console needs to be capable of doing it > 2) Users/customers need to be able to automate this programmatically > from their own provisioning tools, scripts etc. > 3) Consistency between the cluster configuration and the management view. > 4) The cluster manager is in the best position to control rolling > updates (configuration or deployment). Good. Then in seems like JOPR will evolve into something I can use for this, based on the information I expose to JOPR via JMX. Perfect.