[jira] [Created] (IGNITE-10727) [ML] InfModel and Model merging
Alexey Platonov created IGNITE-10727: Summary: [ML] InfModel and Model merging Key: IGNITE-10727 URL: https://issues.apache.org/jira/browse/IGNITE-10727 Project: Ignite Issue Type: Improvement Components: ml Reporter: Alexey Platonov Assignee: Anton Dmitriev Fix For: 2.8 Currently "InfModel" and "Model" provide parallel architecture in terms of using of "InfModels" in after-learning steps like compositions, estimations etc. I propose to move "InfModel" to top of models hierarchy and rename it to just "Model" and current "Model" rename to "LearnedModel/LocalModel/Your_ad_may_be_here". So in this way "InfModel" will be just model with apply-function for generic I-O values and "Model" will be serializable thing on Vector-Double. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10695) MVCC: Fix cache API conditional update operations.
[ https://issues.apache.org/jira/browse/IGNITE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10695: -- Issue Type: Improvement (was: Bug) > MVCC: Fix cache API conditional update operations. > -- > > Key: IGNITE-10695 > URL: https://issues.apache.org/jira/browse/IGNITE-10695 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > Operation like putIfAbsent and replace now tries to transfer Predicate > instance (filter) to remote node. > # Predicates are transferred to remote node with each update. > # Predicate should be transferred only for "replace" operation if certain > entry provided, otherwise we should send a correct operation code and use > corresponding static filter on remote side. > # This change will break protocol compatibility. Should we bother about it? > Let's fix protocol and add tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10238) Intermittent Client Nodes suite hang
[
https://issues.apache.org/jira/browse/IGNITE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723767#comment-16723767
]
Sergey Chugunov commented on IGNITE-10238:
--
I investigated the code a bit more and found out the history of this change: in
order to offload plain old *disco-msg-worker* thread IGNITE-9398 introduced new
thread *disco-notifier-worker.*
But it was't marked by _IgniteDiscoveryThread_ interface and later fix
IGNITE-9895 didn't solve the issue.
We need to put this marker interface to _IgniteThread_ that runs
_DiscoveryMessageNotifierWorker_ and not to worker itself.
> Intermittent Client Nodes suite hang
>
>
> Key: IGNITE-10238
> URL: https://issues.apache.org/jira/browse/IGNITE-10238
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Amelchev Nikita
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> There are occasional hangs of Client Nodes suite in master. A quick peek at
> the thread dumps reveals an interesting deadlock (only relevant parts of the
> thread dump are left):
> {code}
> "disco-notifier-worker-#634%internal.IgniteClientReconnectApiExceptionTest0%"
> #791 prio=5 os_prio=0 tid=0x7f990c12d800 nid=0x11b9 waiting on condition
> [0x7f991a0eb000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:656)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:206)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1293)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2007)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:101)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10131)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10160)
> at
> org.apache.ignite.internal.GridEventConsumeHandler.p2pUnmarshal(GridEventConsumeHandler.java:390)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1362)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:111)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:203)
> at
>
[jira] [Assigned] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov reassigned IGNITE-8823:
Assignee: (was: Andrey Kuznetsov)
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Gura
>Priority: Major
> Fix For: 2.8
>
> Attachments: Ignite8823ReproducerTest.java
>
>
> Reproducable by test method {{testCreateConsistencyMultithreaded}} in
> {{IgfsPrimaryMultiNodeSelfTest}} and
> {{IgfsPrimaryRelaxedConsistencyMultiNodeSelfTest}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
>
[jira] [Commented] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723706#comment-16723706
]
Andrey Kuznetsov commented on IGNITE-8823:
--
[~avinogradov], thanks for your comments.
I've partially reverted the assertion in {{IgniteTxManager.removeTxReturn}}
introduced by IGNITE-5510. Now the issue is reproducible with
{{CacheRebalancingWithConcurrentProcessingTest.testMultithreadedNoOpProcessingWhileRebalanceInProgress}}
and needs additional investigation.
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Ignite8823ReproducerTest.java
>
>
> Reproducable by test method {{testCreateConsistencyMultithreaded}} in
> {{IgfsPrimaryMultiNodeSelfTest}} and
> {{IgfsPrimaryRelaxedConsistencyMultiNodeSelfTest}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
>
[jira] [Commented] (IGNITE-9839) Web Console: update to RxJS 6
[ https://issues.apache.org/jira/browse/IGNITE-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723668#comment-16723668 ] Ilya Borisov commented on IGNITE-9839: -- master has been merged into the branch. > Web Console: update to RxJS 6 > - > > Key: IGNITE-9839 > URL: https://issues.apache.org/jira/browse/IGNITE-9839 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > Time Spent: 6h 47m > Remaining Estimate: 0h > > Since RxJS 6 is required by latest version of Angular, we won't be able to > proceed with UI framework migration without it. To do: update import paths, > convert to pipe API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4440) scalar misses bcastCall() in ScalarProjectionPimp class
[
https://issues.apache.org/jira/browse/IGNITE-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov resolved IGNITE-4440.
--
Resolution: Incomplete
> scalar misses bcastCall() in ScalarProjectionPimp class
> ---
>
> Key: IGNITE-4440
> URL: https://issues.apache.org/jira/browse/IGNITE-4440
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.8
>Reporter: Alexander Prokofyev
>Assignee: Alexander Prokofyev
>Priority: Minor
> Labels: scala
>
> It would be nice if ScalarProjectionPimp will add also bcastCall() method to
> ClusterGroup class like it already does with
> {code}
> def bcastRun(@Nullable r: Run, @Nullable p: NF) {
> value.ignite().compute(forPredicate(p)).broadcast(toRunnable(r))
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-4440) scalar misses bcastCall() in ScalarProjectionPimp class
[
https://issues.apache.org/jira/browse/IGNITE-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov closed IGNITE-4440.
> scalar misses bcastCall() in ScalarProjectionPimp class
> ---
>
> Key: IGNITE-4440
> URL: https://issues.apache.org/jira/browse/IGNITE-4440
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.8
>Reporter: Alexander Prokofyev
>Assignee: Alexander Prokofyev
>Priority: Minor
> Labels: scala
>
> It would be nice if ScalarProjectionPimp will add also bcastCall() method to
> ClusterGroup class like it already does with
> {code}
> def bcastRun(@Nullable r: Run, @Nullable p: NF) {
> value.ignite().compute(forPredicate(p)).broadcast(toRunnable(r))
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4890) Unable to create tables automatically because 'unconfigured columnfamily' error is not handled for older Cassandra versions
[
https://issues.apache.org/jira/browse/IGNITE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723639#comment-16723639
]
ASF GitHub Bot commented on IGNITE-4890:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/1719
> Unable to create tables automatically because 'unconfigured columnfamily'
> error is not handled for older Cassandra versions
> ---
>
> Key: IGNITE-4890
> URL: https://issues.apache.org/jira/browse/IGNITE-4890
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Venky Kandaswamy
>Assignee: Venky Kandaswamy
>Priority: Major
> Labels: patch
> Fix For: 2.8
>
>
> PROBLEM:
> When running Ignite with older Cassandra versions (i.e DSE 4.8.10, Cassandra
> 2.1.6 or older), we noticed that only the first tabel in an Ignite config is
> created and the others fail with 'unconfigured columnfamily' exception.
> SUGGESTED FIX:
> It appears that the error from Cassandra is changed in newer versions to
> 'unconfigured table ...' and this is handled. The conditions checked in
> org.apache.ignite.cache.store.cassandra.common.CassandraHelper needs to be
> modified to handle the older Cassandra errors.
> We are submitting a patch to do that.
> 13:44:28,753 ERROR com.walmartlabs.qarth.ignite.tests.utils.CacheStoreHelper
> [main] - Failed to execute Cassandra CQL statement: insert into
> "test1"."blob_test2" ("key", "value") values (?,?);
> class org.apache.ignite.IgniteException: Failed to execute Cassandra CQL
> statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:163)
> at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:276)
> at
> com.walmartlabs.qarth.ignite.tests.cassandra.CassandraDirectPersistenceTest.blobStrategyTest(CassandraDirectPersistenceTest.java:233)
> 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:497)
> 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.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: class org.apache.ignite.IgniteException: Failed to prepare
> Cassandra CQL statement: insert into "test1"."blob_test2" ("key", "value")
> values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:615)
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:133)
> ... 27 more
> Caused by:
[jira] [Closed] (IGNITE-4890) Unable to create tables automatically because 'unconfigured columnfamily' error is not handled for older Cassandra versions
[
https://issues.apache.org/jira/browse/IGNITE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov closed IGNITE-4890.
> Unable to create tables automatically because 'unconfigured columnfamily'
> error is not handled for older Cassandra versions
> ---
>
> Key: IGNITE-4890
> URL: https://issues.apache.org/jira/browse/IGNITE-4890
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Venky Kandaswamy
>Assignee: Venky Kandaswamy
>Priority: Major
> Labels: patch
> Fix For: 2.8
>
>
> PROBLEM:
> When running Ignite with older Cassandra versions (i.e DSE 4.8.10, Cassandra
> 2.1.6 or older), we noticed that only the first tabel in an Ignite config is
> created and the others fail with 'unconfigured columnfamily' exception.
> SUGGESTED FIX:
> It appears that the error from Cassandra is changed in newer versions to
> 'unconfigured table ...' and this is handled. The conditions checked in
> org.apache.ignite.cache.store.cassandra.common.CassandraHelper needs to be
> modified to handle the older Cassandra errors.
> We are submitting a patch to do that.
> 13:44:28,753 ERROR com.walmartlabs.qarth.ignite.tests.utils.CacheStoreHelper
> [main] - Failed to execute Cassandra CQL statement: insert into
> "test1"."blob_test2" ("key", "value") values (?,?);
> class org.apache.ignite.IgniteException: Failed to execute Cassandra CQL
> statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:163)
> at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:276)
> at
> com.walmartlabs.qarth.ignite.tests.cassandra.CassandraDirectPersistenceTest.blobStrategyTest(CassandraDirectPersistenceTest.java:233)
> 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:497)
> 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.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: class org.apache.ignite.IgniteException: Failed to prepare
> Cassandra CQL statement: insert into "test1"."blob_test2" ("key", "value")
> values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:615)
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:133)
> ... 27 more
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException:
> unconfigured columnfamily blob_test2
> at
>
[jira] [Updated] (IGNITE-10726) Web console: error in console after configuration import
[ https://issues.apache.org/jira/browse/IGNITE-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-10726: -- Description: *What happens:* AngularJS error is thrown when switching between configuration domain models. *How to reproduce:* 1. Start demo mode, launch web agent. 2. Go to configuration and perform DB import once. 3. Open the result configuration domain models section. 4. Import from in place DB, choose to overwrite domain models. 5. Switch between several domain models. The issue does not persist after page reload, this looks like faulty caching. was: What happens: AngularJS error is thrown when switching between configuration domain models. !the error.png! How to reproduce: 1. Start demo mode, launch web agent. 2. Go to configuration and perform DB import once. 3. Open the result configuration domain models section. 4. Import from in place DB, choose to overwrite domain models. 5. Switch between several domain models. The issue does not persist after page reload, this looks like faulty caching. > Web console: error in console after configuration import > > > Key: IGNITE-10726 > URL: https://issues.apache.org/jira/browse/IGNITE-10726 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: the error.png > > Original Estimate: 6h > Remaining Estimate: 6h > > *What happens:* > AngularJS error is thrown when switching between configuration domain models. > *How to reproduce:* > 1. Start demo mode, launch web agent. > 2. Go to configuration and perform DB import once. > 3. Open the result configuration domain models section. > 4. Import from in place DB, choose to overwrite domain models. > 5. Switch between several domain models. > The issue does not persist after page reload, this looks like faulty caching. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10726) Web console: error in console after configuration import
[ https://issues.apache.org/jira/browse/IGNITE-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-10726: -- Attachment: the error.png > Web console: error in console after configuration import > > > Key: IGNITE-10726 > URL: https://issues.apache.org/jira/browse/IGNITE-10726 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: the error.png > > Original Estimate: 6h > Remaining Estimate: 6h > > What happens: > AngularJS error is thrown when switching between configuration domain models. > How to reproduce: > 1. Start demo mode, launch web agent. > 2. Go to configuration and perform DB import once. > 3. Open the result configuration domain models section. > 4. Import from in place DB, choose to overwrite domain models. > 5. Switch between several domain models. > The issue does not persist after page reload, this looks like faulty caching. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10726) Web console: error in console after configuration import
[ https://issues.apache.org/jira/browse/IGNITE-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-10726: -- Description: What happens: AngularJS error is thrown when switching between configuration domain models. !the error.png! How to reproduce: 1. Start demo mode, launch web agent. 2. Go to configuration and perform DB import once. 3. Open the result configuration domain models section. 4. Import from in place DB, choose to overwrite domain models. 5. Switch between several domain models. The issue does not persist after page reload, this looks like faulty caching. was: What happens: AngularJS error is thrown when switching between configuration domain models. How to reproduce: 1. Start demo mode, launch web agent. 2. Go to configuration and perform DB import once. 3. Open the result configuration domain models section. 4. Import from in place DB, choose to overwrite domain models. 5. Switch between several domain models. The issue does not persist after page reload, this looks like faulty caching. > Web console: error in console after configuration import > > > Key: IGNITE-10726 > URL: https://issues.apache.org/jira/browse/IGNITE-10726 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: the error.png > > Original Estimate: 6h > Remaining Estimate: 6h > > What happens: > AngularJS error is thrown when switching between configuration domain models. > !the error.png! > How to reproduce: > 1. Start demo mode, launch web agent. > 2. Go to configuration and perform DB import once. > 3. Open the result configuration domain models section. > 4. Import from in place DB, choose to overwrite domain models. > 5. Switch between several domain models. > The issue does not persist after page reload, this looks like faulty caching. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10726) Web console: error in console after configuration import
Ilya Borisov created IGNITE-10726: - Summary: Web console: error in console after configuration import Key: IGNITE-10726 URL: https://issues.apache.org/jira/browse/IGNITE-10726 Project: Ignite Issue Type: Bug Components: UI, wizards Reporter: Ilya Borisov Assignee: Vasiliy Sisko Attachments: the error.png What happens: AngularJS error is thrown when switching between configuration domain models. How to reproduce: 1. Start demo mode, launch web agent. 2. Go to configuration and perform DB import once. 3. Open the result configuration domain models section. 4. Import from in place DB, choose to overwrite domain models. 5. Switch between several domain models. The issue does not persist after page reload, this looks like faulty caching. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4890) Unable to create tables automatically because 'unconfigured columnfamily' error is not handled for older Cassandra versions
[
https://issues.apache.org/jira/browse/IGNITE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-4890:
-
Fix Version/s: 2.8
> Unable to create tables automatically because 'unconfigured columnfamily'
> error is not handled for older Cassandra versions
> ---
>
> Key: IGNITE-4890
> URL: https://issues.apache.org/jira/browse/IGNITE-4890
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Venky Kandaswamy
>Assignee: Venky Kandaswamy
>Priority: Major
> Labels: patch
> Fix For: 2.8
>
>
> PROBLEM:
> When running Ignite with older Cassandra versions (i.e DSE 4.8.10, Cassandra
> 2.1.6 or older), we noticed that only the first tabel in an Ignite config is
> created and the others fail with 'unconfigured columnfamily' exception.
> SUGGESTED FIX:
> It appears that the error from Cassandra is changed in newer versions to
> 'unconfigured table ...' and this is handled. The conditions checked in
> org.apache.ignite.cache.store.cassandra.common.CassandraHelper needs to be
> modified to handle the older Cassandra errors.
> We are submitting a patch to do that.
> 13:44:28,753 ERROR com.walmartlabs.qarth.ignite.tests.utils.CacheStoreHelper
> [main] - Failed to execute Cassandra CQL statement: insert into
> "test1"."blob_test2" ("key", "value") values (?,?);
> class org.apache.ignite.IgniteException: Failed to execute Cassandra CQL
> statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:163)
> at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:276)
> at
> com.walmartlabs.qarth.ignite.tests.cassandra.CassandraDirectPersistenceTest.blobStrategyTest(CassandraDirectPersistenceTest.java:233)
> 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:497)
> 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.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: class org.apache.ignite.IgniteException: Failed to prepare
> Cassandra CQL statement: insert into "test1"."blob_test2" ("key", "value")
> values (?,?);
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:615)
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:133)
> ... 27 more
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException:
> unconfigured columnfamily blob_test2
> at
>
[jira] [Closed] (IGNITE-10239) Web Console: Create a new top menu
[ https://issues.apache.org/jira/browse/IGNITE-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-10239. --- > Web Console: Create a new top menu > -- > > Key: IGNITE-10239 > URL: https://issues.apache.org/jira/browse/IGNITE-10239 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > Attachments: Top-ignite-menu.png, navigation links block scroll > example.png, new design example.png > > Time Spent: 11h 19m > Remaining Estimate: 0h > > New navigation menu design moves navigation to left sidebar in order to save > some vertical space. The sidebar with navigation links has two modes - > collapsed, with icon-only link, and expanded, with full-text links. By > default, it's kept collapsed, but user can click on toggle sidebar button > left of logo to expand or collapse it again. For now, the sidebar state does > not persist between page reloads. The footer should be moved to expanded > sidebar, except for public screens like "sign in" or "reset password". > Navigation links block in sidebar should scroll and indicate that some > content is hidden when viewport height is low enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723613#comment-16723613
]
Ignite TC Bot commented on IGNITE-9845:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2579475]]
* CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Hibernate 2{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2579481]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Hibernate 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2579483]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2579479]]
* IgniteCacheTestSuite7: CacheGroupMetricsMBeanTest.testCacheGroupMetrics -
0,0% fails in last 344 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2573513buildTypeId=IgniteTests24Java8_RunAll]
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
> Attachments: generate.bat
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config:*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10626) Save authenticated Webconsole session for more than one page refresh
[ https://issues.apache.org/jira/browse/IGNITE-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10626: -- Ignite Flags: (was: Docs Required) > Save authenticated Webconsole session for more than one page refresh > > > Key: IGNITE-10626 > URL: https://issues.apache.org/jira/browse/IGNITE-10626 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Priority: Major > Fix For: 2.8 > > > Now, it's needed to enter login and password after each page refresh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10627) Support custom preferences like date format and other similar features
[ https://issues.apache.org/jira/browse/IGNITE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10627: - Assignee: Alexander Kalinin [~alexdel], Please implement "Preferences" screen. I think you will need to cooperate with [~vabramova] with screen design. > Support custom preferences like date format and other similar features > -- > > Key: IGNITE-10627 > URL: https://issues.apache.org/jira/browse/IGNITE-10627 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Alexander Kalinin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10627) Support custom preferences like date format and other similar features
[ https://issues.apache.org/jira/browse/IGNITE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10627: -- Fix Version/s: 2.8 > Support custom preferences like date format and other similar features > -- > > Key: IGNITE-10627 > URL: https://issues.apache.org/jira/browse/IGNITE-10627 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10626) Save authenticated Webconsole session for more than one page refresh
[ https://issues.apache.org/jira/browse/IGNITE-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10626: - Assignee: Vasiliy Sisko [~vsisko], we can store session tokens at backend and add them to requests. Please investigate. > Save authenticated Webconsole session for more than one page refresh > > > Key: IGNITE-10626 > URL: https://issues.apache.org/jira/browse/IGNITE-10626 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Vasiliy Sisko >Priority: Major > Fix For: 2.8 > > > Now, it's needed to enter login and password after each page refresh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10626) Save authenticated Webconsole session for more than one page refresh
[ https://issues.apache.org/jira/browse/IGNITE-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10626: -- Fix Version/s: 2.8 > Save authenticated Webconsole session for more than one page refresh > > > Key: IGNITE-10626 > URL: https://issues.apache.org/jira/browse/IGNITE-10626 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Priority: Major > Fix For: 2.8 > > > Now, it's needed to enter login and password after each page refresh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-2771) Document machine safety
[ https://issues.apache.org/jira/browse/IGNITE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg updated IGNITE-2771: Fix Version/s: 2.8 > Document machine safety > --- > > Key: IGNITE-2771 > URL: https://issues.apache.org/jira/browse/IGNITE-2771 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723385#comment-16723385
]
Vladimir Ozerov edited comment on IGNITE-10643 at 12/17/18 10:04 PM:
-
Re-run due to faulty TC:
https://ci.ignite.apache.org/viewQueued.html?itemId=2578335
was (Author: vozerov):
https://ci.ignite.apache.org/viewQueued.html?itemId=258
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10723) Investigate failures related to enabling tests (IGNITE-1094)
[ https://issues.apache.org/jira/browse/IGNITE-10723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10723: Labels: MakeTeamcityGreenAgain (was: ) > Investigate failures related to enabling tests (IGNITE-1094) > > > Key: IGNITE-10723 > URL: https://issues.apache.org/jira/browse/IGNITE-10723 > Project: Ignite > Issue Type: Test >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: MakeTeamcityGreenAgain > > The following tests were muted due to IGNITE-1094: > * IgniteChangeGlobalStateTest.testActivateAfterFailGetLock > * CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration > (Hibernate-4.2) > * CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration > (Hibernate-5.1) > * IgniteSqlSchemaIndexingTest.testCaseSensitive > * IgniteSqlSchemaIndexingTest.testCustomSchemaMultipleCachesTablesCollision > * GridPartitionedCacheJtaLookupClassNameSelfTest.testIncompatibleTmLookup > * CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration > * CacheJdbcPojoStoreFactorySelfTest.testIncorrectBeanConfiguration > These test should be analyzed and enabled on the TC if possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9943) Update documentation for default WAL archive size (added auto-adjust)
[ https://issues.apache.org/jira/browse/IGNITE-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg resolved IGNITE-9943. - Resolution: Fixed > Update documentation for default WAL archive size (added auto-adjust) > - > > Key: IGNITE-9943 > URL: https://issues.apache.org/jira/browse/IGNITE-9943 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9943) Update documentation for default WAL archive size (added auto-adjust)
[ https://issues.apache.org/jira/browse/IGNITE-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723410#comment-16723410 ] Prachi Garg commented on IGNITE-9943: - [~Artem Budnikov], looks good. > Update documentation for default WAL archive size (added auto-adjust) > - > > Key: IGNITE-9943 > URL: https://issues.apache.org/jira/browse/IGNITE-9943 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9943) Update documentation for default WAL archive size (added auto-adjust)
[ https://issues.apache.org/jira/browse/IGNITE-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg closed IGNITE-9943. --- > Update documentation for default WAL archive size (added auto-adjust) > - > > Key: IGNITE-9943 > URL: https://issues.apache.org/jira/browse/IGNITE-9943 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9485) Update documentation for ScanQuery with setLocal flag
[ https://issues.apache.org/jira/browse/IGNITE-9485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-9485: --- Assignee: Artem Budnikov > Update documentation for ScanQuery with setLocal flag > - > > Key: IGNITE-9485 > URL: https://issues.apache.org/jira/browse/IGNITE-9485 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8629) There is no documentation about on which nodes Ignite Predicate will be executed during service/cache deploying with NodeFilter
[
https://issues.apache.org/jira/browse/IGNITE-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg reassigned IGNITE-8629:
---
Assignee: Prachi Garg
> There is no documentation about on which nodes Ignite Predicate will be
> executed during service/cache deploying with NodeFilter
> ---
>
> Key: IGNITE-8629
> URL: https://issues.apache.org/jira/browse/IGNITE-8629
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.8
>
>
> In documentation we could see that:
> [https://apacheignite.readme.io/docs/service-grid#section-node-filter-based-deployment]
> This approach is based on a filtering predicate that gets called on every
> node at the time Ignite Service engine determines a set of possible
> candidates for the Ignite Service deployment.
> Looks like it's not correct because in Ignite 2.4 next code:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite2.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> @IgniteInstanceResource Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Will be executed only on "ignite-1"
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> Looks like ignite-1 is the coordinator node in this case. But this behavior
> is different from described in the documentation.
> Also, this should be described in case of the cache deployment:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite2.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-8411: --- Assignee: Prachi Garg > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7739) Write about Spring Injection and IgniteSpringBean in documentation
[ https://issues.apache.org/jira/browse/IGNITE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-7739: --- Assignee: Prachi Garg > Write about Spring Injection and IgniteSpringBean in documentation > -- > > Key: IGNITE-7739 > URL: https://issues.apache.org/jira/browse/IGNITE-7739 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Ilya Kasnacheev >Assignee: Prachi Garg >Priority: Minor > Fix For: 2.8 > > > Currently there is no mention of IgniteSpringBean on readme.io > We have section https://apacheignite.readme.io/docs/resource-injection but > it's totally not obvious how to make e.g. SpringResource work, what are > pre-requisites. > Thing is, if Ignite creates Spring context (via Ignition), then Spring > injection would work out of box. > If Spring context creates Ignite as a bean, that bean should be > IgniteSpringBean and not Ignite. Otherwise, Spring context and lifecycle > would not be visible to Ignite and injection won't work. > On unrelated note, maybe we need support for Spring Boot already? See > https://habrahabr.ru/post/310672/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723385#comment-16723385
]
Vladimir Ozerov commented on IGNITE-10643:
--
https://ci.ignite.apache.org/viewQueued.html?itemId=258
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-1112) Atomic cache #get method returns old value if near cache enabled after second putAll.
[
https://issues.apache.org/jira/browse/IGNITE-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-1112:
---
Labels: MakeTeamcityGreenAgain Muted_test (was: MakeTeamcityGreenAgain)
> Atomic cache #get method returns old value if near cache enabled after second
> putAll.
> -
>
> Key: IGNITE-1112
> URL: https://issues.apache.org/jira/browse/IGNITE-1112
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Andrey Gura
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
>
> These tests failed:
> GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest.testPutAllPutAll
> GridCacheAtomicNearEnabledFairAffinityMultiJvmFullApiSelfTest.testPutAllPutAll
>
> These tests work fine in one jvm, but fails in multi-JVM case.
> Looks like, second putAll does not update data at near cache and get method
> returns old value. But iteration from cache return actual data.
> See ignite-648-putAll branch with more debug information.
> Original log for
> GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest.testPutAllPutAll.
> {noformat}
> junit.framework.AssertionFailedError: expected:<64> but was:<8>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:86)
> at junit.framework.TestCase.assertEquals(TestCase.java:253)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedMultiNodeFullApiSelfTest.testPutAllPutAll(GridCachePartitionedMultiNodeFullApiSelfTest.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1618)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1561)
> --- Stdout: ---
> [17:59:33,524][INFO ][main][root] >>> Starting test: testPutAllPutAll <<<
> [17:59:33,527][INFO ][test-runner][root] > Grid0:
> 00ac324c-cfd0-4433-b00b-1048858b6000
> [17:59:33,528][INFO ][test-runner][root] > Grid1:
> 0a0c6919-127f-4d44-988d-8a236d033379
> [17:59:33,530][INFO ][test-runner][root] > Grid2:
> 17e5a787-5b00-4c68-88ea-cf0e393fefd1
> [17:59:33,531][INFO ][test-runner][root] > Grid3:
> d63de793-e754-4849-826e-2f43669385ba
> [17:59:33,544][INFO ][Thread-110][jvm-0a0c6919]
> [17:59:33,544][INFO][ignite-#12%pub-multijvm.GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest1%][GridDeploymentLocalStore]
> Class locally deployed: class
> org.apache.ignite.testframework.junits.multijvm.IgniteCacheProcessProxy$10
> [17:59:33,736][INFO ][test-runner][root] >>> Before second put.
> [17:59:33,736][INFO ][test-runner][GridDeploymentLocalStore] Class locally
> deployed: class
> org.apache.ignite.testframework.junits.multijvm.IgniteCacheProcessProxy$17
> [17:59:33,741][INFO ][Thread-110][jvm-0a0c6919]
> [17:59:33,741][INFO][ignite-#16%pub-multijvm.GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest1%][GridDeploymentLocalStore]
> Class locally deployed: class
> org.apache.ignite.testframework.junits.multijvm.IgniteCacheProcessProxy$17
> [17:59:33,757][INFO ][test-runner][root] >>> After second put.
> [17:59:33,766][INFO ][main][root] >>> Stopping test: testPutAllPutAll in 240
> ms <<<
> [17:59:33,766][INFO ][main][root] Checking grid: 0
> [17:59:33,787][INFO ][main][root] Size after [idx=0, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=CacheLocalEntries
> []]
> [17:59:33,787][INFO ][main][root] Checking grid: 1
> [17:59:33,812][INFO ][main][root] Size after [idx=1, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=[]]
> [17:59:33,815][INFO ][main][root] Checking grid: 2
> [17:59:33,839][INFO ][main][root] Size after [idx=2, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=[]]
> [17:59:33,842][INFO ][main][root] Checking grid: 3
> [17:59:33,866][INFO ][main][root] Size after [idx=3, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=[]]
> --- Stderr: ---
> [17:59:33,765][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<64> but was:<8>
>
[jira] [Updated] (IGNITE-1112) Atomic cache #get method returns old value if near cache enabled after second putAll.
[
https://issues.apache.org/jira/browse/IGNITE-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-1112:
---
Labels: MakeTeamcityGreenAgain (was: )
> Atomic cache #get method returns old value if near cache enabled after second
> putAll.
> -
>
> Key: IGNITE-1112
> URL: https://issues.apache.org/jira/browse/IGNITE-1112
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Andrey Gura
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> These tests failed:
> GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest.testPutAllPutAll
> GridCacheAtomicNearEnabledFairAffinityMultiJvmFullApiSelfTest.testPutAllPutAll
>
> These tests work fine in one jvm, but fails in multi-JVM case.
> Looks like, second putAll does not update data at near cache and get method
> returns old value. But iteration from cache return actual data.
> See ignite-648-putAll branch with more debug information.
> Original log for
> GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest.testPutAllPutAll.
> {noformat}
> junit.framework.AssertionFailedError: expected:<64> but was:<8>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:86)
> at junit.framework.TestCase.assertEquals(TestCase.java:253)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedMultiNodeFullApiSelfTest.testPutAllPutAll(GridCachePartitionedMultiNodeFullApiSelfTest.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1618)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1561)
> --- Stdout: ---
> [17:59:33,524][INFO ][main][root] >>> Starting test: testPutAllPutAll <<<
> [17:59:33,527][INFO ][test-runner][root] > Grid0:
> 00ac324c-cfd0-4433-b00b-1048858b6000
> [17:59:33,528][INFO ][test-runner][root] > Grid1:
> 0a0c6919-127f-4d44-988d-8a236d033379
> [17:59:33,530][INFO ][test-runner][root] > Grid2:
> 17e5a787-5b00-4c68-88ea-cf0e393fefd1
> [17:59:33,531][INFO ][test-runner][root] > Grid3:
> d63de793-e754-4849-826e-2f43669385ba
> [17:59:33,544][INFO ][Thread-110][jvm-0a0c6919]
> [17:59:33,544][INFO][ignite-#12%pub-multijvm.GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest1%][GridDeploymentLocalStore]
> Class locally deployed: class
> org.apache.ignite.testframework.junits.multijvm.IgniteCacheProcessProxy$10
> [17:59:33,736][INFO ][test-runner][root] >>> Before second put.
> [17:59:33,736][INFO ][test-runner][GridDeploymentLocalStore] Class locally
> deployed: class
> org.apache.ignite.testframework.junits.multijvm.IgniteCacheProcessProxy$17
> [17:59:33,741][INFO ][Thread-110][jvm-0a0c6919]
> [17:59:33,741][INFO][ignite-#16%pub-multijvm.GridCacheAtomicNearEnabledMultiJvmFullApiSelfTest1%][GridDeploymentLocalStore]
> Class locally deployed: class
> org.apache.ignite.testframework.junits.multijvm.IgniteCacheProcessProxy$17
> [17:59:33,757][INFO ][test-runner][root] >>> After second put.
> [17:59:33,766][INFO ][main][root] >>> Stopping test: testPutAllPutAll in 240
> ms <<<
> [17:59:33,766][INFO ][main][root] Checking grid: 0
> [17:59:33,787][INFO ][main][root] Size after [idx=0, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=CacheLocalEntries
> []]
> [17:59:33,787][INFO ][main][root] Checking grid: 1
> [17:59:33,812][INFO ][main][root] Size after [idx=1, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=[]]
> [17:59:33,815][INFO ][main][root] Checking grid: 2
> [17:59:33,839][INFO ][main][root] Size after [idx=2, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=[]]
> [17:59:33,842][INFO ][main][root] Checking grid: 3
> [17:59:33,866][INFO ][main][root] Size after [idx=3, size=0, keySize=0,
> primarySize=0, globalSize=0, globalPrimarySize=0, entrySet=[]]
> --- Stderr: ---
> [17:59:33,765][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<64> but was:<8>
> at
[jira] [Created] (IGNITE-10725) Push Initial Commit to repository
Ilya Kasnacheev created IGNITE-10725: Summary: Push Initial Commit to repository Key: IGNITE-10725 URL: https://issues.apache.org/jira/browse/IGNITE-10725 Project: Ignite Issue Type: Sub-task Reporter: Ilya Kasnacheev Assignee: Alexey Goncharuk Unfortunately, empty repository cannot be forked or offered pull requests. Therefore there is a need of direct push of commit 4b30c1a2cff4ee4a615bc0940327035705198cbc to repository https://gitbox.apache.org/repos/asf?p=ignite-abbrev-plugin.git as 'master' Source code licenses are not proper in this commit, but it will be fixed in following commits. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10724) Publish Abbreviation Plugin source to supplimentary repo
Ilya Kasnacheev created IGNITE-10724: Summary: Publish Abbreviation Plugin source to supplimentary repo Key: IGNITE-10724 URL: https://issues.apache.org/jira/browse/IGNITE-10724 Project: Ignite Issue Type: New Feature Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev A repository was created, now we need everyone who worked on abbrev plugin to offer pull requests to their code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[ https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723301#comment-16723301 ] Pavel Kuznetsov commented on IGNITE-10645: -- SQL test run https://ci.ignite.apache.org/viewQueued.html?itemId=2577098 > SQL properties ownership flag should be set at configuration parsing, not > query execution. > -- > > Key: IGNITE-10645 > URL: https://issues.apache.org/jira/browse/IGNITE-10645 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > At processing time, query entities are transformed and validated, table > descriptors with properties are created. > Now in some case (thre's no keyFields and key is of complex non-sql type), > ownership flag of query property is calculated at execution time (for example > at first put()): > https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132 > So we can't access metadata, that uses this not-yet-initialized field before > we put the data. > But we already have all necessary info to set this field at processing time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10723) Investigate failures related to enabling tests (IGNITE-1094)
[ https://issues.apache.org/jira/browse/IGNITE-10723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-10723: - Ignite Flags: (was: Docs Required) > Investigate failures related to enabling tests (IGNITE-1094) > > > Key: IGNITE-10723 > URL: https://issues.apache.org/jira/browse/IGNITE-10723 > Project: Ignite > Issue Type: Test >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > > The following tests were muted due to IGNITE-1094: > * IgniteChangeGlobalStateTest.testActivateAfterFailGetLock > * CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration > (Hibernate-4.2) > * CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration > (Hibernate-5.1) > * IgniteSqlSchemaIndexingTest.testCaseSensitive > * IgniteSqlSchemaIndexingTest.testCustomSchemaMultipleCachesTablesCollision > * GridPartitionedCacheJtaLookupClassNameSelfTest.testIncompatibleTmLookup > * CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration > * CacheJdbcPojoStoreFactorySelfTest.testIncorrectBeanConfiguration > These test should be analyzed and enabled on the TC if possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10723) Investigate failures related to enabling tests (IGNITE-1094)
Vyacheslav Koptilin created IGNITE-10723: Summary: Investigate failures related to enabling tests (IGNITE-1094) Key: IGNITE-10723 URL: https://issues.apache.org/jira/browse/IGNITE-10723 Project: Ignite Issue Type: Test Affects Versions: 2.7 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin The following tests were muted due to IGNITE-1094: * IgniteChangeGlobalStateTest.testActivateAfterFailGetLock * CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (Hibernate-4.2) * CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (Hibernate-5.1) * IgniteSqlSchemaIndexingTest.testCaseSensitive * IgniteSqlSchemaIndexingTest.testCustomSchemaMultipleCachesTablesCollision * GridPartitionedCacheJtaLookupClassNameSelfTest.testIncompatibleTmLookup * CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration * CacheJdbcPojoStoreFactorySelfTest.testIncorrectBeanConfiguration These test should be analyzed and enabled on the TC if possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10708) SQL implement system view for partition states
[ https://issues.apache.org/jira/browse/IGNITE-10708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723257#comment-16723257 ] Aleksey Plekhanov commented on IGNITE-10708: [~vozerov], please review the patch > SQL implement system view for partition states > -- > > Key: IGNITE-10708 > URL: https://issues.apache.org/jira/browse/IGNITE-10708 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13 > Fix For: 2.8 > > > Implement SQL system view to partition states in the cluster for each cache > group and each node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10708) SQL implement system view for partition states
[ https://issues.apache.org/jira/browse/IGNITE-10708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723166#comment-16723166 ] Dmitriy Pavlov commented on IGNITE-10708: - [~alex_pl] could you please mention any potential reviewer directly in comments? > SQL implement system view for partition states > -- > > Key: IGNITE-10708 > URL: https://issues.apache.org/jira/browse/IGNITE-10708 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13 > Fix For: 2.8 > > > Implement SQL system view to partition states in the cluster for each cache > group and each node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10709) New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on TC configuration
[
https://issues.apache.org/jira/browse/IGNITE-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-10709:
Fix Version/s: 2.8
> New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on
> TC configuration
> --
>
> Key: IGNITE-10709
> URL: https://issues.apache.org/jira/browse/IGNITE-10709
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> IntelliJ IDEA since 2018.1 version has new inspection rules enabled by
> default. This leads to the {{[Inspections] Core}} suite fail as these rules
> are not fixed in the Apache Ignite project code.
> # We need to add and disable them in {{ignite_inspections_teamcity.xml}}
> configuration file.
> # Remove unnecessary suppression according to {{Redundant suppression}} rule
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10722) Abbr-plugin: refactoring inside write action error
Ivan Pavlukhin created IGNITE-10722:
---
Summary: Abbr-plugin: refactoring inside write action error
Key: IGNITE-10722
URL: https://issues.apache.org/jira/browse/IGNITE-10722
Project: Ignite
Issue Type: Bug
Reporter: Ivan Pavlukhin
Abbreviation plugin reports error to IDEA log when applying abbreviate
intention. It claims that deadlock is possible.
{code}
2018-12-17 13:35:10,849 [ 21351] ERROR -
oring.BaseRefactoringProcessor - Refactorings should not be started
inside write action
because they start progress inside and any read action from the
progress task would cause the deadlock
java.lang.Exception
at
com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560)
at com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73)
at
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163)
at
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148)
at
org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121)
at
com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75)
at
com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173)
at
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202)
at com.intellij.openapi.application.WriteAction.run(WriteAction.java:105)
at
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204)
at
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179)
at
com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88)
at
com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153)
at
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178)
at
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139)
at
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97)
at
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87)
at
com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73)
at
com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177)
at
com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118)
at
com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195)
at
com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417)
at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097)
at
com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183)
at
com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132)
at
com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190)
at
com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58)
at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411)
at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160)
at com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307)
at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48)
at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44)
at
com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:138)
at
com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:107)
at
com.intellij.openapi.util.objectTree.ObjectTree.executeActionWithRecursiveGuard(ObjectTree.java:182)
at
com.intellij.openapi.util.objectTree.ObjectNode.execute(ObjectNode.java:107)
at
com.intellij.openapi.util.objectTree.ObjectTree.executeAll(ObjectTree.java:151)
at com.intellij.openapi.util.Disposer.dispose(Disposer.java:129)
at com.intellij.openapi.util.Disposer.dispose(Disposer.java:125)
at com.intellij.ui.popup.WizardPopup.disposeAllParents(WizardPopup.java:263)
at
com.intellij.ui.popup.list.ListPopupImpl.handleNextStep(ListPopupImpl.java:442)
at
com.intellij.ui.popup.list.ListPopupImpl._handleSelect(ListPopupImpl.java:396)
at
[jira] [Commented] (IGNITE-10493) Refactor exchange stages time measurements
[
https://issues.apache.org/jira/browse/IGNITE-10493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723137#comment-16723137
]
ASF GitHub Bot commented on IGNITE-10493:
-
GitHub user Jokser opened a pull request:
https://github.com/apache/ignite/pull/5688
IGNITE-10493 Refactor exchange timings
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10493
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5688.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5688
commit 11bab06240ca9dae34d1b108f45f374feae08348
Author: Pavel Kovalenko
Date: 2018-12-03T18:18:16Z
IGNITE-10493 WIP
Signed-off-by: Pavel Kovalenko
commit f9bf25cea24fbc40fe0cb5b7326a485b2afbfee0
Author: Pavel Kovalenko
Date: 2018-12-12T10:10:59Z
IGNITE-10493 WIP
Signed-off-by: Pavel Kovalenko
commit a3ad16f63b2b11ccb829b1468339a759a776a21e
Author: Pavel Kovalenko
Date: 2018-12-17T16:36:53Z
IGNITE-10493 Refactor exchange timings.
Signed-off-by: Pavel Kovalenko
> Refactor exchange stages time measurements
> --
>
> Key: IGNITE-10493
> URL: https://issues.apache.org/jira/browse/IGNITE-10493
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.7
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
>
> At the current implementation, we don't cover and measure all possible code
> executions that influence on PME time. Instead of it we just measure the
> hottest separate parts with the following hardcoded pattern:
> {noformat}
> long time = currentTime();
> ... // some code block
> print ("Stage name performed in " + (currentTime() - time));
> {noformat}
> This approach can be improved. Instead of declaring time variable and print
> the message to log immediately we can introduce a utility class (TimesBag)
> that will hold all stages and their times. The content of TimesBag can be
> printed when the exchange future is done.
> As exchange is a linear process that executes init stage by exchange-worker
> and finish stage by one of the sys thread we can easily cover all exchange
> code base by time cutoffs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7985) Integration JetBrains IntelliJ IDEA code inspections as TC build
[ https://issues.apache.org/jira/browse/IGNITE-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7985: Labels: inspections (was: ) > Integration JetBrains IntelliJ IDEA code inspections as TC build > > > Key: IGNITE-7985 > URL: https://issues.apache.org/jira/browse/IGNITE-7985 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Labels: inspections > Attachments: ignite_inspections.xml > > > https://confluence.jetbrains.com/display/TCD10/Inspections -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10682) Disable unnecessary loaded plugins for the Inspection test suite
[
https://issues.apache.org/jira/browse/IGNITE-10682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723135#comment-16723135
]
ASF GitHub Bot commented on IGNITE-10682:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5666
> Disable unnecessary loaded plugins for the Inspection test suite
>
>
> Key: IGNITE-10682
> URL: https://issues.apache.org/jira/browse/IGNITE-10682
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> As part of discussion [1] we've faced with the problem: the set of
> unnecessary plugins are loaded during the Inspection test suite run. This
> leads to unnecessary checking inspection rules which are not used in the
> Apache Ignite project and wasting agent CPU resources.
> The log can be found at [2] execution suite results.
> {code}
> > 46 plugins initialized in 1031 ms
> > 2018-12-13 10:55:24,875 [ 1342] INFO - llij.ide.plugins.PluginManager -
> > Loaded bundled plugins: Android Support (10.2.3), Ant Support (1.0), CSS
> > Support (172.4574.11), Database Tools and SQL (172.4574.11), Eclipse
> > Integration (3.0), FreeMarker support (1.0), GWT Support (1.0), Gradle
> > (172.4574.11), Groovy (9.0), Guice (8.0), HTML Tools (2.0), Hibernate
> > Support (1.0), I18n for Java (172.4574.11),
> > IntelliLang (8.0), JBoss Seam Support (1.0), JUnit (1.0), Java EE: Bean
> > Validation Support (1.1), Java EE: Contexts and Dependency Injection (1.1),
> > Java EE: EJB, JPA, Servlets (1.0), Java EE: Java Server Faces (2.2.X.),
> > Java EE: Web Services (JAX-WS) (1.9), Java Server Pages (JSP) Integration
> > (1.0), JavaScript Support (1.0), Kotlin (1.1.4-release-IJ2017.2-3), Maven
> > Integration (172.4574.11), Persistence Frameworks Support (1.0), Plugin
> > DevKit (1.0), Properties Support (172.4574.11), QuirksMode (172.4574.11),
> > Spring AOP/@AspectJ (1.0), Spring Batch (1.0), Spring Data (1.0), Spring
> > Integration Patterns (1.0), Spring Security (1.0), Spring Support (1.0),
> > Spring Web Flow (1.0), Spring Web Services (1.0), Struts 1.x (2.0), Struts
> > 2 (1.0), TestNG-J (8.0), UI Designer (172.4574.11), Velocity support (1.0),
> > W3C Validators (2.0), WebLogic Integration (1.0), XPathView + XSLT Support
> > (4)
> {code}
> We need to disable these loaded plugins as they don't need for checking core
> inspection rules.
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p39471.html
> [2]
> https://ci.ignite.apache.org/viewLog.html?buildId=2538111=IgniteTests24Java8_ExcludedInspections2=artifacts
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8281) Add Docker image build for Apache Ignite Release
[ https://issues.apache.org/jira/browse/IGNITE-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-8281. -- Resolution: Duplicate > Add Docker image build for Apache Ignite Release > > > Key: IGNITE-8281 > URL: https://issues.apache.org/jira/browse/IGNITE-8281 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Similar to Apache Ignite Nightly Release, add Docker images (Apache Ignite > and WebConsole) build to Apache Ignite Release build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8281) Add Docker image build for Apache Ignite Release
[ https://issues.apache.org/jira/browse/IGNITE-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-8281. > Add Docker image build for Apache Ignite Release > > > Key: IGNITE-8281 > URL: https://issues.apache.org/jira/browse/IGNITE-8281 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Similar to Apache Ignite Nightly Release, add Docker images (Apache Ignite > and WebConsole) build to Apache Ignite Release build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7621) Review current builds on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-7621: - Description: There is a little under 600 builds currently configured on teamcity. It is required to review each of them and: * (/) revise and clean obsolete build plans * (/) revise and clean duplicated VCS roots * (/) revise and reconfigure corresponding triggers * (-) revise and strict build configuration access permissions * (-) document everything was: There is a little under 600 builds currently configured on teamcity. It is required to review each of them and: * (/) revise and clean obsolete build plans * (/) revise and clean duplicated VCS roots * (/) revise and reconfigure corresponding triggers * revise and strict build configuration access permissions * document everything > Review current builds on TeamCity > - > > Key: IGNITE-7621 > URL: https://issues.apache.org/jira/browse/IGNITE-7621 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > There is a little under 600 builds currently configured on teamcity. It is > required to review each of them and: > * (/) revise and clean obsolete build plans > * (/) revise and clean duplicated VCS roots > * (/) revise and reconfigure corresponding triggers > * (-) revise and strict build configuration access permissions > * (-) document everything -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7621) Review current builds on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-7621. -- Resolution: Done > Review current builds on TeamCity > - > > Key: IGNITE-7621 > URL: https://issues.apache.org/jira/browse/IGNITE-7621 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > There is a little under 600 builds currently configured on teamcity. It is > required to review each of them and: > * (/) revise and clean obsolete build plans > * (/) revise and clean duplicated VCS roots > * (/) revise and reconfigure corresponding triggers > * (-) revise and strict build configuration access permissions > * (-) document everything -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7985) Integration JetBrains IntelliJ IDEA code inspections as TC build
[ https://issues.apache.org/jira/browse/IGNITE-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-7985. -- Resolution: Invalid Inspections are introduced and maintained by [~Mmuzaf] > Integration JetBrains IntelliJ IDEA code inspections as TC build > > > Key: IGNITE-7985 > URL: https://issues.apache.org/jira/browse/IGNITE-7985 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Attachments: ignite_inspections.xml > > > https://confluence.jetbrains.com/display/TCD10/Inspections -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7985) Integration JetBrains IntelliJ IDEA code inspections as TC build
[ https://issues.apache.org/jira/browse/IGNITE-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-7985. > Integration JetBrains IntelliJ IDEA code inspections as TC build > > > Key: IGNITE-7985 > URL: https://issues.apache.org/jira/browse/IGNITE-7985 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Attachments: ignite_inspections.xml > > > https://confluence.jetbrains.com/display/TCD10/Inspections -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10279) Control.sh utility unify options naming format
[
https://issues.apache.org/jira/browse/IGNITE-10279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723126#comment-16723126
]
Ignite TC Bot commented on IGNITE-10279:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2574618]]
* IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingTest.testBrokenCacheDataTreeShouldFailValidation -
0,0% fails in last 351 master runs.
* IgniteCacheTestSuite7:
IgniteCacheStartWithLoadTest.testNoRebalanceDuringCacheStart - 0,0% fails in
last 351 master runs.
{color:#d04437}Platform .NET (Inspections){color} [[tests 0
BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2574625]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2573091buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh utility unify options naming format
> --
>
> Key: IGNITE-10279
> URL: https://issues.apache.org/jira/browse/IGNITE-10279
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Now we have options in several styles:
> {noformat}
> --ping-interval
> {noformat}
> {noformat}
> --skipZeros
> {noformat}
> I think, we must unify options naming format and we should use linux like
> format, i.e. {{--word1-word2}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10691) thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or C++ client
[
https://issues.apache.org/jira/browse/IGNITE-10691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-10691:
Assignee: (was: Igor Sapego)
> thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or
> C++ client
> -
>
> Key: IGNITE-10691
> URL: https://issues.apache.org/jira/browse/IGNITE-10691
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Priority: Major
> Fix For: 2.8
>
>
> Trying to put uuid with PY or PHP or NodeJS client and get from Java or C++
> client have different results
> Python put
> {code}
> cache = client.get_or_create_cache("UUID_PY")
> cache.put(1, UUID("d597be47-949e-475b-8918-44ca836798a3"),
> key_hint=IntObject, value_hint=UUIDObject)
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PY");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> 5b479e94-47be-97d5-a398-6783ca441889
> {code}
> Same for C++ thin client
> And they looks like mixed up in a different order
> Python: {code}d597be47-949e-475b-8918-44ca836798a3{code}
> Java: {code}5b479e94-47be-97d5-a398-6783ca441889{code}
> For example take "ca" in 7-8 number from the end of java uuid
> On left we have "83", but in python "83" stay on right side from "ca"
> Different for "44" which is on right for Java but on left for Python
> NodeJS put
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_JS"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> key = 1;
> value = [95,190,238,78,178,166,68,220,153,172,100,68,215,254,125,246];
> await cache.put(key, value);
> {code}
> Py get
> {code}
> cache = client.get_or_create_cache("UUID_JS")
> result = cache.get(1, key_hint=IntObject)
> print(result)
> {code}
> Py output
> {code}
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_JS");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc44a6b2-4eee-be5f-f67d-fed74464ac99
> {code}
> PHP put
> [238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205] =
> "ee0f2fed-e07a-42dc-aa59-7f8fc7380acd"
> {code}
> $cache =
> $client->getOrCreateCache("UUID_PH")->setKeyType(ObjectType::INTEGER)->setValueType(ObjectType::UUID);
> $cache->put(1,[238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205]);
> {code}
> JS get
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_PH"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> result = (await cache.get(1));
> {code}
> JS output
> {code}
> 238 15 47 237 224 122 66 220 170 89 127 143 199 56 10 205
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PH");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc427ae0-ed2f-0fee-cd0a-38c78f7f59aa
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7621) Review current builds on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-7621: - Description: There is a little under 600 builds currently configured on teamcity. It is required to review each of them and: * (/) revise and clean obsolete build plans * (/) revise and clean duplicated VCS roots * revise and reconfigure corresponding triggers * revise and strict build configuration access permissions * document everything was: There is a little under 600 builds currently configured on teamcity. It is required to review each of them and: * (/) revise and clean obsolete build plans * revise and clean duplicated VCS roots * revise and reconfigure corresponding triggers * revise and strict build configuration access permissions * document everything > Review current builds on TeamCity > - > > Key: IGNITE-7621 > URL: https://issues.apache.org/jira/browse/IGNITE-7621 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > There is a little under 600 builds currently configured on teamcity. It is > required to review each of them and: > * (/) revise and clean obsolete build plans > * (/) revise and clean duplicated VCS roots > * revise and reconfigure corresponding triggers > * revise and strict build configuration access permissions > * document everything -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10721) Documentation: Fix UUID thin client format description
Igor Sapego created IGNITE-10721: Summary: Documentation: Fix UUID thin client format description Key: IGNITE-10721 URL: https://issues.apache.org/jira/browse/IGNITE-10721 Project: Ignite Issue Type: Task Components: documentation, thin client Reporter: Igor Sapego Fix For: 2.8 UUID thin client format description [1] need to be fixed. The actual format of the UUID should be two longs, not a single 128-bit value. Two longs written in little-endian are not equal to one 128-bit number. [1] - https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-uuid-guid- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7671) Fix '.gitignore files are tracked' error
[
https://issues.apache.org/jira/browse/IGNITE-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov updated IGNITE-7671:
-
Fix Version/s: 2.8
> Fix '.gitignore files are tracked' error
>
>
> Key: IGNITE-7671
> URL: https://issues.apache.org/jira/browse/IGNITE-7671
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.8
>
>
> Current {{.gitignore}} has definitions of files to ignore, which are already
> under the version control system (some *.sh scripts for example). It needs to
> be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7621) Review current builds on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-7621: - Description: There is a little under 600 builds currently configured on teamcity. It is required to review each of them and: * (/) revise and clean obsolete build plans * (/) revise and clean duplicated VCS roots * (/) revise and reconfigure corresponding triggers * revise and strict build configuration access permissions * document everything was: There is a little under 600 builds currently configured on teamcity. It is required to review each of them and: * (/) revise and clean obsolete build plans * (/) revise and clean duplicated VCS roots * revise and reconfigure corresponding triggers * revise and strict build configuration access permissions * document everything > Review current builds on TeamCity > - > > Key: IGNITE-7621 > URL: https://issues.apache.org/jira/browse/IGNITE-7621 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > There is a little under 600 builds currently configured on teamcity. It is > required to review each of them and: > * (/) revise and clean obsolete build plans > * (/) revise and clean duplicated VCS roots > * (/) revise and reconfigure corresponding triggers > * revise and strict build configuration access permissions > * document everything -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7621) Review current builds on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-7621. > Review current builds on TeamCity > - > > Key: IGNITE-7621 > URL: https://issues.apache.org/jira/browse/IGNITE-7621 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > There is a little under 600 builds currently configured on teamcity. It is > required to review each of them and: > * (/) revise and clean obsolete build plans > * (/) revise and clean duplicated VCS roots > * (/) revise and reconfigure corresponding triggers > * (-) revise and strict build configuration access permissions > * (-) document everything -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7234) Optimize TC suites
[ https://issues.apache.org/jira/browse/IGNITE-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-7234. -- Resolution: Invalid All corresponding activities are now run by community members. > Optimize TC suites > -- > > Key: IGNITE-7234 > URL: https://issues.apache.org/jira/browse/IGNITE-7234 > Project: Ignite > Issue Type: Task > Components: build >Affects Versions: 2.3 >Reporter: Sergey Kozlov >Assignee: Peter Ivanov >Priority: Major > > The current organization of test suites on CI servers looks like inefficient. > We've 90+ test suites and the number of tests is permanently growing. > The plan of optimization might look following: > # Analyze and join short executed suites into single(s) suite > # Analyze execution time of suites (tests) to check ability to split tests > into regular and long running suites (e.g. Basic and Basic Long, Cache and > Cache Long, etc) > # Check the approach to compile binaries at once and the run tests against > them > # Make the report of distribution of time-execution of tests, for instance: > 0-10%: X tests > 11-20%: Y tests > ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10709) New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on TC configuration
[
https://issues.apache.org/jira/browse/IGNITE-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10709:
-
Ignite Flags: (was: Docs Required)
> New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on
> TC configuration
> --
>
> Key: IGNITE-10709
> URL: https://issues.apache.org/jira/browse/IGNITE-10709
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
>
> IntelliJ IDEA since 2018.1 version has new inspection rules enabled by
> default. This leads to the {{[Inspections] Core}} suite fail as these rules
> are not fixed in the Apache Ignite project code.
> # We need to add and disable them in {{ignite_inspections_teamcity.xml}}
> configuration file.
> # Remove unnecessary suppression according to {{Redundant suppression}} rule
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9774) CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan hangs
[
https://issues.apache.org/jira/browse/IGNITE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-9774:
--
Assignee: Roman Kondakov
> CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs
> ---
>
> Key: IGNITE-9774
> URL: https://issues.apache.org/jira/browse/IGNITE-9774
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Roman Kondakov
>Priority: Major
> Labels: Hanging
>
> Test
> {{CacheMvccTransactionsTest#testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs}} and can freeze a whole suite. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9774) CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan hangs
[
https://issues.apache.org/jira/browse/IGNITE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723116#comment-16723116
]
ASF GitHub Bot commented on IGNITE-9774:
GitHub user rkondakov opened a pull request:
https://github.com/apache/ignite/pull/5687
IGNITE-9774: Test remuted with a proper ticket.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9774
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5687.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5687
commit 6681d4e8f92488f5b1e4e39887f7fec0d94e93e5
Author: rkondakov
Date: 2018-12-17T16:08:23Z
IGNITE-9774: Test remuted with a proper ticket.
> CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs
> ---
>
> Key: IGNITE-9774
> URL: https://issues.apache.org/jira/browse/IGNITE-9774
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
> Labels: Hanging
>
> Test
> {{CacheMvccTransactionsTest#testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs}} and can freeze a whole suite. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10572) MVCC TX: Possible race on invokeAll operations
[
https://issues.apache.org/jira/browse/IGNITE-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723110#comment-16723110
]
Ignite TC Bot commented on IGNITE-10572:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2573268]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - 0,0% fails in last
352 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2573297buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: Possible race on invokeAll operations
> --
>
> Key: IGNITE-10572
> URL: https://issues.apache.org/jira/browse/IGNITE-10572
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Igor Seliverstov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
>
> see {{GridNearTxEnlistFuture#checkResponse}} method.
> 1) race on result creation - two threads may see {{this.res == null}} and
> just set their values, result is partially lost
> 2) race on success flag set - just set false flag may be overwritten by
> concurrent successful response checking operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-8543) Node.js tests count with debug on/off differs
[ https://issues.apache.org/jira/browse/IGNITE-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov closed IGNITE-8543. > Node.js tests count with debug on/off differs > - > > Key: IGNITE-8543 > URL: https://issues.apache.org/jira/browse/IGNITE-8543 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Running Node,js thin client tests with debug turned on / off results in > different total test count > ([64|https://ci.ignite.apache.org/viewLog.html?buildId=1316067=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs] > and > [99|https://ci.ignite.apache.org/viewLog.html?buildId=1316268=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs] > respectively. Thats not predicted behaviour and require investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8543) Node.js tests count with debug on/off differs
[ https://issues.apache.org/jira/browse/IGNITE-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-8543. -- Resolution: Not A Problem Problem is already solved. > Node.js tests count with debug on/off differs > - > > Key: IGNITE-8543 > URL: https://issues.apache.org/jira/browse/IGNITE-8543 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > > Running Node,js thin client tests with debug turned on / off results in > different total test count > ([64|https://ci.ignite.apache.org/viewLog.html?buildId=1316067=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs] > and > [99|https://ci.ignite.apache.org/viewLog.html?buildId=1316268=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs] > respectively. Thats not predicted behaviour and require investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9866) Unify and optimise *.sh and *.bat code base
[ https://issues.apache.org/jira/browse/IGNITE-9866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-9866: Assignee: Ilya Murchenko (was: Peter Ivanov) > Unify and optimise *.sh and *.bat code base > --- > > Key: IGNITE-9866 > URL: https://issues.apache.org/jira/browse/IGNITE-9866 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.8 > > > There are lots of duplicated code at /bin/*.[sh|bat] scripts (especially -- > Java run string construction). It is required to move duplicated code to > common function script. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10238) Intermittent Client Nodes suite hang
[
https://issues.apache.org/jira/browse/IGNITE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723096#comment-16723096
]
Sergey Chugunov commented on IGNITE-10238:
--
[~NSAmelchev],
I used test from your PR as it reproduces deadlock easily and I found the
problem.
We already have a code in _CacheObjectBinaryProcessorImpl::metadata_ that
allows to read metadata right away if it is requested from discovery thread
(take a look at line 639 in your PR).
But for some reason it doesn't work although I know it was fixed at some moment.
Could you please take a look and sort out why it is broken again and how to fix
it?
> Intermittent Client Nodes suite hang
>
>
> Key: IGNITE-10238
> URL: https://issues.apache.org/jira/browse/IGNITE-10238
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Amelchev Nikita
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> There are occasional hangs of Client Nodes suite in master. A quick peek at
> the thread dumps reveals an interesting deadlock (only relevant parts of the
> thread dump are left):
> {code}
> "disco-notifier-worker-#634%internal.IgniteClientReconnectApiExceptionTest0%"
> #791 prio=5 os_prio=0 tid=0x7f990c12d800 nid=0x11b9 waiting on condition
> [0x7f991a0eb000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:656)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:206)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1293)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2007)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:101)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10131)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10160)
> at
> org.apache.ignite.internal.GridEventConsumeHandler.p2pUnmarshal(GridEventConsumeHandler.java:390)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1362)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:111)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:203)
> at
>
[jira] [Updated] (IGNITE-10675) Refactor Release Candidate check build
[ https://issues.apache.org/jira/browse/IGNITE-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-10675: -- Fix Version/s: 2.8 > Refactor Release Candidate check build > -- > > Key: IGNITE-10675 > URL: https://issues.apache.org/jira/browse/IGNITE-10675 > Project: Ignite > Issue Type: Sub-task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.8 > > > # Revise build, ASC, SHA512, etc. steps. > # Add check for tasks in Jira: all tasks for current RC should be resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10682) Disable unnecessary loaded plugins for the Inspection test suite
[
https://issues.apache.org/jira/browse/IGNITE-10682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723103#comment-16723103
]
Maxim Muzafarov commented on IGNITE-10682:
--
Andrew,
Thank you too for testing.
[~dpavlov]
Can you assist with this PR?
> Disable unnecessary loaded plugins for the Inspection test suite
>
>
> Key: IGNITE-10682
> URL: https://issues.apache.org/jira/browse/IGNITE-10682
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> As part of discussion [1] we've faced with the problem: the set of
> unnecessary plugins are loaded during the Inspection test suite run. This
> leads to unnecessary checking inspection rules which are not used in the
> Apache Ignite project and wasting agent CPU resources.
> The log can be found at [2] execution suite results.
> {code}
> > 46 plugins initialized in 1031 ms
> > 2018-12-13 10:55:24,875 [ 1342] INFO - llij.ide.plugins.PluginManager -
> > Loaded bundled plugins: Android Support (10.2.3), Ant Support (1.0), CSS
> > Support (172.4574.11), Database Tools and SQL (172.4574.11), Eclipse
> > Integration (3.0), FreeMarker support (1.0), GWT Support (1.0), Gradle
> > (172.4574.11), Groovy (9.0), Guice (8.0), HTML Tools (2.0), Hibernate
> > Support (1.0), I18n for Java (172.4574.11),
> > IntelliLang (8.0), JBoss Seam Support (1.0), JUnit (1.0), Java EE: Bean
> > Validation Support (1.1), Java EE: Contexts and Dependency Injection (1.1),
> > Java EE: EJB, JPA, Servlets (1.0), Java EE: Java Server Faces (2.2.X.),
> > Java EE: Web Services (JAX-WS) (1.9), Java Server Pages (JSP) Integration
> > (1.0), JavaScript Support (1.0), Kotlin (1.1.4-release-IJ2017.2-3), Maven
> > Integration (172.4574.11), Persistence Frameworks Support (1.0), Plugin
> > DevKit (1.0), Properties Support (172.4574.11), QuirksMode (172.4574.11),
> > Spring AOP/@AspectJ (1.0), Spring Batch (1.0), Spring Data (1.0), Spring
> > Integration Patterns (1.0), Spring Security (1.0), Spring Support (1.0),
> > Spring Web Flow (1.0), Spring Web Services (1.0), Struts 1.x (2.0), Struts
> > 2 (1.0), TestNG-J (8.0), UI Designer (172.4574.11), Velocity support (1.0),
> > W3C Validators (2.0), WebLogic Integration (1.0), XPathView + XSLT Support
> > (4)
> {code}
> We need to disable these loaded plugins as they don't need for checking core
> inspection rules.
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p39471.html
> [2]
> https://ci.ignite.apache.org/viewLog.html?buildId=2538111=IgniteTests24Java8_ExcludedInspections2=artifacts
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10720) Decrease time to save metadata during checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-10720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723101#comment-16723101 ] ASF GitHub Bot commented on IGNITE-10720: - GitHub user akalash opened a pull request: https://github.com/apache/ignite/pull/5686 IGNITE-10720 Moved save metadata during checkpoint from under write lock You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10720 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5686.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5686 commit 873fb21331e56bdc3065cff453d15e0d2f490a3c Author: Anton Kalashnikov Date: 2018-12-17T15:52:14Z IGNITE-10720 Moved save metadata during checkpoint from under write lock > Decrease time to save metadata during checkpoint > > > Key: IGNITE-10720 > URL: https://issues.apache.org/jira/browse/IGNITE-10720 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > > Looks like it's not neccessery save all metadata(like free list) under write > checkpoint lock because sometimes it's too long. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10720) Decrease time to save metadata during checkpoint
Anton Kalashnikov created IGNITE-10720: -- Summary: Decrease time to save metadata during checkpoint Key: IGNITE-10720 URL: https://issues.apache.org/jira/browse/IGNITE-10720 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Looks like it's not neccessery save all metadata(like free list) under write checkpoint lock because sometimes it's too long. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723091#comment-16723091
]
Vladimir Ozerov commented on IGNITE-10643:
--
One more run: https://ci.ignite.apache.org/viewQueued.html?itemId=2575787
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10584) MVCC: Wal delta record consistency test failed.
[
https://issues.apache.org/jira/browse/IGNITE-10584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723086#comment-16723086
]
Ignite TC Bot commented on IGNITE-10584:
{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=2548942buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Wal delta record consistency test failed.
> ---
>
> Key: IGNITE-10584
> URL: https://issues.apache.org/jira/browse/IGNITE-10584
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: WAL
> Fix For: 2.8
>
>
> Next PDS 1 suite tests are failed in Mvcc mode:
> CpTriggeredWalDeltaConsistencyTest.testPutRemoveCacheDestroy
> ExplicitWalDeltaConsistencyTest.testNotEmptyPds
> ExplicitWalDeltaConsistencyTest.testPutRemoveAfterCheckpoint
> SysPropWalDeltaConsistencyTest.testPutRemoveMultinode
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10314) Spark dataframe will get wrong schema if user executes add/drop column DDL
[
https://issues.apache.org/jira/browse/IGNITE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723088#comment-16723088
]
Ignite TC Bot commented on IGNITE-10314:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2574960]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2536034buildTypeId=IgniteTests24Java8_RunAll]
> Spark dataframe will get wrong schema if user executes add/drop column DDL
> --
>
> Key: IGNITE-10314
> URL: https://issues.apache.org/jira/browse/IGNITE-10314
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7
>Reporter: Ray
>Assignee: Ray
>Priority: Critical
> Fix For: 2.8
>
>
> When user performs add/remove column in DDL, Spark will get the old/wrong
> schema.
>
> Analyse
> Currently Spark data frame API relies on QueryEntity to construct schema, but
> QueryEntity in QuerySchema is a local copy of the original QueryEntity, so
> the original QueryEntity is not updated when modification happens.
>
> Solution
> Get the latest schema using JDBC thin driver's column metadata call, then
> update fields in QueryEntity.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723032#comment-16723032
]
Anton Vinogradov edited comment on IGNITE-8823 at 12/17/18 3:01 PM:
[~andrey-kuznetsov]
Fix looks incorrect.
I see that you just added
{{if (cacheCtx.config().getBackups() == 1)}}
before failing code when cache at test have 0 backups.
was (Author: avinogradov):
[~andrey-kuznetsov]
Fix looks incorrect.
I see thее you just added
{{if (cacheCtx.config().getBackups() == 1)}}
before failing code when cache at test have 0 backups.
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Ignite8823ReproducerTest.java
>
>
> Reproducable by test method {{testCreateConsistencyMultithreaded}} in
> {{IgfsPrimaryMultiNodeSelfTest}} and
> {{IgfsPrimaryRelaxedConsistencyMultiNodeSelfTest}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
>
[jira] [Commented] (IGNITE-10264) MVCC: Enlist request failure on backup can cause grid hanging.
[
https://issues.apache.org/jira/browse/IGNITE-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723084#comment-16723084
]
ASF GitHub Bot commented on IGNITE-10264:
-
GitHub user rkondakov opened a pull request:
https://github.com/apache/ignite/pull/5685
IGNITE-10264: Related tests unmuted.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10264
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5685.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5685
commit 9d25e34bfe9dc69e2efad1249f97c2937eb5cdff
Author: rkondakov
Date: 2018-12-17T15:32:51Z
Related tests unmuted.
> MVCC: Enlist request failure on backup can cause grid hanging.
> --
>
> Key: IGNITE-10264
> URL: https://issues.apache.org/jira/browse/IGNITE-10264
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Critical
> Labels: Hanging
>
> See stacktrace below, runtime ClusterTopologyException has not been catched
> and causes transaction hanging.
> Seems, we should throws some meaningful checked exception and thow it onto
> primary node.
> Reproducer is IgniteCacheIncrementTxTest running in Mvcc mode.
>
> {noformat}
> [2018-11-14
> 22:26:37,099][ERROR][sys-stripe-3-#10280%cache.IgniteCacheIncrementTxTest7%][GridCacheIoManager]
> Failed to process message [senderId=3774798b-3cbc-4ae1-95d1-745dd371,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxQueryFirstEnlistRequest]
> class org.apache.ignite.cluster.ClusterTopologyException: Can not reserve
> partition. Please retry on stable topology.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1865)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:274)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748){noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10719) [ML] LearningEnvironmentBuilder is not passed in makeBagged
[ https://issues.apache.org/jira/browse/IGNITE-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Malykh updated IGNITE-10719: -- Summary: [ML] LearningEnvironmentBuilder is not passed in makeBagged (was: [ML] LEarningEnvironmentBuilder is not passed in makeBagged) > [ML] LearningEnvironmentBuilder is not passed in makeBagged > --- > > Key: IGNITE-10719 > URL: https://issues.apache.org/jira/browse/IGNITE-10719 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > > During TrainerTrainsformers#makeBagged learning environment builder is not > passed from trainer which is made bagged -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10719) [ML] LearningEnvironmentBuilder is not passed in makeBagged
[ https://issues.apache.org/jira/browse/IGNITE-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723082#comment-16723082 ] ASF GitHub Bot commented on IGNITE-10719: - GitHub user artemmalykh opened a pull request: https://github.com/apache/ignite/pull/5684 IGNITE-10719: [ML] LearningEnvironmentBuilder is not passed in makeBagged You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10719 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5684.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5684 commit f2f5e1861411bf726b33a457f8db9dd0685db664 Author: Artem Malykh Date: 2018-12-17T15:31:33Z IGNITE-10719: Bug fix. > [ML] LearningEnvironmentBuilder is not passed in makeBagged > --- > > Key: IGNITE-10719 > URL: https://issues.apache.org/jira/browse/IGNITE-10719 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > > During TrainerTrainsformers#makeBagged learning environment builder is not > passed from trainer which is made bagged -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-845) TcpDiscoveryCloudIpFinderSelfTest.testAmazonWebServices always fails on public TC
[ https://issues.apache.org/jira/browse/IGNITE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723079#comment-16723079 ] Dmitriy Pavlov commented on IGNITE-845: --- Removed test from code here https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=commit;h=8cb502bc9da52aca39d4dc067a6b36a298c6b376 Feel free to add a test back if it will be covered by any open test-fix issue. > TcpDiscoveryCloudIpFinderSelfTest.testAmazonWebServices always fails on > public TC > - > > Key: IGNITE-845 > URL: https://issues.apache.org/jira/browse/IGNITE-845 > Project: Ignite > Issue Type: Bug >Affects Versions: sprint-4 >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > > AWS didn't authorize us when the amazon test is run on the public TC from > docker containers. Everything is fine on the private TC (configuration is > identical on both TCs). Noted that ignite-aws module's tests are also failing > on the public TC. Probably there is some docker + aws related issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10558) MVCC: IgniteWalReader test failed.
[
https://issues.apache.org/jira/browse/IGNITE-10558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723080#comment-16723080
]
Ignite TC Bot commented on IGNITE-10558:
{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=2549747buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: IgniteWalReader test failed.
> --
>
> Key: IGNITE-10558
> URL: https://issues.apache.org/jira/browse/IGNITE-10558
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
>
> Wal iterator doesn't handle Mvcc wal records.
> This causes IgniteWalReader tests failures in Mvcc Pds2 suite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10695) MVCC: Fix cache API conditional update operations.
[ https://issues.apache.org/jira/browse/IGNITE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10695: -- Description: Operation like putIfAbsent and replace now tries to transfer Predicate instance (filter) to remote node. # Predicates are transferred to remote node with each update. # Predicate should be transferred only for "replace" operation if certain entry provided, otherwise we should send a correct operation code and use corresponding static filter on remote side. # This change will break protocol compatibility. Should we bother about it? Let's fix protocol and add tests. was: Operation like putIfAbsent and replace now tries to transfer Predicate instance (filter) to remote node. # Almost all filters can't be serialized as they do not have assigned direct type. # Seems, we have no enough tests and we miss remote-call case for such operations. # Predicate should be transferred only for "replace" operation if certain entry provided, otherwise we should send a correct operation code and use corresponding static filter on remote side. # This change will break protocol compatibility. Should we bother about it? Let's fix protocol and add tests. > MVCC: Fix cache API conditional update operations. > -- > > Key: IGNITE-10695 > URL: https://issues.apache.org/jira/browse/IGNITE-10695 > Project: Ignite > Issue Type: Bug > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > Operation like putIfAbsent and replace now tries to transfer Predicate > instance (filter) to remote node. > # Predicates are transferred to remote node with each update. > # Predicate should be transferred only for "replace" operation if certain > entry provided, otherwise we should send a correct operation code and use > corresponding static filter on remote side. > # This change will break protocol compatibility. Should we bother about it? > Let's fix protocol and add tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10264) MVCC: Enlist request failure on backup can cause grid hanging.
[
https://issues.apache.org/jira/browse/IGNITE-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723077#comment-16723077
]
Roman Kondakov commented on IGNITE-10264:
-
Solved in -IGNITE-9828.-
> MVCC: Enlist request failure on backup can cause grid hanging.
> --
>
> Key: IGNITE-10264
> URL: https://issues.apache.org/jira/browse/IGNITE-10264
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Critical
> Labels: Hanging
>
> See stacktrace below, runtime ClusterTopologyException has not been catched
> and causes transaction hanging.
> Seems, we should throws some meaningful checked exception and thow it onto
> primary node.
> Reproducer is IgniteCacheIncrementTxTest running in Mvcc mode.
>
> {noformat}
> [2018-11-14
> 22:26:37,099][ERROR][sys-stripe-3-#10280%cache.IgniteCacheIncrementTxTest7%][GridCacheIoManager]
> Failed to process message [senderId=3774798b-3cbc-4ae1-95d1-745dd371,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxQueryFirstEnlistRequest]
> class org.apache.ignite.cluster.ClusterTopologyException: Can not reserve
> partition. Please retry on stable topology.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1865)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:274)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748){noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[ https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723076#comment-16723076 ] Pavel Kuznetsov commented on IGNITE-10645: -- Ok, Failed .net test now fail now with another exception. Test creates table via QueryEntity with no keyFields, so insertion with dml leads to empty binary object gets inserted as a cache key. Second insertion has empty binary object as a key too, so we got exception. [~vozerov] suggested to validate this case in the dml processing. > SQL properties ownership flag should be set at configuration parsing, not > query execution. > -- > > Key: IGNITE-10645 > URL: https://issues.apache.org/jira/browse/IGNITE-10645 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > At processing time, query entities are transformed and validated, table > descriptors with properties are created. > Now in some case (thre's no keyFields and key is of complex non-sql type), > ownership flag of query property is calculated at execution time (for example > at first put()): > https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132 > So we can't access metadata, that uses this not-yet-initialized field before > we put the data. > But we already have all necessary info to set this field at processing time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10719) [ML] LEarningEnvironmentBuilder is not passed in makeBagged
Artem Malykh created IGNITE-10719: - Summary: [ML] LEarningEnvironmentBuilder is not passed in makeBagged Key: IGNITE-10719 URL: https://issues.apache.org/jira/browse/IGNITE-10719 Project: Ignite Issue Type: Bug Components: ml Reporter: Artem Malykh Assignee: Artem Malykh During TrainerTrainsformers#makeBagged learning environment builder is not passed from trainer which is made bagged -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10695) MVCC: Fix cache API conditional update operations.
[ https://issues.apache.org/jira/browse/IGNITE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10695: -- Priority: Major (was: Critical) > MVCC: Fix cache API conditional update operations. > -- > > Key: IGNITE-10695 > URL: https://issues.apache.org/jira/browse/IGNITE-10695 > Project: Ignite > Issue Type: Bug > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > Operation like putIfAbsent and replace now tries to transfer Predicate > instance (filter) to remote node. > # Almost all filters can't be serialized as they do not have assigned direct > type. > # Seems, we have no enough tests and we miss remote-call case for such > operations. > # Predicate should be transferred only for "replace" operation if certain > entry provided, otherwise we should send a correct operation code and use > corresponding static filter on remote side. > # This change will break protocol compatibility. Should we bother about it? > Let's fix protocol and add tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10264) MVCC: Enlist request failure on backup can cause grid hanging.
[
https://issues.apache.org/jira/browse/IGNITE-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-10264:
---
Assignee: Roman Kondakov
> MVCC: Enlist request failure on backup can cause grid hanging.
> --
>
> Key: IGNITE-10264
> URL: https://issues.apache.org/jira/browse/IGNITE-10264
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Critical
> Labels: Hanging
>
> See stacktrace below, runtime ClusterTopologyException has not been catched
> and causes transaction hanging.
> Seems, we should throws some meaningful checked exception and thow it onto
> primary node.
> Reproducer is IgniteCacheIncrementTxTest running in Mvcc mode.
>
> {noformat}
> [2018-11-14
> 22:26:37,099][ERROR][sys-stripe-3-#10280%cache.IgniteCacheIncrementTxTest7%][GridCacheIoManager]
> Failed to process message [senderId=3774798b-3cbc-4ae1-95d1-745dd371,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxQueryFirstEnlistRequest]
> class org.apache.ignite.cluster.ClusterTopologyException: Can not reserve
> partition. Please retry on stable topology.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1865)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:274)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748){noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10682) Disable unnecessary loaded plugins for the Inspection test suite
[
https://issues.apache.org/jira/browse/IGNITE-10682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723073#comment-16723073
]
Andrew Mashenkov commented on IGNITE-10682:
---
[~Mmuzaf],
Thanks. Let's apply this.
> Disable unnecessary loaded plugins for the Inspection test suite
>
>
> Key: IGNITE-10682
> URL: https://issues.apache.org/jira/browse/IGNITE-10682
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> As part of discussion [1] we've faced with the problem: the set of
> unnecessary plugins are loaded during the Inspection test suite run. This
> leads to unnecessary checking inspection rules which are not used in the
> Apache Ignite project and wasting agent CPU resources.
> The log can be found at [2] execution suite results.
> {code}
> > 46 plugins initialized in 1031 ms
> > 2018-12-13 10:55:24,875 [ 1342] INFO - llij.ide.plugins.PluginManager -
> > Loaded bundled plugins: Android Support (10.2.3), Ant Support (1.0), CSS
> > Support (172.4574.11), Database Tools and SQL (172.4574.11), Eclipse
> > Integration (3.0), FreeMarker support (1.0), GWT Support (1.0), Gradle
> > (172.4574.11), Groovy (9.0), Guice (8.0), HTML Tools (2.0), Hibernate
> > Support (1.0), I18n for Java (172.4574.11),
> > IntelliLang (8.0), JBoss Seam Support (1.0), JUnit (1.0), Java EE: Bean
> > Validation Support (1.1), Java EE: Contexts and Dependency Injection (1.1),
> > Java EE: EJB, JPA, Servlets (1.0), Java EE: Java Server Faces (2.2.X.),
> > Java EE: Web Services (JAX-WS) (1.9), Java Server Pages (JSP) Integration
> > (1.0), JavaScript Support (1.0), Kotlin (1.1.4-release-IJ2017.2-3), Maven
> > Integration (172.4574.11), Persistence Frameworks Support (1.0), Plugin
> > DevKit (1.0), Properties Support (172.4574.11), QuirksMode (172.4574.11),
> > Spring AOP/@AspectJ (1.0), Spring Batch (1.0), Spring Data (1.0), Spring
> > Integration Patterns (1.0), Spring Security (1.0), Spring Support (1.0),
> > Spring Web Flow (1.0), Spring Web Services (1.0), Struts 1.x (2.0), Struts
> > 2 (1.0), TestNG-J (8.0), UI Designer (172.4574.11), Velocity support (1.0),
> > W3C Validators (2.0), WebLogic Integration (1.0), XPathView + XSLT Support
> > (4)
> {code}
> We need to disable these loaded plugins as they don't need for checking core
> inspection rules.
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p39471.html
> [2]
> https://ci.ignite.apache.org/viewLog.html?buildId=2538111=IgniteTests24Java8_ExcludedInspections2=artifacts
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10691) thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or C++ client
[
https://issues.apache.org/jira/browse/IGNITE-10691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kosenchuk reassigned IGNITE-10691:
-
Assignee: Igor Sapego (was: Dmitry Melnichuk)
UUID binary encoding must be defined in the Binary Protocol specification
(https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-uuid-guid-)
As there are no standards for binary encoding of UUIDs
https://en.wikipedia.org/wiki/Universally_unique_identifier#Encoding
So, it's the issue against the spec first.
Regarding the clients..
Python client uses Python UUID class
(https://docs.python.org/2/library/uuid.html) which, if I understand correctly,
can operate with different encodings.
NodeJs and PHP do not have standard UUID classes.
So, the clients return/accept UUID as just a 16-byte array with binary encoding
inside, exactly as it is read / will be written via the binary protocol.
An application may convert this array to/from a required representation.
> thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or
> C++ client
> -
>
> Key: IGNITE-10691
> URL: https://issues.apache.org/jira/browse/IGNITE-10691
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.8
>
>
> Trying to put uuid with PY or PHP or NodeJS client and get from Java or C++
> client have different results
> Python put
> {code}
> cache = client.get_or_create_cache("UUID_PY")
> cache.put(1, UUID("d597be47-949e-475b-8918-44ca836798a3"),
> key_hint=IntObject, value_hint=UUIDObject)
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PY");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> 5b479e94-47be-97d5-a398-6783ca441889
> {code}
> Same for C++ thin client
> And they looks like mixed up in a different order
> Python: {code}d597be47-949e-475b-8918-44ca836798a3{code}
> Java: {code}5b479e94-47be-97d5-a398-6783ca441889{code}
> For example take "ca" in 7-8 number from the end of java uuid
> On left we have "83", but in python "83" stay on right side from "ca"
> Different for "44" which is on right for Java but on left for Python
> NodeJS put
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_JS"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> key = 1;
> value = [95,190,238,78,178,166,68,220,153,172,100,68,215,254,125,246];
> await cache.put(key, value);
> {code}
> Py get
> {code}
> cache = client.get_or_create_cache("UUID_JS")
> result = cache.get(1, key_hint=IntObject)
> print(result)
> {code}
> Py output
> {code}
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_JS");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc44a6b2-4eee-be5f-f67d-fed74464ac99
> {code}
> PHP put
> [238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205] =
> "ee0f2fed-e07a-42dc-aa59-7f8fc7380acd"
> {code}
> $cache =
> $client->getOrCreateCache("UUID_PH")->setKeyType(ObjectType::INTEGER)->setValueType(ObjectType::UUID);
> $cache->put(1,[238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205]);
> {code}
> JS get
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_PH"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> result = (await cache.get(1));
> {code}
> JS output
> {code}
> 238 15 47 237 224 122 66 220 170 89 127 143 199 56 10 205
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PH");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc427ae0-ed2f-0fee-cd0a-38c78f7f59aa
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9774) CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan hangs
[
https://issues.apache.org/jira/browse/IGNITE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723057#comment-16723057
]
Roman Kondakov commented on IGNITE-9774:
I wasn't able to reproduce this hang locally. May be this case is fixed in
IGNITE-9663. But this test is still unstable. The failures may be caused by the
problem described in IGNITE-9949.
> CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs
> ---
>
> Key: IGNITE-9774
> URL: https://issues.apache.org/jira/browse/IGNITE-9774
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
> Labels: Hanging
>
> Test
> {{CacheMvccTransactionsTest#testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs}} and can freeze a whole suite. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723054#comment-16723054
]
Anton Vinogradov commented on IGNITE-8823:
--
Looks like we have to rollback fix from IGNITE-5510, but add "null is ok" to
these asserts,
and then start fixing this test.
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Ignite8823ReproducerTest.java
>
>
> Reproducable by test method {{testCreateConsistencyMultithreaded}} in
> {{IgfsPrimaryMultiNodeSelfTest}} and
> {{IgfsPrimaryRelaxedConsistencyMultiNodeSelfTest}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
>
[jira] [Commented] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723032#comment-16723032
]
Anton Vinogradov commented on IGNITE-8823:
--
[~andrey-kuznetsov]
Fix looks incorrect.
I see thее you just added
{{if (cacheCtx.config().getBackups() == 1)}}
before failing code when cache at test have 0 backups.
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Ignite8823ReproducerTest.java
>
>
> Reproducable by test method {{testCreateConsistencyMultithreaded}} in
> {{IgfsPrimaryMultiNodeSelfTest}} and
> {{IgfsPrimaryRelaxedConsistencyMultiNodeSelfTest}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
>
[jira] [Commented] (IGNITE-10324) Disallow fallback to Scanner in control.sh when asking password
[
https://issues.apache.org/jira/browse/IGNITE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723029#comment-16723029
]
Ignite TC Bot commented on IGNITE-10324:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2573768]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2537371buildTypeId=IgniteTests24Java8_RunAll]
> Disallow fallback to Scanner in control.sh when asking password
> ---
>
> Key: IGNITE-10324
> URL: https://issues.apache.org/jira/browse/IGNITE-10324
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Alexand Polyakov
>Priority: Major
>
> After implementing IGNITE-9990 we still can fallback to Scanner in case of
> Console is not allowed, user can easily fallback to non-secure mode by using
> some java agent. We should not allow this, cause otherwise all efforts in
> IGNITE-9990 are useless.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10563) Allow manual fsync for WAL
[
https://issues.apache.org/jira/browse/IGNITE-10563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723025#comment-16723025
]
Andrey Gura commented on IGNITE-10563:
--
Just thoughts:
{{putAll}} will involve *at least* one node as well as any sequence of cache
operations can involve *at least* one node. So suggested manual fsync should be
cluster wide (e.g. broadcast task). Such API will look counterintuitive from my
point of view. It seems that batch operations should be performed in
transaction and transactions should have method with {{commit with fsync}}
semantics. But transactions don't allow operations on atomic caches.
> Allow manual fsync for WAL
> --
>
> Key: IGNITE-10563
> URL: https://issues.apache.org/jira/browse/IGNITE-10563
> Project: Ignite
> Issue Type: Improvement
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> When walMode is set to LOG_ONLY or BACKGROUND there is a gap between
> successful return of cache write operations and actual of the data to the
> persistent memory. This gap is, while usually low, generally can be of any
> length and depends on low-level system parameters (e.g. sysctl memory and IO
> settings on Linux).
> On the other hand, there are situations when a user may want to ensure that
> at certain points all writes have been propagated to the disk.
> For example, say a large batch of data is being inserted into Ignite from an
> upstream system. After finishing the batch we want to ensure that all of the
> data is secure, and after that we remove the batch from the upstream storage.
> In other words, we want
> {code}
> map = upstream.getData();
> cache.putAll(map);
> cache.fsync(); // <---
> upstream.removeAll(map);
> {code}
> Currently there is no easy way to ensure that certain write (or all writes
> until a point in time) has been flushed to a device. We can only rely on
> settings like WAL sync interval, checkpoint timeout, etc.
> It would be nice to have a way to manually call fsync() for WAL to have a
> strong guarantee that all previous updates have been fully written on disk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10716) Rest clients should call ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible leaking of the memory
[ https://issues.apache.org/jira/browse/IGNITE-10716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723020#comment-16723020 ] ASF GitHub Bot commented on IGNITE-10716: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5682 > Rest clients should call ctx.security().onSessionExpired(subjid) on > disconnect to avoid the possible leaking of the memory > -- > > Key: IGNITE-10716 > URL: https://issues.apache.org/jira/browse/IGNITE-10716 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > > At the moment ctx.security().onSessionExpired(subjid) didn't called on rest > session expiration. > It provides the leaking of the memory related to resources that were > generated during authentification. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10716) Rest clients should call ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible leaking of the memory
[ https://issues.apache.org/jira/browse/IGNITE-10716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723017#comment-16723017 ] Ilya Kasnacheev commented on IGNITE-10716: -- Thank you for contribution! I have merged to master. > Rest clients should call ctx.security().onSessionExpired(subjid) on > disconnect to avoid the possible leaking of the memory > -- > > Key: IGNITE-10716 > URL: https://issues.apache.org/jira/browse/IGNITE-10716 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > > At the moment ctx.security().onSessionExpired(subjid) didn't called on rest > session expiration. > It provides the leaking of the memory related to resources that were > generated during authentification. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10716) Rest clients should call ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible leaking of the memory
[ https://issues.apache.org/jira/browse/IGNITE-10716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10716: - Ignite Flags: (was: Docs Required) > Rest clients should call ctx.security().onSessionExpired(subjid) on > disconnect to avoid the possible leaking of the memory > -- > > Key: IGNITE-10716 > URL: https://issues.apache.org/jira/browse/IGNITE-10716 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > > At the moment ctx.security().onSessionExpired(subjid) didn't called on rest > session expiration. > It provides the leaking of the memory related to resources that were > generated during authentification. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10669) NPE in freelist.PagesList.findTailIndex
[
https://issues.apache.org/jira/browse/IGNITE-10669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kovalenko reassigned IGNITE-10669:
Assignee: Pavel Kovalenko
> NPE in freelist.PagesList.findTailIndex
> ---
>
> Key: IGNITE-10669
> URL: https://issues.apache.org/jira/browse/IGNITE-10669
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.7
> Environment: Windows
>Reporter: ARomantsov
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.8
>
>
> Run node with 1 cache and put to it.
> Kill node and try run back - it broken on start
> {code:java}
> [22:40:10,916][INFO][main][GridCacheDatabaseSharedManager] Applying lost
> cache updates since last checkpoint record [lastMarked=FileWALPointer [idx=2,
> fileOff=14706, len=21409],
> lastCheckpointId=2f9202e9-c9d7-47ca-9dcc-299a959bb2e0]
> [22:40:10,922][SEVERE][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connections
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.findTailIndex(PagesList.java:502)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.updateTail(PagesList.java:458)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.mergeNoNext(PagesList.java:1330)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.removeDataPage(PagesList.java:1281)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList$RemoveRowHandler.run(AbstractFreeList.java:305)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList$RemoveRowHandler.run(AbstractFreeList.java:261)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:279)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:256)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.removeDataRowByLink(AbstractFreeList.java:571)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetastorageRowStore.removeRow(MetastorageRowStore.java:57)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.putData(MetaStorage.java:253)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.applyUpdate(MetaStorage.java:492)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLogicalUpdates(GridCacheDatabaseSharedManager.java:2420)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1909)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1056)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
> at org.apache.ignite.Ignition.start(Ignition.java:348)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
> [22:40:10,922][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.findTailIndex(PagesList.java:502)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.updateTail(PagesList.java:458)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.mergeNoNext(PagesList.java:1330)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.removeDataPage(PagesList.java:1281)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList$RemoveRowHandler.run(AbstractFreeList.java:305)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList$RemoveRowHandler.run(AbstractFreeList.java:261)
> at
>
[jira] [Commented] (IGNITE-10716) Rest clients should call ctx.security().onSessionExpired(subjid) on disconnect to avoid the possible leaking of the memory
[
https://issues.apache.org/jira/browse/IGNITE-10716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723016#comment-16723016
]
Ignite TC Bot commented on IGNITE-10716:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2573933]]
* CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Queries 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2573998]]
* IgniteSqlSchemaIndexingTest.testCustomSchemaMultipleCachesTablesCollision
(last started)
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2573975]]
* CacheExchangeMergeTest.testStartCacheOnJoinAndCoordinatorFailed1 (last
started)
{color:#d04437}Hibernate 2{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2573922]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Hibernate 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2573921]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2574005buildTypeId=IgniteTests24Java8_RunAll]
> Rest clients should call ctx.security().onSessionExpired(subjid) on
> disconnect to avoid the possible leaking of the memory
> --
>
> Key: IGNITE-10716
> URL: https://issues.apache.org/jira/browse/IGNITE-10716
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.7
>Reporter: Andrey Aleksandrov
>Assignee: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
>
> At the moment ctx.security().onSessionExpired(subjid) didn't called on rest
> session expiration.
> It provides the leaking of the memory related to resources that were
> generated during authentification.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
