[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3934727]]
* exe: CacheParityTest.TestCache
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3934728]]
* dll: CacheParityTest.TestCache
{color:#d04437}SPI (URI Deploy){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3934673]]
* IgniteUriDeploymentTestSuite:
GridUriDeploymentSimpleSelfTest.testSimpleRedeployTwoTasks
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3934755]]
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3934684]]
* IgniteBasicTestSuite: GridVersionSelfTest.testVersions
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3934756buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3946025]]
* exe: CacheParityTest.TestCache
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3946026]]
* dll: CacheParityTest.TestCache
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3947224]]
{color:#d04437}Data Structures{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3946069]]
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedSetSelfTest.testMultithreaded
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3946053]]
{color:#d04437}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3946110]]
* IgniteBinaryCacheTestSuite:
GridCacheJdbcBlobStoreMultithreadedSelfTest.testMultithreadedExplicitTx
{color:#d04437}Cassandra Store{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=3946052]]
* IgniteCassandraStoreTestSuite: IgnitePersistentStoreTest.loadCacheTest
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3946054buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11658) Ignite EntityFramework error when stored procedures
[
https://issues.apache.org/jira/browse/IGNITE-11658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849046#comment-16849046
]
Ignite TC Bot commented on IGNITE-11658:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3959361]]
* exe: ClientConnectionTest.TestOperationTimeout
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3959308]]
{color:#d04437}Thin Client: Java{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3959293]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3959386buildTypeId=IgniteTests24Java8_RunAll]
> Ignite EntityFramework error when stored procedures
> ---
>
> Key: IGNITE-11658
> URL: https://issues.apache.org/jira/browse/IGNITE-11658
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alberto
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi, when I trying to save context in Entity Framework with a stores procedure
> associated to Entity I get the error NullReferenceException.
> In Apache.Ingnite.EntityFramework package InvalidateCache entitySets is NULL
> because no entities is affected. In DbCommandInfo _affectedEntitySets is NULL
> when stored procedures is used.
> Any solution?
> Thanks
> en
> Apache.Ignite.EntityFramework.Impl.DbTransactionInterceptor.InvalidateCache(ICollection`1
> entitySets, DbTransaction transaction)
> en Apache.Ignite.EntityFramework.Impl.DbCommandProxy.InvalidateCache()
> en Apache.Ignite.EntityFramework.Impl.DbCommandProxy.ExecuteNonQuery()
> en
> System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.b__0(DbCommand
> t, DbCommandInterceptionContext`1 c)
> en
> System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget
> target, Func`3 operation, TInterceptionContext interceptionContext, Action`3
> executing, Action`3 executed)
> en
> System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.NonQuery(DbCommand
> command, DbCommandInterceptionContext interceptionContext)
> en System.Data.Entity.Internal.InterceptableDbCommand.ExecuteNonQuery()
> en
> System.Data.Entity.Core.Mapping.Update.Internal.FunctionUpdateCommand.Execute(Dictionary`2
> identifierValues, List`1 generatedValues)
> en System.Data.Entity.Core.Mapping.Update.Internal.UpdateTranslator.Update()
> en
> System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.b__2(UpdateTranslator
> ut)
> en System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.Update[T](T
> noChangesResult, Func`2 updateFunction)
> en System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.Update()
> en System.Data.Entity.Core.Objects.ObjectContext.b__35()
> en
> System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1
> func, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction,
> Boolean releaseConnectionOnSuccess)
> en
> System.Data.Entity.Core.Objects.ObjectContext.SaveChangesToStore(SaveOptions
> options, IDbExecutionStrategy executionStrategy, Boolean
> startLocalTransaction)
> en
> System.Data.Entity.Core.Objects.ObjectContext.<>c__DisplayClass2a.b__27()
> en
> System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute[TResult](Func`1
> operation)
> en
> System.Data.Entity.Core.Objects.ObjectContext.SaveChangesInternal(SaveOptions
> options, Boolean executeInExistingTransaction)
> en System.Data.Entity.Core.Objects.ObjectContext.SaveChanges(SaveOptions
> options)
> en System.Data.Entity.Internal.InternalContext.SaveChanges()
> en System.Data.Entity.Internal.LazyInternalContext.SaveChanges()
> en System.Data.Entity.DbContext.SaveChanges()
> en CommonLibrary.Repositorios.GenericUnitOfWork`1.Save() en
> D:\Documentos\Desarrollo\WEB\RISHT\CommonLibrary\Repositorios\GenericUnitOfWork.cs:línea
> 85
> en RISHT.Services.EstudioCRUDManager.CreateOrEditEstudio(Estudio estudio) en
> D:\Documentos\Desarrollo\WEB\RISHT\RISHT.Services\EstudioCRUDManager.cs:línea
> 274
> en RISHT.Services.EstudioCRUDManager.Save(Estudio estudio) en
> D:\Documentos\Desarrollo\WEB\RISHT\RISHT.Services\EstudioCRUDManager.cs:línea
> 568
> en RISHT.Services.EstudioCRUDManager.SaveEstudio(Estudio estudio) en
> D:\Documentos\Desarrollo\WEB\RISHT\RISHT.Services\EstudioCRUDManager.cs:línea
> 382
> en RISHT.Controllers.EstudioController.AltaFromWizard(EstudioWizardViewModel
> estudioWizardViewModel) en
> D:\Documentos\Desarrollo\WEB\RISHT\RISHT\Controllers\EstudioController.cs:línea
> 105
> en
[jira] [Commented] (IGNITE-11874) Fix mismatch between idle_verify results with and without -dump option.
[ https://issues.apache.org/jira/browse/IGNITE-11874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849024#comment-16849024 ] Dmitriy Pavlov commented on IGNITE-11874: - Please fill the ticket description. It is now unclear what mismatch is mentioned. > Fix mismatch between idle_verify results with and without -dump option. > --- > > Key: IGNITE-11874 > URL: https://issues.apache.org/jira/browse/IGNITE-11874 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11874) Fix mismatch between idle_verify results with and without -dump option.
[ https://issues.apache.org/jira/browse/IGNITE-11874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849024#comment-16849024 ] Dmitriy Pavlov edited comment on IGNITE-11874 at 5/27/19 3:34 PM: -- [~Denis Chudov], could you please fill the ticket description. It is now unclear what mismatch is mentioned. was (Author: dpavlov): Please fill the ticket description. It is now unclear what mismatch is mentioned. > Fix mismatch between idle_verify results with and without -dump option. > --- > > Key: IGNITE-11874 > URL: https://issues.apache.org/jira/browse/IGNITE-11874 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11874) Fix mismatch between idle_verify results with and without -dump option.
Denis Chudov created IGNITE-11874: - Summary: Fix mismatch between idle_verify results with and without -dump option. Key: IGNITE-11874 URL: https://issues.apache.org/jira/browse/IGNITE-11874 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Assignee: Denis Chudov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849004#comment-16849004 ] Sergey Antonov commented on IGNITE-11256: - [~ascherbakov] Fixed. Please review again! > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11298) TcpCommunicationSpi does not support TLSv1.3
[
https://issues.apache.org/jira/browse/IGNITE-11298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848992#comment-16848992
]
Ilya Kasnacheev commented on IGNITE-11298:
--
I can see there is some kind of solution:
https://stackoverflow.com/questions/54687831/changes-in-sslengine-usage-when-going-up-to-tlsv1-3
Is there a chance that it might be applicable?
Otherwise, I think it's wise to stick to TLSv1.2 instead of committing code
that causes most recent Java release to freeze for good. Maybe wait until it
dies out if nothing will help.
> TcpCommunicationSpi does not support TLSv1.3
>
>
> Key: IGNITE-11298
> URL: https://issues.apache.org/jira/browse/IGNITE-11298
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: Java11
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When started on Java 11 we cannot form a secure cluster - Discovery will
> happily use the default TLSv1.3 but Communication will fail with its custom
> SSLEngine-using code.
> Need to fix that.
> Until that, nodes may be salvaged by setProtocol("TLSv1.2") on
> SslContextFactory, or by system property -Djdk.tls.client.protocols="TLSv1.2"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11750) Implement locked pages info dump for long-running B+Tree operations
[
https://issues.apache.org/jira/browse/IGNITE-11750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848931#comment-16848931
]
Ignite TC Bot commented on IGNITE-11750:
{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=3957295buildTypeId=IgniteTests24Java8_RunAll]
> Implement locked pages info dump for long-running B+Tree operations
> ---
>
> Key: IGNITE-11750
> URL: https://issues.apache.org/jira/browse/IGNITE-11750
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I've stumbled upon an incident where a batch of Ignite threads were hanging
> on BPlusTree operations trying to acquire read or write lock on pages. From
> the thread dump it is impossible to check if there is an issue with
> {{OffheapReadWriteLock}} or there is a subtle deadlock in the tree.
> I suggest we implement a timeout for page lock acquire and tracking of locked
> pages. This should be relatively easy to implement in {{PageHandler}} (the
> only thing to consider is performance degradation). If a timeout occurs, we
> should print all the locks currently owned by a thread. This way we should be
> able to determine if there is a deadlock in the {{BPlusTree}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11658) Ignite EntityFramework error when stored procedures
[ https://issues.apache.org/jira/browse/IGNITE-11658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848926#comment-16848926 ] Ilya Kasnacheev commented on IGNITE-11658: -- [~aborja79] are you sure that we don't ned to pass _cache.InvalidateSets(null); when entitySets is null? > Ignite EntityFramework error when stored procedures > --- > > Key: IGNITE-11658 > URL: https://issues.apache.org/jira/browse/IGNITE-11658 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Alberto >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Hi, when I trying to save context in Entity Framework with a stores procedure > associated to Entity I get the error NullReferenceException. > In Apache.Ingnite.EntityFramework package InvalidateCache entitySets is NULL > because no entities is affected. In DbCommandInfo _affectedEntitySets is NULL > when stored procedures is used. > Any solution? > Thanks > en > Apache.Ignite.EntityFramework.Impl.DbTransactionInterceptor.InvalidateCache(ICollection`1 > entitySets, DbTransaction transaction) > en Apache.Ignite.EntityFramework.Impl.DbCommandProxy.InvalidateCache() > en Apache.Ignite.EntityFramework.Impl.DbCommandProxy.ExecuteNonQuery() > en > System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.b__0(DbCommand > t, DbCommandInterceptionContext`1 c) > en > System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget > target, Func`3 operation, TInterceptionContext interceptionContext, Action`3 > executing, Action`3 executed) > en > System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.NonQuery(DbCommand > command, DbCommandInterceptionContext interceptionContext) > en System.Data.Entity.Internal.InterceptableDbCommand.ExecuteNonQuery() > en > System.Data.Entity.Core.Mapping.Update.Internal.FunctionUpdateCommand.Execute(Dictionary`2 > identifierValues, List`1 generatedValues) > en System.Data.Entity.Core.Mapping.Update.Internal.UpdateTranslator.Update() > en > System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.b__2(UpdateTranslator > ut) > en System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.Update[T](T > noChangesResult, Func`2 updateFunction) > en System.Data.Entity.Core.EntityClient.Internal.EntityAdapter.Update() > en System.Data.Entity.Core.Objects.ObjectContext.b__35() > en > System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1 > func, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction, > Boolean releaseConnectionOnSuccess) > en > System.Data.Entity.Core.Objects.ObjectContext.SaveChangesToStore(SaveOptions > options, IDbExecutionStrategy executionStrategy, Boolean > startLocalTransaction) > en > System.Data.Entity.Core.Objects.ObjectContext.<>c__DisplayClass2a.b__27() > en > System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute[TResult](Func`1 > operation) > en > System.Data.Entity.Core.Objects.ObjectContext.SaveChangesInternal(SaveOptions > options, Boolean executeInExistingTransaction) > en System.Data.Entity.Core.Objects.ObjectContext.SaveChanges(SaveOptions > options) > en System.Data.Entity.Internal.InternalContext.SaveChanges() > en System.Data.Entity.Internal.LazyInternalContext.SaveChanges() > en System.Data.Entity.DbContext.SaveChanges() > en CommonLibrary.Repositorios.GenericUnitOfWork`1.Save() en > D:\Documentos\Desarrollo\WEB\RISHT\CommonLibrary\Repositorios\GenericUnitOfWork.cs:línea > 85 > en RISHT.Services.EstudioCRUDManager.CreateOrEditEstudio(Estudio estudio) en > D:\Documentos\Desarrollo\WEB\RISHT\RISHT.Services\EstudioCRUDManager.cs:línea > 274 > en RISHT.Services.EstudioCRUDManager.Save(Estudio estudio) en > D:\Documentos\Desarrollo\WEB\RISHT\RISHT.Services\EstudioCRUDManager.cs:línea > 568 > en RISHT.Services.EstudioCRUDManager.SaveEstudio(Estudio estudio) en > D:\Documentos\Desarrollo\WEB\RISHT\RISHT.Services\EstudioCRUDManager.cs:línea > 382 > en RISHT.Controllers.EstudioController.AltaFromWizard(EstudioWizardViewModel > estudioWizardViewModel) en > D:\Documentos\Desarrollo\WEB\RISHT\RISHT\Controllers\EstudioController.cs:línea > 105 > en lambda_method(Closure , ControllerBase , Object[] ) > en System.Web.Mvc.ActionMethodDispatcher.Execute(ControllerBase controller, > Object[] parameters) > en System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext > controllerContext, IDictionary`2 parameters) > en > System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext > controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 > parameters) > en > System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c.b__9_0(IAsyncResult > asyncResult, ActionInvocation
[jira] [Updated] (IGNITE-11867) Fix flaky test GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions
[
https://issues.apache.org/jira/browse/IGNITE-11867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-11867:
---
Description:
{noformat}
java.lang.AssertionError: Value for 4 is null
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at
org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingWithAsyncClearingTest.testCorrectRebalancingCurrentlyRentingPartitions(GridCacheRebalancingWithAsyncClearingTest.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2148)
at java.lang.Thread.run(Thread.java:748){noformat}
EDIT: The issue is related to recently contributed IGNITE-10078. In specific
scenario due to race partition clearing could be started while partition is
passing through ongoing rebalancing started on previous topology version.
I fixed it by preventing partition clearing on newer topology version. In such
case if rebalance will be finished and partition will go in OWNING state
further clearing is not needed any more, otherwise partition should be
scheduled for clearing again.
was:
{noformat}
java.lang.AssertionError: Value for 4 is null
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at
org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingWithAsyncClearingTest.testCorrectRebalancingCurrentlyRentingPartitions(GridCacheRebalancingWithAsyncClearingTest.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2148)
at java.lang.Thread.run(Thread.java:748){noformat}
EDIT: The issue is related to recently contributed IGNITE-10078. In specific
scenario due to race partition clearing could be started while partition is
passing through ongoing rebalancing started on previous topology version.
I fixed it by preventing partition clearing on newer topology versions. In such
case if rebalance will be finished and partition will go in OWNING state
further clearing is not needed any more, otherwise partition will be scheduled
for clearing again.
> Fix flaky test
> GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions
> -
>
> Key: IGNITE-11867
> URL: https://issues.apache.org/jira/browse/IGNITE-11867
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: Value for 4 is null
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingWithAsyncClearingTest.testCorrectRebalancingCurrentlyRentingPartitions(GridCacheRebalancingWithAsyncClearingTest.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Updated] (IGNITE-11867) Fix flaky test GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions
[
https://issues.apache.org/jira/browse/IGNITE-11867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-11867:
---
Description:
{noformat}
java.lang.AssertionError: Value for 4 is null
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at
org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingWithAsyncClearingTest.testCorrectRebalancingCurrentlyRentingPartitions(GridCacheRebalancingWithAsyncClearingTest.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2148)
at java.lang.Thread.run(Thread.java:748){noformat}
EDIT: The issue is related to recently contributed IGNITE-10078. In specific
scenario due to race partition clearing could be started while partition is
passing through ongoing rebalancing started on previous topology version.
I fixed it by preventing partition clearing on newer topology versions. In such
case if rebalance will be finished and partition will go in OWNING state
further clearing is not needed any more, otherwise partition will be scheduled
for clearing again.
was:
{noformat}
java.lang.AssertionError: Value for 4 is null
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at
org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingWithAsyncClearingTest.testCorrectRebalancingCurrentlyRentingPartitions(GridCacheRebalancingWithAsyncClearingTest.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2148)
at java.lang.Thread.run(Thread.java:748){noformat}
> Fix flaky test
> GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions
> -
>
> Key: IGNITE-11867
> URL: https://issues.apache.org/jira/browse/IGNITE-11867
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> {noformat}
> java.lang.AssertionError: Value for 4 is null
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingWithAsyncClearingTest.testCorrectRebalancingCurrentlyRentingPartitions(GridCacheRebalancingWithAsyncClearingTest.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
[jira] [Commented] (IGNITE-11298) TcpCommunicationSpi does not support TLSv1.3
[
https://issues.apache.org/jira/browse/IGNITE-11298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848825#comment-16848825
]
Vitaliy Biryukov commented on IGNITE-11298:
---
[~ilyak]
I've checked on my Ubuntu pc.
It seems like we are dealing with a [known
bug|https://bugs.openjdk.java.net/browse/JDK-8219658] related to Half-Close
Policy. It's affects only TcpDiscoverySpi (checked only on ubuntu).
This bag cause deadlock between SslSocket.close and inputStream.read. And it
locks so hard so I have to restart my PC to return my network back to normal.
Thread dump:
{noformat}
"test-runner-#1%tcp.TcpCommunicationSpiFaultyClientTest%" #15 prio=5 os_prio=0
cpu=2139,72ms elapsed=75,55s tid=0x7f8ac0815800 nid=0x6422 waiting for
monitor entry [0x7f8a8cee4000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
sun.security.ssl.SSLSocketImpl$AppInputStream.deplete(java.base@12.0.1/SSLSocketImpl.java:921)
- waiting to lock <0x00070791c5e8> (a
sun.security.ssl.SSLSocketImpl$AppInputStream)
at
sun.security.ssl.SSLSocketImpl.bruteForceCloseInput(java.base@12.0.1/SSLSocketImpl.java:615)
at
sun.security.ssl.SSLSocketImpl.duplexCloseOutput(java.base@12.0.1/SSLSocketImpl.java:566)
at sun.security.ssl.SSLSocketImpl.close(java.base@12.0.1/SSLSocketImpl.java:479)
at org.apache.ignite.internal.util.IgniteUtils.closeQuiet(IgniteUtils.java:4135)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$SocketReader.interrupt(ServerImpl.java:7084)
at org.apache.ignite.internal.util.IgniteUtils.interrupt(IgniteUtils.java:4724)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStop0(ServerImpl.java:510)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStop(ServerImpl.java:442)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:2217)
at
org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1743)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2413)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2285)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2574)
- locked <0x000707b608a8> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2537)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
at org.apache.ignite.Ignition.stop(Ignition.java:223)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1253)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1296)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1274)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiFaultyClientTest.testFailClient(TcpCommunicationSpiFaultyClientTest.java:284)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiFaultyClientTest.testNoServerOnHost(TcpCommunicationSpiFaultyClientTest.java:154)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@12.0.1/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@12.0.1/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@12.0.1/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@12.0.1/Method.java:567)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2145)
at java.lang.Thread.run(java.base@12.0.1/Thread.java:835)
"tcp-disco-sock-reader-[31894d88
127.0.0.1:56645]-#12%tcp.TcpCommunicationSpiFaultyClientTest1%" #114 prio=10
os_prio=0 cpu=123,49ms elapsed=72,51s tid=0x7f8a84138800 nid=0x6494
runnable [0x7f89939de000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(java.base@12.0.1/Native Method)
at
java.net.SocketInputStream.socketRead(java.base@12.0.1/SocketInputStream.java:115)
at java.net.SocketInputStream.read(java.base@12.0.1/SocketInputStream.java:168)
at java.net.SocketInputStream.read(java.base@12.0.1/SocketInputStream.java:140)
at
sun.security.ssl.SSLSocketInputRecord.read(java.base@12.0.1/SSLSocketInputRecord.java:448)
at
[jira] [Commented] (IGNITE-11670) Java thin client: Queries are inconsistent in case of failover
[
https://issues.apache.org/jira/browse/IGNITE-11670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848816#comment-16848816
]
Amelchev Nikita commented on IGNITE-11670:
--
[~alex_pl], Your changes look good to me.
> Java thin client: Queries are inconsistent in case of failover
> --
>
> Key: IGNITE-11670
> URL: https://issues.apache.org/jira/browse/IGNITE-11670
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a thin client does failover and switches to a new server, open cursors
> become inconsistent and silently returns the wrong result.
> Reproducer:
> {code:java}
> public void testQueryFailover() throws Exception {
> try (LocalIgniteCluster cluster = LocalIgniteCluster.start(1);
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration()
> .setAddresses(cluster.clientAddresses().iterator().next()))
> ) {
> ObjectName mbeanName =
> U.makeMBeanName(Ignition.allGrids().get(0).name(), "Clients",
> ClientListenerProcessor.class.getSimpleName());
> ClientProcessorMXBean mxBean =
> MBeanServerInvocationHandler.newProxyInstance(
> ManagementFactory.getPlatformMBeanServer(), mbeanName,
> ClientProcessorMXBean.class, true);
> ClientCache cache = client.createCache("cache");
> cache.put(0, 0);
> cache.put(1, 1);
> Query> qry = new ScanQuery String>().setPageSize(1);
> try (QueryCursor> cur =
> cache.query(qry)) {
> int cnt = 0;
> for (Iterator> it =
> cur.iterator(); it.hasNext(); it.next()) {
> cnt++;
> if (cnt == 1)
> mxBean.dropAllConnections();
> }
> assertEquals(2, cnt);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11670) Java thin client: Queries are inconsistent in case of failover
[
https://issues.apache.org/jira/browse/IGNITE-11670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848802#comment-16848802
]
Aleksey Plekhanov commented on IGNITE-11670:
Patch is ready.
[~NSAmelchev] could you please have a look?
> Java thin client: Queries are inconsistent in case of failover
> --
>
> Key: IGNITE-11670
> URL: https://issues.apache.org/jira/browse/IGNITE-11670
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a thin client does failover and switches to a new server, open cursors
> become inconsistent and silently returns the wrong result.
> Reproducer:
> {code:java}
> public void testQueryFailover() throws Exception {
> try (LocalIgniteCluster cluster = LocalIgniteCluster.start(1);
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration()
> .setAddresses(cluster.clientAddresses().iterator().next()))
> ) {
> ObjectName mbeanName =
> U.makeMBeanName(Ignition.allGrids().get(0).name(), "Clients",
> ClientListenerProcessor.class.getSimpleName());
> ClientProcessorMXBean mxBean =
> MBeanServerInvocationHandler.newProxyInstance(
> ManagementFactory.getPlatformMBeanServer(), mbeanName,
> ClientProcessorMXBean.class, true);
> ClientCache cache = client.createCache("cache");
> cache.put(0, 0);
> cache.put(1, 1);
> Query> qry = new ScanQuery String>().setPageSize(1);
> try (QueryCursor> cur =
> cache.query(qry)) {
> int cnt = 0;
> for (Iterator> it =
> cur.iterator(); it.hasNext(); it.next()) {
> cnt++;
> if (cnt == 1)
> mxBean.dropAllConnections();
> }
> assertEquals(2, cnt);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11869) control.sh idle_verify/validate_indexes shouldn't throw GridNotIdleException, if user pages wasn't modified in checkpoint.
[ https://issues.apache.org/jira/browse/IGNITE-11869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848763#comment-16848763 ] Sergey Antonov commented on IGNITE-11869: - [~v.pyatkov] Please review my changes. > control.sh idle_verify/validate_indexes shouldn't throw GridNotIdleException, > if user pages wasn't modified in checkpoint. > -- > > Key: IGNITE-11869 > URL: https://issues.apache.org/jira/browse/IGNITE-11869 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We shouldn't throw GridNotIdleException, if checkpoint contains dirty pages > related to ignite-sys-cache (system background activities) only. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848762#comment-16848762 ] Ivan Bessonov commented on IGNITE-11346: Hi [~Maxoid], I added several comments in your PR, please check them. Please also merge latest master and rerun tests, we have to be sure that your changes don't break anything and that your new test passes. Thank you! > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Assignee: Maxim Karavaev >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11869) control.sh idle_verify/validate_indexes shouldn't throw GridNotIdleException, if user pages wasn't modified in checkpoint.
[
https://issues.apache.org/jira/browse/IGNITE-11869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848758#comment-16848758
]
Ignite TC Bot commented on IGNITE-11869:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3934523buildTypeId=IgniteTests24Java8_RunAll]
> control.sh idle_verify/validate_indexes shouldn't throw GridNotIdleException,
> if user pages wasn't modified in checkpoint.
> --
>
> Key: IGNITE-11869
> URL: https://issues.apache.org/jira/browse/IGNITE-11869
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We shouldn't throw GridNotIdleException, if checkpoint contains dirty pages
> related to ignite-sys-cache (system background activities) only.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-11346: -- Assignee: Maxim Karavaev > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Assignee: Maxim Karavaev >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848754#comment-16848754 ] Sergey Antonov commented on IGNITE-11256: - [~ascherbakov] I can't find your comments in PR. > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11857) Investigate performance drop after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-11857: -- Assignee: Aleksey Plekhanov > Investigate performance drop after IGNITE-10078 > --- > > Key: IGNITE-11857 > URL: https://issues.apache.org/jira/browse/IGNITE-11857 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Aleksey Plekhanov >Priority: Major > > After IGNITE-10078 yardstick tests show performance drop up to 8% in some > scenarios: > * tx-optim-repRead-put-get > * tx-optimistic-put > * tx-putAll > Partially this is due new update counter implementation, but not only. > Investigation is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
