[jira] [Created] (IGNITE-13391) Ignite-hibernate doesn't recreate cache proxies after full reconnect to the cluster
Evgenii Zhuravlev created IGNITE-13391: -- Summary: Ignite-hibernate doesn't recreate cache proxies after full reconnect to the cluster Key: IGNITE-13391 URL: https://issues.apache.org/jira/browse/IGNITE-13391 Project: Ignite Issue Type: Bug Components: hibernate Affects Versions: 2.7.6 Reporter: Evgenii Zhuravlev If there is only one server node in the cluster and user restart it, client node reconnects to the completely new cluster and, in order to continue using the ignite-hibernate integration, it should recreate all the cache proxies. Otherwise, it leads to the issue described in this thread: http://apache-ignite-users.70518.x6.nabble.com/Hibernate-2nd-Level-query-cache-with-Ignite-td33816.html We should add proxies reinitialization on reconnect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-12809:
---
Description:
Reproducer attached.
If result set is bigger than a page size(1 by default) and there are more than
10 fields in an object, then, for all rows after the first query column order
will be wrong. Looks like column order is being sorted as a string instead of
number.
The reason for that is a sorting in api/sql.py:
https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
If you remove it, everything will work fine. We need to make sure that this is
the right solution for this issue.
Output from reproducer:
{code:java}
['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME', 'GOVERNMENTFORM',
'HEADOFSTATE', 'CAPITAL', 'CODE2']
['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'), 'Zhongquo',
'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
Decimal('430572')]
['USA', 'United States', 'United States', 'Federal Republic', 'George W. Bush',
3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'), 1776,
278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
{code}
was:
Reproducer attached.
If result set is bigger than a page size(1 by default) and there are more than
10 fields in an object, then, for all rows after the first query column order
will be wrong.
The reason for that is a sorting in api/sql.py:
https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
If you remove it, everything will work fine. We need to make sure that this is
the right solution for this issue.
Output from reproducer:
{code:java}
['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME', 'GOVERNMENTFORM',
'HEADOFSTATE', 'CAPITAL', 'CODE2']
['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'), 'Zhongquo',
'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
Decimal('430572')]
['USA', 'United States', 'United States', 'Federal Republic', 'George W. Bush',
3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'), 1776,
278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
{code}
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Attachments: reproducer.py
>
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by
[jira] [Created] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
Evgenii Zhuravlev created IGNITE-12809:
--
Summary: Python client returns fields in wrong order since the 2
row when fields_count>10
Key: IGNITE-12809
URL: https://issues.apache.org/jira/browse/IGNITE-12809
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.8
Reporter: Evgenii Zhuravlev
Attachments: reproducer.py
Reproducer attached.
If result set is bigger than a page size(1 by default) and there are more than
10 fields in an object, then, for all rows after the first query column order
will be wrong.
The reason for that is a sorting in api/sql.py:
https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
If you remove it, everything will work fine. We need to make sure that this is
the right solution for this issue.
Output from reproducer:
{code:java}
['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME', 'GOVERNMENTFORM',
'HEADOFSTATE', 'CAPITAL', 'CODE2']
['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'), 'Zhongquo',
'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
Decimal('430572')]
['USA', 'United States', 'United States', 'Federal Republic', 'George W. Bush',
3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'), 1776,
278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9153) Accessing cache from transaction on client node, where it was not accessed yet throws an exception
[ https://issues.apache.org/jira/browse/IGNITE-9153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047072#comment-17047072 ] Evgenii Zhuravlev commented on IGNITE-9153: --- Hi, As a workaround, you can access the same cache before starting a transaction, it will solve this issue > Accessing cache from transaction on client node, where it was not accessed > yet throws an exception > -- > > Key: IGNITE-9153 > URL: https://issues.apache.org/jira/browse/IGNITE-9153 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: newbie > Attachments: ClientCacheTransactionsTest.java > > > Exception message: Cannot start/stop cache within lock or transaction. > Reproducer is attached: ClientCacheTransactionsTest.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
[
https://issues.apache.org/jira/browse/IGNITE-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-12032:
---
Labels: newbie usability (was: usability)
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: newbie, usability
>
> Whenever a process using ODBC clients is finished, it's printing in the
> node logs this exception:
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>
> Failed to process selector key [s
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
> finished=false, heartbeatTs=1564289118230, hashCo
> de=1829856117, interrupted=false,
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
> readBuf=null, inRecove
> ry=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioAsyn
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]], accepted=true, markedForClos
> e=false]]]
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:11
>
> 04)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNi
>
> oServer.java:2389)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:215
>
> 6)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
>
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)*
> {code}
> It's absolutely normal behavior when ODBC client disconnects from the node,
> so, we shouldn't print exception in the log. We should replace it with
> something like INFO message about ODBC client disconnection.
> Thread from user list:
> http://apache-ignite-users.70518.x6.nabble.com/exceptions-in-Ignite-node-when-a-thin-client-process-ends-td28970.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
Evgenii Zhuravlev created IGNITE-12032:
--
Summary: Server node prints exception when ODBC driver disconnects
Key: IGNITE-12032
URL: https://issues.apache.org/jira/browse/IGNITE-12032
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 2.7.5
Reporter: Evgenii Zhuravlev
Whenever a process using ODBC clients is finished, it's printing in the
node logs this exception:
{code:java}
*[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
Failed to process selector key [s
es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
[readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
finished=false, heartbeatTs=1564289118230, hashCo
de=1829856117, interrupted=false,
runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
readBuf=null, inRecove
ry=null, outRecovery=null, super=GridNioSessionImpl
[locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
filterChain=FilterChain[filters=[GridNioAsyn
cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
directMode=false]], accepted=true, markedForClos
e=false]]]
java.io.IOException: An existing connection was forcibly closed by the
remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:11
04)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNi
oServer.java:2389)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:215
6)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)*
{code}
It's absolutely normal behavior when ODBC client disconnects from the node, so,
we shouldn't print exception in the log. We should replace it with something
like INFO message about ODBC client disconnection.
Thread from user list:
http://apache-ignite-users.70518.x6.nabble.com/exceptions-in-Ignite-node-when-a-thin-client-process-ends-td28970.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (IGNITE-11373) varchar_ignorecase doesn't work properly
[
https://issues.apache.org/jira/browse/IGNITE-11373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev resolved IGNITE-11373.
Resolution: Duplicate
> varchar_ignorecase doesn't work properly
>
>
> Key: IGNITE-11373
> URL: https://issues.apache.org/jira/browse/IGNITE-11373
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Looks like a field with type varchar_ignorecase can't be used for filtering
> the values for different cases.
> {code:java}
> Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
>
> IgniteCache cache = ignite.getOrCreateCache("TEST");
> cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
> "(\n" +
> " TEST_IDNUMBER(15)NOT NULL,\n" +
> " TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
> " PRIMARY KEY (TEST_ID)\n" +
> ") "));
> System.out.println("INSERTED:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());
> System.out.println("FOUND:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("Select * from TEST where TEST_VALUE like
> '%aaa%'")).getAll().size());
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
[
https://issues.apache.org/jira/browse/IGNITE-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891744#comment-16891744
]
Evgenii Zhuravlev commented on IGNITE-12007:
[~dpavlov] that's not the reason to close the ticket. This is the real issue
and I see that users are facing it:
https://stackoverflow.com/questions/57179602/starting-webagent-on-apache-ignite-for-docker
> Latest "apacheignite/web-console-backend" docker image is broken
>
>
> Key: IGNITE-12007
> URL: https://issues.apache.org/jira/browse/IGNITE-12007
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.7
>Reporter: Igor Belyakov
>Priority: Critical
>
> It's not possible to run docker container by using the latest version of
> "apacheignite/web-console-backend" image.
> Next error happens on the start:
> {code:java}
> npm ERR! A complete log of this run can be found in:
> npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
> npm ERR! path /opt/web-console/package.json
> npm ERR! code ENOENT
> npm ERR! errno -2
> npm ERR! syscall open
> npm ERR! enoent ENOENT: no such file or directory, open
> '/opt/web-console/package.json'
> npm ERR! enoent This is related to npm not being able to find a file.
> npm ERR! enoent{code}
> How to reproduce:
> Run container by using docker-compose as described here:
> [https://hub.docker.com/r/apacheignite/web-console-backend]
>
> Seems like it was broken by the next commit:
> [https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879133#comment-16879133 ] Evgenii Zhuravlev commented on IGNITE-11312: [~surajsn], do you plan to implement this fix? I know that community is interested in it, so, if you can't implement it, maybe it makes sense to give an opportunity for someone else to step in and contribute it to the project. > JDBC: Thin driver doesn't reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Suraj Singh >Priority: Major > Labels: newbie > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.
[ https://issues.apache.org/jira/browse/IGNITE-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-5037: -- Labels: (was: newbie) > Fix broken @AffinityKeyMapped annotation for compute jobs. > -- > > Key: IGNITE-5037 > URL: https://issues.apache.org/jira/browse/IGNITE-5037 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Alexei Scherbakov >Priority: Major > > See related discussion on dev list entitled Proper collocation of > computations and data > (http://apache-ignite-developers.2346864.n4.nabble.com/Proper-collocation-of-computations-and-data-td16945.html). > We must repair data affinity routing for compute jobs. It should work same as > for affinityCall/Run with partition. > Currently, ComputeTask map method returns Map ClusterNode>, > but we have to provide some API allows to map ComputeJobs to partitions or > keys. > This can be done using AffinityKeyMapped annotation or any other way. > Since that's a publiс API any fixes should be discussed on dev list prior to > implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11847) Change note on the capacity planning page about memory usage
[ https://issues.apache.org/jira/browse/IGNITE-11847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-11847: -- Assignee: Artem Budnikov > Change note on the capacity planning page about memory usage > > > Key: IGNITE-11847 > URL: https://issues.apache.org/jira/browse/IGNITE-11847 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > https://apacheignite.readme.io/docs/capacity-planning#calculating-memory-usage > It says that "Apache Ignite will typically add around 200 bytes overhead to > each entry.", but it's not true, I think it was applicable only for 1.x > versions, where everything was stored in heap -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11847) Change note on the capacity planning page about memory usage
[ https://issues.apache.org/jira/browse/IGNITE-11847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11847: --- Affects Version/s: 2.7 > Change note on the capacity planning page about memory usage > > > Key: IGNITE-11847 > URL: https://issues.apache.org/jira/browse/IGNITE-11847 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.7 >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > https://apacheignite.readme.io/docs/capacity-planning#calculating-memory-usage > It says that "Apache Ignite will typically add around 200 bytes overhead to > each entry.", but it's not true, I think it was applicable only for 1.x > versions, where everything was stored in heap -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11847) Change note on the capacity planning page about memory usage
[ https://issues.apache.org/jira/browse/IGNITE-11847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11847: --- Component/s: documentation > Change note on the capacity planning page about memory usage > > > Key: IGNITE-11847 > URL: https://issues.apache.org/jira/browse/IGNITE-11847 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Evgenii Zhuravlev >Priority: Major > > https://apacheignite.readme.io/docs/capacity-planning#calculating-memory-usage > It says that "Apache Ignite will typically add around 200 bytes overhead to > each entry.", but it's not true, I think it was applicable only for 1.x > versions, where everything was stored in heap -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11847) Change note on the capacity planning page about memory usage
Evgenii Zhuravlev created IGNITE-11847: -- Summary: Change note on the capacity planning page about memory usage Key: IGNITE-11847 URL: https://issues.apache.org/jira/browse/IGNITE-11847 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev https://apacheignite.readme.io/docs/capacity-planning#calculating-memory-usage It says that "Apache Ignite will typically add around 200 bytes overhead to each entry.", but it's not true, I think it was applicable only for 1.x versions, where everything was stored in heap -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11832) Creating cache with EvictionPolicy and without onHeap cache kills the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11832: --- Priority: Critical (was: Major) > Creating cache with EvictionPolicy and without onHeap cache kills the cluster > - > > Key: IGNITE-11832 > URL: https://issues.apache.org/jira/browse/IGNITE-11832 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Priority: Critical > Labels: usability > > After this, the cluster can be restored only by deleting the folder with the > problem cache. We should add some kind of validation to avoid these > situations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11832) Creating cache with EvictionPolicy and without onHeap cache kills the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11832: --- Labels: usability (was: ) > Creating cache with EvictionPolicy and without onHeap cache kills the cluster > - > > Key: IGNITE-11832 > URL: https://issues.apache.org/jira/browse/IGNITE-11832 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: usability > > After this, the cluster can be restored only by deleting the folder with the > problem cache. We should add some kind of validation to avoid these > situations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11832) Creating cache with EvictionPolicy and without onHeap cache kills the cluster
Evgenii Zhuravlev created IGNITE-11832: -- Summary: Creating cache with EvictionPolicy and without onHeap cache kills the cluster Key: IGNITE-11832 URL: https://issues.apache.org/jira/browse/IGNITE-11832 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev After this, the cluster can be restored only by deleting the folder with the problem cache. We should add some kind of validation to avoid these situations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11831) Eviction doesn't work properly for data region with big objects of different sizes
[
https://issues.apache.org/jira/browse/IGNITE-11831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832411#comment-16832411
]
Evgenii Zhuravlev commented on IGNITE-11831:
can be fixed by adding
> Eviction doesn't work properly for data region with big objects of different
> sizes
> --
>
> Key: IGNITE-11831
> URL: https://issues.apache.org/jira/browse/IGNITE-11831
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Reproducer:
> {code:java}
> public class ExampleNodeStartup {
> /**
> * Start up an empty node with example compute configuration.
> *
> * @param args Command line arguments, none required.
> * @throws IgniteException If failed.
> */
> public static void main(String[] args) throws IgniteException {
> Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
> IgniteCache keywordCache =
> ignite.getOrCreateCache("keyword");
> for(int i=0;i<1000;i++){
> int mega = new Random().nextInt(3) + 1;
> keywordCache.put(UUID.randomUUID().toString(), new byte[mega *
> 1024 * 1024]);
> System.out.println("current:"+i);
> }
> }
> }
> {code}
> data region configuration:
> {code:java}
>
> class="org.apache.ignite.configuration.DataStorageConfiguration">
>
> class="org.apache.ignite.configuration.DataRegionConfiguration">
>
>
> value="RANDOM_2_LRU"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11831) Eviction doesn't work properly for data region with big objects of different sizes
Evgenii Zhuravlev created IGNITE-11831:
--
Summary: Eviction doesn't work properly for data region with big
objects of different sizes
Key: IGNITE-11831
URL: https://issues.apache.org/jira/browse/IGNITE-11831
Project: Ignite
Issue Type: Bug
Reporter: Evgenii Zhuravlev
Reproducer:
{code:java}
public class ExampleNodeStartup {
/**
* Start up an empty node with example compute configuration.
*
* @param args Command line arguments, none required.
* @throws IgniteException If failed.
*/
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
IgniteCache keywordCache =
ignite.getOrCreateCache("keyword");
for(int i=0;i<1000;i++){
int mega = new Random().nextInt(3) + 1;
keywordCache.put(UUID.randomUUID().toString(), new byte[mega * 1024
* 1024]);
System.out.println("current:"+i);
}
}
}
{code}
data region configuration:
{code:java}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11830) Visor cmd shows up time in HH:MM:SS format
Evgenii Zhuravlev created IGNITE-11830: -- Summary: Visor cmd shows up time in HH:MM:SS format Key: IGNITE-11830 URL: https://issues.apache.org/jira/browse/IGNITE-11830 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev Attachments: visor_uptime.png In Visor.scala it takes X.timeSpan2HMS(m.getUpTime), which lead to the behavior, that it starts to count starting from 00:00:00 after a day up time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11696) Create JMX metric for current PME execution time
[ https://issues.apache.org/jira/browse/IGNITE-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11696: --- Fix Version/s: 2.8 > Create JMX metric for current PME execution time > > > Key: IGNITE-11696 > URL: https://issues.apache.org/jira/browse/IGNITE-11696 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > Now PME process can't be monitored from JMX, only from the logs. It makes > sense to show the execution time for the current partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11696) Create JMX metric for current PME execution time
[ https://issues.apache.org/jira/browse/IGNITE-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815201#comment-16815201 ] Evgenii Zhuravlev commented on IGNITE-11696: [~antonovsergey93] thank you for your comments! I've updated the code, could you please check it again? > Create JMX metric for current PME execution time > > > Key: IGNITE-11696 > URL: https://issues.apache.org/jira/browse/IGNITE-11696 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Now PME process can't be monitored from JMX, only from the logs. It makes > sense to show the execution time for the current partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11696) Create JMX metric for current PME execution time
[ https://issues.apache.org/jira/browse/IGNITE-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-11696: -- Assignee: Evgenii Zhuravlev > Create JMX metric for current PME execution time > > > Key: IGNITE-11696 > URL: https://issues.apache.org/jira/browse/IGNITE-11696 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Now PME process can't be monitored from JMX, only from the logs. It makes > sense to show the execution time for the current partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11696) Create JMX metric for current PME execution time
Evgenii Zhuravlev created IGNITE-11696: -- Summary: Create JMX metric for current PME execution time Key: IGNITE-11696 URL: https://issues.apache.org/jira/browse/IGNITE-11696 Project: Ignite Issue Type: Improvement Reporter: Evgenii Zhuravlev Now PME process can't be monitored from JMX, only from the logs. It makes sense to show the execution time for the current partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11695) AverageGetTime metric doesn't work properly with ScanQuery predicate
[
https://issues.apache.org/jira/browse/IGNITE-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11695:
---
Labels: newbie (was: )
> AverageGetTime metric doesn't work properly with ScanQuery predicate
>
>
> Key: IGNITE-11695
> URL: https://issues.apache.org/jira/browse/IGNITE-11695
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: newbie
>
> In *GridCacheQueryManager.advance* method *start* variable is set only once,
> at the start of executing the method, while metrics.onRead inside this method
> could be executed multiple times in case if Predicate returns false. In the
> case of using FILTER_COUNT= 10, there will be CacheGets=10 and very
> big value for AverageGetTime. If it will be changed to 1, CacheGets still
> will be equal to 10, while AverageGetTime will be really small.
> Reproducer:
> {code:java}
> public class ExampleNodeStartup {
> private static int FILTER_COUNT = 10;
> /**
> * Start up an empty node with example compute configuration.
> *
> * @param args Command line arguments, none required.
> * @throws IgniteException If failed.
> */
> public static void main(String[] args) throws IgniteException {
> Ignite ignite = Ignition.start();
> IgniteCache cache = ignite.getOrCreateCache(new
> CacheConfiguration<>("test").setStatisticsEnabled(true));
> for (int i = 0; i < 10; i++)
> cache.put(i, i);
> long start = System.currentTimeMillis();
> Iterator it = cache.query(new ScanQuery().setFilter(new
> IgniteBiPredicate() {
> @Override public boolean apply(Object o, Object o2) {
> if ((int)o2 % FILTER_COUNT == 0)
> return true;
> return false;
> }
> })).iterator();
> while (it.hasNext())
> System.out.println("iterator value: " + it.next());
> System.out.println("Execution time: " + (System.currentTimeMillis() -
> start));
> System.out.println("GETS: " + cache.metrics().getCacheGets());
> System.out.println("GET times: " +
> cache.metrics().getAverageGetTime());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11695) AverageGetTime metric doesn't work properly with ScanQuery predicate
[
https://issues.apache.org/jira/browse/IGNITE-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11695:
---
Description:
In *GridCacheQueryManager.advance* method *start* variable is set only once, at
the start of executing the method, while metrics.onRead inside this method
could be executed multiple times in case if Predicate returns false. In the
case of using FILTER_COUNT= 10, there will be CacheGets=10 and very big
value for AverageGetTime. If it will be changed to 1, CacheGets still will be
equal to 10, while AverageGetTime will be really small.
Reproducer:
{code:java}
public class ExampleNodeStartup {
private static int FILTER_COUNT = 10;
/**
* Start up an empty node with example compute configuration.
*
* @param args Command line arguments, none required.
* @throws IgniteException If failed.
*/
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache(new
CacheConfiguration<>("test").setStatisticsEnabled(true));
for (int i = 0; i < 10; i++)
cache.put(i, i);
long start = System.currentTimeMillis();
Iterator it = cache.query(new ScanQuery().setFilter(new
IgniteBiPredicate() {
@Override public boolean apply(Object o, Object o2) {
if ((int)o2 % FILTER_COUNT == 0)
return true;
return false;
}
})).iterator();
while (it.hasNext())
System.out.println("iterator value: " + it.next());
System.out.println("Execution time: " + (System.currentTimeMillis() -
start));
System.out.println("GETS: " + cache.metrics().getCacheGets());
System.out.println("GET times: " + cache.metrics().getAverageGetTime());
}
}
{code}
was:
In *GridCacheQueryManager.advance* method *start* variable is set only once, at
the start of executing the method, while metrics.onRead inside this method
could be executed multiple times in case if Predicate returns false. In case of
using FILTER_COUNT= 10, there will be CacheGets=10 and very high
executing time.
Reproducer:
{code:java}
public class ExampleNodeStartup {
private static int FILTER_COUNT = 10;
/**
* Start up an empty node with example compute configuration.
*
* @param args Command line arguments, none required.
* @throws IgniteException If failed.
*/
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache(new
CacheConfiguration<>("test").setStatisticsEnabled(true));
for (int i = 0; i < 10; i++)
cache.put(i, i);
long start = System.currentTimeMillis();
Iterator it = cache.query(new ScanQuery().setFilter(new
IgniteBiPredicate() {
@Override public boolean apply(Object o, Object o2) {
if ((int)o2 % FILTER_COUNT == 0)
return true;
return false;
}
})).iterator();
while (it.hasNext())
System.out.println("iterator value: " + it.next());
System.out.println("Execution time: " + (System.currentTimeMillis() -
start));
System.out.println("GETS: " + cache.metrics().getCacheGets());
System.out.println("GET times: " + cache.metrics().getAverageGetTime());
}
}
{code}
> AverageGetTime metric doesn't work properly with ScanQuery predicate
>
>
> Key: IGNITE-11695
> URL: https://issues.apache.org/jira/browse/IGNITE-11695
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> In *GridCacheQueryManager.advance* method *start* variable is set only once,
> at the start of executing the method, while metrics.onRead inside this method
> could be executed multiple times in case if Predicate returns false. In the
> case of using FILTER_COUNT= 10, there will be CacheGets=10 and very
> big value for AverageGetTime. If it will be changed to 1, CacheGets still
> will be equal to 10, while AverageGetTime will be really small.
> Reproducer:
> {code:java}
> public class ExampleNodeStartup {
> private static int FILTER_COUNT = 10;
> /**
> * Start up an empty node with example compute configuration.
> *
> * @param args Command line arguments, none required.
> * @throws IgniteException If failed.
> */
> public static void main(String[] args) throws IgniteException {
> Ignite ignite = Ignition.start();
> IgniteCache cache = ignite.getOrCreateCache(new
>
[jira] [Updated] (IGNITE-11695) AverageGetTime metric doesn't work properly with ScanQuery predicate
[
https://issues.apache.org/jira/browse/IGNITE-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11695:
---
Description:
In *GridCacheQueryManager.advance* method *start* variable is set only once, at
the start of executing the method, while metrics.onRead inside this method
could be executed multiple times in case if Predicate returns false. In case of
using FILTER_COUNT= 10, there will be CacheGets=10 and very high
executing time.
Reproducer:
{code:java}
public class ExampleNodeStartup {
private static int FILTER_COUNT = 10;
/**
* Start up an empty node with example compute configuration.
*
* @param args Command line arguments, none required.
* @throws IgniteException If failed.
*/
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache(new
CacheConfiguration<>("test").setStatisticsEnabled(true));
for (int i = 0; i < 10; i++)
cache.put(i, i);
long start = System.currentTimeMillis();
Iterator it = cache.query(new ScanQuery().setFilter(new
IgniteBiPredicate() {
@Override public boolean apply(Object o, Object o2) {
if ((int)o2 % FILTER_COUNT == 0)
return true;
return false;
}
})).iterator();
while (it.hasNext())
System.out.println("iterator value: " + it.next());
System.out.println("Execution time: " + (System.currentTimeMillis() -
start));
System.out.println("GETS: " + cache.metrics().getCacheGets());
System.out.println("GET times: " + cache.metrics().getAverageGetTime());
}
}
{code}
was:
In *GridCacheQueryManager.advance* method *start* variable is set only once, at
the start of executing the method, while metrics.onRead inside this method
could be executed multiple times in case if Predicate returns false:
Reproducer:
{code:java}
public class ExampleNodeStartup {
private static int FILTER_COUNT = 10;
/**
* Start up an empty node with example compute configuration.
*
* @param args Command line arguments, none required.
* @throws IgniteException If failed.
*/
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache(new
CacheConfiguration<>("test").setStatisticsEnabled(true));
for (int i = 0; i < 10; i++)
cache.put(i, i);
long start = System.currentTimeMillis();
Iterator it = cache.query(new ScanQuery().setFilter(new
IgniteBiPredicate() {
@Override public boolean apply(Object o, Object o2) {
if ((int)o2 % FILTER_COUNT == 0)
return true;
return false;
}
})).iterator();
while (it.hasNext())
System.out.println("iterator value: " + it.next());
System.out.println("Execution time: " + (System.currentTimeMillis() -
start));
System.out.println("GETS: " + cache.metrics().getCacheGets());
System.out.println("GET times: " + cache.metrics().getAverageGetTime());
}
}
{code}
> AverageGetTime metric doesn't work properly with ScanQuery predicate
>
>
> Key: IGNITE-11695
> URL: https://issues.apache.org/jira/browse/IGNITE-11695
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> In *GridCacheQueryManager.advance* method *start* variable is set only once,
> at the start of executing the method, while metrics.onRead inside this method
> could be executed multiple times in case if Predicate returns false. In case
> of using FILTER_COUNT= 10, there will be CacheGets=10 and very high
> executing time.
> Reproducer:
> {code:java}
> public class ExampleNodeStartup {
> private static int FILTER_COUNT = 10;
> /**
> * Start up an empty node with example compute configuration.
> *
> * @param args Command line arguments, none required.
> * @throws IgniteException If failed.
> */
> public static void main(String[] args) throws IgniteException {
> Ignite ignite = Ignition.start();
> IgniteCache cache = ignite.getOrCreateCache(new
> CacheConfiguration<>("test").setStatisticsEnabled(true));
> for (int i = 0; i < 10; i++)
> cache.put(i, i);
> long start = System.currentTimeMillis();
> Iterator it = cache.query(new ScanQuery().setFilter(new
> IgniteBiPredicate() {
> @Override public boolean apply(Object o, Object o2) {
> if ((int)o2 % FILTER_COUNT == 0)
>
[jira] [Created] (IGNITE-11695) AverageGetTime metric doesn't work properly with ScanQuery predicate
Evgenii Zhuravlev created IGNITE-11695:
--
Summary: AverageGetTime metric doesn't work properly with
ScanQuery predicate
Key: IGNITE-11695
URL: https://issues.apache.org/jira/browse/IGNITE-11695
Project: Ignite
Issue Type: Bug
Reporter: Evgenii Zhuravlev
In *GridCacheQueryManager.advance* method *start* variable is set only once, at
the start of executing the method, while metrics.onRead inside this method
could be executed multiple times in case if Predicate returns false:
Reproducer:
{code:java}
public class ExampleNodeStartup {
private static int FILTER_COUNT = 10;
/**
* Start up an empty node with example compute configuration.
*
* @param args Command line arguments, none required.
* @throws IgniteException If failed.
*/
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache(new
CacheConfiguration<>("test").setStatisticsEnabled(true));
for (int i = 0; i < 10; i++)
cache.put(i, i);
long start = System.currentTimeMillis();
Iterator it = cache.query(new ScanQuery().setFilter(new
IgniteBiPredicate() {
@Override public boolean apply(Object o, Object o2) {
if ((int)o2 % FILTER_COUNT == 0)
return true;
return false;
}
})).iterator();
while (it.hasNext())
System.out.println("iterator value: " + it.next());
System.out.println("Execution time: " + (System.currentTimeMillis() -
start));
System.out.println("GETS: " + cache.metrics().getCacheGets());
System.out.println("GET times: " + cache.metrics().getAverageGetTime());
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11610) Add note to the DROP TABLE doc that it can be used only for table created with DDL
Evgenii Zhuravlev created IGNITE-11610: -- Summary: Add note to the DROP TABLE doc that it can be used only for table created with DDL Key: IGNITE-11610 URL: https://issues.apache.org/jira/browse/IGNITE-11610 Project: Ignite Issue Type: Bug Components: documentation Reporter: Evgenii Zhuravlev Assignee: Artem Budnikov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11598) Add possibility to have different rebalance thread pool size for nodes in the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11598: --- Summary: Add possibility to have different rebalance thread pool size for nodes in the cluster (was: Add possibility to have different rebalance thread pool size for nodes in cluster) > Add possibility to have different rebalance thread pool size for nodes in the > cluster > - > > Key: IGNITE-11598 > URL: https://issues.apache.org/jira/browse/IGNITE-11598 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Priority: Major > > It can be used for changing this property without downtime when rebalance is > slow -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11599) Thin client doesn't have proper retry
Evgenii Zhuravlev created IGNITE-11599:
--
Summary: Thin client doesn't have proper retry
Key: IGNITE-11599
URL: https://issues.apache.org/jira/browse/IGNITE-11599
Project: Ignite
Issue Type: Bug
Reporter: Evgenii Zhuravlev
In case when one of the nodes from the addresses list is nor available, there
is a chance that you will see "Ignite cluster is unavailable" even if other
nodes are running.
{code:java}
List addrs = new ArrayList(2);
addrs.add("127.0.0.1:10800");
addrs.add("127.0.0.1:10801");
ClientConfiguration cfg = new
ClientConfiguration().setAddresses(addrs.toArray(new String[]{}));
IgniteClient igniteClient = Ignition.startClient(cfg)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11598) Add possibility to have different rebalance thread pool size for nodes in cluster
Evgenii Zhuravlev created IGNITE-11598: -- Summary: Add possibility to have different rebalance thread pool size for nodes in cluster Key: IGNITE-11598 URL: https://issues.apache.org/jira/browse/IGNITE-11598 Project: Ignite Issue Type: Improvement Reporter: Evgenii Zhuravlev It can be used for changing this property without downtime when rebalance is slow -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11554) Create detailed documentation for peerClassLoading with places where and how it can be used
Evgenii Zhuravlev created IGNITE-11554: -- Summary: Create detailed documentation for peerClassLoading with places where and how it can be used Key: IGNITE-11554 URL: https://issues.apache.org/jira/browse/IGNITE-11554 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Evgenii Zhuravlev Right now, it's not clear for which classes and which APIs peerClassLoading works. Also, we should describe some of the examples of use cases for peerClassLoading -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11496: --- Ignite Flags: (was: Docs Required) > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11496: --- Component/s: wizards > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11496: --- Affects Version/s: 2.5 > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
Evgenii Zhuravlev created IGNITE-11496: -- Summary: Long running SQL queries could be randomly canceled from WC Key: IGNITE-11496 URL: https://issues.apache.org/jira/browse/IGNITE-11496 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev I've tried to run some long-running queries from WC(more than a couple of minutes) and I've faced a behavior when the query was canceled without clicking on the cancel button. I've opened different browser tabs at this moment, maybe it could be the reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[ https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11494: --- Labels: usability (was: ) > Change message log message in case of too small > IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter > - > > Key: IGNITE-11494 > URL: https://issues.apache.org/jira/browse/IGNITE-11494 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: usability > > Message "Fetched result set was too large." should be changed to some > recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11495) document IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE parameter
Evgenii Zhuravlev created IGNITE-11495: -- Summary: document IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE parameter Key: IGNITE-11495 URL: https://issues.apache.org/jira/browse/IGNITE-11495 Project: Ignite Issue Type: Improvement Components: documentation, sql Affects Versions: 2.7 Reporter: Evgenii Zhuravlev Assignee: Artem Budnikov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[ https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11494: --- Affects Version/s: 2.7 > Change message log message in case of too small > IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter > - > > Key: IGNITE-11494 > URL: https://issues.apache.org/jira/browse/IGNITE-11494 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: usability > > Message "Fetched result set was too large." should be changed to some > recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
Evgenii Zhuravlev created IGNITE-11494: -- Summary: Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter Key: IGNITE-11494 URL: https://issues.apache.org/jira/browse/IGNITE-11494 Project: Ignite Issue Type: Improvement Components: sql Reporter: Evgenii Zhuravlev Message "Fetched result set was too large." should be changed to some recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11487) Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property
Evgenii Zhuravlev created IGNITE-11487: -- Summary: Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property Key: IGNITE-11487 URL: https://issues.apache.org/jira/browse/IGNITE-11487 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Evgenii Zhuravlev Assignee: Prachi Garg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11373) varchar_ignorecase doesn't work properly
[
https://issues.apache.org/jira/browse/IGNITE-11373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778792#comment-16778792
]
Evgenii Zhuravlev edited comment on IGNITE-11373 at 2/27/19 2:19 AM:
-
I did the analysis of this issue and added an additional flag for the H2
connection
string(org.apache.ignite.internal.processors.query.h2.ConnectionManager#DB_OPTIONS):
IGNORECASE=TRUE;
It started to work, however, after adding an index on this field, it starts to
fail in 2 places on the field type validation: InlineIndexHelper:
On creating the index:
if (this.type != type)
throw new UnsupportedOperationException("Invalid fast index type: "
+ type);
And on reading:
if (val.getType() != type)
throw new UnsupportedOperationException("value type doesn't match");
After commenting these lines, looks like everything started to work. I see that
it works much faster than without index. So, looks like it something that could
be fixed pretty fast, we just need to figure out how to change this type check.
Here is the updated code for the reproducer with index
{code:java}
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
IgniteCache cache = ignite.getOrCreateCache("TEST");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") "));
cache.query(new SqlFieldsQuery("CREATE INDEX value_idx ON TEST
(TEST_VALUE);"));
for (int i = 0; i < 10; i++)
System.out.println("INSERTED: " + i + " - " +
ignite.cache("TEST").query(new SqlFieldsQuery("INSERT INTO TEST values (" + i +
" , '" + (i == 5 ? "" : i) + "aAa')")).getAll().size());
for (int i = 0; i < 1000; i++) {
StopWatch sw = new StopWatch();
sw.start();
System.out.println("FOUND:" + ignite.cache("TEST").query(new
SqlFieldsQuery("Select * from TEST where TEST_VALUE = 'aaa'")).getAll().size());
sw.stop();
System.out.println("Time: " + sw.getTotalTimeMillis());
}
{code}
was (Author: ezhuravl):
I did the analysis of this issue and added an additional flag for the H2
connection
string(org.apache.ignite.internal.processors.query.h2.ConnectionManager#DB_OPTIONS):
IGNORECASE=TRUE;
It started to work, however, after adding an index on this field, it starts to
fail in 2 places on the field type validation: InlineIndexHelper:
On creating the index:
if (this.type != type)
throw new UnsupportedOperationException("Invalid fast index type: "
+ type);
And on reading:
if (val.getType() != type)
throw new UnsupportedOperationException("value type doesn't match");
After commenting these lines, looks like everything started to work. I see that
it works much faster than without index. So, looks like it something that could
be fixed pretty fast, we just need to figure out how to change this type check.
> varchar_ignorecase doesn't work properly
>
>
> Key: IGNITE-11373
> URL: https://issues.apache.org/jira/browse/IGNITE-11373
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Looks like a field with type varchar_ignorecase can't be used for filtering
> the values for different cases.
> {code:java}
> Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
>
> IgniteCache cache = ignite.getOrCreateCache("TEST");
> cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
> "(\n" +
> " TEST_IDNUMBER(15)NOT NULL,\n" +
> " TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
> " PRIMARY KEY (TEST_ID)\n" +
> ") "));
> System.out.println("INSERTED:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());
> System.out.println("FOUND:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("Select * from TEST where TEST_VALUE like
> '%aaa%'")).getAll().size());
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11373) varchar_ignorecase doesn't work properly
[
https://issues.apache.org/jira/browse/IGNITE-11373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778792#comment-16778792
]
Evgenii Zhuravlev commented on IGNITE-11373:
I did the analysis of this issue and added an additional flag for the H2
connection
string(org.apache.ignite.internal.processors.query.h2.ConnectionManager#DB_OPTIONS):
IGNORECASE=TRUE;
It started to work, however, after adding an index on this field, it starts to
fail in 2 places on the field type validation: InlineIndexHelper:
On creating the index:
if (this.type != type)
throw new UnsupportedOperationException("Invalid fast index type: "
+ type);
And on reading:
if (val.getType() != type)
throw new UnsupportedOperationException("value type doesn't match");
After commenting these lines, looks like everything started to work. I see that
it works much faster than without index. So, looks like it something that could
be fixed pretty fast, we just need to figure out how to change this type check.
> varchar_ignorecase doesn't work properly
>
>
> Key: IGNITE-11373
> URL: https://issues.apache.org/jira/browse/IGNITE-11373
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Looks like a field with type varchar_ignorecase can't be used for filtering
> the values for different cases.
> {code:java}
> Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
>
> IgniteCache cache = ignite.getOrCreateCache("TEST");
> cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
> "(\n" +
> " TEST_IDNUMBER(15)NOT NULL,\n" +
> " TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
> " PRIMARY KEY (TEST_ID)\n" +
> ") "));
> System.out.println("INSERTED:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());
> System.out.println("FOUND:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("Select * from TEST where TEST_VALUE like
> '%aaa%'")).getAll().size());
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11373) varchar_ignorecase doesn't work properly
Evgenii Zhuravlev created IGNITE-11373:
--
Summary: varchar_ignorecase doesn't work properly
Key: IGNITE-11373
URL: https://issues.apache.org/jira/browse/IGNITE-11373
Project: Ignite
Issue Type: Bug
Reporter: Evgenii Zhuravlev
Looks like a field with type varchar_ignorecase can't be used for filtering the
values for different cases.
{code:java}
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
IgniteCache cache = ignite.getOrCreateCache("TEST");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") "));
System.out.println("INSERTED:" + ignite.cache("TEST").query(new
SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST").query(new
SqlFieldsQuery("Select * from TEST where TEST_VALUE like
'%aaa%'")).getAll().size());
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6993) Document SMTP server documentation for Web Console
[ https://issues.apache.org/jira/browse/IGNITE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-6993: -- Priority: Critical (was: Minor) > Document SMTP server documentation for Web Console > -- > > Key: IGNITE-6993 > URL: https://issues.apache.org/jira/browse/IGNITE-6993 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Critical > Fix For: 2.8 > > > Document how to configure a custom SMTP server for Web Console on this domain > under "Ignite Web Console" section: > https://apacheignite-tools.readme.io/docs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11165: --- Fix Version/s: 2.7 > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11165: --- Affects Version/s: 2.6 > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6 >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev resolved IGNITE-11165. Resolution: Fixed > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16767691#comment-16767691 ] Evgenii Zhuravlev commented on IGNITE-11165: [~Artem Budnikov] Thank you! Then I suppose we can close this issue. > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11219) CREATE TABLE with template doesn't work properly with data inserted from KV API
[
https://issues.apache.org/jira/browse/IGNITE-11219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11219:
---
Description:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set at the moment of creating a context for a
different type without any keyConfigurations. This leads to the problem with
accessing data from SQL if it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find these rows in the cache.
Possible quickfix:
set affinityMapper to cfgTemplate in GridCacheProcessor.getConfigFromTemplate:
cfgTemplate.setAffinityMapper(null)
Also, interesting thing - if you replace = with IS, then everything works.
was:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set at the moment of creating a context for a
different type without any keyConfigurations. This leads to the problem with
accessing data from SQL if it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code
[jira] [Updated] (IGNITE-11219) CREATE TABLE with template doesn't work properly with data inserted from KV API
[
https://issues.apache.org/jira/browse/IGNITE-11219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11219:
---
Description:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set at the moment of creating a context for a
different type without any keyConfigurations. This leads to the problem with
accessing data from SQL if it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find these rows in the cache.
Possible quickfix:
set affinityMapper to cfgTemplate in GridCacheProcessor.getConfigFromTemplate:
cfgTemplate.setAffinityMapper(null)
was:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set a the moment of creating a context for a different
type without any keyConfigurations. This leads to the problem with accessing
data from SQL if it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find
[jira] [Updated] (IGNITE-11219) CREATE TABLE with template doesn't work properly with data inserted from KV API
[
https://issues.apache.org/jira/browse/IGNITE-11219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11219:
---
Description:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set a the moment of creating context for a different
type without any keyConfigurations. This leads to the problem with accessing
data from SQL if it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find these rows in the cache.
Possible quickfix:
set affinityMapper to cfgTemplate in GridCacheProcessor.getConfigFromTemplate:
cfgTemplate.setAffinityMapper(null)
was:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set for a different type without any
keyConfigurations. This leads to the problem with accessing data from SQL if
it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find these rows in the cache.
Possible
[jira] [Updated] (IGNITE-11219) CREATE TABLE with template doesn't work properly with data inserted from KV API
[
https://issues.apache.org/jira/browse/IGNITE-11219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11219:
---
Description:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set a the moment of creating a context for a different
type without any keyConfigurations. This leads to the problem with accessing
data from SQL if it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find these rows in the cache.
Possible quickfix:
set affinityMapper to cfgTemplate in GridCacheProcessor.getConfigFromTemplate:
cfgTemplate.setAffinityMapper(null)
was:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set a the moment of creating context for a different
type without any keyConfigurations. This leads to the problem with accessing
data from SQL if it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find
[jira] [Updated] (IGNITE-11219) CREATE TABLE with template doesn't work properly with data inserted from KV API
[
https://issues.apache.org/jira/browse/IGNITE-11219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-11219:
---
Description:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set for a different type without any
keyConfigurations. This leads to the problem with accessing data from SQL if
it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
It will show that it can't find these rows in the cache.
Possible quickfix:
set affinityMapper to cfgTemplate in GridCacheProcessor.getConfigFromTemplate:
cfgTemplate.setAffinityMapper(null)
was:
When you use a template for your table, it takes the affinityMapper field from
this template, which was set for a different type without any
keyConfigurations. This leads to the problem with accessing data from SQL if
it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
Possible quickfix:
set affinityMapper to cfgTemplate in GridCacheProcessor.getConfigFromTemplate:
[jira] [Created] (IGNITE-11219) CREATE TABLE with template doesn't work properly with data inserted from KV API
Evgenii Zhuravlev created IGNITE-11219:
--
Summary: CREATE TABLE with template doesn't work properly with
data inserted from KV API
Key: IGNITE-11219
URL: https://issues.apache.org/jira/browse/IGNITE-11219
Project: Ignite
Issue Type: Bug
Reporter: Evgenii Zhuravlev
When you use a template for your table, it takes the affinityMapper field from
this template, which was set for a different type without any
keyConfigurations. This leads to the problem with accessing data from SQL if
it was inserted using Key-value API
Here is a code to reproduce the issue:
{code:java}
Ignition.setClientMode(true);
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
ignite.cluster().active(true);
IgniteCache cache = ignite.getOrCreateCache("test");
cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
" TEST_IDNUMBER(15)NOT NULL,\n" +
" TEST_FIELD VARCHAR2(100),\n" +
" PRIMARY KEY (TEST_ID)\n" +
") with \"TEMPLATE=TEST_TEMPLATE,KEY_TYPE=TEST_KEY
,CACHE_NAME=TEST_CACHE ,
VALUE_TYPE=TEST_VALUE,ATOMICITY=TRANSACTIONAL\";").setSchema("PUBLIC"));
for (int i = 0; i < 100; i++) {
BinaryObjectBuilder keyBuilder =
ignite.binary().builder("TEST_KEY");
keyBuilder.setField("TEST_ID", new BigDecimal(111l +
i));
BinaryObjectBuilder valueBuilder =
ignite.binary().builder("TEST_VALUE");
valueBuilder.setField("TEST_FIELD", "123123" + i);
ignite.cache("TEST_CACHE").withKeepBinary().put(keyBuilder.build(),
valueBuilder.build());
}
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select * from TEST")).getAll().size());
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID =
111")).getAll());
for (int i = 0; i < 100; i++)
System.out.println("FOUND:" + ignite.cache("TEST_CACHE").query(new
SqlFieldsQuery("Select TEST_FIELD from TEST where TEST_ID = " +
(111l + i))).getAll());
{code}
Here is a test template:
{code:java}
{code}
Steps to reproduce:
1. Start a server node, for example, using ExampleNodeStartup.
2. Start a client node using the code provided above with the template in
configuration.
Possible quickfix:
set affinityMapper to cfgTemplate in GridCacheProcessor.getConfigFromTemplate:
cfgTemplate.setAffinityMapper(null)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11200) SQL: query contexts should not be static
[ https://issues.apache.org/jira/browse/IGNITE-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-11200: -- Assignee: Evgenii Zhuravlev (was: Vladimir Ozerov) > SQL: query contexts should not be static > > > Key: IGNITE-11200 > URL: https://issues.apache.org/jira/browse/IGNITE-11200 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently query contexts are static and as a result over complicated. Need to > make them instance-bound and remove static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
Evgenii Zhuravlev created IGNITE-11165: -- Summary: Add note to the documentation that cache name will be used as folder name in case of using persistence Key: IGNITE-11165 URL: https://issues.apache.org/jira/browse/IGNITE-11165 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Evgenii Zhuravlev Assignee: Artem Budnikov We should add a note that it's not recommended to use symbols which are not allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11096) Webagent: flag --disable-demo doesn't work
Evgenii Zhuravlev created IGNITE-11096: -- Summary: Webagent: flag --disable-demo doesn't work Key: IGNITE-11096 URL: https://issues.apache.org/jira/browse/IGNITE-11096 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.7 Environment: After enabling this flag it's still possible to start demo Reporter: Evgenii Zhuravlev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11052) Add documentation for "failed to wait for partition map exchange" message
[ https://issues.apache.org/jira/browse/IGNITE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11052: --- Description: We should describe why this message could be seen in logs and how to debug the real problem that caused this message. This message can be printed in the case when cluster trying to change topology version while some of the operations are still running on the previous topology version. It could be either long running operations which could finish successfully after a while or deadlock(or some other operations, that won't be able to finish by some reason) Here are some examples on the user list: http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html was: We should describe why this message could be seen in logs and how to debug the real problem that caused this message. This message can be printed in the case when cluster trying to change topology version while some of the operations still running on the previous topology version. It could be either long running operations which could finish successfully after a while or deadlock(or some other operations, that won't be able to finish by some reason) Here are some examples on the user list: http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html > Add documentation for "failed to wait for partition map exchange" message > - > > Key: IGNITE-11052 > URL: https://issues.apache.org/jira/browse/IGNITE-11052 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > We should describe why this message could be seen in logs and how to debug > the real problem that caused this message. > This message can be printed in the case when cluster trying to change > topology version while some of the operations are still running on the > previous topology version. It could be either long running operations which > could finish successfully after a while or deadlock(or some other operations, > that won't be able to finish by some reason) > Here are some examples on the user list: > http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html > http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html > http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11052) Add documentation for "failed to wait for partition map exchange" message
[ https://issues.apache.org/jira/browse/IGNITE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11052: --- Description: We should describe why this message could be seen in logs and how to debug the real problem that caused this message. This message can be printed in the case when cluster trying to change topology version while some of the operations still running on the previous topology version. It could be either long running operations which could finish successfully after a while or deadlock(or some other operations, that won't be able to finish by some reason) Here are some examples on the user list: http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html was: We should describe why this message could be seen in logs and how to debug the real problem that caused this message. This message can be printed in the case when cluster trying to change topology version when some of the operations still running on the previous topology version. It could be either long running operations which could finish successfully after a while or deadlock(or some other operations, that won't be able to finish by some reason) Here are some examples on the user list: http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html > Add documentation for "failed to wait for partition map exchange" message > - > > Key: IGNITE-11052 > URL: https://issues.apache.org/jira/browse/IGNITE-11052 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > We should describe why this message could be seen in logs and how to debug > the real problem that caused this message. > This message can be printed in the case when cluster trying to change > topology version while some of the operations still running on the previous > topology version. It could be either long running operations which could > finish successfully after a while or deadlock(or some other operations, that > won't be able to finish by some reason) > Here are some examples on the user list: > http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html > http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html > http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11052) Add documentation for "failed to wait for partition map exchange" message
[ https://issues.apache.org/jira/browse/IGNITE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-11052: -- Assignee: Artem Budnikov (was: Denis Magda) > Add documentation for "failed to wait for partition map exchange" message > - > > Key: IGNITE-11052 > URL: https://issues.apache.org/jira/browse/IGNITE-11052 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > We should describe why this message could be seen in logs and how to debug > the real problem that caused this message. > This message can be printed in the case when cluster trying to change > topology version when some of the operations still running on the previous > topology version. It could be either long running operations which could > finish successfully after a while or deadlock(or some other operations, that > won't be able to finish by some reason) > Here are some examples on the user list: > http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html > http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html > http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11052) Add documentation for "failed to wait for partition map exchange" message
[ https://issues.apache.org/jira/browse/IGNITE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11052: --- Description: We should describe why this message could be seen in logs and how to debug the real problem that caused this message. This message can be printed in the case when cluster trying to change topology version when some of the operations still running on the previous topology version. It could be either long running operations which could finish successfully after a while or deadlock(or some other operations, that won't be able to finish by some reason) Here are some examples on the user list: http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html was:We should describe why this message could be seen in logs and how to debug the real problem that caused this message. > Add documentation for "failed to wait for partition map exchange" message > - > > Key: IGNITE-11052 > URL: https://issues.apache.org/jira/browse/IGNITE-11052 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Denis Magda >Priority: Major > > We should describe why this message could be seen in logs and how to debug > the real problem that caused this message. > This message can be printed in the case when cluster trying to change > topology version when some of the operations still running on the previous > topology version. It could be either long running operations which could > finish successfully after a while or deadlock(or some other operations, that > won't be able to finish by some reason) > Here are some examples on the user list: > http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-td6252i20.html > http://apache-ignite-users.70518.x6.nabble.com/Large-durable-caches-td20097i20.html > http://apache-ignite-users.70518.x6.nabble.com/Cache-operations-hanging-for-a-minute-when-one-of-server-nodes-goes-down-td21964.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11052) Add documentation for "failed to wait for partition map exchange" message
Evgenii Zhuravlev created IGNITE-11052: -- Summary: Add documentation for "failed to wait for partition map exchange" message Key: IGNITE-11052 URL: https://issues.apache.org/jira/browse/IGNITE-11052 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Evgenii Zhuravlev Assignee: Denis Magda We should describe why this message could be seen in logs and how to debug the real problem that caused this message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11015) AveragePutTime metrics doesn't work properly in case of remote puts
Evgenii Zhuravlev created IGNITE-11015: -- Summary: AveragePutTime metrics doesn't work properly in case of remote puts Key: IGNITE-11015 URL: https://issues.apache.org/jira/browse/IGNITE-11015 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev It happens because the number of writes is collected on the server machine, while execution time is collected on the machine which invoked the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9279) Support custom default SQL schema name.
[ https://issues.apache.org/jira/browse/IGNITE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746511#comment-16746511 ] Evgenii Zhuravlev commented on IGNITE-9279: --- Hi [~vozerov], Do we have any plans for preparing documentation for this feature? It's not described anywhere. > Support custom default SQL schema name. > --- > > Key: IGNITE-9279 > URL: https://issues.apache.org/jira/browse/IGNITE-9279 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Default SQL schema is PUBLIC and there is no way to customize. > This may be useful when dynamic schema creation will be implemented. > Let's make default schema name configurable via node properties and then add > it to ignite configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10852) [Documentation] - Add details on to public API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739957#comment-16739957 ] Evgenii Zhuravlev edited comment on IGNITE-10852 at 1/11/19 2:25 AM: - [~pgarg], I'd say that we need more information about each Exception type, so users could link somehow runtime exceptions with our API methods. I will prepare the list of APIs that are related to each Exception. was (Author: ezhuravl): [~pgarg], I'd say that we need more information about each Exception type, so users could link somehow this exceptions with our API methods. I will prepare the list of APIs that are related to each Exception. > [Documentation] - Add details on to public API behaviour > > > Key: IGNITE-10852 > URL: https://issues.apache.org/jira/browse/IGNITE-10852 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.4, 2.5, 2.6, 2.7 >Reporter: Alexander Gerus >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > Current public API documentation has some specification gaps. In case if > method was not successfully executed, it is not clear what should be done by > user code. > Good practice is to describe all API exceptions that can be processed by user > code and recommended actions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10852) [Documentation] - Add details on to public API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739957#comment-16739957 ] Evgenii Zhuravlev commented on IGNITE-10852: [~pgarg], I'd say that we need more information about each Exception type, so users could link somehow this exceptions with our API methods. I will prepare the list of APIs that are related to each Exception. > [Documentation] - Add details on to public API behaviour > > > Key: IGNITE-10852 > URL: https://issues.apache.org/jira/browse/IGNITE-10852 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.4, 2.5, 2.6, 2.7 >Reporter: Alexander Gerus >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > Current public API documentation has some specification gaps. In case if > method was not successfully executed, it is not clear what should be done by > user code. > Good practice is to describe all API exceptions that can be processed by user > code and recommended actions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10838) Ignite wraps byte[] value with UserCacheObjectByteArrayImpl before saving it and copying the whole array
[ https://issues.apache.org/jira/browse/IGNITE-10838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-10838: --- Summary: Ignite wraps byte[] value with UserCacheObjectByteArrayImpl before saving it and copying the whole array (was: Ignite wrap byte[] value with UserCacheObjectByteArrayImpl before saving it and copying the whole array ) > Ignite wraps byte[] value with UserCacheObjectByteArrayImpl before saving it > and copying the whole array > - > > Key: IGNITE-10838 > URL: https://issues.apache.org/jira/browse/IGNITE-10838 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Priority: Major > > I assume it was created for heap cache before 2.0, while it doesn't make > sense for off-heap cache since it will be copied in any case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10838) Ignite wrap byte[] value with UserCacheObjectByteArrayImpl before saving it and copying the whole array
Evgenii Zhuravlev created IGNITE-10838: -- Summary: Ignite wrap byte[] value with UserCacheObjectByteArrayImpl before saving it and copying the whole array Key: IGNITE-10838 URL: https://issues.apache.org/jira/browse/IGNITE-10838 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev I assume it was created for heap cache before 2.0, while it doesn't make sense for off-heap cache since it will be copied in any case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10734) Add documentation for the list of operations that should be retried in case of cluster topology changes
[ https://issues.apache.org/jira/browse/IGNITE-10734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-10734: --- Component/s: documentation > Add documentation for the list of operations that should be retried in case > of cluster topology changes > --- > > Key: IGNITE-10734 > URL: https://issues.apache.org/jira/browse/IGNITE-10734 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > Some of the operations, like get or getAll would throw > ClusterTopologyException if primary node left topology, while other > operations not. So, some operations should be re-tried from user code, while > some operation will do it internally. We should prepare documentation for the > list of these operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10734) Add documentation for the list of operations that should be retried in case of cluster topology changes
Evgenii Zhuravlev created IGNITE-10734: -- Summary: Add documentation for the list of operations that should be retried in case of cluster topology changes Key: IGNITE-10734 URL: https://issues.apache.org/jira/browse/IGNITE-10734 Project: Ignite Issue Type: Improvement Reporter: Evgenii Zhuravlev Assignee: Artem Budnikov Some of the operations, like get or getAll would throw ClusterTopologyException if primary node left topology, while other operations not. So, some operations should be re-tried from user code, while some operation will do it internally. We should prepare documentation for the list of these operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10627) Support custom preferences like date format and other similar features
Evgenii Zhuravlev created IGNITE-10627: -- Summary: Support custom preferences like date format and other similar features Key: IGNITE-10627 URL: https://issues.apache.org/jira/browse/IGNITE-10627 Project: Ignite Issue Type: Improvement Reporter: Evgenii Zhuravlev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10626) Save authenticated Webconsole session for more than one page refresh
Evgenii Zhuravlev created IGNITE-10626: -- Summary: Save authenticated Webconsole session for more than one page refresh Key: IGNITE-10626 URL: https://issues.apache.org/jira/browse/IGNITE-10626 Project: Ignite Issue Type: Improvement Reporter: Evgenii Zhuravlev Now, it's needed to enter login and password after each page refresh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-10414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-10414:
---
Description:
Reproducer:
{code:java}
Ignite ignite = Ignition.start();
ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE TABLE
IF NOT EXISTS City(id LONG PRIMARY KEY,"
+ " name VARCHAR) WITH \"template=replicated\""));
ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE TABLE
IF NOT EXISTS City(id LONG PRIMARY KEY,"
+ " name VARCHAR) WITH \"template=replicated\""));
{code}
Error:
{code:java}
(err) DDL operation failureSchemaOperationException [code=3, msg=Table already
exists: CITY]
at
org.apache.ignite.internal.processors.query.QueryUtils.checkQueryEntityConflicts(QueryUtils.java:1214)
at
org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:351)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2203)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2164)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2125)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
at
org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
Exception in thread "main" javax.cache.CacheException: Table already exists:
CITY
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
at
org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Table already
exists: CITY
at
org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:642)
at
org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:503)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2203)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2164)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2125)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
... 3 more
{code}
was:
Reproducer:
{code:java}
Ignite ignite = Ignition.start();
ignite.getOrCreateCache("test").query(new
[jira] [Updated] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-10414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-10414:
---
Affects Version/s: 2.7
2.6
> IF NOT EXISTS in CREATE TABLE doesn't work
> --
>
> Key: IGNITE-10414
> URL: https://issues.apache.org/jira/browse/IGNITE-10414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4, 2.6, 2.7
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Reproducer:
>
> {code:java}
>Ignite ignite = Ignition.start();
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work
Evgenii Zhuravlev created IGNITE-10414:
--
Summary: IF NOT EXISTS in CREATE TABLE doesn't work
Key: IGNITE-10414
URL: https://issues.apache.org/jira/browse/IGNITE-10414
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.4
Reporter: Evgenii Zhuravlev
Reproducer:
{code:java}
Ignite ignite = Ignition.start();
ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE TABLE
IF NOT EXISTS City(id LONG PRIMARY KEY,"
+ " name VARCHAR) WITH \"template=replicated\""));
ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE TABLE
IF NOT EXISTS City(id LONG PRIMARY KEY,"
+ " name VARCHAR) WITH \"template=replicated\""));
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10398) CacheMetrics always return 0 for local cache
Evgenii Zhuravlev created IGNITE-10398:
--
Summary: CacheMetrics always return 0 for local cache
Key: IGNITE-10398
URL: https://issues.apache.org/jira/browse/IGNITE-10398
Project: Ignite
Issue Type: Bug
Reporter: Evgenii Zhuravlev
However, it shows the right offHeapEntriesCnt.
Short code snippet:
{code:java}
IgniteConfiguration igniteConfig = new IgniteConfiguration();
CacheConfiguration cacheConfig = new CacheConfiguration("testCache");
cacheConfig.setStatisticsEnabled(true);
igniteConfig.setCacheConfiguration(cacheConfig);
cacheConfig.setCacheMode(CacheMode.LOCAL);
try (Ignite ignite = Ignition.start(igniteConfig)) {
IgniteCache cache = ignite.getOrCreateCache(cacheConfig.getName());
cache.put("key", "val");
cache.put("key2", "val2");
cache.remove("key2");
System.out.println(cache.localMetrics());
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10244) Peer classloading creates a new class on each call for nested compute tasks
[ https://issues.apache.org/jira/browse/IGNITE-10244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688159#comment-16688159 ] Evgenii Zhuravlev commented on IGNITE-10244: Hi Yakov, I've rewritten the test to use Junit. Looks like it's the regression after the fix that David mentioned: https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c. Also, it's not reproducible with CONTINUOUS mode. > Peer classloading creates a new class on each call for nested compute tasks > --- > > Key: IGNITE-10244 > URL: https://issues.apache.org/jira/browse/IGNITE-10244 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Mikhail Cherkasov >Priority: Critical > Attachments: IGNITE_10244_Test_for_metaspace_OOM.patch, > JustServer.java, MyCall.java, NestedCall.java, Test.java > > > If a compute task has embedded compute tasks, embeded task will be loaded by > peer class loading as a new class on each call, which leads to metadata OOM. > Reproducer is attached. Make sure that you run ignite nodes with > -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size. > Also, we need to keep client and server in different JVM to make peer > classloading be engaged. > So what happens: > # client sends compute taks MyCall to server_1 > # server_1 execute MyCall and MyCall sends NestedCall task to server_2 > # server_2 loads NestedCall as a new class and execute it > # repeat it's again and on second iteration server_2 will load NestedCall as > new class again, after few iterations this will lead to OOM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10244) Peer classloading creates a new class on each call for nested compute tasks
[ https://issues.apache.org/jira/browse/IGNITE-10244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-10244: --- Attachment: IGNITE_10244_Test_for_metaspace_OOM.patch > Peer classloading creates a new class on each call for nested compute tasks > --- > > Key: IGNITE-10244 > URL: https://issues.apache.org/jira/browse/IGNITE-10244 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Mikhail Cherkasov >Priority: Critical > Attachments: IGNITE_10244_Test_for_metaspace_OOM.patch, > JustServer.java, MyCall.java, NestedCall.java, Test.java > > > If a compute task has embedded compute tasks, embeded task will be loaded by > peer class loading as a new class on each call, which leads to metadata OOM. > Reproducer is attached. Make sure that you run ignite nodes with > -XX:MaxMetaspaceSize=64m , by default JVM doesn't limit meta space size. > Also, we need to keep client and server in different JVM to make peer > classloading be engaged. > So what happens: > # client sends compute taks MyCall to server_1 > # server_1 execute MyCall and MyCall sends NestedCall task to server_2 > # server_2 loads NestedCall as a new class and execute it > # repeat it's again and on second iteration server_2 will load NestedCall as > new class again, after few iterations this will lead to OOM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5836) AffinityFunctionContext should provide consistent previous assignment
[
https://issues.apache.org/jira/browse/IGNITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev reassigned IGNITE-5836:
-
Assignee: (was: Evgenii Zhuravlev)
> AffinityFunctionContext should provide consistent previous assignment
> -
>
> Key: IGNITE-5836
> URL: https://issues.apache.org/jira/browse/IGNITE-5836
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Priority: Critical
> Labels: usability
> Fix For: 2.8
>
>
> Currently each cache maintains its own {{AffinityFunctionContext}}. This
> leads to the case that {{previousAssignment}} can be different for two caches
> created on different topology versions. In particular, this broke
> {{FairAffinityFunction}} which was removed because of that.
> We should do the following:
> * Make sure that {{previousAssignment}} is consistent for all caches with
> same affinity function, regardless of topology versions caches were created
> on.
> * Add mechanism to enforce equality check for affinity functions. We probably
> will need to force user to implement {{equals}} for cache node filter and
> backup filter.
> * When above is done, bring back {{FairAffinityFunction}}.
> This is also discussed on dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction-td19987.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8934) LongJVMPauseDetector prints error on thread interruption when node stopping
[ https://issues.apache.org/jira/browse/IGNITE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625530#comment-16625530 ] Evgenii Zhuravlev commented on IGNITE-8934: --- The header was already longer than the fix of this issue. Added more description if it's not clear > LongJVMPauseDetector prints error on thread interruption when node stopping > --- > > Key: IGNITE-8934 > URL: https://issues.apache.org/jira/browse/IGNITE-8934 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > > There is a scary error message on the LongJVMPauseDetector stop, which will > be printed on each node stop and it's absolutely unnecessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8934) LongJVMPauseDetector prints error on thread interruption when node stopping
[ https://issues.apache.org/jira/browse/IGNITE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-8934: -- Description: There is a scary error message on the LongJVMPauseDetector stop, which will be printed on each node stop and it's absolutely unnecesssary (was: There is a scary error message on the ) > LongJVMPauseDetector prints error on thread interruption when node stopping > --- > > Key: IGNITE-8934 > URL: https://issues.apache.org/jira/browse/IGNITE-8934 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > > There is a scary error message on the LongJVMPauseDetector stop, which will > be printed on each node stop and it's absolutely unnecesssary -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8934) LongJVMPauseDetector prints error on thread interruption when node stopping
[ https://issues.apache.org/jira/browse/IGNITE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-8934: -- Description: There is a scary error message on the LongJVMPauseDetector stop, which will be printed on each node stop and it's absolutely unnecessary. (was: There is a scary error message on the LongJVMPauseDetector stop, which will be printed on each node stop and it's absolutely unnecesssary) > LongJVMPauseDetector prints error on thread interruption when node stopping > --- > > Key: IGNITE-8934 > URL: https://issues.apache.org/jira/browse/IGNITE-8934 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > > There is a scary error message on the LongJVMPauseDetector stop, which will > be printed on each node stop and it's absolutely unnecessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8934) LongJVMPauseDetector prints error on thread interruption when node stopping
[ https://issues.apache.org/jira/browse/IGNITE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-8934: -- Description: There is a scary error message on the > LongJVMPauseDetector prints error on thread interruption when node stopping > --- > > Key: IGNITE-8934 > URL: https://issues.apache.org/jira/browse/IGNITE-8934 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > > There is a scary error message on the -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8934) LongJVMPauseDetector prints error on thread interruption when node stopping
[ https://issues.apache.org/jira/browse/IGNITE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623582#comment-16623582 ] Evgenii Zhuravlev commented on IGNITE-8934: --- [~NIzhikov], Thank you for looking into this ticket. Yes, I need help with the review, as this issue was fixed more than 2 months ago. > LongJVMPauseDetector prints error on thread interruption when node stopping > --- > > Key: IGNITE-8934 > URL: https://issues.apache.org/jira/browse/IGNITE-8934 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9657) socket leak in TcpDiscoverySpi
[ https://issues.apache.org/jira/browse/IGNITE-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623554#comment-16623554 ] Evgenii Zhuravlev commented on IGNITE-9657: --- Issue fixed, TC looks good: https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F4802%2Fhead=buildTypeStatusDiv > socket leak in TcpDiscoverySpi > -- > > Key: IGNITE-9657 > URL: https://issues.apache.org/jira/browse/IGNITE-9657 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Blocker > Fix For: 2.7 > > > When host from ipFinder can't be resolved, the socket don't close -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9657) socket leak in TcpDiscoverySpi
Evgenii Zhuravlev created IGNITE-9657: - Summary: socket leak in TcpDiscoverySpi Key: IGNITE-9657 URL: https://issues.apache.org/jira/browse/IGNITE-9657 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Evgenii Zhuravlev Assignee: Evgenii Zhuravlev Fix For: 2.7 When host from ipFinder can't be resolved, the socket don't close -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-2389) Need to add ability to swap the queue if it's too long
[
https://issues.apache.org/jira/browse/IGNITE-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev resolved IGNITE-2389.
---
Resolution: Won't Fix
Looks like this improvement isn't needed anymore, since data structures can be
persisted using Ignite native persistence
> Need to add ability to swap the queue if it's too long
> --
>
> Key: IGNITE-2389
> URL: https://issues.apache.org/jira/browse/IGNITE-2389
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Reporter: Valentin Kulichenko
>Priority: Major
>
> In some cases there can be a requirement to start swapping new queue elements
> to avoid out of memory errors. For example, if the consumer temporarily
> stopped for some reason, but the producer still adds elements.
> We can do this based on cache swap space and evictions. I think we should:
> # Add max allowed in-memory elements property to {{CollectionConfiguration}}.
> We can also support limit by memory size.
> # Implement special eviction policy that will evict new queue elements if
> limits are reached.
> # Automatically unswap latest elements when consumer resumes polling (can be
> achieved by a background process).
> In case of {{IgniteSet}}, limits should be also honored, but here we don't
> have ordering. So I think we can use our standard LRU, but make sure that
> only elements are swapped. Header and other meta objects should be always in
> memory.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9486) JobStealing doesn't work with affinityRun
Evgenii Zhuravlev created IGNITE-9486:
-
Summary: JobStealing doesn't work with affinityRun
Key: IGNITE-9486
URL: https://issues.apache.org/jira/browse/IGNITE-9486
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Evgenii Zhuravlev
It rebalances job to the node, that doesn't have needed partition, which lead
to the exception:
{code:java}
[2018-09-06 18:03:47,545][ERROR][pub-#61][GridJobWorker] Failed to lock
partitions [jobId=a29f86fa561-3e2c91e1-1f47-401c-80a2-ea2b452a3cb5,
ses=GridJobSessionImpl [ses=GridTaskSessionImpl
[taskName=o.a.i.examples.ExampleNodeStartup3$1, dep=GridDeployment
[ts=1536246214786, depMode=SHARED,
clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
clsLdrId=606b86fa561-cffc6951-7eef-4a58-82e1-69511458d650, userVer=0, loc=true,
sampleClsName=o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap,
pendingUndeploy=false, undeployed=false, usage=1],
taskClsName=o.a.i.examples.ExampleNodeStartup3$1,
sesId=929f86fa561-3e2c91e1-1f47-401c-80a2-ea2b452a3cb5,
startTime=1536246223300, endTime=9223372036854775807,
taskNodeId=3e2c91e1-1f47-401c-80a2-ea2b452a3cb5,
clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, closed=false, cpSpi=null,
failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=false,
topPred=null, subjId=3e2c91e1-1f47-401c-80a2-ea2b452a3cb5, mapFut=IgniteFuture
[orig=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
hash=30355072]], execName=null],
jobId=a29f86fa561-3e2c91e1-1f47-401c-80a2-ea2b452a3cb5]]
class org.apache.ignite.IgniteException: Failed partition reservation.
Partition is not primary on the node. [partition=1, cacheName=test,
nodeId=cffc6951-7eef-4a58-82e1-69511458d650, topology=AffinityTopologyVersion
[topVer=3, minorTopVer=0]]
at
org.apache.ignite.internal.processors.job.GridJobProcessor$PartitionsReservation.reserve(GridJobProcessor.java:1596)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:510)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
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] [Updated] (IGNITE-9425) NPE on index rebuild
[
https://issues.apache.org/jira/browse/IGNITE-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev updated IGNITE-9425:
--
Ignite Flags: (was: Docs Required)
> NPE on index rebuild
>
>
> Key: IGNITE-9425
> URL: https://issues.apache.org/jira/browse/IGNITE-9425
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.7
>
>
> Summary:
> This issue is seen when we have two caches mapped to two different regions
> (one with persistence and one without persistence)
> The client-side config should have the cache definitions
> The server-side config should have the data regions only
> Affinity should be defined on the cache without persistence
> We need to populate the data into both the caches and then restart the server
> and clients
> The issue will be seen when the client reconnects.
> Workaround:
> Add the cache configurations (for the caches without persistence) to the
> server-side config.
> Steps to reproduce:
> Ignite server
> - region1 (with persistence)
> - region2 (without persistence)
> client
> - cache1a from region1 – with custom affinity
> - cache2a fom region2 – with custom affinity
> 1. Populate data in both cache1a and cache2a.
> 2. Restart ignite server. It knows about cache1a from the persistent store.
> It doesn’t know about cache2a.
> 3. Restart client. When it connects to ignite, the server sees a nullpointer
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1243)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1239)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.rebuildIndexesIfNeeded(GridCacheDatabaseSharedManager.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1711)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:126)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:729)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9425) NPE on index rebuild
[
https://issues.apache.org/jira/browse/IGNITE-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602269#comment-16602269
]
Evgenii Zhuravlev commented on IGNITE-9425:
---
Fix look good to me
> NPE on index rebuild
>
>
> Key: IGNITE-9425
> URL: https://issues.apache.org/jira/browse/IGNITE-9425
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.7
>
>
> Summary:
> This issue is seen when we have two caches mapped to two different regions
> (one with persistence and one without persistence)
> The client-side config should have the cache definitions
> The server-side config should have the data regions only
> Affinity should be defined on the cache without persistence
> We need to populate the data into both the caches and then restart the server
> and clients
> The issue will be seen when the client reconnects.
> Workaround:
> Add the cache configurations (for the caches without persistence) to the
> server-side config.
> Steps to reproduce:
> Ignite server
> - region1 (with persistence)
> - region2 (without persistence)
> client
> - cache1a from region1 – with custom affinity
> - cache2a fom region2 – with custom affinity
> 1. Populate data in both cache1a and cache2a.
> 2. Restart ignite server. It knows about cache1a from the persistent store.
> It doesn’t know about cache2a.
> 3. Restart client. When it connects to ignite, the server sees a nullpointer
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1243)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1239)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.rebuildIndexesIfNeeded(GridCacheDatabaseSharedManager.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1711)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:126)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:729)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8886) Simultaneous using of BinaryWriter и BinaryRawWriter leads to BinaryObjectException and OOM
[
https://issues.apache.org/jira/browse/IGNITE-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597339#comment-16597339
]
Evgenii Zhuravlev commented on IGNITE-8886:
---
[~ilyak], Thank you for the screenshot with an example, change looks good to me.
> Simultaneous using of BinaryWriter и BinaryRawWriter leads to
> BinaryObjectException and OOM
> ---
>
> Key: IGNITE-8886
> URL: https://issues.apache.org/jira/browse/IGNITE-8886
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.5
>Reporter: Roman Guseinov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: binary
> Attachments: BinarylizableInvalidFlag.java, BinarylizableOOM.java,
> Screenshot_20180830_142433.png
>
>
> When we use BinaryWriter and BinaryRawWriter simultaneously inside
> writeBinary method we can get the following exceptions in the process of
> deserializing objects:
> 1. class org.apache.ignite.binary.BinaryObjectException: Invalid flag value:
> 115
> {code:java}
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1302)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1732)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:910)
>at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:608)
>at
> org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag.main(BinarylizableInvalidFlag.java:33)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7322)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:171)
>at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4563)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4537)
>at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1350)
>at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:907)
>... 2 more
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> deserialize object
> [typeName=org.apache.ignite.reproducers.fd7550.BinarylizableInvalidFlag$TestBean]
>at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:909)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
>at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1764)
>at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1752)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:679)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:461)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:342)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:216)
>at
[jira] [Created] (IGNITE-9383) Add to the documentation that Ignite cluster requires that each nodes have direct connection to any nodes of grid.
Evgenii Zhuravlev created IGNITE-9383: - Summary: Add to the documentation that Ignite cluster requires that each nodes have direct connection to any nodes of grid. Key: IGNITE-9383 URL: https://issues.apache.org/jira/browse/IGNITE-9383 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.6 Reporter: Evgenii Zhuravlev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9343) ignite-geospatial is not on maven central
[ https://issues.apache.org/jira/browse/IGNITE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588407#comment-16588407 ] Evgenii Zhuravlev edited comment on IGNITE-9343 at 8/22/18 5:24 AM: Ignite geospatial library (ignite-geospatial) depends on JTS that is available under the LGPL license that is not aligned with Apache license and prevents from including ignite-geospatial into Apache Ignite binary deliveries [1]. Please use ignite users list for asking questions like that in future. [1] https://apacheignite-sql.readme.io/docs/geospatial-support#section-including-ignite-geospatial-library was (Author: ezhuravl): Ignite geospatial library (ignite-geospatial) depends on JTS that is available under the LGPL license that is not aligned with Apache license and prevents from including ignite-geospatial into Apache Ignite binary deliveries [1]. [1] https://apacheignite-sql.readme.io/docs/geospatial-support#section-including-ignite-geospatial-library > ignite-geospatial is not on maven central > - > > Key: IGNITE-9343 > URL: https://issues.apache.org/jira/browse/IGNITE-9343 > Project: Ignite > Issue Type: Bug >Reporter: Grant Haywood >Priority: Minor > > I am wondering why ignite-geospatial is not available on maven central? > > [https://apacheignite-sql.readme.io/docs/geospatial-support#including-ignite-geospatial-library] > > the docs here would lead me to believe I just need to add it to my POM > > is it expected that users need to compile ignite locally to use geospatial > index? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9343) ignite-geospatial is not on maven central
[ https://issues.apache.org/jira/browse/IGNITE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev resolved IGNITE-9343. --- Resolution: Not A Problem Ignite geospatial library (ignite-geospatial) depends on JTS that is available under the LGPL license that is not aligned with Apache license and prevents from including ignite-geospatial into Apache Ignite binary deliveries [1]. [1] https://apacheignite-sql.readme.io/docs/geospatial-support#section-including-ignite-geospatial-library > ignite-geospatial is not on maven central > - > > Key: IGNITE-9343 > URL: https://issues.apache.org/jira/browse/IGNITE-9343 > Project: Ignite > Issue Type: Bug >Reporter: Grant Haywood >Priority: Minor > > I am wondering why ignite-geospatial is not available on maven central? > > [https://apacheignite-sql.readme.io/docs/geospatial-support#including-ignite-geospatial-library] > > the docs here would lead me to believe I just need to add it to my POM > > is it expected that users need to compile ignite locally to use geospatial > index? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6677) Collect QueryDetailMetrics for cache-less SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-6677: - Assignee: Evgenii Zhuravlev (was: Vladimir Ozerov) > Collect QueryDetailMetrics for cache-less SQL queries > - > > Key: IGNITE-6677 > URL: https://issues.apache.org/jira/browse/IGNITE-6677 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.2 >Reporter: Alexey Kuznetsov >Assignee: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > > We have logic that collect query history per caches. > We need: > # Add history size param on IgniteConfiguration > # Implement logic that will collect history for SQL queries executed directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9199) Ignite doesn't save history for SQL queries after setting queryDetailMetricsSize
[ https://issues.apache.org/jira/browse/IGNITE-9199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev resolved IGNITE-9199. --- Resolution: Duplicate > Ignite doesn't save history for SQL queries after setting > queryDetailMetricsSize > > > Key: IGNITE-9199 > URL: https://issues.apache.org/jira/browse/IGNITE-9199 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > > Steps to reproduce: > 1. Start cluster with persistence without queryDetailMetricsSize. > 2. Restart cluster with configured queryDetailMetricsSize. > Ignite save history for SCAN queries only. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9199) Ignite doesn't save history for SQL queries after setting queryDetailMetricsSize
[ https://issues.apache.org/jira/browse/IGNITE-9199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev reassigned IGNITE-9199: - Assignee: Evgenii Zhuravlev > Ignite doesn't save history for SQL queries after setting > queryDetailMetricsSize > > > Key: IGNITE-9199 > URL: https://issues.apache.org/jira/browse/IGNITE-9199 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > > Steps to reproduce: > 1. Start cluster with persistence without queryDetailMetricsSize. > 2. Restart cluster with configured queryDetailMetricsSize. > Ignite save history for SCAN queries only. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574588#comment-16574588
]
Evgenii Zhuravlev commented on IGNITE-5103:
---
[~akalashnikov], thank you for review. I've fixed tests from this suite by
increasing clientFailureDetectionTimeout for these tests and some additional
changes for certain tests:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi_IgniteTests24Java8=pull%2F4446%2Fhead=buildTypeStatusDiv
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
