EJB3/Hibernate/JBoss Cache intergration broken in EJB3 trunk
by Brian Stansberry
Carlo,
FYI, there are a bunch of EJB3 clustered entity test failures in AS
trunk due to a bad interaction between Hibernate 3.2.4.SP1 and JBoss
Cache 2.0.0. Basically, this is a temporary mismatch between Hibernate
and JBC. There's work in Hibernate Core's trunk for the 3.3 release that
can let us resolve this, but for now the tests are going to fail.
Problem is the integration layer ends up calling the JBC
putForExternalRead() method when it needs to cache something in the
"UpdateTimestampsCache". JBC treats a calls to this method as a no-op
if the cache node in question already exists. This is new behavior in
JBC 2.0. It's the necessary and intended behavior when the method is
called for caching entities and collections. But when it's called for
the UpdateTimestampsCache, it causes problems. The Hibernate 3.3.
codebase gives us the flexibility to call a different method for the
UpdateTimestampsCache call; to fix the problem we need determine the
exact behavior we want for the UpdateTimestampsCache call and make the
appropriate call to JBC.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
17 years, 6 months
buddy replication test failures in 1.4.x
by Galder Zamarreno
Hi,
I have gone through some of the failures I'm getting when running the
test suite for 1.4.x:
* Some buddy replication tests show this test failures:
junit.framework.AssertionFailedError: buddy's list of groups it
participates in should contain data owner's group name at
org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:280)
Earlier in the test, you can see this Exception:
org.jboss.cache.buddyreplication.BuddyNotInitException: Not yet initialised
at
org.jboss.cache.buddyreplication.BuddyManager.handleAssignToBuddyGroup(BuddyManager.java:450)
at org.jboss.cache.TreeCache._remoteAssignToBuddyGroup(TreeCache.java:5372)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
This failure seems to be a related to a timing issue, when a node
requests another to join the buddy group but this node is still in the
initialisation process, BM.init(). More precisely, the code is
broadcasting buddy pool membership, and at that point a, request to
joing the buddy groups occurs.
The channel is connected before the buddy manager is initialised, so
there's always the possibility of receiving messages before buddy
manager has finished initialising.
Various solutions that come to my mind:
1.- staggering cache starts
2.- wait for a little bit before throwing BuddyNotInitException seeing
that the broadcasting task could be lengthy (i.e. one of the nodes fails
to respond as the call is synchronous), maybe wait for
buddyCommunicationTimeout?
IMO, 2 is preferred.
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years, 6 months