Infinispan offers several persistance stores to persist content of cache,
i.e. based on file system, database, S3 amazon service. Is there some
recommendation which one should be used as a default for Hibernate Search
directory provider based on Infinispan cache?
What about cache loaders configurat
It's already committed I've done it right before leaving
On 14 août 2009, at 15:37, Steve Ebersole wrote:
> FYI, Emmanuel asked to slip a few things in to this beta, so this will
> now occur sometime Monday or before.
>
> On Thu, 2009-08-13 at 14:23 -0500, Steve Ebersole wrote:
>> Heads up that
FYI, Emmanuel asked to slip a few things in to this beta, so this will
now occur sometime Monday or before.
On Thu, 2009-08-13 at 14:23 -0500, Steve Ebersole wrote:
> Heads up that I will be doing the first beta release for 3.5 tomorrow.
> In support of that I will also be cutting a beta release o
I think so.
But ideally I would like:
- to add the property to set the mergerscheduler and expose that
- automatically force the setting if the IW is used by Infinispan
(not sure how easy that is).
On 14 août 09, at 13:35, Łukasz Moreń wrote:
Yes, using SerialMergeScheduler helped. Thanks!
Yes, using SerialMergeScheduler helped. Thanks! Restriction on merge
scheduler should be set in IndexWriterSetting enum, similarly to i.e.
max_buffered_delete_terms or max_buffered_docs properties?
2009/8/14 Emmanuel Bernard
> OK so let's try something.Lukasz, can you try and use
> the SerialMer
Yes let's keep it simple for know, even if I think Manik's suggestion
should work: if the IndexWriter will do reads it can use a
"Future-like" pattern to make the other thread return values
maintaining order of transformations applied to the index).
The IndexWriter must be able to maintain a cohere
I'm still of the idea that "one day" (read: low priority) it would be
nice to have the possibility do configure DirectoryProviders and
backends indipendet per index.
I don't want to put pressure on that, but it might be useful to leave
that option open for the future.
2009/8/14 Emmanuel Bernard :
Well DPs are per index already. Backends, not yet :)
On 14 août 09, at 12:55, Sanne Grinovero wrote:
> I'm still of the idea that "one day" (read: low priority) it would be
> nice to have the possibility do configure DirectoryProviders and
> backends indipendet per index.
> I don't want to put pr
OK so let's try something.
Lukasz, can you try and use the SerialMergeScheduler policy on the
index writer and see what is going on.
It will make indexing slower for Infinispan but it seems we can't do
much better in the short time.
If that works then we will put some restriction in place wh
On 14 août 09, at 06:32, Manik Surtani wrote:
On 14 Aug 2009, at 11:23, Łukasz Moreń wrote:
Expensive is replication to all Infinispan nodes. IndexWriter
creates segment files, merge it to one compound segment, delete
already useless descriptor files - many files that must be
replicated
How do you share the cache between different directories?
A static field would not work well as it would prevent HSearch to be
started twice in a single app.
Anyway if we share the cache, I would still like to use the per
directory provider configuration strategy (from a config property
po
On 08/14/2009 03:26 PM, Brian Stansberry wrote:
> On 08/13/2009 06:27 AM, Galder Zamarreno wrote:
>> Hi Brian,
>>
>> Of my original email, there's a section that I don't think has been
>> answered yet
>>
>> On 08/04/2009 10:37 AM, Galder Zamarreno wrote:
>>> Finally, a question to the list, speci
On 08/13/2009 06:27 AM, Galder Zamarreno wrote:
> Hi Brian,
>
> Of my original email, there's a section that I don't think has been
> answered yet
>
> On 08/04/2009 10:37 AM, Galder Zamarreno wrote:
>> Finally, a question to the list, specially for Brian/Steve who worked on
>> the JBC2/3 integratio
On 14 Aug 2009, at 11:23, Łukasz Moreń wrote:
Expensive is replication to all Infinispan nodes. IndexWriter
creates segment files, merge it to one compound segment, delete
already useless descriptor files - many files that must be
replicated. Some of them even don't need to be replicated b
Expensive is replication to all Infinispan nodes. IndexWriter creates
segment files, merge it to one compound segment, delete already useless
descriptor files - many files that must be replicated. Some of them even
don't need to be replicated because they are inserted into directory at the
begin of
There is one cache for all indexes. In this case scoping configuration will
be hard.Yes, some default config will be provided. Right, different
propterties for xml and programmatic would be better.
2009/8/14 Emmanuel Bernard
> Question,
> Do we have one cache for all indexes (directories) or one
On 14 Aug 2009, at 10:17, Łukasz Moreń wrote:
Yes, but i.e. FSDirectory flushes changes if any file descriptor is
created/updated - can be many in one IndexWriter life.
In infinispan case implementation, I want to commit changes only
when IndexWriter is closing - batch all modifications.
If
Yes, but i.e. FSDirectory flushes changes if any file descriptor is
created/updated - can be many in one IndexWriter life.
In infinispan case implementation, I want to commit changes only when
IndexWriter is closing - batch all modifications.
If I switch to transaction per descriptor modification -
On 14 Aug 2009, at 03:00, Emmanuel Bernard wrote:
> Yes but Lukasz do see data disappearing (see initial email). So there
> is a problem somewhere?
Regarding the data "disappearing", this seems to be an Infinispan JTA
bug when dealing with certain TMs. Lukasz has reported this [1] and
we ha
On 13 Aug 2009, at 19:11, Emmanuel Bernard wrote:
>
> Infini guys, do you support transactional operation spanning several
> concurrent threads?
The *same* tx on different threads? That's disallowed by the JTA spec.
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
htt
20 matches
Mail list logo
