Feedback on Infinispan patch
by Emmanuel Bernard
Hey Lukasz,
Your patch looks quite good and pass tests on my side.
I encourage others to check out the patch before we apply it (ideally
another person form HSearch and one person from infinispan.
Lukasz, I have a few questions/remarks though before applying it. Can
you answer / adjust the patch?
IndexWriterSetting
Why move to return Object in parsing from the initial int?
Move DPHelper#createInfinispanCacheManager to IDP
this is not something that can be shared as it creates a hard
dependency on infinispan otherwise.
in createInfinispanCacheManager
Don't log in error the fact that xml is not used if a default config
is used. Just log in trace at best.
Rename InfinispanCacheManagerConfigurationImpl to
DefaultInfinispanCacheManagerConfiguration or even better with a name
describing nicely the behavior of the infinispan config.
in InfinispanIndexOutput, is it possible to get writeBytes bigger than
buffer size? If yes, does newCheck creates the appropriate numbers of
chunks?
InfinispanDirectoryProvider
put the configuration proeprties available in the
InfinispanDirectoryProvider javadoc.
I think the default cache name should be "Hibernate Search" instead of
"HSInfinispanCache". We know it's in infinispan :)
what's the try catch opening and closing an IW about? It looks weird.
in stop()
you don't close the CacheManager? How is that?
InfinispanCacheManagerConfigurationImpl
What does "Infinispan-Cluster" correspond to? Why this name? Shouldn't
it be "Hibernate Search cluster"?
Is it safe to override the GlobalConfiguration? What if JBoss AS use
infinispan to run?
Why the use of DummyTransactionManagerLookup. Doesn't Infinispan guess
the right TM depending on the environment? e in JBoss As use the JBoss
one etc? I think GenericTransactionManagerLookup does that.
InfinispanCacheManagerConfiguration
some javadoc on the methods would be useful. I don't know what do
implement here.
Is there a better name for Metadata? Like FileMetadata maybe?
Where is ispn-cache-default-conf.xml used? For tests only? If not: is
it possible to use a programmatic version instead and what is "It's a
movie cache"?
Emmanuel
Begin forwarded message:
> From: Łukasz Moreń <lukasz.moren(a)gmail.com>
> Date: 21 août 2009 02:11:03 HAEC
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Subject: GSoC patch with Infinispan Directory Provider
>
> I'm sending patch and piece of documentation - not much but
> necessary information are included.
> There are some todos but I didn't manage to finish it yet.
> I changed maven jgroups dependency to 2.8.beta2, before version was
> clashed with used by infinispan.
> In pom file there was dependency on hibernate common annotations
> 3.2.shapshot. It should't be 3.5?
>
> Cheers,
> Lukasz
17 years
Query module new API and configurations
by Navin Surtani
Hey guys,
Was speaking with Manik the other day and we were just talking about
how we could work in some of the new API into the query module.
What I was thinking to do was something like this: -
CacheQuery cq = new QueryFactory(cache).getQuery("fieldName",
"stuffToSearchFor");
This way, internally we can do all the dirty work of creating lucene
queries, using a query parser etc etc. Which is a major clean-up from
the old JBCS API where you'd need to create it yourself.
The other issue we discussed was setting up searchable configurations.
Vladimir, I believe you're the guy who can help us a bit on this?
Essentially, what Manik suggested was to put in a configuration option
(eg: - 'searchable = true') and then from there internal cache code
should know how to deal with adding in the SearchableInterceptor.
Maybe an XML parser does this? Feel free to throw something at me if
I'm wrong here.
The slightly complex part here is that the Searchable Interceptor sits
in the query module. So if you're only using the core module it also
needs to be able to ignore the query configuration if it doesn't have
the dependency or if the user doesn't want to use the module etc etc.
WDYT?
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
17 years
Benchmarking 2nd level cache providers?
by Galder Zamarreno
While talking to Manik online, the topic of 2nd level cache benchmarking
came up and was wondering if there's a way to benchmark different 2nd
level cache providers in Hibernate?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
Re: [infinispan-dev] [hibernate-dev] Hibernate 3.5.0.Beta-1 released
by Galder Zamarreno
Bugger, this was released hours before I committed the Infinispan cache
provider :(
Steve, let's catch up before next 3.5 release in order to figure out
what's needed to make Infinispan the default cache provider. Do you make
such decision based on any performance test or the configuration itself?
My aim is to make Infinispan the best 2nd level cache provider out there.
On 08/21/2009 06:43 PM, Steve Ebersole wrote:
> Hibernate 3.5.0.Beta-1 has been released. Please see
> http://in.relation.to/12153.lace for details.
>
--
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, 1 month
Infinispan REST server
by Michael Neale
Hey all.
(brief into: I am Mic, work for JBoss, on Drools and other things, I
got chatting to Manik one day and on a cold sunday morning started
hacking...)
I have been working on a RESTful server using RESTEasy as part of the
infinispan server effort. Its really quite easy to do, but I believe
useful for some cases I have in mind (involving non java clients)...
For the moment, while I play with things and then tidy up, I have
thrown the code up here:
http://github.com/michaelneale/Infinispan-rest/tree/master but plan to
put this in the infinispan tree when happy (it is a war, but we can
also have stand alone distros).
The basic cache operations map pretty nicely to HTTP verbs, GET, PUT,
DELETE (can wipe out an element or a whole cache) etc etc... with meta
info in the headers etc... (will be documenting it shortly, probably
on the wiki). For example, a http PUT to /foo/bar puts an element with
a key value of "foo" in the named cache "bar" (one cache manager
config per running server instance). Content-Type headers are needed
so the GET can operate correctly (also, this will probably be useful
down the track for indexing for search/queries, as the payload data
itself is a byte[] from the request body entity/stream).
I am also working on making it honour "eTags" - which are quite handy
(a GET with an eTag means it doesn't have to return the result if it's
copy is already good). This means you could, for instance, use
infinispan as a pretty dynamic content distribution network, pushing
out content updates as often as you like, but taking the load of the
servers (and network) where possible. Another option with persistence
is basically similar to the amazon s3 service (including per cache or
"bucket" ACLs, not hard to do)... many possibilities...
Some questions: I need to track things like "created" or "updated"
time etc.. things that the cache would track - but I can't work out
how to get at that data (so I can put it in the CacheEntry object, but
it seems redundant???) - ideas?
Also, if there a way to list the named caches in a cache manager?
(just thinking as an optional feature).
Anyway, love to hear ideas...
Michael.
17 years, 1 month
mvn improvements
by Mircea Markus
Hi,
Following some guidelines from "Mvn the definitive guide" I've
factorized common libraries parent pom.xml(log4j and xstrem) - this
will allow us to change the version identifier during upgrades in a
single place, rather than in several.
I also reduced dependency for each module: each module depends by
default by easymock, easymockextension and testng. All other 'shared'
artifacts were moved to dependecyManagent (from dependency).
Some unused dependencies (mvn dependecy:analyze) were removed.
Please let me know if you see any build issues.
And a question: what is the purpose of having a parent pom.xml and
<root>/pom.xml -> can't the <root>/pom.xml be the parent?
Cheers,
Mircea
17 years, 1 month
[ISPN-165] Adding visitPutForExternalReadCommand to Visitor interface?
by Galder Zamarreno
Hi,
Re: https://jira.jboss.org/jira/browse/ISPN-165
In JBC, this was fixed by having a overriding
visitPutForExternalReadCommand in InvalidationInterceptor and avoiding
going remote in its implementation.
In ISPN however, there does not appear to be a similar
visitPutForExternalReadCommand method, which forces you to check the
flags passed (Flag.FAIL_SILENTLY, Flag.FORCE_ASYNCHRONOUS,
Flag.ZERO_LOCK_ACQUISITION_TIMEOUT)
Now, not all calls to with these flags are related to
putForExternalRead, so I'd suggest adding a
visitPutForExternalReadCommand to the Visitor interface.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years, 1 month
