Quote:
It was actually pretty easy once I started. :)
Nice!
Quote:
I'll put something together shortly. How would you like it? My code is coupled to my framework and you will want it in a more pure form.
Why is your code coupled to your framework? Do you think you could make it "clean"?
First thing is you should open a new JIRA [1], both to track your cool idea and the changes which are going to happen; you can open one as "new feature".
Then you can either attach a patch file on the JIRA issue, or send a pull request on GitHub; we generally prefer patches formatted consistently with the Hibernate style, having unit tests and a short description in the documentation (which is in source control as well under the _hibernate-search-documentation_ Maven module). But all of this is optional, if you can't do something we can help out: better to receive a half baked patch than nothing, but in that case we might reject it or take more time to be able to look at it.
Of course you can ask for advise or better instruction about anything, either here or better on the hibernate-dev mailing list [2] or IRC chat [3]
1 - https://hibernate.onjira.com/browse/HSEARCH
2 - http://www.hibernate.org/community/mailinglists
3 - http://www.hibernate.org/community/irc
Quote:
To start with I had the wrong version of jGroups which really mucked thing up... but even once I got the configuration worked out for jGroups (we needed TCPPING as the network admins didn't like the sounds of the default multicast option) I had issues. I couldn't get the first node up in the cluster (presumably the coordinator) to be able to leave the group and come back with all the data intact (even if another node was still running with all the data replicated). Maybe this would be solved with a store on the master and using a JMS backed as suggested (to solve the 1 lucene writer issue and JMS ensuring no data loss). But then I thought, why use 2 technologies (with 2x the admin and config) when 1 can do it. If HS/infinispan was able to take care of the writer across the cluster automatically (meaning no JMS required) and self heal regardless of which node goes down (obviously only possible when replication is happening), then it would be a great solution. Ie. a great offering compared to Elastic Search. Basically what I wanted was a simple to configure clustering option (like elastic search) but with the automatic indexing that Hibernate Search provides. Is it there yet in a later version? Please don't take this as a harsh criticism of your great work, just letting you know my experiences...
Very appreciated feedback! Yes we have several ideas to improve on that, I actually have a branch which is using just Infinispan to do both command forwarding and storage, and requires just a single configuration property: "indexmanager = infinispan". Master election is automatic and differentiated per index/shard .. all looking good but couldn't merge it yet because of open issues in Infinispan. If they get fixed quickly we'll have that in Hibernate Search 4.2, but it seems like we'll have to move on with the release without this.
I personally highly prefer embedded Lucene as it's more flexible and can get better performance, but we're not against contributions to integrate remote services like Elastic Search or Solr, we just need someone motivated enough to help on that. So if you think your project would strongly benefit from such an integration, or know someone wanting it, we can work together and make that.
Login
FAQ
Search
