First off, thanks to you and Zhenya for your support
I'm afraid that's not easy, as key's data are unrelated.
As we are in an evaluation phase, we would prefer to wait for the fix and
perform single node benchmarking in the meanwhile... Instead of grouping
keys, we might split the big transactio
Hello,
There are no public methods to calculate CacheConfiguration size.
As Pavel already said all versions of the client compatible with all
versions of the server, the features set will be determined by the highest
common version.
Here is the feature compatibility list for the java thin client
hi, check these links.
[1] https://ignite.apache.org/docs/latest/monitoring-metrics/metrics
[2]
https://www.zylk.net/en/web-2-0/blog/-/blogs/kibana-dashboard-for-monitoring-liferay-jvm-via-jmx
>Hi Zhenya,
>
>It seems those events are not so useful as you suggest, [2]
>In the case of [1], h
Josemari, can you please describe the use case in more detail?
Maybe it is possible to reduce the number of cache entries by combining the
data from multiple keys into one?
On Fri, Jan 29, 2021 at 7:01 AM Zhenya Stanilovsky
wrote:
>
> I also confirm this issue, i will append additional info into
Hi Zhenya,
It seems those events are not so useful as you suggest, [2]
In the case of [1], how are these events accessible from a C# Ignite client?
We don't currently use zabbix, but do use fluentd/kibana.
Thanks,
Raymond.
On Fri, Jan 29, 2021 at 4:54 PM Zhenya Stanilovsky
wrote:
>
> hi ! h
thank you for quick reply
here is some part of my query it is longer then this but rest also same with
small change
SELECT 'FreeSql' AS FIRST_TABLE_NAME, nvl(to_char(a.id),'') AS
FIRST_TABLE_KEYS, 'id' AS FIRST_KEY_1,
null AS FIRST_KEY_2, null AS FIRST_KEY_3, 'user_id' AS FIRST_COLUMN,'null'
AS
I also confirm this issue, i will append additional info into ticket, seems we
can fix it.
jjimeno thanks for highlighting. The only work around for now — is somehow
decrease tx enlisted keys.
>I am able to reproduce the problem - it occurs with any client, thick or thin.
>
>With one node t
hi ! hope this would be helpful [1].
Mentioned events is other one [2] = not useful for you.
Also zabbix can parse the logs, you can obtain all cp info there.
[1] https://issues.apache.org/jira/browse/IGNITE-13845
[2]
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/ch
Dear Igniters,
Could someone please clarify if it is guaranteed that the Affinity
(GridCacheAffinityImpl) will have the most up-to-date information about
partitions distribution and the following scenario is impossible:
1. We have a registered listener of EVT_CACHE_REBALANCE_PART_LOADED and
Hi,
QueryParallelism only help in certain specific instances(queries with
table scans and aggregations). Described more here:
https://ignite.apache.org/docs/latest/SQL/sql-tuning#query-parallelism
The best way to speed up your query is to add appropriate indexes, and if
you are using a clust
I want to make my system detect when a check point has occurred for
monitoring and control purposes.
I found the following events defined in the IA source:
/**
* All checkpoint events. This array can be directly passed into
* {@link IgniteEvents#localListen(IgnitePredicate, int...)}
We have been continuing to monitor this issue and have experimented more
with deactivation versus Ingition.Stop(). There is some evidence that using
graceful shutdown does not perform a checkpoint in that startup times are
not necessarily improved on restart. We'll continue to investigate this but
hello all
My application running sql queries on db and then put the result on ignite
cache. Then I query these data from ignite cache. But the query that I run
on ignite cache taking too much time depending on my data. when I monitor my
system while running queries on ignite cache I realize that c
hello all
My application running sql queries on db and then put the result on ignite
cache. Then I query these data from ignite cache. But the query that I run
on ignite cache taking too much time depending on my data. when I monitor my
system while running queries on ignite cache I realize that c
Hi Val,
throughout the meetings, you are positioning Ignite as a distributed
database. The recent changes have brought the following description of
Ignite: "Distributed Database For High-Performance Computing With In-Memory
Speed".
During the recent meetings, you have shown us examples of Ignite
So we fixed it like this
private static String fixEntityName(Function
nameToTypeId, String name) {
String result = name;
while ((nameToTypeId.apply(result) & 0x00FF) == 103) {
result = "x" + result;
}
Ilya,
Normally you can use any combination of thin client and server versions,
the highest common protocol version is negotiated automatically
during the handshake.
There are some exceptions to this - not all thin clients support very old
protocols,
but with recent versions it should work.
On Th
Hello Ilya,
if use sqlline execute sql,the feedback result of the following
statement is correct.
SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
I used SqlFieldsQuery again to do the above tests, and the results were
all 0. I think there may be a issue in this.
在 2021/1/28
Hello!
I don't think you can use a more recent version of thin client with older
server version.
New thin client features usually require support from the server side as
well.
Regards,
--
Ilya Kasnacheev
ср, 27 янв. 2021 г. в 21:45, jjimeno :
> Hello,
>
> Thanks for your answer.
> The server
Hello!
I think these metrics will be gathered for ScanQuery/SqlFieldsQuery
executed via native Java Query API, but they will not be gathered for
statements executed via JDBC.
One obvious reason is that Java Query API's queries are bound to a specific
cache. JDBC query is not bound to specific cac
I am able to reproduce the problem - it occurs with any client, thick or
thin.
With one node the transaction completes in a reasonable time,
but with two nodes it is orders of magnitude slower.
We'll investigate and get back to you.
On Thu, Jan 28, 2021 at 9:48 AM jjimeno wrote:
> Hi again,
>
21 matches
Mail list logo
