[hibernate-issues] [Hibernate-JIRA] Updated: (HSEARCH-323) Fault tolerant FSSlaveDirectoryProvider

[Oliver Siegmar (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oliver Siegmar updated HSEARCH-323:
-----------------------------------

    Attachment: FSSlaveDirectoryProvider2.java.diff

bq. 1. could you please avoid changing all whitespaces? it doesn't apply on our code as-is, and I'm having an hard time trying to fix it by editing myself.
Sure, here's a patch against upstream using git, without any whitespace changes.

bq. 2. "throw new IllegalStateException(e);", I'd suggest to keep the IOException, or if you really need to wrap it in a runtime exception it's better to use the SearchException which we consistently use for those cases. I wouldn't consider it illegal to have a disk full

I don't need an exception anymore, because I use a RAMDirectory.

bq. 3. dummyDirectory: this one will always be empty, right? Why not using a RAMDirectory instead of physically writing an index to disk? Also I wouldn't close it in the TriggerTask, some IndexReader might still be using it and cause collateral errors. If you where sure no reader could be using it yet, there would be no point in using a dummy at all - so I guess that in your use case it's actually being used. I think you could have it closed at the next task period, or if it gets too complex just leave it open.

I didn't closed the Directory in the TriggerTask, but thanks for the advice - I use a RAMDirectory, now.

bq. 4. Why starting a new TimerTask, couldn't we reuse the existing one? every time it triggers, it could check if we already performed proper initialization. It would make sense to have a separate InitTask if you wanted to configure initial retry periods on a different time base than the copy task, but it doesn't seem the case in the current patch. If you want you can add a new configuration property, make sure to document it.

We do have two tasks now, a InitTask (which one is only used if we need to *retry* initialization) and a UpdateTask (former known as TriggerTask). The UpdateTask is scheduled as soon as the initialization is finished. I think this is the cleanest approach of initialization and update management.


> Fault tolerant FSSlaveDirectoryProvider
> ---------------------------------------
>
>                 Key: HSEARCH-323
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-323
>             Project: Hibernate Search
>          Issue Type: Improvement
>          Components: directory provider
>    Affects Versions: 3.1.0.GA
>            Reporter: Oliver Siegmar
>         Attachments: FSSlaveDirectoryProvider.java.diff, FSSlaveDirectoryProvider2.java.diff
>
>
> The current implementation of FSSlaveDirectoryProvider requires an existent master repository at startup. In our environment it could happen, that the master repository is built some time after the clients (using the FSSlaveDirectoryProvider) are being started. It'd be good to have a more fault tolerant FSSlaveDirectoryProvider, that would retry to initialize itself (using a TimerTask for example). The configuration should allow to enable/disable this feature and to specify the retry interval and period.

-- 
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