[jira] [Commented] (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:comment-tabpanel=16851227#comment-16851227
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Data Structures{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3981399]]
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalCacheConsistencyTest.test[getEntry=true,
async=true]
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalCacheConsistencyTest.test[getEntry=true,
async=false]
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalCacheConsistencyTest.test[getEntry=false,
async=true]
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalCacheConsistencyTest.test[getEntry=false,
async=false]
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3981740]]
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3981817]]
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3981403]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheHistoricalRebalancingTest.testForceRebalanceClientTopology
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=3981791]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3981818buildTypeId=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=16851072#comment-16851072
]
Ignite TC Bot commented on IGNITE-11658:
{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=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 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
[jira] [Created] (IGNITE-11877) Transactional deadlock with Near cache enabled
Ilya Kasnacheev created IGNITE-11877: Summary: Transactional deadlock with Near cache enabled Key: IGNITE-11877 URL: https://issues.apache.org/jira/browse/IGNITE-11877 Project: Ignite Issue Type: Bug Components: cache Reporter: Ilya Kasnacheev As witnessed by unrunning test NearCachePutAllMultinodeTest, since 2.0 there is a deadlock when transaction operations are performed in parallel with near cache enabled. Without near cache it will pass. -- 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=16850994#comment-16850994 ] Vyacheslav Koptilin commented on IGNITE-11256: -- Hi [~antonovsergey93], In general, the proposed change looks good to me. Please take into account my comments that I wrote in your 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: 1h 40m > 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-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850983#comment-16850983 ] Ivan Fedotov commented on IGNITE-11708: --- [~Pavlukhin], Injection through constructor looks better, it is obviously. Situation on TC remains the same. Please check the last commit [1]. Now I will ignore failed tests and rise discussion on dev-list about them. Do you have any other suggestions according to this PR? [1] [https://github.com/apache/ignite/pull/6434/files#diff-3da5dbb6f22e5bf3bf18734933f1bfc5R429] > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11749) Implement automatic pages history dump on CorruptedTreeException
[
https://issues.apache.org/jira/browse/IGNITE-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850865#comment-16850865
]
Ignite TC Bot commented on IGNITE-11749:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3978555]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=3968456]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3934989buildTypeId=IgniteTests24Java8_RunAll]
> Implement automatic pages history dump on CorruptedTreeException
>
>
> Key: IGNITE-11749
> URL: https://issues.apache.org/jira/browse/IGNITE-11749
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, the only way to debug possible bugs in checkpointer/recovery
> mechanics is to manually parse WAL files after the corruption happened. This
> is not practical for several reasons. First, it requires manual actions which
> depend on the content of the exception. Second, it is not always possible to
> obtain WAL files (it may contain sensitive data).
> We need to add a mechanics which will dump all information required for
> primary analysis of the corruption to the exception handler. For example, if
> an exception happened when materializing a link {{0xabcd}} written on an
> index page {{0xdcba}}, we need to dump history of both pages changes,
> checkpoint records on the analysis interval. Possibly, we should include
> FreeList pages to which the aforementioned pages were included to.
> Example of output:
> {noformat}
> [2019-05-07 11:57:57,350][INFO
> ][test-runner-#58%diagnostic.DiagnosticProcessorTest%][PageHistoryDiagnoster]
> Next WAL record :: PageSnapshot [fullPageId = FullPageId
> [pageId=0002, effectivePageId=,
> grpId=-2100569601], page = [
> Header [
> type=11 (PageMetaIO),
> ver=1,
> crc=0,
> pageId=844420635164672(offset=0, flags=10, partId=65535, index=0)
> ],
> PageMeta[
> treeRoot=844420635164675,
> lastSuccessfulFullSnapshotId=0,
> lastSuccessfulSnapshotId=0,
> nextSnapshotTag=1,
> lastSuccessfulSnapshotTag=0,
> lastAllocatedPageCount=0,
> candidatePageCount=0
> ]],
> super = [WALRecord [size=4129, chainSize=0, pos=FileWALPointer [idx=0,
> fileOff=103, len=4129], type=PAGE_RECORD]]]
> Next WAL record :: CheckpointRecord
> [cpId=c6ba7793-113b-4b54-8530-45e1708ca44c, end=false, cpMark=FileWALPointer
> [idx=0, fileOff=29, len=29], super=WALRecord [size=1963, chainSize=0,
> pos=FileWALPointer [idx=0, fileOff=39686, len=1963], type=CHECKPOINT_RECORD]]
> Next WAL record :: PageSnapshot [fullPageId = FullPageId
> [pageId=0002, effectivePageId=,
> grpId=-1368047378], page = [
> Header [
> type=11 (PageMetaIO),
> ver=1,
> crc=0,
> pageId=844420635164672(offset=0, flags=10, partId=65535, index=0)
> ],
> PageMeta[
> treeRoot=844420635164675,
> lastSuccessfulFullSnapshotId=0,
> lastSuccessfulSnapshotId=0,
> nextSnapshotTag=1,
> lastSuccessfulSnapshotTag=0,
> lastAllocatedPageCount=0,
> candidatePageCount=0
> ]],
> super = [WALRecord [size=4129, chainSize=0, pos=FileWALPointer [idx=0,
> fileOff=55961, len=4129], type=PAGE_RECORD]]]
> Next WAL record :: CheckpointRecord
> [cpId=145e599e-66fc-45f5-bde4-b0c392125968, end=false, cpMark=null,
> super=WALRecord [size=21409, chainSize=0, pos=FileWALPointer [idx=0,
> fileOff=13101788, len=21409], type=CHECKPOINT_RECORD]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (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=16850838#comment-16850838 ] Maxim Karavaev edited comment on IGNITE-11346 at 5/29/19 1:21 PM: -- Hi [~ibessonov] , Done. was (Author: maxoid): Hi [~ibessonov] , > 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: 1.5h > 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-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=16850838#comment-16850838 ] Maxim Karavaev commented on IGNITE-11346: - Hi [~ibessonov] , > 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: 1.5h > 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-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850660#comment-16850660 ] Ivan Pavlukhin commented on IGNITE-11708: - [~ivanan.fed], also I went through [TC results|https://ci.ignite.apache.org/viewLog.html?buildId=3969334=IgniteTests24Java8_RunAllNightly] and it seems that an amount of failing test _methods_ is quite limited (roughly I counted 12). I believe that we can look into and ignore them properly. Also it might be a good idea to ask Community help to check those tests as well. > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850652#comment-16850652 ] Ivan Pavlukhin commented on IGNITE-11708: - [~ivanan.fed], approach without _static_ variable looks simpler for me as well. Now we assign a configuration in Ignite _before_ callbacks in order to be sure that the configuration is accessible during each stages of a test execution. But can we inject a configuration in a generated test class constructor (for the same purposes)? In my mind it will make things even more simpler because it requires injection only in one place and guarantees that an injected configuration is accessible on any stage of test execution (regardless what callbacks are used, Ignite of junit). What do you think? > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- 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=16850590#comment-16850590 ] Sergey Antonov commented on IGNITE-11869: - [~ivan.glukos] Could you review my PR please? > 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-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850589#comment-16850589 ] Sergey Antonov commented on IGNITE-11256: - [~slava.koptilin] Could you review my changes please? > 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] [Comment Edited] (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=16850583#comment-16850583
]
Vladislav Pyatkov edited comment on IGNITE-11869 at 5/29/19 7:33 AM:
-
Hi [~antonovsergey93] I have not see reason to use atomic in this place :
{{o.a.i.internal.processors.cache.persistence.pagemem.PageMemoryImpl#dirtyUserPagesPresent}}
{{volatile}} will be enough.
I have not critical comments.
was (Author: v.pyatkov):
Hi [~antonovsergey93] I have not see reason to use atomic in this place :
{{o.a.i.internal.processors.cache.persistence.pagemem.PageMemoryImpl#dirtyUserPagesPresent}}
{{volatile}} will be enough.
> 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-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=16850583#comment-16850583
]
Vladislav Pyatkov commented on IGNITE-11869:
Hi [~antonovsergey93] I have not see reason to use atomic in this place :
{{o.a.i.internal.processors.cache.persistence.pagemem.PageMemoryImpl#dirtyUserPagesPresent}}
{{volatile}} will be enough.
> 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)
