[jira] [Comment Edited] (IGNITE-11946) Do not add java.transaction module in Ignite launch scripts
[
https://issues.apache.org/jira/browse/IGNITE-11946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878066#comment-16878066
]
Ivan Pavlukhin edited comment on IGNITE-11946 at 7/6/19 5:14 AM:
-
Removed command line arguments enabling {{java.transaction}} and {{java.corba}}
modules from TC configuration ("Setup additional arguments" step in ["Build
Apache Ignite"|
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite=buildTypeSettings_IgniteTests24Java8=%3Cdefault%3E]).
was (Author: pavlukhin):
Removed command line arguments enabling {{java.transaction}} and {{java.corba}}
module from TC configuration ("Setup additional arguments" step in ["Build
Apache Ignite"|
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite=buildTypeSettings_IgniteTests24Java8=%3Cdefault%3E]).
> Do not add java.transaction module in Ignite launch scripts
> ---
>
> Key: IGNITE-11946
> URL: https://issues.apache.org/jira/browse/IGNITE-11946
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currenlty {{--add-modules=java.transaction}} is used in ignite scripts for
> Java 9 and 10. Most likely we can remove it safely.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879387#comment-16879387
]
Ivan Pavlukhin commented on IGNITE-11685:
-
[~alex_pl], I left one more comment on GitHub. Please check whether it is
relevant. Everything else is fine.
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6877) Improve behaviour for non-correlated subqueries
[ https://issues.apache.org/jira/browse/IGNITE-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879385#comment-16879385 ] Denis Mekhanikov commented on IGNITE-6877: -- No other tickets for this issue have been created yet, but the problem is still present. So, I'm for keeping the ticket open. Feel free to close as a duplicate, when another one is created. > Improve behaviour for non-correlated subqueries > --- > > Key: IGNITE-6877 > URL: https://issues.apache.org/jira/browse/IGNITE-6877 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Alin Andrei Corodescu >Priority: Minor > > Ignite behaves poorly in terms of performance when given queries which > contain IN or = operators followed by a non-correlated subquery. My guess is > that the query is actually run for each row of the table in order to test the > condition. > A possible solution is to store the results of the subquery in a temporary > table, and use it from there. > A workaround at the moment is to use joins instead of IN or = operators, but > this makes the query much more complicated. > Example: > SELECT name > FROM Employees > WHERE age IN (SELECT age FROM Customers) > The performance of this query is very slow for small amounts of data (about > 20 seconds for 4000 rows in each table last time I tried) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879353#comment-16879353
]
Igor Sapego commented on IGNITE-11685:
--
[~alex_pl], I don't. Looks good overall, you may proceed. I was mostly
concerned with protocol changes and possible backward compatibility issues.
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 4h
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879336#comment-16879336
]
Aleksey Plekhanov commented on IGNITE-11685:
[~Pavlukhin], I've checked TC and found one bug, also I've improved some
diagnostic messages (which helps me to find this bug). Now TC looks good. There
are minor fixes in PR, could you please have a look again?
[~isapego], do you have any additional comments? Can I proceed with the merge?
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 4h
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879313#comment-16879313 ] Ivan Pavlukhin commented on IGNITE-11907: - [~dmekhanikov], I prepared a patch and run tests. Could you review? > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[
https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879311#comment-16879311
]
Ignite TC Bot commented on IGNITE-11907:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4265844buildTypeId=IgniteTests24Java8_RunAll]
> Registration of continuous query should fail if nodes don't have remote
> filter class
>
>
> Key: IGNITE-11907
> URL: https://issues.apache.org/jira/browse/IGNITE-11907
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Attachments:
> ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If one of data nodes doesn't have a remote filter class, then registration of
> continuous queries should fail with an exception. Currently nodes fail
> instead.
> Reproducer is attached:
> [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10502) Add a danger block into transactions documentation
[ https://issues.apache.org/jira/browse/IGNITE-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-10502: Assignee: Ilya Kasnacheev (was: Artem Budnikov) > Add a danger block into transactions documentation > -- > > Key: IGNITE-10502 > URL: https://issues.apache.org/jira/browse/IGNITE-10502 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.6 >Reporter: Roman Guseinov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: documentation > > Currently, we can not safely use caches with CacheStore and caches without > this one inside the same transaction. Those types of caches have different > recovery methods and some topology changes can lead inconsistent data: > [https://issues.apache.org/jira/browse/IGNITE-10452|https://issues.apache.org/jira/browse/IGNITE-10452] > It should be mentioned in the documentation to avoid confusing the users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.
[ https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879302#comment-16879302 ] Ivan Fedotov commented on IGNITE-711: - [~ashutak], If you don't mind I will do this ticket - uncomment al mentioned tests. For more information please take a look at the conversation [1]. [1] http://apache-ignite-developers.2346864.n4.nabble.com/Migration-to-JUnit-5-td40907.html > [Java 8 Examples] Need to complete implementation of Java 8 examples. > - > > Key: IGNITE-711 > URL: https://issues.apache.org/jira/browse/IGNITE-711 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Ivan Fedotov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > > There are next examples for java 7, but there are no for java 8. Need to > implement if they are applicable for java 8. > // BasicExamplesSelfTest > - ComputeReducerExample > - ComputeTaskMapExample > - ComputeTaskSplitExample > // CacheExamplesSelfTest: > - IgniteAtomicLongExample.main > - IgniteAtomicReferenceExample.main > - IgniteAtomicSequenceExample.main > - IgniteAtomicStampedExample.main > - IgniteCountDownLatchExample.main > - IgniteQueueExample.main > - IgniteSetExample.main > - CacheDummyStoreExample.main > - CacheQueryExample.main > - CacheTransactionExample.main > - CacheDataStreamerExample.main > - CachePutGetExample.main > - CacheStarSchemaExample.main > - CacheContinuousQueryExample.main > // CheckpointExamplesSelfTest > - ComputeFailoverExample > // ClusterGroupExampleSelfTest > - ClusterGroupExample > // ContinuationExamplesSelfTest > - ComputeFibonacciContinuationExample > // ContinuousMapperExamplesSelfTest > - ComputeContinuousMapperExample > - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample > - DeploymentExamplesSelfTest # testDeploymentExample > // HibernateL2CacheExampleSelfTest > - HibernateL2CacheExample > - IgfsExamplesSelfTest # testIgniteFsApiExample > // LifecycleExamplesSelfTest > - LifecycleExample > - look at MemcacheRestExamplesMultiNodeSelfTest > - MemcacheRestExample > - CreditRiskExample > - SpringBeanExample > - ComputeTaskSplitExample > - ComputeTaskMapExample > Examples should be implemented for java 8 or testing methods should be > removed if examples do not applicable for java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10218) Detecting lost partitions PME phase triggered twice on coordinator
[
https://issues.apache.org/jira/browse/IGNITE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879277#comment-16879277
]
Ivan Rakov commented on IGNITE-10218:
-
[~NSAmelchev], I agree, crd may be null.
[~Denis Chudov], I've merged PR to master with suggested null check.
> Detecting lost partitions PME phase triggered twice on coordinator
> --
>
> Key: IGNITE-10218
> URL: https://issues.apache.org/jira/browse/IGNITE-10218
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> scenarion: 1 server left
> coordinator node seems to detect partition losses twice per exchange
> {noformat}
> [16:54:22,027][INFO][exchange-worker-#66][time] Finished exchange init
> [topVer=AffinityTopologyVersion [topVer=13, minorTopVer=0], crd=true]
> [16:54:22,163][INFO][db-checkpoint-thread-#86][GridCacheDatabaseSharedManager]
> Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
> checkpointLockHoldTime=525ms, reason='timeout']
> [16:54:22,338][INFO][sys-#136][GridDhtPartitionsExchangeFuture] Coordinator
> received single message [ver=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], node=2b69b32f-1bea-4c83-a70d-d7ff8ad7e319, allReceived=false]
> [16:54:22,401][INFO][sys-#137][GridDhtPartitionsExchangeFuture] Coordinator
> received single message [ver=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], node=933628df-5237-435c-81d3-7d4be20d8cea, allReceived=false]
> [16:54:22,405][INFO][sys-#73][GridDhtPartitionsExchangeFuture] Coordinator
> received single message [ver=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], node=549935a6-48b0-47cd-a763-13cef4706960, allReceived=false]
> [16:54:22,413][INFO][sys-#121][GridDhtPartitionsExchangeFuture] Coordinator
> received single message [ver=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], node=fbdde4e1-2422-49af-a0bb-d6797cc723fe, allReceived=false]
> [16:54:22,722][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Coordinator
> received single message [ver=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], node=d67a748d-9c63-4ede-8dae-064b63dd1586, allReceived=true]
> [16:54:23,493][INFO][db-checkpoint-thread-#86][GridCacheDatabaseSharedManager]
> Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
> checkpointLockHoldTime=849ms, reason='timeout']
> [16:54:23,494][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Coordinator
> received all messages, try merge [ver=AffinityTopologyVersion [topVer=13,
> minorTopVer=0]]
> [16:54:23,494][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Exchanges
> merging performed in 0 ms.
> [16:54:23,494][INFO][sys-#122][GridDhtPartitionsExchangeFuture]
> finishExchangeOnCoordinator [topVer=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=13, minorTopVer=0]]
> [16:54:24,223][INFO][sys-#122][CacheAffinitySharedManager] Affinity
> recalculation (on server left) performed in 729 ms.
> [16:54:24,371][INFO][db-checkpoint-thread-#86][GridCacheDatabaseSharedManager]
> Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
> checkpointLockHoldTime=726ms, reason='timeout']
> [16:54:25,146][INFO][db-checkpoint-thread-#86][GridCacheDatabaseSharedManager]
> Skipping checkpoint (no pages were modified) [checkpointLockWait=1ms,
> checkpointLockHoldTime=493ms, reason='timeout']
> [16:54:26,443][INFO][db-checkpoint-thread-#86][GridCacheDatabaseSharedManager]
> Skipping checkpoint (no pages were modified) [checkpointLockWait=8ms,
> checkpointLockHoldTime=776ms, reason='timeout']
> [16:54:26,443][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Affinity
> changes (coordinator) applied in 2949 ms.
> [16:54:26,758][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Partitions
> validation performed in 307 ms.
> [16:54:27,398][INFO][db-checkpoint-thread-#86][GridCacheDatabaseSharedManager]
> Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
> checkpointLockHoldTime=725ms, reason='timeout']
> [16:54:27,646][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Detecting
> lost partitions performed in 887 ms.
> [16:54:28,908][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Preparing
> Full Message performed in 1138 ms.
> [16:54:28,908][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full
> Message performed in 0 ms.
> [16:54:28,908][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full
> Message to all nodes performed in 0 ms.
> [16:54:28,908][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Finish
> exchange future [startVer=AffinityTopologyVersion [topVer=13, minorTopVer=0],
> resVer=AffinityTopologyVersion [topVer=13, minorTopVer=0],
[jira] [Assigned] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.
[ https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-711: --- Assignee: Ivan Fedotov (was: Artem Shutak) > [Java 8 Examples] Need to complete implementation of Java 8 examples. > - > > Key: IGNITE-711 > URL: https://issues.apache.org/jira/browse/IGNITE-711 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Ivan Fedotov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > > There are next examples for java 7, but there are no for java 8. Need to > implement if they are applicable for java 8. > // BasicExamplesSelfTest > - ComputeReducerExample > - ComputeTaskMapExample > - ComputeTaskSplitExample > // CacheExamplesSelfTest: > - IgniteAtomicLongExample.main > - IgniteAtomicReferenceExample.main > - IgniteAtomicSequenceExample.main > - IgniteAtomicStampedExample.main > - IgniteCountDownLatchExample.main > - IgniteQueueExample.main > - IgniteSetExample.main > - CacheDummyStoreExample.main > - CacheQueryExample.main > - CacheTransactionExample.main > - CacheDataStreamerExample.main > - CachePutGetExample.main > - CacheStarSchemaExample.main > - CacheContinuousQueryExample.main > // CheckpointExamplesSelfTest > - ComputeFailoverExample > // ClusterGroupExampleSelfTest > - ClusterGroupExample > // ContinuationExamplesSelfTest > - ComputeFibonacciContinuationExample > // ContinuousMapperExamplesSelfTest > - ComputeContinuousMapperExample > - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample > - DeploymentExamplesSelfTest # testDeploymentExample > // HibernateL2CacheExampleSelfTest > - HibernateL2CacheExample > - IgfsExamplesSelfTest # testIgniteFsApiExample > // LifecycleExamplesSelfTest > - LifecycleExample > - look at MemcacheRestExamplesMultiNodeSelfTest > - MemcacheRestExample > - CreditRiskExample > - SpringBeanExample > - ComputeTaskSplitExample > - ComputeTaskMapExample > Examples should be implemented for java 8 or testing methods should be > removed if examples do not applicable for java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11959) NullPointerException If transaction failed and failure handler doesn't configured explicitly
[
https://issues.apache.org/jira/browse/IGNITE-11959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879265#comment-16879265
]
Ivan Rakov commented on IGNITE-11959:
-
[~ktkale...@gridgain.com], thanks, merged to master.
> NullPointerException If transaction failed and failure handler doesn't
> configured explicitly
>
>
> Key: IGNITE-11959
> URL: https://issues.apache.org/jira/browse/IGNITE-11959
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-9082 was introduced code in IgniteTxAdapter:
> {code:java}
> U.error(log, String.format(fmt, commit, CU.txString(this),
>
> cctx.gridConfig().getFailureHandler().getClass().getSimpleName()), e);
> {code}
> We get NullPointerException, If failureHander doesn't configured explicitly.
> Information about configured failureHandler is printed in FailureProcessor
> logic. I think we could remove failureHandler classname from such log
> messages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879133#comment-16879133 ] Evgenii Zhuravlev commented on IGNITE-11312: [~surajsn], do you plan to implement this fix? I know that community is interested in it, so, if you can't implement it, maybe it makes sense to give an opportunity for someone else to step in and contribute it to the project. > JDBC: Thin driver doesn't reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Suraj Singh >Priority: Major > Labels: newbie > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11859) CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
[
https://issues.apache.org/jira/browse/IGNITE-11859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879120#comment-16879120
]
Kirill Tkalenko commented on IGNITE-11859:
--
[~antonovsergey93] Check Code Style failure - don't contain my changes.
> CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
> -
>
> Key: IGNITE-11859
> URL: https://issues.apache.org/jira/browse/IGNITE-11859
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{parseArgs(Arrays.asList(WAL.text(), WAL_PRINT));}} and
> {{parseArgs(Arrays.asList(WAL.text(), WAL_DELETE));}} should throw
> IllegalArgumentException, but it isn't.
> h2. How to reproduce:
> Replace test to:
> {code:java}
> /**
> * Test that experimental command (i.e. WAL command) is disabled by
> default.
> */
> @Test
> public void testExperimentalCommandIsDisabled() {
> System.clearProperty(IGNITE_ENABLE_EXPERIMENTAL_COMMAND);
> GridTestUtils.assertThrows(null,
> ()->parseArgs(Arrays.asList(WAL.text(), WAL_PRINT)),
> IllegalArgumentException.class, null);
> GridTestUtils.assertThrows(null,
> ()->parseArgs(Arrays.asList(WAL.text(), WAL_DELETE)),
> IllegalArgumentException.class, null);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11584) Implement batch insertion of new cache entries in FreeList to improve rebalancing
[ https://issues.apache.org/jira/browse/IGNITE-11584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879101#comment-16879101 ] Anton Vinogradov commented on IGNITE-11584: --- [~Mmuzaf], Started the review. Will communicate [~xtern] privately to increase the review speed. Once we'll finish, final review from expert will be required. > Implement batch insertion of new cache entries in FreeList to improve > rebalancing > - > > Key: IGNITE-11584 > URL: https://issues.apache.org/jira/browse/IGNITE-11584 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7 >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-32 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Main goals: > * Implement batch insert operation into FreeList - insert several data rows > at once > * Use batch insertion in the preloader > > Implementation notes: > # Preloader cannot lock multiple cache entries at once, because this may > lead to a deadlock with concurrent batch updates. Therefore, it pre-creates > batch of data rows in the page memory, and then sequentially initializes the > cache entries one by one. > # Batch writing of data rows into data pages uses the free list as usual > because other approaches increase memory fragmentation (for example, using > only "reuse" or "most free" buckets). > # Eviction tracker assumes that only data pages with "heads" of fragmented > data row are tracked, so all other fragments of large data row should be > written on separate data pages (without other data rows which may cause page > tracking). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
[
https://issues.apache.org/jira/browse/IGNITE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879090#comment-16879090
]
Ivan Pavlukhin commented on IGNITE-11685:
-
[~alex_pl], looks fine to me. Thank you!
> Java thin client: Handle multiple async requests in parallel
>
>
> Key: IGNITE-11685
> URL: https://issues.apache.org/jira/browse/IGNITE-11685
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 4h
> Remaining Estimate: 0h
>
> In the current implementation {{ReliableChannel}} uses an exclusive lock to
> send a request and waits for response synchronously. In this implementation,
> there are no benefits of using multiple threads. To improve throughput and
> latency we can implement async request/response processing on the client
> side, since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11859) CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
[
https://issues.apache.org/jira/browse/IGNITE-11859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879076#comment-16879076
]
Sergey Antonov commented on IGNITE-11859:
-
[~ktkale...@gridgain.com] Changes looks good for me. Please recheck, that
{{Check Code Style}} failure doesn't relates with your changes.
> CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
> -
>
> Key: IGNITE-11859
> URL: https://issues.apache.org/jira/browse/IGNITE-11859
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{parseArgs(Arrays.asList(WAL.text(), WAL_PRINT));}} and
> {{parseArgs(Arrays.asList(WAL.text(), WAL_DELETE));}} should throw
> IllegalArgumentException, but it isn't.
> h2. How to reproduce:
> Replace test to:
> {code:java}
> /**
> * Test that experimental command (i.e. WAL command) is disabled by
> default.
> */
> @Test
> public void testExperimentalCommandIsDisabled() {
> System.clearProperty(IGNITE_ENABLE_EXPERIMENTAL_COMMAND);
> GridTestUtils.assertThrows(null,
> ()->parseArgs(Arrays.asList(WAL.text(), WAL_PRINT)),
> IllegalArgumentException.class, null);
> GridTestUtils.assertThrows(null,
> ()->parseArgs(Arrays.asList(WAL.text(), WAL_DELETE)),
> IllegalArgumentException.class, null);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
[
https://issues.apache.org/jira/browse/IGNITE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879060#comment-16879060
]
Anton Vinogradov commented on IGNITE-3195:
--
Folks, we have a lot of problems with rebalance
1) uncontrolled rebalance thread pool size
2) during long rebalance possible situation that some threads do nothing but
some have a long queue
3) code looks bad and should be refactored (simplified!), a see a lot of things
checked 2+ times at different places, some check and actions are useless.
Currently I'm in refactoring stage. Just removed 1/2 of code and now it able to
understand how it works :)
> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-16
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Presently it's considered that the maximum number of threads that has to
> process all demand and supply messages coming from all the nodes must not be
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages,
> that correspond to a particular topic, are processed in parallel for
> different nodes. Refer to the implementation of
> {{GridIoManager.processOrderedMessage}} to see that for every topic there
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2456)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1179)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1148)
> 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)
> {noformat}
> All this means that in fact the number of threads that will be busy with
> replication activity will be equal to
> {{IgniteConfiguration.rebalanceThreadPoolSize}} x
> number_of_nodes_participated_in_rebalancing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
[
https://issues.apache.org/jira/browse/IGNITE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879031#comment-16879031
]
Stanilovsky Evgeny commented on IGNITE-3195:
look like we clash the same problem on blt change:
{code:java}
2019-07-04 06:29:03.649[WARN
][sys-#328%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#328%DPL_GRID%DplGridNodeName% for timeout(ms)=16335
2019-07-04 06:29:03.649[WARN
][sys-#326%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#326%DPL_GRID%DplGridNodeName% for timeout(ms)=13438
2019-07-04 06:29:03.649[WARN
][sys-#277%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#277%DPL_GRID%DplGridNodeName% for timeout(ms)=11609
2019-07-04 06:29:03.649[WARN
][sys-#331%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#331%DPL_GRID%DplGridNodeName% for timeout(ms)=18009
2019-07-04 06:29:03.649[WARN
][sys-#321%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#321%DPL_GRID%DplGridNodeName% for timeout(ms)=15557
2019-07-04 06:29:03.650[WARN
][sys-#307%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#307%DPL_GRID%DplGridNodeName% for timeout(ms)=27938
2019-07-04 06:29:03.649[WARN
][sys-#316%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#316%DPL_GRID%DplGridNodeName% for timeout(ms)=12189
2019-07-04 06:29:03.649[WARN
][sys-#311%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#311%DPL_GRID%DplGridNodeName% for timeout(ms)=11056
2019-07-04 06:29:03.650[WARN
][sys-#295%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#295%DPL_GRID%DplGridNodeName% for timeout(ms)=20848
2019-07-04 06:29:03.649[WARN
][sys-#290%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#290%DPL_GRID%DplGridNodeName% for timeout(ms)=14816
2019-07-04 06:29:03.649[WARN
][sys-#332%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#332%DPL_GRID%DplGridNodeName% for timeout(ms)=14110
2019-07-04 06:29:03.649[WARN
][sys-#298%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#298%DPL_GRID%DplGridNodeName% for timeout(ms)=10028
2019-07-04 06:29:03.650[WARN
][sys-#304%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#304%DPL_GRID%DplGridNodeName% for timeout(ms)=19855
2019-07-04 06:29:03.650[WARN
][sys-#331%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
Parking thread=sys-#331%DPL_GRID%DplGridNodeName% for timeout(ms)=41277
... and so on
{code}
> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-16
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Presently it's considered that the maximum number of threads that has to
> process all demand and supply messages coming from all the nodes must not be
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages,
> that correspond to a particular topic, are processed in parallel for
> different nodes. Refer to the implementation of
> {{GridIoManager.processOrderedMessage}} to see that for every topic there
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
> at
>
[jira] [Commented] (IGNITE-11859) CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
[
https://issues.apache.org/jira/browse/IGNITE-11859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879008#comment-16879008
]
Ignite TC Bot commented on IGNITE-11859:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4263818]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4263819buildTypeId=IgniteTests24Java8_RunAll]
> CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
> -
>
> Key: IGNITE-11859
> URL: https://issues.apache.org/jira/browse/IGNITE-11859
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{parseArgs(Arrays.asList(WAL.text(), WAL_PRINT));}} and
> {{parseArgs(Arrays.asList(WAL.text(), WAL_DELETE));}} should throw
> IllegalArgumentException, but it isn't.
> h2. How to reproduce:
> Replace test to:
> {code:java}
> /**
> * Test that experimental command (i.e. WAL command) is disabled by
> default.
> */
> @Test
> public void testExperimentalCommandIsDisabled() {
> System.clearProperty(IGNITE_ENABLE_EXPERIMENTAL_COMMAND);
> GridTestUtils.assertThrows(null,
> ()->parseArgs(Arrays.asList(WAL.text(), WAL_PRINT)),
> IllegalArgumentException.class, null);
> GridTestUtils.assertThrows(null,
> ()->parseArgs(Arrays.asList(WAL.text(), WAL_DELETE)),
> IllegalArgumentException.class, null);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
