[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-135) Create a RAMDirectoryProvider from an existing Lucene FSDirectory

Hardy Ferentschik (JIRA) noreply at atlassian.com
Tue Oct 27 06:15:12 EDT 2009


    [ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34315#action_34315 ] 

Hardy Ferentschik commented on HSEARCH-135:
-------------------------------------------

[11:00am] hardy_: I was wondering whether you have some more experience now with RamDirectory vd FSDirectory in Lucene
[11:00am] hardy_: https://forum.hibernate.org/viewtopic.php?f=9&t=1000523
[11:01am] hardy_: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-135
[11:01am] hardy_: I created HSEARCH-135 a while ago, because I also thought it would be a good idea to use a RAMDirectory, but initalise it with a FSDirectory
[11:02am] sannegrinovero: ah yer I remember that
[11:02am] sannegrinovero: like more than a year ago 
[11:02am] hardy_: I am not sure if this actually still makes snese
[11:03am] sannegrinovero: my point is that RAMDirectory isn't faster than FSDirectory, when testing on non-trivial indexes
[11:04am] hardy_: right. I think that was also Emmanuel's take on it
[11:04am] sannegrinovero: but if you think the feature ads value, it's easy to implement, so no reason to not making it, besides dev time.
[11:04am] hardy_: i see
[11:04am] hardy_: I think the guy on the forum might have a point with the configuration
[11:05am] sannegrinovero: the NIODirectory is also interesting, but is in high complexity
[11:05am] hardy_: I wam wondering whether we should use the RAMDirectory constructor passing the file based index in case indexBase is specified
[11:06am] sannegrinovero: "the index is allowed to take xyzMB in the VM and the rest you have to go to disk for." is really an Operating System problem
[11:07am] hardy_: right
[11:07am] sannegrinovero: that's what you get when using FSDirectory.. OS will use caches as it sees more fit
[11:07am] sannegrinovero: that's why FSDirectory is as fast as memory, because it uses memory in clever ways.. on unix at least
[11:09am] hardy_: ok, thanks
[11:09am] sannegrinovero: so I see he's asking for a clever implementation combining FS+RAM approaches, I think the answer is FSDirectory, RAMDir being more like a toy.
[11:10am] sannegrinovero: The feature you opened might be useful in case you want the index to be initialized at startup, but then loose changes and "reset state" at application startup.
[11:11am] hardy_: makes sense

> Create a RAMDirectoryProvider from an existing Lucene FSDirectory
> -----------------------------------------------------------------
>
>                 Key: HSEARCH-135
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-135
>             Project: Hibernate Search
>          Issue Type: New Feature
>          Components: directory provider
>            Reporter: Hardy Ferentschik
>            Priority: Trivial
>
> It would be nice to have the ability to use a Lucene RAM index which gets constucted from an existing Lucene file based indexed. For example in an JMS setup the master could create a file based Lucene index, share it out to the slaves which in turn use this file based index to populate a RAM index. This would give you the best of two worlds. 
> Not sure how hard it would be to implement this in an unclustered environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list