11:40 a.m.
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
3:35 p.m.
We could do it via the Statistics mechanism which can be made available via
JMX.
We just have to add whatever info they are interested in to monitor.
Vlad
On Thu, May 31, 2018 at 7:40 PM, Sanne Grinovero <sanne(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2 a.m.
We could do it via the Statistics mechanism which can be made
available
via
JMX.
From what I understand it would be an explicit call from the user
(OpenShift in this case) that would trigger an active check, like a request
to the database. Not sure the statistics are the best place to put such a
thing.
Or is it about us doing periodic checks on our own, and displaying the
results somewhere for anyone to see if something is wrong? That sounds
unnecessarily complex.
Probably best to explore this in ORM first, but then Search and OGM
could expose/implement it too for their respective services?
Sure. I wonder about the granularity though: if we have multiple
connections (multiple Elasticsearch cluster, a Lucene cluster with JGroups
or JMS, ...), what would these OpenShift people want us to expose? One big
"everything is fine/something is wrong" status, potentially returning a
specific error message to tell what part is wrong exactly? Or finer-grained
statuses, like "backend X: OK, backend Y: OK, Backend Z/JGroups: OK, ..."?
Also, I suppose we would expose our own APIs/SPIs, right? Not implement
some OpenShift-specific SPIs? I'd rather avoid that...
On Fri, 1 Jun 2018 at 01:36 Vlad Mihalcea <mihalcea.vlad(a)gmail.com> wrote:
> We could do it via the Statistics mechanism which can be made available via
> JMX.
>
> We just have to add whatever info they are interested in to monitor.
>
> Vlad
>
> On Thu, May 31, 2018 at 7:40 PM, Sanne Grinovero <sanne(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Yoann Rodiere
yoann(a)hibernate.org / yrodiere(a)redhat.com
Software Engineer
Hibernate NoORM team
8:06 a.m.
See inline
On 06/01/2018 03:00 AM, Yoann Rodiere wrote:
> We could do it via the Statistics mechanism which can be made
available
via
JMX.
>From what I understand it would be an explicit call from the user
(OpenShift in this case) that would trigger an active check, like a request
to the database. Not sure the statistics are the best place to put such a
thing.
I don't believe so either, although data from the Statistics may be
what
we do expose.
Perhaps a service placed into the StandardServiceRegistry that operates
as a
SessionFactoryObserver would work in this case allowing us to support
the use case
where an application spins up multiple SessionFactory configurations.
Or is it about us doing periodic checks on our own, and displaying
the
results somewhere for anyone to see if something is wrong? That sounds
unnecessarily complex.
We either do it periodically or we do it at the time the health check
endpoint is called?
Sure. I wonder about the granularity though: if we have multiple
connections (multiple Elasticsearch cluster, a Lucene cluster with JGroups
or JMS, ...), what would these OpenShift people want us to expose? One big
"everything is fine/something is wrong" status, potentially returning a
specific error message to tell what part is wrong exactly? Or finer-grained
statuses, like "backend X: OK, backend Y: OK, Backend Z/JGroups: OK, ..."?
I haven't looked at OpenShift specifically as-of-yet but I would guess
it is something
akin to my experience with Eureka where the caller is effectively
checking 2 things
1. Can I reach the endpoint (if not, its definitely OFFLINE)
2. The value of the "status" named value in the root of the JSON response.
So I would expect we'd had some type of structure similar to this JSON
response
{
"status": "UP"
"backend_X": {
"status": "UP",
...
},
"backend_Y": {
"status": "UP",
...
}
}
Also, I suppose we would expose our own APIs/SPIs, right? Not
implement
some OpenShift-specific SPIs? I'd rather avoid that...
+1
On Fri, 1 Jun 2018 at 01:36 Vlad Mihalcea
<mihalcea.vlad(a)gmail.com> wrote:
> We could do it via the Statistics mechanism which can be made available via
> JMX.
>
> We just have to add whatever info they are interested in to monitor.
>
> Vlad
>
> On Thu, May 31, 2018 at 7:40 PM, Sanne Grinovero <sanne(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
7:58 a.m.
This ties to the lazy database discovery in Cloud environments. The
issue related to that also mentions a health check API.
I don't think it ties to the Stats or JMX API as at least for the
initial start, this API should be able to provide feedback while
Hibernate engine is starting (and looping).
It would be interesting to explore what other IO engines offer as health
check APIs to be inspired (straight poll, callback etc).
Emmanuel
On Thu 18-05-31 17:40, Sanne Grinovero 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:44 a.m.
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
<sanne(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:57 a.m.
+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 <golovnin(a)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 <sanne(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:56 p.m.
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 <gunnar(a)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 <golovnin(a)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 <sanne(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:32 p.m.
I've looked into both Hawkular and Dropwizard. Personally I found neither
of them particularly easy to play with.
Did you have something specific in mind besides what we already collect
with the Statistics API? As Vlad mentioned, we can already do this.
On Sun, Jun 3, 2018 at 5:22 PM Sanne Grinovero <sanne(a)hibernate.org> wrote:
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 <gunnar(a)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 <golovnin(a)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 <sanne(a)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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2350
days inactive
2353
days old
8 comments
8 participants
participants (8)
-
Andrej Golovnin -
Chris Cranford -
Emmanuel Bernard -
Gunnar Morling -
Sanne Grinovero -
Steve Ebersole -
Vlad Mihalcea -
Yoann Rodiere