[jira] [Created] (IGNITE-11352) Compatibility with 2.7 with mode: statistics enabled
Stepachev Maksim created IGNITE-11352: - Summary: Compatibility with 2.7 with mode: statistics enabled Key: IGNITE-11352 URL: https://issues.apache.org/jira/browse/IGNITE-11352 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Stepachev Maksim Assignee: Stepachev Maksim Fix For: 2.7 The problem was founded when we performed a rolling upgrade from 2.4 to 2.7. The root of the problem is CacheMetricsSnapshot, it doesn't work with the previous version of the protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11338) Web Console: Current cache "jump" after edit on "Basic configuration" screen
[ https://issues.apache.org/jira/browse/IGNITE-11338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771665#comment-16771665 ] Ilya Borisov edited comment on IGNITE-11338 at 2/19/19 7:55 AM: [~kuaw26] the issue was caused by a combination of several factors: 1. Basic configuration sorts caches by name. 2. Basic configuration cache changes are applied immediately and not on input blur. 3. component tracks items in edit by index and not id. To fix it, I updated all item operation in list-editable to use computed id instead of index. I also converted most of list-editable extra directives/components to TS in order to ensure correct list-editable controller method call signatures. What to test: 1. Reported issue should not happen, edited item should remain the same regardless of it's position in list. 2. Other list-editable instances do not have regressions. was (Author: klaster_1): [~kuaw26] the issue was caused by a combination of several factors: 1. Basic configuration sorts caches by name. 2. Basic configuration cache changes are applied immediately and not on input blur. 3. component tracks items in edit by index and not id. To fix it, I updated all item operation in list-editable to use computed id instead of index. I also converted most of list-editable extra directives/components to TS in order to ensure correct list-editable controller method call signatures. What to test: 1. Reported issue should not happen, instead > Web Console: Current cache "jump" after edit on "Basic configuration" screen > > > Key: IGNITE-11338 > URL: https://issues.apache.org/jira/browse/IGNITE-11338 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > Time Spent: 1h 13m > Remaining Estimate: 0h > > Steps to reproduce: > # Create new cluster. > # Add 3 caches (just click 3 times on "Add new cache") > # Click on first cache with name "Cache" and add a letter "x" to the end of > its name. > # It will "jump" to the end of list. > # And current "editable" item become cache with name "Cache1" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-10214: -- Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11313) Cluster hangs on cache invoke with binary objects creation
[
https://issues.apache.org/jira/browse/IGNITE-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771684#comment-16771684
]
Ignite TC Bot commented on IGNITE-11313:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3115253&buildTypeId=IgniteTests24Java8_RunAll]
> Cluster hangs on cache invoke with binary objects creation
> --
>
> Key: IGNITE-11313
> URL: https://issues.apache.org/jira/browse/IGNITE-11313
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Creating of binary objects in entry processors in parallel with continuous
> queries may lead to deadlock:
> {code:java}
> [2019-02-11 18:52:50,129][WARN ][grid-timeout-worker-#39] >>> Possible
> starvation in striped pool.
> Thread name: sys-stripe-13-#14
> Queue: []
> Deadlock: false
> Completed: 1
> Thread [name="sys-stripe-13-#14", id=33, state=WAITING, blockCnt=3, waitCnt=3]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> o.a.i.i.binary.BinaryContext.registerUserClassName(BinaryContext.java:1202)
> at
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:366)
> at
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:189)
> at
> o.a.i.scenario.InvokeTask$MyEntryProcessor.process(InvokeTask.java:106)
> at
> o.a.i.i.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:446)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1302)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:713)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1103)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:405)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:367)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:171)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:156)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:118)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:198)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:196)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at o.a.i.i.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-955:
Comment: was deleted
(was: {panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2972857&buildTypeId=IgniteTests24Java8_RunAll])
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: PetrovMikhail
>Priority: Major
> Labels: Usability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-955:
Comment: was deleted
(was: {panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3067693&buildTypeId=IgniteTests24Java8_RunAll])
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: PetrovMikhail
>Priority: Major
> Labels: Usability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-955:
Comment: was deleted
(was: {panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2590568]]
* CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Hibernate 5.1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2590572]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Hibernate 4.2{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2590574]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2581698&buildTypeId=IgniteTests24Java8_RunAll])
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: PetrovMikhail
>Priority: Major
> Labels: Usability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771680#comment-16771680 ] Vasiliy Sisko commented on IGNITE-10214: 2-5 fixed. [~pkonstantinov]. Please test dependencies generation for different datasources. Especially after import of domain model. Check work with JDBC drivers that has JRE specification. Test loading of JDBC driver from central Maven repository for MS SQL Server. > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-955:
Fix Version/s: 2.8
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: PetrovMikhail
>Priority: Major
> Labels: Usability
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
Ilya Borisov created IGNITE-11353: - Summary: Web console: responses with status 401 do not redirect to signin page Key: IGNITE-11353 URL: https://issues.apache.org/jira/browse/IGNITE-11353 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov What happens: On page reload, when backend API responds with status of 401, the app is stuck on "loading" screen and does not redirect to signin screen. What should happen: The app should redirect to signin screen when 401 happens (except for a few exceptions). How to reproduce: 1. Sign in. 2. Kill user session in db. 3. Reload the page. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, abomic, communication
Vasiliy Sisko created IGNITE-11354: -- Summary: Web console: Actualize grid configurator discovery, store, abomic, communication Key: IGNITE-11354 URL: https://issues.apache.org/jira/browse/IGNITE-11354 Project: Ignite Issue Type: Improvement Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Result for class: org.apache.ignite.configuration.DataStorageConfiguration Missed maxWalArchiveSize checkpointReadLockTimeout walCompactionLevel Result for class: org.apache.ignite.configuration.AtomicConfiguration Missed groupName Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Missed nodeAttributes connectionRecoveryTimeout reconnectDelay Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi Missed usePairedConnections connectionsPerNode selectorSpins filterReachableAddresses Removed discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11355) Mention CacheConfiguration.sqlIndexMaxInlineSize and QueryGroupIndex.inlineSize in inline size suggestions
Stanislav Lukyanov created IGNITE-11355:
---
Summary: Mention CacheConfiguration.sqlIndexMaxInlineSize and
QueryGroupIndex.inlineSize in inline size suggestions
Key: IGNITE-11355
URL: https://issues.apache.org/jira/browse/IGNITE-11355
Project: Ignite
Issue Type: Improvement
Reporter: Stanislav Lukyanov
Currently the suggestion for changing inline size of the PK and AK indexes
reads like this
{code}
recommendation = "set system property "
+ IgniteSystemProperties.IGNITE_MAX_INDEX_PAYLOAD_SIZE + "
with recommended size " +
"(be aware it will be used by default for all indexes
without explicit inline size)";
{code}
However, there is also property CacheConfiguration.sqlIndexMaxInlineSize that
can be used. In fact, in most cases it is even better to use the cache
configuration property instead of the system property because 1) it is local,
not global 2) it is a part of the static configuration and doesn't depend of
the correct environment setup
The suggestion for other indexes reads
{code}
recommendation = "use INLINE_SIZE option for CREATE INDEX
command, " +
"QuerySqlField.inlineSize for annotated classes, or
QueryIndex.inlineSize for explicit " +
"QueryEntity configuration";
{code}
It should also mention QueryGroupIndex.inlineSize for group indexes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11355) Mention CacheConfiguration.sqlIndexMaxInlineSize and QueryGroupIndex.inlineSize in inline size suggestions
[
https://issues.apache.org/jira/browse/IGNITE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-11355:
--
Component/s: sql
> Mention CacheConfiguration.sqlIndexMaxInlineSize and
> QueryGroupIndex.inlineSize in inline size suggestions
> --
>
> Key: IGNITE-11355
> URL: https://issues.apache.org/jira/browse/IGNITE-11355
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> Currently the suggestion for changing inline size of the PK and AK indexes
> reads like this
> {code}
> recommendation = "set system property "
> + IgniteSystemProperties.IGNITE_MAX_INDEX_PAYLOAD_SIZE +
> " with recommended size " +
> "(be aware it will be used by default for all indexes
> without explicit inline size)";
> {code}
> However, there is also property CacheConfiguration.sqlIndexMaxInlineSize that
> can be used. In fact, in most cases it is even better to use the cache
> configuration property instead of the system property because 1) it is local,
> not global 2) it is a part of the static configuration and doesn't depend of
> the correct environment setup
> The suggestion for other indexes reads
> {code}
> recommendation = "use INLINE_SIZE option for CREATE INDEX
> command, " +
> "QuerySqlField.inlineSize for annotated classes, or
> QueryIndex.inlineSize for explicit " +
> "QueryEntity configuration";
> {code}
> It should also mention QueryGroupIndex.inlineSize for group indexes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10900) Print a warning if native persistence is used without an explicit consistent ID
[ https://issues.apache.org/jira/browse/IGNITE-10900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim reassigned IGNITE-10900: - Assignee: Stepachev Maksim > Print a warning if native persistence is used without an explicit consistent > ID > --- > > Key: IGNITE-10900 > URL: https://issues.apache.org/jira/browse/IGNITE-10900 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Stepachev Maksim >Priority: Major > > Experience shows that when Native Persistence is enabled, it is better to > explicitly set ConsistentIDs than use the autogenerated ones. > First, it simplifies managing the baseline topology. It is much easier to > manage it via control.sh when the nodes have stable and meaningful names. > Second, it helps to avoid certain shoot-yourself-in-the-foot issues. E.g. if > one loses all the data of a baseline node, when that node is restarted it > doesn't have its old autogenerated consistent ID - so it is not a part of the > baseline anymore. This may be unexpected and confusing. > Finally, having explicit consistent IDs improves the general stability of the > setup - one knows what the the set of nodes, where they run and what they're > called. > All in all, it seems beneficial to urge users to explicitly configure > consistent IDs. We can do this by introducing a warning that is printed every > time a new consistent ID is automatically generated. It should also be > printed when a node doesn't have an explicit consistent ID and picks up one > from an existing peristence folder. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11355) Mention CacheConfiguration.sqlIndexMaxInlineSize and QueryGroupIndex.inlineSize in inline size suggestions
[
https://issues.apache.org/jira/browse/IGNITE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-11355:
--
Ignite Flags: (was: Docs Required)
> Mention CacheConfiguration.sqlIndexMaxInlineSize and
> QueryGroupIndex.inlineSize in inline size suggestions
> --
>
> Key: IGNITE-11355
> URL: https://issues.apache.org/jira/browse/IGNITE-11355
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> Currently the suggestion for changing inline size of the PK and AK indexes
> reads like this
> {code}
> recommendation = "set system property "
> + IgniteSystemProperties.IGNITE_MAX_INDEX_PAYLOAD_SIZE +
> " with recommended size " +
> "(be aware it will be used by default for all indexes
> without explicit inline size)";
> {code}
> However, there is also property CacheConfiguration.sqlIndexMaxInlineSize that
> can be used. In fact, in most cases it is even better to use the cache
> configuration property instead of the system property because 1) it is local,
> not global 2) it is a part of the static configuration and doesn't depend of
> the correct environment setup
> The suggestion for other indexes reads
> {code}
> recommendation = "use INLINE_SIZE option for CREATE INDEX
> command, " +
> "QuerySqlField.inlineSize for annotated classes, or
> QueryIndex.inlineSize for explicit " +
> "QueryEntity configuration";
> {code}
> It should also mention QueryGroupIndex.inlineSize for group indexes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8571) Baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771723#comment-16771723 ] Dmitriy Govorukhin commented on IGNITE-8571: [~akalashnikov], [~ibessonov] Many thanks, LGTM, merged to master. > Baseline auto-adjust feature > > > Key: IGNITE-8571 > URL: https://issues.apache.org/jira/browse/IGNITE-8571 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Now we have only one way to change BLAT - manually update it via console.sh > or API. > We need to add the possibility to change it automatically. Adjust to current > topology. > So, I propose 2 new distributed parameters which would be responsible to tune > this feature. > 1. Flag autoAdjustEnabled - true/false. Easy. Manual baseline control or auto > adjusting baseline. > 2. autoAdjustTimeout - time which we would wait after the actual topology > change. But it would be reset if new discovery event happened. (node > join/exit). > We need to change API next way: > org.apache.ignite.IgniteCluster: > * isBaselineAutoAdjustEnabled() > * setBaselineAutoAdjustEnabled(boolean enabled); > * setBaselineAutoAdjustTimeout(long timeoutInMs); > Also, we need to ensure that all nodes would have the same > parameters(distributed parameters). > And we should be able to survive coordinator left during parameters changes. > When autoAdjustEnabled is true we should be block ability to manual baseline > change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11353: -- Description: What happens: On page reload, when backend API responds with status of 401, the app is stuck on "loading" screen and does not redirect to signin screen. What should happen: The app should redirect to signin screen when 401 happens (except for a few exceptions). How to reproduce: 1. Sign out. 2. Open profile page URL (/settings/profile). was: What happens: On page reload, when backend API responds with status of 401, the app is stuck on "loading" screen and does not redirect to signin screen. What should happen: The app should redirect to signin screen when 401 happens (except for a few exceptions). How to reproduce: 1. Sign in. 2. Kill user session in db. 3. Reload the page. > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8575) Change Baseline auto-adjust parameters via console.sh
[ https://issues.apache.org/jira/browse/IGNITE-8575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771732#comment-16771732 ] Anton Kalashnikov commented on IGNITE-8575: --- [~ibessonov] looks good for me. Thanks for contribution. > Change Baseline auto-adjust parameters via console.sh > - > > Key: IGNITE-8575 > URL: https://issues.apache.org/jira/browse/IGNITE-8575 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We would introduce at IGNITE-8571 new parameters. > We need to have option change them via console.sh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11050) Potential deadlock caused by DhtColocatedLockFuture#map being called inside topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771742#comment-16771742
]
Alexey Goncharuk commented on IGNITE-11050:
---
[~mstepachev], I see a consistent fails of the DataStructures and
ContinuousQueries suites with OOME, I think the change introduced a regression.
Please take a look (probably it was fixed in master, so pull the latest changes
first).
> Potential deadlock caused by DhtColocatedLockFuture#map being called inside
> topology read lock
> --
>
> Key: IGNITE-11050
> URL: https://issues.apache.org/jira/browse/IGNITE-11050
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observed the following stacktrace on TC during tests analysis:
> {code}
> Thread
> [name="exchange-worker-#18471%near.GridCachePartitionedNodeRestartTest0%",
> id=23715, state=WAITING, blockCnt=860, waitCnt=775]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2bfb6b49,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:173)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:142)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:925)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:826)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:70)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:89)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:1019)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:544)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.txUnlock(IgniteTxManager.java:1764)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1775)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1347)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1075)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3602)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:440)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:390)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3784)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4409)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4399)
> at o.a.i.i.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> o.a.i.i.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFu
[jira] [Assigned] (IGNITE-11050) Potential deadlock caused by DhtColocatedLockFuture#map being called inside topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-11050:
-
Assignee: Stepachev Maksim (was: Alexey Goncharuk)
> Potential deadlock caused by DhtColocatedLockFuture#map being called inside
> topology read lock
> --
>
> Key: IGNITE-11050
> URL: https://issues.apache.org/jira/browse/IGNITE-11050
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Stepachev Maksim
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observed the following stacktrace on TC during tests analysis:
> {code}
> Thread
> [name="exchange-worker-#18471%near.GridCachePartitionedNodeRestartTest0%",
> id=23715, state=WAITING, blockCnt=860, waitCnt=775]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2bfb6b49,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:173)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:142)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:925)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:826)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:70)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:89)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:1019)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:544)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.txUnlock(IgniteTxManager.java:1764)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1775)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1347)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1075)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3602)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:440)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:390)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3784)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4409)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4399)
> at o.a.i.i.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> o.a.i.i.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> o.a.i.i.util.futu
[jira] [Commented] (IGNITE-11050) Potential deadlock caused by DhtColocatedLockFuture#map being called inside topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771748#comment-16771748
]
Ignite TC Bot commented on IGNITE-11050:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3114341]]
* ZookeeperDiscoveryClientDisconnectTest.testStartNoServer_WaitForServers2
(last started)
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3114330]]
* GridServiceInjectionSpringResourceTest.testDeployServiceWithSpring (last
started)
{color:#d04437}Data Structures{color} [[tests 0 TIMEOUT , Out Of Memory Error ,
Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3114379]]
* GridCachePartitionedAtomicSequenceMultiThreadedTest.testMixed2 (last started)
{color:#d04437}Continuous Query 1{color} [[tests 0 TIMEOUT , Out Of Memory
Error , Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3114313]]
*
CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatePartitionMvccTxCacheGroup
(last started)
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3114419&buildTypeId=IgniteTests24Java8_RunAll]
> Potential deadlock caused by DhtColocatedLockFuture#map being called inside
> topology read lock
> --
>
> Key: IGNITE-11050
> URL: https://issues.apache.org/jira/browse/IGNITE-11050
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Stepachev Maksim
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observed the following stacktrace on TC during tests analysis:
> {code}
> Thread
> [name="exchange-worker-#18471%near.GridCachePartitionedNodeRestartTest0%",
> id=23715, state=WAITING, blockCnt=860, waitCnt=775]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2bfb6b49,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:173)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:142)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:925)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:826)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:70)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:89)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:1019)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:544)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.txUnlock(IgniteTxManager.java:1764)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1775)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1347)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1075)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3602)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:440)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:390)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> o.a.i.i
[jira] [Created] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
Ivan Pavlukhin created IGNITE-11356:
---
Summary: Test framework: Remove custom assumption exceptions
handling
Key: IGNITE-11356
URL: https://issues.apache.org/jira/browse/IGNITE-11356
Project: Ignite
Issue Type: Task
Reporter: Ivan Pavlukhin
It turns out that custom handling of {{AssumptionViolatedException}} can be
removed. Currently with custom handling tests with unmet assumptions are marked
as passed. With default handling failed assumptions on instance level mark
tests as ignored.
Note: on class level reporting in case of unmet assumptions does not look
perfect. But with custom handling a particular test is not included into TC
report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11328) Ignite binary build is too big
[
https://issues.apache.org/jira/browse/IGNITE-11328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Platonov reassigned IGNITE-11328:
Assignee: Alexey Platonov (was: Yury Babak)
> Ignite binary build is too big
> --
>
> Key: IGNITE-11328
> URL: https://issues.apache.org/jira/browse/IGNITE-11328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Sergey Kozlov
>Assignee: Alexey Platonov
>Priority: Blocker
> Fix For: 2.8
>
>
> I built Apache Ignite and get zip file is ~ 800MB.
> +400MB added by 4 ML modules in {{libs/optional}}
> Looks like it should be redesigned (join in a single module and at least it
> will remove same deps)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771750#comment-16771750 ] Ilya Borisov commented on IGNITE-11353: --- The issue was caused by wrong state name. When 401 happens, the app redirects to '403', which doesn't exist, instead of 'base.403'. The '403' was moved to 'base.403' not so long ago, so this is probably the root of it. After fixing that, I found another related bug: timed-redirect component used for 403 screen did not redirect anywhere if user wasn't authorized, so I added an extra check for user authorization and redirect to 'signin' state if not. > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771750#comment-16771750 ] Ilya Borisov edited comment on IGNITE-11353 at 2/19/19 9:27 AM: The issue was caused by wrong state name. When 401 happens, the app redirects to '403', which doesn't exist, instead of 'base.403'. The '403' was moved to 'base.403' not so long ago, so this is probably the root of it. After fixing that, I found another related bug: timed-redirect component used for 403 screen did not redirect anywhere if user wasn't authorized, so I added an extra check for user authorization and redirect to 'signin' state if not. What to test: 1. The app redirects to 403 when attempting to open a valid URL without being logged in. 2. After #1 happens, 403 page should redirect to sign in screen. was (Author: klaster_1): The issue was caused by wrong state name. When 401 happens, the app redirects to '403', which doesn't exist, instead of 'base.403'. The '403' was moved to 'base.403' not so long ago, so this is probably the root of it. After fixing that, I found another related bug: timed-redirect component used for 403 screen did not redirect anywhere if user wasn't authorized, so I added an extra check for user authorization and redirect to 'signin' state if not. > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-11353: - Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10928) After huge load on cluster and restart with walCompactionEnabled=True errors on log
[
https://issues.apache.org/jira/browse/IGNITE-10928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771753#comment-16771753
]
Pavel Voronkin commented on IGNITE-10928:
-
Looks good to me
> After huge load on cluster and restart with walCompactionEnabled=True errors
> on log
> ---
>
> Key: IGNITE-10928
> URL: https://issues.apache.org/jira/browse/IGNITE-10928
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.5
>Reporter: ARomantsov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
>
> class="org.apache.ignite.configuration.DataRegionConfiguration">
>
>
>
>
>
> {code}
> {code:java}
> [15:30:56,809][INFO][wal-file-compressor-%null%-1-#68][FileWriteAheadLogManager]
> Stopping WAL iteration due to an exception: Failed to read WAL record at
> position: 28310114 size: -1, ptr=FileWALPointer [idx=35, fileOff=28310114,
> len=0]
> [15:30:56,811][INFO][wal-file-compressor-%null%-3-#70][FileWriteAheadLogManager]
> Stopping WAL iteration due to an exception: Failed to read WAL record at
> position: 28303753 size: -1, ptr=FileWALPointer [idx=36, fileOff=28303753,
> len=0]
> [15:30:56,811][SEVERE][wal-file-compressor-%null%-1-#68][FileWriteAheadLogManager]
> Compression of WAL segment [idx=35] was skipped due to unexpected error
> class org.apache.ignite.IgniteCheckedException: Failed to read WAL record at
> position: 28310114 size: -1
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.handleRecordException(AbstractWalRecordsIterator.java:292)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advanceRecord(AbstractWalRecordsIterator.java:258)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advance(AbstractWalRecordsIterator.java:154)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SingleSegmentLogicalRecordsIterator.advance(SingleSegmentLogicalRecordsIterator.java:119)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:123)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:52)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:41)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.compressSegmentToFile(FileWriteAheadLogManager.java:2039)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:1974)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:1950)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to read WAL
> record at position: 28310114 size: -1
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readWithCrc(RecordV1Serializer.java:394)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer.readRecord(RecordV2Serializer.java:235)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advanceRecord(AbstractWalRecordsIterator.java:243)
> ... 10 more
> Caused by: java.nio.channels.ClosedByInterruptException
> at
> java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
> at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:164)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.RandomAccessFileIO.read(RandomAccessFileIO.java:58)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FileIODecorator.read(FileIODecorator.java:51)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.io.SimpleFileInput.ensure(SimpleFileInput.java:119)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.io.FileInput$Crc32CheckingFileInput.ensure(FileInput.java:89)
> at
> org.apache.ignite.internal.processors.cache.persi
[jira] [Created] (IGNITE-11357) MVCC: SQL tx operations and DDL inside tx block
Ivan Pavlukhin created IGNITE-11357:
---
Summary: MVCC: SQL tx operations and DDL inside tx block
Key: IGNITE-11357
URL: https://issues.apache.org/jira/browse/IGNITE-11357
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Ivan Pavlukhin
DLL and special tx (BEGIN, COMMIT) and DDL operations does not behave well
inside explicit tx started using Java API. We should define how such operations
behave inside tx or forbid them inside tx. See test
{{SqlTransactionsCommandsWithMvccEnabledSelfTest#testSqlOperationsWithinNonSqlTransaction}}.
Here is an example of problematic construction:
{code}
try (Transaction tx = node.transactions().txStart(PESSIMISTIC, SERIALIZABLE)) {
cache.put(1, 1);
cache.query(new SqlFieldsQuery("commit"));
cache.put(2, 2);
tx.commit();
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[ https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-10179: Labels: MakeTeamcityGreenAgain (was: ) > Change new tests root to use @BeforeClass and @AfterClass instead of > isFirstTest() and isLastTest() > --- > > Key: IGNITE-10179 > URL: https://issues.apache.org/jira/browse/IGNITE-10179 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > If needed, refer parent task for more details. > isFirstTest() and isLastTest() homebrew methods seem to be in > GridAbstractTest only because Junit 3 lacked necessary functionality; after > migration to Junit 4 these would better changed to use standard API of this > framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[ https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-10179: Labels: (was: MakeTeamcityGreenAgain) > Change new tests root to use @BeforeClass and @AfterClass instead of > isFirstTest() and isLastTest() > --- > > Key: IGNITE-10179 > URL: https://issues.apache.org/jira/browse/IGNITE-10179 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > If needed, refer parent task for more details. > isFirstTest() and isLastTest() homebrew methods seem to be in > GridAbstractTest only because Junit 3 lacked necessary functionality; after > migration to Junit 4 these would better changed to use standard API of this > framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11356:
Labels: MakeTeamcityGreenAgain (was: )
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11357) MVCC: SQL tx operations and DDL inside tx block
[
https://issues.apache.org/jira/browse/IGNITE-11357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11357:
Description:
DDL and special tx (BEGIN, COMMIT) operations does not behave well inside
explicit tx started using Java API. We should define how such operations behave
inside tx or forbid them inside tx. See test
{{SqlTransactionsCommandsWithMvccEnabledSelfTest#testSqlOperationsWithinNonSqlTransaction}}.
Here is an example of problematic construction:
{code}
try (Transaction tx = node.transactions().txStart(PESSIMISTIC, SERIALIZABLE)) {
cache.put(1, 1);
cache.query(new SqlFieldsQuery("commit"));
cache.put(2, 2);
tx.commit();
}
{code}
was:
DLL and special tx (BEGIN, COMMIT) and DDL operations does not behave well
inside explicit tx started using Java API. We should define how such operations
behave inside tx or forbid them inside tx. See test
{{SqlTransactionsCommandsWithMvccEnabledSelfTest#testSqlOperationsWithinNonSqlTransaction}}.
Here is an example of problematic construction:
{code}
try (Transaction tx = node.transactions().txStart(PESSIMISTIC, SERIALIZABLE)) {
cache.put(1, 1);
cache.query(new SqlFieldsQuery("commit"));
cache.put(2, 2);
tx.commit();
}
{code}
> MVCC: SQL tx operations and DDL inside tx block
> ---
>
> Key: IGNITE-11357
> URL: https://issues.apache.org/jira/browse/IGNITE-11357
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> DDL and special tx (BEGIN, COMMIT) operations does not behave well inside
> explicit tx started using Java API. We should define how such operations
> behave inside tx or forbid them inside tx. See test
> {{SqlTransactionsCommandsWithMvccEnabledSelfTest#testSqlOperationsWithinNonSqlTransaction}}.
> Here is an example of problematic construction:
> {code}
> try (Transaction tx = node.transactions().txStart(PESSIMISTIC, SERIALIZABLE))
> {
> cache.put(1, 1);
> cache.query(new SqlFieldsQuery("commit"));
> cache.put(2, 2);
> tx.commit();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project
[
https://issues.apache.org/jira/browse/IGNITE-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771779#comment-16771779
]
Maxim Muzafarov commented on IGNITE-11277:
--
An example of the failed build if checkstyle rules have been violated:
https://ci.ignite.apache.org/viewLog.html?buildId=3123738&buildTypeId=IgniteTests24Java8_BuildApacheIgnite&tab=buildLog&branch_IgniteTests24Java8=pull%2F6134%2Fhead
{code}
[12:57:24] [Step 3/4] [INFO] Starting audit...
[12:57:24] [Step 3/4] [ERROR]
/data/teamcity/work/9198da4c51c3e112/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/IgniteDhtDemandedPartitionsMap.java:23:8:
Unused import - java.util.List. [UnusedImports]
[12:57:24] [Step 3/4] [ERROR]
/data/teamcity/work/9198da4c51c3e112/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/IgniteDhtDemandedPartitionsMap.java:37:1:
File contains tab characters (this is the first instance). [FileTabCharacter]
[12:57:24] [Step 3/4] Audit done.
[12:57:24] [Step 3/4] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (check-style) on
project ignite-core: Failed during checkstyle execution
[12:57:24] [Step 3/4] [INFO]
[12:57:24] [Step 3/4] [INFO] Reactor Summary:
[12:57:24] [Step 3/4] [INFO]
[12:57:24] [Step 3/4] [INFO] ignite-apache-license-gen
.. SUCCESS [ 1.540 s]
[12:57:24] [Step 3/4] [INFO] ignite-tools
... SUCCESS [ 22.872 s]
[12:57:24] [Step 3/4] [INFO] ignite-core
FAILURE [ 56.216 s]
[12:57:24] [Step 3/4] [INFO] ignite-compress
SKIPPED
[12:57:24] [Step 3/4] [INFO] ignite-indexing
SKIPPED
{code}
> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough.
> The suite has a {{FAILED}} status for more than 2 months due to some issues
> on TeamCity application [2]. It confuses most of the members of the Apache
> Ignite community.
> Moreover, this suite is no longer checks configured rules. For instance, in
> the master branch, 11 {{Unused imports}} can be found (e.g. for
> {{IgniteCachePutAllRestartTest}
> [3]).
> I think the maven-checkstyle-plugin should be used as the default code style
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11352) Compatibility with 2.7 with mode: statistics enabled
[ https://issues.apache.org/jira/browse/IGNITE-11352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim updated IGNITE-11352: -- Description: The problem was founded, there are incompatible changes in serialization between 2.4 and 2.7 versions. The root of the problem is CacheMetricsSnapshot. was: The problem was founded when we performed a rolling upgrade from 2.4 to 2.7. The root of the problem is CacheMetricsSnapshot, it doesn't work with the previous version of the protocol. > Compatibility with 2.7 with mode: statistics enabled > - > > Key: IGNITE-11352 > URL: https://issues.apache.org/jira/browse/IGNITE-11352 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.7 > > Time Spent: 10m > Remaining Estimate: 0h > > The problem was founded, there are incompatible changes in serialization > between 2.4 and 2.7 versions. The root of the problem is CacheMetricsSnapshot. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11058) Possible OOM due to large discard queue in TcpDiscoverySpi
[ https://issues.apache.org/jira/browse/IGNITE-11058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-11058: --- Assignee: Sergey Antonov > Possible OOM due to large discard queue in TcpDiscoverySpi > -- > > Key: IGNITE-11058 > URL: https://issues.apache.org/jira/browse/IGNITE-11058 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > Currently it's necessary to store every ensured (marked with > TcpDiscoveryEnsureDelivery annotation) in pending message queue until it's > discarded from coordinator for implementing guaranteed delivery, otherwise if > subsequent nodes will fail while forwarding message the guarantee couldn't be > fulfilled. > On large topologies with active changes the queue may contain many very large > messages causing heap usage bursts and possible OOM. > Possible solution: > # off-load pending messages payload to off-heap or even on disk. > # store messages in serialized form for avoiding JVM Object overhead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project
[
https://issues.apache.org/jira/browse/IGNITE-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771809#comment-16771809
]
Maxim Muzafarov commented on IGNITE-11277:
--
[~NIzhikov],
Hello, can you please review my changes?
PR has been prepared.
> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough.
> The suite has a {{FAILED}} status for more than 2 months due to some issues
> on TeamCity application [2]. It confuses most of the members of the Apache
> Ignite community.
> Moreover, this suite is no longer checks configured rules. For instance, in
> the master branch, 11 {{Unused imports}} can be found (e.g. for
> {{IgniteCachePutAllRestartTest}
> [3]).
> I think the maven-checkstyle-plugin should be used as the default code style
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11313) Cluster hangs on cache invoke with binary objects creation
[
https://issues.apache.org/jira/browse/IGNITE-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771818#comment-16771818
]
Sergey Chugunov commented on IGNITE-11313:
--
[~ibessonov],
I reviewed your changes: great idea to include future to exception! Really like
this approach.
I left minor comment about exception naming and usage, when it is fixed, please
proceed with merge.
Thank you for the patch!
> Cluster hangs on cache invoke with binary objects creation
> --
>
> Key: IGNITE-11313
> URL: https://issues.apache.org/jira/browse/IGNITE-11313
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Creating of binary objects in entry processors in parallel with continuous
> queries may lead to deadlock:
> {code:java}
> [2019-02-11 18:52:50,129][WARN ][grid-timeout-worker-#39] >>> Possible
> starvation in striped pool.
> Thread name: sys-stripe-13-#14
> Queue: []
> Deadlock: false
> Completed: 1
> Thread [name="sys-stripe-13-#14", id=33, state=WAITING, blockCnt=3, waitCnt=3]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> o.a.i.i.binary.BinaryContext.registerUserClassName(BinaryContext.java:1202)
> at
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:366)
> at
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:189)
> at
> o.a.i.scenario.InvokeTask$MyEntryProcessor.process(InvokeTask.java:106)
> at
> o.a.i.i.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:446)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1302)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:713)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1103)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:405)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:367)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:171)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:156)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:118)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:198)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:196)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at o.a.i.i.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-11356:
---
Assignee: Ivan Pavlukhin
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10161) Be able to cancel any query by query id
[
https://issues.apache.org/jira/browse/IGNITE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771854#comment-16771854
]
Yury Gerzhedovich commented on IGNITE-10161:
[~vozerov], merged and refactored according to last master changes. Waiting TC
Bot vise.
> Be able to cancel any query by query id
> ---
>
> Key: IGNITE-10161
> URL: https://issues.apache.org/jira/browse/IGNITE-10161
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User should be able to cancel any query by query id through SQL command.
> SQL syntax: *KILL QUERY '<_query_id>' \{ASYNC}_*
> _ASYNC_ is optional parameter which return control immediately without
> waiting real cancellation will be done.
> By default, without ASYNC parameter, the request is blocking untill
> cancellation is not done.
> Query should be canceled together with its parts on all nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-10414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771860#comment-16771860
]
Ignite TC Bot commented on IGNITE-10414:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3123498&buildTypeId=IgniteTests24Java8_RunAll]
> IF NOT EXISTS in CREATE TABLE doesn't work
> --
>
> Key: IGNITE-10414
> URL: https://issues.apache.org/jira/browse/IGNITE-10414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4, 2.6, 2.7
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
>
> {code:java}
>Ignite ignite = Ignition.start();
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> {code}
> Error:
> {code:java}
> (err) DDL operation failureSchemaOperationException [code=3, msg=Table
> already exists: CITY]
> at
> org.apache.ignite.internal.processors.query.QueryUtils.checkQueryEntityConflicts(QueryUtils.java:1214)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:351)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2203)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2164)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2125)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Exception in thread "main" javax.cache.CacheException: Table already exists:
> CITY
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Table already
> exists: CITY
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:642)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:503)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.ap
[jira] [Updated] (IGNITE-11337) Ignite .NET - Remote Assembly Loading problem when using Data Streamers
[
https://issues.apache.org/jira/browse/IGNITE-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ondrej Rysavy updated IGNITE-11337:
---
Labels: .NET .net-core (was: )
> Ignite .NET - Remote Assembly Loading problem when using Data Streamers
> ---
>
> Key: IGNITE-11337
> URL: https://issues.apache.org/jira/browse/IGNITE-11337
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Apache Ignite 2.7.0 installed from NuGet, running on
> Windows 10.
> Ignite server executed as:
> {{...\.nuget\packages\apache.ignite\2.7.0\lib\net40>Apache.Ignite.exe}}
> The test console program (.NET 4.6 target) attached.
>Reporter: Ondrej Rysavy
>Priority: Major
> Labels: .NET, .net-core
> Attachments: Program.cs
>
>
> When using data streaming, the server raises "IgniteException: No matching
> type found for object [typeId=721826618,
> typeName=StreamingDemo.StringPairVisitor]".
> StreamingDemo.StringPairVisitor implements IStreamReceiver interface (see the
> attached file).
> {{}}Neither suggested solution works (remote assembly loading, -assembly
> argument, etc.)
> The possible workaround is to execute some compute action prior to streaming.
> Then everything works as expected.
> In general, it seems that Streaming itself does not load the necessary
> assembly to locate the matching type implementing custom logic for stream
> processing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11352) CacheMetricsSnapshot deserialization may be broken in some cases
[ https://issues.apache.org/jira/browse/IGNITE-11352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11352: -- Summary: CacheMetricsSnapshot deserialization may be broken in some cases (was: Compatibility with 2.7 with mode: statistics enabled) > CacheMetricsSnapshot deserialization may be broken in some cases > > > Key: IGNITE-11352 > URL: https://issues.apache.org/jira/browse/IGNITE-11352 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.7 > > Time Spent: 10m > Remaining Estimate: 0h > > The problem was founded, there are incompatible changes in serialization > between 2.4 and 2.7 versions. The root of the problem is CacheMetricsSnapshot. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11352) CacheMetricsSnapshot deserialization may be broken in some cases
[ https://issues.apache.org/jira/browse/IGNITE-11352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11352: -- Description: There is an incompatible changes in CacheMetricsSnapshot serialization between 2.4 and 2.7 versions. This may affect users if the event is being stored to some external storage. The fix should be fairly simple as there is already some code that checks the stream contents. was: The problem was founded, there are incompatible changes in serialization between 2.4 and 2.7 versions. The root of the problem is CacheMetricsSnapshot. > CacheMetricsSnapshot deserialization may be broken in some cases > > > Key: IGNITE-11352 > URL: https://issues.apache.org/jira/browse/IGNITE-11352 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.7 > > Time Spent: 10m > Remaining Estimate: 0h > > There is an incompatible changes in CacheMetricsSnapshot serialization > between 2.4 and 2.7 versions. This may affect users if the event is being > stored to some external storage. The fix should be fairly simple as there is > already some code that checks the stream contents. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10693) MVCC TX: Random server restart tests became failed
[ https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771891#comment-16771891 ] Igor Seliverstov commented on IGNITE-10693: --- At now everything points to the fact the root cause is an issue in rebalance logic. Need to put the task on hold until IGNITE-10561 is resolved. > MVCC TX: Random server restart tests became failed > -- > > Key: IGNITE-10693 > URL: https://issues.apache.org/jira/browse/IGNITE-10693 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Labels: failover, mvcc_stabilization_stage_1 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7945125576049372508&branch=%3Cdefault%3E&tab=testDetails], > > [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8412476034648229784&branch=%3Cdefault%3E&tab=testDetails], > > [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&branch=%3Cdefault%3E&tab=testDetails], > all these tests became failed after IGNITE-9630 has been merged to master. > Seems there is an issue in partition calculating mechanism on unstable > topology. I suppose the algorithm uses partitions on nodes just become > primary while the partitions are in moving state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10693) MVCC TX: Random server restart tests became failed
[ https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771891#comment-16771891 ] Igor Seliverstov edited comment on IGNITE-10693 at 2/19/19 12:51 PM: - After fixing mapping logic the affected tests become much stable. However some failures are still there (inconsistent reads on unstable topology). It can be easily reproduced increasing keys count in test scenarios. At now everything points to the fact the root cause is an issue in rebalance logic. Need to put the task on hold until IGNITE-10561 is resolved. was (Author: gvvinblade): At now everything points to the fact the root cause is an issue in rebalance logic. Need to put the task on hold until IGNITE-10561 is resolved. > MVCC TX: Random server restart tests became failed > -- > > Key: IGNITE-10693 > URL: https://issues.apache.org/jira/browse/IGNITE-10693 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Labels: failover, mvcc_stabilization_stage_1 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7945125576049372508&branch=%3Cdefault%3E&tab=testDetails], > > [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8412476034648229784&branch=%3Cdefault%3E&tab=testDetails], > > [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&branch=%3Cdefault%3E&tab=testDetails], > all these tests became failed after IGNITE-9630 has been merged to master. > Seems there is an issue in partition calculating mechanism on unstable > topology. I suppose the algorithm uses partitions on nodes just become > primary while the partitions are in moving state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11348) Ping node procedure may fail when another node leaves the cluster
[
https://issues.apache.org/jira/browse/IGNITE-11348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771916#comment-16771916
]
Ignite TC Bot commented on IGNITE-11348:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3116051&buildTypeId=IgniteTests24Java8_RunAll]
> Ping node procedure may fail when another node leaves the cluster
> -
>
> Key: IGNITE-11348
> URL: https://issues.apache.org/jira/browse/IGNITE-11348
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.8
>
>
> Additional pinging of node on join implemented in IGNITE-5569 may incorrectly
> fail leading to shutting down joining node.
> The reason for this is that if another node from the same host bound to the
> same discovery port as joining node has left the cluster right before joining
> node, socket used for pinging gets closed.
> This leads to the situation when pinging node considers joining node as
> "unreachable" and fails it with JOIN_IMPOSSIBLE error code.
> Workaround: simply start again node failed on join.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11243) Not working control.sh / control.bat in master NPE in output
[ https://issues.apache.org/jira/browse/IGNITE-11243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11243: -- Ignite Flags: (was: Docs Required) > Not working control.sh / control.bat in master NPE in output > > > Key: IGNITE-11243 > URL: https://issues.apache.org/jira/browse/IGNITE-11243 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: ARomantsov >Assignee: Sergey Kosarev >Priority: Blocker > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ./bin/control.sh --host --port --baseline > Cluster state: active > Error: java.lang.NullPointerException > control.bat --host --port --baseline > Cluster state: active > Error: java.lang.NullPointerException > Press any key to continue . . . > No info in cluster logs matched with call, look like problem in utility run > This bug was introuced by IGNITE-8894 and reproduced when new utility runs on > an old version node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7948) SQL: read only necessary fields into the row when possible
[
https://issues.apache.org/jira/browse/IGNITE-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771924#comment-16771924
]
Ignite TC Bot commented on IGNITE-7948:
---
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3113559&buildTypeId=IgniteTests24Java8_RunAll]
> SQL: read only necessary fields into the row when possible
> --
>
> Key: IGNITE-7948
> URL: https://issues.apache.org/jira/browse/IGNITE-7948
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
>
> When H2 row is read, we always fill it with data eagerly through link
> materialization. Materialization is performed under page "read lock" what
> guarantees row-level consistency. This may lead to excessive memory pressure
> due to memory copying. For example, consider a class with 50 fields and a
> query which reads only 2 of them. 48 other fields will be copied without a
> reason. Lazy initialization is not an option because it will only defer
> memcpy, but not eliminate it.
> Instead we can try using H2. It passes {{TableFilter}} class to some of index
> access methods*. We can analyze this class and create the list of required
> fields. Then we can read these fields under read lock from offheap and put
> them to the row.
> In addition to saved memcpy this could give us more benefits:
> 1) No more need for field cache ({{GridH2KeyValueRowOnheap#valCache}})
> 2) No more need to read {{_VER}} column and possibly {{_KEY}} or {{_VAL}}
> But there are a number of drawbacks as well. E.g. it is impossible to read
> strings from offheap efficiently, so queries with VARCHAR will definitely
> suffer from this change.
> \* {{org.h2.index.Index#find(org.h2.table.TableFilter,
> org.h2.result.SearchRow, org.h2.result.SearchRow)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11358) Bug in ZK tests occurs periodically
Pavel Voronkin created IGNITE-11358: --- Summary: Bug in ZK tests occurs periodically Key: IGNITE-11358 URL: https://issues.apache.org/jira/browse/IGNITE-11358 Project: Ignite Issue Type: Bug Reporter: Pavel Voronkin java.lang.NullPointerException at org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.allNodesSupport(ZookeeperDiscoverySpi.java:342) at org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.isHandshakeWaitSupported(TcpCommunicationSpi.java:4109) at org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$400(TcpCommunicationSpi.java:277) at org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2.onConnected(TcpCommunicationSpi.java:430) at org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionOpened(GridNioFilterChain.java:251) at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88) at org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionOpened(GridNioCodecFilter.java:66) at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88) at org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionOpened(GridConnectionBytesVerifyFilter.java:58) at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88) at org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionOpened(GridNioServer.java:3525) at org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionOpened(GridNioFilterChain.java:139) at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.register(GridNioServer.java:2639) at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1997) at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1818) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11255) Fix test failure after IGNITE-7648.
[ https://issues.apache.org/jira/browse/IGNITE-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771928#comment-16771928 ] Pavel Voronkin commented on IGNITE-11255: - I've found another bug running tests related to AllNodesSupport is called while Spi is not initialized. > Fix test failure after IGNITE-7648. > --- > > Key: IGNITE-11255 > URL: https://issues.apache.org/jira/browse/IGNITE-11255 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Labels: MakeTeamcityGreenAgain > Time Spent: 10m > Remaining Estimate: 0h > > We need to fix: > > * > CacheQueriesRestartServerTest.Test_ScanQueryAfterClientReconnect_ReturnsResults(False) > * ZookeeperDiscoveryClientDisconnectTest.testReconnectServersRestart_3 > * IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11359) Improvement of tests. Add additional state check after each test.
Stepachev Maksim created IGNITE-11359: - Summary: Improvement of tests. Add additional state check after each test. Key: IGNITE-11359 URL: https://issues.apache.org/jira/browse/IGNITE-11359 Project: Ignite Issue Type: Improvement Reporter: Stepachev Maksim Assignee: Stepachev Maksim Sometimes, the Flaky tests are interrupted with OOM. There are many reasons for it, but the main is a memory leak in transactions. The good way of fast problem detection will additionally check of maps with transaction futures after a test. It must be empty. Add this logic into GridCommonAbstractTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11195) Platform C++ tests failed to find JVM for Java 11 build
[
https://issues.apache.org/jira/browse/IGNITE-11195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771965#comment-16771965
]
Dmitriy Pavlov commented on IGNITE-11195:
-
After a private talk with [~vveider] I've double-checked C++ runs in the new
branch from master to include the following fix
https://github.com/apache/ignite/commit/033170d90f6c0618b9d6a3fd997e13a5ec1fff89
But currently tests still failed
1. Here no tests were executed:
/usr/bin/ld: cannot find -ljvm
https://ci.ignite.apache.org/viewLog.html?buildId=3117416&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformCLinux
2. Here all tests failed again:
std::exception: JVM library is not found (did you set JAVA_HOME environment
variable?)
https://ci.ignite.apache.org/viewLog.html?buildId=3117417&buildTypeId=IgniteTests24Java8_PlatformCWinX64Release
(it is really strange because 2 runs gave different outputs
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWinX64Release&branch_IgniteTests24Java8=ignite-11195-test&tab=buildTypeStatusDiv
)
[~isapego], [~vveider] could you please step in again?
> Platform C++ tests failed to find JVM for Java 11 build
> ---
>
> Key: IGNITE-11195
> URL: https://issues.apache.org/jira/browse/IGNITE-11195
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Priority: Major
>
> 482 C++ tests failed with error
> {noformat}
> std::exception: JVM library is not found (did you set JAVA_HOME environment
> variable?)
> {noformat}
> https://ci.ignite.apache.org/viewLog.html?buildId=2973675&buildTypeId=IgniteTests24Java8_PlatformCWinX64Release&tab=buildResultsDiv&branch_IgniteTests24Java8=ignite-11155
> Looks like we need somehow handle new parameters in C++ tests
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9947) JDBC thin: Batch update is not performed if streaming state changed before executeBatch()
[
https://issues.apache.org/jira/browse/IGNITE-9947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771099#comment-16771099
]
Taras Ledkov edited comment on IGNITE-9947 at 2/19/19 2:32 PM:
---
[~pkouznet], [~vozerov].
The test looks like invalid a bit:
after the first {{fillParamsWithPerson(pstmt, 1);}} the batch wasn't added.
If the {{pstmt.addBatch();}} is added after this line, the second call of the
{{addBatch}} throws:
{{java.sql.SQLException: Statement has non-empty batch (call executeBatch() or
clearBatch() before enabling streaming).}}
I guess this is valid behavior because STREAMING mode is Ignite-specific.
I propose to close issue with *Not a Bug* or *Invalid*.
was (Author: tledkov-gridgain):
[~pkouznet], [~vozerov].
The test looks like invalid a bit:
after the first {{fillParamsWithPerson(pstmt, 1);}} the batch wasn't added.
If the {{pstmt.addBatch();}} is added after this line, the second call of the
{{addBatch}} throws:
{{java.sql.SQLException: Statement has non-empty batch (call executeBatch() or
clearBatch() before enabling streaming).}}
I guess this is valid behavior because STREAMING mode is Ignite-specific.
I propose to close issue with *Not a Bug*.
> JDBC thin: Batch update is not performed if streaming state changed before
> executeBatch()
> -
>
> Key: IGNITE-9947
> URL: https://issues.apache.org/jira/browse/IGNITE-9947
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Assignee: Taras Ledkov
>Priority: Major
>
> Thin driver is affected.
> How to reproduce:
> 0) Create table
> 1) Create PreparedStatement "INSERT INTO TAB VALUES (?, ?)"
> 2) Set statement's args and call .addBatch()
> 3) Turn on streaming
> 4) call .executeBatch()
> 5) Turn off streaming to flush streamer.
> After that table should contain batched data, but it doesn't
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11195) Platform C++ tests failed to find JVM for Java 11 build
[
https://issues.apache.org/jira/browse/IGNITE-11195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771980#comment-16771980
]
Igor Sapego commented on IGNITE-11195:
--
It seems that directory layout of JDK has changed. I'm going to fix this by the
next release. This does not look like a critical issue for me, as a
{{libjvm.so}} path can be pointed out by user explicitly using configuration.
> Platform C++ tests failed to find JVM for Java 11 build
> ---
>
> Key: IGNITE-11195
> URL: https://issues.apache.org/jira/browse/IGNITE-11195
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Priority: Major
>
> 482 C++ tests failed with error
> {noformat}
> std::exception: JVM library is not found (did you set JAVA_HOME environment
> variable?)
> {noformat}
> https://ci.ignite.apache.org/viewLog.html?buildId=2973675&buildTypeId=IgniteTests24Java8_PlatformCWinX64Release&tab=buildResultsDiv&branch_IgniteTests24Java8=ignite-11155
> Looks like we need somehow handle new parameters in C++ tests
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11349) MVCC: Deadlock in query pool when executing DML over caches with queryParallism > 1
[
https://issues.apache.org/jira/browse/IGNITE-11349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-11349:
Description:
Reproducer: {{CacheMvccSelectForUpdateQueryBasicTest}}
There is possible deadlock in {{QUERY_POOL}} when running massive SQL updates
using queries without reducer when {{cache.queryParallelism > 1}}. These
updates fire two step queries on each data node and both map and reduce phases
are executed in the same {{QUERY_POOL}} which can lead to deadlock because
reduce phase has blocking operation {{GridReduceQueryExecutor#awaitAllReplies}}.
> MVCC: Deadlock in query pool when executing DML over caches with
> queryParallism > 1
> ---
>
> Key: IGNITE-11349
> URL: https://issues.apache.org/jira/browse/IGNITE-11349
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
> Fix For: 2.8
>
>
> Reproducer: {{CacheMvccSelectForUpdateQueryBasicTest}}
> There is possible deadlock in {{QUERY_POOL}} when running massive SQL updates
> using queries without reducer when {{cache.queryParallelism > 1}}. These
> updates fire two step queries on each data node and both map and reduce
> phases are executed in the same {{QUERY_POOL}} which can lead to deadlock
> because reduce phase has blocking operation
> {{GridReduceQueryExecutor#awaitAllReplies}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8055) Sqline command !tables works incorrect for client node
[ https://issues.apache.org/jira/browse/IGNITE-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov resolved IGNITE-8055. -- Resolution: Duplicate Fix Version/s: 2.8 The root cause of the problem is described at the IGNITE-6173 and fixed by the patch. > Sqline command !tables works incorrect for client node > -- > > Key: IGNITE-8055 > URL: https://issues.apache.org/jira/browse/IGNITE-8055 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Taras Ledkov >Priority: Minor > Fix For: 2.8 > > > For reproducing: > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to server node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10800 > 2)Create new table on server node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 5)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > Next commands work from client node as well: > SELECT * FROM City > DROP TABLE City > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11344) High performance drop in master vs 2.7
[ https://issues.apache.org/jira/browse/IGNITE-11344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-11344: --- Assignee: Roman Kondakov > High performance drop in master vs 2.7 > -- > > Key: IGNITE-11344 > URL: https://issues.apache.org/jira/browse/IGNITE-11344 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Artukhov >Assignee: Roman Kondakov >Priority: Critical > Labels: benchmarks, yardstick > Attachments: Screenshot from 2019-02-18 12-53-15.png, Screenshot from > 2019-02-18 12-53-40.png > > > Builds under test: > * Apache Ignite from branch *master*, nightly build at 2019-02-15 > * Apache Ignite 2.7 > Benchmark: > * atomic put-all (IgnitePutAllBenchmark), batch size: 100 > Environment: > * 4 servers, 8 clients (64 threads) > * *In-memory* mode (the drop is not as high when persistence is enabled) > Results for FULL_SYNC (-16.19% drop in master): > !Screenshot from 2019-02-18 12-53-40.png! > Results for PRIMARY_SYNC (-23.41% drop in master): > !Screenshot from 2019-02-18 12-53-15.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8055) Sqline command !tables works incorrect for client node
[ https://issues.apache.org/jira/browse/IGNITE-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772105#comment-16772105 ] Ilya Kasnacheev commented on IGNITE-8055: - [~tledkov-gridgain] does it also fix IGNITE-8060 and IGNITE-8100? > Sqline command !tables works incorrect for client node > -- > > Key: IGNITE-8055 > URL: https://issues.apache.org/jira/browse/IGNITE-8055 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Taras Ledkov >Priority: Minor > Fix For: 2.8 > > > For reproducing: > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to server node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10800 > 2)Create new table on server node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 5)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > Next commands work from client node as well: > SELECT * FROM City > DROP TABLE City > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8575) Change Baseline auto-adjust parameters via console.sh
[
https://issues.apache.org/jira/browse/IGNITE-8575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772228#comment-16772228
]
Ignite TC Bot commented on IGNITE-8575:
---
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3123362&buildTypeId=IgniteTests24Java8_RunAll]
> Change Baseline auto-adjust parameters via console.sh
> -
>
> Key: IGNITE-8575
> URL: https://issues.apache.org/jira/browse/IGNITE-8575
> Project: Ignite
> Issue Type: New Feature
>Reporter: Eduard Shangareev
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We would introduce at IGNITE-8571 new parameters.
> We need to have option change them via console.sh.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11313) Cluster hangs on cache invoke with binary objects creation
[
https://issues.apache.org/jira/browse/IGNITE-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772235#comment-16772235
]
Dmitriy Govorukhin commented on IGNITE-11313:
-
[~ibessonov], [~sergey-chugunov] Thanks for the contribution. Merged to master.
> Cluster hangs on cache invoke with binary objects creation
> --
>
> Key: IGNITE-11313
> URL: https://issues.apache.org/jira/browse/IGNITE-11313
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Creating of binary objects in entry processors in parallel with continuous
> queries may lead to deadlock:
> {code:java}
> [2019-02-11 18:52:50,129][WARN ][grid-timeout-worker-#39] >>> Possible
> starvation in striped pool.
> Thread name: sys-stripe-13-#14
> Queue: []
> Deadlock: false
> Completed: 1
> Thread [name="sys-stripe-13-#14", id=33, state=WAITING, blockCnt=3, waitCnt=3]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> o.a.i.i.binary.BinaryContext.registerUserClassName(BinaryContext.java:1202)
> at
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:366)
> at
> o.a.i.i.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:189)
> at
> o.a.i.scenario.InvokeTask$MyEntryProcessor.process(InvokeTask.java:106)
> at
> o.a.i.i.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:446)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1302)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:713)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1103)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:405)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:367)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:171)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:156)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:118)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:198)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:196)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at o.a.i.i.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772232#comment-16772232
]
Ignite TC Bot commented on IGNITE-7113:
---
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=3126556]]
* exe: Cache.CacheConfigurationTest
* exe: CreateCacheTest.TestCreateFromConfiguration - 0,0% fails in last 598
master runs.
* exe: CreateCacheTest.TestGetOrCreateFromConfiguration - 0,0% fails in last
598 master runs.
* exe: CacheQueriesTest.TestCustomKeyValueFieldNames - 0,0% fails in last 598
master runs.
* exe: CustomLoggerTest.TestQueryEntityValidation - 0,0% fails in last 592
master runs.
* exe: CacheQueriesTest.TestCustomKeyValueFieldNames - 0,0% fails in last 598
master runs.
{color:#d04437}MVCC Queries{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3126519]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlCoordinatorFailoverTest.testSqlReadInsideTxInProgressCoordinatorFails_ReadDelay
- 0,0% fails in last 70 master runs.
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlCoordinatorFailoverTest.testSqlReadInsideTxInProgressCoordinatorFails
- 0,0% fails in last 70 master runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
13|https://ci.ignite.apache.org/viewLog.html?buildId=3126557]]
* dll: CustomLoggerTest.TestQueryEntityValidation - 0,0% fails in last 586
master runs.
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3126501]]
* IgniteSpiTestSuite: GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange
- 0,0% fails in last 422 master runs.
{color:#d04437}Queries 1{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=3126562]]
* IgniteBinaryCacheQueryTestSuite:
IgniteCacheJoinQueryWithAffinityKeyTest.testJoinQueryWithAffinityKeyNotQueryField
- 0,0% fails in last 416 master runs.
* IgniteBinaryCacheQueryTestSuite: SqlSystemViewsSelfTest.testQueryModes - 0,0%
fails in last 416 master runs.
* IgniteBinaryCacheQueryTestSuite:
IncorrectQueryEntityTest.testIncorrectQueryField - 0,0% fails in last 416
master runs.
{color:#d04437}SPI (URI Deploy){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3126502]]
* IgniteUriDeploymentTestSuite:
GridHttpDeploymentSelfTest.testDeployUndeploy2Files - 0,0% fails in last 257
master runs.
* IgniteUriDeploymentTestSuite: GridHttpDeploymentSelfTest.testSameContantFiles
- 0,0% fails in last 257 master runs.
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3126550]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheHistoricalRebalancingTest.testTopologyChangesWithConstantLoad
- 0,0% fails in last 424 master runs.
{color:#d04437}Cache 7{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3126540]]
* IgniteCacheTestSuite7: CacheMetricsManageTest.testCacheApiClearStatistics -
0,0% fails in last 421 master runs.
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - 0,0% fails in last
421 master runs.
{color:#d04437}Queries 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3126496]]
* IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryNodeRestartSelfTest2.testRestarts - 0,0% fails in last 0 master
runs.
* IgniteBinaryCacheQueryTestSuite2:
DynamicIndexPartitionedAtomicConcurrentSelfTest.testConcurrentRebalance - 0,0%
fails in last 421 master runs.
{color:#d04437}Cache 5{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=3126538]]
* IgniteCacheTestSuite5:
ClusterStatePartitionedSelfTest.testDeactivationWithPendingLock - 0,0% fails in
last 426 master runs.
* IgniteCacheTestSuite5:
ClusterStateReplicatedSelfTest.testDeactivationWithPendingLock - 0,0% fails in
last 426 master runs.
* IgniteCacheTestSuite5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 -
0,0% fails in last 426 master runs.
* IgniteCacheTestSuite5:
ClusterStatePartitionedSelfTest.testDeactivationWithPendingTransaction - 0,0%
fails in last 426 master runs.
* IgniteCacheTestSuite5:
ClusterStateReplicatedSelfTest.testDeactivationWithPendingTransaction - 0,0%
fails in last 426 master runs.
{color:#d04437}Activate / Deactivate Cluster{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=3126475]]
* IgniteStandByClusterSuite:
CacheBaselineTopologyTest.testClusterActiveWhileBaselineChanging - 0,0% fails
in last 424 master runs.
{color:#d04437}MVCC Cache{color} [[tests
19|https://ci.ignite.apache.org/viewLog.html?buildId=3126517]]
* IgniteCacheMvccTestSuite: CacheMvccTransactionsTest.testSize - 0,0% fails in
last 418 master runs.
{color:#d04437}Thin Client: Java{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3126492]]
* Cl
[jira] [Updated] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11353: -- Fix Version/s: 2.8 > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Time Spent: 56m > Remaining Estimate: 0h > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11360) Web Console: Should detect situation when session on backed expired / removed
Alexey Kuznetsov created IGNITE-11360:
-
Summary: Web Console: Should detect situation when session on
backed expired / removed
Key: IGNITE-11360
URL: https://issues.apache.org/jira/browse/IGNITE-11360
Project: Ignite
Issue Type: Bug
Components: wizards
Reporter: Alexey Kuznetsov
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: Frontend should go to 403 page.
Errors in logs (from steps):
{code}
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:41.993 angular.js:13539 GET
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
Grid.refreshCanvas @ ui-grid.js:5921
init @ ui-grid.js:3531
post @ ui-grid.js:3465
(anonymous) @ angular.js:1365
(anonymous) @ angular.js:11237
invokeLinkFn @ angular.js:11243
nodeLinkFn @ angular.js:10562
(anonymous) @ angular.js:10908
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.019 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ angular.js:19089
(anonymous) @ angular.js:19409
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
$evalAsync @ angular.js:19407
(anonymous) @ angular.js:17794
scheduleProcessQueue @ angular.js:17970
then @ angular.js:17891
$http @ angular.js:12922
$http.(anonymous function) @ angular.js:13170
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
@ exhaustMap.js:44
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
@ exhaustMap.js:37
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
@ filter.js:38
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
@ Subject.js:47
dispatchAction @ ConfigureState.ts:58
setTimeout @ effects.js:744
setTimeout (async)
ConfigEffects.etp @ effects.js:744
$stateProvider.state.resolve._shortClusters @ states.ts:54
invokeResolveFn @ resolvable.js:73
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.022 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ angular.js:1
[jira] [Updated] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11353: -- Ignite Flags: (was: Docs Required) > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Time Spent: 56m > Remaining Estimate: 0h > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11360) Web Console: Should detect situation when session on backed expired / removed
[
https://issues.apache.org/jira/browse/IGNITE-11360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-11360:
-
Assignee: Ilya Borisov
[~Klaster_1] Please, take a look.
> Web Console: Should detect situation when session on backed expired / removed
> -
>
> Key: IGNITE-11360
> URL: https://issues.apache.org/jira/browse/IGNITE-11360
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Ilya Borisov
>Priority: Major
>
> Steps to reproduce:
> # Start backend and frontend as usual.
> # Sign in on frontend.
> # Stop backend and wipe its DB.
> # Start backend.
> # Click some links on frontend.
> Expected: Frontend should go to 403 page.
> Errors in logs (from steps):
> {code}
> (anonymous) @ angular.js:13539
> sendReq @ angular.js:13265
> serverRequest @ angular.js:13006
> processQueue @ angular.js:17922
> (anonymous) @ angular.js:17970
> $digest @ angular.js:19089
> $apply @ angular.js:19477
> (anonymous) @ angular.js:21578
> completeTask @ angular.js:21208
> (anonymous) @ angular.js:6789
> setTimeout (async)
> Browser.self.defer @ angular.js:6787
> timeout @ angular.js:21568
> (anonymous) @ stateDirectives.js:52
> dispatch @ jquery.js:5206
> elemData.handle @ jquery.js:5014
> 09:42:41.993 angular.js:13539 GET
> http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
> (anonymous) @ angular.js:13539
> sendReq @ angular.js:13265
> serverRequest @ angular.js:13006
> processQueue @ angular.js:17922
> (anonymous) @ angular.js:17970
> $digest @ angular.js:19089
> $apply @ angular.js:19477
> (anonymous) @ angular.js:21578
> completeTask @ angular.js:21208
> (anonymous) @ angular.js:6789
> setTimeout (async)
> Browser.self.defer @ angular.js:6787
> timeout @ angular.js:21568
> Grid.refreshCanvas @ ui-grid.js:5921
> init @ ui-grid.js:3531
> post @ ui-grid.js:3465
> (anonymous) @ angular.js:1365
> (anonymous) @ angular.js:11237
> invokeLinkFn @ angular.js:11243
> nodeLinkFn @ angular.js:10562
> (anonymous) @ angular.js:10908
> processQueue @ angular.js:17922
> (anonymous) @ angular.js:17970
> $digest @ angular.js:19089
> $apply @ angular.js:19477
> (anonymous) @ angular.js:21578
> completeTask @ angular.js:21208
> (anonymous) @ angular.js:6789
> setTimeout (async)
> Browser.self.defer @ angular.js:6787
> timeout @ angular.js:21568
> (anonymous) @ stateDirectives.js:52
> dispatch @ jquery.js:5206
> elemData.handle @ jquery.js:5014
> 09:42:42.019 angular.js:15544 Possibly unhandled rejection:
> {"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
> Access denied. You are not authorized to access this
> page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
> (anonymous) @ angular.js:15544
> (anonymous) @ exceptionHandler.js:32
> processChecks @ angular.js:17954
> $digest @ angular.js:19089
> (anonymous) @ angular.js:19409
> completeTask @ angular.js:21208
> (anonymous) @ angular.js:6789
> setTimeout (async)
> Browser.self.defer @ angular.js:6787
> $evalAsync @ angular.js:19407
> (anonymous) @ angular.js:17794
> scheduleProcessQueue @ angular.js:17970
> then @ angular.js:17891
> $http @ angular.js:12922
> $http.(anonymous function) @ angular.js:13170
> getClustersOverview @ Clusters.ts:106
> ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
> effects.js:220
> push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
> @ exhaustMap.js:44
> push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
> @ exhaustMap.js:37
> push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
> @ Subscriber.js:54
> push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
> @ filter.js:38
> push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
> @ Subscriber.js:54
> push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
> @ Subject.js:47
> dispatchAction @ ConfigureState.ts:58
> setTimeout @ effects.js:744
> setTimeout (async)
> ConfigEffects.etp @ effects.js:744
> $stateProvider.state.resolve._shortClusters @ states.ts:54
> invokeResolveFn @ resolvable.js:73
> processQueue @ angular.js:17922
> (anonymous) @ angular.js:17970
> $digest @ angular.js:19089
> $apply @ angular.js:19477
> (anonymous) @ angular.js:21578
> completeTask @ angular.js:21208
> (anonymous) @ angular.js:6789
> setTimeou
[jira] [Updated] (IGNITE-11360) Web Console: Should detect situation when session on backed expired / removed
[
https://issues.apache.org/jira/browse/IGNITE-11360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-11360:
--
Description:
This issue related to IGNITE-11353.
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: Frontend should go to 403 page.
Errors in logs (from steps):
{code}
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:41.993 angular.js:13539 GET
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
Grid.refreshCanvas @ ui-grid.js:5921
init @ ui-grid.js:3531
post @ ui-grid.js:3465
(anonymous) @ angular.js:1365
(anonymous) @ angular.js:11237
invokeLinkFn @ angular.js:11243
nodeLinkFn @ angular.js:10562
(anonymous) @ angular.js:10908
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.019 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ angular.js:19089
(anonymous) @ angular.js:19409
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
$evalAsync @ angular.js:19407
(anonymous) @ angular.js:17794
scheduleProcessQueue @ angular.js:17970
then @ angular.js:17891
$http @ angular.js:12922
$http.(anonymous function) @ angular.js:13170
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
@ exhaustMap.js:44
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
@ exhaustMap.js:37
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
@ filter.js:38
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
@ Subject.js:47
dispatchAction @ ConfigureState.ts:58
setTimeout @ effects.js:744
setTimeout (async)
ConfigEffects.etp @ effects.js:744
$stateProvider.state.resolve._shortClusters @ states.ts:54
invokeResolveFn @ resolvable.js:73
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.022 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ angular.js:19089
(anonymous) @ angular.js:19409
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
[jira] [Updated] (IGNITE-11360) Web Console: Should detect situation when session on backed expired / removed
[
https://issues.apache.org/jira/browse/IGNITE-11360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-11360:
--
Description:
This issue related to IGNITE-11353.
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: Frontend should go to 403 page.
Errors in logs (from steps):
{code}
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:41.993 angular.js:13539 GET
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
Grid.refreshCanvas @ ui-grid.js:5921
init @ ui-grid.js:3531
post @ ui-grid.js:3465
(anonymous) @ angular.js:1365
(anonymous) @ angular.js:11237
invokeLinkFn @ angular.js:11243
nodeLinkFn @ angular.js:10562
(anonymous) @ angular.js:10908
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.019 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ angular.js:19089
(anonymous) @ angular.js:19409
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
$evalAsync @ angular.js:19407
(anonymous) @ angular.js:17794
scheduleProcessQueue @ angular.js:17970
then @ angular.js:17891
$http @ angular.js:12922
$http.(anonymous function) @ angular.js:13170
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
@ exhaustMap.js:44
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
@ exhaustMap.js:37
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
@ filter.js:38
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
@ Subject.js:47
dispatchAction @ ConfigureState.ts:58
setTimeout @ effects.js:744
setTimeout (async)
ConfigEffects.etp @ effects.js:744
$stateProvider.state.resolve._shortClusters @ states.ts:54
invokeResolveFn @ resolvable.js:73
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
{code}
was:
This issue related to IGNITE-11353.
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: Frontend should go to 403 page.
Errors in logs (from steps):
{code}
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:
[jira] [Updated] (IGNITE-11360) Web Console: Should detect situation when session on backed expired / removed
[
https://issues.apache.org/jira/browse/IGNITE-11360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-11360:
--
Description:
This issue related to IGNITE-11353.
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: Frontend should go to 403 page.
Errors in logs (from steps):
{code}
.
09:42:41.993 angular.js:13539 GET
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
.
09:42:42.019 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
.
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
@ exhaustMap.js:44
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
@ exhaustMap.js:37
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
@ filter.js:38
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
@ Subject.js:47
dispatchAction @ ConfigureState.ts:58
setTimeout @ effects.js:744
setTimeout (async)
ConfigEffects.etp @ effects.js:744
$stateProvider.state.resolve._shortClusters @ states.ts:54
{code}
was:
This issue related to IGNITE-11353.
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: Frontend should go to 403 page.
Errors in logs (from steps):
{code}
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:41.993 angular.js:13539 GET
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
Grid.refreshCanvas @ ui-grid.js:5921
init @ ui-grid.js:3531
post @ ui-grid.js:3465
(anonymous) @ angular.js:1365
(anonymous) @ angular.js:11237
invokeLinkFn @ angular.js:11243
nodeLinkFn @ angular.js:10562
(anonymous) @ angular.js:10908
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.019 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ angular.js:19089
(anonymous) @ angular.js:19409
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
$evalAsync @ angular.js:19407
(anonymous) @ angular.js:17794
scheduleProcessQueue @ angular.js:17970
then @ angular.js:17891
$http @ angular.js:12922
$http.(anonymous function) @ angular.js:13170
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
@
[jira] [Updated] (IGNITE-11360) Web Console: Should detect situation when session on backed expired / removed
[
https://issues.apache.org/jira/browse/IGNITE-11360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-11360:
--
Description:
This issue related to IGNITE-11353.
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: *Frontend should go to 403 page.*
Errors in logs (from steps):
{code}
.
09:42:41.993 angular.js:13539 GET
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
.
09:42:42.019 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
.
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
@ exhaustMap.js:44
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
@ exhaustMap.js:37
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
@ filter.js:38
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
@ Subject.js:47
dispatchAction @ ConfigureState.ts:58
setTimeout @ effects.js:744
setTimeout (async)
ConfigEffects.etp @ effects.js:744
$stateProvider.state.resolve._shortClusters @ states.ts:54
{code}
was:
This issue related to IGNITE-11353.
Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.
Expected: Frontend should go to 403 page.
Errors in logs (from steps):
{code}
.
09:42:41.993 angular.js:13539 GET
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
.
09:42:42.019 angular.js:15544 Possibly unhandled rejection:
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters:
Access denied. You are not authorized to access this
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
.
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
@ exhaustMap.js:44
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
@ exhaustMap.js:37
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
@ filter.js:38
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
@ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
@ Subject.js:47
dispatchAction @ ConfigureState.ts:58
setTimeout @ effects.js:744
setTimeout (async)
ConfigEffects.etp @ effects.js:744
$stateProvider.state.resolve._shortClusters @ states.ts:54
{code}
> Web Console: Should detect situation when session on backed expired / removed
> -
>
> Key: IGNITE-11360
> URL: https://issues.apache.org/jira/browse/IGNITE-11360
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Ilya Borisov
>Priority: Major
>
> This issue related to IGNITE-11353.
> Steps to reproduce:
> # Start backend and frontend as usual.
> # Sign in on frontend.
> # Stop backend and wipe its DB.
> # Start backend.
> # Click some links on frontend.
> Expected: *Frontend should go to 403 page.*
> Errors in logs (from steps):
> {code}
> .
> 09:42:41.993 angular.js:13539 GET
> http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
> .
> 09:42:42.019 angular.js:15544 Possibly unhandled rejection:
> {"type":"LOAD_USER_CLUST
[jira] [Commented] (IGNITE-11255) Fix test failure after IGNITE-7648.
[
https://issues.apache.org/jira/browse/IGNITE-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772656#comment-16772656
]
Ignite TC Bot commented on IGNITE-11255:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3131263]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3039174&buildTypeId=IgniteTests24Java8_RunAll]
> Fix test failure after IGNITE-7648.
> ---
>
> Key: IGNITE-11255
> URL: https://issues.apache.org/jira/browse/IGNITE-11255
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to fix:
>
> *
> CacheQueriesRestartServerTest.Test_ScanQueryAfterClientReconnect_ReturnsResults(False)
> * ZookeeperDiscoveryClientDisconnectTest.testReconnectServersRestart_3
> * IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11255) Fix test failure after IGNITE-7648.
[ https://issues.apache.org/jira/browse/IGNITE-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-11255: Description: We need to fix: * CacheQueriesRestartServerTest.Test_ScanQueryAfterClientReconnect_ReturnsResults(False) * ZookeeperDiscoveryClientDisconnectTest.testReconnectServersRestart_3 * IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes ZookeeperDiscovery1: [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ZooKeeperDiscovery1&branch=pull%2F6062%2Fhead&tab=buildTypeStatusDiv] Platform NET: [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning&branch=pull%2F6062%2Fhead&tab=buildTypeStatusDiv] was: We need to fix: * CacheQueriesRestartServerTest.Test_ScanQueryAfterClientReconnect_ReturnsResults(False) * ZookeeperDiscoveryClientDisconnectTest.testReconnectServersRestart_3 * IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes > Fix test failure after IGNITE-7648. > --- > > Key: IGNITE-11255 > URL: https://issues.apache.org/jira/browse/IGNITE-11255 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Labels: MakeTeamcityGreenAgain > Time Spent: 10m > Remaining Estimate: 0h > > We need to fix: > > * > CacheQueriesRestartServerTest.Test_ScanQueryAfterClientReconnect_ReturnsResults(False) > * ZookeeperDiscoveryClientDisconnectTest.testReconnectServersRestart_3 > * IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes > > ZookeeperDiscovery1: > [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ZooKeeperDiscovery1&branch=pull%2F6062%2Fhead&tab=buildTypeStatusDiv] > Platform NET: > [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning&branch=pull%2F6062%2Fhead&tab=buildTypeStatusDiv] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11255) Fix test failure after IGNITE-7648.
[
https://issues.apache.org/jira/browse/IGNITE-11255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772677#comment-16772677
]
Ignite TC Bot commented on IGNITE-11255:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3039174&buildTypeId=IgniteTests24Java8_RunAll]
> Fix test failure after IGNITE-7648.
> ---
>
> Key: IGNITE-11255
> URL: https://issues.apache.org/jira/browse/IGNITE-11255
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to fix:
>
> *
> CacheQueriesRestartServerTest.Test_ScanQueryAfterClientReconnect_ReturnsResults(False)
> * ZookeeperDiscoveryClientDisconnectTest.testReconnectServersRestart_3
> * IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes
>
> ZookeeperDiscovery1:
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ZooKeeperDiscovery1&branch=pull%2F6062%2Fhead&tab=buildTypeStatusDiv]
> Platform NET:
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning&branch=pull%2F6062%2Fhead&tab=buildTypeStatusDiv]
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, abomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-11354: --- Description: Result for class: org.apache.ignite.configuration.DataStorageConfiguration Missed maxWalArchiveSize checkpointReadLockTimeout walCompactionLevel Result for class: org.apache.ignite.configuration.AtomicConfiguration Missed groupName Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Missed nodeAttributes connectionRecoveryTimeout reconnectDelay soLinger Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi Missed usePairedConnections connectionsPerNode selectorSpins filterReachableAddresses Removed discoveryStartupDelay was: Result for class: org.apache.ignite.configuration.DataStorageConfiguration Missed maxWalArchiveSize checkpointReadLockTimeout walCompactionLevel Result for class: org.apache.ignite.configuration.AtomicConfiguration Missed groupName Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Missed nodeAttributes connectionRecoveryTimeout reconnectDelaysoLinger Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi Missed usePairedConnections connectionsPerNode selectorSpins filterReachableAddresses Removed discoveryStartupDelay > Web console: Actualize grid configurator discovery, store, abomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelay > soLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, abomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-11354: --- Description: Result for class: org.apache.ignite.configuration.DataStorageConfiguration Missed maxWalArchiveSize checkpointReadLockTimeout walCompactionLevel Result for class: org.apache.ignite.configuration.AtomicConfiguration Missed groupName Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Missed nodeAttributes connectionRecoveryTimeout reconnectDelaysoLinger Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi Missed usePairedConnections connectionsPerNode selectorSpins filterReachableAddresses Removed discoveryStartupDelay was: Result for class: org.apache.ignite.configuration.DataStorageConfiguration Missed maxWalArchiveSize checkpointReadLockTimeout walCompactionLevel Result for class: org.apache.ignite.configuration.AtomicConfiguration Missed groupName Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Missed nodeAttributes connectionRecoveryTimeout reconnectDelay Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi Missed usePairedConnections connectionsPerNode selectorSpins filterReachableAddresses Removed discoveryStartupDelay > Web console: Actualize grid configurator discovery, store, abomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelaysoLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11262) Compression on Discovery data bag
[
https://issues.apache.org/jira/browse/IGNITE-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772702#comment-16772702
]
Ignite TC Bot commented on IGNITE-11262:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3127198]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - 0,0% fails in last
421 master runs.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3127244&buildTypeId=IgniteTests24Java8_RunAll]
> Compression on Discovery data bag
> -
>
> Key: IGNITE-11262
> URL: https://issues.apache.org/jira/browse/IGNITE-11262
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Size of GridComponetns data may increase significantly in large deployment.
> Examples:
> 1) In case of more then 3K caches with QueryEntry configured - size of
> {{DiscoveryDataBag}}{{GridCacheProcessor}} data bag consume more then 20 Mb
> 2) If cluster contain more then 13K objects -
> {{GridMarshallerMappingProcessor}} size more then 1 Mb
> 3) Cluster with more then 3К types in binary format -
> {{CacheObjectBinaryProcessorImpl}} size can grow to 10Mb
> The data in most cases contain duplicated structure and simple zip
> compression can led to seriously reduce size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11361) Web console: Actualize grid configurator IgniteConfiguration
Vasiliy Sisko created IGNITE-11361: -- Summary: Web console: Actualize grid configurator IgniteConfiguration Key: IGNITE-11361 URL: https://issues.apache.org/jira/browse/IGNITE-11361 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Result for class: org.apache.ignite.configuration.IgniteConfiguration Missed authenticationEnabled sqlQueryHistorySize lifecycleBeans addressResolver allSegmentationResolversPassRequired localEventListeners mBeanServer networkCompressionLevel segmentCheckFrequency systemWorkerBlockedTimeout includeProperties cacheStoreSessionListenerFactories initBaselineAutoAdjustEnabled failureHandler initBaselineAutoAdjustTimeout autoActivationEnabled sqlSchemas segmentationPolicy segmentationResolveAttempts igniteInstanceName waitForSegmentOnStart igniteHome initBaselineAutoAdjustMaxTimeout communicationFailureResolver segmentationResolvers platformConfiguration encryptionSpi -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, abomic, communication
[ https://issues.apache.org/jira/browse/IGNITE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772709#comment-16772709 ] Vasiliy Sisko commented on IGNITE-11354: Implemented missed fields in configurator. nodeAttributes field is not part of TcpDiscoverySpi configuration. Not implemented. > Web console: Actualize grid configurator discovery, store, abomic, > communication > > > Key: IGNITE-11354 > URL: https://issues.apache.org/jira/browse/IGNITE-11354 > Project: Ignite > Issue Type: Improvement >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > Result for class: org.apache.ignite.configuration.DataStorageConfiguration > Missed > maxWalArchiveSize > checkpointReadLockTimeout > walCompactionLevel > Result for class: org.apache.ignite.configuration.AtomicConfiguration > Missed > groupName > Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi > Missed > nodeAttributes > connectionRecoveryTimeout > reconnectDelay > soLinger > Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi > Missed > usePairedConnections > connectionsPerNode > selectorSpins > filterReachableAddresses > Removed > discoveryStartupDelay -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11266) Platform .NET test failed with Java 11 warning
[
https://issues.apache.org/jira/browse/IGNITE-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772724#comment-16772724
]
Pavel Tupitsyn commented on IGNITE-11266:
-
Done as part of IGNITE-11344, PR: https://github.com/apache/ignite/pull/6127
> Platform .NET test failed with Java 11 warning
> --
>
> Key: IGNITE-11266
> URL: https://issues.apache.org/jira/browse/IGNITE-11266
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> Following warning is unavoidable, because Java always warns about illegal
> reflective access (at least for the first time). Probably we can change some
> settings to avoid "The active test run was aborted. Reason".
> https://ci.ignite.apache.org/viewLog.html?buildId=3027650
> {noformat}
> [17:32:56][test] The active test run was aborted. Reason: WARNING: An illegal
> reflective access operation has occurred
> [17:32:56][test] WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/data/teamcity/work/9198da4c51c3e112/modules/core/target/classes/) to
> field java.nio.Buffer.address
> [17:32:56][test] WARNING: Please consider reporting this to the maintainers
> of org.apache.ignite.internal.util.GridUnsafe$2
> [17:32:56][test] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [17:32:56][test] WARNING: All illegal access operations will be denied in a
> future release
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772727#comment-16772727
]
Ignite TC Bot commented on IGNITE-11356:
{panel:title=--> Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3125455&buildTypeId=IgniteTests24Java8_RunAllNightly]
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11348) Ping node procedure may fail when another node leaves the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772723#comment-16772723 ] Dmitriy Pavlov commented on IGNITE-11348: - I will merge if peer review passes. I've tried to take a brief look but didn't understand why these changes fix the problem. > Ping node procedure may fail when another node leaves the cluster > - > > Key: IGNITE-11348 > URL: https://issues.apache.org/jira/browse/IGNITE-11348 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Critical > Fix For: 2.8 > > > Additional pinging of node on join implemented in IGNITE-5569 may incorrectly > fail leading to shutting down joining node. > The reason for this is that if another node from the same host bound to the > same discovery port as joining node has left the cluster right before joining > node, socket used for pinging gets closed. > This leads to the situation when pinging node considers joining node as > "unreachable" and fails it with JOIN_IMPOSSIBLE error code. > Workaround: simply start again node failed on join. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11266) Platform .NET test failed with Java 11 warning
[
https://issues.apache.org/jira/browse/IGNITE-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11266:
Fix Version/s: 2.8
> Platform .NET test failed with Java 11 warning
> --
>
> Key: IGNITE-11266
> URL: https://issues.apache.org/jira/browse/IGNITE-11266
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.8
>
>
> Following warning is unavoidable, because Java always warns about illegal
> reflective access (at least for the first time). Probably we can change some
> settings to avoid "The active test run was aborted. Reason".
> https://ci.ignite.apache.org/viewLog.html?buildId=3027650
> {noformat}
> [17:32:56][test] The active test run was aborted. Reason: WARNING: An illegal
> reflective access operation has occurred
> [17:32:56][test] WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/data/teamcity/work/9198da4c51c3e112/modules/core/target/classes/) to
> field java.nio.Buffer.address
> [17:32:56][test] WARNING: Please consider reporting this to the maintainers
> of org.apache.ignite.internal.util.GridUnsafe$2
> [17:32:56][test] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [17:32:56][test] WARNING: All illegal access operations will be denied in a
> future release
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11359) Improvement of tests. Add additional state check after each test.
[ https://issues.apache.org/jira/browse/IGNITE-11359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim reassigned IGNITE-11359: - Assignee: (was: Stepachev Maksim) > Improvement of tests. Add additional state check after each test. > - > > Key: IGNITE-11359 > URL: https://issues.apache.org/jira/browse/IGNITE-11359 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Priority: Major > > Sometimes, the Flaky tests are interrupted with OOM. There are many reasons > for it, but the main is a memory leak in transactions. The good way of fast > problem detection will additionally check of maps with transaction futures > after a test. It must be empty. Add this logic into GridCommonAbstractTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11348) Ping node procedure may fail when another node leaves the cluster
[ https://issues.apache.org/jira/browse/IGNITE-11348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772734#comment-16772734 ] Sergey Chugunov commented on IGNITE-11348: -- [~dpavlov], the whole sequence of events leading to the issue looks like as following: # _leaving node_ sitting on a *host0:port0* disco address leaves the cluster (address becomes free); # _new node_ binds to the same *host0:port0* address and sends join request; # _old node_ receives join request and starts pinging _new node_; # NODE_LEFT event for _leaving node_ arrives to _old node_; as part of handling of NODE_LEFT socket for ongoing ping is closed (incorrectly as this ping has nothing to do with _leaving node_) To avoid this situation I add nodeID to ping future and check it before closing socket on NODE_LEFT. The ID enables to distinguish ping request to _new node_ despite of _new node_ and _leaving node_ have the same disco address. > Ping node procedure may fail when another node leaves the cluster > - > > Key: IGNITE-11348 > URL: https://issues.apache.org/jira/browse/IGNITE-11348 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Critical > Fix For: 2.8 > > > Additional pinging of node on join implemented in IGNITE-5569 may incorrectly > fail leading to shutting down joining node. > The reason for this is that if another node from the same host bound to the > same discovery port as joining node has left the cluster right before joining > node, socket used for pinging gets closed. > This leads to the situation when pinging node considers joining node as > "unreachable" and fails it with JOIN_IMPOSSIBLE error code. > Workaround: simply start again node failed on join. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11266) Platform .NET test failed with Java 11 warning
[
https://issues.apache.org/jira/browse/IGNITE-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov resolved IGNITE-11266.
-
Resolution: Fixed
Merged to master, [~ptupitsyn] thank you for fixing the issue
https://github.com/apache/ignite/commit/1dbf57bc58c480a4c5500ed0ecb04a18d07fbcd3
> Platform .NET test failed with Java 11 warning
> --
>
> Key: IGNITE-11266
> URL: https://issues.apache.org/jira/browse/IGNITE-11266
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> Following warning is unavoidable, because Java always warns about illegal
> reflective access (at least for the first time). Probably we can change some
> settings to avoid "The active test run was aborted. Reason".
> https://ci.ignite.apache.org/viewLog.html?buildId=3027650
> {noformat}
> [17:32:56][test] The active test run was aborted. Reason: WARNING: An illegal
> reflective access operation has occurred
> [17:32:56][test] WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/data/teamcity/work/9198da4c51c3e112/modules/core/target/classes/) to
> field java.nio.Buffer.address
> [17:32:56][test] WARNING: Please consider reporting this to the maintainers
> of org.apache.ignite.internal.util.GridUnsafe$2
> [17:32:56][test] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [17:32:56][test] WARNING: All illegal access operations will be denied in a
> future release
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
