Hello, welcome to Hibernate Search time! [for those unaware: some of are now experimenting to work on 2-3 week sprints fully focused on a single Hibernate project, rotating the subject. We decided this privately as it's a matter of time-management for us, but I'm now opening the conversation up to all developers and contributors as it affects the project evolution and technical discussion; essentially it means we'll be focused on Hibernate Search more than other projects in the next few weeks, and aim at get some significant stuff done]
My first and foremost goal for the next couple of weeks would be to drive forward a pain point which is all of: - showing active interest from several power-contributors [1,2,3] - highly demanded from product perspective - had lots of people *begging* for better solutions in the past You might have guessed: I'm talking about the backend configuration complexity in a clustered environment: both the JGroups and the JMS solutions expose the user to various complex system settings. With Emmanuel and Hardy I had some hints of conversations about it, but essentially to start this subject I'm proposing a meeting to discuss these; we can try and make it open to everyone, I might even make a couple of slides. # What do we want During our last meeting, a scary point was to hear that Emmanuel was considering the priority to be free form. It never was for me, and while we didn't dig during that call, we better clarify this soon. Let's please find a moment on IRC to discuss the goals, especially as I need to update the project roadmap. # How do we want it I've been hoping for a clear/formal set of requirements to be provided by some users, as there are many ways to look at the problem. But this never came, and I'm concluding that: A) if a paying customer or other kind of sponsor will want to discuss these requirements I better fly to them and talk face to face. B) I'm being lazy and selfish in expecting externals to clarify all details.. I shouldn't try to deflect this hard problem. I've been thinking of several possible ways, and there are lots of options, and some tradeoffs to choose from. One of these options is to use a distributed consensus - since we already use JGroups in various projects, JGroups RAFT [4] seems a natural candidate but while I'd love the excuse to play with it, it's a very new codebase. Another option would be the more mature Apache Kafka - great for log based replication so might even be complementary to the JGroups RAFT implementation - or just improve JMS (via the standard or via Apache Camel) to have it integrate with Transactions [5: just got a contribution!] and provide better failover options. Not least, I just heard that WildFly 10 is going to provide some form of automatic HA/JMS singleton consumer.. I just heard about it and will need to find more about it. While it's tempting to implement our own custom super clever backend, we should prioritize for an off-the-shelf method with high return on investment to solve the pain point. Also, as suggested by Hardy some months ago, it would be awesome to have the so called "Hibernate Search master node" not need any entity classes nor depend at all to the deployed application (nor its extensions like analyzers), so that if the solution still needs a "master role", we could simply provide a master app which doesn't need changes on application changes. This would necessarily be a change for 6.0, but let's either prepare for that, or get rid of the "master node" concept altogether. We have been sitting and thinking about the problem since a while, I'd love now to see some empirical progress: merge them as experimental, and have some natural selection happen while these would also help us to refine the requirements. ## Other topics Of course this isn't the only thing we'll be working on. The primary goal of current branch is still to deliver an Hibernate ORM 5 compatible version, but we're in an horrible position with that since WildFly 10 just released another alpha tag which still doesn't use Hibernate ORM v.5; Since it's [currently and temporarily] hard to run WildFly overriding the Hibernate ORM version, we won't be able to close in to a CR or Final release until at least the next Wildfly tag. In the meantime we can do some of research needed for the above topic, and make progress with the many issues open for 5.4 [6]. Another subject which we really should work on in this sprint, is to avoid transaction timeout on MassIndexer within a container [7] So, for tomorrow: to get started, JIRA is updated and you have all tasks assigned already. Let's start from there, and then schedule a meeting to discuss the above. Thanks! Sanne References : 1 - https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend 2 - https://github.com/mrobson/hibernate-search-infinispan-jms 3 - https://forum.hibernate.org/viewtopic.php?f=9&t=1040179 4 - https://github.com/belaban/jgroups-raft 5 - https://hibernate.atlassian.net/browse/HSEARCH-668 6 - https://hibernate.atlassian.net/issues/?filter=12266 7 - https://hibernate.atlassian.net/browse/HSEARCH-1474 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
