[jira] [Commented] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256347#comment-17256347
 ] 

Pavel Tupitsyn commented on IGNITE-13883:
-

Merged to master: 971f31852a9fbdf14f0fd987d87d344b97298000

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-13935) Update Ignite docker image description

2020-12-29 Thread Denis A. Magda (Jira)
Denis A. Magda created IGNITE-13935:
---

 Summary: Update Ignite docker image description
 Key: IGNITE-13935
 URL: https://issues.apache.org/jira/browse/IGNITE-13935
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis A. Magda


Apache Ignite is redefined as "a distributed database for in-memory speed and 
high-performance computing".

Update the [docker image 
description|https://hub.docker.com/r/apacheignite/ignite]:
 # The title needs to say "Apache Ignite - Distributed Database"
 # The description of the "What is Apache Ignite?" section needs to be 
identical to a similar section of GitHub's README.md (definition + quick links 
to docs): https://github.com/apache/ignite



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (IGNITE-13779) Ignite as Distributed Database: Required Website Changes

2020-12-29 Thread Denis A. Magda (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis A. Magda closed IGNITE-13779.
---

> Ignite as Distributed Database: Required Website Changes
> 
>
> Key: IGNITE-13779
> URL: https://issues.apache.org/jira/browse/IGNITE-13779
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Denis A. Magda
>Assignee: Mauricio Stekl
>Priority: Critical
> Attachments: Screen Shot 2020-12-24 at 16.57.21.png, 
> banner_text_issue.PNG, description_alignment_issue.PNG, features_issue.PNG
>
>
> The community 
> [voted|http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Define-Apache-Ignite-as-a-Distributed-Database-td50269.html]
>  to define Ignite as a distributed database.
> This is an umbrella ticket with all required website changes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-13779) Ignite as Distributed Database: Required Website Changes

2020-12-29 Thread Denis A. Magda (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis A. Magda resolved IGNITE-13779.
-
Resolution: Fixed

> Ignite as Distributed Database: Required Website Changes
> 
>
> Key: IGNITE-13779
> URL: https://issues.apache.org/jira/browse/IGNITE-13779
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Denis A. Magda
>Assignee: Mauricio Stekl
>Priority: Critical
> Attachments: Screen Shot 2020-12-24 at 16.57.21.png, 
> banner_text_issue.PNG, description_alignment_issue.PNG, features_issue.PNG
>
>
> The community 
> [voted|http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Define-Apache-Ignite-as-a-Distributed-Database-td50269.html]
>  to define Ignite as a distributed database.
> This is an umbrella ticket with all required website changes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Ignite TC Bot (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256209#comment-17256209
 ] 

Ignite TC Bot commented on IGNITE-13883:


{panel:title=Branch: [pull/8627/head] Base: [master] : Possible Blockers 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5812131]]

{color:#d04437}Cache 5{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5812134]]
* IgniteCacheTestSuite5: 
CacheSerializableTransactionsTest.testTxConflictReadRemove2 - Test has low fail 
rate in base branch 0,0% and is not flaky

{panel}
{panel:title=Branch: [pull/8627/head] Base: [master] : No new tests 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5812174buildTypeId=IgniteTests24Java8_RunAll]

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13348) Creating IgniteAtomicLong from the client node may hang.

2020-12-29 Thread Vyacheslav Koptilin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-13348:
-
Fix Version/s: (was: 2.10)
   2.11

> Creating IgniteAtomicLong from the client node may hang.
> 
>
> Key: IGNITE-13348
> URL: https://issues.apache.org/jira/browse/IGNITE-13348
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Attachments: DataStructuresInitializationTest.java
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It looks like, the data structure processor does not properly initialize when 
> a client node connects to a cluster that changes its own state (state 
> transition from the inactive state to active).
> reproducer attached.
> *UPDATE*
> It seems to me, the root cause of the issue is that {{joinFut}} is always 
> completed with {{false}}.
> {code:java|title=GridClusterStateProcessor.java}
> /** {@inheritDoc} */
> @Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage 
> msg) {
> DiscoveryDataClusterState discoClusterState = globalState;
> if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
> ...
> TransitionOnJoinWaitFuture joinFut = this.joinFut;
> if (joinFut != null)
> joinFut.onDone(false);
> ...
> }
> else
> U.warn(log, "Received state finish message with unexpected ID: " 
> + msg);
> }
> {code}
> On the other hand, this value is used to determine the state of the cluster 
> when a new node joins the cluster
> {code:java|title=IgniteKernal.java}
> public void start(
> DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
> IgniteInternalFuture transitionWaitFut = 
> joinData.transitionWaitFuture();
> ...
> boolean active;
> if (transitionWaitFut != null) {
> if (log.isInfoEnabled()) {
> log.info("Join cluster while cluster state transition is 
> in progress, waiting when transition finish.");
> }
> active = transitionWaitFut.get();
> }
> else
> active = joinData.active();
> startTimer.finishGlobalStage("Await transition");
> ...
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13906) Possible deadlock between methods from GridEncryptionManager

2020-12-29 Thread Vyacheslav Koptilin (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256198#comment-17256198
 ] 

Vyacheslav Koptilin commented on IGNITE-13906:
--

Hi [~maliev],

The proposed patch looks good to me. Merged to the master branch. Thanks for 
your efforts!

> Possible deadlock between methods from GridEncryptionManager
> 
>
> Key: IGNITE-13906
> URL: https://issues.apache.org/jira/browse/IGNITE-13906
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.11
>
>
> It seems that {{GridEncryptionManager}} uses {{metaStorageMux}} and 
> {{checkpointReadLock}} in an inconsistent way.
> Sometimes, the implementation acquires the mutex fist and then 
> {{checkpointReadLock}}, sometimes vice versa, which may lead to a deadlock.
> Let's consider the following scenario:
> Thread-1: {{removeGroupKey}} acquired {{metaStorageMux}} and trying to get 
> {{checkpointReadLock}} (cannot proceed further because of checkpointer)
> Therad-2: {{doChangeMasterKey}} acquired {{checkpointReadLock}} and trying to 
> get {{metaStorageMux}} (cannot proceed further due to thread-1)
> Checkpointer-thread: trying to acquire the write lock (cannot get the lock 
> due to thread-2)
>  
> Possible solutuion: acquire {{metaStorageMux}} before {{checkpointReadLock}} 
> in {{doChangeMasterKey}} method
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13906) Possible deadlock between methods from GridEncryptionManager

2020-12-29 Thread Vyacheslav Koptilin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-13906:
-
Fix Version/s: (was: 2.10)
   2.11

> Possible deadlock between methods from GridEncryptionManager
> 
>
> Key: IGNITE-13906
> URL: https://issues.apache.org/jira/browse/IGNITE-13906
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.11
>
>
> It seems that {{GridEncryptionManager}} uses {{metaStorageMux}} and 
> {{checkpointReadLock}} in an inconsistent way.
> Sometimes, the implementation acquires the mutex fist and then 
> {{checkpointReadLock}}, sometimes vice versa, which may lead to a deadlock.
> Let's consider the following scenario:
> Thread-1: {{removeGroupKey}} acquired {{metaStorageMux}} and trying to get 
> {{checkpointReadLock}} (cannot proceed further because of checkpointer)
> Therad-2: {{doChangeMasterKey}} acquired {{checkpointReadLock}} and trying to 
> get {{metaStorageMux}} (cannot proceed further due to thread-1)
> Checkpointer-thread: trying to acquire the write lock (cannot get the lock 
> due to thread-2)
>  
> Possible solutuion: acquire {{metaStorageMux}} before {{checkpointReadLock}} 
> in {{doChangeMasterKey}} method
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13928) Index defragmentation: only one index defragmented

2020-12-29 Thread Ignite TC Bot (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256185#comment-17256185
 ] 

Ignite TC Bot commented on IGNITE-13928:


{panel:title=Branch: [pull/8622/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8622/head] Base: [master] : New Tests 
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 4{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=5811938]]
* {color:#013220}IgnitePdsTestSuite4: 
DefragmentationMXBeanTest.testDefragmentationStatus - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: 
DefragmentationMXBeanTest.testDefragmentationCancel - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: 
DefragmentationMXBeanTest.testDefragmentationSchedule - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: 
DefragmentationMXBeanTest.testDefragmentationCancelInProgress - PASSED{color}

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5811312buildTypeId=IgniteTests24Java8_RunAll]

> Index defragmentation: only one index defragmented
> --
>
> Key: IGNITE-13928
> URL: https://issues.apache.org/jira/browse/IGNITE-13928
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In IndexingDefragmentation.java:
> {code:java}
> // code placeholder
> H2TreeIndex oldH2Idx = (H2TreeIndex)indexes.get(2);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13109) Skip distributed metastorage entries that can not be unmarshalled

2020-12-29 Thread Amelchev Nikita (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amelchev Nikita updated IGNITE-13109:
-
Fix Version/s: (was: 2.10)

> Skip distributed 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
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Need to skip distributed metastorage entries that can not be unmarshalled 
> (These entries can be created by the product that built on Apache Ignite and 
> incorporate additional features). 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.testOldKey
> 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] [Commented] (IGNITE-13109) Skip distributed metastorage entries that can not be unmarshalled

2020-12-29 Thread Amelchev Nikita (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256176#comment-17256176
 ] 

Amelchev Nikita commented on IGNITE-13109:
--

[~mmuzaf], I think a new investigation need. Maintenance mode can help to 
resolve this issue. I have moved the issue to the next release.

> Skip distributed 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
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Need to skip distributed metastorage entries that can not be unmarshalled 
> (These entries can be created by the product that built on Apache Ignite and 
> incorporate additional features). 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.testOldKey
> 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] [Commented] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Ignite TC Bot (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256170#comment-17256170
 ] 

Ignite TC Bot commented on IGNITE-13883:


{panel:title=Branch: [pull/8627/head] Base: [master] : Possible Blockers 
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5811744]]

