If you wan't to try i could send you the binary, or you can just grab the svn and compile it. I'm using it without any problem and i use it with two index, one of 3 million rows and another one of 12 million rows. The code of the 2.3.1 is in the svn and the patch to the 2.3.2 in the mailing list. There was a little discussion in the mailing list about if first release 2.3.1 or 2.3.2 but all the commiters agreed to release 2.3.2 as it's just a maintenance release of 2.3.1 with some bugfixes. For the formal binary release it have to pass all the apache steps, some time in test without problem and the vote process, As you may know, the last released version was 2.0 having the 2.1 in the trunk a long time (also very stable, this one is in use by the rest of the projects in my company without any problem). I think that now that are 2 new commiters that keep the project moving forward, the new official release will come soon.
About 2.3.2, as I am in the initial phases of the release, I'm adding and changing fields in the index, so reducing the time of the full generation to the half is a big help. It has also some useful methods, like the reopen one, a partial optimize that reduce the number of segments of the index in much less time, a background index merger, and some goodies more. On Tue, Nov 25, 2008 at 12:00 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > . I expect to be disponible soon? > > On Tue, Nov 25, 2008 at 12:56 PM, Jokin Cuadrado <[EMAIL PROTECTED]> wrote: >> >> The indexreader take a snapshot of the current index in the directory. >> If you modify it, you mus't tell the reader to reopen it. Right now >> nhibernate search do it when when you write something to the index, so >> you must implement a way to tell the index to reopen. You can throw >> the workspace and create a new one for example. >> >> I just created an jira issue tu upgrade to lucene.net 2.3.2 It have >> several performance benefits on indexing, also adds a reopen method to >> the index reader so it can read the changes without having to drop an >> read again all the cache. I expect to be disponible soon, as all the >> work is done and need a bit of test and pass all the apache release >> process. (But i'm currently using it without any problem and with a >> big performance benefits in indexing speeds as you can read in the >> another thread). >> >> >> >> On Tue, Nov 25, 2008 at 11:46 AM, Vito Vessia <[EMAIL PROTECTED]> >> wrote: >> > >> > Thank you very much for your answer. I've only a last question: can I >> > leave the nh.search on the SAN so all the back-end servers can always >> > read an updated index instead of a local copy of this index constantly >> > updated? In this way I have not to provide an indexreaders refresh >> > because the index is always consistent. The scheduled indexer takes >> > care about the mass update of the indexes and all the backed just read >> > the index with no lock or update on it. Is that a correct way? >> > >> > --Vito >> > >> > >> > >> > On 25 Nov, 11:16, "Jokin Cuadrado" <[EMAIL PROTECTED]> wrote: >> >> On Tue, Nov 25, 2008 at 10:36 AM, Vito <[EMAIL PROTECTED]> wrote: >> >> > All the backend servers are equivalent so there is no special master >> >> > and all the business services running on these backend servers may >> >> > update NH.Search/Lucene indexes. The indexes update is contextual. >> >> > If I configure my back end servers in master/slaves mode, is there an >> >> > automatic way/setting to queue all updates on a master server from >> >> > all >> >> > the slave ones or I have to write the code from scratch? You say that >> >> > I should create an offline scheduled indexer that update indexes >> >> > instead of the current contextual way? Is it the best way? >> >> >> >> As Ayende said, If the index file system is shared among all the >> >> backend servers, you can find problems whith the locking mechanism in >> >> network shares. And in the case it works, a bad performance because >> >> all the machines would need to compete for the write lock. As far as i >> >> know, neither Nhibernate nor Nhibernate.search provide a way to queue >> >> the updates to a master machine. >> >> >> >> The scheduled indexer is what we use, because having a central point >> >> for index writing is a big gain in performance and control in lucene. >> >> You could easily manage when to optimize the index, (a big gain in >> >> search performance and memory footprint again), and the updates are >> >> done in bigger batches, which is also better. If you can live with a >> >> small delay between the database is updated and the search results are >> >> updated, i think it is one of the bests solutions. >> >> >> >> You must also provide a way to refresh the indexreaders, as if i >> >> remember well, nhibernate search refresh them when you write something >> >> to the index. For example if your nlb doesn't send updates one of the >> >> backend machines, it will never refresh the indexreader and it will >> >> present stale results. >> >> >> >> -- >> >> Jokin >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NHibernate Contrib - Development Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com.ar/group/nhcdevs?hl=en -~----------~----~----~----~------~----~------~--~---
