<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Looks good :)<div><br></div><div>I have a few comments on top of Sanne's</div><div><br></div><div><span class="Apple-style-span" style="font-family: Arial; "><div>o JGroupsBackendQueueProcessorFactory<br>Should the channel name have a default name? Could answer yes or no, I am just wondering.</div><div>Empty cfg when you are done using it, or even better don't keep it around and pass it as parameters</div><div><br><br></div><div>o JGroupsAbstractMessageReceiver<br></div><div>getState / setState. What's that?<br></div><div>why those unimplemented methods? Is that expected?</div><div>Generally speaking add comments where the code is not obvious</div><div><br>o Tests</div><div>I haven't tested nor ahve looked long at the tests</div><div>Why do you use plain SQL in one test to creste the object? wouldn't Hibernate work?</div><div>in SearchTestCase protected static File indexDir; => better to expose a protected getter I guess</div><div><br><br></div><div>o Configuration for JGroups</div><div>I'm surprised there is no config on the JGroups side</div><div>Is there some recommendation wrt guaranteed delivery etc?</div><div>Could we somehow extract two or three default profiles (as well as a custom one?)<br><br></div><div>o point #4</div><div>I agree with Sanne, the configuration is too opaque and fragile. I would create:</div><div> - MasterJGroupsBackendQueueProcessorFactory</div><div> - SlaveJGroupsBackendQueueProcessorFactory</div><div>The code will be cleaner.<br></div><div><br>o point #5</div><div>I dont' think that can work easily but we can explore. Maybe by providing the JNDI name of either the EMF or the SessionFactory we can have a configuration only approach.</div><div><br></div><div>o point #6</div><div>I agree Producers and Receivers is confusing for an Hibernate Search user, let's mask these notions and replace them with master and slaves.</div></span></div><div><br></div><div>o docs and logs</div><div>Generally speaking the code is simple enough that it's reasable but a few comments were things are surprising will help</div><div>logs (debug / trace level) can be of help.</div><div><br><div><div>On Jun 9, 2009, at 19:02, Łukasz Moreń wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br>I've finished task concerning JMS replacement with JGroups. The patch is attached. The general idea of pushing indexes through JG is assured, however there are issues to improve (i.e. flexible JG protocol stack configuration). Any review or advices would be welcome to make sure that I am not going into blind alley.<br> <br>Thanks,<br>Lukasz<br><br><div class="gmail_quote">2009/5/27 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Lukasz,<br> I have been discussing with Manik on #3 and we think that JBoss Cache / Infinispan are probably a better fit than plain JGroups for that as all the plumbing will be configured for you.<br> When you reach this problem, let's revive this discussion.<div><div></div><div class="h5"><br> <br> On May 25, 2009, at 11:07, Hardy Ferentschik wrote:<br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi,<br> <br> I talked with Łukasz about this last wekk. Definitely, #1 and #3.<br> #2 I don't like either.<br> <br> The befefit of #3 would also be that one could drop the requirement of<br> having a shared file system (NFS, NAS, ...) #3 should be quite easy to<br> implement. Maybe easy to get started with.<br> <br> --Hardy<br> <br> On Mon, 25 May 2009 10:55:52 +0200, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>> wrote:<br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hello<br> I am not sure this is where we should go, or at least, it depends. here are three scenarii<br> <br> <br> #1 JMS replacement<br> If you want to use JGroups as a replacement for the JMS backend, then I think you should write a jgroups backend. Check org.hibernate.search.backend.impl.jms<br> In this case all changes are sent via JGroups to a "master". The master could be voted by the cluster possibly dynamically but that's not necessary for the first version.<br> <br> #2 apply indexing on all nodes<br> JGroups could send the work queue to all nodes and each node could apply the change.<br> for various reasons I am not fan of this solution as it creates overhead in CPU / memory usage and does nto scale very well from a theoretical PoV.<br> <br> #3 Index copy<br> this is what you are describing, copying the index using JGroups instead of my file system approach. This might have merits esp as we could diminish network traffic using multicast but it also require to rethink the master / slave modus operandi.<br> Today the master copy on a regular basis a clean index to a shared directory<br> On a regular basis, the slave go and copy the clean index from the shared directory.<br> In your approach, the master would send changes to the slaves and slaves would have to apply them "right away" (on their passive version)<br> <br> I think #1 is more interesting than #3, we probably should start with that. #3 might be interesting too, thoughts?<br> <br> Emmanuel<br> <br> PS: refactoring is a fact of life, so feel free to do so. Just don't break public contracts.<br> <br> On May 21, 2009, at 22:14, Łukasz Moreń wrote:<br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi,<br> <br> I have few questions that concern using JGroups to copy index files. I think to create sender(for master) and receiver(slave) directory providers.<br> Sender class mainly based on existing FSMasterDirectoryProvider, first create local index copy and send later to slave nodes<br> (or send without copying, but that may cause lower performance?).<br> To avoid code redundancy it would be good to refactor a little FSMasterDirectoryProvider class, so then I can use copying functionality in new DirectoryProvider and add sending one; or rather I should work around it?<br> <br> I do not understand completely how does the multithreading access to index file work. Does FileChannel class assure that, when index is copied and new Lucene works are pushed?<br> </blockquote></blockquote> <br> <br> <br> </blockquote> <br> </div></div></blockquote></div><br> <span><JGroups_Backend_draft_10-06-2009.patch></span>_______________________________________________<br>hibernate-dev mailing list<br><a href="mailto:hibernate-dev@lists.jboss.org">hibernate-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/hibernate-dev<br></blockquote></div><br></div></body></html>