Hash calculation in DefaultConsistentHash
by Krzysztof Sobolewski
I took a look at the implementation of DefaultConsistentHash and I was
wondering: does the key hash value have to be positive? As in:
int hash = Math.abs(key.hashCode());
I can see that the resulting hash is used to pull a tail map of the hash
space, but there's no reason the SortedMap key has to be positive. I'm
actually most concerned about the fact that Math.abs(Integer.MIN_VALUE) ==
Integer.MIN_VALUE so you have at least one negative key anyway :)
-KS
17 years
Should CacheManagerJmxRegistration.start() be associated with CacheManager.start() ?
by Galder Zamarreno
Hi,
While looking https://jira.jboss.org/jira/browse/ISPN-118, I've noticed
that CacheManagerJmxRegistration.start() only gets called when the 1st
cache is started, not when the CacheManager is started.
Wouldn't it make more sense (for correctness more than anything else),
that CacheManagerJmxRegistration was not registered as a component and
instead from DCM.start(), CacheManagerJmxRegistration.init() and
CacheManagerJmxRegistration.start() being called and from DCM.stop(),
CacheManagerJmxRegistration.stop()
Would you forsee any problems in doing this?
Cheers
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
Re: [infinispan-dev] [hibernate-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
by Sanne Grinovero
Sure I like it! I'm in the swamp of old mails, so I give you my first
impression only:
Even if it's fluent it's not (yet) intuitive to me which methods I should call;
Query luceneQuery =
qb.must(Occurs.MUST)
.add(
qb.boolean(Occurs.Should)
.add( qb.term("city", "Atlanta").boostedTo(4).createQuery() )
.add( qb.term("address1", "Peachtree").fuzzy().createQuery() )
)
.add(
qb.from("movingDate", "200604").to("201201").exclusive().createQuery()
)
.createQuery();
I guess there is a typo? As "must(MUST)" is a bit confusing to me.
why not
qb.booleanQuery()
.Must( qb.otherQuery(...).. )
.Should( qb.secondQuery(..).. )
.build();
and
qb.termQuery("city", "Atlanta").boostedTo(4).createQuery())
or even overloading
qb.termQuery("city", "Atlanta").createQuery())
with
qb.termQuery("city", "Atlanta", 4f).createQuery())
is not as readable as "boostedTo" method but more immediate;
intelligent IDEs should propose the options to devs while typing, even
guessing the parameter name and making it's meaning self-evident.
qb.rangeQuery could be either
rangeQuery("field", "fromX", "toY")
or
rangeQuery("field").from("x").to("y")
so why are you choosing ("field","from").to("to") ?
Thinking about the RangeQuery on dates, it would be cool to accept any
type for which we have Bridges, like accepting Date type or even a
user-defined FieldBridge together with an Object.
I like the Analyzer choices, it would be very cool if we could by
default guess the correct one from the searched-for entity types.
We could even consider a Query-By-Example query builder, reading
indexed fields from an instance of an indexed type, or something like
HSEARCH-119 proposal (for termvectors similatory).
cheers,
Sanne
2009/8/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> Hey Sanne,
> What do you think of the PAI proposal itself?
> Like it? See improvements?
>
> On 28 août 09, at 10:37, Sanne Grinovero wrote:
>
>> I've nothing against a separate maven module, still Hibernate Search
>> already has lots of "goodies" to work with Lucene which are not
>> necessarily linked to Hibernate (e.g. Analyzer definition helpers,
>> pojo mapping through annotations, enhanced filtering, IndexReader
>> pooling, nice Infinispan Directory...) so this new query builder is
>> not much different. Just a thought.
>>
>> So even if Emmanuel has shown this builder to be useful even with this
>> limited features, it could become even more useful when strongly
>> combined with the other features; 2 come to mind, may be more later:
>>
>> A) adding filters to the builders; I don't think it would be easy to
>> have named filters without the full Search package
>>
>> B) Letting the users forget about the Analyzer matches complexity
>> (optionally), as by using the mapping information we could default to
>> a reasonable Analyzer for each field. Most users on the forum are in
>> trouble because they select the wrong analyzer/ forget to use one when
>> building the F.T.Query.
>>
>> IMHO these are good reasons to couple it to the rest of the code;
>> Maybe it would be possible in future to have Hibernate optional.
>>
>> Sanne
>>
>>
>> 2009/8/27 Manik Surtani <manik(a)jboss.org>:
>>>
>>> On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote:
>>>
>>>
>>> queryBuilder.withAnalyzer(Analyzer)
>>> queryBuilder.withEntityAnalyzer(Class<?>)
>>> queryBuilder.basedOnEntityAnalyzer(Class<?>)
>>> .overridesForField(String field, Analyzer)
>>> .overridesForField(String field, Analyzer)
>>> .build() //sucky name
>>>
>>> Perhaps rename the static factory methods to something like:
>>> QueryBuilder.getQueryBuilder(Analyzer)
>>> QueryBuilder.getQueryBuilder(Class<?>)
>>> and QueryBuilder instances have overrideAnalyzerForField(String,
>>> Analyzer).
>>> Why do you need the build() method at the end?
>>>
>>> if you do that, all of the sudden, a QB can change it's analyzer on the
>>> fly
>>> making it immutable.
>>> Also the overridesForField methods would pollute the API when it's time
>>> to
>>> create a query.
>>> One of the advantages of a fluent API in a strongly typed environment is
>>> that we can hide methods that are meaningless in a given context.
>>>
>>> That been said, if the API ends up being pure Lucene and once we
>>> stabilize
>>> it, we can contribute it back even though I am not necessarily a huge fan
>>> of
>>> ASL.
>>>
>>> Not it doesn't have to be either ASL or even hosted at Apache. I guess
>>> what
>>> I am suggesting is perhaps even a separate project - LuceneQueryBuilder
>>> or
>>> something - which plain-old-Lucene users could use as well. Doesn't
>>> matter
>>> where it's hosted or what the license is - as long as its ASL or LGPL :)
>>>
>>> Let's start it under the Hibernate Search umbrella due to potential
>>> synergies and spin it out if needed.
>>>
>>> Ok. Just make sure we use a different maven module or something so that
>>> there are no dependencies on the rest of HS or Hibernate. Otherwise
>>> spinning out will be a PITA. Lucene should be the only dependencies of
>>> this
>>> code.
>>> Cheers
>>> --
>>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>
>
17 years
Should we baseline on Java6?
by Manik Surtani
Thoughts?
The benefits are faster classloading and no more dependency on JAXB
jars.
Given that Java5 will soon be unsupported by Sun, is this a good
move? Or would we be alienating folks who are still baselined on Java5?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
Infinispan QueryFactory API and lazy class addition into lucene
by Navin Surtani
Hello guys,
Was talking with Galder on Friday about how we were to implement the
new QueryFactory API into Infinispan. A main issue was how we could
pass the classes to Hibernate Search. It's currently done in the
SearchableCacheFactory upon creation of the SearchableCache.
We were wondering if it's possible to give the classes to Hibernate
Search lazily? So for example, is there a way to give the class to a
SearchFactoryImplementor when that type is added into the Cache for
the first time?
Also - if it's not possible, is there a feasible way for us to build
this into Hibernate Search? Maybe just create a new instance of the
SearchFactoryImplementor (assuming this won't throw away a lot of the
data required for lucene etc)?
Danke,
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
17 years
Infinispan smoke tests?
by Galder Zamarreno
Hi,
Due to the complexity of tests that have been added to the Infinispan
test suite, the time it takes to run the testsuite has almost doubled.
These tests (i.e. distribution rehashing, non-blocking state transfer)
need to be run, that's for sure.
However, I was thinking whether we could create a brand new group of
tests called "smoke". The aim here is for the tests in that group to run
lightning fast and cover 90% of the testsuite.
I think this would help find most of the regressions that are sometimes
introduced for not running the testsuite locally.
Once hudson issues have been solved, we'll be in a better situation but
I still think having this 'smoke' group could help avoid regressions.
Obviously, the danger here is people always running this profile and
then discovering loads of test fails when the entire testsuite is run
but we have this issue now too.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
[hibernate-dev][HibernateSearch] Infinispan programmatic configuration
by Łukasz Moreń
I am thinking how to provide programmatic configuration into Hibernate
Search for many caches, i.e. if user wants to use different configured
caches for each index.With XML it is ok, in one file can be configured many
named caches. So far in programmatic version user have to implement method
that returns Configuration object - only one configuration can be provided
that way.
To achieve this same what in XML case, method should return something like:
List<{cacheName}, {configuration}>. It is quite painfull, but on the other
hand just extra feature. Some other ideas?
Cheers,
Lukasz Moren
17 years
[ISPN-176] CommandAwareRpcDispatcher.handle() should wrap throwable into ExceptionResponse
by Galder Zamarreno
Hi,
While working on the Hibernate cache provider classloader tests, I've
come across https://jira.jboss.org/jira/browse/ISPN-176
IMO, the fix for this involves making CommandAwareRpcDispatcher.handle()
return an ExceptionResponse with the throwable thrown. This would
require enhancing ExceptionResponse to deal with throwables rather than
Exceptions.
Note that JGroupsTransport.invokeRemotely currently expects a Response
instance as a return rather than a Exception directly.
Does anyone think different?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
writeUnsignedInt() inefficient with bytes between 128 and 255
by Galder Zamarreno
Hi,
While looking at https://jira.jboss.org/jira/browse/ISPN-149, I've
realised that writeUnsignedInt(), due to its dynamic behaivour, it's
more efficient than using a leading byte and then writing a byte, short
or int.
However, I've spotted an unefficiency in
UnsignedNumeric.writeUnsignedInt() which is that if you write a byte
that's between 128-255, it writes two bytes, whereas in theory, you
could just write it as a single unsigned byte.
Now, I'm not an expert on these methods, but I believe a
writeUnsignedInt like this would make 128-255 bytes be written as 1 byte
too:
public static void writeUnsignedInt(ObjectOutput out, int i) throws
IOException {
while ((i & ~0xFF) != 0) {
out.writeByte((byte) ((i & 0xFF) | 0x100));
i >>>= 8;
}
out.writeByte((byte) i);
}
And the read part would look like:
public static int readUnsignedInt(ObjectInput in) throws IOException {
int b = in.readUnsignedByte();
int i = b & 0xFF;
for (int shift = 8; (b & 0x100) != 0; shift += 8) {
b = in.readUnsignedByte();
i |= (b & 0xFFL) << shift;
}
return i;
}
Manik, I think you created these methods in the 1st place, thoughts?
CC'ing David M L who's quite an expert on this too.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
