Hi again,
As a test, I just disabled persistence in both nodes. The already mentioned
transaction of 1.2 million keys and 600MB in size takes 298sec.
Remember that for one single node and persistence enabled it takes 70sec, so
just adding a second node makes the test more than 4 times slower.
Hello,
I know SQL_ QUERIES and SQL_ QUERY_ HISTORY.
I opened *org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi* in
the configuration file
A new METRICS view will be added.
在 2021/1/28 上午7:02, akorensh 写道:
Hi, there is not a view called metrics, only node_metrics, see below
Here are
Hi, there is not a view called metrics, only node_metrics, see below
Here are the docs for those views:
https://ignite.apache.org/docs/latest/monitoring-metrics/system-views
Looks like you might be referring to an SQL view, in which case there is a
realtime one which will only show values when t
Hello,
Thanks for your answer.
The server is already in version 2.9.1 and the c++ thin client is from
master branch to get transactions support.
José
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Here's the stacktrace:
org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
version: 43
BinaryUtils checkProtocolVersion798
org.apache.ignite.internal.binary.BinaryUtils in BinaryUtils.java
BinaryReaderExImpl221
org.ap
Hello,
I understand these deadlocks when there are more than one PuAll at the same
time, but in this case there is only one, and it’s always sorted.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hello,
Can you please share your stacktrace? In 2.7.6 I think this bug
affects only cache configuration retrieval and binary metadata retrieval.
To avoid problems with binary metadata retrieval you should not use types
which typeId (IgniteClient.binary().typeId()) starts with byte 103 as cache
key
> how a deadlock is possible if keys are no repeated
Deadlock is possible when two putAll operations are executed
at the same time on the same keys, but key order is different in the
provided map.
> LinkedHashMap is used for putAll operation
> but I'm using a c++ std::map
Unfortunately, this warni
Hello everyone.
I'm having an issue that appears randomly on my internal product testing.
Looks like its related to https://issues.apache.org/jira/browse/IGNITE-13401
but the stacktrace looks different.
Basically I'm building a BinaryObject which ends up fetching
BinaryObjectMetadata from the serv
Hello! Ok... thanks Ilya!
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
2. I've found this:
[16:02:23,836][WARNING][client-connector-#139][GridDhtColocatedCache]
Unordered map java.util.LinkedHashMap is used for putAll operation on cache
vds. This can lead to a distribut
ed deadlock. Switch to a sorted map like TreeMap instead.
... but I'm using a c++ std::map. It'
Hello!
It seems to me that you should never use messageQueueLimit - if you ever
saturate your network it will break down your cluster.
Regards,
--
Ilya Kasnacheev
ср, 27 янв. 2021 г. в 15:55, Zhenya Stanilovsky :
> 1. Yes i know about this message, don`t pay attention (just remove it). Ilya
1. Yes i know about this message, don`t pay attention (just remove it). Ilya is
this param is safe to use ?
2. plz rerun your nodes with -DIGNITE_QUIET=false jvm param (there are would be
more informative logs).
3 You have long running tx in your logs (IGNITE_QUIET will help to detect why
it ha
Hi Zhenya,
Thanks for your quick response
1. If it is not set, the following message appears on node's startup:
[13:22:33] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and
Hello Ilya,
The test method is as follows:
Start 2 nodes on the localhost.
Use the CREATE TABLE statement to create a table;
Use the COPY command to load some data;
Access to cluster through sqlline;
Execute select count (*) from T;
Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
hi jjimeno.
* I doubt about « messageQueueLimit » correctness, plz remove it and try once
more.
* 16k per page is questionable, i suggest to try with default.
* why there is no progress with 2 node? can you append somehow logs from 2
nodes with transactions degradation?
* Take into account
Hi everyone,
For our project, we have the next requirements:
- One single cache
- Ability to lock a list of cache entries.
- Large transactions. A typical one is to commit 1.2 million keys (a single
PutAll call) with a total size of around 600MB.
- Persistence
In our proof of concept, we've got
Hello!
These values are per-node, as far as I know. Is it possible that you have
connected to a node which does not handle any queries (as reducer, anyway)?
Regards,
--
Ilya Kasnacheev
вт, 26 янв. 2021 г. в 13:48, 38797715 <38797...@qq.com>:
> Hi,
>
> We found that SYS.METRICS View some data
Hi Andrei,
Did you get a chance to look at my comments .
Regarding doing the continuous query as per this example :
https://github.com/gridgain/gridgain/blob/master/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheContinuousQueryExample.java
Our code is pretty much as shown in
Hello!
I'm actually not sure. You can try running the same query in local mode
(query.setLocal(true)) to check if there would be any difference. However,
you will need to run it against a server node as well. When it is run
against client, the client will become reducer, connect to some server
nod
20 matches
Mail list logo
