Sanne,
That error looks suspiciously familiar to an old Lucene error they had.
Could they have regressed?
John Griffin
On Sep 27, 2009 2:00pm, Łukasz Moreń wrote:
You can try to incease TURNS_NUM (I've tried with 1000) and THREADS_NUM
(200) fields in InfinispanDirectoryTest to make it mor
You can try to incease TURNS_NUM (I've tried with 1000) and THREADS_NUM
(200) fields in InfinispanDirectoryTest to make it more propable. Same
problem appears also in InfinispanDirectoryProviderTest
An example stacktrace is:
21:22:44,441 ERROR InfinispanDirectoryTest:142 - Error
java.io.IOExcepti
+1
On 24 sept. 09, at 17:49, Manik Surtani wrote:
Minorly off topic, but rather than working with patches, do we want
this Directory impl in source control somewhere?
Being dependent on LGPL, it won't be accepted into Lucene's
contribs. If it doesn't depend on any Hibernate Search code, I
Minorly off topic, but rather than working with patches, do we want
this Directory impl in source control somewhere?
Being dependent on LGPL, it won't be accepted into Lucene's contribs.
If it doesn't depend on any Hibernate Search code, I could host it in
Infinispan's SVN repo...
On 23
It depends on your definition of "clean" but Emmanuel is correct. When I
worked with highly dynamic data (meaning many segments over a short period
of time ) the IW would do a segment merge whenever the merge threshold was
reached. The Lucene document numbers would obviously change and If there
wer
On 23 sept. 09, at 14:58, Łukasz Moreń wrote:
> Is it because, the IndexWriter only clean files if no indexReaders
> are reading them (how would that be detected)?
> It can happen if IndexWriter clean file, and IndexReader try to
> access that cleaned file.
IndexWriter doe snot clean files A
Conceptually I don't understand why it does work in a pure file system
directory (ie IndexReader can go and process queries with the
IndexWriter goes about its business) and not when using Infinispan.
Is it because, the IndexWriter only clean files if no indexReaders are
reading them (how w
I need to provide this same lifecycle for IndexWriter as for Infinispan tx -
IW is created: tx is started, IW is commited: tx is commited. It assures
that IndexReader doesn't read old data from directory.
Infinispan transaction can be started when IW acquires the lock, but its
commit on IW lock rel
Can you explain in more details what is going on.
Aside from that Workspace has been Sanne's baby lately so he will be
the best to see what design will work in HSearch. That being said, I
don't like the idea of subclassing / overriding very much. In my
experience, it has lead to more bad and
Hi,
After indexwriter's commit changes are visible by IndexReaders. Lock is
released later. If IR tries to read index between that two events, it
doesn't have current data since changes in Infinispan grid are not visible
until tx commit.
This can cause an axception.
> Why not commit the Infinisp
Hi,
Thanks for explanation.
Maybe better I will concentrate on the first release and postpone
distributed writing.
There is already LockStrategy that uses Infinispan. With using it I was
wrapping changes made by IndexWriter in Infinispan transaction, because of
performance reasons -
on lock obtai
Hi,
I'm wondering if it is reasonable to have multiple threads/nodes that
modifies indexes in Lucene Directory based on Infinispan? Let's assume that
two nodes try to update index in this same time. First one creates
IndexWriter and obtains
write lock. There is high propability that second node th
2009/9/12 Michael Neale :
> That does sounds pretty cool. Would be nice if the lucene indexes
> could scale along with how people will want to use infinispan.
> Probably worth playing with.
Sure, this is the goal of Łukasz's work; We know compass has
some good Directories, but we're building our o
Hi Łukasz,
a web application is certainly a good use case for your work, but it's
very hard to properly stress test your code this way.
JMeter is going to provide you with nice graphs, still you're not
focusing on the interesting code but on a much larger stack, including
HTTP communication, which
Hi Sanne,
I think Lucene dir works ok. I improved it following suggestions and fixed
bugs that came up.
Now I'm doing some performance tests, and would like to compare it with
other Directories.
To do it, I've created web app, that inserts and queries data (one insert
and one query per request).
W
Hi Łukasz,
what are the news about the Lucene Directory?
I'm very eager to test it, and have some time to help you if needed.
Is there an updated patch to see?
How are you testing it? Maybe I could help on that?
Also we're going to need some "glue" to integrate the first part of your work
(the j
Hi, thanks for comments ant tips. I'm improving it.Yes, I was checking with
profiler tool and hashcode - even not so heavy - was called often summary
took some time.
There is one test where multiple threads can read or write from/to different
cache instances. However I think would be good to do som
Hi there - all looks good. Some comments:
Summary documentation - is this going to be published on a wiki page
or something somewhere? Especially the Infinispan bit? I think
people will find this info very useful...
CacheKey - if this class is what everything is going to be used in the
c
18 matches
Mail list logo
