[jira] [Updated] (IGNITE-8497) Ignite always stops the node in the middle of checkpointing upon receiving a SIGINT
[
https://issues.apache.org/jira/browse/IGNITE-8497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-8497:
--
Description:
*Steps*
Start Ignite server node with enabled PDS (see the attached
[^example-cache.xml] config file)
Activate the cluster with _./bin/control.sh --activate_
Put some data into cluster (with _CachePutGetExample.java_ for example)
Stop Ignite server node with SIGINT
*Actual result*
Ignite server node invokes the shutdown hook, checkpoint procedure starts, but
Ignite node *does not wait for checkpoint to finish* and terminates the node.
An excerpt from [^srv.1.log] :
{noformat}
[2018-05-15 15:20:59,976][INFO ][Thread-3][G] Invoking shutdown hook...
[2018-05-15 15:20:59,979][INFO ][Thread-3][GridTcpRestProtocol] Command
protocol successfully stopped: TCP binary
[2018-05-15 15:20:59,998][INFO
][db-checkpoint-thread-#50][GridCacheDatabaseSharedManager] Checkpoint started
[checkpointId=f0dde95a-6027-40dd-b3f3-4311aa8508c3, startPtr=FileWALPointer
[idx=0, fileOff=460751, len=40871], checkpointLockWait=0ms,
checkpointLockHoldTime=6ms, pages=167, reason='timeout']
[2018-05-15 15:21:00,011][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=default]
[2018-05-15 15:21:00,011][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=ignite-sys-cache]
[2018-05-15 15:21:00,012][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=CachePutGetExample]
[2018-05-15 15:21:00,049][INFO ][Thread-3][IgniteKernal]
>>> +-+
>>> Ignite ver. 2.4.0-SNAPSHOT#19700101-sha1:DEV stopped OK
>>> +-+
>>> Grid uptime: 00:00:36.228
{noformat}
When one starts the node again, the following warning appears in the log (
[^srv.2.log] ):
{noformat}
[2018-05-15 15:21:39,848][WARN ][main][GridCacheDatabaseSharedManager] Ignite
node stopped in the middle of checkpoint. Will restore memory state and finish
checkpoint on node start.
{noformat}
*Note*
Same behavior when stopping a server node via "Ignition.stop(true)" call.
was:
*Steps*
Start Ignite server node with enabled PDS (see the attached
[^example-cache.xml] config file)
Activate the cluster with _./bin/control.sh --activate_
Put some data into cluster (with _CachePutGetExample.java_ for example)
Stop Ignite server node with SIGINT
*Actual result*
Ignite server node invokes the shutdown hook, checkpoint procedure starts, but
Ignite node *does not wait for checkpoint to finish* and terminates the node.
An excerpt from [^srv.1.log] :
{noformat}
[2018-05-15 15:20:59,976][INFO ][Thread-3][G] Invoking shutdown hook...
[2018-05-15 15:20:59,979][INFO ][Thread-3][GridTcpRestProtocol] Command
protocol successfully stopped: TCP binary
[2018-05-15 15:20:59,998][INFO
][db-checkpoint-thread-#50][GridCacheDatabaseSharedManager] Checkpoint started
[checkpointId=f0dde95a-6027-40dd-b3f3-4311aa8508c3, startPtr=FileWALPointer
[idx=0, fileOff=460751, len=40871], checkpointLockWait=0ms,
checkpointLockHoldTime=6ms, pages=167, reason='timeout']
[2018-05-15 15:21:00,011][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=default]
[2018-05-15 15:21:00,011][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=ignite-sys-cache]
[2018-05-15 15:21:00,012][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=CachePutGetExample]
[2018-05-15 15:21:00,049][INFO ][Thread-3][IgniteKernal]
>>> +-+
>>> Ignite ver. 2.4.0-SNAPSHOT#19700101-sha1:DEV stopped OK
>>> +-+
>>> Grid uptime: 00:00:36.228
{noformat}
When one starts the node again, the following warning appears in the log (
[^srv.2.log] ):
{noformat}
[2018-05-15 15:21:39,848][WARN ][main][GridCacheDatabaseSharedManager] Ignite
node stopped in the middle of checkpoint. Will restore memory state and finish
checkpoint on node start.
{noformat}
> Ignite always stops the node in the middle of checkpointing upon receiving a
> SIGINT
> ---
>
> Key: IGNITE-8497
> URL: https://issues.apache.org/jira/browse/IGNITE-8497
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
> Environment: Ubuntu 17.10
>Reporter: Ivan Artukhov
>Priority: Minor
> Attachments: example-cache.xml, srv.1.log, srv.2.log
>
>
> *Steps*
> Start Ignite server node with enabled PDS (see the attached
> [^example-cache.xml] config file)
> Activate the cluster with _./bin/control.sh --activate_
> Put some data into cluster (with _CachePutGetExample.java_ for example)
> Stop Ignite server node with SIGINT
> *Actual result*
> Ignite server node invokes the shutdown hook, checkpoint procedure
[jira] [Created] (IGNITE-8497) Ignite stops the node in the middle of checkpointing upon receiving a SIGINT
Ivan Artukhov created IGNITE-8497:
-
Summary: Ignite stops the node in the middle of checkpointing upon
receiving a SIGINT
Key: IGNITE-8497
URL: https://issues.apache.org/jira/browse/IGNITE-8497
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.4
Environment: Ubuntu 17.10
Reporter: Ivan Artukhov
Attachments: example-cache.xml, srv.1.log, srv.2.log
*Steps*
Start Ignite server node with enabled PDS (see the attached
[^example-cache.xml] config file)
Activate the cluster with _./bin/control.sh --activate_
Put some data into cluster (with _CachePutGetExample.java_ for example)
Stop Ignite server node with SIGINT
*Actual result*
Ignite server node invokes the shutdown hook, checkpoint procedure starts, but
Ignite node *does not wait for checkpoint to finish* and terminates the node.
An excerpt from [^srv.1.log] :
{noformat}
[2018-05-15 15:20:59,976][INFO ][Thread-3][G] Invoking shutdown hook...
[2018-05-15 15:20:59,979][INFO ][Thread-3][GridTcpRestProtocol] Command
protocol successfully stopped: TCP binary
[2018-05-15 15:20:59,998][INFO
][db-checkpoint-thread-#50][GridCacheDatabaseSharedManager] Checkpoint started
[checkpointId=f0dde95a-6027-40dd-b3f3-4311aa8508c3, startPtr=FileWALPointer
[idx=0, fileOff=460751, len=40871], checkpointLockWait=0ms,
checkpointLockHoldTime=6ms, pages=167, reason='timeout']
[2018-05-15 15:21:00,011][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=default]
[2018-05-15 15:21:00,011][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=ignite-sys-cache]
[2018-05-15 15:21:00,012][INFO ][Thread-3][GridCacheProcessor] Stopped cache
[cacheName=CachePutGetExample]
[2018-05-15 15:21:00,049][INFO ][Thread-3][IgniteKernal]
>>> +-+
>>> Ignite ver. 2.4.0-SNAPSHOT#19700101-sha1:DEV stopped OK
>>> +-+
>>> Grid uptime: 00:00:36.228
{noformat}
When one starts the node again, the following warning appears in the log (
[^srv.2.log] ):
{noformat}
[2018-05-15 15:21:39,848][WARN ][main][GridCacheDatabaseSharedManager] Ignite
node stopped in the middle of checkpoint. Will restore memory state and finish
checkpoint on node start.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8322) Yardstick benchmark preloading option
[ https://issues.apache.org/jira/browse/IGNITE-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515672#comment-16515672 ] Ivan Artukhov commented on IGNITE-8322: --- Now the new *Loader.java* class fails to get _DataRegionConfiguration_ if it is not explicitly set for a given cache. Why not to try to get data region configuration from _defaultDataRegionConfiguration_ property in this case? > Yardstick benchmark preloading option > - > > Key: IGNITE-8322 > URL: https://issues.apache.org/jira/browse/IGNITE-8322 > Project: Ignite > Issue Type: Improvement >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin >Priority: Major > Fix For: 2.6 > > > Yardstick has no benchmarks with eviction on the disk (PDS). For that puspose > we need following: > 1. Make new configuration and put every cache into a separate date region: > atomic,tx,atomic-index,query,compute > 2. Add a new preload option for a benchmark: preload up to a size passed from > that option. There two options: > * total size of preload data (bytes) > * the size of data in memory against total size (percent) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8733) Add benchmarks for NodeJS thin client
[ https://issues.apache.org/jira/browse/IGNITE-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512049#comment-16512049 ] Ivan Artukhov commented on IGNITE-8733: --- There is a thread [1] on dev list with the benchmark prototype. [1] http://apache-ignite-developers.2346864.n4.nabble.com/NodeJS-thin-client-full-API-td30348.html > Add benchmarks for NodeJS thin client > - > > Key: IGNITE-8733 > URL: https://issues.apache.org/jira/browse/IGNITE-8733 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Affects Versions: 2.5 >Reporter: Ilya Suntsov >Priority: Major > > We have several benchmarks for Java thin client > ([PR|https://github.com/apache/ignite/pull/3942]). The same set should be > implemented on NodeJS -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8807) Apache Ignite Linux packages 2.6 update
[
https://issues.apache.org/jira/browse/IGNITE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517870#comment-16517870
]
Ivan Artukhov commented on IGNITE-8807:
---
Peter, thank you for contribution! I've tested DEB and RPM on Centos 7, Ubuntu
18.04, Ubuntu 16.04 and found that clean 2.6 install as well as upgrading from
2.5 to 2.6 works well. Only two minor issues:
1) It would be better to use _mkdir -p_ in _name.service_to avoid messages like
this upon service start:
{noformat}
Jun 19 07:25:33 localhost.localdomain mkdir[2815]: /usr/bin/mkdir: cannot
create directory <80><98>/var/run/apache-ignite<80><99>: File exists
{noformat}
2) There is a bunch of messages like this upon upgrading from 2.5 to 2.6:
{noformat}
...
ownership of '/var/lib/apache-ignite/binary_meta' retained as ignite:ignite
ownership of '/var/lib/apache-ignite/marshaller' retained as ignite:ignite
ownership of '/var/lib/apache-ignite/log' retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache/index.bin'
retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache/cache_data.dat'
retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache'
retained as ignite:ignite
...
{noformat}
I.e. when persistence enabled, there will be a line for every file in _db_
directory. Usually the number of such files a very high which will result in
overwhelmed output to console upon upgrading.
> Apache Ignite Linux packages 2.6 update
> ---
>
> Key: IGNITE-8807
> URL: https://issues.apache.org/jira/browse/IGNITE-8807
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.6
>
>
> Update RPM and DEB packages' specifications for 2.6 release.
> h3. How to test
> ([artifacts|https://ci.ignite.apache.org/viewLog.html?buildId=1390464=Releases_NightlyRelease_ApacheIgniteNightlyRelease3AssemblePackages=artifacts])
> # Bare linux RPM / DEB installation.
> # Bare linux RPM / DEB upgrade (from all versions).
> # Windows 10 WSL Ubuntu DEB installation and upgrade.
> # Windows 10 WSL Debian DEB installation and upgrade.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8807) Apache Ignite Linux packages 2.6 update
[
https://issues.apache.org/jira/browse/IGNITE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517870#comment-16517870
]
Ivan Artukhov edited comment on IGNITE-8807 at 6/20/18 7:11 AM:
Peter, thank you for contribution! I've tested DEB and RPM on Centos 7, Ubuntu
18.04, Ubuntu 16.04 and found that clean 2.6 install as well as upgrading from
2.5 to 2.6 works well. Only two minor issues:
1) It would be better to use _mkdir -p_ in _name.service_ to avoid messages
like this upon service start:
{noformat}
Jun 19 07:25:33 localhost.localdomain mkdir[2815]: /usr/bin/mkdir: cannot
create directory <80><98>/var/run/apache-ignite<80><99>: File exists
{noformat}
2) There is a bunch of messages like this upon upgrading from 2.5 to 2.6:
{noformat}
...
ownership of '/var/lib/apache-ignite/binary_meta' retained as ignite:ignite
ownership of '/var/lib/apache-ignite/marshaller' retained as ignite:ignite
ownership of '/var/lib/apache-ignite/log' retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache/index.bin'
retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache/cache_data.dat'
retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache'
retained as ignite:ignite
...
{noformat}
I.e. when persistence enabled, there will be a line for every file in _db_
directory. Usually the number of such files a very high which will result in
overwhelmed output to console upon upgrading.
was (Author: artukhov):
Peter, thank you for contribution! I've tested DEB and RPM on Centos 7, Ubuntu
18.04, Ubuntu 16.04 and found that clean 2.6 install as well as upgrading from
2.5 to 2.6 works well. Only two minor issues:
1) It would be better to use _mkdir -p_ in _name.service_to avoid messages like
this upon service start:
{noformat}
Jun 19 07:25:33 localhost.localdomain mkdir[2815]: /usr/bin/mkdir: cannot
create directory <80><98>/var/run/apache-ignite<80><99>: File exists
{noformat}
2) There is a bunch of messages like this upon upgrading from 2.5 to 2.6:
{noformat}
...
ownership of '/var/lib/apache-ignite/binary_meta' retained as ignite:ignite
ownership of '/var/lib/apache-ignite/marshaller' retained as ignite:ignite
ownership of '/var/lib/apache-ignite/log' retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache/index.bin'
retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache/cache_data.dat'
retained as ignite:ignite
ownership of
'/var/lib/apache-ignite/db/node00-f06ace12-603f-4e17-ba4f-67d8110fd1e7/cache-ignite-sys-cache'
retained as ignite:ignite
...
{noformat}
I.e. when persistence enabled, there will be a line for every file in _db_
directory. Usually the number of such files a very high which will result in
overwhelmed output to console upon upgrading.
> Apache Ignite Linux packages 2.6 update
> ---
>
> Key: IGNITE-8807
> URL: https://issues.apache.org/jira/browse/IGNITE-8807
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.6
>
>
> Update RPM and DEB packages' specifications for 2.6 release.
> h3. How to test
> ([artifacts|https://ci.ignite.apache.org/viewLog.html?buildId=1390464=Releases_NightlyRelease_ApacheIgniteNightlyRelease3AssemblePackages=artifacts])
> # Bare linux RPM / DEB installation.
> # Bare linux RPM / DEB upgrade (from all versions).
> # Windows 10 WSL Ubuntu DEB installation and upgrade.
> # Windows 10 WSL Debian DEB installation and upgrade.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9144) A client node leaving a grid may trigger the wrong message about coordinator change in the logs
Ivan Artukhov created IGNITE-9144:
-
Summary: A client node leaving a grid may trigger the wrong
message about coordinator change in the logs
Key: IGNITE-9144
URL: https://issues.apache.org/jira/browse/IGNITE-9144
Project: Ignite
Issue Type: Bug
Reporter: Ivan Artukhov
The issue was introduced by https://issues.apache.org/jira/browse/IGNITE-8738.
Suppose we have a grid with X server nodes and Y client nodes. Server nodes are
restarted periodically while client nodes are left untouched. In this case
*order* of current coordinator might be greater than *order* of any client
node. Then when some client node leaves the grid, we will erroneously print the
*Coordinator changed* message with *client* node being the previous
coordinator. E.g.:
{noformat}
[2018-07-19 14:55:28,897][INFO ][disco-event-worker-#61] Node left topology:
TcpDiscoveryNode [id=7240957f-a51b-452d-bfc8-420e8ef9ea68, addrs=[127.0.0.1,
172.17.0.1, 172.25.1.15], sockAddrs=[/172.17.0.1:0, /127.0.0.1:0,
lab15.gridgain.local/172.25.1.15:0], discPort=0, order=16, intOrder=11,
lastExchangeTime=1532001260398, loc=false, ver=2.5.1#20180717-sha1:80e51c80,
isClient=true]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Topology snapshot
[ver=27, servers=3, clients=4, CPUs=96, offheap=260.0GB, heap=56.0GB]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Coordinator changed
[prev=TcpDiscoveryNode [id=7240957f-a51b-452d-bfc8-420e8ef9ea68,
addrs=[127.0.0.1, 172.17.0.1, 172.25.1.15], sockAddrs=[/172.17.0.1:0,
/127.0.0.1:0, lab15.gridgain.local/172.25.1.15:0], discPort=0, order=16,
intOrder=11, lastExchangeTime=1532001260398, loc=false,
ver=2.5.1#20180717-sha1:80e51c80, isClient=true], cur=TcpDiscoveryNode
[id=760fd8f2-b9d7-4953-aa86-3954c05c9feb, addrs=[127.0.0.1, 172.17.0.1,
172.25.1.21], sockAddrs=[/172.17.0.1:47500,
lab21.gridgain.local/172.25.1.21:47500, /127.0.0.1:47500], discPort=47500,
order=21, intOrder=15, lastExchangeTime=1532001260428, loc=false,
ver=2.5.1#20180717-sha1:80e51c80, isClient=false]]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] ^-- Node
[id=22B15E97-9944-48B5-A473-5C64E75A4D5A, clusterState=ACTIVE]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] ^-- Baseline [id=6,
size=3, online=3, offline=0]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Data Regions
Configured:
[2018-07-19 14:55:28,900][INFO ][disco-event-worker-#61] ^-- default
[initSize=256.0 MiB, maxSize=60.0 GiB, persistenceEnabled=true]
{noformat}
The *Coordinator changed* message should not be here because in fact the
coordinator was not changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
Ivan Artukhov created IGNITE-9397:
-
Summary: IgniteSqlDeleteBenchmark fails to run with
java.util.NoSuchElementException
Key: IGNITE-9397
URL: https://issues.apache.org/jira/browse/IGNITE-9397
Project: Ignite
Issue Type: Bug
Components: yardstick
Affects Versions: 2.6
Reporter: Ivan Artukhov
Attachments: r.properties
*Setup*
1 server and 1 client node
Attached the property file
*Steps*
Run
{code}
$ bash bin/benchmark-run-all.sh config/r.properties
{code}
*Result*
An exception during warm-up:
{code}
Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:117)
at
org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
at
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-9397:
--
Attachment: r.properties
> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file
> *Steps*
> Run
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-9397:
--
Description:
*Setup*
1 server and 1 client node
Attached the property file which has the only benchmark with the following
parameters:
{code}
CONFIGS="\
-cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b
${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark
-sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
"
{code}
*Steps*
Run
{code}
$ bash bin/benchmark-run-all.sh config/r.properties
{code}
*Result*
An exception during warm-up:
{code}
Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:117)
at
org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
at
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:748)
{code}
was:
*Setup*
1 server and 1 client node
Attached the property file
*Steps*
Run
{code}
$ bash bin/benchmark-run-all.sh config/r.properties
{code}
*Result*
An exception during warm-up:
{code}
Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:117)
at
org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
at
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:748)
{code}
> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file which has the only benchmark with the following
> parameters:
> {code}
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark
> -sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
> "
> {code}
> *Steps*
> Run
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-9397:
--
Ignite Flags: (was: Docs Required)
> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file which has the only benchmark with the following
> parameters:
> {code}
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark
> -sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
> "
> {code}
> *Steps*
> Run
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8236) Sporadic NPE in IgniteAtomicSequenceExample
Ivan Artukhov created IGNITE-8236:
-
Summary: Sporadic NPE in IgniteAtomicSequenceExample
Key: IGNITE-8236
URL: https://issues.apache.org/jira/browse/IGNITE-8236
Project: Ignite
Issue Type: Bug
Components: data structures
Affects Versions: 1.9
Reporter: Ivan Artukhov
Attachments: IgniteAtomicSequenceExample.1.zip
Platforms: Linux, Windows
Reproducibility: ~30%
Sometimes the _datastructures.IgniteAtomicSequenceExample_ throws the following
exception during run:
{code}
[06:26:26,810][SEVERE][utility-#62%null%][GridCacheIoManager] Failed processing
message [senderId=71fea304-3e08-4706-880a-7b00bebb280f,
msg=GridNearTxPrepareRequest
[futId=d889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc,
miniId=e889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc, near=false,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], last=true,
lastBackups=null, retVal=false, implicitSingle=false, explicitLock=false,
subjId=71fea304-3e08-4706-880a-7b00bebb280f, taskNameHash=0,
firstClientReq=false, super=GridDistributedTxPrepareRequest [threadId=134,
concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
[topVer=134994380, time=1523514386721, order=1523514383656, nodeOrder=2],
timeout=0, invalidate=false, reads=[], writes=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [],
hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [],
hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
entryProcessorsCol=[IgniteBiTuple [val1=AddAtomicProcessor
[info=DataStructureInfo [name=example-sequence, type=ATOMIC_SEQ]],
val2=[Ljava.lang.Object;@1540f725]], ttl=-1, conflictExpireTime=-1,
conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
filtersPassed=false, filtersSet=false, entry=GridDhtColocatedCacheEntry
[super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition
[rmvQueueMaxSize=128, rmvdEntryTtl=1, id=21,
map=o.a.i.i.processors.cache.GridCacheConcurrentMapImpl@1ea42fb7, cntr=1,
shouldBeRenting=false, state=OWNING, reservations=0, empty=false,
createTime=04/12/2018 06:26:18], super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
val=CacheObjectImpl [val={example-sequence=DataStructureInfo
[name=example-sequence, type=ATOMIC_SEQ]}, hasValBytes=true],
startVer=1523514383659, ver=GridCacheVersion [topVer=134994380,
time=1523514386783, order=1523514383665, nodeOrder=1], hash=-1424345221,
extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
[locs=[GridCacheMvccCandidate [nodeId=15305184-e5a2-4872-a549-d98e0df8b745,
ver=GridCacheVersion [topVer=134994380, time=1523514386744,
order=1523514383660, nodeOrder=1], threadId=113, id=6,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], reentry=null,
otherNodeId=15305184-e5a2-4872-a549-d98e0df8b745, otherVer=GridCacheVersion
[topVer=134994380, time=1523514386744, order=1523514383660, nodeOrder=1],
mappedDhtNodes=null, mappedNearNodes=null, ownerVer=GridCacheVersion
[topVer=134994380, time=1523514386732, order=1523514383657, nodeOrder=1],
serOrder=null, key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey
[], hasValBytes=true],
masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
prevVer=null, nextVer=GridCacheVersion [topVer=134994380, time=1523514386789,
order=1523514383667, nodeOrder=1]]], rmts=null]], flags=0, prepared=0,
locked=false, nodeId=null, locMapped=false, expiryPlc=null,
transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null,
xidVer=null]], dhtVers={IgniteTxKey [key=KeyCacheObjectImpl
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
cacheId=-2100569601]=null}, txSize=0, onePhaseCommit=true, sys=true, plc=5,
txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1,
arr=[-2100569601]], txMap={IgniteTxKey [key=KeyCacheObjectImpl
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
cacheId=-2100569601]=IgniteTxEntry [key=KeyCacheObjectImpl
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
cacheId=-2100569601, partId=21, txKey=IgniteTxKey [key=KeyCacheObjectImpl
[val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
cacheId=-2100569601], val=[op=TRANSFORM, val=null], prevVal=[op=NOOP,
val=null], oldVal=[op=NOOP, val=null], entryProcessorsCol=[IgniteBiTuple
[val1=AddAtomicProcessor [info=DataStructureInfo [name=example-sequence,
type=ATOMIC_SEQ]], val2=[Ljava.lang.Object;@1540f725]], ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=false,
[jira] [Updated] (IGNITE-8236) Sporadic NPE in IgniteAtomicSequenceExample
[
https://issues.apache.org/jira/browse/IGNITE-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-8236:
--
Priority: Major (was: Critical)
> Sporadic NPE in IgniteAtomicSequenceExample
>
>
> Key: IGNITE-8236
> URL: https://issues.apache.org/jira/browse/IGNITE-8236
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 1.9
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: IgniteAtomicSequenceExample.1.zip
>
>
> Platforms: Linux, Windows
> Reproducibility: ~30%
> Sometimes the _datastructures.IgniteAtomicSequenceExample_ throws the
> following exception during run:
> {code}
> [06:26:26,810][SEVERE][utility-#62%null%][GridCacheIoManager] Failed
> processing message [senderId=71fea304-3e08-4706-880a-7b00bebb280f,
> msg=GridNearTxPrepareRequest
> [futId=d889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc,
> miniId=e889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc, near=false,
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], last=true,
> lastBackups=null, retVal=false, implicitSingle=false, explicitLock=false,
> subjId=71fea304-3e08-4706-880a-7b00bebb280f, taskNameHash=0,
> firstClientReq=false, super=GridDistributedTxPrepareRequest [threadId=134,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=134994380, time=1523514386721, order=1523514383656, nodeOrder=2],
> timeout=0, invalidate=false, reads=[], writes=[IgniteTxEntry
> [key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [],
> hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [],
> hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
> prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
> entryProcessorsCol=[IgniteBiTuple [val1=AddAtomicProcessor
> [info=DataStructureInfo [name=example-sequence, type=ATOMIC_SEQ]],
> val2=[Ljava.lang.Object;@1540f725]], ttl=-1, conflictExpireTime=-1,
> conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
> filtersPassed=false, filtersSet=false, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition
> [rmvQueueMaxSize=128, rmvdEntryTtl=1, id=21,
> map=o.a.i.i.processors.cache.GridCacheConcurrentMapImpl@1ea42fb7, cntr=1,
> shouldBeRenting=false, state=OWNING, reservations=0, empty=false,
> createTime=04/12/2018 06:26:18], super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> val=CacheObjectImpl [val={example-sequence=DataStructureInfo
> [name=example-sequence, type=ATOMIC_SEQ]}, hasValBytes=true],
> startVer=1523514383659, ver=GridCacheVersion [topVer=134994380,
> time=1523514386783, order=1523514383665, nodeOrder=1], hash=-1424345221,
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=[GridCacheMvccCandidate [nodeId=15305184-e5a2-4872-a549-d98e0df8b745,
> ver=GridCacheVersion [topVer=134994380, time=1523514386744,
> order=1523514383660, nodeOrder=1], threadId=113, id=6,
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], reentry=null,
> otherNodeId=15305184-e5a2-4872-a549-d98e0df8b745, otherVer=GridCacheVersion
> [topVer=134994380, time=1523514386744, order=1523514383660, nodeOrder=1],
> mappedDhtNodes=null, mappedNearNodes=null, ownerVer=GridCacheVersion
> [topVer=134994380, time=1523514386732, order=1523514383657, nodeOrder=1],
> serOrder=null, key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=GridCacheVersion [topVer=134994380,
> time=1523514386789, order=1523514383667, nodeOrder=1]]], rmts=null]],
> flags=0, prepared=0, locked=false, nodeId=null, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
> serReadVer=null, xidVer=null]], dhtVers={IgniteTxKey [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601]=null}, txSize=0, onePhaseCommit=true, sys=true, plc=5,
> txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1,
> arr=[-2100569601]], txMap={IgniteTxKey [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601]=IgniteTxEntry [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601, partId=21, txKey=IgniteTxKey [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601], val=[op=TRANSFORM, val=null],
[jira] [Resolved] (IGNITE-8236) Sporadic NPE in IgniteAtomicSequenceExample
[
https://issues.apache.org/jira/browse/IGNITE-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov resolved IGNITE-8236.
---
Resolution: Cannot Reproduce
Cannot reproduce.
> Sporadic NPE in IgniteAtomicSequenceExample
>
>
> Key: IGNITE-8236
> URL: https://issues.apache.org/jira/browse/IGNITE-8236
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 1.9
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: IgniteAtomicSequenceExample.1.zip
>
>
> Platforms: Linux, Windows
> Reproducibility: ~30%
> Sometimes the _datastructures.IgniteAtomicSequenceExample_ throws the
> following exception during run:
> {code}
> [06:26:26,810][SEVERE][utility-#62%null%][GridCacheIoManager] Failed
> processing message [senderId=71fea304-3e08-4706-880a-7b00bebb280f,
> msg=GridNearTxPrepareRequest
> [futId=d889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc,
> miniId=e889888b261-bc99dff6-1c40-4ab1-90d2-5a1d12832afc, near=false,
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], last=true,
> lastBackups=null, retVal=false, implicitSingle=false, explicitLock=false,
> subjId=71fea304-3e08-4706-880a-7b00bebb280f, taskNameHash=0,
> firstClientReq=false, super=GridDistributedTxPrepareRequest [threadId=134,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=134994380, time=1523514386721, order=1523514383656, nodeOrder=2],
> timeout=0, invalidate=false, reads=[], writes=[IgniteTxEntry
> [key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [],
> hasValBytes=true], cacheId=-2100569601, partId=-1, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=CacheDataStructuresConfigurationKey [],
> hasValBytes=true], cacheId=-2100569601], val=[op=TRANSFORM, val=null],
> prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
> entryProcessorsCol=[IgniteBiTuple [val1=AddAtomicProcessor
> [info=DataStructureInfo [name=example-sequence, type=ATOMIC_SEQ]],
> val2=[Ljava.lang.Object;@1540f725]], ttl=-1, conflictExpireTime=-1,
> conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
> filtersPassed=false, filtersSet=false, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition
> [rmvQueueMaxSize=128, rmvdEntryTtl=1, id=21,
> map=o.a.i.i.processors.cache.GridCacheConcurrentMapImpl@1ea42fb7, cntr=1,
> shouldBeRenting=false, state=OWNING, reservations=0, empty=false,
> createTime=04/12/2018 06:26:18], super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> val=CacheObjectImpl [val={example-sequence=DataStructureInfo
> [name=example-sequence, type=ATOMIC_SEQ]}, hasValBytes=true],
> startVer=1523514383659, ver=GridCacheVersion [topVer=134994380,
> time=1523514386783, order=1523514383665, nodeOrder=1], hash=-1424345221,
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=[GridCacheMvccCandidate [nodeId=15305184-e5a2-4872-a549-d98e0df8b745,
> ver=GridCacheVersion [topVer=134994380, time=1523514386744,
> order=1523514383660, nodeOrder=1], threadId=113, id=6,
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0], reentry=null,
> otherNodeId=15305184-e5a2-4872-a549-d98e0df8b745, otherVer=GridCacheVersion
> [topVer=134994380, time=1523514386744, order=1523514383660, nodeOrder=1],
> mappedDhtNodes=null, mappedNearNodes=null, ownerVer=GridCacheVersion
> [topVer=134994380, time=1523514386732, order=1523514383657, nodeOrder=1],
> serOrder=null, key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=GridCacheVersion [topVer=134994380,
> time=1523514386789, order=1523514383667, nodeOrder=1]]], rmts=null]],
> flags=0, prepared=0, locked=false, nodeId=null, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
> serReadVer=null, xidVer=null]], dhtVers={IgniteTxKey [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601]=null}, txSize=0, onePhaseCommit=true, sys=true, plc=5,
> txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1,
> arr=[-2100569601]], txMap={IgniteTxKey [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601]=IgniteTxEntry [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601, partId=21, txKey=IgniteTxKey [key=KeyCacheObjectImpl
> [val=CacheDataStructuresConfigurationKey [], hasValBytes=true],
> cacheId=-2100569601], val=[op=TRANSFORM,
[jira] [Commented] (IGNITE-6822) IgfsMapReduceExample raise exception in multi nodes run
[
https://issues.apache.org/jira/browse/IGNITE-6822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418627#comment-16418627
]
Ivan Artukhov commented on IGNITE-6822:
---
Reproducible on AI 2.3. The same issue with
_ComputeClientBinaryTaskExecutionExample_.
> IgfsMapReduceExample raise exception in multi nodes run
> ---
>
> Key: IGNITE-6822
> URL: https://issues.apache.org/jira/browse/IGNITE-6822
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Chetaev
>Priority: Minor
> Attachments: example.log, grid.o.a.i.e.igfs.IgfsNodeStartup.1.log,
> grid.o.a.i.e.igfs.IgfsNodeStartup.2.log,
> grid.o.a.i.e.igfs.IgfsNodeStartup.3.log
>
>
> All logs in attachments.
> Exception:
> {code:java}
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7538)
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.fileLock(MarshallerMappingFileStore.java:254)
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.writeMapping(MarshallerMappingFileStore.java:95)
> at
> org.apache.ignite.internal.MappingStoreTask.run(MappingStoreTask.java:57)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7623) Thin client Java API - async API
[ https://issues.apache.org/jira/browse/IGNITE-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641380#comment-16641380 ] Ivan Artukhov edited comment on IGNITE-7623 at 10/8/18 5:52 AM: Current benchmarking results for Ignite native client vs thin client are as follows. Clients used 64 threads to generate load. 1) 1 server, 4 clients !Screenshot from 2018-10-08 08-49-22.png! 2) 4 servers, 8 clients !Screenshot from 2018-10-08 08-46-38.png! was (Author: artukhov): Current benchmarking results for Ignite native client vs thin client are as follows. Clients used 64 threads to generate load. 1) 1 server, 4 clients !Screenshot from 2018-10-08 08-49-22.png! 2) 4 servers, 8 clients !Screenshot from 2018-10-08 08-49-22.png! > Thin client Java API - async API > > > Key: IGNITE-7623 > URL: https://issues.apache.org/jira/browse/IGNITE-7623 > Project: Ignite > Issue Type: Task > Components: clients >Reporter: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > Attachments: Screenshot from 2018-10-08 08-46-38.png, Screenshot from > 2018-10-08 08-49-22.png > > Original Estimate: 0.4h > Remaining Estimate: 0.4h > > Implement Async version of all the Java thin client APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7623) Thin client Java API - async API
[ https://issues.apache.org/jira/browse/IGNITE-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641380#comment-16641380 ] Ivan Artukhov commented on IGNITE-7623: --- Current benchmarking results for Ignite native client vs thin client are as follows. Clients used 64 threads to generate load. 1) 1 server, 4 clients !Screenshot from 2018-10-08 08-49-22.png! 2) 4 servers, 8 clients !Screenshot from 2018-10-08 08-49-22.png! > Thin client Java API - async API > > > Key: IGNITE-7623 > URL: https://issues.apache.org/jira/browse/IGNITE-7623 > Project: Ignite > Issue Type: Task > Components: clients >Reporter: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > Attachments: Screenshot from 2018-10-08 08-46-38.png, Screenshot from > 2018-10-08 08-49-22.png > > Original Estimate: 0.4h > Remaining Estimate: 0.4h > > Implement Async version of all the Java thin client APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7623) Thin client Java API - async API
[ https://issues.apache.org/jira/browse/IGNITE-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Artukhov updated IGNITE-7623: -- Attachment: Screenshot from 2018-10-08 08-46-38.png > Thin client Java API - async API > > > Key: IGNITE-7623 > URL: https://issues.apache.org/jira/browse/IGNITE-7623 > Project: Ignite > Issue Type: Task > Components: clients >Reporter: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > Attachments: Screenshot from 2018-10-08 08-46-38.png, Screenshot from > 2018-10-08 08-49-22.png > > Original Estimate: 0.4h > Remaining Estimate: 0.4h > > Implement Async version of all the Java thin client APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7623) Thin client Java API - async API
[ https://issues.apache.org/jira/browse/IGNITE-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Artukhov updated IGNITE-7623: -- Attachment: Screenshot from 2018-10-08 08-49-22.png > Thin client Java API - async API > > > Key: IGNITE-7623 > URL: https://issues.apache.org/jira/browse/IGNITE-7623 > Project: Ignite > Issue Type: Task > Components: clients >Reporter: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > Attachments: Screenshot from 2018-10-08 08-46-38.png, Screenshot from > 2018-10-08 08-49-22.png > > Original Estimate: 0.4h > Remaining Estimate: 0.4h > > Implement Async version of all the Java thin client APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10280) Create Yardstick IgniteGetAllTxBenchmark
Ivan Artukhov created IGNITE-10280: -- Summary: Create Yardstick IgniteGetAllTxBenchmark Key: IGNITE-10280 URL: https://issues.apache.org/jira/browse/IGNITE-10280 Project: Ignite Issue Type: Improvement Components: yardstick Reporter: Ivan Artukhov Yardstick module has no transactional getAll benchmark. Only atomic IgniteGetAllBenchmark. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10247) TX benchmarks with TRANSACTIONAL_SNAPSHOT caches do not handle write conflicts
Ivan Artukhov created IGNITE-10247:
--
Summary: TX benchmarks with TRANSACTIONAL_SNAPSHOT caches do not
handle write conflicts
Key: IGNITE-10247
URL: https://issues.apache.org/jira/browse/IGNITE-10247
Project: Ignite
Issue Type: Bug
Components: yardstick
Affects Versions: 2.7
Reporter: Ivan Artukhov
When I run e.g. IgnitePutGetTxBenchmark on a cache with TRANSACTIONAL_SNAPSHOT
atomicity mode, I get the following exception and then benchmark driver stops:
{noformat}
Finishing main test [ts=1542181024722, date=Wed Nov 14 10:37:04 MSK 2018]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Cannot serialize transaction due to write conflict (transaction is marked for
rollback)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.yardstick.cache.IgnitePutGetTxBenchmark$1.call(IgnitePutGetTxBenchmark.java:56)
at
org.apache.ignite.yardstick.cache.IgnitePutGetTxBenchmark$1.call(IgnitePutGetTxBenchmark.java:45)
at
org.apache.ignite.yardstick.IgniteBenchmarkUtils.doInTransaction(IgniteBenchmarkUtils.java:80)
at
org.apache.ignite.yardstick.cache.IgnitePutGetTxBenchmark.test(IgnitePutGetTxBenchmark.java:65)
at
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot serialize
transaction due to write conflict (transaction is marked for rollback)
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7427)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.processors.cache.distributed.dht.NearTxResultHandler.createResponse(NearTxResultHandler.java:80)
at
org.apache.ignite.internal.processors.cache.distributed.dht.NearTxResultHandler.createResponse(NearTxResultHandler.java:67)
at
org.apache.ignite.internal.processors.cache.distributed.dht.NearTxResultHandler.apply(NearTxResultHandler.java:107)
at
org.apache.ignite.internal.processors.cache.distributed.dht.NearTxResultHandler.apply(NearTxResultHandler.java:36)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:507)
at
org.apache.ignite.internal.processors.cache.GridCacheFutureAdapter.onDone(GridCacheFutureAdapter.java:55)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:486)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onDone(GridDhtTxAbstractEnlistFuture.java:1054)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:564)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:364)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxEnlistRequest(GridDhtTransactionalCacheAdapter.java:2061)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$900(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$14.apply(GridDhtTransactionalCacheAdapter.java:229)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$14.apply(GridDhtTransactionalCacheAdapter.java:227)
at
[jira] [Commented] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681287#comment-16681287
]
Ivan Artukhov commented on IGNITE-10052:
Commit b2f697b shows another error when I go through the steps from description.
Error on client's side:
{code}
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
Error: Failed to run update. Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8] (state=5,code=1)
{code}
On server's side:
{code}
[14:08:44,202][SEVERE][jdbc-request-handler-worker-#48][DmlStatementsProcessor]
Error during update [localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98]
class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:987)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1939)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:532)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1920)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2305)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
... 13 more
{code}
*a80dc9b8-6a28-4015-a288-0436e2916f98* is the ID of the first server node.
*56dadffc-0d9a-4c42-8d3b-55266e093fc8* is the ID of the second (restarted)
server node.
> Restart node during TX causes
[jira] [Comment Edited] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681287#comment-16681287
]
Ivan Artukhov edited comment on IGNITE-10052 at 11/9/18 11:26 AM:
--
Commit b2f697b shows another error when I go through the steps from description.
Error on client's side:
{code}
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
Error: Failed to run update. Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8] (state=5,code=1)
{code}
On server's side:
{noformat}
[14:08:44,202][SEVERE][jdbc-request-handler-worker-#48][DmlStatementsProcessor]
Error during update [localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98]
class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
[localNodeId=a80dc9b8-6a28-4015-a288-0436e2916f98,
remoteNodeId=56dadffc-0d9a-4c42-8d3b-55266e093fc8]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:987)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2342)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1939)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:532)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1920)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2305)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
... 13 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxMvccVersionCheckedException:
Unexpected state: [state=0, rowVer=1541761538351:12:1,
[jira] [Commented] (IGNITE-10052) Restart node during TX causes vacuum error.
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681309#comment-16681309
]
Ivan Artukhov commented on IGNITE-10052:
The latter problem seems to be the cause of
https://issues.apache.org/jira/browse/IGNITE-9928.
> Restart node during TX causes vacuum error.
> ---
>
> Key: IGNITE-10052
> URL: https://issues.apache.org/jira/browse/IGNITE-10052
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.7
>
>
> 1. Start 2 nodes with PDS, activate , start {{sqlline}}
> 2. Create table
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int, b int, primary
> key(a)) with "atomicity=TRANSACTIONAL_SNAPSHOT,
> backups=1";
> No rows affected (0,294 seconds)
> {noformat}
> 3. Open TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,007 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> 1 row affected (0,112 seconds)
> {noformat}
> 4. Stop and then start 2nd node
> 5. Rollback TX and check the table data (no rows added):
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> rollback;
> No rows affected (0,011 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
> +++
> | A| B|
> +++
> +++
> No rows selected (0,067 seconds)
> {noformat}
> 6. Start second TX that throws the exception:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,001 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> Error: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []] (state=50
> 000,code=1)
> java.sql.SQLException: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchR
> ow []]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> The server nodes print out:
> {noformat}
> [18:46:32,136][SEVERE][jdbc-request-handler-worker-#62][DmlStatementsProcessor]
> Error during update [localNodeId=319a2fda-1315-4bdf-8647-7ddee2d3342e]
> class org.apache.ignite.IgniteCheckedException: Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1919)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:460)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxQueryResultsEnlistRequest(GridDhtTransactionalCacheAdapter.java:2000)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$700(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:215)
> at
>
[jira] [Commented] (IGNITE-10720) Decrease time to save metadata during checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-10720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744790#comment-16744790
]
Ivan Artukhov commented on IGNITE-10720:
Got the following assertion when I start a server node which was previously
stopped (killed) during checkpoint:
{code:java}
[2019-01-16 15:57:48,646][INFO ][main] Starting binary memory restore for:
[-1282194281, -1282194277, -1282194278, -1282194279, -1282194280, -1282194273,
-1282194274, -623411239, -1282194275, -1282194276, -1282194303, -1282194304,
-1282194249, -1282194250, -1282194245, -1282194246, -1282194247, -1282194248,
-1282194241, -1282194242, -1282194243, -1282194244, -1282194272, -2100569601,
-1282194217, -1282194218, -1282194219, -1282194213, -1282194214, -1282194215,
-1282194216, -1282194210, -1282194211, -1282194212, -1093321804, -1282194185,
-1282194186, -1282194187, -1282194188, -1282194181, -1282194182, -1282194183,
-1282194184, -1282194433, -1309826943, -1282194434, -1282194179, -1282194435,
-1282194436, -1282194180, 692518463, 692455107, -1282194405, -623474595,
-1282194401, -1282194402, -1282194403, -1282194404, -1282194429, -1282194430,
-1282194431, -1282194432, -1282194427, -1282194428, -2131765427, -1282194373,
-1282194374, -1282194369, -1282194370, -1282194371, -1282194372, -1282194397,
-1282194398, -1282194399, -1282194400, -1282194396, -1282194341, -1282194342,
-1282194343, -1282194337, -1282194338, -1282194339, -1282194340, -1282194365,
-1282194366, -1282194367, -1282194368, -1974223438, -1282194309, -1282194310,
-1282194311, -1282194312, -1282194305, -1282194306, -1282194307, -1282194308,
-1282194334, -1282194335, 374280892, -1941895502, -1282194336, 374280891,
374280890, 374280889, 374280888, 374280887, 374280886, 374280885, 374280884]
[2019-01-16 15:57:52,885][INFO ][main] Read checkpoint status
[startMarker=/storage/ssd/prtagent/poc/work/db/poc_tester_server_172_25_1_22_id_0/cp/1547643332579-8f0f1aca-36de-4cfd-a5ea-08daae99c80c-START.bin,
endMarker=/storage/ssd/prtagent/poc/work/db/poc_tester_server_172_25_1_22_id_0/cp/1547643312802-93a29247-8743-492c-951e-035a2126ddde-END.bin]
[2019-01-16 15:57:52,885][INFO ][main] Checking memory state
[lastValidPos=FileWALPointer [idx=3302, fileOff=1319234, len=2055203],
lastMarked=FileWALPointer [idx=3338, fileOff=59, len=2055203],
lastCheckpointId=8f0f1aca-36de-4cfd-a5ea-08daae99c80c]
[2019-01-16 15:57:52,886][WARN ][main] Ignite node stopped in the middle of
checkpoint. Will restore memory state and finish checkpoint on node start.
[2019-01-16 15:58:01,586][ERROR][main] Exception during start processors,
node will be stopped and close connections
java.lang.AssertionError: 0002
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1551)
~[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlock(PageMemoryImpl.java:470)
~[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.performBinaryMemoryRestore(GridCacheDatabaseSharedManager.java:2228)
~[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:942)
~[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1946)
~[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1054)
[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2041)
[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
[ignite-core-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at org.apache.ignite.IgniteSpring.start(IgniteSpring.java:66)
[ignite-spring-2.8.0-SNAPSHOT.jar:2.8.0-SNAPSHOT]
at
org.apache.ignite.scenario.internal.utils.IgniteNode.start(IgniteNode.java:242)
[poc-tester-0.1.0-SNAPSHOT.jar:?]
at
org.apache.ignite.scenario.internal.utils.IgniteNode.main(IgniteNode.java:82)
[poc-tester-0.1.0-SNAPSHOT.jar:?]
[2019-01-16 15:58:01,594][ERROR][main] Got exception while starting (will
rollback startup routine).
java.lang.AssertionError: 0002
[jira] [Created] (IGNITE-10650) Yardstick pre-loader does not use defaultDataRegionConfiguration
Ivan Artukhov created IGNITE-10650: -- Summary: Yardstick pre-loader does not use defaultDataRegionConfiguration Key: IGNITE-10650 URL: https://issues.apache.org/jira/browse/IGNITE-10650 Project: Ignite Issue Type: Bug Components: yardstick Affects Versions: 2.7 Reporter: Ivan Artukhov Fix For: 2.8 the new Loader.java class fails to get DataRegionConfiguration if it is not explicitly set for a given cache. Why not to try to get data region configuration from defaultDataRegionConfiguration property in this case? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9356) Ignite rest command http://localhost:8080/ignite?cmd=log=n=m return more line in linux than windows
[ https://issues.apache.org/jira/browse/IGNITE-9356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707092#comment-16707092 ] Ivan Artukhov commented on IGNITE-9356: --- Cannot reproduce. Request http://localhost:8080/ignite?cmd=log=n=m returns equal and correct amount of lines for Ignite running on both Windows and Linux platforms. And the lines in the 'response' field correspond to those in the log file. Please make sure you compare response with lines from log file, not with lines printed to STDOUT. > Ignite rest command http://localhost:8080/ignite?cmd=log=n=m return > more line in linux than windows > - > > Key: IGNITE-9356 > URL: https://issues.apache.org/jira/browse/IGNITE-9356 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.5 > Environment: Centos/ Windows10 >Reporter: ARomantsov >Priority: Minor > Fix For: 2.8 > > > I run cluster in diffrent configuration (centos and windows 10) and notice > that log command return diffrent count of rows in same from and to > Windows rest return 1 less rows -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11242) Update counters mismatch after loading data via DataStreamer into MVCC-enabled caches
[
https://issues.apache.org/jira/browse/IGNITE-11242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16763709#comment-16763709
]
Ivan Artukhov commented on IGNITE-11242:
[~Pavlukhin] There was 3 server nodes and 3 client "DataStreamer" nodes each
using 8 threads to load data. Cluster topology was stable.
> Update counters mismatch after loading data via DataStreamer into
> MVCC-enabled caches
> -
>
> Key: IGNITE-11242
> URL: https://issues.apache.org/jira/browse/IGNITE-11242
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, streaming
>Affects Versions: 2.7
>Reporter: Ivan Artukhov
>Assignee: Ivan Pavlukhin
>Priority: Critical
>
> *Steps:*
> Start 1000 caches in 100 cache groups. Caches configuration:
> {code:xml}
> value="TRANSACTIONAL_SNAPSHOT"/>
>
>
> value="FULL_SYNC"/>
> value="READ_WRITE_SAFE"/>
> {code}
> Preload 1 keys into each cache using DataStreamer
> Run *VerifyBackupPartitionsTaskV2* to check partition inconsistencies between
> hashes or update counters
> *Expected:*
> There are no differences between primary and backup partitions
> *Actual:*
> Two or three *backup* partitions in each cache group have update counters
> which differ from corresponding primary partitions. E.g.:
> {code}
> [2019-02-07 11:04:23,286][INFO ][Task-threadNum-0] Conflict partition:
> PartitionKeyV2 [grpId=-1093321804, grpName=cache_group_100, partId=261]
> [2019-02-07 11:04:23,286][INFO ][Task-threadNum-0] Partition instances:
> [PartitionHashRecordV2 [isPrimary=true, consistentId=id-0, updateCntr=100,
> size=100, partHash=665729765], PartitionHashRecordV2 [isPrimary=false,
> consistentId=id-1, updateCntr=91, size=100, partHash=665729765],
> PartitionHashRecordV2 [isPrimary=false, consistentId=id-2, updateCntr=100,
> size=100, partHash=665729765]]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769176#comment-16769176
]
Ivan Artukhov commented on IGNITE-11216:
[~vveider] [~dpavlov] Checked every script with both OracleJDK 8 and OracleJDK
11 running under Ubuntu. No issues was found. I suppose we can merge the PR.
> Ignite.sh fails on Mac OS and Linux - Java 11
> -
>
> Key: IGNITE-11216
> URL: https://issues.apache.org/jira/browse/IGNITE-11216
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ignite.sh fails on Mac OS Mojave with the following JDK version:
> java version "11.0.2" 2019-01-15 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
> The same issue is reproduced on Linux and the workaround is discussed here:
> https://issues.apache.org/jira/browse/IGNITE-3
> The exception is as follows:
> {noformat}
> /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh:
> line 40: [: -eq: unary operator expected
> ./ignite.sh: line 152: [: -eq: unary operator expected
> ./ignite.sh: line 157: [: -gt: unary operator expected
> ./ignite.sh: line 170: [: -eq: unary operator expected
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar)
> to field java.nio.Buffer.address
> WARNING: Please consider reporting this to the maintainers of
> org.apache.ignite.internal.util.GridUnsafe$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at
> org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795)
> at
> org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305)
> at
> org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99)
> Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class
> is unavailable.
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453)
> at
> org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112)
> ... 4 more
> Caused by: java.lang.IllegalAccessException: class
> org.apache.ignite.internal.util.GridUnsafe cannot access class
> jdk.internal.misc.SharedSecrets (in module java.base) because module
> java.base does not export jdk.internal.misc to unnamed module @4f83df68
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591)
> at java.base/java.lang.reflect.Method.invoke(Method.java:558)
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10720) Decrease time to save metadata during checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-10720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769068#comment-16769068 ] Ivan Artukhov commented on IGNITE-10720: I was unable to reproduce the assertion failure mentioned previously on the latest commit. So the assertion looks fixed. > Decrease time to save metadata during checkpoint > > > Key: IGNITE-10720 > URL: https://issues.apache.org/jira/browse/IGNITE-10720 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like it's not neccessery save all metadata(like free list) under write > checkpoint lock because sometimes it's too long. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11344) High performance drop in master vs 2.7
Ivan Artukhov created IGNITE-11344: -- Summary: High performance drop in master vs 2.7 Key: IGNITE-11344 URL: https://issues.apache.org/jira/browse/IGNITE-11344 Project: Ignite Issue Type: Bug Reporter: Ivan Artukhov Attachments: Screenshot from 2019-02-18 12-53-15.png, Screenshot from 2019-02-18 12-53-40.png Builds under test: * Apache Ignite from branch *master*, nightly build at 2019-02-15 * Apache Ignite 2.7 Benchmark: * atomic put-all (IgnitePutAllBenchmark), batch size: 100 Environment: * 4 servers, 8 clients (64 threads) * *In-memory* mode (the drop is not as high when persistence is enabled) Results for FULL_SYNC (-16.19% drop in master): !Screenshot from 2019-02-18 12-53-40.png! Results for PRIMARY_SYNC (-23.41% drop in master): !Screenshot from 2019-02-18 12-53-15.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765922#comment-16765922
]
Ivan Artukhov commented on IGNITE-11216:
LGTM
> Ignite.sh fails on Mac OS and Linux - Java 11
> -
>
> Key: IGNITE-11216
> URL: https://issues.apache.org/jira/browse/IGNITE-11216
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Ignite.sh fails on Mac OS Mojave with the following JDK version:
> java version "11.0.2" 2019-01-15 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
> The same issue is reproduced on Linux and the workaround is discussed here:
> https://issues.apache.org/jira/browse/IGNITE-3
> The exception is as follows:
> {noformat}
> /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh:
> line 40: [: -eq: unary operator expected
> ./ignite.sh: line 152: [: -eq: unary operator expected
> ./ignite.sh: line 157: [: -gt: unary operator expected
> ./ignite.sh: line 170: [: -eq: unary operator expected
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar)
> to field java.nio.Buffer.address
> WARNING: Please consider reporting this to the maintainers of
> org.apache.ignite.internal.util.GridUnsafe$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at
> org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795)
> at
> org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305)
> at
> org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99)
> Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class
> is unavailable.
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453)
> at
> org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112)
> ... 4 more
> Caused by: java.lang.IllegalAccessException: class
> org.apache.ignite.internal.util.GridUnsafe cannot access class
> jdk.internal.misc.SharedSecrets (in module java.base) because module
> java.base does not export jdk.internal.misc to unnamed module @4f83df68
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591)
> at java.base/java.lang.reflect.Method.invoke(Method.java:558)
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11242) Update counters mismatch after loading data via DataStreamer into MVCC-enabled caches
Ivan Artukhov created IGNITE-11242:
--
Summary: Update counters mismatch after loading data via
DataStreamer into MVCC-enabled caches
Key: IGNITE-11242
URL: https://issues.apache.org/jira/browse/IGNITE-11242
Project: Ignite
Issue Type: Bug
Components: mvcc, streaming
Affects Versions: 2.7
Reporter: Ivan Artukhov
*Steps:*
Start 1000 caches in 100 cache groups. Caches configuration:
{code:xml}
{code}
Preload 1 keys into each cache using DataStreamer
Run *VerifyBackupPartitionsTaskV2* to check partition inconsistencies between
hashes or update counters
*Expected:*
There are no differences between primary and backup partitions
*Actual:*
Two or three *backup* partitions in each cache group have update counters which
differ from corresponding primary partitions. E.g.:
{code}
[2019-02-07 11:04:23,286][INFO ][Task-threadNum-0] Conflict partition:
PartitionKeyV2 [grpId=-1093321804, grpName=cache_group_100, partId=261]
[2019-02-07 11:04:23,286][INFO ][Task-threadNum-0] Partition instances:
[PartitionHashRecordV2 [isPrimary=true, consistentId=id-0, updateCntr=100,
size=100, partHash=665729765], PartitionHashRecordV2 [isPrimary=false,
consistentId=id-1, updateCntr=91, size=100, partHash=665729765],
PartitionHashRecordV2 [isPrimary=false, consistentId=id-2, updateCntr=100,
size=100, partHash=665729765]]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11344) High performance drop in master vs 2.7
[
https://issues.apache.org/jira/browse/IGNITE-11344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772747#comment-16772747
]
Ivan Artukhov commented on IGNITE-11344:
Commit in branch *master* which introduced the drop:
{noformat}
[937164ea1a922ae32e54aa32b7356ef758599e87] IGNITE-10755: MVCC: Fix CQ
registration in the middle of tx. This closes #5841.
{noformat}
> High performance drop in master vs 2.7
> --
>
> Key: IGNITE-11344
> URL: https://issues.apache.org/jira/browse/IGNITE-11344
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Assignee: Roman Kondakov
>Priority: Critical
> Labels: benchmarks, yardstick
> Attachments: Screenshot from 2019-02-18 12-53-15.png, Screenshot from
> 2019-02-18 12-53-40.png
>
>
> Builds under test:
> * Apache Ignite from branch *master*, nightly build at 2019-02-15
> * Apache Ignite 2.7
> Benchmark:
> * atomic put-all (IgnitePutAllBenchmark), batch size: 100
> Environment:
> * 4 servers, 8 clients (64 threads)
> * *In-memory* mode (the drop is not as high when persistence is enabled)
> Results for FULL_SYNC (-16.19% drop in master):
> !Screenshot from 2019-02-18 12-53-40.png!
> Results for PRIMARY_SYNC (-23.41% drop in master):
> !Screenshot from 2019-02-18 12-53-15.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11344) High performance drop in master vs 2.7
[
https://issues.apache.org/jira/browse/IGNITE-11344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772821#comment-16772821
]
Ivan Artukhov commented on IGNITE-11344:
Drivers start-up parameters:
{code:java}
-d 60 --client -j 10 -dn IgnitePutAllBenchmark -ds atomic-put-all-bs-100 -sm
PRIMARY_SYNC -t 64 -bs 100 -w 60 -nn 12 -b 1
{code}
> High performance drop in master vs 2.7
> --
>
> Key: IGNITE-11344
> URL: https://issues.apache.org/jira/browse/IGNITE-11344
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Assignee: Roman Kondakov
>Priority: Critical
> Labels: benchmarks, yardstick
> Attachments: Screenshot from 2019-02-18 12-53-15.png, Screenshot from
> 2019-02-18 12-53-40.png
>
>
> Builds under test:
> * Apache Ignite from branch *master*, nightly build at 2019-02-15
> * Apache Ignite 2.7
> Benchmark:
> * atomic put-all (IgnitePutAllBenchmark), batch size: 100
> Environment:
> * 4 servers, 8 clients (64 threads)
> * *In-memory* mode (the drop is not as high when persistence is enabled)
> Results for FULL_SYNC (-16.19% drop in master):
> !Screenshot from 2019-02-18 12-53-40.png!
> Results for PRIMARY_SYNC (-23.41% drop in master):
> !Screenshot from 2019-02-18 12-53-15.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765112#comment-16765112
]
Ivan Artukhov commented on IGNITE-11216:
Checked on Ubuntu 18.04.1 and OracleJDK 11.0.2. I get the following error if
*JAVA_HOME* variable is *unset*:
{code}
bin/include/functions.sh: line 64: JAVA_HOME: unbound variable
{code}
Proposed fix:
{code}
if [ "${JAVA_HOME:-}" = "" ]; then
{code}
> Ignite.sh fails on Mac OS and Linux - Java 11
> -
>
> Key: IGNITE-11216
> URL: https://issues.apache.org/jira/browse/IGNITE-11216
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ignite.sh fails on Mac OS Mojave with the following JDK version:
> java version "11.0.2" 2019-01-15 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
> The same issue is reproduced on Linux and the workaround is discussed here:
> https://issues.apache.org/jira/browse/IGNITE-3
> The exception is as follows:
> {noformat}
> /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh:
> line 40: [: -eq: unary operator expected
> ./ignite.sh: line 152: [: -eq: unary operator expected
> ./ignite.sh: line 157: [: -gt: unary operator expected
> ./ignite.sh: line 170: [: -eq: unary operator expected
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar)
> to field java.nio.Buffer.address
> WARNING: Please consider reporting this to the maintainers of
> org.apache.ignite.internal.util.GridUnsafe$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at
> org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795)
> at
> org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305)
> at
> org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99)
> Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class
> is unavailable.
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453)
> at
> org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112)
> ... 4 more
> Caused by: java.lang.IllegalAccessException: class
> org.apache.ignite.internal.util.GridUnsafe cannot access class
> jdk.internal.misc.SharedSecrets (in module java.base) because module
> java.base does not export jdk.internal.misc to unnamed module @4f83df68
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591)
> at java.base/java.lang.reflect.Method.invoke(Method.java:558)
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
[ https://issues.apache.org/jira/browse/IGNITE-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036881#comment-17036881 ] Ivan Artukhov commented on IGNITE-11949: [~alex_pl] [~mmuzaf] [~zstan] Looks good to me. > Yardstick benchmarks for WAL page snapshot compression > -- > > Key: IGNITE-11949 > URL: https://issues.apache.org/jira/browse/IGNITE-11949 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-20, yardstick > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > WAL page snapshots compression (implemented by IGNITE-11336) can be enabled > by modifying config.xml file. It will be better to configure benchmarks by > command line options. > Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13337) Performance drop in ignite-2.9 vs Ignite 2.8.1
Ivan Artukhov created IGNITE-13337:
--
Summary: Performance drop in ignite-2.9 vs Ignite 2.8.1
Key: IGNITE-13337
URL: https://issues.apache.org/jira/browse/IGNITE-13337
Project: Ignite
Issue Type: Bug
Components: cache, sql
Affects Versions: 2.9
Environment: 9 equal physical hosts (2x Xeon E5-2609 v4, 96Gb RAM,
3x800Gb SSD RAID0, 10Gb/s ethernet)
3 server nodes, one node per physical host
6 client nodes, one node per physical host, 64 load threads
Reporter: Ivan Artukhov
Attachments: in-mem-FULL_SYNC.png, in-mem-PRIMARY_SYNC.png,
pds-LOG_ONLY-FULL_SYNC.png, pds-LOG_ONLY-PRIMARY_SYNC.png
Yardstick benchmarks show up to 7% performance drop in branch {{ignite-2.9}}
(rev. 6592dfa5) vs Ignite 2.8.1. Please see the attached screenshots.
The benchmarks in use:
{noformat}
IgnitePutBenchmark
IgniteGetBenchmark
IgnitePutTxImplicitBenchmark
IgnitePutGetTxBenchmark -optimistic
IgnitePutGetTxBenchmark -pessimistic
IgnitePutGetTxBenchmark -optimistic -serializable
IgniteSqlQueryBenchmark
IgnitePutAllTxBenchmark
IgnitePutAllBenchmark
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13337) Performance drop in ignite-2.9 vs Ignite 2.8.1
[
https://issues.apache.org/jira/browse/IGNITE-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-13337:
---
Attachment: caches.xml
driver.xml
server.xml
> Performance drop in ignite-2.9 vs Ignite 2.8.1
> --
>
> Key: IGNITE-13337
> URL: https://issues.apache.org/jira/browse/IGNITE-13337
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.9
> Environment: 9 equal physical hosts (2x Xeon E5-2609 v4, 96Gb RAM,
> 3x800Gb SSD RAID0, 10Gb/s ethernet)
> 3 server nodes, one node per physical host
> 6 client nodes, one node per physical host, 64 load threads
>Reporter: Ivan Artukhov
>Priority: Critical
> Attachments: caches.xml, driver.xml, in-mem-FULL_SYNC.png,
> in-mem-PRIMARY_SYNC.png, pds-LOG_ONLY-FULL_SYNC.png,
> pds-LOG_ONLY-PRIMARY_SYNC.png, server.xml
>
>
> Yardstick benchmarks show up to 7% performance drop in branch {{ignite-2.9}}
> (rev. 6592dfa5) vs Ignite 2.8.1. Please see the attached screenshots.
> The benchmarks in use:
> {noformat}
> IgnitePutBenchmark
> IgniteGetBenchmark
> IgnitePutTxImplicitBenchmark
> IgnitePutGetTxBenchmark -optimistic
> IgnitePutGetTxBenchmark -pessimistic
> IgnitePutGetTxBenchmark -optimistic -serializable
> IgniteSqlQueryBenchmark
> IgnitePutAllTxBenchmark
> IgnitePutAllBenchmark
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13337) Performance drop in ignite-2.9 vs Ignite 2.8.1
[
https://issues.apache.org/jira/browse/IGNITE-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172303#comment-17172303
]
Ivan Artukhov commented on IGNITE-13337:
Attached Spring XML configs for server and client nodes.
> Performance drop in ignite-2.9 vs Ignite 2.8.1
> --
>
> Key: IGNITE-13337
> URL: https://issues.apache.org/jira/browse/IGNITE-13337
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.9
> Environment: 9 equal physical hosts (2x Xeon E5-2609 v4, 96Gb RAM,
> 3x800Gb SSD RAID0, 10Gb/s ethernet)
> 3 server nodes, one node per physical host
> 6 client nodes, one node per physical host, 64 load threads
>Reporter: Ivan Artukhov
>Priority: Critical
> Attachments: caches.xml, driver.xml, in-mem-FULL_SYNC.png,
> in-mem-PRIMARY_SYNC.png, pds-LOG_ONLY-FULL_SYNC.png,
> pds-LOG_ONLY-PRIMARY_SYNC.png, server.xml
>
>
> Yardstick benchmarks show up to 7% performance drop in branch {{ignite-2.9}}
> (rev. 6592dfa5) vs Ignite 2.8.1. Please see the attached screenshots.
> The benchmarks in use:
> {noformat}
> IgnitePutBenchmark
> IgniteGetBenchmark
> IgnitePutTxImplicitBenchmark
> IgnitePutGetTxBenchmark -optimistic
> IgnitePutGetTxBenchmark -pessimistic
> IgnitePutGetTxBenchmark -optimistic -serializable
> IgniteSqlQueryBenchmark
> IgnitePutAllTxBenchmark
> IgnitePutAllBenchmark
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-17129) cli tool dosn’t expand tilde in a config path
[
https://issues.apache.org/jira/browse/IGNITE-17129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622142#comment-17622142
]
Ivan Artukhov commented on IGNITE-17129:
Duplicate of https://issues.apache.org/jira/browse/IGNITE-16463
> cli tool dosn’t expand tilde in a config path
> --
>
> Key: IGNITE-17129
> URL: https://issues.apache.org/jira/browse/IGNITE-17129
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha5
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> Many Linux users use tilde ({{{}~{}}}) as a shortcut for a user's home
> directory. CLI tool could expand environment variables (like {{{}$HOME{}}})
> in config path, but fails to expand tilde.
> An example:
> {code:java}
> $ ./ignite node start
> --config=~/work/apache/ignite-3/examples/config/ignite-config.json
> my-first-node
> Starting a new Ignite node...
> Can't start the node. Read logs for details:
> /home/zloddey/opt/ai3/ignite-log/my-first-node.log
> $ cat /home/zloddey/opt/ai3/ignite-log/my-first-node.log
> Exception in thread "main" class org.apache.ignite.lang.IgniteException:
> Unable to read user specific configuration.
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:97)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:105)
> at
> org.apache.ignite.app.IgniteCliRunner.start(IgniteCliRunner.java:109)
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:44)
> Caused by: java.nio.file.NoSuchFileException:
> /home/zloddey/opt/ai3/~/work/apache/ignite-3/examples/config/ignite-config.json
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
> at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
> at java.base/java.nio.file.Files.newByteChannel(Files.java:422)
> at java.base/java.nio.file.Files.readAllBytes(Files.java:3206)
> at java.base/java.nio.file.Files.readString(Files.java:3284)
> at java.base/java.nio.file.Files.readString(Files.java:3243)
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:92)
> ... 3 more
> {code}
> When I use {{/home/zloddey}} or {{$HOME}} instead of tilde, it works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18177) Clarify DEVNOTES.md in modules/platforms/cpp
Ivan Artukhov created IGNITE-18177: -- Summary: Clarify DEVNOTES.md in modules/platforms/cpp Key: IGNITE-18177 URL: https://issues.apache.org/jira/browse/IGNITE-18177 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 3.0.0-beta1 Reporter: Ivan Artukhov I've checked C++ module in Apache Ignite 3 beta1 RC2 (https://dist.apache.org/repos/dist/dev/ignite/3.0.0-beta1-rc2/apache-ignite-3.0.0-beta1-cpp.zip). Found no issues with building the module and running tests but DEVNOTES.md needs the following clarification of section "Build Java". * it is not clear whether a user needs to build the Java part of the project to run C++ tests. * `mvn` is deprecated in favor of `gradle` so `DEVNOTES.md` should not mention `mvn`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16778) Support timestamp through jdbc
[ https://issues.apache.org/jira/browse/IGNITE-16778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709303#comment-17709303 ] Ivan Artukhov commented on IGNITE-16778: [~jooger] FYI ^^^ > Support timestamp through jdbc > -- > > Key: IGNITE-16778 > URL: https://issues.apache.org/jira/browse/IGNITE-16778 > Project: Ignite > Issue Type: Bug > Components: jdbc >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > Attachments: RunnerForTestNode.java > > > Able to use timestamp data type through KV view by LocalDateTime, but no > through jdbc setTimestamp method. Example in attachment -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19275) Creation of big amount of tables throws exception
[
https://issues.apache.org/jira/browse/IGNITE-19275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17727447#comment-17727447
]
Ivan Artukhov commented on IGNITE-19275:
The issue looks fixed in https://issues.apache.org/jira/browse/IGNITE-19563.
> Creation of big amount of tables throws exception
> -
>
> Key: IGNITE-19275
> URL: https://issues.apache.org/jira/browse/IGNITE-19275
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 3.0
>Reporter: Igor
>Priority: Critical
> Labels: ignite-3
> Attachments: image-2023-04-11-16-11-09-934.png, node_0.log.zip,
> node_1.log.zip
>
>
> h1. *Steps:*
> # Sart 2 nodes
> # Init cluster
> # Connect to cluster via jdbc
> # Create table with 5 columns.
> # Wait 30 ms.
> # Repeat points 4-5 1000 times.
> h1. *Expected behavior:*
> # Creation time is constant.
> # Tables are created.
> h1. *Actual behavior:*
> # Creation time is increasing
> # The exception is thrown| after 200+ tables are created
> h2. *Details:*
> h3. Creation time graph:
> !image-2023-04-11-16-11-09-934.png|width=522,height=323!
> h3. Exceptions:
> # From client:
> {code:java}
> Exception in thread "main" java.sql.SQLException: Exception while executing
> query [query=CREATE TABLE table_239(id INT PRIMARY KEY, column_1 VARCHAR,
> column_2 VARCHAR, column_3 VARCHAR, column_4 VARCHAR)]. Error
> message:IGN-CMN-65535 TraceId:7299edda-2a88-4448-ba6d-366fca88cfd4
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:177)
> at lunigorn.ignite3test.Test.main(Test.java:18) {code}
> 2. From server logs:
> {code:java}
> 2023-04-11 15:13:49:881 +0200
> [WARNING][%node_1%Raft-Group-Client-5][SchemaManager] Error when processing
> CREATE event
> java.util.concurrent.CompletionException:
> org.apache.ignite.lang.IgniteInternalException: IGN-SQL-32
> TraceId:d3484efb-2ca6-4098-8c17-30a878c0801e Couldn't evaluate sql schemas
> for causality token: 722
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.lambda$copyState$6(BaseVersionedValue.java:305)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
> at
> java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.copyState(BaseVersionedValue.java:303)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.complete(BaseVersionedValue.java:189)
> at
> org.apache.ignite.internal.causality.CompletableVersionedValue.completeExceptionally(CompletableVersionedValue.java:101)
> at
> org.apache.ignite.internal.sql.engine.schema.SqlSchemaManagerImpl.lambda$new$1(SqlSchemaManagerImpl.java:131)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.lambda$notifyCompletionListeners$7(BaseVersionedValue.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
> at
> java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.notifyCompletionListeners(BaseVersionedValue.java:326)
> at
> org.apache.ignite.internal.causality.BaseVersionedValue.complete(BaseVersionedValue.java:198)
> at
> org.apache.ignite.internal.causality.IncrementalVersionedValue.lambda$completeInternal$1(IncrementalVersionedValue.java:236)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>
[jira] [Created] (IGNITE-19631) No way to pass JVM options when using bin/ignite3db
Ivan Artukhov created IGNITE-19631:
--
Summary: No way to pass JVM options when using bin/ignite3db
Key: IGNITE-19631
URL: https://issues.apache.org/jira/browse/IGNITE-19631
Project: Ignite
Issue Type: Bug
Reporter: Ivan Artukhov
There is no way to set custom JVM options when starting an Ignite node via
`bin/ignite3db` script.
The {{${IGNITE_HOME}/etc/vars.env}} file contains the
{{IGNITE3_EXTRA_JVM_ARGS}} parameter, but currently its value is placed after
the {{IgniteRunner}} in the command-line which is wrong. See
[bootstrap-functions.sh|https://github.com/apache/ignite-3/blob/ae3c4660ab9ae0be9a4f4bef84b002e9e392c243/packaging/common/bootstrap-functions.sh#L51].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19664:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Insufficient performance of key-value operations via Java thin client
> -
>
> Key: IGNITE-19664
> URL: https://issues.apache.org/jira/browse/IGNITE-19664
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ai3_embedded_20230606_083100.jfr.zip,
> ai3_thin_client_20230606_074305.jfr.zip, gc.log.20230606_074305,
> ignite-config.conf, ignite3db-0.log, ycsb-run8-thin.txt,
> ycsb-run9-embedded.txt
>
>
> Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
> YCSB key-value benchmarks:
> https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
> h1. Summary
> The performance of key-value {{put()}} operations may be ~1.5 worse if
> performed via Java thin client in comparison to similar {{put()}} operations
> performed within an embedded node.
> h1. Test 1. Thin client node
> h2. Steps
> Start a separate Ignite 3 node and a YCSB client which "100% inserts"
> workload.
> 1. Start an Apache Ignite 3 server node with the attached
> {{ignite-config.conf}}.
> 2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
> YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
> hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true
> -p operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=false -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Node's log: [^ignite3db-0.log]
> Node's GC log: [^gc.log.20230606_074305]
> Node's config: [^ignite-config.conf]
> YCSB log: [^ycsb-run8-thin.txt]
> h1. Test 2. Embedded node
> h2. Steps
> The following step will start YCSB with an embedded Ignite 3 node within the
> same JVM and the "100% insert" workload on that node.
> 1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
> site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
> ./workloads/workloadc -threads 4 -p dataintegrity=true -p
> operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=true -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 173993
> [OVERALL], Throughput(ops/sec), 5747.357652319346
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 614.723711
> [INSERT], MinLatency(us), 284
> [INSERT], MaxLatency(us), 342271
> [INSERT], 95thPercentileLatency(us), 1182
> [INSERT], 99thPercentileLatency(us), 3357
> [INSERT], Return=OK, 100
> {noformat}
> Whole YCSB log: [^ycsb-run9-embedded.txt]
> h1. Local machine specs
> Lenovo ThinkPad T15 Gen 1
> CPU: Intel i7-10510U (4 cores, 8 threads)
> RAM: 32 GiB DDR4-2666
> SSD: 512 GiB M.2 2242
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19665) High performance drop in key-value put() operations introduced between May 23 and June 5
[
https://issues.apache.org/jira/browse/IGNITE-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19665:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> High performance drop in key-value put() operations introduced between May 23
> and June 5
>
>
> Key: IGNITE-19665
> URL: https://issues.apache.org/jira/browse/IGNITE-19665
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ai3_embedded_20230606_144606.jfr.zip,
> ai3_thin_client_20230606_075104.jfr.zip, gc.log.20230606_075104,
> ignite-config.conf, ignite3db-0.log, run11-new-emb-jfr.txt, ycsb-run10.log
>
>
> This ticket is a product of subsequent work on
> https://issues.apache.org/jira/browse/IGNITE-19664.
> There are high (more than 4x on my local machine) performance drop in
> {{KeyValueView#put}} operations introduced somewhere between the following
> commit:
> {noformat}
> commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
> Author: Slava Koptilin
> Date: Tue May 23 10:17:53 2023 +0300
> IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
> {noformat}
> and the following one:
> {code:java}
> commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
> origin/HEAD)
> Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
> Date: Mon Jun 5 17:43:07 2023 +0300
> IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
> {code}
> The test is the "Test 1" from
> https://issues.apache.org/jira/browse/IGNITE-19664, i.e.:
> 1. Start an Ignite 3 server node with attached {{ignite-config.conf}}.
> {{raft.fsync=false}} is set in the config.
> 2. Start YCSB client which makes {{KeyValueView#put}} operations within a
> "100% insert" profile.
> Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x
> worse in terms of throughput:
> {code:java}
> [OVERALL], RunTime(ms), 1325870
> [OVERALL], Throughput(ops/sec), 754.2217562807816
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 5229.54584
> [INSERT], MinLatency(us), 1297
> [INSERT], MaxLatency(us), 164223
> [INSERT], 95thPercentileLatency(us), 9871
> [INSERT], 99thPercentileLatency(us), 14271
> [INSERT], Return=OK, 100
> {code}
> Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
> https://issues.apache.org/jira/browse/IGNITE-19664
> Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
> - node's config: [^ignite-config.conf]
> - node's log: [^ignite3db-0.log]
> - node's GC log: [^gc.log.20230606_075104]
> - YCSB client log: [^ycsb-run10.log]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19665) High performance drop in key-value put() operations introduced between May 23 and June 5
[
https://issues.apache.org/jira/browse/IGNITE-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19665:
---
Attachment: ai3_embedded_20230606_144606.jfr.zip
run11-new-emb-jfr.txt
> High performance drop in key-value put() operations introduced between May 23
> and June 5
>
>
> Key: IGNITE-19665
> URL: https://issues.apache.org/jira/browse/IGNITE-19665
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ai3_embedded_20230606_144606.jfr.zip,
> ai3_thin_client_20230606_075104.jfr.zip, gc.log.20230606_075104,
> ignite-config.conf, ignite3db-0.log, run11-new-emb-jfr.txt, ycsb-run10.log
>
>
> This ticket is a product of subsequent work on
> https://issues.apache.org/jira/browse/IGNITE-19664.
> There are high (more than 4x on my local machine) performance drop in
> {{KeyValueView#put}} operations introduced somewhere between the following
> commit:
> {noformat}
> commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
> Author: Slava Koptilin
> Date: Tue May 23 10:17:53 2023 +0300
> IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
> {noformat}
> and the following one:
> {code:java}
> commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
> origin/HEAD)
> Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
> Date: Mon Jun 5 17:43:07 2023 +0300
> IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
> {code}
> The test is the "Test 1" from
> https://issues.apache.org/jira/browse/IGNITE-19664, i.e.:
> 1. Start an Ignite 3 server node with attached {{ignite-config.conf}}.
> {{raft.fsync=false}} is set in the config.
> 2. Start YCSB client which makes {{KeyValueView#put}} operations within a
> "100% insert" profile.
> Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x
> worse in terms of throughput:
> {code:java}
> [OVERALL], RunTime(ms), 1325870
> [OVERALL], Throughput(ops/sec), 754.2217562807816
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 5229.54584
> [INSERT], MinLatency(us), 1297
> [INSERT], MaxLatency(us), 164223
> [INSERT], 95thPercentileLatency(us), 9871
> [INSERT], 99thPercentileLatency(us), 14271
> [INSERT], Return=OK, 100
> {code}
> Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
> https://issues.apache.org/jira/browse/IGNITE-19664
> Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
> - node's config: [^ignite-config.conf]
> - node's log: [^ignite3db-0.log]
> - node's GC log: [^gc.log.20230606_075104]
> - YCSB client log: [^ycsb-run10.log]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19665) High performance drop in key-value put() operations introduced between May 23 and June 5
[
https://issues.apache.org/jira/browse/IGNITE-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729778#comment-17729778
]
Ivan Artukhov commented on IGNITE-19665:
Results of the "Test 2. Embedded mode" from for the "new" commit
{{a2254434c403bc54685f05e0d6f51bef56abea2a}} are the same as for "old"
{{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} from
https://issues.apache.org/jira/browse/IGNITE-19664:
{code:java}
[OVERALL], RunTime(ms), 175194
[OVERALL], Throughput(ops/sec), 5707.958035092526
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 638.186869
[INSERT], MinLatency(us), 253
[INSERT], MaxLatency(us), 479487
[INSERT], 95thPercentileLatency(us), 1342
[INSERT], 99thPercentileLatency(us), 3825
[INSERT], Return=OK, 100
{code}
YCSB log: [^run11-new-emb-jfr.txt]
JFR: [^ai3_embedded_20230606_144606.jfr.zip]
> High performance drop in key-value put() operations introduced between May 23
> and June 5
>
>
> Key: IGNITE-19665
> URL: https://issues.apache.org/jira/browse/IGNITE-19665
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ai3_embedded_20230606_144606.jfr.zip,
> ai3_thin_client_20230606_075104.jfr.zip, gc.log.20230606_075104,
> ignite-config.conf, ignite3db-0.log, run11-new-emb-jfr.txt, ycsb-run10.log
>
>
> This ticket is a product of subsequent work on
> https://issues.apache.org/jira/browse/IGNITE-19664.
> There are high (more than 4x on my local machine) performance drop in
> {{KeyValueView#put}} operations introduced somewhere between the following
> commit:
> {noformat}
> commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
> Author: Slava Koptilin
> Date: Tue May 23 10:17:53 2023 +0300
> IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
> {noformat}
> and the following one:
> {code:java}
> commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
> origin/HEAD)
> Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
> Date: Mon Jun 5 17:43:07 2023 +0300
> IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
> {code}
> The test is the "Test 1" from
> https://issues.apache.org/jira/browse/IGNITE-19664, i.e.:
> 1. Start an Ignite 3 server node with attached {{ignite-config.conf}}.
> {{raft.fsync=false}} is set in the config.
> 2. Start YCSB client which makes {{KeyValueView#put}} operations within a
> "100% insert" profile.
> Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x
> worse in terms of throughput:
> {code:java}
> [OVERALL], RunTime(ms), 1325870
> [OVERALL], Throughput(ops/sec), 754.2217562807816
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 5229.54584
> [INSERT], MinLatency(us), 1297
> [INSERT], MaxLatency(us), 164223
> [INSERT], 95thPercentileLatency(us), 9871
> [INSERT], 99thPercentileLatency(us), 14271
> [INSERT], Return=OK, 100
> {code}
> Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
> https://issues.apache.org/jira/browse/IGNITE-19664
> Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
> - node's config: [^ignite-config.conf]
> - node's log: [^ignite3db-0.log]
> - node's GC log: [^gc.log.20230606_075104]
> - YCSB client log: [^ycsb-run10.log]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19615) Index is not used while performing SELECT over an indexed column
Ivan Artukhov created IGNITE-19615: -- Summary: Index is not used while performing SELECT over an indexed column Key: IGNITE-19615 URL: https://issues.apache.org/jira/browse/IGNITE-19615 Project: Ignite Issue Type: Bug Components: sql Reporter: Ivan Artukhov Performing SELECT on an indexed column does not utilize the index. This is shown on EXPLAIN query. ``` 11:35:27.760 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: create table index_test_table_1(id INTEGER not null, field_1 TINYINT, field_2 SMALLINT, field_3 INTEGER, field_4 FLOAT, field_5 VARCHAR(50), primary key (id)) 11:35:28.924 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: CREATE INDEX index_test_index_1_1 ON index_test_table_1 (field_2) Jun 01, 2023 11:35:28 AM org.apache.ignite.internal.logger.IgniteLogger logInternal INFO: Partition assignment change notification received [remoteAddress=localhost:10801] 11:35:29.003 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (0, 0, 0, 0, 0.0, 'string_value_0') 11:35:30.529 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (1, 1, 1, 1, 1.1, 'string_value_1') 11:35:30.571 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (2, 2, 2, 2, 2.2, 'string_value_2') 11:35:30.602 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (3, 3, 3, 3, 3.3003, 'string_value_3') 11:35:30.636 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (4, 4, 4, 4, 4.4, 'string_value_4') 11:35:30.669 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (5, 5, 5, 5, 5.5, 'string_value_5') 11:35:30.700 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (6, 6, 6, 6, 6.6005, 'string_value_6') 11:35:30.727 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (7, 7, 7, 7, 7.701, 'string_value_7') 11:35:30.755 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (8, 8, 8, 8, 8.8, 'string_value_8') 11:35:30.785 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (9, 9, 9, 9, 9.9, 'string_value_9') 11:35:30.819 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (10, 10, 10, 10, 11.0, 'string_value_10') 11:35:30.850 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (11, 11, 11, 11, 12.101, 'string_value_11') 11:35:30.881 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (12, 12, 12, 12, 13.201, 'string_value_12') 11:35:30.907 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (13, 13, 13, 13, 14.3, 'string_value_13') 11:35:30.932 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (14, 14, 14, 14, 15.402, 'string_value_14') 11:35:30.964 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (15, 15, 15, 15, 16.5, 'string_value_15') 11:35:30.998 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (16, 16, 16, 16, 17.6, 'string_value_16') 11:35:31.030 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests -- Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (17, 17, 17, 17, 18.703, 'string_value_17') 11:35:31.053 [Test worker] INFO
[jira] [Updated] (IGNITE-19615) Index is not used while performing SELECT over an indexed column
[ https://issues.apache.org/jira/browse/IGNITE-19615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Artukhov updated IGNITE-19615: --- Description: Apache Ignite 3, rev. faac3854f687daab2de4580fd9666fb227bf4c3a Performing SELECT on an indexed column does not utilize the index. This is shown on EXPLAIN query. ``` 11:35:27.760 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: create table index_test_table_1(id INTEGER not null, field_1 TINYINT, field_2 SMALLINT, field_3 INTEGER, field_4 FLOAT, field_5 VARCHAR(50), primary key (id)) 11:35:28.924 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: CREATE INDEX index_test_index_1_1 ON index_test_table_1 (field_2) Jun 01, 2023 11:35:28 AM org.apache.ignite.internal.logger.IgniteLogger logInternal INFO: Partition assignment change notification received [remoteAddress=localhost:10801] 11:35:29.003 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (0, 0, 0, 0, 0.0, 'string_value_0') 11:35:30.529 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (1, 1, 1, 1, 1.1, 'string_value_1') 11:35:30.571 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (2, 2, 2, 2, 2.2, 'string_value_2') 11:35:30.602 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (3, 3, 3, 3, 3.3003, 'string_value_3') 11:35:30.636 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (4, 4, 4, 4, 4.4, 'string_value_4') 11:35:30.669 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (5, 5, 5, 5, 5.5, 'string_value_5') 11:35:30.700 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (6, 6, 6, 6, 6.6005, 'string_value_6') 11:35:30.727 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (7, 7, 7, 7, 7.701, 'string_value_7') 11:35:30.755 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (8, 8, 8, 8, 8.8, 'string_value_8') 11:35:30.785 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (9, 9, 9, 9, 9.9, 'string_value_9') 11:35:30.819 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (10, 10, 10, 10, 11.0, 'string_value_10') 11:35:30.850 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (11, 11, 11, 11, 12.101, 'string_value_11') 11:35:30.881 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (12, 12, 12, 12, 13.201, 'string_value_12') 11:35:30.907 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (13, 13, 13, 13, 14.3, 'string_value_13') 11:35:30.932 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (14, 14, 14, 14, 15.402, 'string_value_14') 11:35:30.964 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (15, 15, 15, 15, 16.5, 'string_value_15') 11:35:30.998 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (16, 16, 16, 16, 17.6, 'string_value_16') 11:35:31.030 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5) VALUES (17, 17, 17, 17, 18.703, 'string_value_17') 11:35:31.053 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4, field_5)
[jira] [Updated] (IGNITE-19615) Index is not used while performing SELECT over an indexed column
[
https://issues.apache.org/jira/browse/IGNITE-19615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19615:
---
Description:
Apache Ignite 3, rev. faac3854f687daab2de4580fd9666fb227bf4c3a
Performing SELECT on an indexed column does not utilize the index. This is
shown on EXPLAIN query.
{noformat}
11:35:27.760 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: create table index_test_table_1(id INTEGER not null, field_1 TINYINT,
field_2 SMALLINT, field_3 INTEGER, field_4 FLOAT, field_5 VARCHAR(50), primary
key (id))
11:35:28.924 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: CREATE INDEX index_test_index_1_1 ON index_test_table_1 (field_2)
Jun 01, 2023 11:35:28 AM org.apache.ignite.internal.logger.IgniteLogger
logInternal
INFO: Partition assignment change notification received
[remoteAddress=localhost:10801]
11:35:29.003 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (0, 0, 0, 0, 0.0, 'string_value_0')
11:35:30.529 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (1, 1, 1, 1, 1.1, 'string_value_1')
11:35:30.571 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (2, 2, 2, 2, 2.2, 'string_value_2')
...
11:35:33.189 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (97, 97, 97, 97, 106.7, 'string_value_97')
11:35:33.212 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (98, 98, 98, 98, 107.81, 'string_value_98')
11:35:33.236 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (99, 99, 99, 99, 108.9, 'string_value_99')
11:35:33.258 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Query:
SELECT * FROM index_test_table_1 WHERE field_2 = 50
11:35:33.513 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests – Query:
explain plan for SELECT * FROM index_test_table_1 WHERE field_2 = 50
11:35:33.565 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Result: IgniteExchange(distribution=[single]): rowcount = 1500.0, cumulative
cost = IgniteCost [rowCount=11500.0, cpu=41500.0, memory=0.0, io=24.0,
network=36000.0], id = 10103
IgniteTableScan(table=[[PUBLIC, INDEX_TEST_TABLE_1]],
tableId=[8239005d-346b-40d9-afe7-c15923ef3020], filters=[=(CAST($t2):INTEGER,
50)], requiredColumns=[
{0, 1, 2, 3, 4, 5}
]): rowcount = 1500.0, cumulative cost = IgniteCost [rowCount=1.0,
cpu=4.0, memory=0.0, io=24.0, network=0.0], id = 10102
{noformat}
It is expected that {{explain plan for SELECT * FROM index_test_table_1 WHERE
field_2 = 50}} query will contain {{IgniteIndexScan` with
`index_test_index_1_1}}.
was:
Apache Ignite 3, rev. faac3854f687daab2de4580fd9666fb227bf4c3a
Performing SELECT on an indexed column does not utilize the index. This is
shown on EXPLAIN query.
```
11:35:27.760 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: create table index_test_table_1(id INTEGER not null, field_1 TINYINT,
field_2 SMALLINT, field_3 INTEGER, field_4 FLOAT, field_5 VARCHAR(50), primary
key (id))
11:35:28.924 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: CREATE INDEX index_test_index_1_1 ON index_test_table_1 (field_2)
Jun 01, 2023 11:35:28 AM org.apache.ignite.internal.logger.IgniteLogger
logInternal
INFO: Partition assignment change notification received
[remoteAddress=localhost:10801]
11:35:29.003 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (0, 0, 0, 0, 0.0, 'string_value_0')
11:35:30.529 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (1, 1, 1, 1, 1.1, 'string_value_1')
11:35:30.571 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (2, 2, 2, 2, 2.2, 'string_value_2')
11:35:30.602 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2, field_3, field_4,
field_5) VALUES (3, 3, 3, 3, 3.3003, 'string_value_3')
11:35:30.636 [Test worker] INFO org.gridgain.ai3tests.tests.IndexTests –
Update: INSERT INTO index_test_table_1 (id, field_1, field_2,
[jira] [Created] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
Ivan Artukhov created IGNITE-19664:
--
Summary: Insufficient performance of key-value operations via Java
thin client
Key: IGNITE-19664
URL: https://issues.apache.org/jira/browse/IGNITE-19664
Project: Ignite
Issue Type: Bug
Reporter: Ivan Artukhov
Attachments: gc.log.20230606_074305, ignite-config.conf,
ignite3db-0.log, ycsb-run8-thin.txt, ycsb-run9-embedded.txt
Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
YCSB key-value benchmarks:
https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
h1. Summary
The performance of key-value {{put()}} operations may be ~1.5 worse if
performed via Java thin client in comparison to similar {{put()}} operations
performed within an embedded node.
h1. Test 1. Thin client node
h2. Steps
Start a separate Ignite 3 node and a YCSB client which "100% inserts" workload.
1. Start an Apache Ignite 3 server node with the attached
{{ignite-config.conf}}.
2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=false -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[CLEANUP], Operations, 4
[CLEANUP], AverageLatency(us), 2487301.25
[CLEANUP], MinLatency(us), 4
[CLEANUP], MaxLatency(us), 9953279
[CLEANUP], 95thPercentileLatency(us), 9953279
[CLEANUP], 99thPercentileLatency(us), 9953279
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Node's log: [^ignite3db-0.log]
Node's GC log: [^gc.log.20230606_074305]
Node's config: [^ignite-config.conf]
YCSB log: [^ycsb-run8-thin.txt]
h1. Test 2. Embedded node
h2. Steps
The following step will start YCSB with an embedded Ignite 3 node within the
same JVM and the "100% insert" workload on that node.
1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=true -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 173993
[OVERALL], Throughput(ops/sec), 5747.357652319346
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 614.723711
[INSERT], MinLatency(us), 284
[INSERT], MaxLatency(us), 342271
[INSERT], 95thPercentileLatency(us), 1182
[INSERT], 99thPercentileLatency(us), 3357
[INSERT], Return=OK, 100
{noformat}
Whole YCSB log: [^ycsb-run9-embedded.txt]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19664:
---
Description:
Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
YCSB key-value benchmarks:
https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
h1. Summary
The performance of key-value {{put()}} operations may be ~1.5 worse if
performed via Java thin client in comparison to similar {{put()}} operations
performed within an embedded node.
h1. Test 1. Thin client node
h2. Steps
Start a separate Ignite 3 node and a YCSB client which "100% inserts" workload.
1. Start an Apache Ignite 3 server node with the attached
{{ignite-config.conf}}.
2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=false -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[CLEANUP], Operations, 4
[CLEANUP], AverageLatency(us), 2487301.25
[CLEANUP], MinLatency(us), 4
[CLEANUP], MaxLatency(us), 9953279
[CLEANUP], 95thPercentileLatency(us), 9953279
[CLEANUP], 99thPercentileLatency(us), 9953279
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Node's log: [^ignite3db-0.log]
Node's GC log: [^gc.log.20230606_074305]
Node's config: [^ignite-config.conf]
YCSB log: [^ycsb-run8-thin.txt]
h1. Test 2. Embedded node
h2. Steps
The following step will start YCSB with an embedded Ignite 3 node within the
same JVM and the "100% insert" workload on that node.
1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=true -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 173993
[OVERALL], Throughput(ops/sec), 5747.357652319346
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 614.723711
[INSERT], MinLatency(us), 284
[INSERT], MaxLatency(us), 342271
[INSERT], 95thPercentileLatency(us), 1182
[INSERT], 99thPercentileLatency(us), 3357
[INSERT], Return=OK, 100
{noformat}
Whole YCSB log: [^ycsb-run9-embedded.txt]
h1. Local machine specs
Lenovo ThinkPad T15 Gen 1
CPU: Intel i7-10510U (4 cores, 8 threads)
RAM: 32 GiB DDR4-2666
SSD: 512 GiB M.2 2242
was:
Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
YCSB key-value benchmarks:
https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
h1. Summary
The performance of key-value {{put()}} operations may be ~1.5 worse if
performed via Java thin client in comparison to similar {{put()}} operations
performed within an embedded node.
h1. Test 1. Thin client node
h2. Steps
Start a separate Ignite 3 node and a YCSB client which "100% inserts" workload.
1. Start an Apache Ignite 3 server node with the attached
{{ignite-config.conf}}.
2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=false -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[CLEANUP], Operations, 4
[CLEANUP], AverageLatency(us), 2487301.25
[CLEANUP], MinLatency(us), 4
[CLEANUP], MaxLatency(us), 9953279
[CLEANUP], 95thPercentileLatency(us), 9953279
[CLEANUP], 99thPercentileLatency(us), 9953279
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Node's log: [^ignite3db-0.log]
Node's GC log: [^gc.log.20230606_074305]
Node's config: [^ignite-config.conf]
YCSB log: [^ycsb-run8-thin.txt]
h1. Test 2. Embedded node
h2. Steps
The following step will start YCSB with an embedded Ignite 3 node within the
same JVM and the "100% insert" workload on that node.
1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=true -load}}
h2. Results
{noformat}
[jira] [Updated] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19664:
---
Attachment: ai3_thin_client_20230606_074305.jfr.zip
> Insufficient performance of key-value operations via Java thin client
> -
>
> Key: IGNITE-19664
> URL: https://issues.apache.org/jira/browse/IGNITE-19664
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3
> Attachments: ai3_embedded_20230606_083100.jfr.zip,
> ai3_thin_client_20230606_074305.jfr.zip, gc.log.20230606_074305,
> ignite-config.conf, ignite3db-0.log, ycsb-run8-thin.txt,
> ycsb-run9-embedded.txt
>
>
> Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
> YCSB key-value benchmarks:
> https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
> h1. Summary
> The performance of key-value {{put()}} operations may be ~1.5 worse if
> performed via Java thin client in comparison to similar {{put()}} operations
> performed within an embedded node.
> h1. Test 1. Thin client node
> h2. Steps
> Start a separate Ignite 3 node and a YCSB client which "100% inserts"
> workload.
> 1. Start an Apache Ignite 3 server node with the attached
> {{ignite-config.conf}}.
> 2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
> YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
> hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true
> -p operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=false -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [CLEANUP], Operations, 4
> [CLEANUP], AverageLatency(us), 2487301.25
> [CLEANUP], MinLatency(us), 4
> [CLEANUP], MaxLatency(us), 9953279
> [CLEANUP], 95thPercentileLatency(us), 9953279
> [CLEANUP], 99thPercentileLatency(us), 9953279
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Node's log: [^ignite3db-0.log]
> Node's GC log: [^gc.log.20230606_074305]
> Node's config: [^ignite-config.conf]
> YCSB log: [^ycsb-run8-thin.txt]
> h1. Test 2. Embedded node
> h2. Steps
> The following step will start YCSB with an embedded Ignite 3 node within the
> same JVM and the "100% insert" workload on that node.
> 1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
> site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
> ./workloads/workloadc -threads 4 -p dataintegrity=true -p
> operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=true -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 173993
> [OVERALL], Throughput(ops/sec), 5747.357652319346
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 614.723711
> [INSERT], MinLatency(us), 284
> [INSERT], MaxLatency(us), 342271
> [INSERT], 95thPercentileLatency(us), 1182
> [INSERT], 99thPercentileLatency(us), 3357
> [INSERT], Return=OK, 100
> {noformat}
> Whole YCSB log: [^ycsb-run9-embedded.txt]
> h1. Local machine specs
> Lenovo ThinkPad T15 Gen 1
> CPU: Intel i7-10510U (4 cores, 8 threads)
> RAM: 32 GiB DDR4-2666
> SSD: 512 GiB M.2 2242
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19664:
---
Attachment: ai3_embedded_20230606_083100.jfr.zip
> Insufficient performance of key-value operations via Java thin client
> -
>
> Key: IGNITE-19664
> URL: https://issues.apache.org/jira/browse/IGNITE-19664
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3
> Attachments: ai3_embedded_20230606_083100.jfr.zip,
> ai3_thin_client_20230606_074305.jfr.zip, gc.log.20230606_074305,
> ignite-config.conf, ignite3db-0.log, ycsb-run8-thin.txt,
> ycsb-run9-embedded.txt
>
>
> Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
> YCSB key-value benchmarks:
> https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
> h1. Summary
> The performance of key-value {{put()}} operations may be ~1.5 worse if
> performed via Java thin client in comparison to similar {{put()}} operations
> performed within an embedded node.
> h1. Test 1. Thin client node
> h2. Steps
> Start a separate Ignite 3 node and a YCSB client which "100% inserts"
> workload.
> 1. Start an Apache Ignite 3 server node with the attached
> {{ignite-config.conf}}.
> 2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
> YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
> hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true
> -p operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=false -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [CLEANUP], Operations, 4
> [CLEANUP], AverageLatency(us), 2487301.25
> [CLEANUP], MinLatency(us), 4
> [CLEANUP], MaxLatency(us), 9953279
> [CLEANUP], 95thPercentileLatency(us), 9953279
> [CLEANUP], 99thPercentileLatency(us), 9953279
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Node's log: [^ignite3db-0.log]
> Node's GC log: [^gc.log.20230606_074305]
> Node's config: [^ignite-config.conf]
> YCSB log: [^ycsb-run8-thin.txt]
> h1. Test 2. Embedded node
> h2. Steps
> The following step will start YCSB with an embedded Ignite 3 node within the
> same JVM and the "100% insert" workload on that node.
> 1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
> site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
> ./workloads/workloadc -threads 4 -p dataintegrity=true -p
> operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=true -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 173993
> [OVERALL], Throughput(ops/sec), 5747.357652319346
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 614.723711
> [INSERT], MinLatency(us), 284
> [INSERT], MaxLatency(us), 342271
> [INSERT], 95thPercentileLatency(us), 1182
> [INSERT], 99thPercentileLatency(us), 3357
> [INSERT], Return=OK, 100
> {noformat}
> Whole YCSB log: [^ycsb-run9-embedded.txt]
> h1. Local machine specs
> Lenovo ThinkPad T15 Gen 1
> CPU: Intel i7-10510U (4 cores, 8 threads)
> RAM: 32 GiB DDR4-2666
> SSD: 512 GiB M.2 2242
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729749#comment-17729749
]
Ivan Artukhov commented on IGNITE-19664:
Attached JFRs.
[^ai3_thin_client_20230606_074305.jfr.zip] -- JFR from the server node of Test
1.
[^ai3_embedded_20230606_083100.jfr.zip] -- JFR from the Test 2 (both server
node and a client node share the same JVM).
> Insufficient performance of key-value operations via Java thin client
> -
>
> Key: IGNITE-19664
> URL: https://issues.apache.org/jira/browse/IGNITE-19664
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3
> Attachments: ai3_embedded_20230606_083100.jfr.zip,
> ai3_thin_client_20230606_074305.jfr.zip, gc.log.20230606_074305,
> ignite-config.conf, ignite3db-0.log, ycsb-run8-thin.txt,
> ycsb-run9-embedded.txt
>
>
> Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
> YCSB key-value benchmarks:
> https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
> h1. Summary
> The performance of key-value {{put()}} operations may be ~1.5 worse if
> performed via Java thin client in comparison to similar {{put()}} operations
> performed within an embedded node.
> h1. Test 1. Thin client node
> h2. Steps
> Start a separate Ignite 3 node and a YCSB client which "100% inserts"
> workload.
> 1. Start an Apache Ignite 3 server node with the attached
> {{ignite-config.conf}}.
> 2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
> YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
> hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true
> -p operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=false -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [CLEANUP], Operations, 4
> [CLEANUP], AverageLatency(us), 2487301.25
> [CLEANUP], MinLatency(us), 4
> [CLEANUP], MaxLatency(us), 9953279
> [CLEANUP], 95thPercentileLatency(us), 9953279
> [CLEANUP], 99thPercentileLatency(us), 9953279
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Node's log: [^ignite3db-0.log]
> Node's GC log: [^gc.log.20230606_074305]
> Node's config: [^ignite-config.conf]
> YCSB log: [^ycsb-run8-thin.txt]
> h1. Test 2. Embedded node
> h2. Steps
> The following step will start YCSB with an embedded Ignite 3 node within the
> same JVM and the "100% insert" workload on that node.
> 1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
> site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
> ./workloads/workloadc -threads 4 -p dataintegrity=true -p
> operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=true -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 173993
> [OVERALL], Throughput(ops/sec), 5747.357652319346
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 614.723711
> [INSERT], MinLatency(us), 284
> [INSERT], MaxLatency(us), 342271
> [INSERT], 95thPercentileLatency(us), 1182
> [INSERT], 99thPercentileLatency(us), 3357
> [INSERT], Return=OK, 100
> {noformat}
> Whole YCSB log: [^ycsb-run9-embedded.txt]
> h1. Local machine specs
> Lenovo ThinkPad T15 Gen 1
> CPU: Intel i7-10510U (4 cores, 8 threads)
> RAM: 32 GiB DDR4-2666
> SSD: 512 GiB M.2 2242
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19664:
---
Description:
Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
YCSB key-value benchmarks:
https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
h1. Summary
The performance of key-value {{put()}} operations may be ~1.5 worse if
performed via Java thin client in comparison to similar {{put()}} operations
performed within an embedded node.
h1. Test 1. Thin client node
h2. Steps
Start a separate Ignite 3 node and a YCSB client which "100% inserts" workload.
1. Start an Apache Ignite 3 server node with the attached
{{ignite-config.conf}}.
2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=false -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[CLEANUP], Operations, 4
[CLEANUP], AverageLatency(us), 2487301.25
[CLEANUP], MinLatency(us), 4
[CLEANUP], MaxLatency(us), 9953279
[CLEANUP], 95thPercentileLatency(us), 9953279
[CLEANUP], 99thPercentileLatency(us), 9953279
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Node's log: [^ignite3db-0.log]
Node's GC log: [^gc.log.20230606_074305]
Node's config: [^ignite-config.conf]
YCSB log: [^ycsb-run8-thin.txt]
h1. Test 2. Embedded node
h2. Steps
The following steps will start YCSB with an embedded Ignite 3 node within the
same JVM and the "100% insert" workload on that node.
1. Ensure that the node started in the Test 1 are stopped.
2. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=true -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 173993
[OVERALL], Throughput(ops/sec), 5747.357652319346
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 614.723711
[INSERT], MinLatency(us), 284
[INSERT], MaxLatency(us), 342271
[INSERT], 95thPercentileLatency(us), 1182
[INSERT], 99thPercentileLatency(us), 3357
[INSERT], Return=OK, 100
{noformat}
Whole YCSB log: [^ycsb-run9-embedded.txt]
h1. Local machine specs
Lenovo ThinkPad T15 Gen 1
CPU: Intel i7-10510U (4 cores, 8 threads)
RAM: 32 GiB DDR4-2666
SSD: 512 GiB M.2 2242
was:
Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
YCSB key-value benchmarks:
https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
h1. Summary
The performance of key-value {{put()}} operations may be ~1.5 worse if
performed via Java thin client in comparison to similar {{put()}} operations
performed within an embedded node.
h1. Test 1. Thin client node
h2. Steps
Start a separate Ignite 3 node and a YCSB client which "100% inserts" workload.
1. Start an Apache Ignite 3 server node with the attached
{{ignite-config.conf}}.
2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=false -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[CLEANUP], Operations, 4
[CLEANUP], AverageLatency(us), 2487301.25
[CLEANUP], MinLatency(us), 4
[CLEANUP], MaxLatency(us), 9953279
[CLEANUP], 95thPercentileLatency(us), 9953279
[CLEANUP], 99thPercentileLatency(us), 9953279
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Node's log: [^ignite3db-0.log]
Node's GC log: [^gc.log.20230606_074305]
Node's config: [^ignite-config.conf]
YCSB log: [^ycsb-run8-thin.txt]
h1. Test 2. Embedded node
h2. Steps
The following step will start YCSB with an embedded Ignite 3 node within the
same JVM and the "100% insert" workload on that node.
1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p
[jira] [Updated] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19664:
---
Description:
Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
YCSB key-value benchmarks:
https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
h1. Summary
The performance of key-value {{put()}} operations may be ~1.5 worse if
performed via Java thin client in comparison to similar {{put()}} operations
performed within an embedded node.
h1. Test 1. Thin client node
h2. Steps
Start a separate Ignite 3 node and a YCSB client which "100% inserts" workload.
1. Start an Apache Ignite 3 server node with the attached
{{ignite-config.conf}}.
2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=false -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Node's log: [^ignite3db-0.log]
Node's GC log: [^gc.log.20230606_074305]
Node's config: [^ignite-config.conf]
YCSB log: [^ycsb-run8-thin.txt]
h1. Test 2. Embedded node
h2. Steps
The following step will start YCSB with an embedded Ignite 3 node within the
same JVM and the "100% insert" workload on that node.
1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=true -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 173993
[OVERALL], Throughput(ops/sec), 5747.357652319346
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 614.723711
[INSERT], MinLatency(us), 284
[INSERT], MaxLatency(us), 342271
[INSERT], 95thPercentileLatency(us), 1182
[INSERT], 99thPercentileLatency(us), 3357
[INSERT], Return=OK, 100
{noformat}
Whole YCSB log: [^ycsb-run9-embedded.txt]
h1. Local machine specs
Lenovo ThinkPad T15 Gen 1
CPU: Intel i7-10510U (4 cores, 8 threads)
RAM: 32 GiB DDR4-2666
SSD: 512 GiB M.2 2242
was:
Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
YCSB key-value benchmarks:
https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
h1. Summary
The performance of key-value {{put()}} operations may be ~1.5 worse if
performed via Java thin client in comparison to similar {{put()}} operations
performed within an embedded node.
h1. Test 1. Thin client node
h2. Steps
Start a separate Ignite 3 node and a YCSB client which "100% inserts" workload.
1. Start an Apache Ignite 3 server node with the attached
{{ignite-config.conf}}.
2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=false -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[CLEANUP], Operations, 4
[CLEANUP], AverageLatency(us), 2487301.25
[CLEANUP], MinLatency(us), 4
[CLEANUP], MaxLatency(us), 9953279
[CLEANUP], 95thPercentileLatency(us), 9953279
[CLEANUP], 99thPercentileLatency(us), 9953279
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Node's log: [^ignite3db-0.log]
Node's GC log: [^gc.log.20230606_074305]
Node's config: [^ignite-config.conf]
YCSB log: [^ycsb-run8-thin.txt]
h1. Test 2. Embedded node
h2. Steps
The following steps will start YCSB with an embedded Ignite 3 node within the
same JVM and the "100% insert" workload on that node.
1. Ensure that the node started in the Test 1 are stopped.
2. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
./workloads/workloadc -threads 4 -p dataintegrity=true -p
operationcount=100 -p recordcount=100 -p disableFsync=true -p
useEmbedded=true -load}}
h2. Results
{noformat}
[OVERALL], RunTime(ms), 173993
[OVERALL], Throughput(ops/sec), 5747.357652319346
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 614.723711
[INSERT],
[jira] [Created] (IGNITE-19665) High performance drop in key-value put() operations introduced between May 23 and June 5
Ivan Artukhov created IGNITE-19665:
--
Summary: High performance drop in key-value put() operations
introduced between May 23 and June 5
Key: IGNITE-19665
URL: https://issues.apache.org/jira/browse/IGNITE-19665
Project: Ignite
Issue Type: Bug
Reporter: Ivan Artukhov
Attachments: gc.log.20230606_075104, ignite-config.conf,
ignite3db-0.log, ycsb-run10.log
This ticket is a product of subsequent work on
https://issues.apache.org/jira/browse/IGNITE-19664.
There are high (more than 4x on my local machine) performance drop in
{{KeyValueView#put}} operations introduced somewhere between the following
commit:
{noformat}
commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
Author: Slava Koptilin
Date: Tue May 23 10:17:53 2023 +0300
IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
{noformat}
and the following one:
{code:java}
commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
origin/HEAD)
Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
Date: Mon Jun 5 17:43:07 2023 +0300
IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
{code}
The test is the "Test 1" from
https://issues.apache.org/jira/browse/IGNITE-19664, i.e. YCSB client which
makes {{KeyValueView#put}} operations within a "100% insert" profile.
Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x worse
in terms of throughput:
{code:java}
[OVERALL], RunTime(ms), 1325870
[OVERALL], Throughput(ops/sec), 754.2217562807816
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 5229.54584
[INSERT], MinLatency(us), 1297
[INSERT], MaxLatency(us), 164223
[INSERT], 95thPercentileLatency(us), 9871
[INSERT], 99thPercentileLatency(us), 14271
[INSERT], Return=OK, 100
{code}
Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
https://issues.apache.org/jira/browse/IGNITE-19664
Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
- node's config: [^ignite-config.conf]
- node's log: [^ignite3db-0.log]
- node's GC log: [^gc.log.20230606_075104]
- YCSB client log: [^ycsb-run10.log]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19664) Insufficient performance of key-value operations via Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19664:
---
Labels: ignite-3 performance (was: ignite-3)
> Insufficient performance of key-value operations via Java thin client
> -
>
> Key: IGNITE-19664
> URL: https://issues.apache.org/jira/browse/IGNITE-19664
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ai3_embedded_20230606_083100.jfr.zip,
> ai3_thin_client_20230606_074305.jfr.zip, gc.log.20230606_074305,
> ignite-config.conf, ignite3db-0.log, ycsb-run8-thin.txt,
> ycsb-run9-embedded.txt
>
>
> Apache Ignite 3, rev. 0c68cbe3f016e508bd9d53ce5320c88acba1acff
> YCSB key-value benchmarks:
> https://github.com/gridgain/YCSB/tree/ae687c3bbd82eb7ce7b886af9a2ae2757457097c/ignite3
> h1. Summary
> The performance of key-value {{put()}} operations may be ~1.5 worse if
> performed via Java thin client in comparison to similar {{put()}} operations
> performed within an embedded node.
> h1. Test 1. Thin client node
> h2. Steps
> Start a separate Ignite 3 node and a YCSB client which "100% inserts"
> workload.
> 1. Start an Apache Ignite 3 server node with the attached
> {{ignite-config.conf}}.
> 2. Start a YCSB client node which performs {{KeyValueView#put}} operations.
> YCSB command line options: {{-db site.ycsb.db.ignite3.IgniteClient -p
> hosts=127.0.0.1 -s -P ./workloads/workloadc -threads 4 -p dataintegrity=true
> -p operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=false -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Node's log: [^ignite3db-0.log]
> Node's GC log: [^gc.log.20230606_074305]
> Node's config: [^ignite-config.conf]
> YCSB log: [^ycsb-run8-thin.txt]
> h1. Test 2. Embedded node
> h2. Steps
> The following step will start YCSB with an embedded Ignite 3 node within the
> same JVM and the "100% insert" workload on that node.
> 1. Run YCSB with the {{useEmbedded=true}} parameter: {{-db
> site.ycsb.db.ignite3.IgniteClient -p hosts=127.0.0.1 -s -P
> ./workloads/workloadc -threads 4 -p dataintegrity=true -p
> operationcount=100 -p recordcount=100 -p disableFsync=true -p
> useEmbedded=true -load}}
> h2. Results
> {noformat}
> [OVERALL], RunTime(ms), 173993
> [OVERALL], Throughput(ops/sec), 5747.357652319346
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 614.723711
> [INSERT], MinLatency(us), 284
> [INSERT], MaxLatency(us), 342271
> [INSERT], 95thPercentileLatency(us), 1182
> [INSERT], 99thPercentileLatency(us), 3357
> [INSERT], Return=OK, 100
> {noformat}
> Whole YCSB log: [^ycsb-run9-embedded.txt]
> h1. Local machine specs
> Lenovo ThinkPad T15 Gen 1
> CPU: Intel i7-10510U (4 cores, 8 threads)
> RAM: 32 GiB DDR4-2666
> SSD: 512 GiB M.2 2242
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19665) High performance drop in key-value put() operations introduced between May 23 and June 5
[
https://issues.apache.org/jira/browse/IGNITE-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19665:
---
Labels: ignite-3 performance (was: ignite-3)
> High performance drop in key-value put() operations introduced between May 23
> and June 5
>
>
> Key: IGNITE-19665
> URL: https://issues.apache.org/jira/browse/IGNITE-19665
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: gc.log.20230606_075104, ignite-config.conf,
> ignite3db-0.log, ycsb-run10.log
>
>
> This ticket is a product of subsequent work on
> https://issues.apache.org/jira/browse/IGNITE-19664.
> There are high (more than 4x on my local machine) performance drop in
> {{KeyValueView#put}} operations introduced somewhere between the following
> commit:
> {noformat}
> commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
> Author: Slava Koptilin
> Date: Tue May 23 10:17:53 2023 +0300
> IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
> {noformat}
> and the following one:
> {code:java}
> commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
> origin/HEAD)
> Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
> Date: Mon Jun 5 17:43:07 2023 +0300
> IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
> {code}
> The test is the "Test 1" from
> https://issues.apache.org/jira/browse/IGNITE-19664, i.e. YCSB client which
> makes {{KeyValueView#put}} operations within a "100% insert" profile.
> Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x
> worse in terms of throughput:
> {code:java}
> [OVERALL], RunTime(ms), 1325870
> [OVERALL], Throughput(ops/sec), 754.2217562807816
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 5229.54584
> [INSERT], MinLatency(us), 1297
> [INSERT], MaxLatency(us), 164223
> [INSERT], 95thPercentileLatency(us), 9871
> [INSERT], 99thPercentileLatency(us), 14271
> [INSERT], Return=OK, 100
> {code}
> Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
> https://issues.apache.org/jira/browse/IGNITE-19664
> Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
> - node's config: [^ignite-config.conf]
> - node's log: [^ignite3db-0.log]
> - node's GC log: [^gc.log.20230606_075104]
> - YCSB client log: [^ycsb-run10.log]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19665) High performance drop in key-value put() operations introduced between May 23 and June 5
[
https://issues.apache.org/jira/browse/IGNITE-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19665:
---
Description:
This ticket is a product of subsequent work on
https://issues.apache.org/jira/browse/IGNITE-19664.
There are high (more than 4x on my local machine) performance drop in
{{KeyValueView#put}} operations introduced somewhere between the following
commit:
{noformat}
commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
Author: Slava Koptilin
Date: Tue May 23 10:17:53 2023 +0300
IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
{noformat}
and the following one:
{code:java}
commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
origin/HEAD)
Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
Date: Mon Jun 5 17:43:07 2023 +0300
IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
{code}
The test is the "Test 1" from
https://issues.apache.org/jira/browse/IGNITE-19664, i.e.:
1. Start an Ignite 3 server node with attached {{ignite-config.conf}}.
{{raft.fsync=false}} is set in the config.
2. Start YCSB client which makes {{KeyValueView#put}} operations within a "100%
insert" profile.
Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x worse
in terms of throughput:
{code:java}
[OVERALL], RunTime(ms), 1325870
[OVERALL], Throughput(ops/sec), 754.2217562807816
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 5229.54584
[INSERT], MinLatency(us), 1297
[INSERT], MaxLatency(us), 164223
[INSERT], 95thPercentileLatency(us), 9871
[INSERT], 99thPercentileLatency(us), 14271
[INSERT], Return=OK, 100
{code}
Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
https://issues.apache.org/jira/browse/IGNITE-19664
Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
- node's config: [^ignite-config.conf]
- node's log: [^ignite3db-0.log]
- node's GC log: [^gc.log.20230606_075104]
- YCSB client log: [^ycsb-run10.log]
was:
This ticket is a product of subsequent work on
https://issues.apache.org/jira/browse/IGNITE-19664.
There are high (more than 4x on my local machine) performance drop in
{{KeyValueView#put}} operations introduced somewhere between the following
commit:
{noformat}
commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
Author: Slava Koptilin
Date: Tue May 23 10:17:53 2023 +0300
IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
{noformat}
and the following one:
{code:java}
commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
origin/HEAD)
Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
Date: Mon Jun 5 17:43:07 2023 +0300
IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
{code}
The test is the "Test 1" from
https://issues.apache.org/jira/browse/IGNITE-19664, i.e. YCSB client which
makes {{KeyValueView#put}} operations within a "100% insert" profile.
Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
{noformat}
[OVERALL], RunTime(ms), 282482
[OVERALL], Throughput(ops/sec), 3540.048569466373
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 1067.488346
[INSERT], MinLatency(us), 492
[INSERT], MaxLatency(us), 421375
[INSERT], 95thPercentileLatency(us), 2059
[INSERT], 99thPercentileLatency(us), 5151
[INSERT], Return=OK, 100
{noformat}
Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x worse
in terms of throughput:
{code:java}
[OVERALL], RunTime(ms), 1325870
[OVERALL], Throughput(ops/sec), 754.2217562807816
[INSERT], Operations, 100
[INSERT], AverageLatency(us), 5229.54584
[INSERT], MinLatency(us), 1297
[INSERT], MaxLatency(us), 164223
[INSERT], 95thPercentileLatency(us), 9871
[INSERT], 99thPercentileLatency(us), 14271
[INSERT], Return=OK, 100
{code}
Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
https://issues.apache.org/jira/browse/IGNITE-19664
Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
- node's config: [^ignite-config.conf]
- node's log: [^ignite3db-0.log]
- node's GC log: [^gc.log.20230606_075104]
- YCSB client log: [^ycsb-run10.log]
> High performance drop in key-value put() operations introduced between May 23
> and June 5
>
>
> Key: IGNITE-19665
> URL:
[jira] [Updated] (IGNITE-19665) High performance drop in key-value put() operations introduced between May 23 and June 5
[
https://issues.apache.org/jira/browse/IGNITE-19665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Artukhov updated IGNITE-19665:
---
Attachment: ai3_thin_client_20230606_075104.jfr.zip
> High performance drop in key-value put() operations introduced between May 23
> and June 5
>
>
> Key: IGNITE-19665
> URL: https://issues.apache.org/jira/browse/IGNITE-19665
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Artukhov
>Priority: Major
> Labels: ignite-3, performance
> Attachments: ai3_thin_client_20230606_075104.jfr.zip,
> gc.log.20230606_075104, ignite-config.conf, ignite3db-0.log, ycsb-run10.log
>
>
> This ticket is a product of subsequent work on
> https://issues.apache.org/jira/browse/IGNITE-19664.
> There are high (more than 4x on my local machine) performance drop in
> {{KeyValueView#put}} operations introduced somewhere between the following
> commit:
> {noformat}
> commit 0c68cbe3f016e508bd9d53ce5320c88acba1acff (HEAD)
> Author: Slava Koptilin
> Date: Tue May 23 10:17:53 2023 +0300
> IGNITE-17883 Removed not implemented 'invoke' functionality (#2090)
> {noformat}
> and the following one:
> {code:java}
> commit a2254434c403bc54685f05e0d6f51bef56abea2a (HEAD -> main, origin/main,
> origin/HEAD)
> Author: Vadim Pakhnushev <8614891+valep...@users.noreply.github.com>
> Date: Mon Jun 5 17:43:07 2023 +0300
> IGNITE-19559 NPE in deploy/undeploy calls in non-REPL mode (#2131)
> {code}
> The test is the "Test 1" from
> https://issues.apache.org/jira/browse/IGNITE-19664, i.e.:
> 1. Start an Ignite 3 server node with attached {{ignite-config.conf}}.
> {{raft.fsync=false}} is set in the config.
> 2. Start YCSB client which makes {{KeyValueView#put}} operations within a
> "100% insert" profile.
> Results for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}} were as follows:
> {noformat}
> [OVERALL], RunTime(ms), 282482
> [OVERALL], Throughput(ops/sec), 3540.048569466373
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 1067.488346
> [INSERT], MinLatency(us), 492
> [INSERT], MaxLatency(us), 421375
> [INSERT], 95thPercentileLatency(us), 2059
> [INSERT], 99thPercentileLatency(us), 5151
> [INSERT], Return=OK, 100
> {noformat}
> Results for {{a2254434c403bc54685f05e0d6f51bef56abea2a}} are more than 4x
> worse in terms of throughput:
> {code:java}
> [OVERALL], RunTime(ms), 1325870
> [OVERALL], Throughput(ops/sec), 754.2217562807816
> [INSERT], Operations, 100
> [INSERT], AverageLatency(us), 5229.54584
> [INSERT], MinLatency(us), 1297
> [INSERT], MaxLatency(us), 164223
> [INSERT], 95thPercentileLatency(us), 9871
> [INSERT], 99thPercentileLatency(us), 14271
> [INSERT], Return=OK, 100
> {code}
> Logs for {{0c68cbe3f016e508bd9d53ce5320c88acba1acff}}: see
> https://issues.apache.org/jira/browse/IGNITE-19664
> Logs for {{a2254434c403bc54685f05e0d6f51bef56abea2a}}:
> - node's config: [^ignite-config.conf]
> - node's log: [^ignite3db-0.log]
> - node's GC log: [^gc.log.20230606_075104]
> - YCSB client log: [^ycsb-run10.log]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
