[jira] [Comment Edited] (IGNITE-17398) Opencensus metrics do not work well with Prometheus since it do not have tags
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574198#comment-17574198
]
Sergey Kadaner edited comment on IGNITE-17398 at 8/2/22 12:25 PM:
--
I see your point about it not being free, however, they say "Each labelset is
an additional time series". As I understand it, that means that it is the same
cost as creating the same number of time series. I.e. _cache_MY_CACHE_NAME1_
and _cache_MY_CACHE_NAME2_ metrics have the same cost as
_cache\{name="MY_CACHE_NAME1"}_ and {_}cache\{name="MY_CACHE_NAME2"}{_}. So
basically there is no additional cost in this case.
In fact, the previous section to the one you mentioned explains [when to use
labels|https://prometheus.io/docs/practices/instrumentation/#use-labels] and it
matches this case exactly.
It is hard to say how it affects the GC pressure without actually measuring it,
but AFAIK modern garbage collectors (G1 and newer) are very good with
short-lived objects and should not have issues reclaiming them.
The issue is also not simply a convenience problem unless you can suggest how
to draw diagrams without the tags and without knowing cache names in advance.
was (Author: sergeykad):
I see your point about it not being free, however, they say "Each labelset is
an additional time series". As I understand it, that means that it is the same
cost as creating the same number of time series. I.e. _cache_MY_CACHE_NAME1_
and _cache_MY_CACHE_NAME2_ metrics have the same cost as
_cache\{name="MY_CACHE_NAME1"}_ and {_}cache\{name="MY_CACHE_NAME2"}{_}. So
basically there is no additional cost in this case.
It is hard to say how it affects the GC pressure without actually measuring it,
but AFAIK modern garbage collectors (G1 and newer) are very good with
short-lived objects and should not have issues reclaiming them.
The issue is also not simply a convenience problem unless you can suggest how
to draw diagrams without the tags and without knowing cache names in advance.
> Opencensus metrics do not work well with Prometheus since it do not have tags
> -
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
> Attachments: image-2022-07-20-17-51-07-217.png
>
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
> For example with tags it is very easy to get a graph in Grafana with a cache
> hit percentage that includes every existing cache. It automatically extracts
> the cache name from the "cache" tag. Unfortunately, it is not possible if
> there are no tags.
> !image-2022-07-20-17-51-07-217.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17398) Opencensus metrics do not work well with Prometheus since it do not have tags
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574198#comment-17574198
]
Sergey Kadaner edited comment on IGNITE-17398 at 8/2/22 12:20 PM:
--
I see your point about it not being free, however, they say "Each labelset is
an additional time series". As I understand it, that means that it is the same
cost as creating the same number of time series. I.e. _cache_MY_CACHE_NAME1_
and _cache_MY_CACHE_NAME2_ metrics have the same cost as
_cache\{name="MY_CACHE_NAME1"}_ and {_}cache\{name="MY_CACHE_NAME2"}{_}. So
basically there is no additional cost in this case.
It is hard to say how it affects the GC pressure without actually measuring it,
but AFAIK modern garbage collectors (G1 and newer) are very good with
short-lived objects and should not have issues reclaiming them.
The issue is also not simply a convenience problem unless you can suggest how
to draw diagrams without the tags and without knowing cache names in advance.
was (Author: sergeykad):
I see your point about it not being free, however, they say "Each labelset is
an additional time series". As I understand it, that means that it is the same
cost as creating the same number of time series. I.e. _cache_MY_CACHE_NAME1_
and _cache_MY_CACHE_NAME2_ metrics have the same cost as
_cache\{name="MY_CACHE_NAME1"}_ and {_}cache\{name="MY_CACHE_NAME2"}{_}. So
basically there is no additional cost in this case.
It is hard to say how it affects the GC pressure without actually measuring it,
but AFAIK modern garbage collectors (G1 and newer) are very good with
short-lived objects and should not have issues reclaiming them.
The issue is also not simply a convenience problem unless you can suggest how
to draw diagrams without knowing cache names in advance without the tags.
> Opencensus metrics do not work well with Prometheus since it do not have tags
> -
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
> Attachments: image-2022-07-20-17-51-07-217.png
>
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
> For example with tags it is very easy to get a graph in Grafana with a cache
> hit percentage that includes every existing cache. It automatically extracts
> the cache name from the "cache" tag. Unfortunately, it is not possible if
> there are no tags.
> !image-2022-07-20-17-51-07-217.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17398) Opencensus metrics do not work well with Prometheus since it do not have tags
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574198#comment-17574198
]
Sergey Kadaner edited comment on IGNITE-17398 at 8/2/22 12:19 PM:
--
I see your point about it not being free, however, they say "Each labelset is
an additional time series". As I understand it, that means that it is the same
cost as creating the same number of time series. I.e. _cache_MY_CACHE_NAME1_
and _cache_MY_CACHE_NAME2_ metrics have the same cost as
_cache\{name="MY_CACHE_NAME1"}_ and {_}cache\{name="MY_CACHE_NAME2"}{_}. So
basically there is no additional cost in this case.
It is hard to say how it affects the GC pressure without actually measuring it,
but AFAIK modern garbage collectors (G1 and newer) are very good with
short-lived objects and should not have issues reclaiming them.
The issue is also not simply a convenience problem unless you can suggest how
to draw diagrams without knowing cache names in advance without the tags.
was (Author: sergeykad):
I see your point about it not being free, however, they say "Each labelset is
an additional time series". As I understand it, that means that it is the same
cost as creating the same number of time series. I.e. _cache_MY_CACHE_NAME1_
and _cache_MY_CACHE_NAME2_ metrics have the same cost as
_cache\{name="MY_CACHE_NAME1"}_ and {_}cache\{name="MY_CACHE_NAME2"}{_}. So
basically there is no additional cost in this case.
It is hard to say how it affects the GC pressure without actually measuring it,
but AFAIK modern garbage collectors (G1 and newer) are very good with
short-lived objects and should not have issues reclaiming them.
The issue is also not simply a convenience problem unless you can suggest how
to draw diagrams without knowing cache names in advance.
> Opencensus metrics do not work well with Prometheus since it do not have tags
> -
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
> Attachments: image-2022-07-20-17-51-07-217.png
>
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
> For example with tags it is very easy to get a graph in Grafana with a cache
> hit percentage that includes every existing cache. It automatically extracts
> the cache name from the "cache" tag. Unfortunately, it is not possible if
> there are no tags.
> !image-2022-07-20-17-51-07-217.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17398) Opencensus metrics do not work well with Prometheus since it do not have tags
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574198#comment-17574198
]
Sergey Kadaner commented on IGNITE-17398:
-
I see your point about it not being free, however, they say "Each labelset is
an additional time series". As I understand it, that means that it is the same
cost as creating the same number of time series. I.e. _cache_MY_CACHE_NAME1_
and _cache_MY_CACHE_NAME2_ metrics have the same cost as
_cache\{name="MY_CACHE_NAME1"}_ and {_}cache\{name="MY_CACHE_NAME2"}{_}. So
basically there is no additional cost in this case.
It is hard to say how it affects the GC pressure without actually measuring it,
but AFAIK modern garbage collectors (G1 and newer) are very good with
short-lived objects and should not have issues reclaiming them.
The issue is also not simply a convenience problem unless you can suggest how
to draw diagrams without knowing cache names in advance.
> Opencensus metrics do not work well with Prometheus since it do not have tags
> -
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
> Attachments: image-2022-07-20-17-51-07-217.png
>
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
> For example with tags it is very easy to get a graph in Grafana with a cache
> hit percentage that includes every existing cache. It automatically extracts
> the cache name from the "cache" tag. Unfortunately, it is not possible if
> there are no tags.
> !image-2022-07-20-17-51-07-217.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-15334) Incorrect detection of multiple grid instances
[
https://issues.apache.org/jira/browse/IGNITE-15334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571330#comment-17571330
]
Sergey Kadaner edited comment on IGNITE-15334 at 7/26/22 10:21 AM:
---
I was trying to start my service in a development environment without any
actual Ignite server. Caching is not required in such a scenario.
Unfortunately, I do not have the stack trace anymore.
was (Author: sergeykad):
I was trying to start my service in a development environment without any
actual Ignite server. Caching is not required in such a scenario.
Unfortunately I do not have the stack trace anymore.
> Incorrect detection of multiple grid instances
> --
>
> Key: IGNITE-15334
> URL: https://issues.apache.org/jira/browse/IGNITE-15334
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
>
> The IgnitionEx class has a validation that checks if SPI supports multiple
> grid instances. However, the following code is used to check if it is a
> single instance:
> {code:java}
> startCtx.single(grids.size() == 1);
> {code}
> In my case the grid size is zero, therefore startCtx.single is false which
> triggers an error for SPI that does not support multiple instances.
>
> IMHO the the following code should be used instead:
> {code:java}
> startCtx.single(grids.size() < 2);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15334) Incorrect detection of multiple grid instances
[
https://issues.apache.org/jira/browse/IGNITE-15334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571330#comment-17571330
]
Sergey Kadaner commented on IGNITE-15334:
-
I was trying to start my service in a development environment without any
actual Ignite server. Caching is not required in such a scenario.
Unfortunately I do not have the stack trace anymore.
> Incorrect detection of multiple grid instances
> --
>
> Key: IGNITE-15334
> URL: https://issues.apache.org/jira/browse/IGNITE-15334
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
>
> The IgnitionEx class has a validation that checks if SPI supports multiple
> grid instances. However, the following code is used to check if it is a
> single instance:
> {code:java}
> startCtx.single(grids.size() == 1);
> {code}
> In my case the grid size is zero, therefore startCtx.single is false which
> triggers an error for SPI that does not support multiple instances.
>
> IMHO the the following code should be used instead:
> {code:java}
> startCtx.single(grids.size() < 2);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16941) Spring Cache integration does not expose statistics via Spring's CacheMeterBinderProvider
[ https://issues.apache.org/jira/browse/IGNITE-16941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kadaner updated IGNITE-16941: Description: Exposing cache statistics is an important part of Spring Cache integration. You can see [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] a number of existing implementations. I am trying to implement it myself by writing a class that implements CacheMeterBinderProvider. However, the 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's Cache interface is package protected and cannot be used. There is a simple example here of implementing the CacheMeterBinderProvider: [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] was: Exposing cache statistics is an important part of Spring Cache integration. You can see [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] a number of existing implementations. I am trying to implement it myself, but I am supposed to write a class that implements CacheMeterBinderProvider, but unfortunately the 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's Cache interface is package protected. There is a simple example here of implementing the CacheMeterBinderProvider: [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] > Spring Cache integration does not expose statistics via Spring's > CacheMeterBinderProvider > - > > Key: IGNITE-16941 > URL: https://issues.apache.org/jira/browse/IGNITE-16941 > Project: Ignite > Issue Type: Improvement > Components: cache, extensions, integrations, spring >Affects Versions: 2.9.1 >Reporter: Sergey Kadaner >Priority: Major > > Exposing cache statistics is an important part of Spring Cache integration. > You can see > [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] > a number of existing implementations. > I am trying to implement it myself by writing a class that implements > CacheMeterBinderProvider. However, the > 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's > Cache interface is package protected and cannot be used. > There is a simple example here of implementing the CacheMeterBinderProvider: > [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17398) Opencensus metrics do not work well with Prometheus since it do not have tags
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-17398:
Summary: Opencensus metrics do not work well with Prometheus since it do
not have tags (was: Opencensus metrics do not work well with Prometheus)
> Opencensus metrics do not work well with Prometheus since it do not have tags
> -
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
> Attachments: image-2022-07-20-17-51-07-217.png
>
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
> For example with tags it is very easy to get a graph in Grafana with a cache
> hit percentage that includes every existing cache. It automatically extracts
> the cache name from the "cache" tag. Unfortunately, it is not possible if
> there are no tags.
> !image-2022-07-20-17-51-07-217.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17398) Opencensus metrics do not work well with Prometheus
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-17398:
Description:
The metrics created by the [new metrics
system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
are very inconvenient to use with Prometheus since it does not use tags.
For example, Spring metric generated for the same cache looks like the
following in Prometheus and is very convenient to use:
{noformat}
cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
1387.0{noformat}
The native Ignite metric looks like the following:
{noformat}
cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
The Spring reported statistics can be easily filtered by cache name and other
attributes, while the build-in Ignite metrics do not provide an easy way to
access cache names. The only option seems to be parsing the
"cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by Grafana.
For example with tags it is very easy to get a graph in Grafana with a cache
hit percentage that includes every existing cache. It automatically extracts
the cache name from the "cache" tag. Unfortunately, it is not possible if there
are no tags.
!image-2022-07-20-17-51-07-217.png!
was:
The metrics created by the [new metrics
system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
are very inconvenient to use with Prometheus since it does not use tags.
For example, Spring metric generated for the same cache looks like the
following in Prometheus and is very convenient to use:
{noformat}
cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
1387.0{noformat}
The native Ignite metric looks like the following:
{noformat}
cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
The Spring reported statistics can be easily filtered by cache name and other
attributes, while the build-in Ignite metrics do not provide an easy way to
access cache names. The only option seems to be parsing the
"cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by Grafana.
> Opencensus metrics do not work well with Prometheus
> ---
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
> Attachments: image-2022-07-20-17-51-07-217.png
>
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
> For example with tags it is very easy to get a graph in Grafana with a cache
> hit percentage that includes every existing cache. It automatically extracts
> the cache name from the "cache" tag. Unfortunately, it is not possible if
> there are no tags.
> !image-2022-07-20-17-51-07-217.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17398) Opencensus metrics do not work well with Prometheus
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-17398:
Attachment: image-2022-07-20-17-51-07-217.png
> Opencensus metrics do not work well with Prometheus
> ---
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
> Attachments: image-2022-07-20-17-51-07-217.png
>
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17398) Opencensus metrics do not work well with Prometheus
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-17398:
Description:
The metrics created by the [new metrics
system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
are very inconvenient to use with Prometheus since it does not use tags.
For example, Spring metric generated for the same cache looks like the
following in Prometheus and is very convenient to use:
{noformat}
cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
1387.0{noformat}
The native Ignite metric looks like the following:
{noformat}
cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
The Spring reported statistics can be easily filtered by cache name and other
attributes, while the build-in Ignite metrics do not provide an easy way to
access cache names. The only option seems to be parsing the
"cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by Grafana.
was:
The metrics created by the new metrics system are very inconvenient to use with
Prometheus since it does not use tags.
For example, Spring metric generated for the same cache looks like the
following in Prometheus and is very convenient to use:
{noformat}
cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
1387.0{noformat}
The native Ignite metric looks like the following:
{noformat}
cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
The Spring reported statistics can be easily filtered by cache name and other
attributes, while the build-in Ignite metrics do not provide an easy way to
access cache names. The only option seems to be parsing the
"cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by Grafana.
> Opencensus metrics do not work well with Prometheus
> ---
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
>
> The metrics created by the [new metrics
> system|https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics]
> are very inconvenient to use with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17398) Opencensus metrics do not work well with Prometheus
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-17398:
Labels: metrics (was: )
> Opencensus metrics do not work well with Prometheus
> ---
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
> Labels: metrics
>
> The metrics created by the new metrics system are very inconvenient to use
> with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17398) Opencensus metrics do not work well with Prometheus
[
https://issues.apache.org/jira/browse/IGNITE-17398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-17398:
Affects Version/s: 2.9.1
> Opencensus metrics do not work well with Prometheus
> ---
>
> Key: IGNITE-17398
> URL: https://issues.apache.org/jira/browse/IGNITE-17398
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
>
> The metrics created by the new metrics system are very inconvenient to use
> with Prometheus since it does not use tags.
> For example, Spring metric generated for the same cache looks like the
> following in Prometheus and is very convenient to use:
>
> {noformat}
> cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
> 1387.0{noformat}
>
> The native Ignite metric looks like the following:
>
> {noformat}
> cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
> The Spring reported statistics can be easily filtered by cache name and other
> attributes, while the build-in Ignite metrics do not provide an easy way to
> access cache names. The only option seems to be parsing the
> "cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by
> Grafana.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17398) Opencensus metrics do not work well with Prometheus
Sergey Kadaner created IGNITE-17398:
---
Summary: Opencensus metrics do not work well with Prometheus
Key: IGNITE-17398
URL: https://issues.apache.org/jira/browse/IGNITE-17398
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Kadaner
The metrics created by the new metrics system are very inconvenient to use with
Prometheus since it does not use tags.
For example, Spring metric generated for the same cache looks like the
following in Prometheus and is very convenient to use:
{noformat}
cache_gets_total{cache="MY_CACHE_NAME",name="MY_CACHE_NAME",result="hit",}
1387.0{noformat}
The native Ignite metric looks like the following:
{noformat}
cache_MY_CACHE_NAME_CacheHits 1387.0{noformat}
The Spring reported statistics can be easily filtered by cache name and other
attributes, while the build-in Ignite metrics do not provide an easy way to
access cache names. The only option seems to be parsing the
"cache_MY_CACHE_NAME_CacheHits" strings which AFAIK is not supported by Grafana.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17538282#comment-17538282
]
Sergey Kadaner edited comment on IGNITE-9878 at 5/17/22 3:30 PM:
-
I am getting the same error while retrieving a cache by name from the
SpringCacheManager. What does this error mean?
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
myCacheName
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356)
~[ignite-spring-2.9.1.jar:2.9.1]{noformat}
was (Author: sergeykad):
I am getting the same error while retrieving a cache by name from the
SpringCacheManager:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
myCacheName
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356)
~[ignite-spring-2.9.1.jar:2.9.1]{noformat}
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java, NearCacheTest.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[
https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17538282#comment-17538282
]
Sergey Kadaner commented on IGNITE-9878:
I am getting the same error while retrieving a cache by name from the
SpringCacheManager:
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to start near cache (local node is an affinity node for cache):
myCacheName
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376)
~[ignite-core-2.9.1.jar:2.9.1]
at
org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356)
~[ignite-spring-2.9.1.jar:2.9.1]{noformat}
> Failed to start near cache after second call of getOrCreateCache
>
>
> Key: IGNITE-9878
> URL: https://issues.apache.org/jira/browse/IGNITE-9878
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: NearCacheIssueReproducer.java, NearCacheTest.java
>
>
> Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg,
> NearCacheConfiguration nearCfg)` lead the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (local node is an affinity node for cache):
> ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (local node is an affinity node for cache): ignite-test-near-rep
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983)
> ... 23 more
> {code}
> Also, if a cache is specified in the IgniteConfiguration,
> `Ignite#getOrCreateNearCache` will fail with the following exception:
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to start near cache (a cache with the same name without near cache is
> already started)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072)
> at
> org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> near cache (a cache with the same name without near cache is already started)
> at
> org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067)
> ... 23 more
> {code}
> The test is attached [^NearCacheIssueReproducer.java]. The workaround is to
> put near cache config into cache configuration
> `CacheConfiguration.setNearConfiguration`.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16941) Spring Cache integration does not expose statistics via Spring's CacheMeterBinderProvider
[ https://issues.apache.org/jira/browse/IGNITE-16941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kadaner updated IGNITE-16941: Description: Exposing cache statistics is an important part of Spring Cache integration. You can see [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] a number of existing implementations. I am trying to implement it myself, but I am supposed to write a class that implements CacheMeterBinderProvider, but unfortunately the 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's Cache interface is package protected. There is a simple example here of implementing the CacheMeterBinderProvider: [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] was: Exposing cache statistics is an important part of Spring Cache integration. You can see [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] a number of existing implementations. I suspect that the missing Ignite integration can be connected to the fact that 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's Cache interface is package protected. There is a simple example here of implementing the CacheMeterBinderProvider: [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934|https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] > Spring Cache integration does not expose statistics via Spring's > CacheMeterBinderProvider > - > > Key: IGNITE-16941 > URL: https://issues.apache.org/jira/browse/IGNITE-16941 > Project: Ignite > Issue Type: Improvement > Components: cache, extensions, integrations, spring >Affects Versions: 2.9.1 >Reporter: Sergey Kadaner >Priority: Major > > Exposing cache statistics is an important part of Spring Cache integration. > You can see > [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] > a number of existing implementations. > I am trying to implement it myself, but I am supposed to write a class that > implements CacheMeterBinderProvider, but unfortunately the > 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's > Cache interface is package protected. > There is a simple example here of implementing the CacheMeterBinderProvider: > [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16941) Spring Cache integration does not expose statistics via Spring's CacheMeterBinderProvider
[ https://issues.apache.org/jira/browse/IGNITE-16941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kadaner updated IGNITE-16941: Description: Exposing cache statistics is an important part of Spring Cache integration. You can see [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] a number of existing implementations. I suspect that the missing Ignite integration can be connected to the fact that 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's Cache interface is package protected. There is a simple example here of implementing the CacheMeterBinderProvider: [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934|https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] was: Exposing cache statistics is an important part of Spring Cache integration. You can see [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] a number of existing implementations. I suspect that the missing Ignite integration can be connected to the fact that 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's Cache interface is package protected. There is a simple example here of implementing the CacheMeterBinderProvider: [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934|CacheMeterBinderProvider] > Spring Cache integration does not expose statistics via Spring's > CacheMeterBinderProvider > - > > Key: IGNITE-16941 > URL: https://issues.apache.org/jira/browse/IGNITE-16941 > Project: Ignite > Issue Type: Improvement > Components: cache, extensions, integrations, spring >Affects Versions: 2.9.1 >Reporter: Sergey Kadaner >Priority: Major > > Exposing cache statistics is an important part of Spring Cache integration. > You can see > [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] > a number of existing implementations. I suspect that the missing Ignite > integration can be connected to the fact that > 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's > Cache interface is package protected. > > There is a simple example here of implementing the CacheMeterBinderProvider: > [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934|https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16941) Spring Cache integration does not expose statistics via Spring's CacheMeterBinderProvider
Sergey Kadaner created IGNITE-16941: --- Summary: Spring Cache integration does not expose statistics via Spring's CacheMeterBinderProvider Key: IGNITE-16941 URL: https://issues.apache.org/jira/browse/IGNITE-16941 Project: Ignite Issue Type: Improvement Components: cache, extensions, integrations, spring Affects Versions: 2.9.1 Reporter: Sergey Kadaner Exposing cache statistics is an important part of Spring Cache integration. You can see [here|https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/actuate/metrics/cache/package-summary.html] a number of existing implementations. I suspect that the missing Ignite integration can be connected to the fact that 'org.apache.ignite.cache.spring.SpringCache' that implements the Spring's Cache interface is package protected. There is a simple example here of implementing the CacheMeterBinderProvider: [https://medium.com/@iliamsharipov_56660/spring-boot-actuator-for-concurrentmapcache-2c7f0d290934|CacheMeterBinderProvider] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Issue Comment Deleted] (IGNITE-14063) Error: Failed to get java major version (unknown 'java.version' format) [ver=14-ea]
[
https://issues.apache.org/jira/browse/IGNITE-14063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-14063:
Comment: was deleted
(was: The full stack trace is:
{noformat}
java.lang.NullPointerException: Cannot invoke
"intelligence360.dal.datatypes.response.InsertResponse.getStatus()" because
"response" is null
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:55)
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:29)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:151)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:38)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.runOnMessage(MessageConsumer.java:246)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.handleConsumerRecord(MessageConsumer.java:227)
at
org.springframework.kafka.listener.AcknowledgingMessageListener.onMessage(AcknowledgingMessageListener.java:33)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeOnMessage(KafkaMessageListenerContainer.java:2148)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeOnMessage(KafkaMessageListenerContainer.java:2120)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeRecordListener(KafkaMessageListenerContainer.java:2039)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeWithRecords(KafkaMessageListenerContainer.java:1967)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeRecordListener(KafkaMessageListenerContainer.java:1853)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeListener(KafkaMessageListenerContainer.java:1543)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.pollAndInvoke(KafkaMessageListenerContainer.java:1190)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.run(KafkaMessageListenerContainer.java:1087)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:832){noformat}
)
> Error: Failed to get java major version (unknown 'java.version' format)
> [ver=14-ea]
> ---
>
> Key: IGNITE-14063
> URL: https://issues.apache.org/jira/browse/IGNITE-14063
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
>
> Running Ignite client on Java 14 results in the following error from
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager
> _Failed to get java major version (unknown 'java.version' format) [ver=14-ea]_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14063) Error: Failed to get java major version (unknown 'java.version' format) [ver=14-ea]
[
https://issues.apache.org/jira/browse/IGNITE-14063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17399347#comment-17399347
]
Sergey Kadaner edited comment on IGNITE-14063 at 8/29/21, 6:19 AM:
---
The full stack trace is:
{noformat}
java.lang.NullPointerException: Cannot invoke
"intelligence360.dal.datatypes.response.InsertResponse.getStatus()" because
"response" is null
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:55)
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:29)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:151)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:38)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.runOnMessage(MessageConsumer.java:246)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.handleConsumerRecord(MessageConsumer.java:227)
at
org.springframework.kafka.listener.AcknowledgingMessageListener.onMessage(AcknowledgingMessageListener.java:33)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeOnMessage(KafkaMessageListenerContainer.java:2148)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeOnMessage(KafkaMessageListenerContainer.java:2120)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeRecordListener(KafkaMessageListenerContainer.java:2039)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeWithRecords(KafkaMessageListenerContainer.java:1967)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeRecordListener(KafkaMessageListenerContainer.java:1853)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeListener(KafkaMessageListenerContainer.java:1543)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.pollAndInvoke(KafkaMessageListenerContainer.java:1190)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.run(KafkaMessageListenerContainer.java:1087)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:832){noformat}
was (Author: sergeykad):
The full stack trace is:
{noformat}
java.lang.NullPointerException: Cannot invoke
"intelligence360.dal.datatypes.response.InsertResponse.getStatus()" because
"response" is null
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:55)
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:29)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:151)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:38)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.runOnMessage(MessageConsumer.java:246)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.handleConsumerRecord(MessageConsumer.java:227)
at
org.springframework.kafka.listener.AcknowledgingMessageListener.onMessage(AcknowledgingMessageListener.java:33)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeOnMessage(KafkaMessageListenerContainer.java:2148)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeOnMessage(KafkaMessageListenerContainer.java:2120)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeRecordListener(KafkaMessageListenerContainer.java:2039)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeWithRecords(KafkaMessageListenerContainer.java:1967)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeRecordListener(KafkaMessageListenerContainer.java:1853)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeListener(KafkaMessageListenerContainer.java:1543)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.pollAndInvoke(KafkaMessageListenerContainer.java:1190)
at
[jira] [Created] (IGNITE-15334) Incorrect detection of multiple grid instances
Sergey Kadaner created IGNITE-15334:
---
Summary: Incorrect detection of multiple grid instances
Key: IGNITE-15334
URL: https://issues.apache.org/jira/browse/IGNITE-15334
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Sergey Kadaner
The IgnitionEx class has a validation that checks if SPI supports multiple grid
instances. However, the following code is used to check if it is a single
instance:
{code:java}
startCtx.single(grids.size() == 1);
{code}
In my case the grid size is zero, therefore startCtx.single is false which
triggers an error for SPI that does not support multiple instances.
IMHO the the following code should be used instead:
{code:java}
startCtx.single(grids.size() < 2);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14063) Error: Failed to get java major version (unknown 'java.version' format) [ver=14-ea]
[
https://issues.apache.org/jira/browse/IGNITE-14063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17399347#comment-17399347
]
Sergey Kadaner commented on IGNITE-14063:
-
The full stack trace is:
{noformat}
java.lang.NullPointerException: Cannot invoke
"intelligence360.dal.datatypes.response.InsertResponse.getStatus()" because
"response" is null
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:55)
at
intelligence360.dal.primaries.monitor.db.DalMonitorHandler.handleMsg(DalMonitorHandler.java:29)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:151)
at
intelligence360.skeleton.kafka.consumers.SkeletonConsumersMessageLogic.onMessage(SkeletonConsumersMessageLogic.java:38)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.runOnMessage(MessageConsumer.java:246)
at
intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer.handleConsumerRecord(MessageConsumer.java:227)
at
org.springframework.kafka.listener.AcknowledgingMessageListener.onMessage(AcknowledgingMessageListener.java:33)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeOnMessage(KafkaMessageListenerContainer.java:2148)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeOnMessage(KafkaMessageListenerContainer.java:2120)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeRecordListener(KafkaMessageListenerContainer.java:2039)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeWithRecords(KafkaMessageListenerContainer.java:1967)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeRecordListener(KafkaMessageListenerContainer.java:1853)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeListener(KafkaMessageListenerContainer.java:1543)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.pollAndInvoke(KafkaMessageListenerContainer.java:1190)
at
org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.run(KafkaMessageListenerContainer.java:1087)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:832){noformat}
[https://kibana-logs.intel360.gamma.projects.e-bitbox.com/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:'2021-08-15T06:42:02.998Z',to:'2021-08-15T06:49:21.100Z'))&_a=(columns:!(_source),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:'logs*',key:level,negate:!t,params:(query:INFO),type:phrase),query:(match_phrase:(level:INFO))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:'logs*',key:service_name,negate:!f,params:(query:dal-monitor),type:phrase),query:(match_phrase:(service_name:dal-monitor))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:'logs*',key:logger_name,negate:!f,params:(query:intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer),type:phrase),query:(match_phrase:(logger_name:intelligence360.infrastructure.kafka.spring.consumers.MessageConsumer))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:'logs*',key:line_number,negate:!f,params:(query:'272'),type:phrase),query:(match_phrase:(line_number:'272',index:'logs*',interval:auto,query:(language:kuery,query:''),sort:!())]
> Error: Failed to get java major version (unknown 'java.version' format)
> [ver=14-ea]
> ---
>
> Key: IGNITE-14063
> URL: https://issues.apache.org/jira/browse/IGNITE-14063
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
>
> Running Ignite client on Java 14 results in the following error from
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager
> _Failed to get java major version (unknown 'java.version' format) [ver=14-ea]_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14888) IgniteJdbcThinDriver fails to initialize on Java 16
[
https://issues.apache.org/jira/browse/IGNITE-14888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-14888:
Description:
I am getting the following error on Java 16:
{code:java}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.IgniteJdbcThinDriver
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:466)
at
java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
at
java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:547)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:449)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:426)
at
com.zaxxer.hikari.util.DriverDataSource.(DriverDataSource.java:60)
{code}
I am not even trying to use the JDBC driver. Unfortunately, Hikari performs
Class.forName() on all JDBC drivers in the classpath, and I have a dependency
on ignite-core.jar. The jar is part of the Java thick client.
Currently, this issue prevents me from upgrading to Java 16
was:
I am getting the following error on Java 16:
{code:java}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.IgniteJdbcThinDriver
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:466)
at
java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
at
java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:547)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:449)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:426)
at
com.zaxxer.hikari.util.DriverDataSource.(DriverDataSource.java:60)
{code}
I am not even trying to use the JDBC driver. Unfortunately, Hikari performs
Class.forName() on all JDBC drivers in the classpath, and I have a dependency
on ignite-core.jar
Currently, this issue prevents me from upgrading to Java 16
> IgniteJdbcThinDriver fails to initialize on Java 16
> ---
>
> Key: IGNITE-14888
> URL: https://issues.apache.org/jira/browse/IGNITE-14888
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
>
> I am getting the following error on Java 16:
> {code:java}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.ignite.IgniteJdbcThinDriver
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:466)
> at
> java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
> at
> java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:547)
> at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:449)
> at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:426)
> at
> com.zaxxer.hikari.util.DriverDataSource.(DriverDataSource.java:60)
> {code}
> I am not even trying to use the JDBC driver. Unfortunately, Hikari performs
> Class.forName() on all JDBC drivers in the classpath, and I have a dependency
> on ignite-core.jar. The jar is part of the Java thick client.
> Currently, this issue prevents me from upgrading to Java 16
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14891) Support Next Java LTS (Java 17)
Sergey Kadaner created IGNITE-14891: --- Summary: Support Next Java LTS (Java 17) Key: IGNITE-14891 URL: https://issues.apache.org/jira/browse/IGNITE-14891 Project: Ignite Issue Type: Improvement Reporter: Sergey Kadaner Next Java LTS is right around the corner and many projects already started working on supporting it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14888) IgniteJdbcThinDriver fails to initialize on Java 16
[
https://issues.apache.org/jira/browse/IGNITE-14888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kadaner updated IGNITE-14888:
Summary: IgniteJdbcThinDriver fails to initialize on Java 16 (was:
IgniteJdbcThinDriver fails to instantiate on Java 16)
> IgniteJdbcThinDriver fails to initialize on Java 16
> ---
>
> Key: IGNITE-14888
> URL: https://issues.apache.org/jira/browse/IGNITE-14888
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.9.1
>Reporter: Sergey Kadaner
>Priority: Major
>
> I am getting the following error on Java 16:
> {code:java}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.ignite.IgniteJdbcThinDriver
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:466)
> at
> java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
> at
> java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:547)
> at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:449)
> at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:426)
> at
> com.zaxxer.hikari.util.DriverDataSource.(DriverDataSource.java:60)
> {code}
> I am not even trying to use the JDBC driver. Unfortunately, Hikari performs
> Class.forName() on all JDBC drivers in the classpath, and I have a dependency
> on ignite-core.jar
> Currently, this issue prevents me from upgrading to Java 16
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14888) IgniteJdbcThinDriver fails to instantiate on Java 16
Sergey Kadaner created IGNITE-14888:
---
Summary: IgniteJdbcThinDriver fails to instantiate on Java 16
Key: IGNITE-14888
URL: https://issues.apache.org/jira/browse/IGNITE-14888
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 2.9.1
Reporter: Sergey Kadaner
I am getting the following error on Java 16:
{code:java}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.IgniteJdbcThinDriver
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:466)
at
java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
at
java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:547)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:449)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:426)
at
com.zaxxer.hikari.util.DriverDataSource.(DriverDataSource.java:60)
{code}
I am not even trying to use the JDBC driver. Unfortunately, Hikari performs
Class.forName() on all JDBC drivers in the classpath, and I have a dependency
on ignite-core.jar
Currently, this issue prevents me from upgrading to Java 16
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14063) Error: Failed to get java major version (unknown 'java.version' format) [ver=14-ea]
Sergey Kadaner created IGNITE-14063: --- Summary: Error: Failed to get java major version (unknown 'java.version' format) [ver=14-ea] Key: IGNITE-14063 URL: https://issues.apache.org/jira/browse/IGNITE-14063 Project: Ignite Issue Type: Bug Affects Versions: 2.9.1 Reporter: Sergey Kadaner Running Ignite client on Java 14 results in the following error from org.apache.ignite.internal.managers.discovery.GridDiscoveryManager _Failed to get java major version (unknown 'java.version' format) [ver=14-ea]_ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14031) Add Docker images based on Java 11
Sergey Kadaner created IGNITE-14031: --- Summary: Add Docker images based on Java 11 Key: IGNITE-14031 URL: https://issues.apache.org/jira/browse/IGNITE-14031 Project: Ignite Issue Type: Improvement Reporter: Sergey Kadaner Since Java 11 support was added in https://issues.apache.org/jira/browse/IGNITE-11189 it should be possible to create Docker images as well. This will allow usage of TLSv1.3 and make _‑Djdk.tls.client.protocols=TLSv1.2_ JVM parameter unnecessary on thick clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14014) Insufficient documentation and examples for ignite-spring-boot-autoconfigure-ext
Sergey Kadaner created IGNITE-14014: --- Summary: Insufficient documentation and examples for ignite-spring-boot-autoconfigure-ext Key: IGNITE-14014 URL: https://issues.apache.org/jira/browse/IGNITE-14014 Project: Ignite Issue Type: Bug Components: spring Affects Versions: 2.9.1 Reporter: Sergey Kadaner I tried following the example on the documentation page linked below but it covers only a small subset of Ignite configuration options. I tried guessing how to configure an IP finder and a near cache with an eviction policy, but without any success. To make matters worse incorrect configuration is usually silently ignored. https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-boot#set-ignite-up-via-spring-boot-configuration -- This message was sent by Atlassian Jira (v8.3.4#803005)
