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

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