Thanks for all comments! Agreed to look at MicroProfile and other IO engines.
Sure we don't want to pull in more dependencies, just allow others to query Hibernate status over a well-defined API. In case this was to need some Openshift or MicroProfile specifics I'd code that as a new module, somewhat like providing a working example, which calls into / boots Hibernate. I don't like to rely exclusively on the orchestration layer to try/reboot in a loop as the only mechanism - we need to help with that. With a non-trivial amount of inter-dependent services, you'd have the risk of livelock. Even if it eventually resolves with some lucky timings, you might end up rebooting the Hibernate SessionFactory - including the JVM - and several other services. That could easily take a long time and waste a ton of computing resources if we're not careful. Sanne On 1 June 2018 at 14:57, Gunnar Morling <gun...@hibernate.org> wrote: > +1 for looking into the mP health check API. > > In fact, I don't even think that Hibernate would have to implement any sort > of looping itself. Instead, the orchestration layer would check the health > check endpoint and automatically restart the service if it's not in a > healthy state. That way, the ordering of start up isn't really an issue, the > application would be simply restarted as often as needed until the DB is up. > > 2018-06-01 15:44 GMT+02:00 Andrej Golovnin <golov...@gmx.net>: >> >> Hi Sanne, >> >> whatever you consider to implement in Hibernate ORM/Search/OMG >> I think you should use/follow the MicroProfile Health spec [1]. >> As far as I know WildFly Swarm supports already this spec. >> >> Best regards, >> Andrej Golovnin >> >> [1] https://github.com/eclipse/microprofile-health/ >> >> > On 31. May 2018, at 18:40, Sanne Grinovero <sa...@hibernate.org> wrote: >> > >> > It was suggested to me that Hibernate ORM could help people developing >> > microservices on Kubernetes / Openshift by making "health checks" >> > easier. >> > >> > In short, how to expose to some management API that we're being able >> > to connect to the database and do our usual things. >> > >> > This could be done by connection pools as well but I suspect there >> > could be benefits in exposing this information in a unified way at an >> > higher level API; also on top of using ad-hoc specific connection >> > APIs, or Dialect specific instructions, I guess we could monitor >> > timeout exceptions, etc.. happening on the application sessions. >> > >> > Wrote some notes on: >> > - https://hibernate.atlassian.net/browse/HHH-12655 >> > >> > Probably best to explore this in ORM first, but then Search and OGM >> > could expose/implement it too for their respective services? >> > >> > Or maybe people would prefer to just run a query? >> > >> > Thanks, >> > Sanne >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