{color:#d04437}Queries 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5811772]]
* IgniteBinaryCacheQueryTestSuite: 
IndexingCachePartitionLossPolicySelfTest.checkLostPartition[TRANSACTIONAL 
READ_ONLY_ALL 2 false 5 false] - Test has low fail rate in base branch 0,0% and 
is not flaky

{color:#d04437}SPI{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5811721]]
* IgniteSpiTestSuite: 
TcpDiscoveryPendingMessageDeliveryTest.testPendingMessagesOverflow - Test has 
low fail rate in base branch 1,3% and is not flaky

{color:#d04437}Examples{color} [[tests 
5|https://ci.ignite.apache.org/viewLog.html?buildId=5811703]]
* IgniteExamplesSelfTestSuite: 
CacheExamplesMultiNodeSelfTest.testCacheAffinityExample - Test has low fail 
rate in base branch 0,0% and is not flaky
* IgniteExamplesSelfTestSuite: 
BasicExamplesMultiNodeSelfTest.testRunnableExample - Test has low fail rate in 
base branch 0,0% and is not flaky
* IgniteExamplesSelfTestSuite: 
BasicExamplesMultiNodeSelfTest.testClosureExample - Test has low fail rate in 
base branch 0,0% and is not flaky
* IgniteExamplesSelfTestSuite: 
CacheExamplesMultiNodeSelfTest.testCacheAtomicSequenceExample - Test has low 
fail rate in base branch 0,0% and is not flaky
* IgniteExamplesSelfTestSuite: 
BasicExamplesMultiNodeSelfTest.testTaskMapExample - 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=5811731]]
* IgniteBasicTestSuite: GridFailFastNodeFailureDetectionSelfTest.testFailFast - 
Test has low fail rate in base branch 0,7% and is not flaky

{color:#d04437}PDS (Indexing){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5811760]]
* IgnitePdsWithIndexingCoreTestSuite: 
IgnitePdsTxHistoricalRebalancingTest.testRebalancingOnRestartAfterCheckpoint - 
Test has low fail rate in base branch 1,3% and is not flaky

{color:#d04437}Platform .NET (Integrations){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5811769]]
* dll: EntityFrameworkCacheTest.TestIncrementMultithreaded - Test has low fail 
rate in base branch 0,0% and is not flaky

{panel}
{panel:title=Branch: [pull/8627/head] Base: [master] : New Tests 
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Compatibility)*{color} [[tests 
4|https://ci.ignite.apache.org/viewLog.html?buildId=5811759]]
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JavaThinCompatibilityTest.testOldClientToCurrentServer[Version 2.11.0-SNAPSHOT] 
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JdbcThinCompatibilityTest.testCurrentClientToOldServer[Version 2.11.0-SNAPSHOT] 
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JavaThinCompatibilityTest.testCurrentClientToOldServer[Version 2.11.0-SNAPSHOT] 
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JdbcThinCompatibilityTest.testOldClientToCurrentServer[Version 2.11.0-SNAPSHOT] 
- PASSED{color}

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5811791buildTypeId=IgniteTests24Java8_RunAll]

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-13934) Some of the source files are missing license headers

2020-12-29 Thread Valentin Kulichenko (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Valentin Kulichenko resolved IGNITE-13934.
--
Resolution: Fixed

> Some of the source files are missing license headers
> 
>
> Key: IGNITE-13934
> URL: https://issues.apache.org/jira/browse/IGNITE-13934
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Fix For: 3.0.0-alpha1
>
>
> Need to add the license check to the build process, and fix all the missing 
> headers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13934) Some of the source files are missing license headers

2020-12-29 Thread Valentin Kulichenko (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256162#comment-17256162
 ] 

Valentin Kulichenko commented on IGNITE-13934:
--

Added license checker and fixed missing headers.

> Some of the source files are missing license headers
> 
>
> Key: IGNITE-13934
> URL: https://issues.apache.org/jira/browse/IGNITE-13934
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Fix For: 3.0.0-alpha1
>
>
> Need to add the license check to the build process, and fix all the missing 
> headers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13934) Some of the source files are missing license headers

2020-12-29 Thread Valentin Kulichenko (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Valentin Kulichenko updated IGNITE-13934:
-
Issue Type: Bug  (was: Improvement)

> Some of the source files are missing license headers
> 
>
> Key: IGNITE-13934
> URL: https://issues.apache.org/jira/browse/IGNITE-13934
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Fix For: 3.0.0-alpha1
>
>
> Need to add the license check to the build process, and fix all the missing 
> headers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-13934) Some of the source files are missing license headers

2020-12-29 Thread Valentin Kulichenko (Jira)
Valentin Kulichenko created IGNITE-13934:


 Summary: Some of the source files are missing license headers
 Key: IGNITE-13934
 URL: https://issues.apache.org/jira/browse/IGNITE-13934
 Project: Ignite
  Issue Type: Improvement
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 3.0.0-alpha1


Need to add the license check to the build process, and fix all the missing 
headers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13926) Misleading Javadoc of checkpoint events.

2020-12-29 Thread Vyacheslav Koptilin (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256153#comment-17256153
 ] 

Vyacheslav Koptilin commented on IGNITE-13926:
--

Hi [~alapin], [~maliev],

Could you please take a look?

> Misleading Javadoc of checkpoint events.
> 
>
> Key: IGNITE-13926
> URL: https://issues.apache.org/jira/browse/IGNITE-13926
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It does not obvious that checkpoint events only relate to compute/job 
> checkpointing (an ability to save and restore intermediate state).
> Also:
>  - Documentation for method {{Ignite.cache(name)}} says nothing about the 
> fact that it returns {{null}} if the cache doesn't exist.
>  - {{Ignite.destroyCache()}} does not describe the behavior in case the cache 
> name is null or the given cache does not exist.
>  - {{IgniteSet.removed()}} and {{IgniteSet.close()}} are confusing. what is 
> the difference?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13926) Misleading Javadoc of checkpoint events.

2020-12-29 Thread Vyacheslav Koptilin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-13926:
-
Description: 
It does not obvious that checkpoint events only relate to compute/job 
checkpointing (an ability to save and restore intermediate state).

Also:
 - Documentation for method {{Ignite.cache(name)}} says nothing about the fact 
that it returns {{null}} if the cache doesn't exist.
 - {{Ignite.destroyCache()}} does not describe the behavior in case the cache 
name is null or the given cache does not exist.
 - {{IgniteSet.removed()}} and {{IgniteSet.close()}} are confusing. what is the 
difference?

  was:
It does not obvious that checkpoint events only relate to compute/job 
checkpointing (an ability to save and restore intermediate state).

Also:
 - Documentation for method {{Ignite.cache(name)}} says nothing about the fact 
that it returns {{null}} if the cache doesn't exist.
 - {{Ignite.destroCache()}} does not describe the behavior in case the cache 
name is null or the given cache does not exist.
 - {{IgniteSet.removed()}} and {{IgniteSet.close()}} are confusing. what is the 
difference?


> Misleading Javadoc of checkpoint events.
> 
>
> Key: IGNITE-13926
> URL: https://issues.apache.org/jira/browse/IGNITE-13926
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It does not obvious that checkpoint events only relate to compute/job 
> checkpointing (an ability to save and restore intermediate state).
> Also:
>  - Documentation for method {{Ignite.cache(name)}} says nothing about the 
> fact that it returns {{null}} if the cache doesn't exist.
>  - {{Ignite.destroyCache()}} does not describe the behavior in case the cache 
> name is null or the given cache does not exist.
>  - {{IgniteSet.removed()}} and {{IgniteSet.close()}} are confusing. what is 
> the difference?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13926) Misleading Javadoc of checkpoint events.

2020-12-29 Thread Vyacheslav Koptilin (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-13926:
-
Fix Version/s: 2.11

> Misleading Javadoc of checkpoint events.
> 
>
> Key: IGNITE-13926
> URL: https://issues.apache.org/jira/browse/IGNITE-13926
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It does not obvious that checkpoint events only relate to compute/job 
> checkpointing (an ability to save and restore intermediate state).
> Also:
>  - Documentation for method {{Ignite.cache(name)}} says nothing about the 
> fact that it returns {{null}} if the cache doesn't exist.
>  - {{Ignite.destroCache()}} does not describe the behavior in case the cache 
> name is null or the given cache does not exist.
>  - {{IgniteSet.removed()}} and {{IgniteSet.close()}} are confusing. what is 
> the difference?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13926) Misleading Javadoc of checkpoint events.

2020-12-29 Thread Ignite TC Bot (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256152#comment-17256152
 ] 

Ignite TC Bot commented on IGNITE-13926:


{panel:title=Branch: [pull/8621/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8621/head] Base: [master] : No new tests 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5810846buildTypeId=IgniteTests24Java8_RunAll]

> Misleading Javadoc of checkpoint events.
> 
>
> Key: IGNITE-13926
> URL: https://issues.apache.org/jira/browse/IGNITE-13926
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It does not obvious that checkpoint events only relate to compute/job 
> checkpointing (an ability to save and restore intermediate state).
> Also:
>  - Documentation for method {{Ignite.cache(name)}} says nothing about the 
> fact that it returns {{null}} if the cache doesn't exist.
>  - {{Ignite.destroCache()}} does not describe the behavior in case the cache 
> name is null or the given cache does not exist.
>  - {{IgniteSet.removed()}} and {{IgniteSet.close()}} are confusing. what is 
> the difference?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Igor Sapego (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256147#comment-17256147
 ] 

Igor Sapego commented on IGNITE-13883:
--

[~ptupitsyn] overall, looks good. Please, see my single minor comment in PR.

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13933) Add an ability to customize documentation source repo

2020-12-29 Thread Valentin Kulichenko (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256140#comment-17256140
 ] 

Valentin Kulichenko commented on IGNITE-13933:
--

[~mstekl] Mauricio, could you please take a look? We're going to release the 
first version of Ignite 3.x in the next few days - it would be really nice to 
have the fix prior to that.

> Add an ability to customize documentation source repo
> -
>
> Key: IGNITE-13933
> URL: https://issues.apache.org/jira/browse/IGNITE-13933
> Project: Ignite
>  Issue Type: Improvement
>  Components: website
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 3.0.0-alpha1
>
>
> Documentation deployment script current has the original Ignite repo 
> hardcoded: 
> https://github.com/apache/ignite-website/blob/master/_docs/build.sh#L42
> Ignite 3.x is located in a different repo: https://github.com/apache/ignite-3
> Suggestion: add a parameter that would allow specifying the version (2.x or 
> 3.x). The script should then pick the corresponding repo URL and fetch the 
> sources from there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-13933) Add an ability to customize documentation source repo

2020-12-29 Thread Valentin Kulichenko (Jira)
Valentin Kulichenko created IGNITE-13933:


 Summary: Add an ability to customize documentation source repo
 Key: IGNITE-13933
 URL: https://issues.apache.org/jira/browse/IGNITE-13933
 Project: Ignite
  Issue Type: Improvement
  Components: website
Reporter: Valentin Kulichenko
 Fix For: 3.0.0-alpha1


Documentation deployment script current has the original Ignite repo hardcoded: 
https://github.com/apache/ignite-website/blob/master/_docs/build.sh#L42

Ignite 3.x is located in a different repo: https://github.com/apache/ignite-3

Suggestion: add a parameter that would allow specifying the version (2.x or 
3.x). The script should then pick the corresponding repo URL and fetch the 
sources from there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-13883:

Fix Version/s: 2.10
 Release Note: .NET: Improve primitives deserialization performance

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256100#comment-17256100
 ] 

Pavel Tupitsyn edited comment on IGNITE-13883 at 12/29/20, 7:15 PM:


Benchmark added: {{BinarySystemTypeReadBenchmark}}.

On Core i7-9700K, Ubuntu 20.04, .NET Core 3.1:

{code}
|| Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
| Before | 1.080 us | 0.0030 us | 0.0025 us | 0.0725 | - | - | 456 
B |
|  After | 849.4 ns |   4.44 ns | 4.16 ns   | 0.0725 | - | - | 456 
B |
{code}

(~20% improvement)


was (Author: ptupitsyn):
Benchmark added: {{BinarySystemTypeReadBenchmark}}.

On Core i7-9700K, Ubuntu 20.04, .NET Core 3.1:

*BEFORE*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.080 us | 0.0030 us | 0.0025 us | 0.0725 | - | - | 456 
B |
{code}

