Configuration.getGlobalConfiguration
by Mircea Markus
Hi,
This is deprecated right now. I remember some discussions in past about marking it deprecated but right now I just can't see the reasons for the deprecation.
Any comments? Shall we remove @Deprecate?
Cheers,
Mircea
14 years, 4 months
ISPN-194 updating Hibernate Search dependecy on trunk
by Navin Surtani
Hey all,
Just wanted to make sure that it's okay for now to update the
Hibernate Search dependency to 3.3 Beta so that we can make use of the
changes to finalise the Query API. To be sure that we don't release
5.0 Betas or CR's beforehand shall I create a JIRA to update the HS
version to the Final when that release comes out?
Does this sound okay by you guys?
--
Navin Surtani
Intern Infinispan
14 years, 4 months
Re: [infinispan-dev] ISPN-194 updating Hibernate Search dependecy on trunk
by Sanne Grinovero
+1
no known regressions where found so far in the latest trunk. Be aware that
tomorrow a new beta will be released: you might want to use that one.
Il giorno 27/ott/2010 18:43, "Manik Surtani" <manik(a)jboss.org> ha scritto:
+1
On 27 Oct 2010, at 17:40, Navin Surtani wrote:
> Hey all,
>
> Just wanted to make sure that it's ...
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists...
14 years, 4 months
API changes with ISPN-180
by Mircea Markus
Hi,
ISPN-180 requires changes in ConsistentHash interface. This is a public interface in 4.x as its implementation is pluggable.
1. Is this something we want to do? I think we should doi it as a) the migration to new impl is relatively simple b) I don't think this is has a highly used feature
2. The interface I need for implementing ISPN-180 looks something like: http://www.pastie.org/1250789
Last three methods were added, and two methods were removed: getDistance and isAdjacent
How does this look to you?
Cheers,
Mircea
14 years, 4 months
rehashing hazard
by Mircea Markus
Hi,
ISPN-180 requires some significant code changes around re-hashing, so I've decided to make the rehashing-related test suite more stable before changing the code.
I've fixed some, but transactional rehash tests are still failing. Here is why:
{A,B,C, D}, num owners= 2. A's state is {(k,v)} and a transactions is prepared with {(k, otherValue)} on A.
B crashes.
two things happen with A's state:
1. on C an thread pulls state from A
2. A sends transaction state to C on another thread
Whit the right timing:
- 2 executes first (tx log is drained)
- tx commits - this applies the changes on C as well
- 1 executes last
Data ends up inconsistent:
A's states is {(k, otherValue)} while C's state is {(k,v)}
State transfer and tx log needs to be sequential (not parallel). The easy way to achieve this is to only do push, i.e. A sends the state and then drains tx log.
This can be reproduce by running ConcurrentNonOverlappingLeaveTest.testTransactional (fails aprox 1/5)
Cheers,
Mircea
14 years, 4 months
Merged and MergeEvent in 4.2
by Vladimir Blagojevic
Hey,
I wanted to re-enable and implement some additional partition merge tests when I noticed, what seems, some unfinished work in merge event notification. I see that Manik added Merged annotation and MergeEvent in 4.2 which are similar to ViewChanged annotation and ViewChangedEvent except that they are exclusively used for merge view notifications. Anyway, JGroups MergeView is detected in JGroupsTransport, listeners are invoked except that Merge notification is not allowed to propagate in CacheManagerNotifierImpl! In addition to this DistributionManagerImpl does not register listener for Merge event notification!
Does anyone know what is going on here? Why is this mechanism left unfinished?
Regards,
Vladimir
--
Vladimir Blagojevic
JBoss Clustering Team
JBoss, by Red Hat
14 years, 4 months
Global components per CacheManager
by Vladimir Blagojevic
User on a forum complained seeing eviction thread per created cache [1]. Although global configuration settings are shared amongst all caches created in CacheManager each created cache gets a fresh copy of these global elements?! Each created cache therefore indeed gets a new eviction executor service with one running thread. Does that mean that by default we also create one async transport executor per cache with 25 threads spinning?
If so, we should tell users that running more than two dozen caches per CacheManager is going to impact the system significantly.
[1] http://community.jboss.org/thread/157913
--
Vladimir Blagojevic
JBoss Clustering Team
JBoss, by Red Hat
14 years, 4 months
4.2.ALPHA4 contains errors in schema
by Sanne Grinovero
Hello all,
I was successfully using 4.2.0-SNAPSHOT before the ALPHA4, and I'm
also successful in using it just after the release,
but if I try pinning the version to 4.2.0-ALPHA4 my builds fail with
"Caused by: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2:
Attribute 'strictPeerToPeer' is not allowed to appear in element
'transport'."
Indeed the schema included in the release doesn't include the new
"strictPeerToPeer" attribute, but lists it in the sequence, as the
properties (see below).
Strange thing is that versions I tested just before the release where
fine, and the schema I get when building it now from 4.2 branch are
also correct.
4.2.0-ALPHA4 contains:
<xs:complexType name="transportType">
<xs:complexContent>
<xs:extension base="tns:abstractConfigurationBeanWithGCR">
<xs:sequence>
<xs:element name="properties" type="tns:propertiesType"
minOccurs="0"/>
<xs:element name="strictPeerToPeer" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="clusterName" type="xs:string"/>
<xs:attribute name="distributedSyncTimeout" type="xs:long"/>
<xs:attribute name="nodeName" type="xs:string"/>
<xs:attribute name="transportClass" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
4.2.0-SNAPSHOT (correct):
<xs:complexType name="transportType">
<xs:complexContent>
<xs:extension base="tns:abstractConfigurationBeanWithGCR">
<xs:sequence>
<xs:element name="properties" type="tns:propertiesType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="clusterName" type="xs:string"/>
<xs:attribute name="distributedSyncTimeout" type="xs:long"/>
<xs:attribute name="nodeName" type="xs:string"/>
<xs:attribute name="strictPeerToPeer" type="xs:boolean"/>
<xs:attribute name="transportClass" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
any idea of how this could happen?
Having this schema makes Alpha4 unusable for me.
Cheers,
Sanne
14 years, 4 months
4.2.ALPHA4
by Mircea Markus
Hi there,
I'm thinking to cut alpha 4 at 1630 BST. This ships with jgroups 2.10.1.GA.
Cheers,
Mircea
14 years, 4 months
