Pulling the FileCacheLoader from 3.0.0
by Manik Surtani
What do you guys think? Too many people try and use this in
production and then complain that it doesn't work. It is not
transactional and cannot withstand a JVM crash midway during a write.
Should we deprecate this in 2.2.0 and remove it in 3.0.0?
I know that JBoss AS uses it in some cases, but can that not be
changed to use the JDBM cache loader?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years
JBoss Cache, JGroups and TestNG
by Manik Surtani
Looking at using the thread counts and parallelizing test execution in
TestNG (as Bela has done with JGroups), one of my biggest stumbling
blocks is that quite a few tests end up starting and stopping
replicated JBoss Cache instances. If these tests were to be run in
parallel, they would detect each other and produce unexpected results.
Question for any of the JGroups guys on this list: how did you get
around this with creating JGroups channels, as I expect you have the
same problem? Or do you not run tests that create/start channels in
parallel?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 1 month
JBCACHE-471 - Handling JGroups MERGE
by Manik Surtani
This was on 2.2.0's task list:
http://jira.jboss.com/jira/browse/JBCACHE-471
The last time we spoke about this was in Neuchatel, and we decided
we'd expose an interface, a MergeHandler, that people could
implement. We'd also provide a few standard implementations, like
EvictEntireClusterStateHandler and FatalStopMergeHandler? I think a
SingleWinnerHandler and DisjointedSubtreeMergeHandler can come later,
as they would both involve a proxying mechanism to talk to remote
caches being in place - something which will be developed as a part of
Partitioning [1].
We didn't discuss the design of this interface - how about a single
callback with:
public interface MergeHandler
{
void handleMerge(Cache currentInstance, List<Address>
winningSubPartition, List<Address> losingSubPartition);
}
Can we see any other information being needed?
[1] http://jira.jboss.org/jira/browse/JBCACHE-60
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 1 month
Re: [jbosscache-dev] AS Integration tests in JBC test suites
by Brian Stansberry
Mircea Markus wrote:
>
>
> Brian Stansberry wrote:
>> Manik Surtani wrote:
>>> +1.
>>>
>>> How do you foresee this, as a separate suite of tests? E.g.,
>>> src/integration-test/java? And how about integration with Hudson?
>>> Run on every build? Every release?
>>>
>>
>> Hadn't really thought that far. :-)
>>
>> I *was* thinking in terms of just a separate package (with
>> subpackages) under src/test/java. Say org.jboss.cache.integration or
>> something. But, yeah, there's no need to run these every build, just
>> before release, so lets organize in whatever way makes it easy to
>> control when they get run.
>>
> Do we expect these tests to perform slow?
Maybe a bit. The general AS use cases involve things like failover after
async repl, so you need to pause a bit to be sure the repl had time to
happen. Also passivation, where there is some pausing to allow
passivation timeouts to happen. Stuff like that.
> If not, I guess running them
> together with the common test suite would only bring an additional
> safety net... I also think that it worths having them in an different
> package as they will mainly be written by the teams that needs
> integration (Brian I think :) )
For sure we want a distinct package. :) Gotta ensure we cover all the
use cases; if tests are spread in random places it's too hard to track
whether we did that or not.
>> Re: hudson, since we don't want them run on every build, IMO it would
>> be good to have a separate, unscheduled, hudson job to run w/ them
>> included. They need to run before release, but we should also make it
>> easy for a dev to kick off a run that includes them so problems can be
>> caught early.
>>
>>> On 18 Mar 2008, at 17:26, Brian Stansberry wrote:
>>>> I'd like to propose adding a package structure in the core cache and
>>>> pojo cache testsuites for adding tests of compliance with the
>>>> behavior the AS and Hibernate expect from JBC. Basically, in these
>>>> packages the AS developers would write tests that simulate the AS
>>>> and Hibernate usage of JBC. Simulations would *not* add any new
>>>> dependencies. Goal over time is to 99.5% eliminate the chances of
>>>> finding JBC-caused regressions in the AS/Hibernate testsuites by
>>>> ensuring they are caught in JBC itself.
>>>>
>>>> Right now a lot of issues slip through because the JBC test suites
>>>> have a hard time covering all of its permutations of features.
>>>> Something gets changed and a test gets added, but it doesn't cover
>>>> the configuration set AS/Hibernate uses, so we get a regression at
>>>> the AS level.
>>>>
>>>> Downside to this is theoretically everything we add in these new
>>>> packages should be redundant. But in practice that will be hard to
>>>> achieve.
>>>>
>>>
>>> When you say redundant, do you mean duplication between the
>>> AS/Hibernate test suite and JBC's test suite (+1 in this case), or
>>> duplication between JBC's unit test suite and integration test suite
>>> (-1 in this case)?
>>>
>>
>> Meant both, although I was really talking about the latter. The idea
>> here is these integration tests set up caches configured that match
>> what AS/Hib uses and then exercise the call patterns that AS/Hib
>> makes. In a perfect world, those call patterns are exercised with
>> those configuration options somewhere else in the JBC testsuite. But
>> the world isn't perfect; there are too many permutations.
>>
>> Part of the tradeoff here is Paul and I will be working to expand the
>> JBC suite and covering code paths not otherwise covered. But when we
>> make this effort we just think "here's the config, here's the call
>> pattern." We don't spend time digging through all the hundreds of
>> tests in the main testsuite looking for redundancy.
>>
>> Of course, if one of these tests surfaces a bug, a test in the regular
>> testsuite showing the bug should be added.
>>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
16 years, 1 month
Naming 2.2.0 and 3.0.0
by Manik Surtani
Alright, that time has come again for some creative naming of upcoming
JBC releases. :-)
Thoughts and opinions, people?
Poblano and Naga? :-)
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 1 month
AS Integration tests in JBC test suites
by Brian Stansberry
I'd like to propose adding a package structure in the core cache and
pojo cache testsuites for adding tests of compliance with the behavior
the AS and Hibernate expect from JBC. Basically, in these packages the
AS developers would write tests that simulate the AS and Hibernate usage
of JBC. Simulations would *not* add any new dependencies. Goal over
time is to 99.5% eliminate the chances of finding JBC-caused regressions
in the AS/Hibernate testsuites by ensuring they are caught in JBC itself.
Right now a lot of issues slip through because the JBC test suites have
a hard time covering all of its permutations of features. Something
gets changed and a test gets added, but it doesn't cover the
configuration set AS/Hibernate uses, so we get a regression at the AS level.
Downside to this is theoretically everything we add in these new
packages should be redundant. But in practice that will be hard to achieve.
Comments?
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
16 years, 1 month
JBoss Cache 2.2.0
by Manik Surtani
Guys,
What do you think should be in 2.2.0, and what should be in 3.x? Not
just for Core, but POJO as well?
I think that 2.2.0 should be a very quick release, my target for GA
being mid-May or so, so we can get back on to 3.x tasks (some of
which, like MVCC, I will be doing in parallel to 2.2.0 tasks).
Brian, does this make sense, since the main goal of 2.2.0 is, apart
from some more refactoring and a few features, to be rock-solid for AS
5 (given the way AS 5 deadlines are moving). With GA targeted for mid-
May, I would think the first betas would start coming out in 2 - 3
weeks?
Main tasks for core cache:
- bug fixes reported on 2.1.0, inc. JBCACHE-1170, JBCACHE-1190,
JBCACHE-1258
- new features, inc. JBCACHE-789, JBCACHE-1262, JBCACHE-1273
- optimisations/refactoring, inc. JBCACHE-890, JBCACHE-611,
JBCACHE-1222, JBCACHE-1239,
Jason, what are your thoughts for POJO Cache?
Cheers
Manik
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 1 month
Add a 'JBossAS' profile to pom.xml for PojoCache
by Galder Zamarreno
Hi,
Re: http://jira.jboss.com/jira/browse/PCACHE-60
I've been playing around with this JIRA and there's a couple of things
I've noted:
1.- When we build cache-core with JBossAS profile, the generated pom
file still points to the original dependencies, which means that in the
cache-pojo's pom.xml, we have to repeat the cache-core dependencies for
JBossAS profile.
If a project depends on library A-1.0.0.GA and the profile specifies
dependency on A-1.0.0.SP1, you'd expect that any build artifacts
generated, i.e. pom.xml, would have main dependency switched to
A-1.0.0.SP1 but it doesn't. So, you have built a new jar with profile
dependencies but when it's used by another project, it still downloads
original dependencies.... useless. I'm gonna follow this up with Maven
users and see what I can find.
For the time being, until I've found a better solution, dependencies in
JBossAS profile in cache-core will be repeated in cache-pojo.
2.- As cache-pojo's pom.xml says about the maven jbossaop plugin, "
<!-- HACK: AOP project and plugin has broken deps -->", the
dependencies for jbossaop are broken, so we have to repeat them. This
has a direct effect on creating a brand new profile for JBossAS.
Even though I've updated JBossAS dependencies, I need to add similar
dependencies to the maven-jbossaop-plugin in order for aopc to happen
with the desired dependencies.
Now, in a profile, you can't override the following section of the main
pom.xml:
<build>
<plugins>
...
This means that I need to define all JBoss AOP dependencies for
maven-jbossaop-plugin that we might want to override in JBossAS profile.
For example jboss-javaee, microcontainer...etc using properties and
define the versions at the top of the pom.xml and then define these same
properties for JBossAS profile. For example:
<properties>
<jbosscache-pojo-version>2.1.0.CR4</jbosscache-pojo-version>
<jbosscache-core-version>2.1.0.CR4</jbosscache-core-version>
<jboss.aop.version>2.0.0.CR3</jboss.aop.version>
<jboss.microcontainer.version>2.0.0.Beta6</jboss.microcontainer.version>
</properties>
...
<groupId>org.jboss.maven.plugins</groupId>
<artifactId>maven-jbossaop-plugin</artifactId>
<version>2.0.0.beta1</version>
...
<dependency>
<groupId>org.jboss.microcontainer</groupId>
<artifactId>jboss-container</artifactId>
<version>${jboss.microcontainer.version}</version>
</dependency>
...
<profiles>
<profile>
<id>JBossAS</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<jbosscache-pojo-version>2.1.0.CR4-JBossAS</jbosscache-pojo-version>
<jbosscache-core-version>2.1.0-SNAPSHOT-JBossAS</jbosscache-core-version>
<jboss.aop.version>2.0.0.CR7</jboss.aop.version>
<jboss.microcontainer.version>2.0.0.Beta10</jboss.microcontainer.version>
...
Having to do this is a royal pain in the butt and can lead to incorrect
version definitions. Thoughts? Has anyone looked into fixing the broken
maven aop plugin?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
16 years, 1 month
Re: JGroups Shared Transport support in JBC
by Brian Stansberry
Sure, no problem.
When are you expecting 1.4.1.beta2 out?
Tim Fox wrote:
> Yeah this is probably a trivial change on our side, but we just haven't
> got round to looking at it yet. :(
>
> If it's high priority I'll take a look soon, tomorrow ok?
>
> Cheers
>
> Brian Stansberry wrote:
>> Sorry Tim, I'd meant to include you on this thread from the start. :(
>>
>> We were having a discussion of how to handle the difference between a
>> JGroups JChannel w/ a shared transport (new in 2.6.2) and the old
>> multiplexer MuxChannel.
>>
>> If you call ChannelFactory.createMultiplexerChannel() the return type
>> is Channel, but the code actually returns the MuxChannel
>> implementation class. Which is reasonable; the name of the method
>> implies the multiplexer will be used.
>>
>> But, a shared transport JChannel is actually a much better solution to
>> JGroups resource sharing. So, question is how to get a shared
>> transport JChannel into users' hands.
>>
>> 1) Have them specifically ask for a JChannel by calling
>> ChannelFactory.createChannel(String) instead of
>> ChannelFactory.createMultiplexerChannel(). Puts the issue back in the
>> user service; e.g. JBC might add a config property to help it
>> determine if a call to createMultiplexerChannel() or createChannel()
>> is the desired way to go. Or maybe just switch to createChannel().
>>
>> 2) Have the createMultiplexerChannel() method internally decide
>> whether to return a MuxChannel or a shared transport JChannel.
>>
>> Due to the late date this came up, my plan for AS 5 was #2.
>> JBMESSAGING-1244 is a problem with that plan, but I see you have a JBM
>> 1.4.1.BETA2 Fix Version on that, so I think it's OK.
>>
>> #1 isn't workable yet; it requires a minor change in JGroups that
>> won't be out until 2.6.3. After I found JBMESSAGING-1244, I pinged
>> Bela/Manik to see if it could be done quickly in case JBMESSAGING-1244
>> was something that wouldn't get done in time for AS 5. Sounds like
>> it's not an issue.
>>
>> Tim Fox wrote:
>>>
>>>
>>> Manik Surtani wrote:
>>>> Is Tim even on this list?
>>>
>>> On jbosscache-dev - no I'm not
>>>
>>> Can someone recap?
>>>
>>>>
>>>> On 4 Mar 2008, at 11:58, Bela Ban wrote:
>>>>
>>>>> Releasing 2.6.3 is not really feasible, as I've just released
>>>>> 2.6.2. So, if the change in JBC and JBM is minor (which I think it
>>>>> is), then I'd appreciate your guys fixing this.
>>>>> Cheers,
>>>>>
>>>>> Manik Surtani wrote:
>>>>>> And I could implement this in JBC 2.1.0.GA easily enough, but if
>>>>>> there is a viable workaround I'd rather leave this for 2.2.0 given
>>>>>> current timeframes.
>>>>>>
>>>>>>
>>>>>> On 4 Mar 2008, at 07:14, Bela Ban wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Brian Stansberry wrote:
>>>>>>>> Being able to handle this in JBC 2.1.0 is a bit more of an issue
>>>>>>>> due to a bug in the way JBM handles a Channel.connect() call
>>>>>>>> (http://jira.jboss.com/jira/browse/JBMESSAGING-1244). The bug
>>>>>>>> basically means JBM will fail if it calls
>>>>>>>> ChannelFactory.createMultiplexerChannel() and the call doesn't
>>>>>>>> return a MuxChannel. So, my intended approach for AS 5
>>>>>>>> (override createMultiplexerChannel()and return a regular
>>>>>>>> JChannel if it's configured for shared transport) breaks JBM.
>>>>>>>>
>>>>>>>> Maybe they'll get JBMESSAGING-1244 fixed in time for AS 5; maybe
>>>>>>>> not.
>>>>>>>
>>>>>>> I certainly hope so, sounds like a small change (use a JChannel
>>>>>>> type rather than a MuxChannel (extends JChannel))...
>>>>>>>
>>>>>>>> If we can get a JGroups 2.6.3
>>>>>>>
>>>>>>> Another release, so soon after 2.6.2 ? Only if absolutely
>>>>>>> necessary. Seems to me that Tim can fix his stuff much more
>>>>>>> quickly... In any case, let me know, I need a few days to get a
>>>>>>> 2.6.3 out (including fixing the NPE you opened).
>>>>>>>
>>>>>>>> and JBC 2.1.0.GA able to call ChannelFactory.createChannel(),
>>>>>>>> then I can just let JBM get a MuxChannel.
>>>>>>>
>>>>>>> This is possible in 2.6.3 by which feature/bug I implemented ?
>>>>>>>
>>>>>>> --
>>>>>>> Bela Ban
>>>>>>> Lead JGroups / Clustering Team
>>>>>>> JBoss - a division of Red Hat
>>>>>>
>>>>>> --
>>>>>> Manik Surtani
>>>>>> Lead, JBoss Cache
>>>>>> manik(a)jboss.org
>>>>>> msurtani(a)redhat.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Bela Ban
>>>>> Lead JGroups / Clustering Team
>>>>> JBoss - a division of Red Hat
>>>>>
>>>>
>>>> --
>>>> Manik Surtani
>>>> Lead, JBoss Cache
>>>> manik(a)jboss.org
>>>> msurtani(a)redhat.com
>>>>
>>>>
>>>>
>>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
16 years, 1 month