*AFTER*
{code}
| Method | Mean |   Error |  StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|--- |-:|:|:|---:|--:|--:|--:|
|   Read | 849.4 ns | 4.44 ns | 4.16 ns | 0.0725 | - | - | 456 B |
{code}

(~20% improvement)

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256100#comment-17256100
 ] 

Pavel Tupitsyn edited comment on IGNITE-13883 at 12/29/20, 7:02 PM:


Benchmark added: {{BinarySystemTypeReadBenchmark}}.

On Core i7-9700K, Ubuntu 20.04:

*BEFORE*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.080 us | 0.0030 us | 0.0025 us | 0.0725 | - | - | 456 
B |
{code}

*AFTER*
{code}
| Method | Mean |   Error |  StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|--- |-:|:|:|---:|--:|--:|--:|
|   Read | 849.4 ns | 4.44 ns | 4.16 ns | 0.0725 | - | - | 456 B |
{code}

(~20% improvement)


was (Author: ptupitsyn):
Benchmark added: {{BinarySystemTypeReadBenchmark}}.

On Core i7-9700K, Ubuntu 20.04:

*BEFORE*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.080 us | 0.0030 us | 0.0025 us | 0.0725 | - | - | 456 
B |
{code}

*AFTER*
{code}
| Method | Mean |   Error |  StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|--- |-:|:|:|---:|--:|--:|--:|
|   Read | 849.4 ns | 4.44 ns | 4.16 ns | 0.0725 | - | - | 456 B |
{code}

(~13% improvement)

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256100#comment-17256100
 ] 

Pavel Tupitsyn edited comment on IGNITE-13883 at 12/29/20, 7:02 PM:


Benchmark added: {{BinarySystemTypeReadBenchmark}}.

On Core i7-9700K, Ubuntu 20.04, .NET Core 3.1:

*BEFORE*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.080 us | 0.0030 us | 0.0025 us | 0.0725 | - | - | 456 
B |
{code}

*AFTER*
{code}
| Method | Mean |   Error |  StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|--- |-:|:|:|---:|--:|--:|--:|
|   Read | 849.4 ns | 4.44 ns | 4.16 ns | 0.0725 | - | - | 456 B |
{code}

(~20% improvement)


was (Author: ptupitsyn):
Benchmark added: {{BinarySystemTypeReadBenchmark}}.

On Core i7-9700K, Ubuntu 20.04:

*BEFORE*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.080 us | 0.0030 us | 0.0025 us | 0.0725 | - | - | 456 
B |
{code}

*AFTER*
{code}
| Method | Mean |   Error |  StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|--- |-:|:|:|---:|--:|--:|--:|
|   Read | 849.4 ns | 4.44 ns | 4.16 ns | 0.0725 | - | - | 456 B |
{code}

(~20% improvement)

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IGNITE-13927) Custom Maven repositories do not work

2020-12-29 Thread Valentin Kulichenko (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Valentin Kulichenko resolved IGNITE-13927.
--
Resolution: Fixed

Fixed in {{main}} and {{ignite-3.0.0-alpha1}}.

> Custom Maven repositories do not work
> -
>
> Key: IGNITE-13927
> URL: https://issues.apache.org/jira/browse/IGNITE-13927
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
>  Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha1
>
>
> I've created a staging [1] for 3.0.0-alpha1 and tried to install from this 
> repo, but it failed to work:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite init 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494/
> Creating directories... Done!
> +++
> | Binaries Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-bin  |
> +++
> | Work Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-work |
> +++
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> Downloading through {{add module}} doesn't work either:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite module add 
> mvn:org.apache.ignite:ignite-runner:3.0.0-alpha1 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> [1] https://repository.apache.org/content/repositories/orgapacheignite-1494/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13927) Custom Maven repositories do not work

2020-12-29 Thread Valentin Kulichenko (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256118#comment-17256118
 ] 

Valentin Kulichenko commented on IGNITE-13927:
--

[~slava.koptilin], thanks for the investigation! The {{apache-ignite}} artifact 
was indeed skipped for some reason. I've fixed the deployment - works now.

> Custom Maven repositories do not work
> -
>
> Key: IGNITE-13927
> URL: https://issues.apache.org/jira/browse/IGNITE-13927
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
>  Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha1
>
>
> I've created a staging [1] for 3.0.0-alpha1 and tried to install from this 
> repo, but it failed to work:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite init 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494/
> Creating directories... Done!
> +++
> | Binaries Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-bin  |
> +++
> | Work Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-work |
> +++
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> Downloading through {{add module}} doesn't work either:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite module add 
> mvn:org.apache.ignite:ignite-runner:3.0.0-alpha1 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> [1] https://repository.apache.org/content/repositories/orgapacheignite-1494/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13845) Add checkpoint metrics

2020-12-29 Thread Nikolay Izhikov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256117#comment-17256117
 ] 

Nikolay Izhikov commented on IGNITE-13845:
--

Hello, [~mmuzaf], [~NSAmelchev]

I will do review shortly.

> Add checkpoint metrics
> --
>
> Key: IGNITE-13845
> URL: https://issues.apache.org/jira/browse/IGNITE-13845
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add last checkpoint duration metrics:
> * beforeLockDuration
> * listenersExecuteDuration
> * lockHoldDuration
> * walCpRecordFsyncDuration
> * writeCheckpointEntryDuration
> * splitAndSortCpPagesDuration
> Add durations histograms:
> * CheckpointBeforeLockHistogram
> * CheckpointLockWaitHistogram
> * CheckpointListenersExecuteHistogram
> * CheckpointMarkHistogram
> * CheckpointLockHoldHistogram
> * CheckpointPagesWriteHistogram
> * CheckpointFsyncHistogram
> * CheckpointWalRecordFsyncHistogram
> * CheckpointWriteEntryHistogram
> * CheckpointSplitAndSortPagesHistogram
> * CheckpointHistogram



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256100#comment-17256100
 ] 

Pavel Tupitsyn edited comment on IGNITE-13883 at 12/29/20, 6:50 PM:


Benchmark added: {{BinarySystemTypeReadBenchmark}}.

On Core i7-9700K, Ubuntu 20.04:

*BEFORE*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.080 us | 0.0030 us | 0.0025 us | 0.0725 | - | - | 456 
B |
{code}

*AFTER*
{code}
| Method | Mean |   Error |  StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|--- |-:|:|:|---:|--:|--:|--:|
|   Read | 849.4 ns | 4.44 ns | 4.16 ns | 0.0725 | - | - | 456 B |
{code}

(~13% improvement)


was (Author: ptupitsyn):
Benchmark added: {{BinarySystemTypeReadBenchmark}}.

*BEFORE*
{code}
 | Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
 |--- 
|-:|--:|--:|---:|--:|--:|--:|
 |   Read | 2.063 us | 0.0089 us | 0.0084 us | 0.2823 | - | - |   1.74 
KB |
{code}

*AFTER*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.792 us | 0.0080 us | 0.0071 us | 0.2728 | - | - |   1.67 
KB |
{code}

(~13% improvement)

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256100#comment-17256100
 ] 

Pavel Tupitsyn edited comment on IGNITE-13883 at 12/29/20, 6:28 PM:


Benchmark added: {{BinarySystemTypeReadBenchmark}}.

*BEFORE*
{code}
 | Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
 |--- 
|-:|--:|--:|---:|--:|--:|--:|
 |   Read | 2.063 us | 0.0089 us | 0.0084 us | 0.2823 | - | - |   1.74 
KB |
{code}

*AFTER*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.792 us | 0.0080 us | 0.0071 us | 0.2728 | - | - |   1.67 
KB |
{code}

(~13% improvement)


was (Author: ptupitsyn):
*BEFORE*
{code}
 | Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
 |--- 
|-:|--:|--:|---:|--:|--:|--:|
 |   Read | 2.063 us | 0.0089 us | 0.0084 us | 0.2823 | - | - |   1.74 
KB |
{code}

*AFTER*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.792 us | 0.0080 us | 0.0071 us | 0.2728 | - | - |   1.67 
KB |
{code}

(~13% improvement)

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256100#comment-17256100
 ] 

Pavel Tupitsyn edited comment on IGNITE-13883 at 12/29/20, 6:27 PM:


*BEFORE*
{code}
 | Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
 |--- 
|-:|--:|--:|---:|--:|--:|--:|
 |   Read | 2.063 us | 0.0089 us | 0.0084 us | 0.2823 | - | - |   1.74 
KB |
{code}

*AFTER*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.792 us | 0.0080 us | 0.0071 us | 0.2728 | - | - |   1.67 
KB |
{code}

(~13% improvement)


was (Author: ptupitsyn):
*BEFORE*
{code}
 | Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
 |--- 
|-:|--:|--:|---:|--:|--:|--:|
 |   Read | 2.063 us | 0.0089 us | 0.0084 us | 0.2823 | - | - |   1.74 
KB |
{code}

*AFTER*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.792 us | 0.0080 us | 0.0071 us | 0.2728 | - | - |   1.67 
KB |
{code}

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256100#comment-17256100
 ] 

Pavel Tupitsyn commented on IGNITE-13883:
-

*BEFORE*
{code}
 | Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
 |--- 
|-:|--:|--:|---:|--:|--:|--:|
 |   Read | 2.063 us | 0.0089 us | 0.0084 us | 0.2823 | - | - |   1.74 
KB |
{code}

*AFTER*
{code}
| Method | Mean | Error |StdDev |  Gen 0 | Gen 1 | Gen 2 | 
Allocated |
|--- 
|-:|--:|--:|---:|--:|--:|--:|
|   Read | 1.792 us | 0.0080 us | 0.0071 us | 0.2728 | - | - |   1.67 
KB |
{code}

