[jira] [Commented] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853552#comment-16853552 ] Roman Shtykh commented on IGNITE-9409: -- Got it, thanks! > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Ilya Kasnacheev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9978) [ML] Implement Compound Naive Bayes classifier
[
https://issues.apache.org/jira/browse/IGNITE-9978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853506#comment-16853506
]
Ignite TC Bot commented on IGNITE-9978:
---
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4003698]]
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4003650]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=4003701]]
{color:#d04437}Client Nodes{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4003619]]
{color:#d04437}[Licenses Headers]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4003665]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4003728&buildTypeId=IgniteTests24Java8_RunAll]
> [ML] Implement Compound Naive Bayes classifier
> --
>
> Key: IGNITE-9978
> URL: https://issues.apache.org/jira/browse/IGNITE-9978
> Project: Ignite
> Issue Type: Task
> Components: ml
>Reporter: Alexey Platonov
>Assignee: Ravil Galeyev
>Priority: Major
> Labels: new-feature
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to create compound Naive Bayes classifier as model composition of
> several Naive Bayes classifiers where each classifier represents subset of
> features of one type. For example such model may contain Naive Bayes model
> over Gauss Distribution for all continuous features and Naive Bayes model
> over Discrete Distribution for enum-like features.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11512) Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853334#comment-16853334 ] Ivan Rakov commented on IGNITE-11512: - Looks good to me. Please fix abbreviation plugin reports and proceed to merge (as long as fresh TC bot visa is received). > Add counter left partition for index rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-11512 > URL: https://issues.apache.org/jira/browse/IGNITE-11512 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.7 >Reporter: Alexand Polyakov >Assignee: Stanilovsky Evgeny >Priority: Major > > Now, if ran rebuild indexes, this can determined only on load CPU and thread > dump. The presence of the "how many partitions left to index" metric will > help determine whether the rebuilding is going on and on which cache, as well > as the percentage of completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9876) .NET: Thin Client: Implement Best Effort Affinity
[ https://issues.apache.org/jira/browse/IGNITE-9876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853208#comment-16853208 ] Pavel Tupitsyn commented on IGNITE-9876: [~ashapkin] please check the PR too. > .NET: Thin Client: Implement Best Effort Affinity > - > > Key: IGNITE-9876 > URL: https://issues.apache.org/jira/browse/IGNITE-9876 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-23 > Time Spent: 10m > Remaining Estimate: 0h > > See linked IEP-23. > First iteration is going to be an "experimental feature" with the following > limitations: > * No reconnect support for failed nodes > * No AffinityKeyMapped support -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9876) .NET: Thin Client: Implement Best Effort Affinity
[ https://issues.apache.org/jira/browse/IGNITE-9876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853205#comment-16853205 ] Pavel Tupitsyn commented on IGNITE-9876: [~isapego] good point, I will double check how node age affects partition distribution, I assumed it was deterministic. > .NET: Thin Client: Implement Best Effort Affinity > - > > Key: IGNITE-9876 > URL: https://issues.apache.org/jira/browse/IGNITE-9876 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-23 > Time Spent: 10m > Remaining Estimate: 0h > > See linked IEP-23. > First iteration is going to be an "experimental feature" with the following > limitations: > * No reconnect support for failed nodes > * No AffinityKeyMapped support -- 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&focusedCommentId=16853204#comment-16853204 ] Pavel Tupitsyn commented on IGNITE-11658: - [~ilyak] looks good, merged to master: f71f7776c50cb974a795437d4fb2ffcd0b399d10 Yes, transaction does not matter here I think (or am I missing something)? The premise of EF caching is that it works only when you use EF queries. Raw SQL queries, updating DB directly, stored procedures and other means of changing data can't be detected by our provider, and we can't invalidate data in those cases. > 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: 20m > 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, IDiction
[jira] [Commented] (IGNITE-9217) Uncomment 24 test classes in IgniteCacheTestSuite2 (Cache 2)
[
https://issues.apache.org/jira/browse/IGNITE-9217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853184#comment-16853184
]
Ignite TC Bot commented on IGNITE-9217:
---
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=4000255]]
* IgniteCacheTestSuite2:
GridCachePartitionedEvictionSelfTest.testEvictionTxPessimisticSerializable
* IgniteCacheTestSuite2: dht.IgniteCacheContainsKeyColocatedSelfTest
* IgniteCacheTestSuite2: near.IgniteCacheContainsKeyNearSelfTest
* IgniteCacheTestSuite2: dht.GridCachePartitionedNearDisabledMetricsSelfTest
{color:#d04437}Queries 2{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=4000257]]
* IgniteBinaryCacheQueryTestSuite2:
GridCachePartitionedTxMultiNodeSelfTest.testRemoveInTxQueried
* IgniteBinaryCacheQueryTestSuite2:
GridCachePartitionedTxMultiNodeSelfTest.testPutTwoEntriesInTx
* IgniteBinaryCacheQueryTestSuite2:
GridCachePartitionedTxMultiNodeSelfTest.testRemoveInTxQueriedMultiThreaded
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=4000260]]
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4000258]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3991047&buildTypeId=IgniteTests24Java8_RunAll]
> Uncomment 24 test classes in IgniteCacheTestSuite2 (Cache 2)
>
>
> Key: IGNITE-9217
> URL: https://issues.apache.org/jira/browse/IGNITE-9217
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
>
> //suite.addTestSuite(GridCacheLocalBasicStoreMultithreadedSelfTest.class);
> //suite.addTestSuite(GridCacheLocalTxReadTest.class);
> //suite.addTest(new
> TestSuite(RendezvousAffinityFunctionSelfTest.class));
> //suite.addTest(new
> TestSuite(GridCachePartitionedEntryLockSelfTest.class));
> //suite.addTest(new
> TestSuite(GridCachePartitionedEvictionSelfTest.class));
> //suite.addTest(new
> TestSuite(GridCachePartitionedNestedTxTest.class));
> //suite.addTest(new
> TestSuite(GridCachePartitionedStorePutSelfTest.class));
> //suite.addTest(new
> TestSuite(GridCachePartitionedTxConcurrentGetTest.class));
> //suite.addTest(new
> TestSuite(GridCachePartitionedTxMultiNodeSelfTest.class));
> //suite.addTest(new TestSuite(GridCachePartitionedTxReadTest.class));
> //suite.addTest(new
> TestSuite(NearCacheMultithreadedUpdateTest.class));
> //suite.addTest(new TestSuite(NearCachePutAllMultinodeTest.class));
> //suite.addTest(new
> TestSuite(IgniteCacheContainsKeyNearSelfTest.class));
> //suite.addTest(new TestSuite(IgniteCacheNearTxRollbackTest.class));
> //suite.addTest(new TestSuite(GridCacheColocatedDebugTest.class));
> //suite.addTest(new
> TestSuite(GridCacheDhtAtomicEvictionNearReadersSelfTest.class));
> //suite.addTest(new TestSuite(GridCacheDhtEntrySetSelfTest.class));
> //suite.addTest(new
> TestSuite(GridCacheDhtEvictionNearReadersSelfTest.class));
> //suite.addTest(new TestSuite(GridCacheDhtMultiBackupTest.class));
> //suite.addTest(new
> TestSuite(GridCacheDhtPreloadMessageCountTest.class));
> //suite.addTest(new
> TestSuite(GridCachePartitionedNearDisabledMetricsSelfTest.class));
> //suite.addTest(new
> TestSuite(IgniteCacheContainsKeyColocatedSelfTest.class));
> //suite.addTest(new
> TestSuite(IgniteCrossCacheTxNearEnabledSelfTest.class));
> //suite.addTest(new
> TestSuite(IgniteTxConsistencyColocatedRestartSelfTest.class));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9876) .NET: Thin Client: Implement Best Effort Affinity
[ https://issues.apache.org/jira/browse/IGNITE-9876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853148#comment-16853148 ] Igor Sapego commented on IGNITE-9876: - [~ptupitsyn] Overall looks good. I only see a single probably problematic place - AffinityAwarenessTest, as it heavily relies on order of nodes. My doubt here that it can be flaky. > .NET: Thin Client: Implement Best Effort Affinity > - > > Key: IGNITE-9876 > URL: https://issues.apache.org/jira/browse/IGNITE-9876 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-23 > Time Spent: 10m > Remaining Estimate: 0h > > See linked IEP-23. > First iteration is going to be an "experimental feature" with the following > limitations: > * No reconnect support for failed nodes > * No AffinityKeyMapped support -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11650) Commutication worker doesn't kick client node after expired idleConnTimeout
[
https://issues.apache.org/jira/browse/IGNITE-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov reassigned IGNITE-11650:
--
Assignee: (was: Anton Kalashnikov)
> Commutication worker doesn't kick client node after expired idleConnTimeout
> ---
>
> Key: IGNITE-11650
> URL: https://issues.apache.org/jira/browse/IGNITE-11650
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproduced by TcpCommunicationSpiFreezingClientTest.testFreezingClient
> {noformat}
> java.lang.AssertionError: Client node must be kicked from topology
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.fail(JUnitAssertAware.java:49)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiFreezingClientTest.testFreezingClient(TcpCommunicationSpiFreezingClientTest.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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:2102)
> {noformat}
--
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&focusedCommentId=16853102#comment-16853102 ] Ilya Kasnacheev commented on IGNITE-11658: -- [~ptupitsyn] please review amended fix. What do you think regarding whether we should immediately return regardless if transaction is null or not? > 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.<>
[jira] [Assigned] (IGNITE-11627) Test CheckpointFreeListTest.testRestoreFreeListCorrectlyAfterRandomStop always fails in DiskCompression suite
[ https://issues.apache.org/jira/browse/IGNITE-11627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov reassigned IGNITE-11627: -- Assignee: (was: Anton Kalashnikov) > Test CheckpointFreeListTest.testRestoreFreeListCorrectlyAfterRandomStop > always fails in DiskCompression suite > - > > Key: IGNITE-11627 > URL: https://issues.apache.org/jira/browse/IGNITE-11627 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5828425958400232265&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E -- 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&focusedCommentId=16853100#comment-16853100
]
Sergey Chugunov commented on IGNITE-11750:
--
[~DmitriyGovorukhin],
Change looks good to me, please proceed with merging.
Thank you for contribution!
> 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] [Comment Edited] (IGNITE-11888) CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC
[ https://issues.apache.org/jira/browse/IGNITE-11888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853094#comment-16853094 ] Ivan Pavlukhin edited comment on IGNITE-11888 at 5/31/19 2:58 PM: -- Also we should unmute tests on TC if needed. was (Author: pavlukhin): Also we need to unmute tests on TC if needed. > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails on GG TC > -- > > Key: IGNITE-11888 > URL: https://issues.apache.org/jira/browse/IGNITE-11888 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > A test > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11888) CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC
[ https://issues.apache.org/jira/browse/IGNITE-11888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853094#comment-16853094 ] Ivan Pavlukhin commented on IGNITE-11888: - Also we need to unmute tests on TC if needed. > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails on GG TC > -- > > Key: IGNITE-11888 > URL: https://issues.apache.org/jira/browse/IGNITE-11888 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > A test > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11883) Unable to find keys in testKeyAffinityDeploy
[
https://issues.apache.org/jira/browse/IGNITE-11883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853064#comment-16853064
]
Denis Mekhanikov commented on IGNITE-11883:
---
AFAICS, invocation to {{primaryKey}} cannot generate a primary key for the
provided cache on a tested node. It means that the node has no primary
partitions available locally. Most probably, it's not in the baseline topology.
> Unable to find keys in testKeyAffinityDeploy
>
>
> Key: IGNITE-11883
> URL: https://issues.apache.org/jira/browse/IGNITE-11883
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Priority: Major
>
> After turn on IgniteConfigVariationsAbstractTest
> IgniteServiceConfigVariationsFullApiTest#testKeyAffinityDeploy became failed
> - "Unable to find 1 required keys" [1].
> It is necessary to investigate the reason and fix the test.
> [1]
> https://ci.ignite.apache.org/viewLog.html?buildId=3978784&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode#testNameId5798659135386117314
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11857) Investigate performance drop after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853058#comment-16853058 ] Aleksey Plekhanov commented on IGNITE-11857: [~ustas] I've benchmarked IgnitePutTxImplicitBenchmark with exactly your parameters on two commits ([1] and [2]), but again didn't get any significant performance drop. Can you double check your results? [1]: [https://github.com/apache/ignite/commit/e7a90a445f09b0783918a0b5cfbeddee7102c45e] [2]: [https://github.com/apache/ignite/commit/b87bea845565394dd051a42cc097acd881cff1cf] > Investigate performance drop after IGNITE-10078 > --- > > Key: IGNITE-11857 > URL: https://issues.apache.org/jira/browse/IGNITE-11857 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Aleksey Plekhanov >Priority: Major > Attachments: ignite-config.xml, > run.properties.tx-optimistic-put-b-backup > > > After IGNITE-10078 yardstick tests show performance drop up to 8% in some > scenarios: > * tx-optim-repRead-put-get > * tx-optimistic-put > * tx-putAll > Partially this is due new update counter implementation, but not only. > Investigation is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6324) Transactional cache data partially available after crash.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-6324: -- Assignee: (was: Dmitriy Govorukhin) > Transactional cache data partially available after crash. > - > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 1.9, 2.1 >Reporter: Stanilovsky Evgeny >Priority: Major > Fix For: 2.8 > > Attachments: InterruptCommitedThreadTest.java > > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853035#comment-16853035 ] Ilya Kasnacheev commented on IGNITE-9409: - Hello! I think I'll drop version check, always use current version, i.e. the one this provider is built with. > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-9409: --- Assignee: Ilya Kasnacheev (was: Roman Shtykh) > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Ilya Kasnacheev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11887) Add more test scenarious for OWNING -> RENTING -> MOVING scenario
[ https://issues.apache.org/jira/browse/IGNITE-11887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-11887: --- Description: Relevant test GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions. Need to extend with 1. in-memory 2. under load was:Relevant test GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions > Add more test scenarious for OWNING -> RENTING -> MOVING scenario > - > > Key: IGNITE-11887 > URL: https://issues.apache.org/jira/browse/IGNITE-11887 > Project: Ignite > Issue Type: Test >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > > Relevant test > GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions. > Need to extend with > 1. in-memory > 2. under load -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11888) CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC
[ https://issues.apache.org/jira/browse/IGNITE-11888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853030#comment-16853030 ] Ivan Pavlukhin commented on IGNITE-11888: - It seems that expectations made in the test does not conform to guarantees provided by CQ. Briefly, the test closes a CQ and after that checks that notifications were received for all successfully completed updates. But it might not be true when an async callback is used. I edited the test so a query is closed after a notifications check in the async mode. > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails on GG TC > -- > > Key: IGNITE-11888 > URL: https://issues.apache.org/jira/browse/IGNITE-11888 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > A test > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11888) CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC
Ivan Pavlukhin created IGNITE-11888: --- Summary: CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC Key: IGNITE-11888 URL: https://issues.apache.org/jira/browse/IGNITE-11888 Project: Ignite Issue Type: Bug Components: cache Reporter: Ivan Pavlukhin Assignee: Ivan Pavlukhin A test CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11887) Add more test scenarious for OWNING -> RENTING -> MOVING scenario
Alexei Scherbakov created IGNITE-11887: -- Summary: Add more test scenarious for OWNING -> RENTING -> MOVING scenario Key: IGNITE-11887 URL: https://issues.apache.org/jira/browse/IGNITE-11887 Project: Ignite Issue Type: Test Reporter: Alexei Scherbakov Assignee: Alexei Scherbakov Relevant test GridCacheRebalancingWithAsyncClearingTest#testCorrectRebalancingCurrentlyRentingPartitions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11883) Unable to find keys in testKeyAffinityDeploy
[ https://issues.apache.org/jira/browse/IGNITE-11883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853027#comment-16853027 ] Ilya Kasnacheev commented on IGNITE-11883: -- [~dmekhanikov] Do you know anything about it? > Unable to find keys in testKeyAffinityDeploy > > > Key: IGNITE-11883 > URL: https://issues.apache.org/jira/browse/IGNITE-11883 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Priority: Major > > After turn on IgniteConfigVariationsAbstractTest > IgniteServiceConfigVariationsFullApiTest#testKeyAffinityDeploy became failed > - "Unable to find 1 required keys" [1]. > It is necessary to investigate the reason and fix the test. > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=3978784&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode#testNameId5798659135386117314 -- 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&focusedCommentId=16853016#comment-16853016 ] Sergey Antonov commented on IGNITE-11869: - [~dpavlov] Could you review my changes 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] [Created] (IGNITE-11886) Unable to check query result in IgniteCacheConfigVariationsQueryTest
Ivan Fedotov created IGNITE-11886: - Summary: Unable to check query result in IgniteCacheConfigVariationsQueryTest Key: IGNITE-11886 URL: https://issues.apache.org/jira/browse/IGNITE-11886 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest IgniteCacheConfigVariationsQueryTest #testLocalScanQuery and testScanQueryLocalFilter became failed [1]. Not all predicates were executed during query - failed to check execEvtLatch. [1] https://ci.ignite.apache.org/viewLog.html?buildId=3978709&buildTypeId=IgniteTests24Java8_QueriesConfigVariations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11885) Tests from IgniteCacheConfigVariationsFullApiTest failed on TC
Ivan Fedotov created IGNITE-11885: - Summary: Tests from IgniteCacheConfigVariationsFullApiTest failed on TC Key: IGNITE-11885 URL: https://issues.apache.org/jira/browse/IGNITE-11885 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest multiple tests in IgniteCacheConfigVariationsFullApiTest became failed [1]. The reason is that the expected value was not found in the cache, but deeper reason for each test can be different - this issue must be investigated. [1] https://ci.ignite.apache.org/viewLog.html?buildId=3978681&buildTypeId=IgniteTests24Java8_CacheFullApiBasicConfigVariations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11884) Time outed invokeAll tests in WithKeepBinaryCacheFullApiTest
Ivan Fedotov created IGNITE-11884: - Summary: Time outed invokeAll tests in WithKeepBinaryCacheFullApiTest Key: IGNITE-11884 URL: https://issues.apache.org/jira/browse/IGNITE-11884 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest 2 tests in WithKeepBinaryCacheFullApiTest became failed: testInvokeAll and testInvokeAllAsync. Tests failed because of time out [1]. [1] https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_CacheFullApiConfigVariations&buildId=3978682 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11883) Unable to find keys in testKeyAffinityDeploy
Ivan Fedotov created IGNITE-11883: - Summary: Unable to find keys in testKeyAffinityDeploy Key: IGNITE-11883 URL: https://issues.apache.org/jira/browse/IGNITE-11883 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest IgniteServiceConfigVariationsFullApiTest#testKeyAffinityDeploy became failed - "Unable to find 1 required keys" [1]. It is necessary to investigate the reason and fix the test. [1] https://ci.ignite.apache.org/viewLog.html?buildId=3978784&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode#testNameId5798659135386117314 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11882) Bugs related to SPI & tests fixes
[ https://issues.apache.org/jira/browse/IGNITE-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-11882: --- Description: This issue contains fixes for several issues: * Checkpointer thread waits for too long on pending futures without heartbeat. * Ignite build date is always shown in current timezone. UTC should be used. * Examples have troublesome "jackson" dependency version and can't be run as a result. * Baseline in discovery cache might be inconsistent with the actual baseline on in-memory clusters. * Distributed metastorage triggers failure handler on thread interruption while node stopping. * Spring test suite has issues: ** Exchange manager may invoke the failure processor on node stop with NodeStoppingException. ** KillerLifecycleBean should wait for the start of all nodes before stop node otherwise start the second node may lead to G.start() return null. * IgnitePdsCorruptedStoreTest.testReadOnlyMetaStore fails when run under root permissions. was: This issue contains fixes for several issues: * Checkpointer thread waits for too long on pending futures without heartbeat. * Ignite build date is always shown in current timezone. UTC should be used. * Examples have troublesome "jackson" dependency version and can't be run as a result. * Baseline in discovery cache might be inconsistent with the actual baseline on in-memory clusters. * Distributed metastorage triggers failure handler on thread interruption while node stopping. * Sometimes node restore fails with no segments to read, but there are no useful logs for diagnostic. * Spring test suite has issues: ** Exchange manager may invoke the failure processor on node stop with NodeStoppingException. ** KillerLifecycleBean should wait for the start of all nodes before stop node otherwise start the second node may lead to G.start() return null. * IgnitePdsCorruptedStoreTest.testReadOnlyMetaStore fails when run under root permissions. > Bugs related to SPI & tests fixes > - > > Key: IGNITE-11882 > URL: https://issues.apache.org/jira/browse/IGNITE-11882 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > This issue contains fixes for several issues: > * Checkpointer thread waits for too long on pending futures without > heartbeat. > * Ignite build date is always shown in current timezone. UTC should be used. > * Examples have troublesome "jackson" dependency version and can't be run as > a result. > * Baseline in discovery cache might be inconsistent with the actual baseline > on in-memory clusters. > * Distributed metastorage triggers failure handler on thread interruption > while node stopping. > * Spring test suite has issues: > ** Exchange manager may invoke the failure processor on node stop with > NodeStoppingException. > ** KillerLifecycleBean should wait for the start of all nodes before stop > node otherwise start the second node may lead to G.start() return null. > * IgnitePdsCorruptedStoreTest.testReadOnlyMetaStore fails when run under > root permissions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11882) Bugs related to SPI & tests fixes
[ https://issues.apache.org/jira/browse/IGNITE-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-11882: --- Labels: MakeTeamcityGreenAgain (was: ) > Bugs related to SPI & tests fixes > - > > Key: IGNITE-11882 > URL: https://issues.apache.org/jira/browse/IGNITE-11882 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > This issue contains fixes for several issues: > * Checkpointer thread waits for too long on pending futures without > heartbeat. > * Ignite build date is always shown in current timezone. UTC should be used. > * Examples have troublesome "jackson" dependency version and can't be run as > a result. > * Baseline in discovery cache might be inconsistent with the actual baseline > on in-memory clusters. > * Distributed metastorage triggers failure handler on thread interruption > while node stopping. > * Sometimes node restore fails with no segments to read, but there are no > useful logs for diagnostic. > * Spring test suite has issues: > ** Exchange manager may invoke the failure processor on node stop with > NodeStoppingException. > ** KillerLifecycleBean should wait for the start of all nodes before stop > node otherwise start the second node may lead to G.start() return null. > * IgnitePdsCorruptedStoreTest.testReadOnlyMetaStore fails when run under > root permissions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11882) Bugs related to SPI & tests fixes
[ https://issues.apache.org/jira/browse/IGNITE-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-11882: --- Fix Version/s: 2.8 > Bugs related to SPI & tests fixes > - > > Key: IGNITE-11882 > URL: https://issues.apache.org/jira/browse/IGNITE-11882 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > > This issue contains fixes for several issues: > * Checkpointer thread waits for too long on pending futures without > heartbeat. > * Ignite build date is always shown in current timezone. UTC should be used. > * Examples have troublesome "jackson" dependency version and can't be run as > a result. > * Baseline in discovery cache might be inconsistent with the actual baseline > on in-memory clusters. > * Distributed metastorage triggers failure handler on thread interruption > while node stopping. > * Sometimes node restore fails with no segments to read, but there are no > useful logs for diagnostic. > * Spring test suite has issues: > ** Exchange manager may invoke the failure processor on node stop with > NodeStoppingException. > ** KillerLifecycleBean should wait for the start of all nodes before stop > node otherwise start the second node may lead to G.start() return null. > * IgnitePdsCorruptedStoreTest.testReadOnlyMetaStore fails when run under > root permissions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11882) Bugs related to SPI & tests fixes
Ivan Bessonov created IGNITE-11882: -- Summary: Bugs related to SPI & tests fixes Key: IGNITE-11882 URL: https://issues.apache.org/jira/browse/IGNITE-11882 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov This issue contains fixes for several issues: * Checkpointer thread waits for too long on pending futures without heartbeat. * Ignite build date is always shown in current timezone. UTC should be used. * Examples have troublesome "jackson" dependency version and can't be run as a result. * Baseline in discovery cache might be inconsistent with the actual baseline on in-memory clusters. * Distributed metastorage triggers failure handler on thread interruption while node stopping. * Sometimes node restore fails with no segments to read, but there are no useful logs for diagnostic. * Spring test suite has issues: ** Exchange manager may invoke the failure processor on node stop with NodeStoppingException. ** KillerLifecycleBean should wait for the start of all nodes before stop node otherwise start the second node may lead to G.start() return null. * IgnitePdsCorruptedStoreTest.testReadOnlyMetaStore fails when run under root permissions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11857) Investigate performance drop after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852897#comment-16852897 ] Ilya Suntsov commented on IGNITE-11857: --- [~alex_pl] I've attached configs. > Investigate performance drop after IGNITE-10078 > --- > > Key: IGNITE-11857 > URL: https://issues.apache.org/jira/browse/IGNITE-11857 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Aleksey Plekhanov >Priority: Major > Attachments: ignite-config.xml, > run.properties.tx-optimistic-put-b-backup > > > After IGNITE-10078 yardstick tests show performance drop up to 8% in some > scenarios: > * tx-optim-repRead-put-get > * tx-optimistic-put > * tx-putAll > Partially this is due new update counter implementation, but not only. > Investigation is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11857) Investigate performance drop after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Suntsov updated IGNITE-11857: -- Attachment: ignite-config.xml run.properties.tx-optimistic-put-b-backup > Investigate performance drop after IGNITE-10078 > --- > > Key: IGNITE-11857 > URL: https://issues.apache.org/jira/browse/IGNITE-11857 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Aleksey Plekhanov >Priority: Major > Attachments: ignite-config.xml, > run.properties.tx-optimistic-put-b-backup > > > After IGNITE-10078 yardstick tests show performance drop up to 8% in some > scenarios: > * tx-optim-repRead-put-get > * tx-optimistic-put > * tx-putAll > Partially this is due new update counter implementation, but not only. > Investigation is required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10913) Reduce heap occupation by o.a.i.i.processors.cache.persistence.file.FilePageStore instances.
[ https://issues.apache.org/jira/browse/IGNITE-10913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852884#comment-16852884 ] Eduard Shangareev commented on IGNITE-10913: Looks good. Thank you for contribution. > Reduce heap occupation by > o.a.i.i.processors.cache.persistence.file.FilePageStore instances. > > > Key: IGNITE-10913 > URL: https://issues.apache.org/jira/browse/IGNITE-10913 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > With large topology and large amount of caches/partitions and enabled > persistence could be millions of FilePageStore objects in heap (for each > partition). > Each instance has a reference to a File (field cfgFile) storing as String > absolute path to a partition. > Also internal File inplementation (on example UnixFile) also allocates space > for file path. > I observed about 2Gb of heap space occupied by these objects in one of > environments. > Solution: dereference (set to null) cfgFile after object creation, create > File object lazily on demand when needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11512) Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-11512: - Assignee: Stanilovsky Evgeny (was: Alexand Polyakov) > Add counter left partition for index rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-11512 > URL: https://issues.apache.org/jira/browse/IGNITE-11512 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.7 >Reporter: Alexand Polyakov >Assignee: Stanilovsky Evgeny >Priority: Major > > Now, if ran rebuild indexes, this can determined only on load CPU and thread > dump. The presence of the "how many partitions left to index" metric will > help determine whether the rebuilding is going on and on which cache, as well > as the percentage of completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov reassigned IGNITE-7883:
Assignee: Stanilovsky Evgeny (was: Alexand Polyakov)
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11861) GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-11861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852878#comment-16852878 ] Dmitriy Govorukhin commented on IGNITE-11861: - Muted test, merge to master. > GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC > - > > Key: IGNITE-11861 > URL: https://issues.apache.org/jira/browse/IGNITE-11861 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4911099288413140059&tab=testDetails] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11861) GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-11861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-11861: --- Assignee: (was: Ivan Bessonov) > GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC > - > > Key: IGNITE-11861 > URL: https://issues.apache.org/jira/browse/IGNITE-11861 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4911099288413140059&tab=testDetails] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11878) Rebuild index skips MOVING partitions when historical re balance
[
https://issues.apache.org/jira/browse/IGNITE-11878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852842#comment-16852842
]
Ignite TC Bot commented on IGNITE-11878:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 4{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=3997501]]
* IgnitePdsMvccTestSuite4:
IgniteRebalanceOnCachesStoppingOrDestroyingTest.testDestroySpecificCacheAndCacheGroupSecondGroup
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=3997503]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3989045&buildTypeId=IgniteTests24Java8_RunAll]
> Rebuild index skips MOVING partitions when historical re balance
>
>
> Key: IGNITE-11878
> URL: https://issues.apache.org/jira/browse/IGNITE-11878
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5, 2.6, 2.7
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Rebuild index skips MOVING partitions when historical rebalance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11857) Investigate performance drop after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852833#comment-16852833 ] Aleksey Plekhanov commented on IGNITE-11857: [~ascherbakov] can you provide full parameters (benchmark.properties and ignite-config.xml files) of scenarios where you got a performance drop? I've run some benchmarks with these scenarios but didn't see any notable performance drop. Also, I've profiled code with different ignite/cache/transactions settings and again didn't get any drop. According to my measures, new counters implementation is not resource-consuming and transaction spend no more than 0.5% of the time in "update counter" methods. > 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)
[jira] [Commented] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
[ https://issues.apache.org/jira/browse/IGNITE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852780#comment-16852780 ] Roman Shtykh commented on IGNITE-9409: -- [~ilyak] no plans for now. You can reassign to yourself. What mechanisms are you planning to use? (just curious) > yarn IgniteProvider uses an obsolete URL for a version check > > > Key: IGNITE-9409 > URL: https://issues.apache.org/jira/browse/IGNITE-9409 > Project: Ignite > Issue Type: Bug >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Major > -- 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&focusedCommentId=16852730#comment-16852730 ] Pavel Tupitsyn commented on IGNITE-11658: - [~ilyak] the fix makes sense. Two issues: * No tests for this. Unfortunately, there are no Stored Procedures in Sqlite or SQL CE, so that would be hard to do. * No invalidation when Stored Procedure modifies the data. Nothing we can do again, not possible to know what that SP does. So please do the following: * Invert if to reduce nesting(if ... return) * Add a comment explaining when this happens. Thanks! > 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 > controllerCont
[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&focusedCommentId=16852723#comment-16852723 ] Ivan Bessonov commented on IGNITE-11346: Hi [~dpavlov], [~Maxoid], I see no more issues with the code, so let's run checkstyle suite (at least) and merge it. 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: 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)
