[jira] [Assigned] (IGNITE-8987) Ignite hangs during getting of atomic structure after autoactivation
[ https://issues.apache.org/jira/browse/IGNITE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan reassigned IGNITE-8987: - Assignee: Alexey Goncharuk > Ignite hangs during getting of atomic structure after autoactivation > > > Key: IGNITE-8987 > URL: https://issues.apache.org/jira/browse/IGNITE-8987 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > I investigate the use cases with autoactivation and creating of the > IgniteAtomicSequence. It hangs on awaitInitialization() method in case if it > called after the last node from BLT was started. > Steps to reproduce: > First iteration: > > Do next in one thread: > 1)Start server 1 > 2)Start server 2 > 3)Activate the cluster > 4)Create the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > atomicConfiguration, > 10, > true); > Second iteration: > 1)Start server 1 > 2)Start server 2 (Autoactivation will be started) > 3)Get the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > 10, > true); //could be false because TestName was already created in iteration 1 > In this case, we hang in awaitInitialization() method in > DataStructureProcessor.getAtomic() method. > In case if I added some sleep timeout between step 2 and 3 in the second > iteration then everything was ok. Looks like we have some race here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9156) SQL: Impossible to specify equality condition on sub-select field
[
https://issues.apache.org/jira/browse/IGNITE-9156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan reassigned IGNITE-9156:
-
Assignee: Vladimir Ozerov
> SQL: Impossible to specify equality condition on sub-select field
> -
>
> Key: IGNITE-9156
> URL: https://issues.apache.org/jira/browse/IGNITE-9156
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.7
>
>
> Execution of the following sequence of SQL statements leads to an exception:
> {code:sql}
> CREATE TABLE PEOPLE (id int PRIMARY KEY, name varchar);
> INSERT INTO PEOPLE(id, name) VALUES(1, 'Mike');
> SELECT * FROM (SELECT * FROM People p) tmp WHERE tmp.name='Mike';{code}
> Exception:
> {noformat}
> java.lang.ClassCastException: org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2340)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2272)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2254)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQueryModel(GridSqlQuerySplitter.java:1227)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:306)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:224)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.split(IgniteH2Indexing.java:1991)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1953)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1702)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2107)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2102)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2650)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2116)
> ~[classes/:?]
> ... 12 more
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9156) SQL: Impossible to specify equality condition on sub-select field
[
https://issues.apache.org/jira/browse/IGNITE-9156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-9156:
--
Priority: Critical (was: Major)
> SQL: Impossible to specify equality condition on sub-select field
> -
>
> Key: IGNITE-9156
> URL: https://issues.apache.org/jira/browse/IGNITE-9156
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Critical
> Fix For: 2.7
>
>
> Execution of the following sequence of SQL statements leads to an exception:
> {code:sql}
> CREATE TABLE PEOPLE (id int PRIMARY KEY, name varchar);
> INSERT INTO PEOPLE(id, name) VALUES(1, 'Mike');
> SELECT * FROM (SELECT * FROM People p) tmp WHERE tmp.name='Mike';{code}
> Exception:
> {noformat}
> java.lang.ClassCastException: org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2340)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2272)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2254)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQueryModel(GridSqlQuerySplitter.java:1227)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:306)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:224)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.split(IgniteH2Indexing.java:1991)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1953)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1702)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2107)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2102)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2650)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2116)
> ~[classes/:?]
> ... 12 more
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9156) SQL: Impossible to specify equality condition on sub-select field
[
https://issues.apache.org/jira/browse/IGNITE-9156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-9156:
--
Fix Version/s: 2.7
> SQL: Impossible to specify equality condition on sub-select field
> -
>
> Key: IGNITE-9156
> URL: https://issues.apache.org/jira/browse/IGNITE-9156
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Major
> Fix For: 2.7
>
>
> Execution of the following sequence of SQL statements leads to an exception:
> {code:sql}
> CREATE TABLE PEOPLE (id int PRIMARY KEY, name varchar);
> INSERT INTO PEOPLE(id, name) VALUES(1, 'Mike');
> SELECT * FROM (SELECT * FROM People p) tmp WHERE tmp.name='Mike';{code}
> Exception:
> {noformat}
> java.lang.ClassCastException: org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2340)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2272)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2254)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQueryModel(GridSqlQuerySplitter.java:1227)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:306)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:224)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.split(IgniteH2Indexing.java:1991)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1953)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1702)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2107)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2102)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2650)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2116)
> ~[classes/:?]
> ... 12 more
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-5103:
--
Priority: Blocker (was: Critical)
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9178) Partition lost event are not triggered if multiple nodes left cluster
[ https://issues.apache.org/jira/browse/IGNITE-9178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-9178: -- Fix Version/s: 2.7 > Partition lost event are not triggered if multiple nodes left cluster > - > > Key: IGNITE-9178 > URL: https://issues.apache.org/jira/browse/IGNITE-9178 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Blocker > Fix For: 2.7 > > > If multiple nodes left cluster simultaneously, left partitions are removed > from GridDhtPartitionTopologyImpl#node2part without adding to leftNode2Part > in GridDhtPartitionTopologyImpl#update method. > Thus GridDhtPartitionTopologyImpl#detectLostPartitions can't detect lost > partitions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9178) Partition lost event are not triggered if multiple nodes left cluster
[ https://issues.apache.org/jira/browse/IGNITE-9178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-9178: -- Priority: Blocker (was: Critical) > Partition lost event are not triggered if multiple nodes left cluster > - > > Key: IGNITE-9178 > URL: https://issues.apache.org/jira/browse/IGNITE-9178 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Blocker > Fix For: 2.7 > > > If multiple nodes left cluster simultaneously, left partitions are removed > from GridDhtPartitionTopologyImpl#node2part without adding to leftNode2Part > in GridDhtPartitionTopologyImpl#update method. > Thus GridDhtPartitionTopologyImpl#detectLostPartitions can't detect lost > partitions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-9068:
--
Priority: Blocker (was: Critical)
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Blocker
> Labels: test
> Fix For: 2.7
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
>
[jira] [Commented] (IGNITE-9146) Analyse and improve code coverage in ML module
[
https://issues.apache.org/jira/browse/IGNITE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568663#comment-16568663
]
Oleg Ignatenko commented on IGNITE-9146:
Further study of coverage reports revealed some dead code that needs to be
removed:
- class {{SmallTrainingDatasetSizeException}}. It was introduced per
IGNITE-6880 but the code that used this class was later changed to go without
it per IGNITE-7702
- class {{math.Precision}}. It was introduced (adopted from apache commons
math) per IGNITE-5012 but in later changes turned out of extremely low demand
(as of now only use is a private constant in {{AbstractLSQR}}). Per discussion
with [~amalykh] who is most involved in this code it is better to remove. (to
avoid confusion, note that there is another class with same name but in another
package: {{selection.scoring.metric.Precision}} - that one is to be kept)
> Analyse and improve code coverage in ML module
> --
>
> Key: IGNITE-9146
> URL: https://issues.apache.org/jira/browse/IGNITE-9146
> Project: Ignite
> Issue Type: Task
> Components: ml
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: 20180731-ml-coverage.zip
>
>
> Run code coverage analysis, study results and add missing tests where needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9178) Partition lost event are not triggered if multiple nodes left cluster
[ https://issues.apache.org/jira/browse/IGNITE-9178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Gerus reassigned IGNITE-9178: --- Assignee: Pavel Vinokurov > Partition lost event are not triggered if multiple nodes left cluster > - > > Key: IGNITE-9178 > URL: https://issues.apache.org/jira/browse/IGNITE-9178 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > If multiple nodes left cluster simultaneously, left partitions are removed > from GridDhtPartitionTopologyImpl#node2part without adding to leftNode2Part > in GridDhtPartitionTopologyImpl#update method. > Thus GridDhtPartitionTopologyImpl#detectLostPartitions can't detect lost > partitions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Gerus updated IGNITE-5103:
Priority: Critical (was: Major)
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9178) Partition lost event are not triggered if multiple nodes left cluster
[ https://issues.apache.org/jira/browse/IGNITE-9178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Gerus updated IGNITE-9178: Priority: Critical (was: Major) > Partition lost event are not triggered if multiple nodes left cluster > - > > Key: IGNITE-9178 > URL: https://issues.apache.org/jira/browse/IGNITE-9178 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Critical > > If multiple nodes left cluster simultaneously, left partitions are removed > from GridDhtPartitionTopologyImpl#node2part without adding to leftNode2Part > in GridDhtPartitionTopologyImpl#update method. > Thus GridDhtPartitionTopologyImpl#detectLostPartitions can't detect lost > partitions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Gerus updated IGNITE-9068:
Priority: Critical (was: Major)
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Critical
> Labels: test
> Fix For: 2.7
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
> at
>
[jira] [Commented] (IGNITE-9186) Datastreamer may ignores perNodeBuffer size unexpectedly.
[ https://issues.apache.org/jira/browse/IGNITE-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568571#comment-16568571 ] ASF GitHub Bot commented on IGNITE-9186: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/4484 IGNITE-9186: Omit datastreamer per-thread buffers for already batched. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9186 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4484.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4484 commit 3fc53117e648593fbbe8ab512ced01b2c14ef267 Author: Andrey V. Mashenkov Date: 2018-08-03T17:54:32Z IGNITE-9186: Omit datastreamer per-thread buffers for already batched data. > Datastreamer may ignores perNodeBuffer size unexpectedly. > - > > Key: IGNITE-9186 > URL: https://issues.apache.org/jira/browse/IGNITE-9186 > Project: Ignite > Issue Type: Improvement > Components: streaming >Reporter: Andrew Mashenkov >Assignee: Igor Seliverstov >Priority: Major > > Looks like we have to omit per-thread buffer for batches that are passed to > data streamer. > Large per-thread buffer size may have negative affect on latency in some > cases (small batch or small per-node buffer size). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9186) Datastreamer may ignores perNodeBuffer size unexpectedly.
[ https://issues.apache.org/jira/browse/IGNITE-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-9186: Assignee: Igor Seliverstov > Datastreamer may ignores perNodeBuffer size unexpectedly. > - > > Key: IGNITE-9186 > URL: https://issues.apache.org/jira/browse/IGNITE-9186 > Project: Ignite > Issue Type: Improvement > Components: streaming >Reporter: Andrew Mashenkov >Assignee: Igor Seliverstov >Priority: Major > > Looks like we have to omit per-thread buffer for batches that are passed to > data streamer. > Large per-thread buffer size may have negative affect on latency in some > cases (small batch or small per-node buffer size). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9186) Datastreamer may ignores perNodeBuffer size unexpectedly.
Andrew Mashenkov created IGNITE-9186: Summary: Datastreamer may ignores perNodeBuffer size unexpectedly. Key: IGNITE-9186 URL: https://issues.apache.org/jira/browse/IGNITE-9186 Project: Ignite Issue Type: Improvement Components: streaming Reporter: Andrew Mashenkov Looks like we have to omit per-thread buffer for batches that are passed to data streamer. Large per-thread buffer size may have negative affect on latency in some cases (small batch or small per-node buffer size). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9185) Collect and check update counters visited during WAL rebalance
[ https://issues.apache.org/jira/browse/IGNITE-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568543#comment-16568543 ] Maxim Muzafarov commented on IGNITE-9185: - [~Jokser], May be we can merge with this task for printing debug info? -- [IGNITE-9119 - Missed dumpDebugInfo for rebalance|https://issues.apache.org/jira/browse/IGNITE-9119] > Collect and check update counters visited during WAL rebalance > -- > > Key: IGNITE-9185 > URL: https://issues.apache.org/jira/browse/IGNITE-9185 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Critical > Fix For: 2.7 > > > Currently we don't check what update counters we visit during WAL iteration > and what data we send to a demander node. There can be situation, that we met > last requested update counter in WAL and stop rebalance process, while due to > possible DataRecord's reordering we miss some updates after. > If rebalance process breaks due to end of WAL, but not all data records were > visit, we can easily check what records are missed, cancel rebalance and > print useful information to log for further debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9044) Update scala dependency version in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568534#comment-16568534 ] Dmitriy Pavlov edited comment on IGNITE-9044 at 8/3/18 5:52 PM: Changes look good to me. But test RunAll has a couple of suspicious failures, including timeouts. I would like to be completely sure there is no failures, so I've retriggered failed builds. [~kuaw26] could you please take a look to changes? was (Author: dpavlov): Changes look good to me. But test RunAll has a couple of suspicious failures, including timeouts. I would like to be completely sure there is no failures, so I've retriggered failed builds. [~kuaw26] could you please take a look? > Update scala dependency version in Apache Ignite > > > Key: IGNITE-9044 > URL: https://issues.apache.org/jira/browse/IGNITE-9044 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Nikolai Kulagin >Priority: Major > Fix For: 2.7 > > > *ignite-scalar* > scala.library.version=2.11.8, need to be at least 2.11.12 or newer. > *ignite-scalar_2.10* > scala210.library.version 2.10.6, need to be at least 2.10.7, probably newer > *visor 2.10* > scala210.jline.version = 2.10.4 , need to be at least 2.10.7, probably newer > Probably impact would be wider. > We need at least run run-all, local build.sh and optionally release candate > step on TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9044) Update scala dependency version in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568534#comment-16568534 ] Dmitriy Pavlov commented on IGNITE-9044: Changes look good to me. But test RunAll has a couple of suspicious failures, including timeouts. I would like to be completely sure there is no failures, so I've retriggered failed builds. [~kuaw26] could you please take a look? > Update scala dependency version in Apache Ignite > > > Key: IGNITE-9044 > URL: https://issues.apache.org/jira/browse/IGNITE-9044 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Nikolai Kulagin >Priority: Major > Fix For: 2.7 > > > *ignite-scalar* > scala.library.version=2.11.8, need to be at least 2.11.12 or newer. > *ignite-scalar_2.10* > scala210.library.version 2.10.6, need to be at least 2.10.7, probably newer > *visor 2.10* > scala210.jline.version = 2.10.4 , need to be at least 2.10.7, probably newer > Probably impact would be wider. > We need at least run run-all, local build.sh and optionally release candate > step on TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Gerus updated IGNITE-9184: Ignite Flags: (was: Docs Required) > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Dmitriy Govorukhin >Priority: Blocker > Fix For: 2.7 > > Attachments: StressTest.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Gerus reassigned IGNITE-9184: --- Assignee: Dmitriy Govorukhin > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Dmitriy Govorukhin >Priority: Blocker > Fix For: 2.7 > > Attachments: StressTest.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Gerus updated IGNITE-9184: Priority: Blocker (was: Critical) > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.7 > > Attachments: StressTest.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9185) Collect and check update counters visited during WAL rebalance
Pavel Kovalenko created IGNITE-9185: --- Summary: Collect and check update counters visited during WAL rebalance Key: IGNITE-9185 URL: https://issues.apache.org/jira/browse/IGNITE-9185 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.7 Currently we don't check what update counters we visit during WAL iteration and what data we send to a demander node. There can be situation, that we met last requested update counter in WAL and stop rebalance process, while due to possible DataRecord's reordering we miss some updates after. If rebalance process breaks due to end of WAL, but not all data records were visit, we can easily check what records are missed, cancel rebalance and print useful information to log for further debug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject
[
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568353#comment-16568353
]
ASF GitHub Bot commented on IGNITE-9043:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4447
> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Labels: usability
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> But if you try to assign a {{HashMap}} to this field afterwards, then
> exception is thrown.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map,
> fieldType=Object, assignedValueType=Map]
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
> at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
> {noformat}
> It would be convenient, if objects of any type could be written as {{Object}}
> without the need to specify the type explicitly in
> {{BinaryObjectBuilder.setField(...)}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9134) ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with OOME
[
https://issues.apache.org/jira/browse/IGNITE-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568333#comment-16568333
]
ASF GitHub Bot commented on IGNITE-9134:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4461
> ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with OOME
> -
>
> Key: IGNITE-9134
> URL: https://issues.apache.org/jira/browse/IGNITE-9134
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at java.lang.reflect.Array.newInstance(Array.java:75)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1671)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at
> org.apache.ignite.internal.util.IgniteUtils.readMap(IgniteUtils.java:5179)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClusterNode.readExternal(ZookeeperClusterNode.java:365)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1842)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1799)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:139)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.unmarshalZip(ZookeeperDiscoveryImpl.java:3925)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.unmarshalJoinData(ZookeeperDiscoveryImpl.java:1824)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processBulkJoin(ZookeeperDiscoveryImpl.java:2779)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processNewEvents(ZookeeperDiscoveryImpl.java:2628)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processNewEvents(ZookeeperDiscoveryImpl.java:2603)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2000(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$ZkWatcher.processResult(ZookeeperDiscoveryImpl.java:4113)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$DataCallbackWrapper.processResult(ZookeeperClient.java:1219)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:561)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9157) Optimize memory usage of data regions in tests
[ https://issues.apache.org/jira/browse/IGNITE-9157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568322#comment-16568322 ] ASF GitHub Bot commented on IGNITE-9157: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4470 > Optimize memory usage of data regions in tests > -- > > Key: IGNITE-9157 > URL: https://issues.apache.org/jira/browse/IGNITE-9157 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > If we use persistence in tests and do not explicitly set the max size of a > data region, by default it will be 20% of available RAM on a host. This can > lead to memory over-usage and sometimes JVMs, where such tests are running, > will be killed by Linux OOM killer. > We should find all tests where data region max size has forgotten and set > this value explicitly to minimal possible value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9170) .NET: Test CachePartitionedAtomicNearEnabledTest.TestRebalance hangs
[
https://issues.apache.org/jira/browse/IGNITE-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568313#comment-16568313
]
ASF GitHub Bot commented on IGNITE-9170:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4479
> .NET: Test CachePartitionedAtomicNearEnabledTest.TestRebalance hangs
>
>
> Key: IGNITE-9170
> URL: https://issues.apache.org/jira/browse/IGNITE-9170
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.6
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test hangs
> {{CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance}}
> {code}
> [Apache.Ignite.Core.Tests.exe]
> Apache.Ignite.Core.Tests.Cache.CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance
> (1h:57m:24s)
> {code}
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1575775&_focus=4725#_state=
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9148) Split Cache 3 TC configuration.
[ https://issues.apache.org/jira/browse/IGNITE-9148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568305#comment-16568305 ] ASF GitHub Bot commented on IGNITE-9148: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4472 > Split Cache 3 TC configuration. > --- > > Key: IGNITE-9148 > URL: https://issues.apache.org/jira/browse/IGNITE-9148 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Fix For: 2.7 > > > Cache 3 TC configuration takes too long time to complete (>1.5h) and should > be split into two. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9159) Basic 2 TC and Cache 2 configurations are halted by failure handler
[
https://issues.apache.org/jira/browse/IGNITE-9159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568299#comment-16568299
]
Ivan Rakov commented on IGNITE-9159:
Merged to master.
> Basic 2 TC and Cache 2 configurations are halted by failure handler
> ---
>
> Key: IGNITE-9159
> URL: https://issues.apache.org/jira/browse/IGNITE-9159
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1569350&_focus=7955
> https://ci.ignite.apache.org/viewLog.html?buildId=1575803=buildResultsDiv=IgniteTests24Java8_Cache2
> {code}
> [01:19:21][org.apache.ignite:ignite-core] [2018-07-13
> 22:19:21,713][ERROR][exchange-worker-#3043%messaging.IgniteMessagingConfigVariationFullApiTest3%][IgniteTestResources]
> JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Failed to send message (node may have left the
> grid or TCP connection cannot be established due to firewall issues)
> [node=TcpDiscoveryNode [id=b8f7b201-ab85-4a14-bcf0-2b397532,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=3,
> intOrder=3, lastExchangeTime=1531520358330, loc=false,
> ver=2.7.0#20180713-sha1:6a8a2ff8, isClient=false], topic=TOPIC_CACHE,
> msg=GridDhtPartitionsSingleMessage [parts=null, partCntrs=null,
> partsSizes=null, partHistCntrs=null, err=null, client=true, compress=true,
> finishMsg=null, super=GridDhtPartitionsAbstractMessage
> [exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion
> [topVer=10, minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=0fe68fcc-eca6-4f40-9f16-c6181fa0, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1531520358330, loc=false, ver=2.7.0#20180713-sha1:6a8a2ff8,
> isClient=false], topVer=10, nodeId8=7b265a8e, msg=Node left: TcpDiscoveryNode
> [id=0fe68fcc-eca6-4f40-9f16-c6181fa0, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1531520358330, loc=false, ver=2.7.0#20180713-sha1:6a8a2ff8,
> isClient=false], type=NODE_LEFT, tstamp=1531520361620], nodeId=0fe68fcc,
> evt=NODE_LEFT], lastVer=GridCacheVersion [topVer=0, order=1531520357089,
> nodeOrder=0], super=GridCacheMessage [msgId=238, depInfo=null, err=null,
> skipPrepare=false]]], policy=2]]]
> [01:19:22][org.apache.ignite:ignite-core] Process exited with code 130
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9159) Basic 2 TC and Cache 2 configurations are halted by failure handler
[
https://issues.apache.org/jira/browse/IGNITE-9159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568290#comment-16568290
]
ASF GitHub Bot commented on IGNITE-9159:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4471
> Basic 2 TC and Cache 2 configurations are halted by failure handler
> ---
>
> Key: IGNITE-9159
> URL: https://issues.apache.org/jira/browse/IGNITE-9159
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1569350&_focus=7955
> https://ci.ignite.apache.org/viewLog.html?buildId=1575803=buildResultsDiv=IgniteTests24Java8_Cache2
> {code}
> [01:19:21][org.apache.ignite:ignite-core] [2018-07-13
> 22:19:21,713][ERROR][exchange-worker-#3043%messaging.IgniteMessagingConfigVariationFullApiTest3%][IgniteTestResources]
> JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Failed to send message (node may have left the
> grid or TCP connection cannot be established due to firewall issues)
> [node=TcpDiscoveryNode [id=b8f7b201-ab85-4a14-bcf0-2b397532,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=3,
> intOrder=3, lastExchangeTime=1531520358330, loc=false,
> ver=2.7.0#20180713-sha1:6a8a2ff8, isClient=false], topic=TOPIC_CACHE,
> msg=GridDhtPartitionsSingleMessage [parts=null, partCntrs=null,
> partsSizes=null, partHistCntrs=null, err=null, client=true, compress=true,
> finishMsg=null, super=GridDhtPartitionsAbstractMessage
> [exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion
> [topVer=10, minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=0fe68fcc-eca6-4f40-9f16-c6181fa0, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1531520358330, loc=false, ver=2.7.0#20180713-sha1:6a8a2ff8,
> isClient=false], topVer=10, nodeId8=7b265a8e, msg=Node left: TcpDiscoveryNode
> [id=0fe68fcc-eca6-4f40-9f16-c6181fa0, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1531520358330, loc=false, ver=2.7.0#20180713-sha1:6a8a2ff8,
> isClient=false], type=NODE_LEFT, tstamp=1531520361620], nodeId=0fe68fcc,
> evt=NODE_LEFT], lastVer=GridCacheVersion [topVer=0, order=1531520357089,
> nodeOrder=0], super=GridCacheMessage [msgId=238, depInfo=null, err=null,
> skipPrepare=false]]], policy=2]]]
> [01:19:22][org.apache.ignite:ignite-core] Process exited with code 130
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-9184: -- Attachment: logs > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Priority: Critical > Fix For: 2.7 > > Attachments: StressTest.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
Mikhail Cherkasov created IGNITE-9184: - Summary: Cluster hangs during concurrent node restart and continues query registration Key: IGNITE-9184 URL: https://issues.apache.org/jira/browse/IGNITE-9184 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.6 Reporter: Mikhail Cherkasov Fix For: 2.7 Attachments: StressTest.java, stacktrace Please check the attached test case and stack trace. I can see: "Failed to wait for initial partition map exchange" message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9157) Optimize memory usage of data regions in tests
[ https://issues.apache.org/jira/browse/IGNITE-9157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568222#comment-16568222 ] Dmitriy Pavlov edited comment on IGNITE-9157 at 8/3/18 1:46 PM: Re-run shows, that test was fixed, so I set PA status again. WIll take a look was (Author: dpavlov): Re-run seems that test was fixed, so I set PA status again. WIll take a look > Optimize memory usage of data regions in tests > -- > > Key: IGNITE-9157 > URL: https://issues.apache.org/jira/browse/IGNITE-9157 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > If we use persistence in tests and do not explicitly set the max size of a > data region, by default it will be 20% of available RAM on a host. This can > lead to memory over-usage and sometimes JVMs, where such tests are running, > will be killed by Linux OOM killer. > We should find all tests where data region max size has forgotten and set > this value explicitly to minimal possible value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9157) Optimize memory usage of data regions in tests
[ https://issues.apache.org/jira/browse/IGNITE-9157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568222#comment-16568222 ] Dmitriy Pavlov commented on IGNITE-9157: Re-run seems that test was fixed, so I set PA status again. WIll take a look > Optimize memory usage of data regions in tests > -- > > Key: IGNITE-9157 > URL: https://issues.apache.org/jira/browse/IGNITE-9157 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > If we use persistence in tests and do not explicitly set the max size of a > data region, by default it will be 20% of available RAM on a host. This can > lead to memory over-usage and sometimes JVMs, where such tests are running, > will be killed by Linux OOM killer. > We should find all tests where data region max size has forgotten and set > this value explicitly to minimal possible value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9183) Proper handling UUID columns, that are added by DDL.
[ https://issues.apache.org/jira/browse/IGNITE-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568219#comment-16568219 ] Ivan Daschinskiy edited comment on IGNITE-9183 at 8/3/18 1:43 PM: -- [Pull Request #4483|https://github.com/apache/ignite/pull/4483] was (Author: ivandasch): [Pull Request|https://github.com/apache/ignite/pull/4483] > Proper handling UUID columns, that are added by DDL. > > > Key: IGNITE-9183 > URL: https://issues.apache.org/jira/browse/IGNITE-9183 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.5, 2.6 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.7 > > > Currently, if we added new UUID columnt thru DDL, it is saved to schema as > byte[]. So it's impossible to use it with DML without placeholders and put > values thru cache api without converting UUID to byte[]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9183) Proper handling UUID columns, that are added by DDL.
[ https://issues.apache.org/jira/browse/IGNITE-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568219#comment-16568219 ] Ivan Daschinskiy commented on IGNITE-9183: -- [Pull Request|https://github.com/apache/ignite/pull/4483] > Proper handling UUID columns, that are added by DDL. > > > Key: IGNITE-9183 > URL: https://issues.apache.org/jira/browse/IGNITE-9183 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.5, 2.6 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.7 > > > Currently, if we added new UUID columnt thru DDL, it is saved to schema as > byte[]. So it's impossible to use it with DML without placeholders and put > values thru cache api without converting UUID to byte[]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9149) Get rid of logging remaining supplier nodes rebalance time
[
https://issues.apache.org/jira/browse/IGNITE-9149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568216#comment-16568216
]
ASF GitHub Bot commented on IGNITE-9149:
GitHub user ivandasch opened a pull request:
https://github.com/apache/ignite/pull/4483
IGNITE-9149 Add proper handling of UUID column in DDL statements.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9149
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4483.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4483
commit 06ab44c311a0084f75c44aacb1fc11142f67a922
Author: Ivan Daschinskiy
Date: 2018-08-03T13:30:51Z
IGNITE-9149 Add proper handling of UUID column in DDL statements.
> Get rid of logging remaining supplier nodes rebalance time
> --
>
> Key: IGNITE-9149
> URL: https://issues.apache.org/jira/browse/IGNITE-9149
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: rebalance
>
> Logging rebalance execution time in section of each supplier node have no
> sence and provides no helpfull info for analyzing logs. It also
> overcomplicates {{GridDhtPartitionDemander}}.
> I'm suggesting remove it by simplifying {{Map IgniteDhtDemandedPartitionsMap>>}} to {{Map IgniteDhtDemandedPartitionsMap>}}.
> {code:java}
> /** Remaining. T2: startTime, partitions */
> private final Map> remaining =
> new HashMap<>();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject
[
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568207#comment-16568207
]
Vladimir Ozerov commented on IGNITE-9043:
-
[~dmekhanikov], looks good to me.
> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Labels: usability
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> But if you try to assign a {{HashMap}} to this field afterwards, then
> exception is thrown.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map,
> fieldType=Object, assignedValueType=Map]
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
> at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
> {noformat}
> It would be convenient, if objects of any type could be written as {{Object}}
> without the need to specify the type explicitly in
> {{BinaryObjectBuilder.setField(...)}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9183) Proper handling UUID columns, that are added by DDL.
Ivan Daschinskiy created IGNITE-9183: Summary: Proper handling UUID columns, that are added by DDL. Key: IGNITE-9183 URL: https://issues.apache.org/jira/browse/IGNITE-9183 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.6, 2.5 Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.7 Currently, if we added new UUID columnt thru DDL, it is saved to schema as byte[]. So it's impossible to use it with DML without placeholders and put values thru cache api without converting UUID to byte[]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8477) Web console: duration is empty
[ https://issues.apache.org/jira/browse/IGNITE-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8477: Assignee: Alexander Kalinin (was: Alexey Kuznetsov) [~alexdel], please merge with master, there a lot of conflicts. > Web console: duration is empty > -- > > Key: IGNITE-8477 > URL: https://issues.apache.org/jira/browse/IGNITE-8477 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexander Kalinin >Priority: Major > Fix For: 2.7 > > Attachments: screenshot-1.png > > > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9182) Propagate lazy flag to synthetic SELECT used by first step of DELETE
Stanislav Lukyanov created IGNITE-9182: -- Summary: Propagate lazy flag to synthetic SELECT used by first step of DELETE Key: IGNITE-9182 URL: https://issues.apache.org/jira/browse/IGNITE-9182 Project: Ignite Issue Type: Bug Components: sql Reporter: Stanislav Lukyanov When DELETE is executed it first executed SELECT with the same WHERE, and then deletes all results via an invoke(). If a large number of entries is to be deleted, it may lead to OOM. The task is to allow to perform the SELECT with the parent query's LAZY flag. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-9085. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9085: - Ignite Flags: (was: Docs Required) > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9085: - Fix Version/s: 2.7 > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9147) When server node left cluster on high load, cluster take hang on PartitionalExchange
[ https://issues.apache.org/jira/browse/IGNITE-9147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568171#comment-16568171 ] Alexei Scherbakov commented on IGNITE-9147: --- Root cause is race between forced tx rollback and tx map phase. > When server node left cluster on high load, cluster take hang on > PartitionalExchange > > > Key: IGNITE-9147 > URL: https://issues.apache.org/jira/browse/IGNITE-9147 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Alexei Scherbakov >Priority: Critical > Fix For: 2.7 > > > I ran a simple test > 1) Start 15 servers node > 2) Start client with long transaction > 3) Additional start 5 client with loading in many caches (near 2 thousand) > 4) Stop 1 server node, wait 1 minute and start it back > Cluster freenze on more than hour, then license end -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9147) When server node left cluster on high load, cluster take hang on PartitionalExchange
[ https://issues.apache.org/jira/browse/IGNITE-9147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov reassigned IGNITE-9147: - Assignee: Alexei Scherbakov > When server node left cluster on high load, cluster take hang on > PartitionalExchange > > > Key: IGNITE-9147 > URL: https://issues.apache.org/jira/browse/IGNITE-9147 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Alexei Scherbakov >Priority: Critical > Fix For: 2.7 > > > I ran a simple test > 1) Start 15 servers node > 2) Start client with long transaction > 3) Additional start 5 client with loading in many caches (near 2 thousand) > 4) Stop 1 server node, wait 1 minute and start it back > Cluster freenze on more than hour, then license end -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9181) Continuous query with remote filter factory doesn't let nodes join
[
https://issues.apache.org/jira/browse/IGNITE-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-9181:
-
Ignite Flags: (was: Docs Required)
> Continuous query with remote filter factory doesn't let nodes join
> ---
>
> Key: IGNITE-9181
> URL: https://issues.apache.org/jira/browse/IGNITE-9181
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments: ContinuousQueryNodeJoinTest.java
>
>
> When continuous query is registered, that has a remote filter factory
> configured, and P2P class loading is enabled, then all new nodes fail with an
> exception, which doesn't let them join the cluster.
> Exception:
> {noformat}
> [ERROR][tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%][TestTcpDiscoverySpi]
> Runtime error caught during grid runnable execution: GridWorker
> [name=tcp-disco-msg-worker,
> igniteInstanceName=continuous.ContinuousQueryNodeJoinTest1, finished=false,
> hashCode=726450632, interrupted=false,
> runner=tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%],
> nextNode=[null]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.getEventFilter(CacheContinuousQueryHandlerV2.java:108)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.register(CacheContinuousQueryHandler.java:330)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.registerHandler(GridContinuousProcessor.java:1738)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onDiscoDataReceived(GridContinuousProcessor.java:646)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onGridDataReceived(GridContinuousProcessor.java:538)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:889)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4502)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2804)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2604)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7115)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2688)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7059)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> Reproducer is in the attachment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9181) Continuous query with remote filter factory doesn't let nodes join
[
https://issues.apache.org/jira/browse/IGNITE-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-9181:
-
Description:
When continuous query is registered, that has a remote filter factory
configured, and P2P class loading is enabled, then all new nodes fail with an
exception, which doesn't let them join the cluster.
Exception:
{noformat}
[ERROR][tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%][TestTcpDiscoverySpi]
Runtime error caught during grid runnable execution: GridWorker
[name=tcp-disco-msg-worker,
igniteInstanceName=continuous.ContinuousQueryNodeJoinTest1, finished=false,
hashCode=726450632, interrupted=false,
runner=tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%],
nextNode=[null]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.getEventFilter(CacheContinuousQueryHandlerV2.java:108)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.register(CacheContinuousQueryHandler.java:330)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.registerHandler(GridContinuousProcessor.java:1738)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onDiscoDataReceived(GridContinuousProcessor.java:646)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onGridDataReceived(GridContinuousProcessor.java:538)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:889)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1993)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4502)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2804)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2604)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7115)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2688)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7059)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}
Reproducer is in the attachment.
was:
When continuous query is registered, that has a remote filter factory
configured, and P2P class loading is enabled, then all new nodes fail with an
exception, which doesn't let them join the cluster.
Reproducer is in the attachment.
> Continuous query with remote filter factory doesn't let nodes join
> ---
>
> Key: IGNITE-9181
> URL: https://issues.apache.org/jira/browse/IGNITE-9181
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments: ContinuousQueryNodeJoinTest.java
>
>
> When continuous query is registered, that has a remote filter factory
> configured, and P2P class loading is enabled, then all new nodes fail with an
> exception, which doesn't let them join the cluster.
> Exception:
> {noformat}
> [ERROR][tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%][TestTcpDiscoverySpi]
> Runtime error caught during grid runnable execution: GridWorker
> [name=tcp-disco-msg-worker,
> igniteInstanceName=continuous.ContinuousQueryNodeJoinTest1, finished=false,
> hashCode=726450632, interrupted=false,
> runner=tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%],
> nextNode=[null]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.getEventFilter(CacheContinuousQueryHandlerV2.java:108)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.register(CacheContinuousQueryHandler.java:330)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.registerHandler(GridContinuousProcessor.java:1738)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onDiscoDataReceived(GridContinuousProcessor.java:646)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onGridDataReceived(GridContinuousProcessor.java:538)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:889)
> at
>
[jira] [Commented] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject
[
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568160#comment-16568160
]
Dmitry Karachentsev commented on IGNITE-9043:
-
[~dmekhanikov] Reviewed, looks OK for me.
> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Labels: usability
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> But if you try to assign a {{HashMap}} to this field afterwards, then
> exception is thrown.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map,
> fieldType=Object, assignedValueType=Map]
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
> at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
> {noformat}
> It would be convenient, if objects of any type could be written as {{Object}}
> without the need to specify the type explicitly in
> {{BinaryObjectBuilder.setField(...)}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568159#comment-16568159
]
Ilya Lantukh commented on IGNITE-9068:
--
https://ci.ignite.apache.org/viewLog.html?buildId=1584926=buildResultsDiv=IgniteTests24Java8_RunAll
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: test
> Fix For: 2.7
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
> at
>
[jira] [Commented] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568155#comment-16568155
]
ASF GitHub Bot commented on IGNITE-9068:
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/4482
IGNITE-9068 : Avoided potential deadlock when service is deployed while
node is stopping.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9068
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4482.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4482
commit 44cff17b4f2c444b2cbb71d70b735066e96f1bb8
Author: Ilya Lantukh
Date: 2018-08-03T12:31:31Z
IGNITE-9068 : Avoided potential deadlock when service is deployed while
node is stopping.
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: test
> Fix For: 2.7
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
>
[jira] [Created] (IGNITE-9181) Continuous query with remote filter factory doesn't let nodes join
Denis Mekhanikov created IGNITE-9181: Summary: Continuous query with remote filter factory doesn't let nodes join Key: IGNITE-9181 URL: https://issues.apache.org/jira/browse/IGNITE-9181 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Denis Mekhanikov Attachments: ContinuousQueryNodeJoinTest.java When continuous query is registered, that has a remote filter factory configured, and P2P class loading is enabled, then all new nodes fail with an exception, which doesn't let them join the cluster. Reproducer is in the attachment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9159) Basic 2 TC and Cache 2 configurations are halted by failure handler
[
https://issues.apache.org/jira/browse/IGNITE-9159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568147#comment-16568147
]
Vitaliy Biryukov commented on IGNITE-9159:
--
Looks good to me.
> Basic 2 TC and Cache 2 configurations are halted by failure handler
> ---
>
> Key: IGNITE-9159
> URL: https://issues.apache.org/jira/browse/IGNITE-9159
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1569350&_focus=7955
> https://ci.ignite.apache.org/viewLog.html?buildId=1575803=buildResultsDiv=IgniteTests24Java8_Cache2
> {code}
> [01:19:21][org.apache.ignite:ignite-core] [2018-07-13
> 22:19:21,713][ERROR][exchange-worker-#3043%messaging.IgniteMessagingConfigVariationFullApiTest3%][IgniteTestResources]
> JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Failed to send message (node may have left the
> grid or TCP connection cannot be established due to firewall issues)
> [node=TcpDiscoveryNode [id=b8f7b201-ab85-4a14-bcf0-2b397532,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=3,
> intOrder=3, lastExchangeTime=1531520358330, loc=false,
> ver=2.7.0#20180713-sha1:6a8a2ff8, isClient=false], topic=TOPIC_CACHE,
> msg=GridDhtPartitionsSingleMessage [parts=null, partCntrs=null,
> partsSizes=null, partHistCntrs=null, err=null, client=true, compress=true,
> finishMsg=null, super=GridDhtPartitionsAbstractMessage
> [exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion
> [topVer=10, minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=0fe68fcc-eca6-4f40-9f16-c6181fa0, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1531520358330, loc=false, ver=2.7.0#20180713-sha1:6a8a2ff8,
> isClient=false], topVer=10, nodeId8=7b265a8e, msg=Node left: TcpDiscoveryNode
> [id=0fe68fcc-eca6-4f40-9f16-c6181fa0, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1531520358330, loc=false, ver=2.7.0#20180713-sha1:6a8a2ff8,
> isClient=false], type=NODE_LEFT, tstamp=1531520361620], nodeId=0fe68fcc,
> evt=NODE_LEFT], lastVer=GridCacheVersion [topVer=0, order=1531520357089,
> nodeOrder=0], super=GridCacheMessage [msgId=238, depInfo=null, err=null,
> skipPrepare=false]]], policy=2]]]
> [01:19:22][org.apache.ignite:ignite-core] Process exited with code 130
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8145) Web console: Implement test to check missed new fields in configurations, and SPIs, and...
[ https://issues.apache.org/jira/browse/IGNITE-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-8145: - Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Web console: Implement test to check missed new fields in configurations, and > SPIs, and... > -- > > Key: IGNITE-8145 > URL: https://issues.apache.org/jira/browse/IGNITE-8145 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8145) Web console: Implement test to check missed new fields in configurations, and SPIs, and...
[ https://issues.apache.org/jira/browse/IGNITE-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568126#comment-16568126 ] Vasiliy Sisko commented on IGNITE-8145: --- Implemented test to check missed, deprecated and removed fields. > Web console: Implement test to check missed new fields in configurations, and > SPIs, and... > -- > > Key: IGNITE-8145 > URL: https://issues.apache.org/jira/browse/IGNITE-8145 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9180) IgniteSparkSession Should Copy State on cloneSession()
[ https://issues.apache.org/jira/browse/IGNITE-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Macdonald updated IGNITE-9180: - Description: The IgniteSparkSession class extends SparkSession and overrides the cloneSession() method. The contract for cloneSession() explicitly states that it should clone all state (ie. the sharedState and sessionState fields), however the IgniteSparkSession implementation doesn't clone its state fields. This has the side-effect of breaking stateful operations for anything which uses cloneSession(), for example a Spark streaming job will not be able to use cached data across streaming microbatches, which is a significant issue for such applications. was: The IgniteSparkSession class extends SparkState and overrides the cloneSession() method. The contract for cloneSession() explicitly states that it should clone all state (ie. the sharedState and sessionState fields), however the IgniteSparkSession implementation doesn't clone its state fields. This has the side-effect of breaking stateful operations for anything which uses cloneSession(), for example a Spark streaming job will not be able to use cached data across streaming microbatches, which is a significant issue for such applications. > IgniteSparkSession Should Copy State on cloneSession() > -- > > Key: IGNITE-9180 > URL: https://issues.apache.org/jira/browse/IGNITE-9180 > Project: Ignite > Issue Type: Bug > Components: spark >Reporter: Stuart Macdonald >Priority: Major > > The IgniteSparkSession class extends SparkSession and overrides the > cloneSession() method. The contract for cloneSession() explicitly states that > it should clone all state (ie. the sharedState and sessionState fields), > however the IgniteSparkSession implementation doesn't clone its state fields. > This has the side-effect of breaking stateful operations for anything which > uses cloneSession(), for example a Spark streaming job will not be able to > use cached data across streaming microbatches, which is a significant issue > for such applications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9180) IgniteSparkSession Should Copy State on cloneSession()
[ https://issues.apache.org/jira/browse/IGNITE-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Macdonald updated IGNITE-9180: - Description: The IgniteSparkSession class extends SparkState and overrides the cloneSession() method. The contract for cloneSession() explicitly states that it should clone all state (ie. the sharedState and sessionState fields), however the IgniteSparkSession implementation doesn't clone its state fields. This has the side-effect of breaking stateful operations for anything which uses cloneSession(), for example a Spark streaming job will not be able to use cached data across streaming microbatches, which is a significant issue for such applications. was: The IgniteSparkSession object extends SparkState and overrides the cloneSession() method. The contract for cloneSession() explicitly states that it should clone all state (ie. the sharedState and sessionState fields), however the IgniteSparkSession implementation doesn't clone its state fields. This has the side-effect of breaking stateful operations for anything which uses cloneSession(), for example a Spark streaming job will not be able to use cached data across streaming microbatches, which is a significant issue for such applications. > IgniteSparkSession Should Copy State on cloneSession() > -- > > Key: IGNITE-9180 > URL: https://issues.apache.org/jira/browse/IGNITE-9180 > Project: Ignite > Issue Type: Bug > Components: spark >Reporter: Stuart Macdonald >Priority: Major > > The IgniteSparkSession class extends SparkState and overrides the > cloneSession() method. The contract for cloneSession() explicitly states that > it should clone all state (ie. the sharedState and sessionState fields), > however the IgniteSparkSession implementation doesn't clone its state fields. > This has the side-effect of breaking stateful operations for anything which > uses cloneSession(), for example a Spark streaming job will not be able to > use cached data across streaming microbatches, which is a significant issue > for such applications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9180) IgniteSparkSession Should Copy State on cloneSession()
Stuart Macdonald created IGNITE-9180: Summary: IgniteSparkSession Should Copy State on cloneSession() Key: IGNITE-9180 URL: https://issues.apache.org/jira/browse/IGNITE-9180 Project: Ignite Issue Type: Bug Components: spark Reporter: Stuart Macdonald The IgniteSparkSession object extends SparkState and overrides the cloneSession() method. The contract for cloneSession() explicitly states that it should clone all state (ie. the sharedState and sessionState fields), however the IgniteSparkSession implementation doesn't clone its state fields. This has the side-effect of breaking stateful operations for anything which uses cloneSession(), for example a Spark streaming job will not be able to use cached data across streaming microbatches, which is a significant issue for such applications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8680) Encoding categorical features with OneHotEncoder
[ https://issues.apache.org/jira/browse/IGNITE-8680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568113#comment-16568113 ] ASF GitHub Bot commented on IGNITE-8680: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4469 > Encoding categorical features with OneHotEncoder > > > Key: IGNITE-8680 > URL: https://issues.apache.org/jira/browse/IGNITE-8680 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9064) Decision tree optimization
[ https://issues.apache.org/jira/browse/IGNITE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568109#comment-16568109 ] ASF GitHub Bot commented on IGNITE-9064: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4436 > Decision tree optimization > -- > > Key: IGNITE-9064 > URL: https://issues.apache.org/jira/browse/IGNITE-9064 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We need to optimize impurity function calculation by additional index > structure for all sorted features and reusing it in learning iterations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9085: Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4010) Web Console: Implement responsive layout
[ https://issues.apache.org/jira/browse/IGNITE-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-4010. -- Assignee: Pavel Konstantinov (was: Dmitriy Shabalin) Fixed issue under Edge and merged to master. > Web Console: Implement responsive layout > > > Key: IGNITE-4010 > URL: https://issues.apache.org/jira/browse/IGNITE-4010 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 1.7 >Reporter: Andrey Novikov >Assignee: Pavel Konstantinov >Priority: Minor > Labels: web-console-UI-UX > Fix For: 2.7 > > > Add responsive width for body. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9177: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9179) Web Console: Split VisorBaselineTask for two parts in order to simplify tooling
[ https://issues.apache.org/jira/browse/IGNITE-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568103#comment-16568103 ] Pavel Konstantinov commented on IGNITE-9179: Tested. > Web Console: Split VisorBaselineTask for two parts in order to simplify > tooling > --- > > Key: IGNITE-9179 > URL: https://issues.apache.org/jira/browse/IGNITE-9179 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Split to: view & manipulate tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov resolved IGNITE-9177. Resolution: Fixed > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568069#comment-16568069 ] Pavel Konstantinov commented on IGNITE-9177: Tested. > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-9177: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9176) Web console: show authorization exception if user hasn't permission to activate a cluster
[ https://issues.apache.org/jira/browse/IGNITE-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9176: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Added error handling on cluster state toggle. Please test in branch ignite-9176. > Web console: show authorization exception if user hasn't permission to > activate a cluster > - > > Key: IGNITE-9176 > URL: https://issues.apache.org/jira/browse/IGNITE-9176 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Labels: web-console-monitoring-baseline > Fix For: 2.7 > > > I've faced with an issue that we don't show any error if a user has no > permission to activate a cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9176) Web console: show authorization exception if user hasn't permission to activate a cluster
[ https://issues.apache.org/jira/browse/IGNITE-9176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9176: - Fix Version/s: 2.7 > Web console: show authorization exception if user hasn't permission to > activate a cluster > - > > Key: IGNITE-9176 > URL: https://issues.apache.org/jira/browse/IGNITE-9176 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Labels: web-console-monitoring-baseline > Fix For: 2.7 > > > I've faced with an issue that we don't show any error if a user has no > permission to activate a cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568065#comment-16568065 ] Vica Abramova commented on IGNITE-9085: --- It was decided not to do so. > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vica Abramova reassigned IGNITE-9085: - Assignee: Pavel Konstantinov (was: Vica Abramova) > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9179) Web Console: Split VisorBaselineTask for two parts in order to simplify tooling
[ https://issues.apache.org/jira/browse/IGNITE-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-9179. > Web Console: Split VisorBaselineTask for two parts in order to simplify > tooling > --- > > Key: IGNITE-9179 > URL: https://issues.apache.org/jira/browse/IGNITE-9179 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Split to: view & manipulate tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9179) Web Console: Split VisorBaselineTask for two parts in order to simplify tooling
[ https://issues.apache.org/jira/browse/IGNITE-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-9179. -- Resolution: Fixed Merged to master. > Web Console: Split VisorBaselineTask for two parts in order to simplify > tooling > --- > > Key: IGNITE-9179 > URL: https://issues.apache.org/jira/browse/IGNITE-9179 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Split to: view & manipulate tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation
[
https://issues.apache.org/jira/browse/IGNITE-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568040#comment-16568040
]
Anton Vinogradov commented on IGNITE-8446:
--
[~dpavlov],
Fix is ready and passed review.
Could you please benchmark
https://github.com/apache/ignite/tree/ignite-8446
vs
https://github.com/apache/ignite/tree/ignite-8446-master
Only one benchmark is required: tx throughput
> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.7
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to
> guarantee it filled.
> So, we have to add special event fired on {{tx}} creation.
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta
> should be added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-9085: -- Assignee: Vica Abramova (was: Pavel Konstantinov) > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vica Abramova >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9085) Web console: Actualize Login page carousel images
[ https://issues.apache.org/jira/browse/IGNITE-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568036#comment-16568036 ] Pavel Konstantinov commented on IGNITE-9085: [~vabramova] The screenshots are not actual - there is no cluster activation component on the screenshots. > Web console: Actualize Login page carousel images > - > > Key: IGNITE-9085 > URL: https://issues.apache.org/jira/browse/IGNITE-9085 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9134) ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with OOME
[
https://issues.apache.org/jira/browse/IGNITE-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568026#comment-16568026
]
Vitaliy Biryukov commented on IGNITE-9134:
--
Hi [~dpavlov], please take a look.
> ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with OOME
> -
>
> Key: IGNITE-9134
> URL: https://issues.apache.org/jira/browse/IGNITE-9134
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at java.lang.reflect.Array.newInstance(Array.java:75)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1671)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at
> org.apache.ignite.internal.util.IgniteUtils.readMap(IgniteUtils.java:5179)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClusterNode.readExternal(ZookeeperClusterNode.java:365)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1842)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1799)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:139)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.unmarshalZip(ZookeeperDiscoveryImpl.java:3925)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.unmarshalJoinData(ZookeeperDiscoveryImpl.java:1824)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processBulkJoin(ZookeeperDiscoveryImpl.java:2779)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processNewEvents(ZookeeperDiscoveryImpl.java:2628)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processNewEvents(ZookeeperDiscoveryImpl.java:2603)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.access$2000(ZookeeperDiscoveryImpl.java:108)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl$ZkWatcher.processResult(ZookeeperDiscoveryImpl.java:4113)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient$DataCallbackWrapper.processResult(ZookeeperClient.java:1219)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:561)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568020#comment-16568020
]
Dmitriy Govorukhin commented on IGNITE-5103:
[~akalashnikov] Please, review this changes. The link in an attached.
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Major
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9179) Web Console: Split VisorBaselineTask for two parts in order to simplify tooling
Alexey Kuznetsov created IGNITE-9179: Summary: Web Console: Split VisorBaselineTask for two parts in order to simplify tooling Key: IGNITE-9179 URL: https://issues.apache.org/jira/browse/IGNITE-9179 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Split to: view & manipulate tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9179) Web Console: Split VisorBaselineTask for two parts in order to simplify tooling
[ https://issues.apache.org/jira/browse/IGNITE-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9179: - Fix Version/s: 2.7 > Web Console: Split VisorBaselineTask for two parts in order to simplify > tooling > --- > > Key: IGNITE-9179 > URL: https://issues.apache.org/jira/browse/IGNITE-9179 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Split to: view & manipulate tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9175) AssertionError on simultaneous nodes stop
[
https://issues.apache.org/jira/browse/IGNITE-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9175:
--
Description:
https://ci.ignite.apache.org/viewLog.html?buildId=1577915;
"New" assertion errors which were found in
{{GridCacheDhtPreloadMultiThreadedSelfTest#testConcurrentNodesStartStop}} after
issue IGNITE-9159 was fixed.
{code}
[2018-08-02
20:28:06,639][ERROR][tcp-disco-msg-worker-#6163%grid-tester-3%][TcpDiscoverySpi]
TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in
order to prevent cluster wide instability.
java.lang.AssertionError
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.sendMessageAcrossRing(ServerImpl.java:2922)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeLeftMessage(ServerImpl.java:4846)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2810)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2604)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7115)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2688)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7059)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}
{code}
[2018-08-02 09:56:25,337][ERROR][tester-4][IgniteKernal%grid-tester-4] Got
exception while starting (will rollback startup routine).
java.lang.AssertionError: Topology version out of order [this.topVer=Snapshot
[topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0]], topVer=1,
node=TcpDiscoveryNode [id=e3be6dc3-78bb-489c-a00f-1c14e4110b51, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47505], discPort=47505, order=1,
intOrder=1, lastExchangeTime=1533203783365, loc=true,
ver=2.7.0#20180802-sha1:7b79fc20, isClient=false],
nextTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=0], evt=NODE_JOINED]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:747)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:590)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1443)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:934)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:389)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1754)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
at org.apache.ignite.Ignition.start(Ignition.java:327)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1349)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1332)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadMultiThreadedSelfTest.access$500(GridCacheDhtPreloadMultiThreadedSelfTest.java:42)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadMultiThreadedSelfTest$4.call(GridCacheDhtPreloadMultiThreadedSelfTest.java:146)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
[2018-08-02 09:56:25,393][WARN
][tcp-disco-msg-worker-#3278%grid-tester-2%][TcpDisco
{code}
was:
{code}
[2018-08-02
20:28:06,639][ERROR][tcp-disco-msg-worker-#6163%grid-tester-3%][TcpDiscoverySpi]
TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in
order to prevent cluster wide instability.
java.lang.AssertionError
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.sendMessageAcrossRing(ServerImpl.java:2922)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeLeftMessage(ServerImpl.java:4846)
at
[jira] [Created] (IGNITE-9178) Partition lost event are not triggered if multiple nodes left cluster
Pavel Vinokurov created IGNITE-9178: --- Summary: Partition lost event are not triggered if multiple nodes left cluster Key: IGNITE-9178 URL: https://issues.apache.org/jira/browse/IGNITE-9178 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.4 Reporter: Pavel Vinokurov If multiple nodes left cluster simultaneously, left partitions are removed from GridDhtPartitionTopologyImpl#node2part without adding to leftNode2Part in GridDhtPartitionTopologyImpl#update method. Thus GridDhtPartitionTopologyImpl#detectLostPartitions can't detect lost partitions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-4780) Web Console: Improve the adaptability of the web console
[ https://issues.apache.org/jira/browse/IGNITE-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-4780. > Web Console: Improve the adaptability of the web console > > > Key: IGNITE-4780 > URL: https://issues.apache.org/jira/browse/IGNITE-4780 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > > TBD layouts for different screen resolutions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4780) Web Console: Improve the adaptability of the web console
[ https://issues.apache.org/jira/browse/IGNITE-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-4780. -- Resolution: Duplicate Assignee: Alexey Kuznetsov (was: Vica Abramova) Duplicate of IGNITE-4010 > Web Console: Improve the adaptability of the web console > > > Key: IGNITE-4780 > URL: https://issues.apache.org/jira/browse/IGNITE-4780 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > > TBD layouts for different screen resolutions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9170) .NET: Test CachePartitionedAtomicNearEnabledTest.TestRebalance hangs
[
https://issues.apache.org/jira/browse/IGNITE-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16567818#comment-16567818
]
Maxim Muzafarov edited comment on IGNITE-9170 at 8/3/18 8:04 AM:
-
Issue is caused by this line, if the first cache group in a list has
{{CachMode.LOCAL}}
{code:java|title=GridCachePartitionExchangeManager.java\:2608}
if (resVer == null)
resVer = grp.topology().readyTopologyVersion();
{code}
was (Author: mmuzaf):
Issue is caused by this line, if the first cache group in a list has
{{CachMode.LOCAL}}
{code:java}
if (resVer == null)
resVer = grp.topology().readyTopologyVersion();
{code}
> .NET: Test CachePartitionedAtomicNearEnabledTest.TestRebalance hangs
>
>
> Key: IGNITE-9170
> URL: https://issues.apache.org/jira/browse/IGNITE-9170
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.6
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test hangs
> {{CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance}}
> {code}
> [Apache.Ignite.Core.Tests.exe]
> Apache.Ignite.Core.Tests.Cache.CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance
> (1h:57m:24s)
> {code}
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1575775&_focus=4725#_state=
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9170) .NET: Test CachePartitionedAtomicNearEnabledTest.TestRebalance hangs
[
https://issues.apache.org/jira/browse/IGNITE-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16567928#comment-16567928
]
Maxim Muzafarov commented on IGNITE-9170:
-
Changes ready.
[~dpavlov],
Will you have time to have a look to?
Run::All – [#3125 (03 Aug 18
08:24)|https://ci.ignite.apache.org/viewLog.html?buildId=1582250=buildResultsDiv=IgniteTests24Java8_RunAll]
Run::.Net – [#2953 (03 Aug 18
08:24)|https://ci.ignite.apache.org/viewLog.html?buildId=1582207=buildResultsDiv=IgniteTests24Java8_RunAllNet]
And separately for, now not hungs.
[Platform .NET (Long
Running)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning_IgniteTests24Java8=pull%2F4479%2Fhead=buildTypeStatusDiv]
> .NET: Test CachePartitionedAtomicNearEnabledTest.TestRebalance hangs
>
>
> Key: IGNITE-9170
> URL: https://issues.apache.org/jira/browse/IGNITE-9170
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.6
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test hangs
> {{CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance}}
> {code}
> [Apache.Ignite.Core.Tests.exe]
> Apache.Ignite.Core.Tests.Cache.CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance
> (1h:57m:24s)
> {code}
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1575775&_focus=4725#_state=
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16567929#comment-16567929
]
ASF GitHub Bot commented on IGNITE-9165:
GitHub user zzzadruga opened a pull request:
https://github.com/apache/ignite/pull/4481
IGNITE-9165 Close streams in core module
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/zzzadruga/ignite IGNITE-9165
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4481.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4481
commit f4d542b6bd426ae7fb6546d5c0654fa0cb9b41a4
Author: zzzadruga
Date: 2018-08-03T07:28:05Z
IGNITE-9165 Close streams
commit be4c168078c56cef9930322bab9350e3fde41205
Author: zzzadruga
Date: 2018-08-03T07:58:06Z
IGNITE-9165 Remove unused import
> 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
> Fix For: 2.7
>
> 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
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-9177: Assignee: Pavel Konstantinov (was: Dmitriy Shabalin) > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16567925#comment-16567925 ] Dmitriy Shabalin commented on IGNITE-9177: -- [~pkonstantinov] fix first issue, pls review it. second issue, It's not mistake. After redesign we could add placeholder if fields do not have values. > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Dmitriy Shabalin >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16567904#comment-16567904
]
ASF GitHub Bot commented on IGNITE-8640:
GitHub user dgarus opened a pull request:
https://github.com/apache/ignite/pull/4480
IGNITE-8640 earlier validation of cache config
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dgarus/ignite ignte-8640
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4480.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4480
commit 46e68d648f31163bb704ff832e9553006a26ebd7
Author: Garus Denis
Date: 2018-08-03T07:44:11Z
IGNITE-8640 earlier validation of cache config
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.7
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:544)
> at
>
[jira] [Assigned] (IGNITE-9163) Web console: incorrect cluster state for clusters of version 1.x
[ https://issues.apache.org/jira/browse/IGNITE-9163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9163: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Web console: incorrect cluster state for clusters of version 1.x > > > Key: IGNITE-9163 > URL: https://issues.apache.org/jira/browse/IGNITE-9163 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > Labels: web-console-UI-UX > Fix For: 2.7 > > Attachments: screenshot-1.png > > > !screenshot-1.png! > Clusters of version 1.x always active -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9177: - Fix Version/s: 2.7 > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Dmitriy Shabalin >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9177) Web console: full screen UI issues under Edge
[ https://issues.apache.org/jira/browse/IGNITE-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9177: - Ignite Flags: (was: Docs Required) > Web console: full screen UI issues under Edge > - > > Key: IGNITE-9177 > URL: https://issues.apache.org/jira/browse/IGNITE-9177 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Dmitriy Shabalin >Priority: Major > Labels: web-console-UI-UX, web-console-configuration > Fix For: 2.7 > > Attachments: screenshot-1.png, screenshot-2.png > > > (1) Basic tab, discovery addresses > !screenshot-1.png! > (2) Advanced tab, User attributes > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
