[jira] [Updated] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[ https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13095: Issue Type: Bug (was: New Feature) > .NET: Thin Client Compute does not cancel task on server when cancelled on > client > - > > Key: IGNITE-13095 > URL: https://issues.apache.org/jira/browse/IGNITE-13095 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Original Estimate: 3h > Time Spent: 2h 20m > Remaining Estimate: 40m > > Client should call OP_RESOURCE_CLOSE to cancel the task on server side. > Test this by reading server logs, "Job was cancelled" should be there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[ https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125598#comment-17125598 ] Pavel Tupitsyn commented on IGNITE-13095: - Merged to master: e9aa94b0370466fe3488ce29420234a1fd3cf103 > .NET: Thin Client Compute does not cancel task on server when cancelled on > client > - > > Key: IGNITE-13095 > URL: https://issues.apache.org/jira/browse/IGNITE-13095 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Original Estimate: 3h > Time Spent: 2h 20m > Remaining Estimate: 40m > > Client should call OP_RESOURCE_CLOSE to cancel the task on server side. > Test this by reading server logs, "Job was cancelled" should be there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[ https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125595#comment-17125595 ] Pavel Tupitsyn commented on IGNITE-13095: - [~ashapkin] thanks, test fixed now. > .NET: Thin Client Compute does not cancel task on server when cancelled on > client > - > > Key: IGNITE-13095 > URL: https://issues.apache.org/jira/browse/IGNITE-13095 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Original Estimate: 3h > Time Spent: 10m > Remaining Estimate: 2h 50m > > Client should call OP_RESOURCE_CLOSE to cancel the task on server side. > Test this by reading server logs, "Job was cancelled" should be there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13097) Ignite OOMs when from local tests with many Caches
[
https://issues.apache.org/jira/browse/IGNITE-13097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125554#comment-17125554
]
Scott Feldstein edited comment on IGNITE-13097 at 6/4/20, 5:43 AM:
---
Suggestion from the forum was to use cache-groups and limit partitions. Both
alleviated this problem. Additionally I was able to reduce my page size to
free up memory.
was (Author: scottmf):
Suggestion from the forum was to use cache-groups and limit partitions. Both
alleviate this. Additionally I was able to reduce my page size to free up
memory.
> Ignite OOMs when from local tests with many Caches
> --
>
> Key: IGNITE-13097
> URL: https://issues.apache.org/jira/browse/IGNITE-13097
> Project: Ignite
> Issue Type: Bug
>Reporter: Scott Feldstein
>Priority: Major
>
> This is the reproduction of a bug that reflects [this user
> post|[http://apache-ignite-users.70518.x6.nabble.com/Random2LruPageEvictionTracker-causing-hanging-in-our-integration-tests-td32239.html]].
> This impacts us in our integration-tests, not in any real environment.
> The reproduction is here -> [https://github.com/scottmf/ignite-oom]
>
> My observation is that each {{IgniteCache}} object takes up almost 8MB. I'm
> pretty sure this is taking up all the off-heap memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13097) Ignite OOMs when from local tests with many Caches
[
https://issues.apache.org/jira/browse/IGNITE-13097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Feldstein resolved IGNITE-13097.
--
Resolution: Fixed
Suggestion from the forum was to use cache-groups and limit partitions. Both
alleviate this. Additionally I was able to reduce my page size to free up
memory.
> Ignite OOMs when from local tests with many Caches
> --
>
> Key: IGNITE-13097
> URL: https://issues.apache.org/jira/browse/IGNITE-13097
> Project: Ignite
> Issue Type: Bug
>Reporter: Scott Feldstein
>Priority: Major
>
> This is the reproduction of a bug that reflects [this user
> post|[http://apache-ignite-users.70518.x6.nabble.com/Random2LruPageEvictionTracker-causing-hanging-in-our-integration-tests-td32239.html]].
> This impacts us in our integration-tests, not in any real environment.
> The reproduction is here -> [https://github.com/scottmf/ignite-oom]
>
> My observation is that each {{IgniteCache}} object takes up almost 8MB. I'm
> pretty sure this is taking up all the off-heap memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[
https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125549#comment-17125549
]
Ignite TC Bot commented on IGNITE-13095:
{panel:title=Branch: [pull/7883/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5362898]]
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5362882]]
* exe: CacheAbstractTransactionalTest.TestTxDeadlockDetection - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5362836]]
* IgniteBasicTestSuite: BPlusTreeReuseSelfTest.testMassiveRemove2_false - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5362859]]
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheWriteBehindStoreMultithreadedSelfTest.testStoreFailureWithoutCoalescing
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5362909&buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Thin Client Compute does not cancel task on server when cancelled on
> client
> -
>
> Key: IGNITE-13095
> URL: https://issues.apache.org/jira/browse/IGNITE-13095
> Project: Ignite
> Issue Type: New Feature
> Components: platforms, thin client
>Affects Versions: 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
> Original Estimate: 3h
> Time Spent: 10m
> Remaining Estimate: 2h 50m
>
> Client should call OP_RESOURCE_CLOSE to cancel the task on server side.
> Test this by reading server logs, "Job was cancelled" should be there.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13104) Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
[
https://issues.apache.org/jira/browse/IGNITE-13104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125496#comment-17125496
]
Ignite TC Bot commented on IGNITE-13104:
{panel:title=Branch: [pull/7886/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5357987&buildTypeId=IgniteTests24Java8_RunAll]
> Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
> --
>
> Key: IGNITE-13104
> URL: https://issues.apache.org/jira/browse/IGNITE-13104
> Project: Ignite
> Issue Type: Improvement
> Components: springdata
>Affects Versions: 2.8.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code}
> /** {@inheritDoc} */
> @Override public void deleteAllById(Iterable ids) {
> if (ids instanceof Set)
> cache.removeAll((Set)ids);
> if (ids instanceof Collection)
> cache.removeAll(new HashSet<>((Collection)ids));
> TreeSet keys = new TreeSet<>();
> for (ID id : ids)
> keys.add(id);
> cache.removeAll(keys);
> }
> {code}
> As you can see cache.removeAll may be executed THREE times in some situations.
> Also this method can throw ClassCast exception if ids collection contains
> objects that are not implement Comparable interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[
https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125484#comment-17125484
]
Ivan Daschinskiy commented on IGNITE-13078:
---
[~isapego] Thank you for review
1. Ok, got it.
2. It seems that I forgot to remove link to odbcinst, it should work with
${ODBC_LIBBRARY}
3. Tests are optional, but its possible to add check if directory exists
4. I have consultancy with [~dmitry.pavlov], he said that its absolutely ok,
but one more notice in LICENCE should be added. Actually, I changed this script
a little bit in order to be compatible with older cmake 3
It's nice to heat, that it works with VS without big issues. I don't expect
this, but it seems that we go to right direction and finally our project will
have unified cross platform build system.
> С++: Add CMake build support
>
>
> Key: IGNITE-13078
> URL: https://issues.apache.org/jira/browse/IGNITE-13078
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, it is hard to build Ignite.C++. Different build process for
> windows and linux, lack of building support on Mac OS X (quite popular OS
> among developers), absolutely not IDE support, except windows and only Visual
> Studio is supported.
> I’d suggest to migrate to CMake build system. It is very popular among open
> source projects, and in Apache Software Foundation too. Notable user: Apache
> Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf
> and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache
> Thrift. Popular column-oriented database ClickHouse also uses CMake.
> CMake is widely supported in many IDE’s on various platforms, notably Visual
> Studio, CLion, Xcode, QtCreator, KDevelop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13078) С++: Add CMake build support
[
https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125451#comment-17125451
]
Igor Sapego edited comment on IGNITE-13078 at 6/4/20, 1:17 AM:
---
[~ivandasch]
Checked it on CentOS 7 and Windows with CLion and msvc 15. See my comments
below:
# Let's change minimal required version for Boost. Now it is set to 1.56 but
CentOS's 7 default is 1.53 and everything works just fine with it.
# We try to link ODBC driver to odbcinst but this is only component of
unixODBC. There is no such library on Windows, nor when iODBC is used AFAIK.
Need to add a check. Also, why don't we link {{$\{ODBC_LIBRARIES}}} provided by
FindOBDC? Maybe it will add odbcinst without need to add it manually?
# I'm not sure, how will it work in binary package, where some of the
directories are missing (like tests). Have anyone tested it?
# FindODBC which is included in project is licensed with BSD License. Is it
compatible with Apache License?
By the way, I faced some compilation errors when building with msvc 15 on
Windows. Filed a ticked: IGNITE-13116
I'm also planning to do some more testing on Windows with tests. Will keep you
posted.
was (Author: isapego):
[~ivandasch]
Checked it on CentOS 7 and Windows with CLion and msvc 15. See my comments
below:
# Let's change minimal required version for Boost. Now it is set to 1.56 but
CentOS's 7 default is 1.53 and everything works just fine with it.
# We try to link to ODBC driver to odbcinst but this is only component of
unixODBC. There is no so lib on Windows, nor when iODBC is used AFAIK. Need to
add a check. Also, why don't we link {{$\{ODBC_LIBRARIES}}} provided by
FindOBDC?
# I'm not sure though, how will it work in binary package, where some of the
directories are missing (like tests). Have anyone tested it?
# FindODBC which is included in project is lecensed with BSD License. Is it
compatible with Apache License?
By the way, I faced some compilation errors when building with msvc 15 on
Windows. Filed a ticked: IGNITE-13116
I'm also planning to do some more testing on Windows with tests. Will keep you
posted.
> С++: Add CMake build support
>
>
> Key: IGNITE-13078
> URL: https://issues.apache.org/jira/browse/IGNITE-13078
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, it is hard to build Ignite.C++. Different build process for
> windows and linux, lack of building support on Mac OS X (quite popular OS
> among developers), absolutely not IDE support, except windows and only Visual
> Studio is supported.
> I’d suggest to migrate to CMake build system. It is very popular among open
> source projects, and in Apache Software Foundation too. Notable user: Apache
> Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf
> and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache
> Thrift. Popular column-oriented database ClickHouse also uses CMake.
> CMake is widely supported in many IDE’s on various platforms, notably Visual
> Studio, CLion, Xcode, QtCreator, KDevelop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13078) С++: Add CMake build support
[
https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125451#comment-17125451
]
Igor Sapego edited comment on IGNITE-13078 at 6/4/20, 1:15 AM:
---
[~ivandasch]
Checked it on CentOS 7 and Windows with CLion and msvc 15. See my comments
below:
# Let's change minimal required version for Boost. Now it is set to 1.56 but
CentOS's 7 default is 1.53 and everything works just fine with it.
# We try to link to ODBC driver to odbcinst but this is only component of
unixODBC. There is no so lib on Windows, nor when iODBC is used AFAIK. Need to
add a check. Also, why don't we link {{$\{ODBC_LIBRARIES}}} provided by
FindOBDC?
# I'm not sure though, how will it work in binary package, where some of the
directories are missing (like tests). Have anyone tested it?
# FindODBC which is included in project is lecensed with BSD License. Is it
compatible with Apache License?
By the way, I faced some compilation errors when building with msvc 15 on
Windows. Filed a ticked: IGNITE-13116
I'm also planning to do some more testing on Windows with tests. Will keep you
posted.
was (Author: isapego):
[~ivandasch]
Checked it on CentOS 7 and Windows with CLion and msvc 15. See my comments
below:
# Let's change minimal required version of Boost. Now it is set to 1.56 but
CentOS's 7 default is 1.53 and everything works just fine with it.
# We try to link to ODBC driver to odbcinst but this is only component of
unixODBC. There is no so lib on Windows, nor when iODBC is used AFAIK. Need to
add a check. Also, why don't we link {{${ODBC_LIBRARIES}}} provided by FindOBDC?
# I'm not sure though, how will it work in binary package, where some of the
directories are missing (like tests). Have anyone tested it?
# FindODBC which is included in project is lecensed with BSD License. Is it
compatible with Apache License?
By the way, I faced some compilation errors when building with msvc 15 on
Windows. Filed a ticked: IGNITE-13116
I'm also planning to do some more testing on Windows with tests. Will keep you
posted.
> С++: Add CMake build support
>
>
> Key: IGNITE-13078
> URL: https://issues.apache.org/jira/browse/IGNITE-13078
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, it is hard to build Ignite.C++. Different build process for
> windows and linux, lack of building support on Mac OS X (quite popular OS
> among developers), absolutely not IDE support, except windows and only Visual
> Studio is supported.
> I’d suggest to migrate to CMake build system. It is very popular among open
> source projects, and in Apache Software Foundation too. Notable user: Apache
> Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf
> and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache
> Thrift. Popular column-oriented database ClickHouse also uses CMake.
> CMake is widely supported in many IDE’s on various platforms, notably Visual
> Studio, CLion, Xcode, QtCreator, KDevelop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[
https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125451#comment-17125451
]
Igor Sapego commented on IGNITE-13078:
--
[~ivandasch]
Checked it on CentOS 7 and Windows with CLion and msvc 15. See my comments
below:
# Let's change minimal required version of Boost. Now it is set to 1.56 but
CentOS's 7 default is 1.53 and everything works just fine with it.
# We try to link to ODBC driver to odbcinst but this is only component of
unixODBC. There is no so lib on Windows, nor when iODBC is used AFAIK. Need to
add a check. Also, why don't we link {{${ODBC_LIBRARIES}}} provided by FindOBDC?
# I'm not sure though, how will it work in binary package, where some of the
directories are missing (like tests). Have anyone tested it?
# FindODBC which is included in project is lecensed with BSD License. Is it
compatible with Apache License?
By the way, I faced some compilation errors when building with msvc 15 on
Windows. Filed a ticked: IGNITE-13116
I'm also planning to do some more testing on Windows with tests. Will keep you
posted.
> С++: Add CMake build support
>
>
> Key: IGNITE-13078
> URL: https://issues.apache.org/jira/browse/IGNITE-13078
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, it is hard to build Ignite.C++. Different build process for
> windows and linux, lack of building support on Mac OS X (quite popular OS
> among developers), absolutely not IDE support, except windows and only Visual
> Studio is supported.
> I’d suggest to migrate to CMake build system. It is very popular among open
> source projects, and in Apache Software Foundation too. Notable user: Apache
> Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf
> and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache
> Thrift. Popular column-oriented database ClickHouse also uses CMake.
> CMake is widely supported in many IDE’s on various platforms, notably Visual
> Studio, CLion, Xcode, QtCreator, KDevelop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13116) CPP: Can not compile using msvc 15
Igor Sapego created IGNITE-13116: Summary: CPP: Can not compile using msvc 15 Key: IGNITE-13116 URL: https://issues.apache.org/jira/browse/IGNITE-13116 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.8.1 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.9 There are linking errors when trying to build Ignite C++ with msvc 15. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13015) Use nano time in node failure detection.
[
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125318#comment-17125318
]
Ignite TC Bot commented on IGNITE-13015:
{panel:title=Branch: [pull/7872/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5346003&buildTypeId=IgniteTests24Java8_RunAll]
> Use nano time in node failure detection.
>
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: iep-45
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Make sure node failure detection do not use:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> We should use nano time instead. Disadventages of current impl.:
> 1)System time has no quarantine of strict forward movement. System time
> can be adjusted, synchronized by NTP as example. This can lead to incorrect
> and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms
> *To fix*:
> {code:java}ServerImpl.lastRingMsgReceivedTime{code} should be nano.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13115) Master key can't be changed if Unicode symbols present
[
https://issues.apache.org/jira/browse/IGNITE-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125275#comment-17125275
]
Pavel Pereslegin edited comment on IGNITE-13115 at 6/3/20, 8:46 PM:
[~NSAmelchev], looks good to me, thanks for fixing this.
was (Author: xtern):
[~NSAmelchev], Looks good to me, thanks for fixing this.
> Master key can't be changed if Unicode symbols present
> --
>
> Key: IGNITE-13115
> URL: https://issues.apache.org/jira/browse/IGNITE-13115
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The master key can't be changed if there are Unicode symbols in the name.
> The reason is the wrong key name length calculation.
> {noformat}
> [2020-06-03
> 18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
> class
> org.apache.ignite.internal.processors.cache.persistence.StorageException:
> Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
> write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
> fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
> ... 18 more
> Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
> [size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386,
> len=418], type=MASTER_KEY_CHANGE_RECORD]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
> ... 17 more
> Caused by: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.
[jira] [Comment Edited] (IGNITE-13115) Master key can't be changed if Unicode symbols present
[
https://issues.apache.org/jira/browse/IGNITE-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125275#comment-17125275
]
Pavel Pereslegin edited comment on IGNITE-13115 at 6/3/20, 8:46 PM:
[~NSAmelchev], Looks good to me, thanks for fixing this.
was (Author: xtern):
[~NSAmelchev], lgtm, thanks for fixing this.
> Master key can't be changed if Unicode symbols present
> --
>
> Key: IGNITE-13115
> URL: https://issues.apache.org/jira/browse/IGNITE-13115
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The master key can't be changed if there are Unicode symbols in the name.
> The reason is the wrong key name length calculation.
> {noformat}
> [2020-06-03
> 18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
> class
> org.apache.ignite.internal.processors.cache.persistence.StorageException:
> Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
> write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
> fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
> ... 18 more
> Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
> [size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386,
> len=418], type=MASTER_KEY_CHANGE_RECORD]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
> ... 17 more
> Caused by: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1
[jira] [Comment Edited] (IGNITE-13115) Master key can't be changed if Unicode symbols present
[
https://issues.apache.org/jira/browse/IGNITE-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125275#comment-17125275
]
Pavel Pereslegin edited comment on IGNITE-13115 at 6/3/20, 8:37 PM:
[~NSAmelchev], lgtm, thanks for fixing this.
was (Author: xtern):
LGTM, thanks for fixing this.
> Master key can't be changed if Unicode symbols present
> --
>
> Key: IGNITE-13115
> URL: https://issues.apache.org/jira/browse/IGNITE-13115
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The master key can't be changed if there are Unicode symbols in the name.
> The reason is the wrong key name length calculation.
> {noformat}
> [2020-06-03
> 18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
> class
> org.apache.ignite.internal.processors.cache.persistence.StorageException:
> Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
> write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
> fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
> ... 18 more
> Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
> [size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386,
> len=418], type=MASTER_KEY_CHANGE_RECORD]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
> ... 17 more
> Caused by: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writePlainRecord
[jira] [Commented] (IGNITE-13115) Master key can't be changed if Unicode symbols present
[
https://issues.apache.org/jira/browse/IGNITE-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125275#comment-17125275
]
Pavel Pereslegin commented on IGNITE-13115:
---
LGTM, thanks for fixing this.
> Master key can't be changed if Unicode symbols present
> --
>
> Key: IGNITE-13115
> URL: https://issues.apache.org/jira/browse/IGNITE-13115
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The master key can't be changed if there are Unicode symbols in the name.
> The reason is the wrong key name length calculation.
> {noformat}
> [2020-06-03
> 18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
> class
> org.apache.ignite.internal.processors.cache.persistence.StorageException:
> Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
> write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
> fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
> ... 18 more
> Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
> [size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386,
> len=418], type=MASTER_KEY_CHANGE_RECORD]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
> ... 17 more
> Caused by: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writePlainRecord(RecordDataV1Serializer.java:1821)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializ
[jira] [Updated] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10959: - Fix Version/s: 2.9 > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.9 > > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > continuousquery_leak_profile.png, referencepath.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125189#comment-17125189
]
Ivan Pavlukhin commented on IGNITE-13094:
-
[~ilyak], the patch looks good.
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Class locally deployed: class
> com.sonic.sample.springboot.controller.WebController
> 2020-05-28 07:00:48.890 WARN 8460 --- [p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback
> java.lang.ClassNotFoundException: ch.qos.logback
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_121]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_121]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> ~[na:1.8.0_121]
> at java.lang.C
[jira] [Comment Edited] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125127#comment-17125127 ] Maksim Timonin edited comment on IGNITE-13051 at 6/3/20, 4:47 PM: -- [~ascherbakov] could you please provide commit id where tests are failing. They're working on my machine with last version of branch ignite-13003 and cherry-picked my commit check attachments - there are pictures from my laptop was (Author: timonin.maksim): [~ascherbakov] could you please provide commit id where tests are failing. They're working on my machine with last version of branch ignite-13003 and cherry-picked my commit > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Attachments: Снимок экрана 2020-06-03 в 19.41.53.png, Снимок экрана > 2020-06-03 в 19.42.44.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125127#comment-17125127 ] Maksim Timonin commented on IGNITE-13051: - [~ascherbakov] could you please provide commit id where tests are failing. They're working on my machine with last version of branch ignite-13003 and cherry-picked my commit > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Attachments: Снимок экрана 2020-06-03 в 19.41.53.png, Снимок экрана > 2020-06-03 в 19.42.44.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-13051: Attachment: Снимок экрана 2020-06-03 в 19.42.44.png Снимок экрана 2020-06-03 в 19.41.53.png > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Attachments: Снимок экрана 2020-06-03 в 19.41.53.png, Снимок экрана > 2020-06-03 в 19.42.44.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13083) Double adding "onSegmentArchived" observer to SegmentArchivedStorage
[ https://issues.apache.org/jira/browse/IGNITE-13083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-13083: - Fix Version/s: 2.9 > Double adding "onSegmentArchived" observer to SegmentArchivedStorage > > > Key: IGNITE-13083 > URL: https://issues.apache.org/jira/browse/IGNITE-13083 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > SegmentCompressStorage is build with static method > SegmentCompressStorage#buildCompressStorage, where private constructor is > called, and the same observer storage::onSegmentArchived is added to same > SegmentArchivedStorage in constructor and in the static method. This can > cause double call of SegmentCompressStorage#onSegmentArchived. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13065) Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read property 'length' of null
[ https://issues.apache.org/jira/browse/IGNITE-13065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125087#comment-17125087 ] Maxim Losevskoy commented on IGNITE-13065: -- Hi there! According to [this vote|[http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Stop-Maintenance-of-Ignite-WebConsole-td47451.html]] Ignite Web Console is not maintained anymore. I would advise to try out [GridGain Web Console|[https://www.gridgain.com/docs/web-console/latest/web-console-getting-started]] instead, it also should be compatible with Ignite > Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read > property 'length' of null > - > > Key: IGNITE-13065 > URL: https://issues.apache.org/jira/browse/IGNITE-13065 > Project: Ignite > Issue Type: Bug >Reporter: david >Priority: Critical > > Hi, > I am using docker to host the web console and have pulled the latest image > from docker. I have upgraded my ignite server to 2.8.0 but co no longer > perform scans of my cache > > Has a new docker image for the web console been pushed to docker to support > ignite 2.8.0? > > thank you > David -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov reopened IGNITE-13051: > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13115) Master key can't be changed if Unicode symbols present
[
https://issues.apache.org/jira/browse/IGNITE-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13115:
-
Fix Version/s: 2.9
> Master key can't be changed if Unicode symbols present
> --
>
> Key: IGNITE-13115
> URL: https://issues.apache.org/jira/browse/IGNITE-13115
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The master key can't be changed if there are Unicode symbols in the name.
> The reason is the wrong key name length calculation.
> {noformat}
> [2020-06-03
> 18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
> class
> org.apache.ignite.internal.processors.cache.persistence.StorageException:
> Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
> write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
> fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
> ... 18 more
> Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
> [size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386,
> len=418], type=MASTER_KEY_CHANGE_RECORD]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
> ... 17 more
> Caused by: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writePlainRecord(RecordDataV1Serializer.java:1821)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV2Serializer.writePlainRecord(RecordDataV2Serializer.j
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125085#comment-17125085 ] Alexey Scherbakov commented on IGNITE-13051: [~avinogradov] [~timonin.maksim] The fix is incorrect, it works only if a node has joined. The test mentioned in the ticket desciption still hangs. I've reopened the ticket. > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13115) Master key can't be changed if Unicode symbols present
[
https://issues.apache.org/jira/browse/IGNITE-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13115:
-
Description:
The master key can't be changed if there are Unicode symbols in the name.
The reason is the wrong key name length calculation.
{noformat}
[2020-06-03
18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
class org.apache.ignite.internal.processors.cache.persistence.StorageException:
Unable to write
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
at
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
at
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
at
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
at
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
at
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
at
org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
... 18 more
Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
[size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386, len=418],
type=MASTER_KEY_CHANGE_RECORD]
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
... 17 more
Caused by: java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
at java.nio.ByteBuffer.put(ByteBuffer.java:859)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writePlainRecord(RecordDataV1Serializer.java:1821)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV2Serializer.writePlainRecord(RecordDataV2Serializer.java:332)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writeRecord(RecordDataV1Serializer.java:238)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer$2.writeWithHeaders(RecordV2Serializer.java:189)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.writeWithCrc(RecordV1Serializer.java:414)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer.writeRec
[jira] [Updated] (IGNITE-13115) Master key can't be changed if Unicode symbols present
[
https://issues.apache.org/jira/browse/IGNITE-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13115:
-
Summary: Master key can't be changed if Unicode symbols present (was:
Master key name can't be changed if Unicode symbols present)
> Master key can't be changed if Unicode symbols present
> --
>
> Key: IGNITE-13115
> URL: https://issues.apache.org/jira/browse/IGNITE-13115
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
>
> The master key name can't be changed if Unicode symbols present.
> The reason is the wrong key name length calculation.
> {noformat}
> [2020-06-03
> 18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
> class
> org.apache.ignite.internal.processors.cache.persistence.StorageException:
> Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
> write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
> fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
> ... 18 more
> Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
> [size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386,
> len=418], type=MASTER_KEY_CHANGE_RECORD]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
> ... 17 more
> Caused by: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writePlainRecord(RecordDataV1Serializer.java:1821)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV2Serializer.writePlainRecord(R
[jira] [Created] (IGNITE-13115) Master key name can't be changed if Unicode symbols present
Amelchev Nikita created IGNITE-13115:
Summary: Master key name can't be changed if Unicode symbols
present
Key: IGNITE-13115
URL: https://issues.apache.org/jira/browse/IGNITE-13115
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The master key name can't be changed if Unicode symbols present.
The reason is the wrong key name length calculation.
{noformat}
[2020-06-03
18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
class org.apache.ignite.internal.processors.cache.persistence.StorageException:
Unable to write
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
at
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
at
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
at
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
at
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
at
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
at
org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to
write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0,
fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
... 18 more
Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord
[size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386, len=418],
type=MASTER_KEY_CHANGE_RECORD]
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
... 17 more
Caused by: java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
at java.nio.ByteBuffer.put(ByteBuffer.java:859)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writePlainRecord(RecordDataV1Serializer.java:1821)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV2Serializer.writePlainRecord(RecordDataV2Serializer.java:332)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writeRecord(RecordDataV1Serializer.java:238)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer$2.writeWithHeaders(RecordV2Serializer.java:189)
at
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.R
[jira] [Updated] (IGNITE-13015) Use nano time in node failure detection.
[
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13015:
--
Description:
Make sure node failure detection do not use:
{code:java}
System.currentTimeMillis()
and
IgniteUtils.currentTimeMillis()
{code}
We should use nano time instead. Disadventages of current impl.:
1) System time has no quarantine of strict forward movement. System time
can be adjusted, synchronized by NTP as example. This can lead to incorrect and
negative delays.
2) IgniteUtils.currentTimeMillis() is granulated by 10ms
*To fix*:
{code:java}ServerImpl.lastRingMsgReceivedTime{code} should be nano.
was:
Make sure node failure detection do not use:
{code:java}
System.currentTimeMillis()
and
IgniteUtils.currentTimeMillis()
{code}
We should use nano time instead. Disadventages of current impl.:
1) System time has no quarantine of strict forward movement. System time
can be adjusted, synchronized by NTP as example. This can lead to incorrect and
negative delays.
2) IgniteUtils.currentTimeMillis() is granulated by 10ms
> Use nano time in node failure detection.
>
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: iep-45
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Make sure node failure detection do not use:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> We should use nano time instead. Disadventages of current impl.:
> 1)System time has no quarantine of strict forward movement. System time
> can be adjusted, synchronized by NTP as example. This can lead to incorrect
> and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms
> *To fix*:
> {code:java}ServerImpl.lastRingMsgReceivedTime{code} should be nano.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13104) Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
[
https://issues.apache.org/jira/browse/IGNITE-13104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125023#comment-17125023
]
Ilya Kasnacheev commented on IGNITE-13104:
--
OK, let's go ahead once you fix CRUD abbrev. Please post the visa from bot.
> Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
> --
>
> Key: IGNITE-13104
> URL: https://issues.apache.org/jira/browse/IGNITE-13104
> Project: Ignite
> Issue Type: Improvement
> Components: springdata
>Affects Versions: 2.8.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code}
> /** {@inheritDoc} */
> @Override public void deleteAllById(Iterable ids) {
> if (ids instanceof Set)
> cache.removeAll((Set)ids);
> if (ids instanceof Collection)
> cache.removeAll(new HashSet<>((Collection)ids));
> TreeSet keys = new TreeSet<>();
> for (ID id : ids)
> keys.add(id);
> cache.removeAll(keys);
> }
> {code}
> As you can see cache.removeAll may be executed THREE times in some situations.
> Also this method can throw ClassCast exception if ids collection contains
> objects that are not implement Comparable interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13114) Off-by-one error in GridPortProcessor port number assertion
[ https://issues.apache.org/jira/browse/IGNITE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125020#comment-17125020 ] Chris Dennis edited comment on IGNITE-13114 at 6/3/20, 2:51 PM: Patch available here: [https://github.com/apache/ignite/pull/7896] was (Author: chrisdennis): Patcha available here: https://github.com/apache/ignite/pull/7896 > Off-by-one error in GridPortProcessor port number assertion > --- > > Key: IGNITE-13114 > URL: https://issues.apache.org/jira/browse/IGNITE-13114 > Project: Ignite > Issue Type: Bug >Reporter: Chris Dennis >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > GridPortProcessor asserts that the provided port number is `> 0` and `< > 65535`. This upper bounds check should be `<= 65535`. Since this is a Java > language assert it's likely to never be tripped in any production system, but > could be seen when using Ignite in a testing environment that turns on these > assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13114) Off-by-one error in GridPortProcessor port number assertion
[ https://issues.apache.org/jira/browse/IGNITE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125022#comment-17125022 ] Chris Dennis edited comment on IGNITE-13114 at 6/3/20, 2:51 PM: Mentioning [~avinogradov] as a maintainer as requested. Note that this is currently formulated as a Daggy bug-fix ([https://wiki.monotone.ca/DaggyFixes/)] since this is the Git bug-fix pattern I am most used to (and because this bug is so old, and probably affect all Ignite releases). It either needs a manual merge fix via the github UI, or I'll need to create an integration branch for it. Let me know if more work is needed on my side. was (Author: chrisdennis): Mentioning [~avinogradov] as a maintainer a requested. Note that this is currently formulated as a Daggy bug-fix ([https://wiki.monotone.ca/DaggyFixes/)] since this is the Git bug-fix pattern I am most used to (and because this bug is so old, and probably affect all Ignite releases). It either needs a manual merge fix via the github UI, or I'll need to create an integration branch for it. Let me know if more work is needed on my side. > Off-by-one error in GridPortProcessor port number assertion > --- > > Key: IGNITE-13114 > URL: https://issues.apache.org/jira/browse/IGNITE-13114 > Project: Ignite > Issue Type: Bug >Reporter: Chris Dennis >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > GridPortProcessor asserts that the provided port number is `> 0` and `< > 65535`. This upper bounds check should be `<= 65535`. Since this is a Java > language assert it's likely to never be tripped in any production system, but > could be seen when using Ignite in a testing environment that turns on these > assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13114) Off-by-one error in GridPortProcessor port number assertion
[ https://issues.apache.org/jira/browse/IGNITE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125022#comment-17125022 ] Chris Dennis commented on IGNITE-13114: --- Mentioning [~avinogradov] as a maintainer a requested. Note that this is currently formulated as a Daggy bug-fix ([https://wiki.monotone.ca/DaggyFixes/)] since this is the Git bug-fix pattern I am most used to (and because this bug is so old, and probably affect all Ignite releases). It either needs a manual merge fix via the github UI, or I'll need to create an integration branch for it. Let me know if more work is needed on my side. > Off-by-one error in GridPortProcessor port number assertion > --- > > Key: IGNITE-13114 > URL: https://issues.apache.org/jira/browse/IGNITE-13114 > Project: Ignite > Issue Type: Bug >Reporter: Chris Dennis >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > GridPortProcessor asserts that the provided port number is `> 0` and `< > 65535`. This upper bounds check should be `<= 65535`. Since this is a Java > language assert it's likely to never be tripped in any production system, but > could be seen when using Ignite in a testing environment that turns on these > assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13114) Off-by-one error in GridPortProcessor port number assertion
[ https://issues.apache.org/jira/browse/IGNITE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Dennis updated IGNITE-13114: -- Flags: (was: Patch) > Off-by-one error in GridPortProcessor port number assertion > --- > > Key: IGNITE-13114 > URL: https://issues.apache.org/jira/browse/IGNITE-13114 > Project: Ignite > Issue Type: Bug >Reporter: Chris Dennis >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > GridPortProcessor asserts that the provided port number is `> 0` and `< > 65535`. This upper bounds check should be `<= 65535`. Since this is a Java > language assert it's likely to never be tripped in any production system, but > could be seen when using Ignite in a testing environment that turns on these > assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13114) Off-by-one error in GridPortProcessor port number assertion
[ https://issues.apache.org/jira/browse/IGNITE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Dennis updated IGNITE-13114: -- Flags: Patch Patcha available here: https://github.com/apache/ignite/pull/7896 > Off-by-one error in GridPortProcessor port number assertion > --- > > Key: IGNITE-13114 > URL: https://issues.apache.org/jira/browse/IGNITE-13114 > Project: Ignite > Issue Type: Bug >Reporter: Chris Dennis >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > GridPortProcessor asserts that the provided port number is `> 0` and `< > 65535`. This upper bounds check should be `<= 65535`. Since this is a Java > language assert it's likely to never be tripped in any production system, but > could be seen when using Ignite in a testing environment that turns on these > assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13065) Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read property 'length' of null
[ https://issues.apache.org/jira/browse/IGNITE-13065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125018#comment-17125018 ] Peter Ivanov commented on IGNITE-13065: --- [~imurchenko], can you look through? > Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read > property 'length' of null > - > > Key: IGNITE-13065 > URL: https://issues.apache.org/jira/browse/IGNITE-13065 > Project: Ignite > Issue Type: Bug >Reporter: david >Priority: Critical > > Hi, > I am using docker to host the web console and have pulled the latest image > from docker. I have upgraded my ignite server to 2.8.0 but co no longer > perform scans of my cache > > Has a new docker image for the web console been pushed to docker to support > ignite 2.8.0? > > thank you > David -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13114) Off-by-one error in GridPortProcessor port number assertion
Chris Dennis created IGNITE-13114: - Summary: Off-by-one error in GridPortProcessor port number assertion Key: IGNITE-13114 URL: https://issues.apache.org/jira/browse/IGNITE-13114 Project: Ignite Issue Type: Bug Reporter: Chris Dennis GridPortProcessor asserts that the provided port number is `> 0` and `< 65535`. This upper bounds check should be `<= 65535`. Since this is a Java language assert it's likely to never be tripped in any production system, but could be seen when using Ignite in a testing environment that turns on these assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13065) Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read property 'length' of null
[ https://issues.apache.org/jira/browse/IGNITE-13065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125004#comment-17125004 ] Maxim Muzafarov commented on IGNITE-13065: -- [~vveider] Hello, can you help with this? Maybe it's also necessary to upload 2.8.1 images also. > Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read > property 'length' of null > - > > Key: IGNITE-13065 > URL: https://issues.apache.org/jira/browse/IGNITE-13065 > Project: Ignite > Issue Type: Bug >Reporter: david >Priority: Critical > > Hi, > I am using docker to host the web console and have pulled the latest image > from docker. I have upgraded my ignite server to 2.8.0 but co no longer > perform scans of my cache > > Has a new docker image for the web console been pushed to docker to support > ignite 2.8.0? > > thank you > David -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124988#comment-17124988
]
Ignite TC Bot commented on IGNITE-13094:
{panel:title=Branch: [pull/7887/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5360568&buildTypeId=IgniteTests24Java8_RunAll]
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Class locally deployed: class
> com.sonic.sample.springboot.controller.WebController
> 2020-05-28 07:00:48.890 WARN 8460 --- [p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback
> java.lang.ClassNotFoundException: ch.qos.logback
> at java.net.URLClassLoader.find
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124989#comment-17124989
]
Ilya Kasnacheev commented on IGNITE-13094:
--
[~ipavlukhin] I have updated my contribution, please re-check.
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Class locally deployed: class
> com.sonic.sample.springboot.controller.WebController
> 2020-05-28 07:00:48.890 WARN 8460 --- [p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback
> java.lang.ClassNotFoundException: ch.qos.logback
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_121]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_121]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> ~[n
[jira] [Updated] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Affects Version/s: 2.8.1 > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Affects Versions: 2.8.1 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Ignite Flags: (was: Docs Required,Release Notes Required) > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13113) CacheEvent#subjectId for cache events with types EventType#EVTS_CACHE
Denis Garus created IGNITE-13113: Summary: CacheEvent#subjectId for cache events with types EventType#EVTS_CACHE Key: IGNITE-13113 URL: https://issues.apache.org/jira/browse/IGNITE-13113 Project: Ignite Issue Type: Bug Components: cache, security Affects Versions: 2.8.1 Reporter: Denis Garus Assignee: Denis Garus For cache events with types: EVT_CACHE_ENTRY_CREATED, EVT_CACHE_ENTRY_DESTROYED, EVT_CACHE_OBJECT_PUT, EVT_CACHE_OBJECT_READ, EVT_CACHE_OBJECT_REMOVED, EVT_CACHE_OBJECT_LOCKED, EVT_CACHE_OBJECT_UNLOCKED, EVT_CACHE_OBJECT_EXPIRED field CacheEvent#subjectId should be subject id associated with SecuritySubject that trigged the cache event. Currently, CacheEvent#subjectId for these event types is null or equals subject id associated with the node that sends a change request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Labels: iep-41 (was: ) > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-13112: Assignee: Denis Garus > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
Denis Garus created IGNITE-13112: Summary: CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED Key: IGNITE-13112 URL: https://issues.apache.org/jira/browse/IGNITE-13112 Project: Ignite Issue Type: Bug Components: cache, security Reporter: Denis Garus CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have fieldCacheEvent#subjectId always null. CacheEvent#subjectId should be subject id associated with SecuritySubject that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[ https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124952#comment-17124952 ] Ivan Daschinskiy commented on IGNITE-13078: --- Ok, I'd think a little bit how to rewrite this paragraph to be more understandable. May be you suggestion is the best variant. > С++: Add CMake build support > > > Key: IGNITE-13078 > URL: https://issues.apache.org/jira/browse/IGNITE-13078 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, it is hard to build Ignite.C++. Different build process for > windows and linux, lack of building support on Mac OS X (quite popular OS > among developers), absolutely not IDE support, except windows and only Visual > Studio is supported. > I’d suggest to migrate to CMake build system. It is very popular among open > source projects, and in Apache Software Foundation too. Notable user: Apache > Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf > and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache > Thrift. Popular column-oriented database ClickHouse also uses CMake. > CMake is widely supported in many IDE’s on various platforms, notably Visual > Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[ https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124942#comment-17124942 ] Ilya Kasnacheev commented on IGNITE-13078: -- It's even more possible to make a mistake since I'm viewing it with `less` before trying to build sources, so I don't see any benefit of markdown. > С++: Add CMake build support > > > Key: IGNITE-13078 > URL: https://issues.apache.org/jira/browse/IGNITE-13078 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, it is hard to build Ignite.C++. Different build process for > windows and linux, lack of building support on Mac OS X (quite popular OS > among developers), absolutely not IDE support, except windows and only Visual > Studio is supported. > I’d suggest to migrate to CMake build system. It is very popular among open > source projects, and in Apache Software Foundation too. Notable user: Apache > Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf > and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache > Thrift. Popular column-oriented database ClickHouse also uses CMake. > CMake is widely supported in many IDE’s on various platforms, notably Visual > Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13111) Simplify backward checking of node connection.
[
https://issues.apache.org/jira/browse/IGNITE-13111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13111:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Simplify backward checking of node connection.
> --
>
> Key: IGNITE-13111
> URL: https://issues.apache.org/jira/browse/IGNITE-13111
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, FailureDetectionResearch_fixed.txt,
> WostCaseStepByStep.txt
>
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestion:*
> 1) We can simplify backward connection checking as we implement IGNITE-13012.
> Once we get robust, predictable connection ping, we don't need to check
> previous node because we can see whether it sent ping to current node within
> failure detection timeout. If not, previous node can be considered lost.
> Instead of:
> {code:java}
> // Node cannot connect to it's next (for local node it's previous).
> // Need to check connectivity to it.
> long rcvdTime = lastRingMsgReceivedTime;
> long now = U.currentTimeMillis();
> // We got message from previous in less than double
> connection check interval.
> boolean ok = rcvdTime + effectiveExchangeTimeout() >=
> now;
> TcpDiscoveryNode previous = null;
> if (ok) {
> // Check case when previous node suddenly died.
> This will speed up
> // node failing.
> Checking connection to previous node
> }
> {code}
> 2) Then, seems we can remove:
> {code:java}
> ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13111) Simplify backward checking of node connection.
[
https://issues.apache.org/jira/browse/IGNITE-13111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13111:
--
Labels: iep-45 (was: )
> Simplify backward checking of node connection.
> --
>
> Key: IGNITE-13111
> URL: https://issues.apache.org/jira/browse/IGNITE-13111
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, FailureDetectionResearch_fixed.txt,
> WostCaseStepByStep.txt
>
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestion:*
> 1) We can simplify backward connection checking as we implement IGNITE-13012.
> Once we get robust, predictable connection ping, we don't need to check
> previous node because we can see whether it sent ping to current node within
> failure detection timeout. If not, previous node can be considered lost.
> Instead of:
> {code:java}
> // Node cannot connect to it's next (for local node it's previous).
> // Need to check connectivity to it.
> long rcvdTime = lastRingMsgReceivedTime;
> long now = U.currentTimeMillis();
> // We got message from previous in less than double
> connection check interval.
> boolean ok = rcvdTime + effectiveExchangeTimeout() >=
> now;
> TcpDiscoveryNode previous = null;
> if (ok) {
> // Check case when previous node suddenly died.
> This will speed up
> // node failing.
> Checking connection to previous node
> }
> {code}
> 2) Then, seems we can remove:
> {code:java}
> ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13111) Simplify backward checking of node connection.
[
https://issues.apache.org/jira/browse/IGNITE-13111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13111:
--
Attachment: FailureDetectionResearch_fixed.txt
> Simplify backward checking of node connection.
> --
>
> Key: IGNITE-13111
> URL: https://issues.apache.org/jira/browse/IGNITE-13111
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, FailureDetectionResearch_fixed.txt,
> WostCaseStepByStep.txt
>
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestion:*
> 1) We can simplify backward connection checking as we implement IGNITE-13012.
> Once we get robust, predictable connection ping, we don't need to check
> previous node because we can see whether it sent ping to current node within
> failure detection timeout. If not, previous node can be considered lost.
> Instead of:
> {code:java}
> // Node cannot connect to it's next (for local node it's previous).
> // Need to check connectivity to it.
> long rcvdTime = lastRingMsgReceivedTime;
> long now = U.currentTimeMillis();
> // We got message from previous in less than double
> connection check interval.
> boolean ok = rcvdTime + effectiveExchangeTimeout() >=
> now;
> TcpDiscoveryNode previous = null;
> if (ok) {
> // Check case when previous node suddenly died.
> This will speed up
> // node failing.
> Checking connection to previous node
> }
> {code}
> 2) Then, seems we can remove:
> {code:java}
> ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13111) Simplify backward checking of node connection.
[
https://issues.apache.org/jira/browse/IGNITE-13111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13111:
--
Attachment: FailureDetectionResearch.txt
> Simplify backward checking of node connection.
> --
>
> Key: IGNITE-13111
> URL: https://issues.apache.org/jira/browse/IGNITE-13111
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, WostCaseStepByStep.txt
>
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestion:*
> 1) We can simplify backward connection checking as we implement IGNITE-13012.
> Once we get robust, predictable connection ping, we don't need to check
> previous node because we can see whether it sent ping to current node within
> failure detection timeout. If not, previous node can be considered lost.
> Instead of:
> {code:java}
> // Node cannot connect to it's next (for local node it's previous).
> // Need to check connectivity to it.
> long rcvdTime = lastRingMsgReceivedTime;
> long now = U.currentTimeMillis();
> // We got message from previous in less than double
> connection check interval.
> boolean ok = rcvdTime + effectiveExchangeTimeout() >=
> now;
> TcpDiscoveryNode previous = null;
> if (ok) {
> // Check case when previous node suddenly died.
> This will speed up
> // node failing.
> Checking connection to previous node
> }
> {code}
> 2) Then, seems we can remove:
> {code:java}
> ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Attachment: (was: NodeFailureResearch.patch)
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, FailureDetectionResearch_fixed.txt,
> WostCaseStepByStep.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
> timeout of failure detection.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Attachment: (was: WostCaseStepByStep.txt)
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, FailureDetectionResearch_fixed.txt,
> WostCaseStepByStep.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
> timeout of failure detection.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13111) Simplify backward checking of node connection.
[
https://issues.apache.org/jira/browse/IGNITE-13111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13111:
--
Attachment: FailureDetectionResearch.patch
> Simplify backward checking of node connection.
> --
>
> Key: IGNITE-13111
> URL: https://issues.apache.org/jira/browse/IGNITE-13111
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, WostCaseStepByStep.txt
>
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestion:*
> 1) We can simplify backward connection checking as we implement IGNITE-13012.
> Once we get robust, predictable connection ping, we don't need to check
> previous node because we can see whether it sent ping to current node within
> failure detection timeout. If not, previous node can be considered lost.
> Instead of:
> {code:java}
> // Node cannot connect to it's next (for local node it's previous).
> // Need to check connectivity to it.
> long rcvdTime = lastRingMsgReceivedTime;
> long now = U.currentTimeMillis();
> // We got message from previous in less than double
> connection check interval.
> boolean ok = rcvdTime + effectiveExchangeTimeout() >=
> now;
> TcpDiscoveryNode previous = null;
> if (ok) {
> // Check case when previous node suddenly died.
> This will speed up
> // node failing.
> Checking connection to previous node
> }
> {code}
> 2) Then, seems we can remove:
> {code:java}
> ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13111) Simplify backward checking of node connection.
[
https://issues.apache.org/jira/browse/IGNITE-13111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13111:
--
Attachment: WostCaseStepByStep.txt
> Simplify backward checking of node connection.
> --
>
> Key: IGNITE-13111
> URL: https://issues.apache.org/jira/browse/IGNITE-13111
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, WostCaseStepByStep.txt
>
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestion:*
> 1) We can simplify backward connection checking as we implement IGNITE-13012.
> Once we get robust, predictable connection ping, we don't need to check
> previous node because we can see whether it sent ping to current node within
> failure detection timeout. If not, previous node can be considered lost.
> Instead of:
> {code:java}
> // Node cannot connect to it's next (for local node it's previous).
> // Need to check connectivity to it.
> long rcvdTime = lastRingMsgReceivedTime;
> long now = U.currentTimeMillis();
> // We got message from previous in less than double
> connection check interval.
> boolean ok = rcvdTime + effectiveExchangeTimeout() >=
> now;
> TcpDiscoveryNode previous = null;
> if (ok) {
> // Check case when previous node suddenly died.
> This will speed up
> // node failing.
> Checking connection to previous node
> }
> {code}
> 2) Then, seems we can remove:
> {code:java}
> ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Attachment: FailureDetectionResearch.patch
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, FailureDetectionResearch_fixed.txt,
> NodeFailureResearch.patch, WostCaseStepByStep.txt, WostCaseStepByStep.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
> timeout of failure detection.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Attachment: WostCaseStepByStep.txt
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: FailureDetectionResearch.patch,
> FailureDetectionResearch.txt, FailureDetectionResearch_fixed.txt,
> NodeFailureResearch.patch, WostCaseStepByStep.txt, WostCaseStepByStep.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolong node failure detection upto:
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms.
> See:
> * ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
> which emulates long answears on a failed node and measures failure detection
> delays.
> * '_FailureDetectionResearch.txt_' - results of the test.
> * '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
> * '_WostCaseStepByStep.txt_' - description how the worst case happens.
> *Suggestions:*
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it rely on failureDetectionTimeout.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
> timeout of failure detection.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13111) Simplify backward checking of node connection.
Vladimir Steshin created IGNITE-13111:
-
Summary: Simplify backward checking of node connection.
Key: IGNITE-13111
URL: https://issues.apache.org/jira/browse/IGNITE-13111
Project: Ignite
Issue Type: Improvement
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
We should fix several drawbacks in the backward checking of failed node. They
prolong node failure detection upto:
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms.
See:
* ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch'
which emulates long answears on a failed node and measures failure detection
delays.
* '_FailureDetectionResearch.txt_' - results of the test.
* '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
* '_WostCaseStepByStep.txt_' - description how the worst case happens.
*Suggestion:*
1) We can simplify backward connection checking as we implement IGNITE-13012.
Once we get robust, predictable connection ping, we don't need to check
previous node because we can see whether it sent ping to current node within
failure detection timeout. If not, previous node can be considered lost.
Instead of:
{code:java}
// Node cannot connect to it's next (for local node it's previous).
// Need to check connectivity to it.
long rcvdTime = lastRingMsgReceivedTime;
long now = U.currentTimeMillis();
// We got message from previous in less than double
connection check interval.
boolean ok = rcvdTime + effectiveExchangeTimeout() >=
now;
TcpDiscoveryNode previous = null;
if (ok) {
// Check case when previous node suddenly died.
This will speed up
// node failing.
Checking connection to previous node
}
{code}
2) Then, seems we can remove:
{code:java}
ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13105) Spring data 2.0 IgniteRepositoryQuery#transformQueryCursor contains cursor leak
[
https://issues.apache.org/jira/browse/IGNITE-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124899#comment-17124899
]
Ignite TC Bot commented on IGNITE-13105:
{panel:title=Branch: [pull/7888/head] Base: [master] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5360572]]
* IgniteCacheTestSuite6:
IgniteExchangeLatchManagerCoordinatorFailTest.testCoordinatorFail1 - Test has
low fail rate in base branch 2,0% and is not flaky
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5360302]]
* IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= PESSIMISTIC, Concurrency = REPEATABLE_READ, Started from = PRIMARY] - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5360825]]
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
near.IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest - History for
base branch is absent.
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5360823]]
* IgniteBasicTestSuite: GridVersionSelfTest.testVersions - Test has low fail
rate in base branch 2,5% and is not flaky
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5358513&buildTypeId=IgniteTests24Java8_RunAll]
> Spring data 2.0 IgniteRepositoryQuery#transformQueryCursor contains cursor
> leak
> ---
>
> Key: IGNITE-13105
> URL: https://issues.apache.org/jira/browse/IGNITE-13105
> Project: Ignite
> Issue Type: Improvement
> Components: springdata
>Affects Versions: 2.8.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This code produce cursor leak in RunningQueryManager:
> If result set contains one ore more rows.
> {code}
> case ONE_VALUE:
> Iterator iter = qryIter.iterator();
> if (iter.hasNext())
> return iter.next().get(0);
> return null;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13105) Spring data 2.0 IgniteRepositoryQuery#transformQueryCursor contains cursor leak
[
https://issues.apache.org/jira/browse/IGNITE-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124900#comment-17124900
]
Ilya Kasnacheev commented on IGNITE-13105:
--
Some tests fail routinely. Can you please rebase?
> Spring data 2.0 IgniteRepositoryQuery#transformQueryCursor contains cursor
> leak
> ---
>
> Key: IGNITE-13105
> URL: https://issues.apache.org/jira/browse/IGNITE-13105
> Project: Ignite
> Issue Type: Improvement
> Components: springdata
>Affects Versions: 2.8.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This code produce cursor leak in RunningQueryManager:
> If result set contains one ore more rows.
> {code}
> case ONE_VALUE:
> Iterator iter = qryIter.iterator();
> if (iter.hasNext())
> return iter.next().get(0);
> return null;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13056) SchemaManager refactoring
[ https://issues.apache.org/jira/browse/IGNITE-13056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-13056: - Labels: IEP-49 calcite (was: calcite) > SchemaManager refactoring > - > > Key: IGNITE-13056 > URL: https://issues.apache.org/jira/browse/IGNITE-13056 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-49, calcite > > Since Ignite wants to leverage from several SQL engines we need to make work > with index independent from the used SQL engine. > We also should consider moving all machinery related to an index to the core > module to make it available from any module that wants to use it. > Requirements so far: > * Ability to track indexes in several engines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[ https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124863#comment-17124863 ] Ivan Daschinskiy commented on IGNITE-13078: --- [~ilyak] May be it's worth to rewrite it in markdown format? In markdown, it's impossible to make mistake with double dot. And it is more readable even without rendering (IMO) > С++: Add CMake build support > > > Key: IGNITE-13078 > URL: https://issues.apache.org/jira/browse/IGNITE-13078 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, it is hard to build Ignite.C++. Different build process for > windows and linux, lack of building support on Mac OS X (quite popular OS > among developers), absolutely not IDE support, except windows and only Visual > Studio is supported. > I’d suggest to migrate to CMake build system. It is very popular among open > source projects, and in Apache Software Foundation too. Notable user: Apache > Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf > and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache > Thrift. Popular column-oriented database ClickHouse also uses CMake. > CMake is widely supported in many IDE’s on various platforms, notably Visual > Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[ https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124846#comment-17124846 ] Ilya Kasnacheev commented on IGNITE-13078: -- Now that's too complex. Ideally, copy-paste should Just Work. Maybe we put simpler approach to README, document more options to DEVNOTES. > С++: Add CMake build support > > > Key: IGNITE-13078 > URL: https://issues.apache.org/jira/browse/IGNITE-13078 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, it is hard to build Ignite.C++. Different build process for > windows and linux, lack of building support on Mac OS X (quite popular OS > among developers), absolutely not IDE support, except windows and only Visual > Studio is supported. > I’d suggest to migrate to CMake build system. It is very popular among open > source projects, and in Apache Software Foundation too. Notable user: Apache > Mesos, Apache Zookeeper (C client offers CMake as an alternative to autoconf > and only option on windows), Apache Kafka (librdkafka - C/C++ client), Apache > Thrift. Popular column-oriented database ClickHouse also uses CMake. > CMake is widely supported in many IDE’s on various platforms, notably Visual > Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13110) An option to validate field types against SQL schema on key-value insert
Sergey Kalashnikov created IGNITE-13110:
---
Summary: An option to validate field types against SQL schema on
key-value insert
Key: IGNITE-13110
URL: https://issues.apache.org/jira/browse/IGNITE-13110
Project: Ignite
Issue Type: Bug
Reporter: Sergey Kalashnikov
Assignee: Sergey Kalashnikov
Let's add a configurable option to prevent insertion of key-value pairs that
aren't compatible with SQL schema.
An option can be added on {{SqlConfiguration}} level or even per
{{QueryEntity}}.
The checks can be performed within the existing
{{GridQueryTypeDescriptor#validateKeyAndValue}} facility that seems to be well
suited for this task.
This addition will prevent the problems when values successfully added to the
cache later produce errors when queried with SQL.
See discussion :
http://apache-ignite-developers.2346864.n4.nabble.com/Prevent-insertion-of-cache-entry-if-the-binary-field-type-and-the-type-of-the-query-entity-do-not-ma-td47678.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13018) Get rid of duplicated checking of failed node.
[ https://issues.apache.org/jira/browse/IGNITE-13018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13018: -- Labels: (was: iep-45) > Get rid of duplicated checking of failed node. > -- > > Key: IGNITE-13018 > URL: https://issues.apache.org/jira/browse/IGNITE-13018 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > Failed node checking should be simplified to one step: ping node (send a > message) from previous one in the ring and wait for response within > IgniteConfiguration.failureDetectionTimeout. If node doesn't respond, we > should consider it failed. Extra steps of connection checking may seriously > delay failure detection, bring confusion and weird behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[ https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124785#comment-17124785 ] Alexandr Shapkin edited comment on IGNITE-13095 at 6/3/20, 9:55 AM: [~ptupitsyn] LGTM, please check the failed test - TestExecuteJavaTaskAsyncCancellation was (Author: ashapkin): [~ptupitsyn] LGTM > .NET: Thin Client Compute does not cancel task on server when cancelled on > client > - > > Key: IGNITE-13095 > URL: https://issues.apache.org/jira/browse/IGNITE-13095 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Original Estimate: 3h > Time Spent: 10m > Remaining Estimate: 2h 50m > > Client should call OP_RESOURCE_CLOSE to cancel the task on server side. > Test this by reading server logs, "Job was cancelled" should be there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124814#comment-17124814
]
Maxim Muzafarov commented on IGNITE-13108:
--
Merged to the master branch, thank you for the review!
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&mode=builds
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12845) GridNioServer can infinitely lose some events
[
https://issues.apache.org/jira/browse/IGNITE-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12845:
---
Description:
With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
{{GridNioServer}} can lose some events for a channel (depending on JDK version
and OS). It can lead to connected applications hang. Reproducer:
{code:java}
public void testConcurrentLoad() throws Exception {
startGrid(0);
try (IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
GridTestUtils.runMultiThreaded(
() -> {
for (int i = 0; i < 1000; i++)
cache.put(i, i);
}, 5, "run-async");
}
}
{code}
This reproducer hangs eventually on MacOS (tested with JDK 8, 11, 12, 13, 14),
but passes on Windows and Linux systems, or when system property
{{IGNITE_NO_SELECTOR_OPTS = true}} is set.
The root cause: optimized {{SelectedSelectionKeySet}} always returns {{false}}
for {{contains()}} method. The {{contains()}} method used by
{{sun.nio.ch.SelectorImpl.processReadyEvents()}} method:
{code:java}
if (selectedKeys.contains(ski)) {
if (ski.translateAndUpdateReadyOps(rOps)) {
return 1;
}
} else {
ski.translateAndSetReadyOps(rOps);
if ((ski.nioReadyOps() & ski.nioInterestOps()) != 0) {
selectedKeys.add(ski);
return 1;
}
}
{code}
So, for fair implementation, if a selection key is contained in the selected
keys set, then ready operations flags are updated, but for
{{SelectedSelectionKeySet}} ready operations flags will be always overridden
and new selector key will be added even if it's already contained in the set.
Some {{SelectorImpl}} implementations can pass several events for one selector
key to {{processReadyEvents}} method (for example, MacOs implementation
{{KQueueSelectorImpl}} works in such a way). In this case, duplicated selector
keys will be added to {{selectedKeys}} and all events except last will be lost.
Two bad things happen in {{GridNioServer}} due to described above reasons:
# Some event flags are lost and the worker doesn't process corresponding
action (for attached reproducer "channel is ready for reading" event is lost
and the workers never read the channel after some point in time).
# Duplicated selector keys with the same event flags (for attached reproducer
it's "channel is ready for writing" event, this duplication leads to wrong
processing of {{GridSelectorNioSessionImpl#procWrite}} flag, which will be
{{false}} in some cases, but at the same time selector key's {{interestedOps}}
will contain {{OP_WRITE}} operation and this operation never be excluded)
Possible solutions:
* Fair implementation of {{SelectedSelectionKeySet.contains}} method (this
will solve all problems but can be resource consuming)
* Always set {{GridSelectorNioSessionImpl#procWrite}} to {{true}} when adding
{{OP_WRITE}} to {{interestedOps}} (for example in
{{AbstractNioClientWorker.registerWrite()}} method). In this case, some
"channel is ready for reading" events (but not data) still can be lost, but not
infinitely, and eventually data will be read. If events will be reordered
(first "channel is ready for writing", after it "channel is ready for reading")
then write to the channel will be only processed after all data will be read.
* Exclude {{OP_WRITE}} from {{interestedOps}} even if
{{GridSelectorNioSessionImpl#procWrite}} is {{false}} when there are no write
requests in the queue (see {{GridNioServer.stopPollingForWrite()}} method).
This solution has the same shortcomings as the previous one.
* Hybrid approach. Use some probabilistic implementation for {{contains}}
method (bloom filter or just check the last element) and use one of two
previous solutions as a workaround, for cases when we incorrectly return
{{false}} for {{contains}}.
was:
With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
{{GridNioServer}} can lose some events for a channel (depending on JDK version
and OS). It can lead to connected applications hang. Reproducer:
{code:java}
public void testConcurrentLoad() throws Exception {
startGrid(0);
try (IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
GridTestUtils.runMultiThreaded(
() -> {
for (int i = 0; i < 1000; i++)
cache.put(i, i);
}, 5, "run-async");
}
}
{code}
This reproducer hangs eventually on MacOS (tested with JDK 8, 11, 12, 13, 14),
hangs on some Linux environments (for example passed more t
[jira] [Commented] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124793#comment-17124793
]
Aleksey Plekhanov commented on IGNITE-13108:
[~mmuzaf], looks good to me.
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&mode=builds
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13109) Skip metastorage entries that can not be unmarshalled
Amelchev Nikita created IGNITE-13109:
Summary: Skip metastorage entries that can not be unmarshalled
Key: IGNITE-13109
URL: https://issues.apache.org/jira/browse/IGNITE-13109
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
Need to skip metastorage entries that can not be unmarshalled (created by the
old cluster). It leads that nodes can't join to the first started node:
{noformat}
[SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while starting
(will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
at org.apache.ignite.Ignition.start(Ignition.java:328)
at
org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI:
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
marsh=JdkMarshaller
[clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724],
reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5,
forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
skipAddrsRandomization=false]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
... 8 more
Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to unmarshal
key=ignite.testOldClusterTag
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2111)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:299)
... 10 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13083) Double adding "onSegmentArchived" observer to SegmentArchivedStorage
[ https://issues.apache.org/jira/browse/IGNITE-13083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-13083. -- Resolution: Fixed Thank you for this fix, I have merged it to master. > Double adding "onSegmentArchived" observer to SegmentArchivedStorage > > > Key: IGNITE-13083 > URL: https://issues.apache.org/jira/browse/IGNITE-13083 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > SegmentCompressStorage is build with static method > SegmentCompressStorage#buildCompressStorage, where private constructor is > called, and the same observer storage::onSegmentArchived is added to same > SegmentArchivedStorage in constructor and in the static method. This can > cause double call of SegmentCompressStorage#onSegmentArchived. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13083) Double adding "onSegmentArchived" observer to SegmentArchivedStorage
[ https://issues.apache.org/jira/browse/IGNITE-13083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-13083: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Double adding "onSegmentArchived" observer to SegmentArchivedStorage > > > Key: IGNITE-13083 > URL: https://issues.apache.org/jira/browse/IGNITE-13083 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > SegmentCompressStorage is build with static method > SegmentCompressStorage#buildCompressStorage, where private constructor is > called, and the same observer storage::onSegmentArchived is added to same > SegmentArchivedStorage in constructor and in the static method. This can > cause double call of SegmentCompressStorage#onSegmentArchived. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[ https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124785#comment-17124785 ] Alexandr Shapkin commented on IGNITE-13095: --- [~ptupitsyn] LGTM > .NET: Thin Client Compute does not cancel task on server when cancelled on > client > - > > Key: IGNITE-13095 > URL: https://issues.apache.org/jira/browse/IGNITE-13095 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Original Estimate: 3h > Time Spent: 10m > Remaining Estimate: 2h 50m > > Client should call OP_RESOURCE_CLOSE to cancel the task on server side. > Test this by reading server logs, "Job was cancelled" should be there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124778#comment-17124778 ] Anton Vinogradov commented on IGNITE-13051: --- Merget to master. Thanks for your contribution. > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13108:
-
Issue Type: Task (was: Bug)
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13108:
-
Attachment: (was: image-2020-06-03-11-41-58-804.png)
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13108:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
Maxim Muzafarov created IGNITE-13108:
Summary: Decrease number of clients for IgniteCache150ClientsTest
Key: IGNITE-13108
URL: https://issues.apache.org/jira/browse/IGNITE-13108
Project: Ignite
Issue Type: Bug
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
The number of clients for the {{IgniteCache150ClientsTest}} due to not
sufficient TeamCity resources available on agents.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[
https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124764#comment-17124764
]
Ignite TC Bot commented on IGNITE-13051:
{panel:title=Branch: [pull/7852/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5346380&buildTypeId=IgniteTests24Java8_RunAll]
> Optimized affinity switch on baseline node left is broken for client topology
> and MVCC
> --
>
> Key: IGNITE-13051
> URL: https://issues.apache.org/jira/browse/IGNITE-13051
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Maksim Timonin
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> If a node contains only client cache topology with MVCC enabled, PME will
> hang after changes introduced in IGNITE-12617.
> Reproduced by
> CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0
> false false -1] and enabled MVCC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13108:
-
Attachment: (was: image-2020-06-03-11-41-59-857.png)
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124774#comment-17124774
]
Maxim Muzafarov commented on IGNITE-13108:
--
Cache6 Suite --
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6&branch_IgniteTests24Java8=pull%2F7892%2Fhead&tab=buildTypeStatusDiv
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&mode=builds
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13104) Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
[
https://issues.apache.org/jira/browse/IGNITE-13104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124769#comment-17124769
]
Ilya Kasnacheev commented on IGNITE-13104:
--
I have added some code coments. Do you have MTCGA visa?
> Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
> --
>
> Key: IGNITE-13104
> URL: https://issues.apache.org/jira/browse/IGNITE-13104
> Project: Ignite
> Issue Type: Improvement
> Components: springdata
>Affects Versions: 2.8.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> /** {@inheritDoc} */
> @Override public void deleteAllById(Iterable ids) {
> if (ids instanceof Set)
> cache.removeAll((Set)ids);
> if (ids instanceof Collection)
> cache.removeAll(new HashSet<>((Collection)ids));
> TreeSet keys = new TreeSet<>();
> for (ID id : ids)
> keys.add(id);
> cache.removeAll(keys);
> }
> {code}
> As you can see cache.removeAll may be executed THREE times in some situations.
> Also this method can throw ClassCast exception if ids collection contains
> objects that are not implement Comparable interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest
[
https://issues.apache.org/jira/browse/IGNITE-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13108:
-
Description:
The number of clients for the {{IgniteCache150ClientsTest}} due to not
sufficient TeamCity resources available on agents.
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&mode=builds
was:The number of clients for the {{IgniteCache150ClientsTest}} due to not
sufficient TeamCity resources available on agents.
> Decrease number of clients for IgniteCache150ClientsTest
>
>
> Key: IGNITE-13108
> URL: https://issues.apache.org/jira/browse/IGNITE-13108
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The number of clients for the {{IgniteCache150ClientsTest}} due to not
> sufficient TeamCity resources available on agents.
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&mode=builds
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13060) Tracing: initial implementation
[
https://issues.apache.org/jira/browse/IGNITE-13060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124719#comment-17124719
]
Ignite TC Bot commented on IGNITE-13060:
{panel:title=Branch: [pull/7884/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5357841&buildTypeId=IgniteTests24Java8_RunAll]
> Tracing: initial implementation
> ---
>
> Key: IGNITE-13060
> URL: https://issues.apache.org/jira/browse/IGNITE-13060
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Initial tracing implementation. See
> [IEP-48|https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing]
> for details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
