Freeze on docs in trunk
by Manik Surtani
Guys,
Please don't make any changes to the docs in trunk - Samson is having
a look at changing this structure to suit his i18n processes.
Cheers
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
17 years, 10 months
Testing JBC with the AS profile
by Brian Stansberry
FYI, I got testing JBC core built with the JBossAS dependency set
working on hudson:
http://hudson.qa.jboss.com/hudson/job/jboss-cache-core-2.2.X-jbossas/
It's manually triggered.
A run w/ the latest dependencies configured shows one failure that I
can't imagine is related to the different dependency set:
http://hudson.qa.jboss.com/hudson/job/jboss-cache-core-2.2.X-jbossas/org....
Also, the main dependency set in 2.2.0.CR6 shows this test dependency on
a beta:
<dependency>
<groupId>org.jboss.transaction</groupId>
<artifactId>jboss-jta</artifactId>
<version>4.3.0.BETA2</version>
<scope>test</scope>
</dependency>
The 4.3.0.GA is out, so that can be updated. But, it seems where
JBossTS is published in maven has changed. I used this in the JBossAS
profile:
<dependency>
<groupId>jboss.jbossts</groupId>
<artifactId>jbossjta</artifactId>
<version>4.3.0.GA</version>
<scope>test</scope>
</dependency>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
17 years, 10 months
Parallelizing TestNG tests
by Manik Surtani
Vladimir/Bela,
Could you guys talk briefly on how you implemented parallelizing your
TestNG tests, making use of dynamically changing channel ports to
allow clustered tests to run concurrently? Is any of this reusable?
I've created a JIRA for JBC [1] to make use of this if possible. 2+
hrs for our test suite is hugely annoying. :-)
Thanks
Manik
[1] http://jira.jboss.org/jira/browse/JBCACHE-1386
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
17 years, 10 months
Locking parents for insertion and removal with MVCC
by Manik Surtani
In the past, parent nodes were not (write) locked when child nodes
were added or removed.
With PL, we simply got a read lock on a parent and edited the child
map. This allowed for phantom reads (and TBH wasn't really R_R either).
With OL, we didn't increment parent versioning when children were
added or removed, but attempted to merge child maps.
For both of the above, we introduced a LockParentForChildInsertRemove
system-wide config property (which defaulted to false). If true, a WL
was acquired on parents (PL) or parent versioning was incremented and
validated (OL) when adding/removing children.
Now with MVCC - since there are no read locks - we have a problem.
Consider:
1. Tx begns.
2. Tx reads /a (no locks)
3. Tx removes /a/b (locks /a/b)
4. Tx counts children of /a (will still see that /a/b is in /a's
child map).
he approaches I have considered are:
1. Removing /a/b from /a's child map.
This will provide a consistent view to the tx removing /a/b but will
mean that other txs will also see /a/b disappear when counting /a's
children, but not when querying the cache for /a/b! Worse, rollbacks
would mean re-adding /a/b to /a's child map, providing weird views on
other readers (/a/b disappears for a while, then reappears)
2. Make a copy of /a for the tx to work off, when removing /a/b.
This is the same as having LockParentForChildInsertRemove semantics.
Copy the parent as well and work off it, but to prevent problems with
concurrent child removes and adds, we'd have to lock the parent.
My vote is for approach 2. In fact, LockParentForChildInsertRemove
would always need to be enabled when using MVCC. Perhaps this should
be a deprecated property that just supports additional consistency for
OL and PL, and be removed when OL/PL eventually get removed?
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
17 years, 10 months
Re: Any reason not to use ExposedByteArrayOutputStream instead of ByteArrayOutputStream ?
by Manik Surtani
cc'ing JBC-dev.
The stream looks good, except that getting the raw buffer would mean
that the buffer returned would "almost certainly be longer than the
data written to it" (quoted from Brian's excellent javadocs). Bela,
how would JGroups behave with this? Would it attempt to stream the
entire buffer, including uninitialized values?
Will need to see how this gets de-serialized as well. Also, since all
cacheloaders use the same marshaller, will need to see how they deal
with this as well. Any code that relies on buf.length may end up at
best writing unnecessary data and at worst breaking when deserializing.
Cheers
Manik
On 3 Jul 2008, at 20:37, Bela Ban wrote:
> Good ! I see that our friend Brian added code to EBAOS to double the
> byte array and - after a certain limit - grow only linearly. Good
> thing, this should help keep memory consumption down even more
>
> Manik Surtani wrote:
>> Yes, good point - will investigate.
>>
>> On 3 Jul 2008, at 16:59, Bela Ban wrote:
>>
>>> At least in AbstractMarshaller:
>>> public byte[] objectToByteBuffer(Object obj) throws Exception
>>> {
>>> ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>> ObjectOutputStream out =
>>> ObjectSerializationFactory.createObjectOutputStream(baos);
>>> objectToObjectStream(obj, out);
>>> out.close();
>>> return baos.toByteArray();
>>> }
>>>
>>> Here, an ExposedByteArrayOutputStream instead of a BAOS would
>>> prevent the COPY of the byte buffer. We also don't need to be
>>> concerned about reentrancy as the output streams are local (stack)
>>> variables...
>>>
>>> Maybe you guys should take a look at all occurrences of BAOS !
>>>
>>> --
>>> Bela Ban
>>> Lead JGroups / JBoss Clustering team
>>> JBoss - a division of Red Hat
>>>
>>
>> --
>> Manik Surtani
>> Lead, JBoss Cache
>> manik(a)jboss.org
>>
>>
>>
>>
>>
>>
>
> --
> Bela Ban
> Lead JGroups / JBoss Clustering team
> JBoss - a division of Red Hat
>
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
17 years, 10 months
2.2.0.CR6
by Manik Surtani
Just tagged and cut this, being uploaded to the maven2 repo as we speak.
Brian, this contains the fixes you need for AS 5.
Jason, this contains the JBossCacheView extension point for the POJO
Cache demo GUI.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
17 years, 10 months