> .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to 
> switch-case
> -
>
> Key: IGNITE-13883
> URL: https://issues.apache.org/jira/browse/IGNITE-13883
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> {{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and 
> generics:
> * Hard to understand and maintain
> * Possibly causes overhead due to virtual method calls
> Refactor to switch-case and check if performance improves.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12824) .NET: Interoperable DateTime

2020-12-29 Thread Nikolay Izhikov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12824:
-
Fix Version/s: 2.10

> .NET: Interoperable DateTime
> 
>
> Key: IGNITE-12824
> URL: https://issues.apache.org/jira/browse/IGNITE-12824
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET, iep-54, ignite-3, sbcf
> Fix For: 3.0, 2.10
>
> Attachments: IGNITE-12824-from-2.9.0.patch
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> *+The Problem+* 
>  Presently .NET API writes dates as composite Ignite objects. Only .NET 
> clients can read such dates: any other client (JDBC, Java, etc) does not 
> understand it without custom deserialization.
>   
>  It is still possible to configure .NET serialization to write dates as 
> Ignite dates - see [DateTime Serialization 
> note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
>  But then Ignite accepts only UTC dates, requiring the application developers 
> to convert local dates to UTC dates and back. This task is not trivial: 
> [DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
>  uses calendars different from Java (and the .NET calendars are the invalid 
> ones - especially for pre-1990 dates).
>   
>  The motivation for the current default behavior was probably the desire to 
> keep the Time Zone information: Ignite dates do not store time zones.
>   
>  In our experience interoperability is more important than storing time zone 
> info.
>   
>  *+The Solution+*
>  # Always write .NET dates as portable Ignite dates: get rid of the 
> {{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers 
> this behavior.
>  Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects 
> seems a useful case.
>  # Automatically convert Local dates to UTC and back *inside* Ignite.NET. 
>  Add a {{BinaryReflectiveSerializer.UtcDate flag}} to disable this 
> conversion. This prevents loosing the {{DateTime.Kind}} property of UTC 
> dates.  {{UtcDate}} set to true implies the existing behavior: Ignite gets 
> UTC dates and throws a "Date must be in UTC" exception on an attempt to write 
> a Local date. The {{UtcDate}} flag is false by default.
>  # Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda 
> time uses Java calendars making the conversion truly portable.
>  
>  *+The Benefits+*
>  # Portable dates is a more frequent use-case than storing time zone info for 
> every date in Ignite. This becomes default behavior and the developers do not 
> need to always explicitly configure it.
>  # Non-trivial code to make the truly portable UTC<->Local conversion is 
> implemented once inside Ignite instead of having every Ignite.NET application 
> implementing it.
> +*References*+
>  * [Dev-List 
> Discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Interoperable-Ignite-NET-Dates-td49946.html]
>  * IEP-TBD



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET

2020-12-29 Thread Nikolay Izhikov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-10075:
-
Fix Version/s: 2.10

> .NET: Avoid binary configurations of Ignite Java service params and result 
> when calling it from Ignite.NET
> --
>
> Key: IGNITE-10075
> URL: https://issues.apache.org/jira/browse/IGNITE-10075
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET, sbcf
> Fix For: 2.10
>
> Attachments: IGNITE-10075-from-2.9.0.patch, MyTest.cs
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Presently if there is an Ignite Java service taking parameters of complex 
> (composite) types and returning a result of complex type then all the complex 
> types must be explicitly specified in the binary configuration.
> We need to enhance Ignite not to require binary configuration assuming that 
> we use the same type, package/namespace and field/property names on both the 
> .NET and Java sides (or provide a custom name mapper for relaxed naming 
> conventions).
> h2. Reproducer
> [https://github.com/kukushal/apache-ignite-issue10075.git]
> h3. ICalculator.java
> {code:java}
> package Apache.Ignite.Issue10075;
> public interface ICalculator {
> Result Calculate(Parameter p);
> }
> {code}
> h3. Parameter.java
> {code:java}
> package Apache.Ignite.Issue10075;
> public final class Parameter {
> private int id;
> private double val;
> public int getId() {
> return id;
> }
> public Parameter setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return val;
> }
> public Parameter setValue(double val) {
> this.val = val;
> return this;
> }
> }
> {code}
> h3. Result .java
> {code:java}
> package Apache.Ignite.Issue10075;
> public final class Result {
> private int id;
> private double value;
> public int getId() {
> return id;
> }
> public Result setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return value;
> }
> public Result setValue(double val) {
> this.value = val;
> return this;
> }
> }
> {code}
> h3. IgniteCalculatorService.java
> {code:java}
> package Apache.Ignite.Issue10075;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public final class IgniteCalculatorService implements Service, ICalculator {
> @Override public Result Calculate(Parameter p) {
> return new Result().setId(p.getId()).setValue(p.getValue() * 
> p.getValue());
> }
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) {
> }
> @Override public void execute(ServiceContext ctx) {
> }
> }
> {code}
> h3. build.gradle
> {code:groovy}
> plugins {
> id 'java'
> }
> group 'apache.ignite.issue10075'
> version '1.0.0-SNAPSHOT'
> sourceCompatibility = 1.8
> repositories {
> mavenLocal()
> mavenCentral()
> }
> def igniteVer='2.9.0'
> dependencies {
> compile group: 'org.apache.ignite', name: 'ignite-core', version: 
> igniteVer
> testCompile group: 'junit', name: 'junit', version: '4.12'
> }
> {code}
> h3. Apache.Ignite.Issue10075/ignite-config.xml
> {code:xml}
> 
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd;>
>  class="org.apache.ignite.configuration.IgniteConfiguration">
> 
> 
> 
> 
> 
> 
> 
>  class="Apache.Ignite.Issue10075.IgniteCalculatorService"/>
> 
> 
> 
> 
> 
> 
> 
>  class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
> 
> 
> 127.0.0.1:47500
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> h3. Apache.Ignite.Issue10075/ICalculator.cs
> {code:c#}
> namespace Apache.Ignite.Issue10075
> {
> public interface ICalculator
> {
> Result Calculate(Parameter p);
> }
> }
> {code}
> h3. 

[jira] [Assigned] (IGNITE-13927) Custom Maven repositories do not work

2020-12-29 Thread Valentin Kulichenko (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Valentin Kulichenko reassigned IGNITE-13927:


Assignee: Valentin Kulichenko

> Custom Maven repositories do not work
> -
>
> Key: IGNITE-13927
> URL: https://issues.apache.org/jira/browse/IGNITE-13927
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
>  Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha1
>
>
> I've created a staging [1] for 3.0.0-alpha1 and tried to install from this 
> repo, but it failed to work:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite init 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494/
> Creating directories... Done!
> +++
> | Binaries Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-bin  |
> +++
> | Work Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-work |
> +++
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> Downloading through {{add module}} doesn't work either:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite module add 
> mvn:org.apache.ignite:ignite-runner:3.0.0-alpha1 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> [1] https://repository.apache.org/content/repositories/orgapacheignite-1494/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13930) Update pom depencencies to 2.11.0-SNAPSHOT version

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256093#comment-17256093
 ] 

Maxim Muzafarov commented on IGNITE-13930:
--

Merge to the master branch.
Thank you for the review.

> Update pom depencencies to 2.11.0-SNAPSHOT version
> --
>
> Key: IGNITE-13930
> URL: https://issues.apache.org/jira/browse/IGNITE-13930
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.11
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The pom dependencies must be updated due to the ignite-2.10 branch has been 
> created.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13931) .NET: Service can't assign correct type to passed array parameters (.Net -> .Net call)

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256037#comment-17256037
 ] 

Pavel Tupitsyn commented on IGNITE-13931:
-

[~nizhikov] Looks good to me

> .NET: Service can't assign correct type to passed array parameters (.Net -> 
> .Net call)
> --
>
> Key: IGNITE-13931
> URL: https://issues.apache.org/jira/browse/IGNITE-13931
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, parameters);
> {code}
> Please note, that if there's no overloaded methods, at least in 

[jira] [Commented] (IGNITE-13931) .NET: Service can't assign correct type to passed array parameters (.Net -> .Net call)

2020-12-29 Thread Nikolay Izhikov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256023#comment-17256023
 ] 

Nikolay Izhikov commented on IGNITE-13931:
--

https://ci.ignite.apache.org/viewLog.html?buildId=5811357=IgniteTests24Java8_RunAllNet
 - tests are OK.

> .NET: Service can't assign correct type to passed array parameters (.Net -> 
> .Net call)
> --
>
> Key: IGNITE-13931
> URL: https://issues.apache.org/jira/browse/IGNITE-13931
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, 

[jira] [Commented] (IGNITE-13927) Custom Maven repositories do not work

2020-12-29 Thread Vyacheslav Koptilin (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256016#comment-17256016
 ] 

Vyacheslav Koptilin commented on IGNITE-13927:
--

Hello [~vkulichenko],

It looks like, the root cause of the issue is the fact that parent artifact 
{{apache-ignite}} is missing at the custom repository [1], and so it cannot be 
resolved.
Please take a look at the following debug output:

{noformat}
[SUCCESSFUL ] 
org.apache.ignite#ignite-runner;3.0.0-alpha1!ignite-runner.pom(pom.original) 
(57ms)
parent.groupId: org.apache.ignite
parent.artifactId: apache-ignite
parent.version: 3.0.0-alpha1
chainResolver: Checking cache for: dependency: 
org.apache.ignite#apache-ignite;3.0.0-alpha1 {}
no ivy file in cache for org.apache.ignite#apache-ignite;3.0.0-alpha1: 
tried ...
no ivy file in cache for org.apache.ignite#apache-ignite;3.0.0-alpha1: 
tried ...
trying 
https://repository.apache.org/content/repositories/orgapacheignite-1494/org/apache/ignite/apache-ignite/3.0.0-alpha1/apache-ignite-3.0.0-alpha1.pom
tried 
https://repository.apache.org/content/repositories/orgapacheignite-1494/org/apache/ignite/apache-ignite/3.0.0-alpha1/apache-ignite-3.0.0-alpha1.pom
HTTP response status: 404 
url=https://repository.apache.org/content/repositories/orgapacheignite-1494/org/apache/ignite/apache-ignite/3.0.0-alpha1/apache-ignite-3.0.0-alpha1.pom
CLIENT ERROR: Not Found 
url=https://repository.apache.org/content/repositories/orgapacheignite-1494/org/apache/ignite/apache-ignite/3.0.0-alpha1/apache-ignite-3.0.0-alpha1.pom
/content/repositories/orgapacheignite-1494: resource not reachable for 
org/apache/ignite#apache-ignite;3.0.0-alpha1: 

res=https://repository.apache.org/content/repositories/orgapacheignite-1494/org/apache/ignite/apache-ignite/3.0.0-alpha1/apache-ignite-3.0.0-alpha1.pom

{noformat}


> Custom Maven repositories do not work
> -
>
> Key: IGNITE-13927
> URL: https://issues.apache.org/jira/browse/IGNITE-13927
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Priority: Blocker
>  Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha1
>
>
> I've created a staging [1] for 3.0.0-alpha1 and tried to install from this 
> repo, but it failed to work:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite init 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494/
> Creating directories... Done!
> +++
> | Binaries Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-bin  |
> +++
> | Work Directory | 
> /Users/vkulichenko/GridGain/apache-ignite-3/modules/cli/target/ignite-work |
> +++
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> Downloading through {{add module}} doesn't work either:
> {noformat}
> Valentin-Kulichenko-MacBook-Pro-1772:apache-ignite-3 vkulichenko$ 
> ./modules/cli/target/ignite module add 
> mvn:org.apache.ignite:ignite-runner:3.0.0-alpha1 
> --repo=https://repository.apache.org/content/repositories/orgapacheignite-1494
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha1...
> |>
>|0%
> [unresolved dependency: org.apache.ignite#ignite-runner;3.0.0-alpha1: not 
> found]
> {noformat}
> [1] https://repository.apache.org/content/repositories/orgapacheignite-1494/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-13932) Extend Ignite thread pools documentation

2020-12-29 Thread Nikita Safonov (Jira)
Nikita Safonov created IGNITE-13932:
---

 Summary: Extend Ignite thread pools documentation
 Key: IGNITE-13932
 URL: https://issues.apache.org/jira/browse/IGNITE-13932
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.9
Reporter: Nikita Safonov
Assignee: Nikita Safonov


There are references in the code to three thread pools that don't appear to be 
referenced in the Ignite thread pool documentation at 
[https://apacheignite.readme.io/docs/thread-pools]. 
 
These are:
 
asyncCallbackThreadPoolSize
managementThreadPoolSize
utilityCacheThreadPoolSize

 
By default these pools will be set to Max(8, Environment.ProcessorCount) []we 
use the IA C# client]
 
Note: These configurations are referenced in the Ignite Javadoc pages, but the 
descriptions are just single sentences mirroring the names of the thread pools 
themselves.
 
The thread pool documentation should be extended to include these additional 
pools, particularly with respect to their purpose and roles, and the 
circumstances when you would change them from the default value.
 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13911) asyncio version of python ignite thin client

