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

Manik Surtani wrote: 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. :) 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. 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. 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... 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 Lead, AS Clustering JBoss by Red Hat