[jira] [Commented] (IGNITE-11926) [IEP-35] Migrage GridJobMetricsProcessor
[ https://issues.apache.org/jira/browse/IGNITE-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872945#comment-16872945 ] Aleksey Plekhanov commented on IGNITE-11926: [~NIzhikov], looks good to me. > [IEP-35] Migrage GridJobMetricsProcessor > > > Key: IGNITE-11926 > URL: https://issues.apache.org/jira/browse/IGNITE-11926 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Time Spent: 2h 40m > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `GridJobMetricsProcessor` to > the new metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10019) Documentation: partition preloading
[ https://issues.apache.org/jira/browse/IGNITE-10019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872778#comment-16872778 ] Garrett commented on IGNITE-10019: -- We need to add the "Docfeedback" label to this issue. I don't have permission to add labels... > Documentation: partition preloading > --- > > Key: IGNITE-10019 > URL: https://issues.apache.org/jira/browse/IGNITE-10019 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexei Scherbakov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > > We have to add documentation for partition preloading feature: > IgniteCache.preloadPartition -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11942) IGFS and Hadoop Accelerator Discontinuation
Denis Magda created IGNITE-11942: Summary: IGFS and Hadoop Accelerator Discontinuation Key: IGNITE-11942 URL: https://issues.apache.org/jira/browse/IGNITE-11942 Project: Ignite Issue Type: Task Reporter: Denis Magda Fix For: 2.8 The community has voted for the following decision: * IGFS and In-Memory Hadoop Accelerator components are to be discontinued and no longer supported by the community * The existing source code of IGFS and In-Memory Hadoop Accelerator is to be removed from Ignite master. Before that, a special branch like "ignite-igfs-and-hadoop-accelerator" to be forked off the master in order to preserve the sources in Git history for those who might need it. The voting thread: http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42405.html Once the changes are made for Ignite 2.8, please contact Denis Magda to update a public documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8873) Optimize cache scans with enabled persistence.
[ https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872682#comment-16872682 ] Alexei Scherbakov commented on IGNITE-8873: --- [~dmagda] This method was added to address exactly the case where huge (tens of terabytes) cache have to be efficiently fully scanned. It was already successfully used in production by some Ignite users as far as I know. The main idea behind per partition preloading API same as for other methods working with partitions: affinity run/call, scan by partition, SQL query by partition(s). I suggest to keep this method for advanced use cases and add some more "high level" APIs like you have proposed. > Optimize cache scans with enabled persistence. > -- > > Key: IGNITE-8873 > URL: https://issues.apache.org/jira/browse/IGNITE-8873 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > > Currently cache scans with enabled persistence involve link resolution, which > can lead to radom disk access resulting in bad performace on SAS disks. > One possibility is to preload cache data pages to remove slow random disk > access. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11926) [IEP-35] Migrage GridJobMetricsProcessor
[
https://issues.apache.org/jira/browse/IGNITE-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872512#comment-16872512
]
Ignite TC Bot commented on IGNITE-11926:
{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=4197934&buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-35] Migrage GridJobMetricsProcessor
>
>
> Key: IGNITE-11926
> URL: https://issues.apache.org/jira/browse/IGNITE-11926
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Time Spent: 2h
> Remaining Estimate: 0h
>
> After merging of IGNITE-11848 we should migrate `GridJobMetricsProcessor` to
> the new metric framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11869) Rework control.sh tests structure
[ https://issues.apache.org/jira/browse/IGNITE-11869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872479#comment-16872479 ] Sergey Antonov commented on IGNITE-11869: - [~DmitriyGovorukhin] Please review changes again, please! > Rework control.sh tests structure > - > > Key: IGNITE-11869 > URL: https://issues.apache.org/jira/browse/IGNITE-11869 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > GridCommandHandlerIndexingTest. extends GridCommandHandlerTest. It's bad > design. We should create common abstract test class and extend it in > GridCommandHandlerIndexingTest and GridCommandHandlerTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11869) Rework control.sh tests structure
[
https://issues.apache.org/jira/browse/IGNITE-11869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872426#comment-16872426
]
Ignite TC Bot commented on IGNITE-11869:
{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=4197352&buildTypeId=IgniteTests24Java8_RunAll]
> Rework control.sh tests structure
> -
>
> Key: IGNITE-11869
> URL: https://issues.apache.org/jira/browse/IGNITE-11869
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridCommandHandlerIndexingTest. extends GridCommandHandlerTest. It's bad
> design. We should create common abstract test class and extend it in
> GridCommandHandlerIndexingTest and GridCommandHandlerTest.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11857) Investigate performance drop after IGNITE-10078
[
https://issues.apache.org/jira/browse/IGNITE-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872422#comment-16872422
]
Aleksey Plekhanov commented on IGNITE-11857:
I still can't reproduce a performance drop on my environment. Maximum I can get
is 1% drop on introduced for not MVCC transactions method
{{IgniteTxHandler#applyPartitionsUpdatesCounters}}.
So, I've tried to optimize {{PartitionTxUpdateCounterImpl#update(long, long)}}
and now this method about 1.3-1.5 times faster (according to microbenchmarks).
This method is synchronized. I've tried to get rid of the synchronized block
and preserve thread safety but this doesn't give any performance boost while
bringing extra complexity to the code. Seems like contention is not a problem
here.
Also, I've fixed some usages of write entries and read entries collections.
These collections are predicate views and {{F.isEmpty()}} on a collection leads
to undesirable iteration over collection sometimes.
But both these optimizations give no more than 0.5% on my environment.
[~ustas] can you check PR [1] against commit b87bea8 on your environment?
[~ascherbakov] cant you review partition update counter fix?
[1]: [https://github.com/apache/ignite/pull/6640]
> Investigate performance drop after IGNITE-10078
> ---
>
> Key: IGNITE-11857
> URL: https://issues.apache.org/jira/browse/IGNITE-11857
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Attachments: ignite-config.xml,
> run.properties.tx-optimistic-put-b-backup
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-10078 yardstick tests show performance drop up to 8% in some
> scenarios:
> * tx-optim-repRead-put-get
> * tx-optimistic-put
> * tx-putAll
> Partially this is due new update counter implementation, but not only.
> Investigation is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11917) Row count [select count(*) from table] not matching with the actual row count present in the table
[ https://issues.apache.org/jira/browse/IGNITE-11917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shivakumar updated IGNITE-11917: Description: To reproduce, create a sample table using JDBC endpoint: CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person, KEY_TYPE=personKey,VALUE_TYPE=person"; and configure cache expiry policy as below with above cache configuration records will start expiring at the end of 10 minute, batch insert around 1 records to the table and after 10 minute records will start expiring but after some time check the records count [select count(*) from person] most of the time it will show some non zero number but if rows are selected instead of count to see the actual data with [select * from person] there will be zero rows. why count is not becoming zero even though there is no data (rows) in the table ? 0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from person; ++ |COUNT(*)| ++ |70| ++ 1 row selected (0.004 seconds) 0: jdbc:ignite:thin://10.*.*.*:10800> select * from person; +--+--++++- |ID|BIRTHTIME|NAME| +--+--++++- +--+--++++- No rows selected (0.015 seconds) 0: jdbc:ignite:thin://10.*.*.*:10800> was: To reproduce, create a sample table using JDBC endpoint: CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person, KEY_TYPE=personKey,VALUE_TYPE=person"; and configure cache expiry policy as below with above cache configuration records will start expiring at the end of 10 minute, batch insert around 1 records to the table and after 10 minute records will start expiring but after some time check the records count [select count(*) from person] most of the time it will show some non zero number but if rows are selected instead of count to see the actual data with [select * from person] there will be zero rows. why count is not becoming zero even though there are now data (rows) in the table ? 0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from person; ++ |COUNT(*)| ++ |70| ++ 1 row selected (0.004 seconds) 0: jdbc:ignite:thin://10.*.*.*:10800> select * from person; +-+---++++- |ID|BIRTHTIME|NAME| +-+---++++- +-+---++++- No rows selected (0.015 seconds) 0: jdbc:ignite:thin://10.*.*.*:10800> > Row count [select count(*) from table] not matching with the actual row count > present in the table > --- > > Key: IGNITE-11917 > URL: https://issues.apache.org/jira/browse/IGNITE-11917 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: shivakumar >Assignee: Evgeniy Rudenko >Priority: Major > > To reproduce, create a sample table using JDBC endpoint: > CREATE TABLE person(Id VARCHAR, birthTime TIMESTAMP, name VARCHAR, PRIMARY > KEY(Id)) WITH "TEMPLATE=templateEternal,CACHE_NAME=person, > KEY_TYPE=personKey,VALUE_TYPE=person"; > > and configure cache expiry policy as below > > > class="org.apache.ignite.configuration.CacheConfiguration"> > > > > > > factory-method="factoryOf"> > > > > > > > > > > > > with above cache configuration records will start expiring at the end of 10 > minute, batch insert around 1 records to the table and after 10 minute > records will start expiring but after some time check the records count > [select count(*) from person] most of the time it will show some non zero > number but if ro
[jira] [Updated] (IGNITE-11844) Should to filtered indexes by cache name instead of validate all caches in group
[ https://issues.apache.org/jira/browse/IGNITE-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kalinin updated IGNITE-11844: Reviewer: Dmitriy Govorukhin (was: Alexey Goncharuk) > Should to filtered indexes by cache name instead of validate all caches in > group > > > Key: IGNITE-11844 > URL: https://issues.apache.org/jira/browse/IGNITE-11844 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Andrey Kalinin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > control.sh utility method validate_indexes checks all indexes of all caches > in group. Just do specify one caches (from generic group) in caches list, > then all indexes from all caches (that group) will be start to validate and > this can consume more time, than checks indexes only specified caches. > Will be correct to validate only indexes of specified caches, for the purpose > need to filtered caches, by list from parameters, in shared group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler
[
https://issues.apache.org/jira/browse/IGNITE-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-11914:
--
Assignee: Ivan Bessonov
> Failures to deserialize discovery data should be handled by a failure handler
> -
>
> Key: IGNITE-11914
> URL: https://issues.apache.org/jira/browse/IGNITE-11914
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Denis Mekhanikov
>Assignee: Ivan Bessonov
>Priority: Major
> Attachments: DiscoveryDataDeserializationFailureHanderTest.java
>
>
> When a node during join receives a discovery data packet, that it cannot
> deserialize, then this error is printed to log and not handled in any way. It
> leads to swallowing potentially important failures.
> For example, a failure to deserialize a continuous query remote filter should
> be propagated to a failure handler, but it doesn't happen. Test is attached.
> Error message:
> {noformat}
> Failed to unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2282)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2206)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at java.io.ObjectInputStream.
[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&focusedCommentId=16872184#comment-16872184 ] Ivan Pavlukhin commented on IGNITE-11907: - There are following cases: 1. A query is registered (for a first time) and some of nodes does not have needed classes. 2. A new node without needed classes tries to join a topology. Affinity nodes and node filter should be taken into account. > 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 > > > 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-11940) MVCC SysPropWalDeltaConsistencyTest.testPutRemoveMultinode fails frequently
[
https://issues.apache.org/jira/browse/IGNITE-11940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872129#comment-16872129
]
Ignite TC Bot commented on IGNITE-11940:
{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=4189363&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC SysPropWalDeltaConsistencyTest.testPutRemoveMultinode fails frequently
> ---
>
> Key: IGNITE-11940
> URL: https://issues.apache.org/jira/browse/IGNITE-11940
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [SysPropWalDeltaConsistencyTest.testPutRemoveMultinode|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=8000156635398196642&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=__all_branches__&itemsCount=50]
> fails frequently in MVCC runs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