2020-12-29 Thread Ivan Daschinskiy (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Daschinskiy updated IGNITE-13911:
--
Component/s: thin client

> asyncio version of python ignite thin client
> 
>
> Key: IGNITE-13911
> URL: https://issues.apache.org/jira/browse/IGNITE-13911
> Project: Ignite
>  Issue Type: New Feature
>  Components: python, thin client
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Currently, asyncio is default event-loop and coroutine engine for python 
> 3.6+. This approach can drastically improve performance of IO-bound tasks. So 
> it is important to implement asyncio version of python ignite client. Old 
> synchronous version should remain and share common code with asyncio version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13895) SSL usage in ducktape tests

2020-12-29 Thread Sergei Ryzhov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergei Ryzhov updated IGNITE-13895:
---
Description: 
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

{code}
Root
 - CA
  - Server
  - Client
  - Admin
{code}




  was:
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
  - Server
  - Client
  - Admin




> SSL usage in ducktape tests
> ---
>
> Key: IGNITE-13895
> URL: https://issues.apache.org/jira/browse/IGNITE-13895
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>  Labels: IEP-56, ducktape
>
> SSL usage in ducktape tests
> certificates are generated at startup ./run-test.sh
> {code}
> Root
>  - CA
>   - Server
>   - Client
>   - Admin
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13895) SSL usage in ducktape tests

2020-12-29 Thread Sergei Ryzhov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergei Ryzhov updated IGNITE-13895:
---
Description: 
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

{code}
Root
 - CA
   - Server
   - Client
   - Admin
{code}




  was:
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

{code}
Root
 - CA
  - Server
  - Client
  - Admin
{code}





> SSL usage in ducktape tests
> ---
>
> Key: IGNITE-13895
> URL: https://issues.apache.org/jira/browse/IGNITE-13895
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>  Labels: IEP-56, ducktape
>
> SSL usage in ducktape tests
> certificates are generated at startup ./run-test.sh
> {code}
> Root
>  - CA
>- Server
>- Client
>- Admin
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13895) SSL usage in ducktape tests

2020-12-29 Thread Sergei Ryzhov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergei Ryzhov updated IGNITE-13895:
---
Description: 
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
  - Server
  - Client
  - Admin



  was:
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
 - Server
 - Client
 - Admin




> SSL usage in ducktape tests
> ---
>
> Key: IGNITE-13895
> URL: https://issues.apache.org/jira/browse/IGNITE-13895
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>  Labels: IEP-56, ducktape
>
> SSL usage in ducktape tests
> certificates are generated at startup ./run-test.sh
> Root
>  - CA
>   - Server
>   - Client
>   - Admin



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13895) SSL usage in ducktape tests

2020-12-29 Thread Sergei Ryzhov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergei Ryzhov updated IGNITE-13895:
---
Description: 
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
- Server
- Client
- Admin



  was:
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
   - Server
   - Client
   - Admin




> SSL usage in ducktape tests
> ---
>
> Key: IGNITE-13895
> URL: https://issues.apache.org/jira/browse/IGNITE-13895
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>  Labels: IEP-56, ducktape
>
> SSL usage in ducktape tests
> certificates are generated at startup ./run-test.sh
> Root
>  - CA
> - Server
> - Client
> - Admin



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13895) SSL usage in ducktape tests

2020-12-29 Thread Sergei Ryzhov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergei Ryzhov updated IGNITE-13895:
---
Description: 
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA

- Server
- Client
- Admin



  was:
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
- Server
- Client
- Admin




> SSL usage in ducktape tests
> ---
>
> Key: IGNITE-13895
> URL: https://issues.apache.org/jira/browse/IGNITE-13895
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>  Labels: IEP-56, ducktape
>
> SSL usage in ducktape tests
> certificates are generated at startup ./run-test.sh
> Root
>  - CA
> - Server
> - Client
> - Admin



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13895) SSL usage in ducktape tests

2020-12-29 Thread Sergei Ryzhov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergei Ryzhov updated IGNITE-13895:
---
Description: 
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
   - Server
   - Client
   - Admin



  was:SSL usage in ducktape tests


> SSL usage in ducktape tests
> ---
>
> Key: IGNITE-13895
> URL: https://issues.apache.org/jira/browse/IGNITE-13895
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>  Labels: IEP-56, ducktape
>
> SSL usage in ducktape tests
> certificates are generated at startup ./run-test.sh
> Root
>  - CA
>- Server
>- Client
>- Admin



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13895) SSL usage in ducktape tests

2020-12-29 Thread Sergei Ryzhov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergei Ryzhov updated IGNITE-13895:
---
Description: 
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA
 - Server
 - Client
 - Admin



  was:
SSL usage in ducktape tests

certificates are generated at startup ./run-test.sh

Root
 - CA

- Server
- Client
- Admin




> SSL usage in ducktape tests
> ---
>
> Key: IGNITE-13895
> URL: https://issues.apache.org/jira/browse/IGNITE-13895
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>  Labels: IEP-56, ducktape
>
> SSL usage in ducktape tests
> certificates are generated at startup ./run-test.sh
> Root
>  - CA
>  - Server
>  - Client
>  - Admin



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13930) Update pom depencencies to 2.11.0-SNAPSHOT version

2020-12-29 Thread Aleksey Plekhanov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255981#comment-17255981
 ] 

Aleksey Plekhanov commented on IGNITE-13930:


[~mmuzaf], looks good to me.

> Update pom depencencies to 2.11.0-SNAPSHOT version
> --
>
> Key: IGNITE-13930
> URL: https://issues.apache.org/jira/browse/IGNITE-13930
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The pom dependencies must be updated due to the ignite-2.10 branch has been 
> created.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13555) Java thin: Add support for IPv6 addresses

2020-12-29 Thread Pavel Tupitsyn (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-13555:

Release Note: Java thin: allow IPv6 server addresses

> Java thin: Add support for IPv6 addresses
> -
>
> Key: IGNITE-13555
> URL: https://issues.apache.org/jira/browse/IGNITE-13555
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Varvara Kozhukhova
>Priority: Minor
>  Labels: newbie
> Fix For: 2.10
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> ReliableChannel#parseAddresses -> HostAndPortRange#parse logic does not 
> support IPv6 addresses, fix it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13931) .NET: Service can't assign correct type to passed array parameters (.Net -> .Net call)

2020-12-29 Thread Nikolay Izhikov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255965#comment-17255965
 ] 

Nikolay Izhikov commented on IGNITE-13931:
--

This ticket is a follow-up for IGNITE-13897.

Here I will check and fix .Net -> .Net call with overloaded methods and typed 
arrays.

> .NET: Service can't assign correct type to passed array parameters (.Net -> 
> .Net call)
> --
>
> Key: IGNITE-13931
> URL: https://issues.apache.org/jira/browse/IGNITE-13931
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, parameters);
> {code}
> Please 

[jira] [Created] (IGNITE-13931) .NET: Service can't assign correct type to passed array parameters (.Net -> .Net call)

2020-12-29 Thread Nikolay Izhikov (Jira)
Nikolay Izhikov created IGNITE-13931:


 Summary: .NET: Service can't assign correct type to passed array 
parameters (.Net -> .Net call)
 Key: IGNITE-13931
 URL: https://issues.apache.org/jira/browse/IGNITE-13931
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.9
Reporter: Yaroslav Molochkov
Assignee: Nikolay Izhikov
 Fix For: 2.10


This issue relates to IGNITE-12823.

Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class 
org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
at 
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
 Method)
at 
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
at 
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
at 
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
at 
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at 
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Service interface itself looks like this:
{code:java}
public interface SomeService : IService
{
int processSomething(int foo, Parameter[] parameters);

int processSomething(int foo, int bar);
}

public class Parameter
{

private int id;

private ParamValue[] _values;


public Parameter(int id, ParamValue[] _values)
{
 
   this.id = id;

   this._values = _values;

}

}



public class ParamValue
{

private int id;

private double val;


public ParamValue(int id, double val)
{
 
   this.id = id;
   
   this.val = val;
  
}

}

{code}
And the call to the service:
{code:java}
var svc = igniteServices.GetServiceProxy(name, false);
var result = svc.processSomething(id, parameters);
{code}
Please note, that if there's no overloaded methods, at least in our experiments 
we found out that it does reproduce with equal number of parameters in 
overloaded methods (e.g. here we have overloaded methods that take 2 parameters 
each), then the code works like a charm.

Fix in IGNITE-12823 addresses particular code execution path where the 
execution flow goes through PlatformServices class. Yet in this case our code 
goes through PlatformAbstractService. I think that the fix of casting arrays 
should be positioned a little bit lower in the call stack (or 

[jira] [Commented] (IGNITE-13897) .NET: Service can't assign correct type to passed array parameters

2020-12-29 Thread Nikolay Izhikov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255964#comment-17255964
 ] 

Nikolay Izhikov commented on IGNITE-13897:
--

The merged patch fixes the following issue - .Net -> Java service not invoked 
for overload methods.

I will create a follow-up ticket to check .Net -> .Net invocation.

> .NET: Service can't assign correct type to passed array parameters
> --
>
> Key: IGNITE-13897
> URL: https://issues.apache.org/jira/browse/IGNITE-13897
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = 

[jira] [Created] (IGNITE-13930) Update pom depencencies to 2.11.0-SNAPSHOT version

2020-12-29 Thread Maxim Muzafarov (Jira)
Maxim Muzafarov created IGNITE-13930:


 Summary: Update pom depencencies to 2.11.0-SNAPSHOT version
 Key: IGNITE-13930
 URL: https://issues.apache.org/jira/browse/IGNITE-13930
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


The pom dependencies must be updated due to the ignite-2.10 branch has been 
created.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13930) Update pom depencencies to 2.11.0-SNAPSHOT version

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13930:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Update pom depencencies to 2.11.0-SNAPSHOT version
> --
>
> Key: IGNITE-13930
> URL: https://issues.apache.org/jira/browse/IGNITE-13930
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> The pom dependencies must be updated due to the ignite-2.10 branch has been 
> created.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13930) Update pom depencencies to 2.11.0-SNAPSHOT version

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13930:
-
Fix Version/s: 2.11

> Update pom depencencies to 2.11.0-SNAPSHOT version
> --
>
> Key: IGNITE-13930
> URL: https://issues.apache.org/jira/browse/IGNITE-13930
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.11
>
>
> The pom dependencies must be updated due to the ignite-2.10 branch has been 
> created.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12852) Comma in field is not supported by COPY command

2020-12-29 Thread YuJue Li (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255952#comment-17255952
 ] 

YuJue Li commented on IGNITE-12852:
---

I recommend that this patch be included in version 2.10.
The copy command is very useful in some test scenarios

> Comma in field is not supported by COPY command
> ---
>
> Key: IGNITE-12852
> URL: https://issues.apache.org/jira/browse/IGNITE-12852
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Critical
> Fix For: 2.10
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); 
>  
> a.csv: 
> 1,"a,b",2 
>  
> COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; 
>  
> The copy command fails because there is a comma in the second field,but this 
> is a fully legal and compliant CSV format



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13928) Index defragmentation: only one index defragmented

