[jira] [Updated] (IGNITE-13389) Add possibility to obtain full stack trace on thin client side.
[
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-13389:
Reviewer: Vladislav Pyatkov
> Add possibility to obtain full stack trace on thin client side.
> ---
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors
> which contains informative messages for further problem recognition. Possible
> such mechanism need to be disabled on production environment. Example of non
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to
> process request [1]: Failed to update keys (retry update if possible).: [1]
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
> ... 13 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> update keys.
> ... 23 more
> Suppressed: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on search row: SearchRow
> ... 25 more
> Caused by: class org.apache.ignite.IgniteCheckedException:
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
> ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in
> ThinClientConfiguration configured both as direct setting and through JMX
> (ClientProcessorMXBean).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13389) Add possibility to obtain full stack trace on thin client side.
[
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188227#comment-17188227
]
Stanilovsky Evgeny commented on IGNITE-13389:
-
[~v.pyatkov] could you review it plz?
> Add possibility to obtain full stack trace on thin client side.
> ---
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors
> which contains informative messages for further problem recognition. Possible
> such mechanism need to be disabled on production environment. Example of non
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to
> process request [1]: Failed to update keys (retry update if possible).: [1]
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
> ... 13 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> update keys.
> ... 23 more
> Suppressed: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on search row: SearchRow
> ... 25 more
> Caused by: class org.apache.ignite.IgniteCheckedException:
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
> ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in
> ThinClientConfiguration configured both as direct setting and through JMX
> (ClientProcessorMXBean).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12809:
Assignee: Nikolay Izhikov (was: Igor Sapego)
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: python
> Attachments:
> IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch, reproducer.py
>
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188207#comment-17188207
]
Nikolay Izhikov commented on IGNITE-12809:
--
Hello, [~isapego]
I want to work on this ticket.
Are you don't mind?
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Major
> Labels: python
> Attachments:
> IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch, reproducer.py
>
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188246#comment-17188246
]
Nikolay Izhikov commented on IGNITE-12809:
--
https://ci.ignite.apache.org/viewLog.html?buildId=5576255=queuedBuildOverviewTab
- Tests results.
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: python
> Attachments:
> IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch, reproducer.py
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13389) Add possibility to obtain full stack trace on thin client side.
[
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188226#comment-17188226
]
Ignite TC Bot commented on IGNITE-13389:
{panel:title=Branch: [pull/8195/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8195/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5569270]]
* {color:#013220}ClientTestSuite:
IgniteBinaryTest.testBinaryWithNotGenericInterceptor - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5569366buildTypeId=IgniteTests24Java8_RunAll]
> Add possibility to obtain full stack trace on thin client side.
> ---
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors
> which contains informative messages for further problem recognition. Possible
> such mechanism need to be disabled on production environment. Example of non
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to
> process request [1]: Failed to update keys (retry update if possible).: [1]
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
> ... 13 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> update keys.
> ... 23 more
> Suppressed: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on search row: SearchRow
> ... 25 more
> Caused by: class org.apache.ignite.IgniteCheckedException:
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
> ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in
> ThinClientConfiguration configured both as direct setting and through JMX
> (ClientProcessorMXBean).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11974) infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress ...
[
https://issues.apache.org/jira/browse/IGNITE-11974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188952#comment-17188952
]
Henrique commented on IGNITE-11974:
---
Hi [~v.pyatkov],
I've set *RebalanceMode.SYNC* for all my distributed caches and it seems to
have "solved" it. At least it mitigated the issue to a point where I can't
reproduce it.
> infinite loop and 100% cpu in GridDhtPartitionsEvictor: Eviction in progress
> ...
>
>
> Key: IGNITE-11974
> URL: https://issues.apache.org/jira/browse/IGNITE-11974
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Igor Kamyshnikov
>Priority: Blocker
> Attachments: eviction-in-progress-dumps.zip,
> image-2019-07-10-16-07-37-185.png, server-node-restarts-1.png
>
>
> Note: RCA was not done:
> Sometimes ignite server nodes fall into infinite loop and consume 100% cpu:
> {noformat}
> "sys-#260008" #260285 prio=5 os_prio=0 tid=0x7fabb020a800 nid=0x1e850
> runnable [0x7fab26fef000]
>java.lang.Thread.State: RUNNABLE
> at
> java.util.concurrent.ConcurrentHashMap$Traverser.advance(ConcurrentHashMap.java:3339)
> at
> java.util.concurrent.ConcurrentHashMap$ValueIterator.next(ConcurrentHashMap.java:3439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:84)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionsEvictor$1.call(GridDhtPartitionsEvictor.java:73)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - <0x000649b9cba0> (a
> java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> the following appears in logs each 2 minutes:
> {noformat}
> INFO 2019-07-08 12:21:45.081 (1562581305081) [sys-#98168]
> [GridDhtPartitionsEvictor] > Eviction in progress
> [grp=CUSTPRODINVOICEDISCUSAGE, remainingCnt=102]
> {noformat}
> remainingCnt remains the same once it reached 102 (the very first line in the
> logs was with value equal to 101).
> Some other facts:
> we have a heapdump taken for *topVer = 900* . the problem appeared after
> *topVer = 790*, but it looks like it was silently waiting from *topVer = 641*
> (about 24 hours back).
> There were 259 topology changes between 900 and 641.
> All 102 GridDhtLocalPartitions can be found in the heapdump:
> {noformat}
> select * from
> "org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition"
> t where delayedRenting = true
> {noformat}
> They all have status = 65537 , which means (according to
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition#state):
> reservations(65537) = 1
> getPartState(65537) = OWNING
> There are also 26968 instances of
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl$$Lambda$70,
> that are created by
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#checkEvictions
> method.
> 26418 of 26968 refer to AtomicInteger instance with value = 102:
> 26418/102 = 259 = 900 - 641 (see topology info above).
> The key thing seen from the heapdump is that topVer = 641 or topVer = 642 was
> the last topology where these 102 partitions were assigned to the current
> ignite server node.
> {noformat}
> select
> t.this
> ,t.this['clientEvtChange'] as clientEvtChange
> ,t.this['topVer.topVer'] as topVer
>
> ,t.this['assignment.elementData'][555]['elementData'][0]['hostNames.elementData'][0]
> as primary_part
>
> ,t.this['assignment.elementData'][555]['elementData'][1]['hostNames.elementData'][0]
> as secondary_part
> from org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
> t where length(t.this['assignment.elementData']) = 1024
> order by topVer
> {noformat}
> !image-2019-07-10-16-07-37-185.png!
> The connection of a client node at topVer = 790 somehow triggered the
> GridDhtPartitionsEvictor loop to execute.
> Summary:
> 1) it is seen that 102 partitions has one reservation and OWNING state.
> 2) they were backup partitions.
> 3) for some reason their eviction has been silently delaying (because of
> reservations), but each topology change seemed to trigger
[jira] [Commented] (IGNITE-13013) Thick client must not open server sockets when used by serverless functions
[ https://issues.apache.org/jira/browse/IGNITE-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188346#comment-17188346 ] Ivan Bessonov commented on IGNITE-13013: Hi [~alex_pl], I prepared PR for ignite-2.9: [https://github.com/apache/ignite/pull/8199/files] It differs a little bit from master code because we have huge TcpCommunicationSpi refactoring in master. I was careful, test don't show new issues in this branch. I think it's safe to merge it. Thank you! > Thick client must not open server sockets when used by serverless functions > --- > > Key: IGNITE-13013 > URL: https://issues.apache.org/jira/browse/IGNITE-13013 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.10 > > Attachments: image-2020-07-30-18-42-01-266.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > A thick client fails to start if being used inside of a serverless function > such as AWS Lamda or Azure Functions. Cloud providers prohibit opening > network ports to accept connections on the function's end. In short, the > function can only connect to a remote address. > To reproduce, you can follow this tutorial and swap the thin client (used in > the tutorial) with the thick one: > https://www.gridgain.com/docs/tutorials/serverless/azure_functions_tutorial > The thick client needs to support a mode when the communication SPI doesn't > create a server socket if the client is used for serverless computing. This > improvement looks like an extra task of this initiative: > https://issues.apache.org/jira/browse/IGNITE-12438 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13013) Thick client must not open server sockets when used by serverless functions
[
https://issues.apache.org/jira/browse/IGNITE-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188344#comment-17188344
]
Ignite TC Bot commented on IGNITE-13013:
{panel:title=Branch: [pull/8199/head] Base: [ignite-2.9] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5576257]]
{color:#d04437}Control Utility (Zookeeper){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5576259]]
{panel}
{panel:title=Branch: [pull/8199/head] Base: [ignite-2.9] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}SPI{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5574625]]
* {color:#013220}IgniteSpiTestSuite:
GridTotallyUnreachableClientTest.testTotallyUnreachableClient - PASSED{color}
* {color:#013220}IgniteSpiTestSuite:
GridSandboxedClientWithoutNetworkTest.testNodeWithoutNetwork - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5574689]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=6b129c33-8883-479a-86ff-5326a255f3a3, topVer=0,
msgTemplate=null, span=null, nodeId8=539c89e7, msg=, type=NODE_JOINED,
tstamp=1598865841992], val2=AffinityTopologyVersion
[topVer=-7224218227570184834, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=6b129c33-8883-479a-86ff-5326a255f3a3, topVer=0,
msgTemplate=null, span=null, nodeId8=539c89e7, msg=, type=NODE_JOINED,
tstamp=1598865841992], val2=AffinityTopologyVersion
[topVer=-7224218227570184834, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=b925ed34471-adfd3faa-51b2-41ec-8194-a978483d344d, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=95b4a244-cf8c-46d9-9b74-eeb2eacf1715, topVer=0, msgTemplate=null,
span=null, nodeId8=95b4a244, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1598865841992]], val2=AffinityTopologyVersion
[topVer=5859633856586367631, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=b925ed34471-adfd3faa-51b2-41ec-8194-a978483d344d, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=95b4a244-cf8c-46d9-9b74-eeb2eacf1715, topVer=0, msgTemplate=null,
span=null, nodeId8=95b4a244, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1598865841992]], val2=AffinityTopologyVersion
[topVer=5859633856586367631, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5574690]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=5b9af83e-b303-4797-89be-6e9c822e3985, topVer=0,
msgTemplate=null, span=null, nodeId8=b4da6bae, msg=, type=NODE_JOINED,
tstamp=1598865769474], val2=AffinityTopologyVersion
[topVer=6032947771994464230, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=5b9af83e-b303-4797-89be-6e9c822e3985, topVer=0,
msgTemplate=null, span=null, nodeId8=b4da6bae, msg=, type=NODE_JOINED,
tstamp=1598865769474], val2=AffinityTopologyVersion
[topVer=6032947771994464230, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c9ccdd34471-e0e51c02-72c9-498d-88a0-5c9159550f8b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=b8a4b2e0-448c-4c13-80e6-6ea0b073dbd9, topVer=0, msgTemplate=null,
span=null, nodeId8=b8a4b2e0, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1598865769474]], val2=AffinityTopologyVersion
[topVer=6423906890456427985, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c9ccdd34471-e0e51c02-72c9-498d-88a0-5c9159550f8b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[jira] [Commented] (IGNITE-13204) Java Thin client Kubernetes discovery
[ https://issues.apache.org/jira/browse/IGNITE-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188598#comment-17188598 ] Maksim Timonin commented on IGNITE-13204: - Hi [~Vladimir Pligin]! I've submitted PR for a review [1]. Could you please check it? Is it a right way? [1] [https://github.com/apache/ignite/pull/8206|https://github.com/apache/ignite/pull/8206] > Java Thin client Kubernetes discovery > - > > Key: IGNITE-13204 > URL: https://issues.apache.org/jira/browse/IGNITE-13204 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Alexandr >Assignee: Maksim Timonin >Priority: Major > Labels: java > Time Spent: 10m > Remaining Estimate: 0h > > Thin clients should be able to discover servers from within Kubernetes pod > through k8s API, without specifying any IP addresses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13310) Add tracing of SQL queries.
[ https://issues.apache.org/jira/browse/IGNITE-13310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-13310: Description: It's needed to add tracing of SQL queries based on the tracing framework that was added as part of the [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] Tracing of SQL queries must show phases of query execution, their duration, errors and additional information describing each of the phases, such as the number of rows requested from a remote node, SQL query mapping, and so on. was:It's needed to add SQL tracing based on the tracing framework that was added as part of the [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] Summary: Add tracing of SQL queries. (was: Add SQL tracing.) > Add tracing of SQL queries. > --- > > Key: IGNITE-13310 > URL: https://issues.apache.org/jira/browse/IGNITE-13310 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.10 > > > It's needed to add tracing of SQL queries based on the tracing framework > that was added as part of the > [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] > Tracing of SQL queries must show phases of query execution, their duration, > errors and additional information describing each of the phases, such as the > number of rows requested from a remote node, SQL query mapping, and so on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188438#comment-17188438
]
Aleksey Plekhanov commented on IGNITE-12809:
[~nizhikov], cherry-picked to 2.9.
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: python
> Fix For: 2.9
>
> Attachments:
> IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch, reproducer.py
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13382) DurableBackgroundTask can abandon incomplete task
[ https://issues.apache.org/jira/browse/IGNITE-13382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188491#comment-17188491 ] Sergey Chugunov commented on IGNITE-13382: -- [~makedonskaya], Merged to master in commit *04ae61f668b65a6f7881f090c9481cdf3ccad25c*, thank you for contribution! > DurableBackgroundTask can abandon incomplete task > - > > Key: IGNITE-13382 > URL: https://issues.apache.org/jira/browse/IGNITE-13382 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > DurableBackgroundTasks are tracked using metastorage, there's a specific > marker for every task, and it is removed right after the task is complete. > But there's a race between checkpointer and metastorage. End-marker removal > is a logical operation, while task itself is mostly physical (at least the > existing one). So, following scenario is possible: > * Checkpoint occurs in the middle of the task; > * Task is completed before the next checkpoint; > * Metastorage record is deleted, this fact if written to WAL and synced to > the storage; > * Node failed; > * Recovery process applies deletion from metastorage, this means that > DurableBackgroundTasks info is lost; > * But part of the index is still present in the storage. > I think that we should remove markers from metastorage only after the next > checkpoint, this will 100% save us from such situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13382) DurableBackgroundTask can abandon incomplete task
[ https://issues.apache.org/jira/browse/IGNITE-13382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13382: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > DurableBackgroundTask can abandon incomplete task > - > > Key: IGNITE-13382 > URL: https://issues.apache.org/jira/browse/IGNITE-13382 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > DurableBackgroundTasks are tracked using metastorage, there's a specific > marker for every task, and it is removed right after the task is complete. > But there's a race between checkpointer and metastorage. End-marker removal > is a logical operation, while task itself is mostly physical (at least the > existing one). So, following scenario is possible: > * Checkpoint occurs in the middle of the task; > * Task is completed before the next checkpoint; > * Metastorage record is deleted, this fact if written to WAL and synced to > the storage; > * Node failed; > * Recovery process applies deletion from metastorage, this means that > DurableBackgroundTasks info is lost; > * But part of the index is still present in the storage. > I think that we should remove markers from metastorage only after the next > checkpoint, this will 100% save us from such situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13310) Add tracing of SQL queries.
[ https://issues.apache.org/jira/browse/IGNITE-13310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-13310: Description: It's needed to add tracing of SQL queries based on the tracing framework that was added as part of the [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] Tracing of SQL queries must show phases of query execution, their duration, errors and additional information describing each of the phases, such as the number of rows requested from a remote node, SQL query mapping, and so on. For the first step of implementation Its proposed to distinguish the following phases of queries execution: * The overall execution of SQL query. * Opening SQL query cursor. * Closing SQL query cursor. * Cancellation SQL query cursor. * Parsing SQL query. * Processing SQL query execution request. * Processing SQL next result page request. * Processing mapped node response with requested SQL result page. * Execution SQL query by H2. * Reading rows from cursor and preparing result page. * Processing SQL query fail response. * Processing DML query request. * Processing DML query response. * Processing query cancellation request. * Opening cursor iterator. * Opening cursor iterator. * Fetching SQL query result page. * Waiting for SQL query results page to be received. * Processing SQL index range request. * Processing SQL index range response. * Execution of SQL DML query. * Execution of SQL command query which either DDL SQL queries or Ignite native SQL commands. * SQL query partitions reservation. * Update of cache as a result of the SQL DML query. * Processing of incoming batch. And keeps the following info: * SQL query text * SQL query schema * Number of rows that result page contains. * Number of rows that index range response contains. * Name of SQL table. * Number of cache entries to be updated as a result of DML query. was: It's needed to add tracing of SQL queries based on the tracing framework that was added as part of the [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] Tracing of SQL queries must show phases of query execution, their duration, errors and additional information describing each of the phases, such as the number of rows requested from a remote node, SQL query mapping, and so on. For the first step of implementation Its proposed to distinguish the following phases of queries execution: * The overall execution of SQL query. * Opening SQL query cursor. * Closing SQL query cursor. * Cancellation SQL query cursor. * Parsing SQL query. * Processing SQL query execution request. * Processing SQL next result page request. * Processing mapped node response with requested SQL result page. * Execution SQL query by H2. * Reading rows from cursor and preparing result page. * Processing SQL query fail response. * Processing DML query request. * Processing DML query response. * Processing query cancellation request. * Opening cursor iterator. * Opening cursor iterator. * Fetching SQL query result page. * Waiting for SQL query results page to be received. * Processing SQL index range request. * Processing SQL index range response. * Execution of SQL DML query. * Execution of SQL command query which either DDL SQL queries or Ignite native SQL commands. * SQL query partitions reservation. * Update of cache as a result of the SQL DML query. * Processing of incoming batch. And keeps the following info: * 1. SQL query text * 2. SQL query schema * 3. Number of rows that result page contains. * 4. Number of rows that index range response contains. * 5. Name of SQL table. * 6. Number of cache entries to be updated as a result of DML query. > Add tracing of SQL queries. > --- > > Key: IGNITE-13310 > URL: https://issues.apache.org/jira/browse/IGNITE-13310 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > It's needed to add tracing of SQL queries based on the tracing framework > that was added as part of the > [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] > Tracing of SQL queries must show phases of query execution, their duration, > errors and additional information describing each of the phases, such as the > number of rows requested from a remote node, SQL query mapping, and so on. > For the first step of implementation Its proposed to distinguish the > following phases of queries execution: > * The overall execution of SQL query. > * Opening SQL
[jira] [Updated] (IGNITE-13310) Add tracing of SQL queries.
[ https://issues.apache.org/jira/browse/IGNITE-13310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-13310: Description: It's needed to add tracing of SQL queries based on the tracing framework that was added as part of the [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] Tracing of SQL queries must show phases of query execution, their duration, errors and additional information describing each of the phases, such as the number of rows requested from a remote node, SQL query mapping, and so on. For the first step of implementation Its proposed to distinguish the following phases of queries execution: * The overall execution of SQL query. * Opening SQL query cursor. * Closing SQL query cursor. * Cancellation SQL query cursor. * Parsing SQL query. * Processing SQL query execution request. * Processing SQL next result page request. * Processing mapped node response with requested SQL result page. * Execution SQL query by H2. * Reading rows from cursor and preparing result page. * Processing SQL query fail response. * Processing DML query request. * Processing DML query response. * Processing query cancellation request. * Opening cursor iterator. * Opening cursor iterator. * Fetching SQL query result page. * Waiting for SQL query results page to be received. * Processing SQL index range request. * Processing SQL index range response. * Execution of SQL DML query. * Execution of SQL command query which either DDL SQL queries or Ignite native SQL commands. * SQL query partitions reservation. * Update of cache as a result of the SQL DML query. * Processing of incoming batch. And keeps the following info: * 1. SQL query text * 2. SQL query schema * 3. Number of rows that result page contains. * 4. Number of rows that index range response contains. * 5. Name of SQL table. * 6. Number of cache entries to be updated as a result of DML query. was: It's needed to add tracing of SQL queries based on the tracing framework that was added as part of the [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] Tracing of SQL queries must show phases of query execution, their duration, errors and additional information describing each of the phases, such as the number of rows requested from a remote node, SQL query mapping, and so on. > Add tracing of SQL queries. > --- > > Key: IGNITE-13310 > URL: https://issues.apache.org/jira/browse/IGNITE-13310 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > It's needed to add tracing of SQL queries based on the tracing framework > that was added as part of the > [IGNITE-13060|https://issues.apache.org/jira/browse/IGNITE-13060] > Tracing of SQL queries must show phases of query execution, their duration, > errors and additional information describing each of the phases, such as the > number of rows requested from a remote node, SQL query mapping, and so on. > For the first step of implementation Its proposed to distinguish the > following phases of queries execution: > * The overall execution of SQL query. > * Opening SQL query cursor. > * Closing SQL query cursor. > * Cancellation SQL query cursor. > * Parsing SQL query. > * Processing SQL query execution request. > * Processing SQL next result page request. > * Processing mapped node response with requested SQL result page. > * Execution SQL query by H2. > * Reading rows from cursor and preparing result page. > * Processing SQL query fail response. > * Processing DML query request. > * Processing DML query response. > * Processing query cancellation request. > * Opening cursor iterator. > * Opening cursor iterator. > * Fetching SQL query result page. > * Waiting for SQL query results page to be received. > * Processing SQL index range request. > * Processing SQL index range response. > * Execution of SQL DML query. > * Execution of SQL command query which either DDL SQL queries or Ignite > native SQL commands. > * SQL query partitions reservation. > * Update of cache as a result of the SQL DML query. > * Processing of incoming batch. > And keeps the following info: > * 1. SQL query text > * 2. SQL query schema > * 3. Number of rows that result page contains. > * 4. Number of rows that index range response contains. > * 5. Name of SQL table. > * 6. Number of cache entries to be updated as a result of DML query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13013) Thick client must not open server sockets when used by serverless functions
[ https://issues.apache.org/jira/browse/IGNITE-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13013: --- Fix Version/s: (was: 2.10) 2.9 > Thick client must not open server sockets when used by serverless functions > --- > > Key: IGNITE-13013 > URL: https://issues.apache.org/jira/browse/IGNITE-13013 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.9 > > Attachments: image-2020-07-30-18-42-01-266.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > A thick client fails to start if being used inside of a serverless function > such as AWS Lamda or Azure Functions. Cloud providers prohibit opening > network ports to accept connections on the function's end. In short, the > function can only connect to a remote address. > To reproduce, you can follow this tutorial and swap the thin client (used in > the tutorial) with the thick one: > https://www.gridgain.com/docs/tutorials/serverless/azure_functions_tutorial > The thick client needs to support a mode when the communication SPI doesn't > create a server socket if the client is used for serverless computing. This > improvement looks like an extra task of this initiative: > https://issues.apache.org/jira/browse/IGNITE-12438 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13013) Thick client must not open server sockets when used by serverless functions
[ https://issues.apache.org/jira/browse/IGNITE-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188437#comment-17188437 ] Aleksey Plekhanov commented on IGNITE-13013: [~ibessonov], merged to 2.9. Thanks! > Thick client must not open server sockets when used by serverless functions > --- > > Key: IGNITE-13013 > URL: https://issues.apache.org/jira/browse/IGNITE-13013 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.9 > > Attachments: image-2020-07-30-18-42-01-266.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > A thick client fails to start if being used inside of a serverless function > such as AWS Lamda or Azure Functions. Cloud providers prohibit opening > network ports to accept connections on the function's end. In short, the > function can only connect to a remote address. > To reproduce, you can follow this tutorial and swap the thin client (used in > the tutorial) with the thick one: > https://www.gridgain.com/docs/tutorials/serverless/azure_functions_tutorial > The thick client needs to support a mode when the communication SPI doesn't > create a server socket if the client is used for serverless computing. This > improvement looks like an extra task of this initiative: > https://issues.apache.org/jira/browse/IGNITE-12438 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13382) DurableBackgroundTask can abandon incomplete task
[ https://issues.apache.org/jira/browse/IGNITE-13382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13382: - Fix Version/s: 2.10 > DurableBackgroundTask can abandon incomplete task > - > > Key: IGNITE-13382 > URL: https://issues.apache.org/jira/browse/IGNITE-13382 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > DurableBackgroundTasks are tracked using metastorage, there's a specific > marker for every task, and it is removed right after the task is complete. > But there's a race between checkpointer and metastorage. End-marker removal > is a logical operation, while task itself is mostly physical (at least the > existing one). So, following scenario is possible: > * Checkpoint occurs in the middle of the task; > * Task is completed before the next checkpoint; > * Metastorage record is deleted, this fact if written to WAL and synced to > the storage; > * Node failed; > * Recovery process applies deletion from metastorage, this means that > DurableBackgroundTasks info is lost; > * But part of the index is still present in the storage. > I think that we should remove markers from metastorage only after the next > checkpoint, this will 100% save us from such situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12809:
---
Fix Version/s: 2.9
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: python
> Fix For: 2.9
>
> Attachments:
> IGNITE-12809_Fix_and_test_value_ordering_for_client_sql.patch, reproducer.py
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
