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.v...@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 <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