2020-12-29 Thread Ivan Bessonov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255949#comment-17255949
 ] 

Ivan Bessonov commented on IGNITE-13928:


[~sdanilov] looks good, thank you! Let's wait for tests before merging.

> Index defragmentation: only one index defragmented
> --
>
> Key: IGNITE-13928
> URL: https://issues.apache.org/jira/browse/IGNITE-13928
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In IndexingDefragmentation.java:
> {code:java}
> // code placeholder
> H2TreeIndex oldH2Idx = (H2TreeIndex)indexes.get(2);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IGNITE-13929) Don't print sensitive information in logs by default

2020-12-29 Thread Sergey Uttsel (Jira)
Sergey Uttsel created IGNITE-13929:
--

 Summary: Don't print sensitive information in logs by default
 Key: IGNITE-13929
 URL: https://issues.apache.org/jira/browse/IGNITE-13929
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Uttsel
Assignee: Sergey Uttsel


Right now, by default, node prints entries in logs of PME and long running 
operations. It’s not secure, because it disclose sensitive data. However 
printing of entries might help with certain issues such as deadlock. So we can 
print hash of entries in log.

 

 

*Summary of the changes:*
1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated
2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three possible 
values:
"plain" - print as is
"hash" - print hash (primitives are printed as is)
"none" - don’t print anything
3. "hash" is default value
4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the value 
converts to IGNITE_SENSITIVE_DATA_LOGGING:
true -> plain
false -> none



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13929) Don't print sensitive information in logs by default

2020-12-29 Thread Sergey Uttsel (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Uttsel updated IGNITE-13929:
---
Description: 
Right now, by default, node prints entries in logs of PME and long running 
operations. It’s not secure, because it disclose sensitive data. However 
printing of entries might help with certain issues such as deadlock. So we can 
print hash of entries in log.

  

*Summary of the changes:*
 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated
 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three possible 
values:
 "plain" - print as is
 "hash" - print hash (primitives are printed as is)
 "none" - don’t print anything
 3. "hash" is default value
 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the value 
converts to IGNITE_SENSITIVE_DATA_LOGGING:
 true -> plain
 false -> none

  was:
Right now, by default, node prints entries in logs of PME and long running 
operations. It’s not secure, because it disclose sensitive data. However 
printing of entries might help with certain issues such as deadlock. So we can 
print hash of entries in log.

 

 

*Summary of the changes:*
1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated
2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three possible 
values:
"plain" - print as is
"hash" - print hash (primitives are printed as is)
"none" - don’t print anything
3. "hash" is default value
4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the value 
converts to IGNITE_SENSITIVE_DATA_LOGGING:
true -> plain
false -> none


> Don't print sensitive information in logs by default
> 
>
> Key: IGNITE-13929
> URL: https://issues.apache.org/jira/browse/IGNITE-13929
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
>
> Right now, by default, node prints entries in logs of PME and long running 
> operations. It’s not secure, because it disclose sensitive data. However 
> printing of entries might help with certain issues such as deadlock. So we 
> can print hash of entries in log.
>   
> *Summary of the changes:*
>  1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated
>  2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three 
> possible values:
>  "plain" - print as is
>  "hash" - print hash (primitives are printed as is)
>  "none" - don’t print anything
>  3. "hash" is default value
>  4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the 
> value converts to IGNITE_SENSITIVE_DATA_LOGGING:
>  true -> plain
>  false -> none



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13897) .NET: Service can't assign correct type to passed array parameters

2020-12-29 Thread Nikolay Izhikov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255924#comment-17255924
 ] 

Nikolay Izhikov commented on IGNITE-13897:
--

Failures unrelated.

> .NET: Service can't assign correct type to passed array parameters
> --
>
> Key: IGNITE-13897
> URL: https://issues.apache.org/jira/browse/IGNITE-13897
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, parameters);
> {code}
> Please note, that if there's no overloaded methods, at least in our 
> experiments we found out that it does 

[jira] [Commented] (IGNITE-13897) .NET: Service can't assign correct type to passed array parameters

2020-12-29 Thread Ignite TC Bot (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255923#comment-17255923
 ] 

Ignite TC Bot commented on IGNITE-13897:


{panel:title=Branch: [pull/8614/head] Base: [master] : Possible Blockers 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=5811165]]
* ZookeeperDiscoverySpiTestSuite3: 
GridCacheReplicatedNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups - 
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite3: GridEventConsumeSelfTest.testApi - Test has 
low fail rate in base branch 0,0% and is not flaky

{panel}
{panel:title=Branch: [pull/8614/head] Base: [master] : New Tests 
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Binary Objects{color} [[tests 
6|https://ci.ignite.apache.org/viewLog.html?buildId=5811087]]
* {color:#013220}IgniteBinaryObjectsTestSuite: 
BinaryMarshallerNonCompactSelfTest.testReadDetachedTypedArray - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite: 
BinaryMarshallerSelfTest.testReadDetachedTypedArray - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite: 
BinaryMarshallerSelfTest.testReadArrayOfBinaryCollections - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite: 
BinaryMarshallerSelfTest.testReadArrayOfCollections - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite: 
BinaryMarshallerNonCompactSelfTest.testReadArrayOfBinaryCollections - 
PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite: 
BinaryMarshallerNonCompactSelfTest.testReadArrayOfCollections - PASSED{color}

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5811183buildTypeId=IgniteTests24Java8_RunAll]

> .NET: Service can't assign correct type to passed array parameters
> --
>
> Key: IGNITE-13897
> URL: https://issues.apache.org/jira/browse/IGNITE-13897
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>  

[jira] [Created] (IGNITE-13928) Index defragmentation: only one index defragmented

2020-12-29 Thread Semyon Danilov (Jira)
Semyon Danilov created IGNITE-13928:
---

 Summary: Index defragmentation: only one index defragmented
 Key: IGNITE-13928
 URL: https://issues.apache.org/jira/browse/IGNITE-13928
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Semyon Danilov
Assignee: Semyon Danilov
 Fix For: 2.10


In IndexingDefragmentation.java:
{code:java}
// code placeholder
H2TreeIndex oldH2Idx = (H2TreeIndex)indexes.get(2);
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13897) .NET: Service can't assign correct type to passed array parameters

2020-12-29 Thread Pavel Tupitsyn (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255907#comment-17255907
 ] 

Pavel Tupitsyn commented on IGNITE-13897:
-

[~nizhikov] [~YAMolochkov] 

The bug is about .NET services, right?
1. The fix is for Java service calls
2. I can't reproduce the bug on current master

> .NET: Service can't assign correct type to passed array parameters
> --
>
> Key: IGNITE-13897
> URL: https://issues.apache.org/jira/browse/IGNITE-13897
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, 

[jira] [Assigned] (IGNITE-7039) SQL: local query should pin affected partitions

2020-12-29 Thread Stanilovsky Evgeny (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanilovsky Evgeny reassigned IGNITE-7039:
--

Assignee: Stanilovsky Evgeny

> SQL: local query should pin affected partitions
> ---
>
> Key: IGNITE-7039
> URL: https://issues.apache.org/jira/browse/IGNITE-7039
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Stanilovsky Evgeny
>Priority: Major
>  Labels: sql-stability
> Attachments: 3194.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When distributed query is executed, we pin cache partitions for particular 
> topology version on map nodes [1]. However, it seems that we do no do that 
> for local queries. This is a bug because partition with required data could 
> be evicted from local node at any time, leading to incorrect results.
> [1] 
> https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13897) .NET: Service can't assign correct type to passed array parameters

2020-12-29 Thread Pavel Tupitsyn (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-13897:

Summary: .NET: Service can't assign correct type to passed array parameters 
 (was: .NET Service can't assign correct type to passed array parameters)

> .NET: Service can't assign correct type to passed array parameters
> --
>
> Key: IGNITE-13897
> URL: https://issues.apache.org/jira/browse/IGNITE-13897
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, parameters);
> {code}
> Please note, that 

[jira] [Updated] (IGNITE-13897) .NET Service can't assign correct type to passed array parameters

2020-12-29 Thread Pavel Tupitsyn (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-13897:

Labels: .NET  (was: )

> .NET Service can't assign correct type to passed array parameters
> -
>
> Key: IGNITE-13897
> URL: https://issues.apache.org/jira/browse/IGNITE-13897
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET
> Fix For: 2.10
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method 
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)
>   at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
>   at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
>   at 
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService : IService
> {
> int processSomething(int foo, Parameter[] parameters);
> int processSomething(int foo, int bar);
> }
> public class Parameter
{

> private int id;

> private ParamValue[] _values;


> public Parameter(int id, ParamValue[] _values)
{
 
>this.id = id;

>this._values = _values;

> }
> 
}
> 

public class ParamValue
{

> private int id;

> private double val;


> public ParamValue(int id, double val)
{
 
>this.id = id;
   
>this.val = val;
  
> }
> 
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, parameters);
> {code}
> Please note, that if there's no overloaded methods, at least in our 
> experiments we found out that it does reproduce with equal number of 
> 

[jira] [Commented] (IGNITE-11110) UnsupportedOperationException: null when stopping grid

2020-12-29 Thread Anton Kurbanov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-0?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255900#comment-17255900
 ] 

Anton Kurbanov commented on IGNITE-0:
-

[~ilyak] Could you please review the patch?

> UnsupportedOperationException: null when stopping grid
> --
>
> Key: IGNITE-0
> URL: https://issues.apache.org/jira/browse/IGNITE-0
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Jens Borgland
>Assignee: Anton Kurbanov
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> After upgrading to 2.7 we've started getting these errors when stopping grids:
> {noformat}
> java.lang.UnsupportedOperationException: null
>   at 
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551) 
> ~[ignite-core-2.7.0.jar:2.7.0]
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264)
>  ~[ignite-core-2.7.0.jar:2.7.0]
>   at 
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356) 
> ~[ignite-core-2.7.0.jar:2.7.0]
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228) 
> ~[ignite-core-2.7.0.jar:2.7.0]
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612)
>  ~[ignite-core-2.7.0.jar:2.7.0]
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575)
>  ~[ignite-core-2.7.0.jar:2.7.0]
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379) 
> ~[ignite-core-2.7.0.jar:2.7.0]
>   at org.apache.ignite.Ignition.stop(Ignition.java:225) 
> ~[ignite-core-2.7.0.jar:2.7.0]
>   at 
> org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568) 
> ~[ignite-core-2.7.0.jar:2.7.0]
> {noformat}
> At first glance it looks likely that it was introduced with commit 
> [d04d764|https://github.com/apache/ignite/commit/d04d76440ce86873de7aebc8c03d39484cd1e3e5]
>  (the {{GridJobProcessor}} still calls {{clear()}} on maps).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13456) Expand info collected during tracing of SQL queries.

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13456:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Expand info collected during tracing of SQL queries.
> 
>
> Key: IGNITE-13456
> URL: https://issues.apache.org/jira/browse/IGNITE-13456
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>  Labels: iep-48
> Fix For: 2.10
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> It's needed to expand info that collected during tracing of SQL queries. 
> The following info must be collected:
> * partition reservation (set of reserved partitions);
> * query parse info: cached query parse result or real parse.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13456) Expand info collected during tracing of SQL queries.

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255899#comment-17255899
 ] 

