Bundling JBossJTA in JBossCache
by Jason T. Greene
Hi Everyone,
I am not sure if there has been a discussion on this before, but What do
you guys think about replacing the DummyTransactionManager with
JBoss(Arjuna)JTA? Perhaps it makes sense to leave it as a mock test, but
I was thinking it might be a good idea to offer everyone an integrated
solid TM out of the box.
Thoughts?
-Jason
16 years
I want to contribute
by Rosa Yáñez
Hello,
My name is Rosa Yáñez, I'm suscribed to the list since some months ago and
I'm eager in getting involved in this project. After reading the
documentation and working I little on my own, I want to contribute to this
project. I would be very grateful if you give me some guidances. I was
thinking about spanish doc translation as starting point. Could it be
useful?
Best Regards.
16 years
POJO Cache Jira separated from JBoss Cache
by Jason T. Greene
Everyone,
I have cleaned up all outstanding POJO Cache related issues, and moved
the remaining issues to a separate POJO Cache project:
http://jira.jboss.org/jira/browse/PCACHE
All issues resolved in releases that have already been released (2.0.0 &
<= 1.4.1SP4) will remain in the JBoss Cache jira project so that the
release notes are not changed. All future issues should be targeted to
the PCACHE release.
-Jason
16 years
cacheloader migration examples
by Galder Zamarreno
Hi,
I think I have fixed the issues in the cacheloader-migration project. I
just need to commit them. Before doing that, some questions:
1.- Is there any way to create the ZIP distribution that we created when
JBossCache 2.0.GA was released? The build scripts I created to run the
cache loader migration examples relied on the distro ZIP structure to
run, so I'd like to build that ZIP to test the examples.
2.- Alternatively, and I guess this is where we're trying to get to,
should I be converting this build scripts to Maven scripts and so they
should run independent to the location of libraries...etc? This leads me
to think that I need to be building a snapshot of cacheloader-migration
and uploading it (as Manik suggested couple of weeks back).
Jason, IIRC, PojoCache had some examples relying on build scripts, what
are you doing about them?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
16 years
JBCACHE-991 - batching calls without the use of a JTA Transaction Manager
by Manik Surtani
Mainly pertains to Brian since he requested it, but any opinions on
how critical JBCACHE-991 is for AS 5?
This is the ability to batch calls without the use of a JTA TM. We
had some discussions on this subject some while back but didn't
finalise on a solution.
I'd like to push this to 2.2 so we have time to hash out a proper
solution.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
16 years
Different types of flush WAS: [jgroups-dev] Start flush timeout with MuxChannel connect
by Brian Stansberry
The discussion on a javagroups-development thread made me realize that
for sure JBC wants to take advantage of the 2.6 connect+statetransfer
feature.
The JBCACHE-315 solution is only really applicable to a FLUSH associated
with a state transfer. That's when the cache needs to ensure the state
it transfer doesn't have any changes in it from uncommitted
transactions. Since the JBCACHE-315 fix is potentially disruptive to
transactions, we want to use it as judiciously as possible. Combining
connect+statetransfer is a good step in that direction.
Beyond that:
1) A block() call associated with a simple connect. JBC has no need to
deal with ongoing transactions; just prevent messages going out.
2) A block() call associated with a state transfer request for a
different state-id. For example, two different caches sharing a
multiplexed channel; cacheA gets a block call when a new instance of
cacheB deploys somewhere. Again, cacheA has no need to deal with ongoing
transactions since it won't be transferring staet; just prevent messages
going out.
Problem is JBC has no idea what the context is when its block() callback
is invoked.
Brian Stansberry wrote:
> AIUI, it's the time for all the services' block() impls to return, plus
> all the other work FLUSH does sending messages around.
>
> It's the JBC block() impl that is going to take time. JBCACHE-315 means
> JBC block() analyzing transactions that have written to the cache state,
> giving them a chance to clear, rolling back those that don't etc. Takes
> time.
>
> Vladimir Blagojevic wrote:
>> Hey Brian,
>>
>> This is a different timeout. It gives flush time window of 3 seconds to
>> quiet the cluster i.e to complete a first phase of flush. It does not
>> mean that the cluster will be quiet for 3 seconds. The timeout you are
>> thinking about is the one in configuration file.
>>
>> Cheers,
>> Vladimir
>>
>> Brian Stansberry wrote:
>>> Looking at org.jgroups.JChannelFactory.connect it's calling startFlush
>>> on the MuxChannel with a hardcoded timeout of 3 secs for the flush to
>>> complete. I think such a short timeout will for sure be a problem on
>>> production systems when nodes join active clusters. E.g. a good
>>> solution to http://jira.jboss.com/jira/browse/JBCACHE-315 likely
>>> requires spending some time to allow active transactions to clear.
>>>
>>>
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
16 years
Paring down the roadmap for "Alegrias" 2.1.0
by Manik Surtani
Guys,
Given the deadlines for getting 2.1.0 into AS 5's Beta3, I propose we
drop the MC/AOP integration from this release. This particularly
bugs me, since I really want to lose a lot of the boiler plate code,
but being pragmatic, it is too big a change to be done right in such
a short time frame. So, I propose a leaner 2.1.0 release, dropping
not only the MC/AOP integration but also the following JIRAs
JBCACHE-89
JBCACHE-207
JBCACHE-1082
JBCACHE-789
JBCACHE-331
JBCACHE-931
Hopefully we can release 2.1.0 by the end of Oct and then focus on a
2.2.0 release with all the remaining bits of 2.1.0, including MC/AOP
integration, for Jan or Feb and then push for a 3.0.0 with MVCC after
that.
What are your thoughts? From a JBoss AS integration perspective, my
understanding is that as long as the release is API compatible with
2.1.0 we should be able to slip it in to future versions of AS 5.
(Correct me if I am wrong, Brian)
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
16 years
Hudson and continuous integration
by Manik Surtani
We're getting somewhere with Hudson.
See http://jira.jboss.com/jira/browse/JBQA-969 for details, but in a
nutshell it is now set up for JBoss Cache - both core and pojo, with
JDK 5 and JDK 6.
Working on getting it running for the legacy branch 1.4.x as well,
since this is used in AS 4.x.
Also working on getting this *publicly accessible!!* Currently only
available if you use the RHT VPN client.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
16 years
Maven TestNG rewrite complete for JBoss Cache and POJO Cache
by Jason T. Greene
Hello Everyone,
All 2516 JBoss Cache and POJO Cache tests have been ported from JUnit to
TestNG. Since this involved some significant changes I took the
opportunity to remove all compiler warnings, which notably reduces the
warning noise. I have introduced primary test groups (explained below)
and have assigned the relevant tests.
I also have refactored the maven build to handle what I refer to as
permutations. Essentially it allows us to rerun subsections of tests
using different configurations. This will allow us to test things like
different jgroups protocol stacks using the same (but relevant) tests.
There is one small outstanding issue, which is the unreliable and buggy
nature of system output redirection (one of the many maven surefire
bugs). So currently when you execute a testrun all sys out will go to
your terminal.
Finally, I have written a detailed overview of the maven + testng
testing mechanics, and have included it in the project README:
http://anonsvn.jboss.org/repos/jbosscache/core/trunk/README-Maven.txt
I have also attached the additional overview section below.
Thanks,
-Jason
Testing
=======
Tests are written against the TestNG testing framework. Each test should
belong to one or more group. The group acts as a filter, and is used to
select which tests are ran as part of the maven test lifecycle. There
are 3 groups that are currently in use, but there is not formal, you can
make up any group name if you like.
Current Groups
--------------
* functional - Tests which test the general functionality of JBoss Cache
* jgroups - Tests which need to send data on a JGroups Channel
* transaction - Tests which use a transaction manager
It should be noted that every test should at least be in the functional
group, since this is the default test group that is executed by maven,
and the one that is required to prepare a release.
Executing the default test run
------------------------------
The default run executes all tests in the functional group. To just run
the tests with txt and xml output the command is:
mvn test
Alternatively, you can execute the tests AND generate a report with:
mvn surefire-report:report
If you already have ran a test cycle, and you want to generate a report
off the current reports, then you use the report-only goal, ike so:
mvn surefire-report:report-only
Executing different groups
--------------------------
A group can be executed (using the default configuration) by simply
using the groups property like so:
mvn -Dgroups=jgroups surefire-report:report
Mutiple groups can also be executed, although if a test is in more than
of the selected groups, it is executed only once:
mvn -Dgroups=jgroups,transaction surefire-report:report
Executing a single test
-----------------------
A single test can be executed using the test property. The value is the
short name (not the fully qualified package name) of the test.
mvn -Dtest=FqnTest
Skipping the test run
---------------------
It is sometimes desirable to install the jboss cache package in your
local repository without performing a full test run. To do this, simply
use the maven.test.skip.exec property:
mvn -Dmaven.test.skip.exec=true install
Again, this is just a shortcut for local use. It SHOULD NEVER BE USED
when releasing. Also, make sure "exec" is included in the property, if
not the tests will not be built, which will prevent a test jar being
produced (POJO Cache needs the Core Cache test jar).
Permutations
------------
We use the term permutation to describe a group execution against a
particular config. This allows us to test a variety of environments and
configurations without rewriting the same basic test over and over
again. For example, the jgroups-tcp permutation executes the jgroups
group using the TCP config. Each permutation requires a maven profile
which defines the various options, environmental variables, etc. The
command to run the jgroups-tcp permutatin is:
mvn -Pjgroups-tcp surefire-report:report
Each permutation uses its own report directory, and its own html output
file name. This allows you to execute multiple permutations without
wiping the results from the previous run. Note that due to the way maven
operates, only one permutation can be executed per mvn command. So
automating multiple runs requires shell scripting, or some other
execution framework to make multiple called to maven.
16 years
