[jira] [Assigned] (IGNITE-11107) MVCC: IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs sometimes
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-11107:
---
Assignee: Ivan Pavlukhin
> MVCC:
> IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes
> hangs sometimes
> ---
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Hanging, mvcc_stabilization_stage_1
>
> Sometimes
> IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes
> hangs on PME. Some partitions have not changed their state from {{RENTING}}
> to {{OWNING}}.
> {noformat}
> [2019-01-27 07:20:23,420][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Finished waiting for topology map update
> [igniteInstanceName=distributed.IgniteCachePartitionLossPolicySelfTest4, p=0,
> duration=1415ms]
> [2019-01-27 07:20:23,421][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=2, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> [2019-01-27 07:20:25,023][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=13, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> Thread
> [name="test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%",
> id=35714, state=RUNNABLE, blockCnt=93, waitCnt=1033]
> at sun.management.ThreadImpl.dumpThreads0(Native Method)
> at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:454)
> at o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1370)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:792)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:569)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:560)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes(IgniteCachePartitionLossPolicySelfTest.java:258)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11427) Document custom node fail functional.
Stanilovsky Evgeny created IGNITE-11427: --- Summary: Document custom node fail functional. Key: IGNITE-11427 URL: https://issues.apache.org/jira/browse/IGNITE-11427 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.7 Reporter: Stanilovsky Evgeny Assignee: Artem Budnikov Fix For: 2.8 Attachments: Screenshot_20190227_100539.png Append additional node fail documentation related to [1] [1] https://issues.apache.org/jira/browse/IGNITE-11332 how it looks into jconsole: !Screenshot_20190227_100539.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11425) Log information about inaccessible nodes through Communication
[
https://issues.apache.org/jira/browse/IGNITE-11425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11425:
---
Description:
In case of long getting communication TCP client (longe than this
CONNECTION_ESTABLISH_THRESHOLD_MS = 100) message will printed:
{noformat}
[sys-#20167%dht.CacheGetReadFromBackupFailoverTest0%][TcpCommunicationSpi] TCP
client created [client=GridTcpNioCommunicationClient
[ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=3, bytesRcvd=0, bytesSent=0, bytesRcvd0=0,
bytesSent0=0, select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-3,
igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, finished=false,
heartbeatTs=1550512236151, hashCode=140561231, interrupted=false,
runner=grid-nio-worker-tcp-comm-3-#20147%dht.CacheGetReadFromBackupFailoverTest0%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
[id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5, intOrder=4,
lastExchangeTime=1550512235890, loc=false, ver=2.8.0#20190218-sha1:29232e37,
isClient=false], connected=false, connectCnt=2, queueLimit=4096, reserveCnt=2,
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=0,
resendCnt=0, rcvCnt=0, sentCnt=0, reserved=true, lastAck=0, nodeLeft=false,
node=TcpDiscoveryNode [id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5,
intOrder=4, lastExchangeTime=1550512235890, loc=false,
ver=2.8.0#20190218-sha1:29232e37, isClient=false], connected=false,
connectCnt=2, queueLimit=4096, reserveCnt=2, pairedConnections=false],
super=GridNioSessionImpl [locAddr=/127.0.0.1:38770, rmtAddr=/127.0.0.1:45212,
createTime=1550512236151, closeTime=0, bytesSent=0, bytesRcvd=0, bytesSent0=0,
bytesRcvd0=0, sndSchedTime=1550512236151, lastSndTime=1550512236151,
lastRcvTime=1550512236151, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=org.apache.ignite.internal.util.nio.GridDirectParser@d240a48,
directMode=true], GridConnectionBytesVerifyFilter], accepted=false,
markedForClose=false]], super=GridAbstractCommunicationClient
[lastUsed=1550512236151, closed=false, connIdx=0]], duration=211ms]
{noformat}
but in some cases we can not to get client during time out, and the message
reduce to
{noformat}
TCP client created [client=null, duration=60004 ms]
{noformat}
According to the message you cannot understand which nodes were inaccessible.
Moreover, wants to see the connection trouble earlier than the 10 minutes after.
Should to log ip/host for clear understanding what was the node and log WARN
message each time when need to increase timeout:
{code}
if (lastWaitingTimeout < 6)
lastWaitingTimeout *= 2;
{code}
was:
In case of long getting communication TCP client (longe than this
CONNECTION_ESTABLISH_THRESHOLD_MS = 100) message will printed:
{noformat}
[sys-#20167%dht.CacheGetReadFromBackupFailoverTest0%][TcpCommunicationSpi] TCP
client created [client=GridTcpNioCommunicationClient
[ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=3, bytesRcvd=0, bytesSent=0, bytesRcvd0=0,
bytesSent0=0, select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-3,
igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, finished=false,
heartbeatTs=1550512236151, hashCode=140561231, interrupted=false,
runner=grid-nio-worker-tcp-comm-3-#20147%dht.CacheGetReadFromBackupFailoverTest0%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
[id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5, intOrder=4,
lastExchangeTime=1550512235890, loc=false, ver=2.8.0#20190218-sha1:29232e37,
isClient=false], connected=false, connectCnt=2, queueLimit=4096, reserveCnt=2,
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=0,
resendCnt=0, rcvCnt=0, sentCnt=0, reserved=true, lastAck=0, nodeLeft=false,
node=TcpDiscoveryNode [id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5,
intOrder=4, lastExchangeTime=1550512235890, loc=false,
ver=2.8.0#20190218-sha1:29232e37, isClient=false], connected=false,
connectCnt=2, queueLimit=4096, reserveCnt=2,
[jira] [Updated] (IGNITE-11425) Log information about inaccessible nodes through Communication
[
https://issues.apache.org/jira/browse/IGNITE-11425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11425:
---
Description:
In case of long getting communication TCP client (longe than this
CONNECTION_ESTABLISH_THRESHOLD_MS = 100) message will printed:
{noformat}
[sys-#20167%dht.CacheGetReadFromBackupFailoverTest0%][TcpCommunicationSpi] TCP
client created [client=GridTcpNioCommunicationClient
[ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=3, bytesRcvd=0, bytesSent=0, bytesRcvd0=0,
bytesSent0=0, select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-3,
igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, finished=false,
heartbeatTs=1550512236151, hashCode=140561231, interrupted=false,
runner=grid-nio-worker-tcp-comm-3-#20147%dht.CacheGetReadFromBackupFailoverTest0%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
[id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5, intOrder=4,
lastExchangeTime=1550512235890, loc=false, ver=2.8.0#20190218-sha1:29232e37,
isClient=false], connected=false, connectCnt=2, queueLimit=4096, reserveCnt=2,
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=0,
resendCnt=0, rcvCnt=0, sentCnt=0, reserved=true, lastAck=0, nodeLeft=false,
node=TcpDiscoveryNode [id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5,
intOrder=4, lastExchangeTime=1550512235890, loc=false,
ver=2.8.0#20190218-sha1:29232e37, isClient=false], connected=false,
connectCnt=2, queueLimit=4096, reserveCnt=2, pairedConnections=false],
super=GridNioSessionImpl [locAddr=/127.0.0.1:38770, rmtAddr=/127.0.0.1:45212,
createTime=1550512236151, closeTime=0, bytesSent=0, bytesRcvd=0, bytesSent0=0,
bytesRcvd0=0, sndSchedTime=1550512236151, lastSndTime=1550512236151,
lastRcvTime=1550512236151, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=org.apache.ignite.internal.util.nio.GridDirectParser@d240a48,
directMode=true], GridConnectionBytesVerifyFilter], accepted=false,
markedForClose=false]], super=GridAbstractCommunicationClient
[lastUsed=1550512236151, closed=false, connIdx=0]], duration=211ms]
{noformat}
but in some cases we can not to get client during time out, and the message
reduce to
{noformat}
TCP client created [client=null, duration=60004 ms]
{noformat}
According to the message you cannot understand which nodes were inaccessible.
Moreover, wants to see the connection trouble earlier than the 10 minutes after.
Should to log ip/host for clear understanding what was the node and log WARN
message each time when need to increase timeout:
{code}
if (lastWaitingTimeout < 6)
lastWaitingTimeout *= 2;
{code}
was:
In case of long getting communication TCP client (longe than this
CONNECTION_ESTABLISH_THRESHOLD_MS = 100) message will printed:
{noformat}
[sys-#20167%dht.CacheGetReadFromBackupFailoverTest0%][TcpCommunicationSpi] TCP
client created [client=GridTcpNioCommunicationClient
[ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=3, bytesRcvd=0, bytesSent=0, bytesRcvd0=0,
bytesSent0=0, select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-3,
igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, finished=false,
heartbeatTs=1550512236151, hashCode=140561231, interrupted=false,
runner=grid-nio-worker-tcp-comm-3-#20147%dht.CacheGetReadFromBackupFailoverTest0%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
[id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5, intOrder=4,
lastExchangeTime=1550512235890, loc=false, ver=2.8.0#20190218-sha1:29232e37,
isClient=false], connected=false, connectCnt=2, queueLimit=4096, reserveCnt=2,
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=0,
resendCnt=0, rcvCnt=0, sentCnt=0, reserved=true, lastAck=0, nodeLeft=false,
node=TcpDiscoveryNode [id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5,
intOrder=4, lastExchangeTime=1550512235890, loc=false,
ver=2.8.0#20190218-sha1:29232e37, isClient=false], connected=false,
connectCnt=2, queueLimit=4096, reserveCnt=2,
[jira] [Updated] (IGNITE-11332) Add jmx ability to exclude node from topology.
[
https://issues.apache.org/jira/browse/IGNITE-11332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-11332:
Description:
In very rare corner cases may occur situation that physically unreachable host
still present in topology that may leads to hanging overall cluster operations.
Add ability to exclude with specific warning.
{code:java}
/**
* Exclude node from cluster.
*
* @param nodeId Node id.
*/
@MXBeanDescription("Exclude node from cluster.")
public void excludeNode(String nodeId);{code}
was:
In very rare corner cases may occur situation that physically unreachable host
still present in topology that may leads to hanging overall cluster operations.
Add ability to exclude with specific warning.
{code:java}
/**
* Exclude node from cluster.
*
* @param nodeId Node id.
*/
@MXBeanDescription("Exclude node from cluster.")
public void excludeNode(UUID nodeId);{code}
> Add jmx ability to exclude node from topology.
> --
>
> Key: IGNITE-11332
> URL: https://issues.apache.org/jira/browse/IGNITE-11332
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In very rare corner cases may occur situation that physically unreachable
> host still present in topology that may leads to hanging overall cluster
> operations.
> Add ability to exclude with specific warning.
> {code:java}
> /**
> * Exclude node from cluster.
> *
> * @param nodeId Node id.
> */
> @MXBeanDescription("Exclude node from cluster.")
> public void excludeNode(String nodeId);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11139) Remove deprecated snapshot tags from PageMetaIO.
[ https://issues.apache.org/jira/browse/IGNITE-11139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778915#comment-16778915 ] ankit singh commented on IGNITE-11139: -- Hi [~ivandasch], What do you mean by 'corresponding PageDeltaRecords' should also be removed? Are you saying that we don't want /** Meta page update last successful snapshot id. */ META_PAGE_UPDATE_LAST_SUCCESSFUL_SNAPSHOT_ID (MIXED), /** Meta page update last successful full snapshot id. */ META_PAGE_UPDATE_LAST_SUCCESSFUL_FULL_SNAPSHOT_ID (MIXED), /** Meta page update next snapshot id. */ META_PAGE_UPDATE_NEXT_SNAPSHOT_ID (MIXED), WalRecords? > Remove deprecated snapshot tags from PageMetaIO. > > > Key: IGNITE-11139 > URL: https://issues.apache.org/jira/browse/IGNITE-11139 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinskiy >Assignee: ankit singh >Priority: Major > Fix For: 3.0 > > > After resolving IGNITE-9672, unnecessary methods from PageMetaIO should be > removed. > Also corresponding PageDeltaRecords should be also removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11053) When cluster is absent Notebook paragraph are supposed to saved.
[ https://issues.apache.org/jira/browse/IGNITE-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11053: -- Assignee: Alexander Kalinin (was: Alexey Kuznetsov) > When cluster is absent Notebook paragraph are supposed to saved. > > > Key: IGNITE-11053 > URL: https://issues.apache.org/jira/browse/IGNITE-11053 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > Original Estimate: 6h > Time Spent: 0.5h > Remaining Estimate: 5.5h > > Currently in scope of task IGNITE-10538 we allow user to use notebooks > screen. But when paragraph is executed notebook is not saved on backend and > no message appears that execution failed. > Error message should be added and notebooks saving on execution should be > made. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11139) Remove deprecated snapshot tags from PageMetaIO.
[ https://issues.apache.org/jira/browse/IGNITE-11139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ankit singh reassigned IGNITE-11139: Assignee: ankit singh > Remove deprecated snapshot tags from PageMetaIO. > > > Key: IGNITE-11139 > URL: https://issues.apache.org/jira/browse/IGNITE-11139 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinskiy >Assignee: ankit singh >Priority: Major > Fix For: 3.0 > > > After resolving IGNITE-9672, unnecessary methods from PageMetaIO should be > removed. > Also corresponding PageDeltaRecords should be also removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11053) When cluster is absent Notebook paragraph are supposed to saved.
[ https://issues.apache.org/jira/browse/IGNITE-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11053: -- Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > When cluster is absent Notebook paragraph are supposed to saved. > > > Key: IGNITE-11053 > URL: https://issues.apache.org/jira/browse/IGNITE-11053 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Original Estimate: 6h > Time Spent: 0.5h > Remaining Estimate: 5.5h > > Currently in scope of task IGNITE-10538 we allow user to use notebooks > screen. But when paragraph is executed notebook is not saved on backend and > no message appears that execution failed. > Error message should be added and notebooks saving on execution should be > made. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11053) When cluster is absent Notebook paragraph are supposed to saved.
[ https://issues.apache.org/jira/browse/IGNITE-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11053: -- Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > When cluster is absent Notebook paragraph are supposed to saved. > > > Key: IGNITE-11053 > URL: https://issues.apache.org/jira/browse/IGNITE-11053 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Original Estimate: 6h > Time Spent: 0.5h > Remaining Estimate: 5.5h > > Currently in scope of task IGNITE-10538 we allow user to use notebooks > screen. But when paragraph is executed notebook is not saved on backend and > no message appears that execution failed. > Error message should be added and notebooks saving on execution should be > made. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11053) When cluster is absent Notebook paragraph are supposed to saved.
[ https://issues.apache.org/jira/browse/IGNITE-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778896#comment-16778896 ] Alexander Kalinin commented on IGNITE-11053: [~kuaw26] This problem seems to be fixed after latest closing queries updates. Now notebooks are saved even if cluster or agent is unavailable. Can be closed. > When cluster is absent Notebook paragraph are supposed to saved. > > > Key: IGNITE-11053 > URL: https://issues.apache.org/jira/browse/IGNITE-11053 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > Original Estimate: 6h > Time Spent: 0.5h > Remaining Estimate: 5.5h > > Currently in scope of task IGNITE-10538 we allow user to use notebooks > screen. But when paragraph is executed notebook is not saved on backend and > no message appears that execution failed. > Error message should be added and notebooks saving on execution should be > made. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, abomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11354: -- Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: Actualize grid configurator discovery, store, abomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelay > soLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11322) [USABILITY] Extend Node FAILED message by add consistentId if it exist
[ https://issues.apache.org/jira/browse/IGNITE-11322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778800#comment-16778800 ] Andrey Kalinin commented on IGNITE-11322: - [~antonovsergey93], please review again. > [USABILITY] Extend Node FAILED message by add consistentId if it exist > -- > > Key: IGNITE-11322 > URL: https://issues.apache.org/jira/browse/IGNITE-11322 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: ARomantsov >Assignee: Andrey Kalinin >Priority: Major > Labels: newbie, usability > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Now I having only this > [GridDiscoveryManager] Node FAILED: TcpDiscoveryNode > [id=f8cd73a1-8da5-4a07-b298-55634dd7c9f8, addrs=ArrayList [127.0.0.1], > sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, > lastExchangeTime=1550141566893, loc=false, isClient=false] -- 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] [Commented] (IGNITE-11322) [USABILITY] Extend Node FAILED message by add consistentId if it exist
[
https://issues.apache.org/jira/browse/IGNITE-11322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778766#comment-16778766
]
Ignite TC Bot commented on IGNITE-11322:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3188479]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3183477buildTypeId=IgniteTests24Java8_RunAll]
> [USABILITY] Extend Node FAILED message by add consistentId if it exist
> --
>
> Key: IGNITE-11322
> URL: https://issues.apache.org/jira/browse/IGNITE-11322
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: ARomantsov
>Assignee: Andrey Kalinin
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now I having only this
> [GridDiscoveryManager] Node FAILED: TcpDiscoveryNode
> [id=f8cd73a1-8da5-4a07-b298-55634dd7c9f8, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1550141566893, loc=false, isClient=false]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11426) Denial of Service Attack Vulnerability
[
https://issues.apache.org/jira/browse/IGNITE-11426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Jimenez updated IGNITE-11426:
-
Description:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{quote}{{[ERROR] [grid-nio-worker-client-listener-0-#110|#110]
ClientListenerProcessor - Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3490)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1113)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2339)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1764)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at java.lang.Thread.run(Thread.java:748)
[?:1.8.0_172]}}
{quote}
Relevant Lines:
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L483]
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L541]
*Solution*: On our internal build we opted to replace the assert statements
with conditionals to simply close the session and log a warning if the incoming
message isn't of the expected type. This approach is present throughout other
parts of the codebase, thus it seemed fitting.
was:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{{"}}
{{[ERROR] [grid-nio-worker-client-listener-0-#110] ClientListenerProcessor -
Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
[jira] [Updated] (IGNITE-11426) Denial of Service Attack Vulnerability
[
https://issues.apache.org/jira/browse/IGNITE-11426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Jimenez updated IGNITE-11426:
-
Description:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{quote}{{[ERROR] [grid-nio-worker-client-listener-0-#110|#110]
ClientListenerProcessor - Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3490)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1113)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2339)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1764)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at java.lang.Thread.run(Thread.java:748)
[?:1.8.0_172]}}
{quote}
Relevant Lines:
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L483]
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L541]
*Solution*: On our internal build we opted to replace the assert statements
with conditionals to simply close the session and log a warning if the incoming
message isn't of the expected type. This approach is present throughout other
parts of the codebase, thus it seemed fitting.
was:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{quote}{{[ERROR] [grid-nio-worker-client-listener-0-#110|#110]
ClientListenerProcessor - Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
[jira] [Updated] (IGNITE-11426) Denial of Service Attack Vulnerability
[
https://issues.apache.org/jira/browse/IGNITE-11426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Jimenez updated IGNITE-11426:
-
Description:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{quote}{{[ERROR] [grid-nio-worker-client-listener-0-#110|#110]
ClientListenerProcessor - Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3490)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1113)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2339)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1764)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at java.lang.Thread.run(Thread.java:748)
[?:1.8.0_172]}}
{quote}
Relevant Lines:
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L483]
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L541]
*Solution*: On our internal build we opted to replace the assert statements
with conditionals to simply close the session and log a warning if the incoming
message isn't of the expected type. This approach is present throughout other
parts of the codebase, thus it seemed fitting.
was:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{quote}{{[ERROR] [grid-nio-worker-client-listener-0-#110|#110]
ClientListenerProcessor - Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
[jira] [Updated] (IGNITE-11426) Denial of Service Attack Vulnerability
[
https://issues.apache.org/jira/browse/IGNITE-11426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Jimenez updated IGNITE-11426:
-
Description:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{quote}{{[ERROR] [grid-nio-worker-client-listener-0-#110|#110]
ClientListenerProcessor - Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3490)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1113)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2339)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1764)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at java.lang.Thread.run(Thread.java:748)
[?:1.8.0_172]}}
{quote}
Relevant Lines:
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L483]
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L541]
*Solution*: On our internal build we opted to replace the assert statements
with conditionals to simply close the session and log a warning if the incoming
message isn't of the expected type. This approach is present throughout other
parts of the codebase, thus it seemed fitting.
was:
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{quote}{{[ERROR] [grid-nio-worker-client-listener-0-#110|#110]
ClientListenerProcessor - Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
[jira] [Commented] (IGNITE-11199) Add extra logging for client-server connections in TCP discovery
[
https://issues.apache.org/jira/browse/IGNITE-11199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778591#comment-16778591
]
Ignite TC Bot commented on IGNITE-11199:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3183239buildTypeId=IgniteTests24Java8_RunAll]
> Add extra logging for client-server connections in TCP discovery
>
>
> Key: IGNITE-11199
> URL: https://issues.apache.org/jira/browse/IGNITE-11199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Andrey Kalinin
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When client node connects to a server node, it should print detailed
> information about server (at least, server node ID and consistent ID).
> When server node starts serving client node connection, it also should print
> detailed information about client.
> Currently, all we have is abstract logs about connections.
> On client side:
> {code:java}
> [2019-02-02 17:50:43,270][INFO
> ][grid-nio-worker-tcp-comm-0-#24][TcpCommunicationSpi] Established outgoing
> communication connection [locAddr=/127.0.0.1:53183, rmtAddr=/127.0.0.1:47100]
> [2019-02-02 17:50:43,446][INFO
> ][grid-nio-worker-tcp-comm-1-#25][TcpCommunicationSpi] Established outgoing
> communication connection [locAddr=/127.0.0.1:53184, rmtAddr=/127.0.0.1:47103]
> {code}
> On server side:
> {code:java}
> ./mahina98-2019-02-01.log:<190>Feb 1 18:24:19 mahina98.ca.sbrf.ru 2019-02-01
> 18:24:19.236[INFO
> ][tcp-disco-sock-reader-#5%DPL_GRID%DplGridNodeName%][o.a.i.s.d.tcp.TcpDiscoverySpi][tcp-disco-sock-reader-#5%DPL_GRID%DplGridNodeName%]
> Started serving remote node connection [rmtAddr=/10.124.133.5:56297,
> rmtPort=56297]
> {code}
> This is definetely not enough to find out which clients connected to local
> server node and to which server local client node has been connected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11426) Denial of Service Attack Vulnerability
Gabriel Jimenez created IGNITE-11426:
Summary: Denial of Service Attack Vulnerability
Key: IGNITE-11426
URL: https://issues.apache.org/jira/browse/IGNITE-11426
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Gabriel Jimenez
{{*Problem Statement*: The DiscoverySPI and CommunicationSPI have components
that listen on open ports (Various GridNIOServer(Communication) and
SocketReader(Discovery) instances). These open ports result on a vulnerability
to denial of service attacks. Even more concerning is the fact that the
rejection behavior for GridNIOServer relies on asserting instanceof for the
incoming message (subsequently throwing an exception on failed assertion). This
is relatively costly computationally, and can lead to OutOfMemory issues for
the node JVM. Additionally, the exception is not properly handled by the
GridNIOServer instances, and can result in error messages:}}
{{"}}
{{[ERROR] [grid-nio-worker-client-listener-0-#110] ClientListenerProcessor -
Closing NIO session because of unhandled exception.
org.apache.ignite.IgniteCheckedException: Invalid handshake message at
org.apache.ignite.internal.processors.odbc.ClientListenerNioServerBuffer.read(ClientListenerNioServerBuffer.java:115)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:60)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.processors.odbc.ClientListenerBufferedParser.decode(ClientListenerBufferedParser.java:40)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3490)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
~[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1113)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2339)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1764)
[bdp-ignite-core-2.6.0.jar:2.6.0] at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[bdp-ignite-core-2.6.0.jar:2.6.0] at java.lang.Thread.run(Thread.java:748)
[?:1.8.0_172]}}
{{"}}
{{Relevant Lines:}}
{{[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L483]}}
[https://github.com/apache/ignite/blob/ignite-2.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L541]
*Solution*: On our internal build we opted to replace the assert statements
with conditionals to simply close the session and log a warning if the incoming
message isn't of the expected type. This approach is present throughout other
parts of the codebase, thus it seemed fitting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11425) Log information about inaccessible nodes through Communication
[
https://issues.apache.org/jira/browse/IGNITE-11425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11425:
---
Description:
In case of long getting communication TCP client (longe than this
CONNECTION_ESTABLISH_THRESHOLD_MS = 100) message will printed:
{noformat}
[sys-#20167%dht.CacheGetReadFromBackupFailoverTest0%][TcpCommunicationSpi] TCP
client created [client=GridTcpNioCommunicationClient
[ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=3, bytesRcvd=0, bytesSent=0, bytesRcvd0=0,
bytesSent0=0, select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-3,
igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, finished=false,
heartbeatTs=1550512236151, hashCode=140561231, interrupted=false,
runner=grid-nio-worker-tcp-comm-3-#20147%dht.CacheGetReadFromBackupFailoverTest0%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
[id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5, intOrder=4,
lastExchangeTime=1550512235890, loc=false, ver=2.8.0#20190218-sha1:29232e37,
isClient=false], connected=false, connectCnt=2, queueLimit=4096, reserveCnt=2,
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=0,
resendCnt=0, rcvCnt=0, sentCnt=0, reserved=true, lastAck=0, nodeLeft=false,
node=TcpDiscoveryNode [id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5,
intOrder=4, lastExchangeTime=1550512235890, loc=false,
ver=2.8.0#20190218-sha1:29232e37, isClient=false], connected=false,
connectCnt=2, queueLimit=4096, reserveCnt=2, pairedConnections=false],
super=GridNioSessionImpl [locAddr=/127.0.0.1:38770, rmtAddr=/127.0.0.1:45212,
createTime=1550512236151, closeTime=0, bytesSent=0, bytesRcvd=0, bytesSent0=0,
bytesRcvd0=0, sndSchedTime=1550512236151, lastSndTime=1550512236151,
lastRcvTime=1550512236151, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=org.apache.ignite.internal.util.nio.GridDirectParser@d240a48,
directMode=true], GridConnectionBytesVerifyFilter], accepted=false,
markedForClose=false]], super=GridAbstractCommunicationClient
[lastUsed=1550512236151, closed=false, connIdx=0]], duration=211ms]
{noformat}
but in some cases we can not to get client during time out, and the message
reduce to
TCP client created [client=null, duration=60004 ms]
According to the message you cannot understand which nodes were inaccessible.
Moreover, wants to see the connection trouble earlier than the 10 minutes after.
Should to log ip/host for clear understanding what was the node and log WARN
message each time when need to increase timeout:
{code}
if (lastWaitingTimeout < 6)
lastWaitingTimeout *= 2;
{code}
was:
In case of long getting communication TCP client (longe than this
CONNECTION_ESTABLISH_THRESHOLD_MS = 100) message will printed:
{noformat}
[sys-#20167%dht.CacheGetReadFromBackupFailoverTest0%][TcpCommunicationSpi] TCP
client created [client=GridTcpNioCommunicationClient
[ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=3, bytesRcvd=0, bytesSent=0, bytesRcvd0=0,
bytesSent0=0, select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-3,
igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, finished=false,
heartbeatTs=1550512236151, hashCode=140561231, interrupted=false,
runner=grid-nio-worker-tcp-comm-3-#20147%dht.CacheGetReadFromBackupFailoverTest0%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
[id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5, intOrder=4,
lastExchangeTime=1550512235890, loc=false, ver=2.8.0#20190218-sha1:29232e37,
isClient=false], connected=false, connectCnt=2, queueLimit=4096, reserveCnt=2,
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=0,
resendCnt=0, rcvCnt=0, sentCnt=0, reserved=true, lastAck=0, nodeLeft=false,
node=TcpDiscoveryNode [id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5,
intOrder=4, lastExchangeTime=1550512235890, loc=false,
ver=2.8.0#20190218-sha1:29232e37, isClient=false], connected=false,
connectCnt=2, queueLimit=4096, reserveCnt=2, pairedConnections=false],
[jira] [Created] (IGNITE-11425) Log information about inaccessible nodes through Communication
Vladislav Pyatkov created IGNITE-11425:
--
Summary: Log information about inaccessible nodes through
Communication
Key: IGNITE-11425
URL: https://issues.apache.org/jira/browse/IGNITE-11425
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
In case of long getting communication TCP client (longe than this
CONNECTION_ESTABLISH_THRESHOLD_MS = 100) message will printed:
{noformat}
[sys-#20167%dht.CacheGetReadFromBackupFailoverTest0%][TcpCommunicationSpi] TCP
client created [client=GridTcpNioCommunicationClient
[ses=GridSelectorNioSessionImpl [worker=DirectNioClientWorker
[super=AbstractNioClientWorker [idx=3, bytesRcvd=0, bytesSent=0, bytesRcvd0=0,
bytesSent0=0, select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-3,
igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, finished=false,
heartbeatTs=1550512236151, hashCode=140561231, interrupted=false,
runner=grid-nio-worker-tcp-comm-3-#20147%dht.CacheGetReadFromBackupFailoverTest0%]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
[id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5, intOrder=4,
lastExchangeTime=1550512235890, loc=false, ver=2.8.0#20190218-sha1:29232e37,
isClient=false], connected=false, connectCnt=2, queueLimit=4096, reserveCnt=2,
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=0,
resendCnt=0, rcvCnt=0, sentCnt=0, reserved=true, lastAck=0, nodeLeft=false,
node=TcpDiscoveryNode [id=8a660330-6ddb-4031-b955-4cb4f4b2, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=5,
intOrder=4, lastExchangeTime=1550512235890, loc=false,
ver=2.8.0#20190218-sha1:29232e37, isClient=false], connected=false,
connectCnt=2, queueLimit=4096, reserveCnt=2, pairedConnections=false],
super=GridNioSessionImpl [locAddr=/127.0.0.1:38770, rmtAddr=/127.0.0.1:45212,
createTime=1550512236151, closeTime=0, bytesSent=0, bytesRcvd=0, bytesSent0=0,
bytesRcvd0=0, sndSchedTime=1550512236151, lastSndTime=1550512236151,
lastRcvTime=1550512236151, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=org.apache.ignite.internal.util.nio.GridDirectParser@d240a48,
directMode=true], GridConnectionBytesVerifyFilter], accepted=false,
markedForClose=false]], super=GridAbstractCommunicationClient
[lastUsed=1550512236151, closed=false, connIdx=0]], duration=211ms]
{noformt}
but in some cases we can not to get client during time out, and the message
reduce to
TCP client created [client=null, duration=60004 ms]
According to the message you cannot understand which nodes were inaccessible.
Moreover, wants to see the connection trouble earlier than the 10 minutes after.
Should to log ip/host for clear understanding what was the node and log WARN
message each time when need to increase timeout:
{code}
if (lastWaitingTimeout < 6)
lastWaitingTimeout *= 2;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11377) Display time to baseline auto-adjust event in console.sh
[
https://issues.apache.org/jira/browse/IGNITE-11377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778033#comment-16778033
]
Ignite TC Bot commented on IGNITE-11377:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3174831buildTypeId=IgniteTests24Java8_RunAll]
> Display time to baseline auto-adjust event in console.sh
>
>
> Key: IGNITE-11377
> URL: https://issues.apache.org/jira/browse/IGNITE-11377
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It required to add information about next auto-adjust.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8574) Change Baseline auto-adjust parameters via JMX
[ https://issues.apache.org/jira/browse/IGNITE-8574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-8574: -- Fix Version/s: 2.8 > Change Baseline auto-adjust parameters via JMX > -- > > Key: IGNITE-8574 > URL: https://issues.apache.org/jira/browse/IGNITE-8574 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We would introduce at IGNITE-8571 new parameters. > We need to have option change them via JMX. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11236) Add Distributed Metastorage to the list of IgniteFeatures
[ https://issues.apache.org/jira/browse/IGNITE-11236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777977#comment-16777977 ] Anton Kalashnikov commented on IGNITE-11236: [~ibessonov], looks good for me. > Add Distributed Metastorage to the list of IgniteFeatures > - > > Key: IGNITE-11236 > URL: https://issues.apache.org/jira/browse/IGNITE-11236 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Add Distributed Metastorage to the list of > org.apache.ignite.internal.IgniteFeatures -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10903) [ML] Provide an example with training of regression model and its evaluation
[ https://issues.apache.org/jira/browse/IGNITE-10903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10903: Ignite Flags: (was: Docs Required) > [ML] Provide an example with training of regression model and its evaluation > > > Key: IGNITE-10903 > URL: https://issues.apache.org/jira/browse/IGNITE-10903 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > It could be parametric or non-parametric regression -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6578) Too many diagnostic: Found long running cache future
[ https://issues.apache.org/jira/browse/IGNITE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777936#comment-16777936 ] Roman Guseinov commented on IGNITE-6578: [~ilyak], thanks. > Too many diagnostic: Found long running cache future > > > Key: IGNITE-6578 > URL: https://issues.apache.org/jira/browse/IGNITE-6578 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1, 2.7 >Reporter: Alexander Belyak >Assignee: Roman Guseinov >Priority: Major > Fix For: 2.8 > > Attachments: LongRunningCacheFutureReproducer.java > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Get about 100Mb of message: > [WARN][grid-timeout-worker-...][o.apache.ignite.internal.diagnostic] > Found long running cache future > few equals message per ms! Can loose logs by rotating! Can't read logs > without prefiltering! > Reproducer is attached [^LongRunningCacheFutureReproducer.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11059) Print information about pending locks queue in case of dht local tx timeout.
[ https://issues.apache.org/jira/browse/IGNITE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777942#comment-16777942 ] Alexei Scherbakov commented on IGNITE-11059: [~agoncharuk], I agree, dumping first not yet locked key should be enough for detecting tx blocker. Actually the same thing should be done for org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture#lockKeys. > Print information about pending locks queue in case of dht local tx timeout. > > > Key: IGNITE-11059 > URL: https://issues.apache.org/jira/browse/IGNITE-11059 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Labels: newbie > Fix For: 2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently in case of dht local tx timeout it's hard to understand which keys > was not locked. > Addtional information should be printed in log on timeout containing > information about pending keys: > key, tx info holding a lock (xid, label if present) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7664) SQL: throw sane exception on unsupported SQL statements
[ https://issues.apache.org/jira/browse/IGNITE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-7664: - Fix Version/s: 2.8 > SQL: throw sane exception on unsupported SQL statements > --- > > Key: IGNITE-7664 > URL: https://issues.apache.org/jira/browse/IGNITE-7664 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko >Assignee: Taras Ledkov >Priority: Major > Labels: sql-stability > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Inspired by this SO issue: > [https://stackoverflow.com/questions/48708238/ignite-database-create-schema-assertionerror] > We should handle unsupported stuff more gracefully both in core code and > drivers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11424) Cannot build C++ from tarball of master branch
Ilya Kasnacheev created IGNITE-11424:
Summary: Cannot build C++ from tarball of master branch
Key: IGNITE-11424
URL: https://issues.apache.org/jira/browse/IGNITE-11424
Project: Ignite
Issue Type: Bug
Components: platforms
Reporter: Ilya Kasnacheev
Assignee: Igor Sapego
In a tarball made by mvn initialize -Prelease on fresh master branch:
{code}
% libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:36: installing './ar-lib'
configure.ac:35: installing './compile'
configure.ac:24: installing './config.guess'
configure.ac:24: installing './config.sub'
configure.ac:28: installing './install-sh'
configure.ac:28: installing './missing'
configure.ac:88: error: required file 'network/include/Makefile.in' not found
configure.ac:88: error: required file 'network/Makefile.in' not found
Makefile.am:27: error: required directory ./network does not exist
Makefile.am:22: error: required directory ./network does not exist
Makefile.am:51: error: required directory ./network does not exist
binary/Makefile.am: installing './depcomp'
{code}
Indeed it seems that network/ does not exist
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11423) Multiple configurations to SpringCacheManager
[ https://issues.apache.org/jira/browse/IGNITE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinil Lee updated IGNITE-11423: --- Description: I'm using SpringCacheManager for my project. I want to apply each cache-specific configuration (eg expiry policy), but only one configuration applies when I create the cachemanager. was:I'm using SpringCacheManager for my project. I want to apply each cache-specific configuration (eg expire policy), but only one configuration applies when I create the cachemanager. > Multiple configurations to SpringCacheManager > - > > Key: IGNITE-11423 > URL: https://issues.apache.org/jira/browse/IGNITE-11423 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Jinil Lee >Priority: Minor > Labels: newbie > > I'm using SpringCacheManager for my project. > I want to apply each cache-specific configuration (eg expiry policy), > but only one configuration applies when I create the cachemanager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11423) Multiple configurations to SpringCacheManager
Jinil Lee created IGNITE-11423: -- Summary: Multiple configurations to SpringCacheManager Key: IGNITE-11423 URL: https://issues.apache.org/jira/browse/IGNITE-11423 Project: Ignite Issue Type: Improvement Components: cache Reporter: Jinil Lee I'm using SpringCacheManager for my project. I want to apply each cache-specific configuration (eg expire policy), but only one configuration applies when I create the cachemanager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6578) Too many diagnostic: Found long running cache future
[ https://issues.apache.org/jira/browse/IGNITE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777905#comment-16777905 ] Ilya Kasnacheev commented on IGNITE-6578: - [~guseinov] Thank you for this contribution! I have merged it to master after some tweaks. > Too many diagnostic: Found long running cache future > > > Key: IGNITE-6578 > URL: https://issues.apache.org/jira/browse/IGNITE-6578 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1, 2.7 >Reporter: Alexander Belyak >Assignee: Roman Guseinov >Priority: Major > Attachments: LongRunningCacheFutureReproducer.java > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Get about 100Mb of message: > [WARN][grid-timeout-worker-...][o.apache.ignite.internal.diagnostic] > Found long running cache future > few equals message per ms! Can loose logs by rotating! Can't read logs > without prefiltering! > Reproducer is attached [^LongRunningCacheFutureReproducer.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10860) Exception on GridJobProcessor.stop()
[ https://issues.apache.org/jira/browse/IGNITE-10860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10860: - Ignite Flags: (was: Docs Required) > Exception on GridJobProcessor.stop() > > > Key: IGNITE-10860 > URL: https://issues.apache.org/jira/browse/IGNITE-10860 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kurbanov >Assignee: Anton Kurbanov >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-9056 made calling clear() to throw UnsupportedOperationException from > org.jsr166.ConcurrentLinkedHashMap. > > Need to verify all calls to .clear(). > > java.lang.UnsupportedOperationException: null > at > org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551) > at > org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264) > at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356) > at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575) > at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379) > at org.apache.ignite.Ignition.stop(Ignition.java:225) > at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6578) Too many diagnostic: Found long running cache future
[ https://issues.apache.org/jira/browse/IGNITE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6578: Fix Version/s: 2.8 > Too many diagnostic: Found long running cache future > > > Key: IGNITE-6578 > URL: https://issues.apache.org/jira/browse/IGNITE-6578 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1, 2.7 >Reporter: Alexander Belyak >Assignee: Roman Guseinov >Priority: Major > Fix For: 2.8 > > Attachments: LongRunningCacheFutureReproducer.java > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Get about 100Mb of message: > [WARN][grid-timeout-worker-...][o.apache.ignite.internal.diagnostic] > Found long running cache future > few equals message per ms! Can loose logs by rotating! Can't read logs > without prefiltering! > Reproducer is attached [^LongRunningCacheFutureReproducer.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11050) Potential deadlock caused by DhtColocatedLockFuture#map being called inside topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777885#comment-16777885
]
Alexey Goncharuk commented on IGNITE-11050:
---
Thanks, merged to master.
> Potential deadlock caused by DhtColocatedLockFuture#map being called inside
> topology read lock
> --
>
> Key: IGNITE-11050
> URL: https://issues.apache.org/jira/browse/IGNITE-11050
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observed the following stacktrace on TC during tests analysis:
> {code}
> Thread
> [name="exchange-worker-#18471%near.GridCachePartitionedNodeRestartTest0%",
> id=23715, state=WAITING, blockCnt=860, waitCnt=775]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2bfb6b49,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:173)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:142)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:925)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:826)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:70)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:89)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:1019)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:544)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.txUnlock(IgniteTxManager.java:1764)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1775)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1347)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1075)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3602)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:440)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:390)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3784)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4409)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4399)
> at o.a.i.i.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> o.a.i.i.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
>
[jira] [Commented] (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:comment-tabpanel=16777881#comment-16777881
]
Ignite TC Bot commented on IGNITE-10414:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3183683]]
* IgniteBinaryCacheTestSuite:
GridCachePartitionedLocalStoreSelfTest.testPrimaryNode - 0,0% fails in last 432
master runs.
{color:#d04437}Cache 8{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3183690]]
* IgniteCacheTestSuite8:
FifoEvictionPolicySelfTest.testPartitionedNearEnabledMultiThreaded - 0,0% fails
in last 437 master runs.
{color:#d04437}JDBC Driver{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3183642]]
* IgniteJdbcDriverTestSuite: JdbcMetadataSelfTest.testParametersMetadata - 0,0%
fails in last 430 master runs.
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3183716]]
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3183670]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3183735buildTypeId=IgniteTests24Java8_RunAll]
> 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
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
>
[jira] [Commented] (IGNITE-10860) Exception on GridJobProcessor.stop()
[
https://issues.apache.org/jira/browse/IGNITE-10860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777871#comment-16777871
]
Ignite TC Bot commented on IGNITE-10860:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3183890buildTypeId=IgniteTests24Java8_RunAll]
> Exception on GridJobProcessor.stop()
>
>
> Key: IGNITE-10860
> URL: https://issues.apache.org/jira/browse/IGNITE-10860
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kurbanov
>Assignee: Anton Kurbanov
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-9056 made calling clear() to throw UnsupportedOperationException from
> org.jsr166.ConcurrentLinkedHashMap.
>
> Need to verify all calls to .clear().
>
> java.lang.UnsupportedOperationException: null
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379)
> at org.apache.ignite.Ignition.stop(Ignition.java:225)
> at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10937) Support data page scan for JDBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777863#comment-16777863 ] Pavel Kuznetsov commented on IGNITE-10937: -- [~vozerov] Done! Also merged latest master and added stub for ODBC support > Support data page scan for JDBC > --- > > Key: IGNITE-10937 > URL: https://issues.apache.org/jira/browse/IGNITE-10937 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Sergi Vladykin >Assignee: Pavel Kuznetsov >Priority: Major > Labels: performance > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > In scope jdbc v2 and thin drivers > We need to add connection property that reflects states of data page scan > feature: enabled/disabled/not defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11059) Print information about pending locks queue in case of dht local tx timeout.
[ https://issues.apache.org/jira/browse/IGNITE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777860#comment-16777860 ] Alexey Goncharuk commented on IGNITE-11059: --- [~ivandasch] [~ascherbakov] Do we need to print out all the pending keys. When lock future is used, we always acquire locks sequentially, so no need to print out all keys, we need to print out only one key that actually blocks the lock future and it's actual owner. If the number of keys in lock future is high, it will complicate logs analysis. WDYT? > Print information about pending locks queue in case of dht local tx timeout. > > > Key: IGNITE-11059 > URL: https://issues.apache.org/jira/browse/IGNITE-11059 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Labels: newbie > Fix For: 2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently in case of dht local tx timeout it's hard to understand which keys > was not locked. > Addtional information should be printed in log on timeout containing > information about pending keys: > key, tx info holding a lock (xid, label if present) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11059) Print information about pending locks queue in case of dht local tx timeout.
[ https://issues.apache.org/jira/browse/IGNITE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11059: -- Ignite Flags: (was: Docs Required) > Print information about pending locks queue in case of dht local tx timeout. > > > Key: IGNITE-11059 > URL: https://issues.apache.org/jira/browse/IGNITE-11059 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Labels: newbie > Fix For: 2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently in case of dht local tx timeout it's hard to understand which keys > was not locked. > Addtional information should be printed in log on timeout containing > information about pending keys: > key, tx info holding a lock (xid, label if present) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11050) Potential deadlock caused by DhtColocatedLockFuture#map being called inside topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777853#comment-16777853
]
Stepachev Maksim commented on IGNITE-11050:
---
It's true. I removed it.
> Potential deadlock caused by DhtColocatedLockFuture#map being called inside
> topology read lock
> --
>
> Key: IGNITE-11050
> URL: https://issues.apache.org/jira/browse/IGNITE-11050
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observed the following stacktrace on TC during tests analysis:
> {code}
> Thread
> [name="exchange-worker-#18471%near.GridCachePartitionedNodeRestartTest0%",
> id=23715, state=WAITING, blockCnt=860, waitCnt=775]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2bfb6b49,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:173)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:142)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:925)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:826)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:70)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:89)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:1019)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:544)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.txUnlock(IgniteTxManager.java:1764)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1775)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1347)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1075)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3602)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:440)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:390)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3784)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4409)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4399)
> at o.a.i.i.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> o.a.i.i.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
>
[jira] [Updated] (IGNITE-11171) Assertion on tx preparing
[
https://issues.apache.org/jira/browse/IGNITE-11171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11171:
--
Ignite Flags: (was: Docs Required)
> Assertion on tx preparing
> -
>
> Key: IGNITE-11171
> URL: https://issues.apache.org/jira/browse/IGNITE-11171
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> 2019-01-22
> 14:00:01.203[ERROR][sys-stripe-15-#16%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandle
> r, failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.AssertionError: Got entry removed exception while holding
> transactional lock on entry
> [e=o.a.i.i.processors.cache.GridCacheEntryRemovedException,
> cached=GridDhtCacheEntry
> [rdrs=ReaderId[] [], part=7042, super=GridDistributedCacheEntry
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [part=7042,
> val=SCHEDULED_CHECK_STOP_PAYMENTS_TASK_DPL_defaultSection, hasValBytes=true],
> val=null, startVer=1548154332959,
> ver=GridCacheVersion [topVer=159054171, order=1548061479047, nodeOrder=20],
> hash=1755381247, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=2147483647, order=0, nodeOrder=0]],
> flags=2]]
> java.lang.AssertionError: Got entry removed exception while holding
> transactional lock on entry
> [e=org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException,
> cached=GridDhtCacheEntry [rdrs=ReaderId[] [], part=7042, supe
> r=GridDistributedCacheEntry [super=GridCacheMapEntry [key=KeyCacheObjectImpl
> [part=7042, val=SCHEDULED_CHECK_STOP_PAYMENTS_TASK_DPL_defaultSection,
> hasValBytes=true], val=null, startVer=1548154332959, ver=GridCacheVersion
> [topVer=159054
> 171, order=1548061479047, nodeOrder=20], hash=1755381247,
> extras=GridCacheObsoleteEntryExtras [obsoleteVer=GridCacheVersion
> [topVer=2147483647, order=0, nodeOrder=0]], flags=2
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:512)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1231)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:520)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:161)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:139)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:101)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:181)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:179)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:583)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:382)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:297)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
>
[jira] [Commented] (IGNITE-11050) Potential deadlock caused by DhtColocatedLockFuture#map being called inside topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777852#comment-16777852
]
Ignite TC Bot commented on IGNITE-11050:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3177131buildTypeId=IgniteTests24Java8_RunAll]
> Potential deadlock caused by DhtColocatedLockFuture#map being called inside
> topology read lock
> --
>
> Key: IGNITE-11050
> URL: https://issues.apache.org/jira/browse/IGNITE-11050
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observed the following stacktrace on TC during tests analysis:
> {code}
> Thread
> [name="exchange-worker-#18471%near.GridCachePartitionedNodeRestartTest0%",
> id=23715, state=WAITING, blockCnt=860, waitCnt=775]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2bfb6b49,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:173)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:142)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:925)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:826)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:70)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:89)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:1019)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:544)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.txUnlock(IgniteTxManager.java:1764)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1775)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1347)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1075)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3602)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:440)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:390)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3784)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4409)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4399)
> at o.a.i.i.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> o.a.i.i.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
>
[jira] [Created] (IGNITE-11422) Remove H2 console from documentation
Vladimir Ozerov created IGNITE-11422: Summary: Remove H2 console from documentation Key: IGNITE-11422 URL: https://issues.apache.org/jira/browse/IGNITE-11422 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov H2 console was deprecated as a part of IGNITE-11333. Need to remove all mentions of "H2 console" from documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11333) SQL: Deprecate H2 console
[ https://issues.apache.org/jira/browse/IGNITE-11333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11333: - Fix Version/s: 2.8 > SQL: Deprecate H2 console > - > > Key: IGNITE-11333 > URL: https://issues.apache.org/jira/browse/IGNITE-11333 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > This functional is not tested, not supported and may fail with unexpected > errors. This affects user experience. Need to disable it and create ticket > for relevant documentation update. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11421) There's no AI version in ODBC driver available for the connected client
[
https://issues.apache.org/jira/browse/IGNITE-11421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov updated IGNITE-11421:
---
Summary: There's no AI version in ODBC driver available for the connected
client (was: There's no AI version in ODBC driver available for a connection)
> There's no AI version in ODBC driver available for the connected client
> ---
>
> Key: IGNITE-11421
> URL: https://issues.apache.org/jira/browse/IGNITE-11421
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
>
> I use {{pyodbc}} and successfuly connected to AI cluster
> But all connections attributes have no AI version:
> {noformat}
> conn = drv.connect('odbc', '127.0.0.1', 10800)
> print(conn.getinfo(SQL_DRIVER_NAME))
> Apache Ignite
> print(conn.getinfo(SQL_DRIVER_ODBC_VER))
> 03.00
> print(conn.getinfo(SQL_DRIVER_VER))
> 02.04.
> print(conn.getinfo(SQL_DBMS_VER))
> 02.04.
> print(conn.getinfo(SQL_ODBC_VER ))
> 03.80.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11421) There's no AI version in ODBC driver available for a connection
[
https://issues.apache.org/jira/browse/IGNITE-11421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov updated IGNITE-11421:
---
Description:
I use {{pyodbc}} and successfuly connected to AI cluster
But all connections attributes have no AI version:
{noformat}
conn = drv.connect('odbc', '127.0.0.1', 10800)
print(conn.getinfo(SQL_DRIVER_NAME))
Apache Ignite
print(conn.getinfo(SQL_DRIVER_ODBC_VER))
03.00
print(conn.getinfo(SQL_DRIVER_VER))
02.04.
print(conn.getinfo(SQL_DBMS_VER))
02.04.
print(conn.getinfo(SQL_ODBC_VER ))
03.80.
{noformat}
was:
I use {{pyodbc}} and successfuly connected to AI cluster
But all connections attributes have no AI version:
{noformat}
print(conn.getinfo(SQL_DRIVER_NAME))
Apache Ignite
print(conn.getinfo(SQL_DRIVER_ODBC_VER))
03.00
print(conn.getinfo(SQL_DRIVER_VER))
02.04.
print(conn.getinfo(SQL_DBMS_VER))
02.04.
print(conn.getinfo(SQL_ODBC_VER ))
03.80.
{noformat}
> There's no AI version in ODBC driver available for a connection
> ---
>
> Key: IGNITE-11421
> URL: https://issues.apache.org/jira/browse/IGNITE-11421
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
>
> I use {{pyodbc}} and successfuly connected to AI cluster
> But all connections attributes have no AI version:
> {noformat}
> conn = drv.connect('odbc', '127.0.0.1', 10800)
> print(conn.getinfo(SQL_DRIVER_NAME))
> Apache Ignite
> print(conn.getinfo(SQL_DRIVER_ODBC_VER))
> 03.00
> print(conn.getinfo(SQL_DRIVER_VER))
> 02.04.
> print(conn.getinfo(SQL_DBMS_VER))
> 02.04.
> print(conn.getinfo(SQL_ODBC_VER ))
> 03.80.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11421) There's no AI version in ODBC driver available for a connection
Sergey Kozlov created IGNITE-11421:
--
Summary: There's no AI version in ODBC driver available for a
connection
Key: IGNITE-11421
URL: https://issues.apache.org/jira/browse/IGNITE-11421
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.7
Reporter: Sergey Kozlov
I use {{pyodbc}} and successfuly connected to AI cluster
But all connections attributes have no AI version:
{noformat}
print(conn.getinfo(SQL_DRIVER_NAME))
Apache Ignite
print(conn.getinfo(SQL_DRIVER_ODBC_VER))
03.00
print(conn.getinfo(SQL_DRIVER_VER))
02.04.
print(conn.getinfo(SQL_DBMS_VER))
02.04.
print(conn.getinfo(SQL_ODBC_VER ))
03.80.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777804#comment-16777804
]
Sergey Chugunov edited comment on IGNITE-11356 at 2/26/19 10:43 AM:
[~Pavlukhin],
Now patch looks good to me. As we don't have any regression in tests, lets
proceed with merging it to master.
Thank you for contribution!
was (Author: sergey-chugunov):
[~Pavlukhin],
Now patch looks good to me. As we don't have any regression in tests, lets
proceed with merging it to master.
Thanks for contribution!
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777804#comment-16777804
]
Sergey Chugunov edited comment on IGNITE-11356 at 2/26/19 10:43 AM:
[~Pavlukhin],
Now patch looks good to me. As we don't have any regression in tests, lets
proceed with merging it to master.
Thanks for contribution!
was (Author: sergey-chugunov):
[~Pavlukhin],
Patch looks good to me. As we don't have any regression in tests, lets proceed
with merging it to master.
Thanks for contribution!
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777804#comment-16777804
]
Sergey Chugunov commented on IGNITE-11356:
--
[~Pavlukhin],
Patch looks good to me. As we don't have any regression in tests, lets proceed
with merging it to master.
Thanks for contribution!
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11420) MVCC: Test fails due to unexpected txRollbackException.
Andrew Mashenkov created IGNITE-11420: - Summary: MVCC: Test fails due to unexpected txRollbackException. Key: IGNITE-11420 URL: https://issues.apache.org/jira/browse/IGNITE-11420 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Andrew Mashenkov Next tests are failed with unexpected TxRollbackException in mvcc mode: TxRollbackOnIncorrectParamsTest.testLabelFilledLocalGuarantee TxRollbackOnIncorrectParamsTest.testLabelFilledRemoteGuarantee TxRollbackOnIncorrectParamsTest.testRollbackInsideLocalListenerAfterRemoteFilter TxRollbackOnIncorrectParamsTest.testTimeoutSetLocalGuarantee TxRollbackOnIncorrectParamsTest.testTimeoutSetRemoteGuarantee Seems, smth was missed in IGNITE-10415 fix or during merge to master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11419) Memory leak after multiple restarts of server node within the same jvm
Pavel Vinokurov created IGNITE-11419: Summary: Memory leak after multiple restarts of server node within the same jvm Key: IGNITE-11419 URL: https://issues.apache.org/jira/browse/IGNITE-11419 Project: Ignite Issue Type: Bug Reporter: Pavel Vinokurov Multiple restarts of a server node with enabled persistence and 20 caches lead to OutOfMemory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6578) Too many diagnostic: Found long running cache future
[
https://issues.apache.org/jira/browse/IGNITE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1680#comment-1680
]
Ignite TC Bot commented on IGNITE-6578:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3176421buildTypeId=IgniteTests24Java8_RunAll]
> Too many diagnostic: Found long running cache future
>
>
> Key: IGNITE-6578
> URL: https://issues.apache.org/jira/browse/IGNITE-6578
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.1, 2.7
>Reporter: Alexander Belyak
>Assignee: Roman Guseinov
>Priority: Major
> Attachments: LongRunningCacheFutureReproducer.java
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Get about 100Mb of message:
> [WARN][grid-timeout-worker-...][o.apache.ignite.internal.diagnostic]
> Found long running cache future
> few equals message per ms! Can loose logs by rotating! Can't read logs
> without prefiltering!
> Reproducer is attached [^LongRunningCacheFutureReproducer.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6578) Too many diagnostic: Found long running cache future
[ https://issues.apache.org/jira/browse/IGNITE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1681#comment-1681 ] Roman Guseinov commented on IGNITE-6578: Hi [~ilyak], please take a look at the updated PR. > Too many diagnostic: Found long running cache future > > > Key: IGNITE-6578 > URL: https://issues.apache.org/jira/browse/IGNITE-6578 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1, 2.7 >Reporter: Alexander Belyak >Assignee: Roman Guseinov >Priority: Major > Attachments: LongRunningCacheFutureReproducer.java > > Time Spent: 1.5h > Remaining Estimate: 0h > > Get about 100Mb of message: > [WARN][grid-timeout-worker-...][o.apache.ignite.internal.diagnostic] > Found long running cache future > few equals message per ms! Can loose logs by rotating! Can't read logs > without prefiltering! > Reproducer is attached [^LongRunningCacheFutureReproducer.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11416) DistributedMetaStorage improvements
[ https://issues.apache.org/jira/browse/IGNITE-11416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-11416: --- Description: We need following improvements: * do not write the same value twice in a row, this would lead to history pollution; * add "putAll" functionality on binary level, not in public API yet. This would simplify the migration in future; * do not use "*HistoryItem" class for everything, this is not conventional; * retrieve "dmsVer" from cluster on handshake, this would help to reduce joining node DataBag size drastically; * add "isEmpty()" or "long getVersion()" method to metastorage, will be helpful for components that use it; * there has to be an ability to read data on client nodes, maybe write as well, not sure yet; * implement more optimal in-memory storage for history cache; * start in-memory metastorage at proper time, current implementation does it a bit too late. was: We need following improvements: * do not write the same value twice in a row, this would lead to history pollution; * add "putAll" functionality on binary level, not in public API yet. This would simplify the migration in future; * do not use "*HistoryItem" class for everything, this is not conventional; * retrieve "dmsVer" from cluster on handshake, this would help to reduce joining node DataBag size drastically; * add "isEmpty()" or "long getVersion()" method to metastorage, will be helpful for components that use it; * there has to be an ability to read data on client nodes, maybe write as well, not sure yet. > DistributedMetaStorage improvements > --- > > Key: IGNITE-11416 > URL: https://issues.apache.org/jira/browse/IGNITE-11416 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > > We need following improvements: > * do not write the same value twice in a row, this would lead to history > pollution; > * add "putAll" functionality on binary level, not in public API yet. This > would simplify the migration in future; > * do not use "*HistoryItem" class for everything, this is not conventional; > * retrieve "dmsVer" from cluster on handshake, this would help to reduce > joining node DataBag size drastically; > * add "isEmpty()" or "long getVersion()" method to metastorage, will be > helpful for components that use it; > * there has to be an ability to read data on client nodes, maybe write as > well, not sure yet; > * implement more optimal in-memory storage for history cache; > * start in-memory metastorage at proper time, current implementation does it > a bit too late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel=1666#comment-1666
]
Pavel Kuznetsov commented on IGNITE-10414:
--
[~vozerov] Thank you, yes this change eliminated that jdbc v2 driver doesn't
perform schema normalization on the driver side. The new test cases, confirmed
this. Fixed, made behaviour the same as in thin driver.
scheduling RunAll
> 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
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
>
[jira] [Updated] (IGNITE-6609) H2PkHashIndex.H2Cursor doesn't take in count expiration
[
https://issues.apache.org/jira/browse/IGNITE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6609:
Fix Version/s: 2.8
> H2PkHashIndex.H2Cursor doesn't take in count expiration
> ---
>
> Key: IGNITE-6609
> URL: https://issues.apache.org/jira/browse/IGNITE-6609
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Correct: {{H2Cursor#next}} - expire time is checked;
> Incorrect: {{H2PkHashIndex.H2Cursor#next}} - expired time is ignored.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11418) Document SQL IGNITE.INDEXES view
[
https://issues.apache.org/jira/browse/IGNITE-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-11418:
-
Description: New {{IGNITE.INDEXES}} view was added, which displays indexes
for specific columns. (was: New {{IGNITE.INDEXES}} view was added, which
displays indexes in specific columns. )
> Document SQL IGNITE.INDEXES view
>
>
> Key: IGNITE-11418
> URL: https://issues.apache.org/jira/browse/IGNITE-11418
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
>
> New {{IGNITE.INDEXES}} view was added, which displays indexes for specific
> columns.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11418) Document SQL IGNITE.INDEXES view
Vladimir Ozerov created IGNITE-11418:
Summary: Document SQL IGNITE.INDEXES view
Key: IGNITE-11418
URL: https://issues.apache.org/jira/browse/IGNITE-11418
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Vladimir Ozerov
Assignee: Artem Budnikov
New {{IGNITE.INDEXES}} view was added, which displays indexes in specific
columns.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1639#comment-1639
]
Ivan Pavlukhin commented on IGNITE-11356:
-
Rerun tests after merge with latest master.
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11199) Add extra logging for client-server connections in TCP discovery
[
https://issues.apache.org/jira/browse/IGNITE-11199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1635#comment-1635
]
Andrey Kalinin commented on IGNITE-11199:
-
> "Initialized connection with remote " message - maybe consistent ID is not
> really needed in this message
[~ivan.glukos], in this message, only nodeId and socketAddress are printed.
> below there's code that prints nearly the same message with DEBUG level.
> Maybe we should remove it?
Got it.
> Add extra logging for client-server connections in TCP discovery
>
>
> Key: IGNITE-11199
> URL: https://issues.apache.org/jira/browse/IGNITE-11199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Andrey Kalinin
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When client node connects to a server node, it should print detailed
> information about server (at least, server node ID and consistent ID).
> When server node starts serving client node connection, it also should print
> detailed information about client.
> Currently, all we have is abstract logs about connections.
> On client side:
> {code:java}
> [2019-02-02 17:50:43,270][INFO
> ][grid-nio-worker-tcp-comm-0-#24][TcpCommunicationSpi] Established outgoing
> communication connection [locAddr=/127.0.0.1:53183, rmtAddr=/127.0.0.1:47100]
> [2019-02-02 17:50:43,446][INFO
> ][grid-nio-worker-tcp-comm-1-#25][TcpCommunicationSpi] Established outgoing
> communication connection [locAddr=/127.0.0.1:53184, rmtAddr=/127.0.0.1:47103]
> {code}
> On server side:
> {code:java}
> ./mahina98-2019-02-01.log:<190>Feb 1 18:24:19 mahina98.ca.sbrf.ru 2019-02-01
> 18:24:19.236[INFO
> ][tcp-disco-sock-reader-#5%DPL_GRID%DplGridNodeName%][o.a.i.s.d.tcp.TcpDiscoverySpi][tcp-disco-sock-reader-#5%DPL_GRID%DplGridNodeName%]
> Started serving remote node connection [rmtAddr=/10.124.133.5:56297,
> rmtPort=56297]
> {code}
> This is definetely not enough to find out which clients connected to local
> server node and to which server local client node has been connected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1622#comment-1622
]
Ignite TC Bot commented on IGNITE-11356:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3182665]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3181875buildTypeId=IgniteTests24Java8_RunAll]
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11199) Add extra logging for client-server connections in TCP discovery
[
https://issues.apache.org/jira/browse/IGNITE-11199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1621#comment-1621
]
Andrey Kalinin commented on IGNITE-11199:
-
[~ivan.glukos], look at [IGNITE-11322]. In that ticket I added consistent ID in
toString representation.
> Add extra logging for client-server connections in TCP discovery
>
>
> Key: IGNITE-11199
> URL: https://issues.apache.org/jira/browse/IGNITE-11199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Andrey Kalinin
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When client node connects to a server node, it should print detailed
> information about server (at least, server node ID and consistent ID).
> When server node starts serving client node connection, it also should print
> detailed information about client.
> Currently, all we have is abstract logs about connections.
> On client side:
> {code:java}
> [2019-02-02 17:50:43,270][INFO
> ][grid-nio-worker-tcp-comm-0-#24][TcpCommunicationSpi] Established outgoing
> communication connection [locAddr=/127.0.0.1:53183, rmtAddr=/127.0.0.1:47100]
> [2019-02-02 17:50:43,446][INFO
> ][grid-nio-worker-tcp-comm-1-#25][TcpCommunicationSpi] Established outgoing
> communication connection [locAddr=/127.0.0.1:53184, rmtAddr=/127.0.0.1:47103]
> {code}
> On server side:
> {code:java}
> ./mahina98-2019-02-01.log:<190>Feb 1 18:24:19 mahina98.ca.sbrf.ru 2019-02-01
> 18:24:19.236[INFO
> ][tcp-disco-sock-reader-#5%DPL_GRID%DplGridNodeName%][o.a.i.s.d.tcp.TcpDiscoverySpi][tcp-disco-sock-reader-#5%DPL_GRID%DplGridNodeName%]
> Started serving remote node connection [rmtAddr=/10.124.133.5:56297,
> rmtPort=56297]
> {code}
> This is definetely not enough to find out which clients connected to local
> server node and to which server local client node has been connected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11417) Get rid of CacheRebalanceMode#NONE
Roman Kondakov created IGNITE-11417:
---
Summary: Get rid of CacheRebalanceMode#NONE
Key: IGNITE-11417
URL: https://issues.apache.org/jira/browse/IGNITE-11417
Project: Ignite
Issue Type: Improvement
Components: cache
Reporter: Roman Kondakov
Fix For: 3.0
We should get rid of erroneous and unusable rebalance mode {{NONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