Maxim Muzafarov commented on IGNITE-13456:
--

[~PetrovMikhail] 

Merged to the master branch, thank you for the contribution.

> Expand info collected during tracing of SQL queries.
> 
>
> Key: IGNITE-13456
> URL: https://issues.apache.org/jira/browse/IGNITE-13456
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>  Labels: iep-48
> Fix For: 2.10
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> It's needed to expand info that collected during tracing of SQL queries. 
> The following info must be collected:
> * partition reservation (set of reserved partitions);
> * query parse info: cached query parse result or real parse.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13456) Expand info collected during tracing of SQL queries.

2020-12-29 Thread Taras Ledkov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255896#comment-17255896
 ] 

Taras Ledkov commented on IGNITE-13456:
---

[~mmuzaf], please merge the patch into master.

> Expand info collected during tracing of SQL queries.
> 
>
> Key: IGNITE-13456
> URL: https://issues.apache.org/jira/browse/IGNITE-13456
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>  Labels: iep-48
> Fix For: 2.10
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> It's needed to expand info that collected during tracing of SQL queries. 
> The following info must be collected:
> * partition reservation (set of reserved partitions);
> * query parse info: cached query parse result or real parse.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-9005:

Fix Version/s: (was: 2.10)
   2.11

> Eviction policy MBeans change failed LifecycleAwareTest on cache name 
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitry Pavlov
>Assignee: Nikolai Kulagin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7246907407546697403=%3Cdefault%3E=testDetails
> after merging 
> IGNITE-8776 Eviction policy MBeans are never registered if 
> evictionPolicyFactory is used 
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for 
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
>  expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from 
> test class. 
> Seems that returing call to cctx.kernalContext (). resource (). 
> injectCacheName (rsrc, cfg.getName ()); should fix issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-9160:

Fix Version/s: (was: 2.10)

> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Attachments: check.txt, reproduce.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE  
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object 
> cannot be cast to 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
>  Or NPE 
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
>  The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
>     return false;{code}
> + List of classes with similar problems: +
>  * *GridTopic$T1-T8* - NPE
>  * *GridCachePreloadLifecycleAbstractTest -* NPE
>  * *GridDhtPartitionFullMap -* NPE and CCE
>  * *GridDhtPartitionMap -* NPE and CCE
>  * *OptimizedMarshallerSelfTest -* NPE and CCE
>  * *GatewayProtectedCacheProxy -* NPE and CCE
>  * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
>  * *GridCacheDistributedQueryManager -* NPE and CCE
>  * *GridServiceMethodReflectKey -* NPE and CCE
>  *  *GridListSetSelfTest -* NPE and CCE
>  * *GridTestKey -* NPE and CCE
>  * *GridCacheMvccCandidate -* CCE
>  * *GridDhtPartitionExchangeId -* CCE
>  * *GridTuple6 -* CCE



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12194) [Phase-2] Calculate expected rebalancing cache group keys

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-12194:
-
Fix Version/s: (was: 2.10)
   2.11

> [Phase-2] Calculate expected rebalancing cache group keys
> -
>
> Key: IGNITE-12194
> URL: https://issues.apache.org/jira/browse/IGNITE-12194
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Nikolai Kulagin
>Priority: Critical
>  Labels: IEP-35
> Fix For: 2.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We need to implement expected to be rebalanced cache group keys and total 
> bytes. Currently, 'estimatedKeysCount' cache metric returns '-1' for some of 
> the cases (see comments IGNITE-11330).
> * rebalancingExpectedKeys long metric
> * rebalancingExpectedBytes long metric
> * rebalancingEvictedPartitionsLeft long metric



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-9165:

Fix Version/s: (was: 2.10)

> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Attachments: 
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields, 
> pass it to other methods that might close it, or return it, and does not 
> appear to close the stream on all paths out of the method.  This may result 
> in a file descriptor leak.
> Example:
>  
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
>  props.load(new FileReader(GridTestUtils.resolveIgnitePath(
>  "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
>  throw new RuntimeException(e);
> }{code}
>  
>  One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>   
>  +org.apache.ignite.internal:+   
>  * *BinaryContext*#classesInPackage(String)
>  * *GridClientJdkMarshaller*#marshal(Object, int)
>  * 
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
>  * *OptimizedObjectStreamSelfTest*#testReadLine()
>  * *PageIdDistributionTest*#_testRealHistory()
>  * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
>  * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
>  * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
>  * *GridTestUtils*.sslContext()



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255891#comment-17255891
 ] 

Maxim Muzafarov commented on IGNITE-12779:
--

[~vladsz83], [~NSAmelchev]

Is there any hepl needed?

> Split implementations of Ignite and IgniteMXBean, make behavior of their 
> active(boolean) different 
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure of in-memory 
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing 
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
> Additionally, as discussed, we should improve comments
> {code:java}
> /** If {@code true}, cluster deactivation will be forced. */
> {code}
> Let's add a link to a full description.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12610) Disable H2 object cache reliably

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255890#comment-17255890
 ] 

Maxim Muzafarov commented on IGNITE-12610:
--

[~artsiom_panko] 

I see some comments still unresolved, do you need any help? Should we include 
this issue to the 2.10 release or can move it to the next?

> Disable H2 object cache reliably
> 
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
>  Labels: newbie
> Fix For: 2.10
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be 
> disabled by using "h2.objectCache" system property. There is a clear intent 
> to disable this cache because the system property is set to "false" in 
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But 
> apparently it is too late, because the property is read by H2 internals 
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13109) Skip distributed metastorage entries that can not be unmarshalled

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255889#comment-17255889
 ] 

Maxim Muzafarov commented on IGNITE-13109:
--

[~NSAmelchev] 

What do we need for this issue to proceed?

> Skip distributed 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
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Need to skip distributed metastorage entries that can not be unmarshalled 
> (These entries can be created by the product that built on Apache Ignite and 
> incorporate additional features). 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.testOldKey
> 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] [Commented] (IGNITE-13582) WAL force rollout timeout

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255888#comment-17255888
 ] 

Maxim Muzafarov commented on IGNITE-13582:
--

[~nizhikov] 

Is everything ready for merge? Do we need a review, TC bot green visa here?

> WAL force rollout timeout
> -
>
> Key: IGNITE-13582
> URL: https://issues.apache.org/jira/browse/IGNITE-13582
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-59
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, Ignite doesn't have a timeout to force WAL segments to rollout.
> We need to introduce one to be able to provide some lag guarantees for the 
> CDC application.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13767) Remove Python PHP and Node.js thin clients from main repository

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255886#comment-17255886
 ] 

Maxim Muzafarov commented on IGNITE-13767:
--

[~isapego] 

Can we move it to the next release or we should wait for the TC configuration?

> Remove Python PHP and Node.js thin clients from main repository
> ---
>
> Key: IGNITE-13767
> URL: https://issues.apache.org/jira/browse/IGNITE-13767
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.9
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Need to remove the following directories, as we now have separate repos for 
> Python, Node.js and PHP thin clients:
> modules/platforms/python
> modules/platforms/nodejs
> modules/platforms/php
>  
> Also, need to check all the places in code where those directories are 
> referenced.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-12852) Comma in field is not supported by COPY command

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255885#comment-17255885
 ] 

Maxim Muzafarov commented on IGNITE-12852:
--

[~liyuj], [~nizhikov] 

Do we have any unresolved comments? Can we proceed with this patch?

> Comma in field is not supported by COPY command
> ---
>
> Key: IGNITE-12852
> URL: https://issues.apache.org/jira/browse/IGNITE-12852
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.8
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Critical
> Fix For: 2.10
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); 
>  
> a.csv: 
> 1,"a,b",2 
>  
> COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; 
>  
> The copy command fails because there is a comma in the second field,but this 
> is a fully legal and compliant CSV format



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13456) Expand info collected during tracing of SQL queries.

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255884#comment-17255884
 ] 

Maxim Muzafarov commented on IGNITE-13456:
--

[~tledkov-gridgain] 

Hello, can we proceed with the merge?

> Expand info collected during tracing of SQL queries.
> 
>
> Key: IGNITE-13456
> URL: https://issues.apache.org/jira/browse/IGNITE-13456
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>  Labels: iep-48
> Fix For: 2.10
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> It's needed to expand info that collected during tracing of SQL queries. 
> The following info must be collected:
> * partition reservation (set of reserved partitions);
> * query parse info: cached query parse result or real parse.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13624) Extend tracing of communication socket write with number of sent bytes.

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255883#comment-17255883
 ] 

Maxim Muzafarov commented on IGNITE-13624:
--

[~slava.koptilin] 

Hello, can we proceed we the merge?

> Extend tracing of communication socket write with number of sent bytes.
> ---
>
> Key: IGNITE-13624
> URL: https://issues.apache.org/jira/browse/IGNITE-13624
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>  Labels: iep-48
> Fix For: 2.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It's needed to extend tracing of communication socket write with number of 
> sent bytes for each message.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13623) Scaladoc not created during release process

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13623:
-
Fix Version/s: 2.10

> Scaladoc not created during release process
> ---
>
> Key: IGNITE-13623
> URL: https://issues.apache.org/jira/browse/IGNITE-13623
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.8, 2.9, 2.8.1
>Reporter: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.10
>
>
> Scaladoc creation is broken (probably by IGNITE-11933). We have 3 release 
> assemblies without scaladoc now (2.8, 2.8.1, 2.9).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13558) GridCacheProcessor should implement better parallelization when restoring partition states on startup

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13558:
-
Fix Version/s: (was: 2.10)

> GridCacheProcessor should implement better parallelization when restoring 
> partition states on startup
> -
>
> Key: IGNITE-13558
> URL: https://issues.apache.org/jira/browse/IGNITE-13558
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Ivan Bessonov
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> GridCacheProcessor#restorePartitionStates method tries to employ striped pool 
> to restore partition states in parallel but level of parallelization is down 
> only to cache group per thread.
> It is not enough and not utilizes resources effectively in case of one cache 
> group much bigger than the others.
> We need to parallel restore process down to individual partitions to get the 
> most from the available resources and speed up node startup.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-8293) BinaryUtils#isCustomJavaSerialization fails when only readObject is declared in a class

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8293:

Fix Version/s: (was: 2.10)

> BinaryUtils#isCustomJavaSerialization fails when only readObject is declared 
> in a class
> ---
>
> Key: IGNITE-8293
> URL: https://issues.apache.org/jira/browse/IGNITE-8293
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.4
>Reporter: MihkelJ
>Assignee: MihkelJ
>Priority: Minor
>
> Consider this class:
>  
> {code:java}
> public class Test implements Serializable {
> private transient AtomicBoolean dirty = new AtomicBoolean(false);
> private void readObject(java.io.ObjectInputStream in) throws IOException, 
> ClassNotFoundException {
> dirty = new AtomicBoolean(false);
> }
> //methods to check and mark class as dirty
> }{code}
> {{isCustomJavaSerialization}} will get a {{NoSuchMethodException}} when 
> trying to grab the {{writeObject}} method and falsely conclude that Test 
> doesn't use custom serialization.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-8784) Deadlock during simultaneous client reconnect and node stop

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8784:

Fix Version/s: (was: 2.10)

> Deadlock during simultaneous client reconnect and node stop
> ---
>
> Key: IGNITE-8784
> URL: https://issues.apache.org/jira/browse/IGNITE-8784
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Priority: Critical
>
> {noformat}
> [18:48:22,665][ERROR][tcp-client-disco-msg-worker-#467%client%][IgniteKernal%client]
>  Failed to reconnect, will stop node
> class org.apache.ignite.IgniteException: Failed to wait for local node joined 
> event (grid is stopping).
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.localJoin(GridDiscoveryManager.java:2193)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:583)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheSharedContext.onReconnected(GridCacheSharedContext.java:396)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onReconnected(GridCacheProcessor.java:1159)
>   at 
> org.apache.ignite.internal.IgniteKernal.onReconnected(IgniteKernal.java:3915)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:830)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2423)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2402)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:2047)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1896)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1788)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to wait for 
> local node joined event (grid is stopping).
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.onKernalStop0(GridDiscoveryManager.java:1657)
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.onKernalStop(GridManagerAdapter.java:652)
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2218)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2166)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
>   at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
>   at org.apache.ignite.Ignition.stop(Ignition.java:229)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1128)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
>   at 
> org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotNotStableTopologiesTest.afterTest(IgniteDbSnapshotNotStableTopologiesTest.java:250)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
>   at junit.framework.TestCase.runBare(TestCase.java:146)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
>   

[jira] [Updated] (IGNITE-8848) Introduce new split-brain tests when topology is under load

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8848:

Fix Version/s: (was: 2.10)

> Introduce new split-brain tests when topology is under load
> ---
>
> Key: IGNITE-8848
> URL: https://issues.apache.org/jira/browse/IGNITE-8848
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
>
> We should check following cases:
> 1) Primary node of transaction located at a part of a cluster that will 
> survive, while backup doesn't.
> 2) Backup node of transaction located at a part of a cluster that will 
> survive, while primary doesn't.
> 3) A client has a connection to both split-brained parts.
> 4) A client has a connection to only 1 part of a split cluster.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-8785) Node may hang indefinitely in CONNECTING state during cluster segmentation

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-8785:

Fix Version/s: (was: 2.10)

> Node may hang indefinitely in CONNECTING state during cluster segmentation
> --
>
> Key: IGNITE-8785
> URL: https://issues.apache.org/jira/browse/IGNITE-8785
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Priority: Major
>
> Affected test: 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest#testTopologyValidatorWithCacheGroup
> Node hangs with following stacktrace:
> {noformat}
> "grid-starter-testTopologyValidatorWithCacheGroup-22" #117619 prio=5 
> os_prio=0 tid=0x7f17dd19b800 nid=0x304a in Object.wait() 
> [0x7f16b19df000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:931)
>   - locked <0x000705ee4a60> (a java.lang.Object)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:373)
>   at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1948)
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:915)
>   at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1739)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1046)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
>   - locked <0x000705995ec0> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$3.call(GridAbstractTest.java:742)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> It seems that node never receives acknowledgment from coordinator.
> There were some failure before:
> {noformat}
> [org.apache.ignite:ignite-core] [2018-06-10 04:59:18,876][WARN 
> ][grid-starter-testTopologyValidatorWithCacheGroup-22][IgniteCacheTopologySplitAbstractTest$SplitTcpDiscoverySpi]
>  Node has not been connected to topology and will repeat join process. Check 
> remote nodes logs for possible error messages. Note that large topology may 
> require significant time to start. Increase 'TcpDiscoverySpi.networkTimeout' 
> configuration property if getting this message on the starting nodes 
> [networkTimeout=5000]
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IGNITE-13845) Add checkpoint metrics

2020-12-29 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-13845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255882#comment-17255882
 ] 

Maxim Muzafarov commented on IGNITE-13845:
--

[~NSAmelchev] 

Do you need any help here? Can we proceed?

> Add checkpoint metrics
> --
>
> Key: IGNITE-13845
> URL: https://issues.apache.org/jira/browse/IGNITE-13845
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.10
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add last checkpoint duration metrics:
> * beforeLockDuration
> * listenersExecuteDuration
> * lockHoldDuration
> * walCpRecordFsyncDuration
> * writeCheckpointEntryDuration
> * splitAndSortCpPagesDuration
> Add durations histograms:
> * CheckpointBeforeLockHistogram
> * CheckpointLockWaitHistogram
> * CheckpointListenersExecuteHistogram
> * CheckpointMarkHistogram
> * CheckpointLockHoldHistogram
> * CheckpointPagesWriteHistogram
> * CheckpointFsyncHistogram
> * CheckpointWalRecordFsyncHistogram
> * CheckpointWriteEntryHistogram
> * CheckpointSplitAndSortPagesHistogram
> * CheckpointHistogram



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-4554) Optimize integer sets.

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-4554:

Fix Version/s: (was: 2.10)

> Optimize integer sets.
> --
>
> Key: IGNITE-4554
> URL: https://issues.apache.org/jira/browse/IGNITE-4554
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
>
> Ignite has many uses of data structures like Set, IntArray etc.
> This is not most efficient way to represent integer sets. The best way is to 
> use compressed bit sets. This should save a lot of heap space.
> We should optimize integer sets whenever possible.
> The most obvious place to start is GridAffinityAssignment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-12396) [ML] Random Forest generates NaN for a part of models on small datasets

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-12396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-12396:
-
Fix Version/s: (was: 2.10)

> [ML] Random Forest generates NaN for a part of models on small datasets
> ---
>
> Key: IGNITE-12396
> URL: https://issues.apache.org/jira/browse/IGNITE-12396
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Major
>
> @Override public Double predict(Vector features) {
>  double[] predictions = new double[models.size()];
>  for (int i = 0; i < models.size(); i++)
>  predictions[i] = models.get(i).predict(features);
>  return predictionsAggregator.apply(predictions);
> }
>  
> predictionAggreagtor gets a lot of models and part of them returns null and 
> it could be aggregated, first of all handle this in Aggregator (using 
> threshold for amount of broken models before aggregation) also RandomForest 
> trees should return Double.NaN - it should fail or throw message after the 
> training
>  
> I've tested with 100 or 1000 rows and it fails and doesn't fail on 10 000 rows
>  
> RF generates a few models with one LEAF node with empty val (Double.NaN by 
> default)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13774) Create TC suites for release Python Node.js and PHP clients

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13774:
-
Fix Version/s: (was: 2.10)

> Create TC suites for release Python Node.js and PHP clients
> ---
>
> Key: IGNITE-13774
> URL: https://issues.apache.org/jira/browse/IGNITE-13774
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.9
> Environment: Create TC suites for release of new clients
>Reporter: Igor Sapego
>Priority: Major
>
> We now have separate repos for Python, Node.js and PHP thin clients. Need to 
> create a TC suites to release them as a separate packages on Ignite site and 
> in pip, npm and composer.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13679) Entryprocessor cannot be hot deployed properly via UriDeploymentSpi

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13679:
-
Fix Version/s: (was: 2.10)

> Entryprocessor cannot be hot deployed properly via UriDeploymentSpi
> ---
>
> Key: IGNITE-13679
> URL: https://issues.apache.org/jira/browse/IGNITE-13679
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.9
>Reporter: YuJue Li
>Priority: Critical
> Attachments: ignite-deploy.zip
>
>
> Entryprocessor cannot be hot deployed properly via UriDeploymentSpi,the 
> operation steps are as follows:
> 1.put jar in the specified folder of uriList;
> 2.Use example-deploy.xml,start two ignite nodes;
> 3.Use the DeployClient to deploy the service named "deployService";
> 4.Execute the test through ThickClientTest, and the result is correct;
> 5.Modify the code of DeployServiceImpl and DeployEntryProcessor, for example, 
> change "Hello" to "Hi", then repackage it and put it into the specified 
> folder of uriList;
> 6.Redeploy services by RedeployClient;
> 7.Execute the test again through ThickClientTest, and the result is 
> incorrect,we will find that if the Entryprocessor accessed by the service is 
> on another node, the Entryprocessor uses the old version of the class 
> definition.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-7644) Add an utility to export all key-value data from a persisted partition

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-7644:

Fix Version/s: (was: 2.10)

> Add an utility to export all key-value data from a persisted partition
> --
>
> Key: IGNITE-7644
> URL: https://issues.apache.org/jira/browse/IGNITE-7644
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Govorukhin
>Priority: Major
>
> We need an emergency utility analogous to pgdump which will be able to 
> full-scan all PDS partition pages and extract all survived data in some form 
> that later can be uploaded back to Ignite cluster



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-6324) Transactional cache data partially available after crash.

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-6324:

Fix Version/s: (was: 2.10)

> Transactional cache data partially available after crash.
> -
>
> Key: IGNITE-6324
> URL: https://issues.apache.org/jira/browse/IGNITE-6324
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.9, 2.1
>Reporter: Stanilovsky Evgeny
>Priority: Critical
> Attachments: InterruptCommitedThreadTest.java
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If InterruptedException raise in client code during pds store operations we 
> can obtain inconsistent cache after restart. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-13497) [ML] Tutorial examples fails with serialization error

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-13497:
-
Fix Version/s: (was: 2.10)

> [ML] Tutorial examples fails with serialization error
> -
>
> Key: IGNITE-13497
> URL: https://issues.apache.org/jira/browse/IGNITE-13497
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Critical
>
> Cross-Validation uses in interfaces unserializable functions (DoubleConsumers 
> and etc.)
> Adds custom serializable functions and double check-up all public interfaces 
> to find similar problems
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IGNITE-6532) Introduce preallocation in LFS files to avoid high fragmentation on filesystem level

2020-12-29 Thread Maxim Muzafarov (Jira)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-6532:

Fix Version/s: (was: 2.10)

> Introduce preallocation in LFS files to avoid high fragmentation on 
> filesystem level
> 
>
> Key: IGNITE-6532
> URL: https://issues.apache.org/jira/browse/IGNITE-6532
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Ivan Rakov
>Priority: Major
>
> Modern databases (Oracle, MySql) work with storage drive on physical level, 
> creating their own partition table and filesystem.
> Ignite Persistent Store work with regular files. It appends new pages to 
> partition file once new pages are allocated and written on checkpoint. These 
> new pages can form one or several fragments on filesystem level.
> As a result, after weeks of uptime, partition files can contain huge amount 
> of fragments. There were reports about 120 fragments in index.bin file on 
> XFS filesystem. 
> We can work this around by preallocating files in bigger chunks, e.g. 1000 
> pages at a time. On the other hand, early allocation will increase LFS size 
> overhead, so we should consider reasonable heuristic for allocation.
> Allocation should be performed on native level. Just writing a byte at 
> position (file_size + page_size * 1000) won't do it because XFS (and other 
> filesystems as well) has an optimization for that case. Missing range will be 
> just skipped.
> Related article about filesystem internals: 
> https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-deadlock-kmem_alloc/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


  1   2   3   >