[jira] [Created] (IGNITE-9863) Refactor VisorDataTransferObject to common class
Alexey Kuznetsov created IGNITE-9863: Summary: Refactor VisorDataTransferObject to common class Key: IGNITE-9863 URL: https://issues.apache.org/jira/browse/IGNITE-9863 Project: Ignite Issue Type: Task Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Initially VisorDataTransferObject was implemented to use with Visor CMD only. But I see that now it is using together with control.sh utility. And it looks strange that some classes not related to Visor use some Visor-specific class. Lets move this class to "org.apache.ignite.internal.dto" package with name IgniteDataTransferObject and deprecate VisorDataTransferObject (with removal in 3.0). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-9739:
---
Component/s: persistence
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=1983794578, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
> cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
> primitiveCollection=false, isVersioned=false, isComposite=false,
> isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code,
> isIndexedCollection=false, isGlobal=true, maxSelective=1000]
> , com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1821682714, hash=-1245813786, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
> moduleName=union-module, cachedUnselectives=1, selectors=ArrayList
> {globalId}, exceptUnselectives=false, primitiveCollection=false,
> isVersioned=false, isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_globalId, isIndexedCollection=false,
> isGlobal=false, maxSelective=
[jira] [Updated] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-9739:
---
Description:
Activation finished
{code:java}
2018-09-20 20:47:05.169 [INFO
][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
Successfully performed final activation steps
[nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
{code}
but we have nodes not in base line
{code:java}
2018-09-20 20:45:36.116 [INFO
][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
Local node is not included in Baseline Topology and will not be used for
persistent data storage. Use control.(sh|bat) script or IgniteCluster interface
to include the node to Baseline Topology.
{code}
And we have cache (869481129) in the data region with persistanceEnabled=false
{code:java}
2018-09-20 20:49:01.825 [INFO
][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
{code}
Transaction on this cache(869481129)
{code:java}
869481129{code}
leads to critical error causing nodes by faulure handler:
{code:java}
2018-09-20 20:50:24.275
[ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
invalidateNearEntries={}, nearWrites=null, owned=null,
nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
preloadKeys=null, skipCompletedVers=false,
super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
order=1537511036824, nodeOrder=7], timeout=299970, reads=null, writes=ArrayList
[
IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
*cacheId=869481129*,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
*cacheId=869481129*], val=[op=CREATE,
val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
[idHash=811765531, hash=1522508040,
cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
{com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
[idHash=1583970836, hash=363194492, isSoftReference=false,
unselectiveBuckets=4096, fieldNames=ArrayList
\{isDeleted},moduleName=union-module
, cachedUnselectives=1, selectors=ArrayList {isDeleted},
exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
isComposite=false, isSystemTypeBelongs=false,
name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
isGlobal=false, maxSelective=1000],
com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
[idHash=2060926101, hash=1983794578, isSoftReference=false,
unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
primitiveCollection=false, isVersioned=false, isComposite=false,
isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code,
isIndexedCollection=false, isGlobal=true, maxSelective=1000]
, com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
[idHash=1821682714, hash=-1245813786, isSoftReference=false,
unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
moduleName=union-module, cachedUnselectives=1, selectors=ArrayList
{globalId}, exceptUnselectives=false, primitiveCollection=false,
isVersioned=false, isComposite=false, isSystemTypeBelongs=false,
name=com.sbt.gbk.entities.DocType_DPL_globalId, isIndexedCollection=false,
isGlobal=false, maxSelective=1000]
}, partitionDependencyClassName=null, moduleName=union-module,
cacheModuleName=union-module]
], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
explicitVer=null, dhtVer=null, filters=CacheEntryPredicate[] [],
filtersPassed=false, filtersSet=false, entry=GridCacheMapEntry
[key=KeyCacheObjectImpl [part=27254,
val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true], val=null,
startVer=1537511036806, ver=GridCacheVersion [topVer=148944365,
order=1537511036806, nodeOrder=86], hash=-1897857526,
extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=null, rmts=Link
edList [GridCacheM
[jira] [Assigned] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev reassigned IGNITE-9739:
--
Assignee: Sergey Kosarev
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=1983794578, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
> cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
> primitiveCollection=false, isVersioned=false, isComposite=false,
> isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code,
> isIndexedCollection=false, isGlobal=true, maxSelective=1000]
> , com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1821682714, hash=-1245813786, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
> moduleName=union-module, cachedUnselectives=1, selectors=ArrayList
> {globalId}, exceptUnselectives=false, primitiveCollection=false,
> isVersioned=false, isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_globalId, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000]
> }, partitionDependen
[jira] [Commented] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647533#comment-16647533
]
Ignite TC Bot commented on IGNITE-9739:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hadoop{color} [[tests 0 Out Of Memory Error , Exit Code ,
[Artifacts publishing failed]
|https://ci.ignite.apache.org/viewLog.html?buildId=2066052]]
* IgniteHadoopFileSystemClientBasedOpenTest.testFsOpenMultithreadedSkipInProc
(last started)
{color:#d04437}Platform .NET (Long Running){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2066056]]
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 3,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 3,0% fails in last 100 master
runs.
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 3,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 3,0% fails in last 100 master
runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2064417&buildTypeId=IgniteTests24Java8_RunAll]
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Priority: Major
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=19837
[jira] [Commented] (IGNITE-7054) S3 IP finder: support client side encryption
[
https://issues.apache.org/jira/browse/IGNITE-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647528#comment-16647528
]
Uday Kale commented on IGNITE-7054:
---
[~vkulichenko],
Yes adding an {{init()}} method makes sense. I have made all the changes and
updated the PR. Please have a look.
> S3 IP finder: support client side encryption
>
>
> Key: IGNITE-7054
> URL: https://issues.apache.org/jira/browse/IGNITE-7054
> Project: Ignite
> Issue Type: Improvement
> Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> In case client side encryption [1] is used, it may be required to use
> {{AmazonS3EncryptionClient}} instead of regular {{AmazonS3Client}}. We need
> to add this option to the S3 IP finder, along with any applicable
> configuration parameters.
> [1]
> http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9862) Web Console: Add support for "date", "time" and "date-and-time" on InputDialog
[ https://issues.apache.org/jira/browse/IGNITE-9862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647469#comment-16647469 ] ASF GitHub Bot commented on IGNITE-9862: GitHub user akuznetsov-gridgain opened a pull request: https://github.com/apache/ignite/pull/4966 IGNITE-9862 Web Console: Add support for "date", "time" and "date-and… …-time" to InputDialog. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9862 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4966.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 #4966 commit 2fd5342ca62313638ca68b489092613139ac Author: Alexey Kuznetsov Date: 2018-10-12T05:00:39Z IGNITE-9862 Web Console: Add support for "date", "time" and "date-and-time" to InputDialog. > Web Console: Add support for "date", "time" and "date-and-time" on InputDialog > -- > > Key: IGNITE-9862 > URL: https://issues.apache.org/jira/browse/IGNITE-9862 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > It will be useful also support following types "date", "time" and > "date-and-time" in order to input them via this dialog. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9862) Web Console: Add support for "date", "time" and "date-and-time" on InputDialog
[ https://issues.apache.org/jira/browse/IGNITE-9862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9862: - Ignite Flags: (was: Docs Required) > Web Console: Add support for "date", "time" and "date-and-time" on InputDialog > -- > > Key: IGNITE-9862 > URL: https://issues.apache.org/jira/browse/IGNITE-9862 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > It will be useful also support following types "date", "time" and > "date-and-time" in order to input them via this dialog. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9862) Web Console: Add support for "date", "time" and "date-and-time" on InputDialog
Alexey Kuznetsov created IGNITE-9862: Summary: Web Console: Add support for "date", "time" and "date-and-time" on InputDialog Key: IGNITE-9862 URL: https://issues.apache.org/jira/browse/IGNITE-9862 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.8 It will be useful also support following types "date", "time" and "date-and-time" in order to input them via this dialog. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9345) Document custom SQL schemas
[
https://issues.apache.org/jira/browse/IGNITE-9345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg reassigned IGNITE-9345:
---
Assignee: Denis Magda (was: Prachi Garg)
> Document custom SQL schemas
> ---
>
> Key: IGNITE-9345
> URL: https://issues.apache.org/jira/browse/IGNITE-9345
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.7
>
>
> Key highlights:
> 1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
> \{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
> from docs (if there is such paragraph)
> 2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
> schemas with provided names.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9345) Document custom SQL schemas
[
https://issues.apache.org/jira/browse/IGNITE-9345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647289#comment-16647289
]
Prachi Garg commented on IGNITE-9345:
-
[~Artem Budnikov], looks good. I made minor edits.
[~dmagda], please do final review.
> Document custom SQL schemas
> ---
>
> Key: IGNITE-9345
> URL: https://issues.apache.org/jira/browse/IGNITE-9345
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.7
>
>
> Key highlights:
> 1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
> \{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
> from docs (if there is such paragraph)
> 2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
> schemas with provided names.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7054) S3 IP finder: support client side encryption
[
https://issues.apache.org/jira/browse/IGNITE-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647211#comment-16647211
]
Valentin Kulichenko commented on IGNITE-7054:
-
[~uday],
Agree with #4 and #5. Please do the changes for #1-3 and resubmit the PR.
Regarding #3: I think it makes sense to add {{init()}} method to the
{{EncryptionService}} and use it for the initialization step. This way you will
avoid complicated synchronization and simplify the implementation. Makes sense?
> S3 IP finder: support client side encryption
>
>
> Key: IGNITE-7054
> URL: https://issues.apache.org/jira/browse/IGNITE-7054
> Project: Ignite
> Issue Type: Improvement
> Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> In case client side encryption [1] is used, it may be required to use
> {{AmazonS3EncryptionClient}} instead of regular {{AmazonS3Client}}. We need
> to add this option to the S3 IP finder, along with any applicable
> configuration parameters.
> [1]
> http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[ https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647190#comment-16647190 ] PetrovMikhail commented on IGNITE-8331: --- Hello, [~vozerov]. IgniteCachePartitionedTransactionalColumnConstraintsTest, IgniteCacheReplicatedAtomicColumnConstraintsTest and IgniteCacheReplicatedTransactionalColumnConstraintsTest are extended from IgniteCachePartitionedAtomicColumnConstraintsTest and provide tests for corresponding cache modes by overriding cacheMode() and atomicityMode() methods. Tests for TRANSACTIONAL and TRANSACTIONAL_SNAPSHOT caches was added similarly. Can you review my changes, please? > SQL: Add Decimal precision and scale constraint > --- > > Key: IGNITE-8331 > URL: https://issues.apache.org/jira/browse/IGNITE-8331 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should support DECIMAL(X, Y) syntax. > Currently, we ignore it. > It affects semantics. > E.g., one can insert a DECIMAL with greater precision into a cache/table > without any problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[ https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647188#comment-16647188 ] PetrovMikhail commented on IGNITE-8331: --- All .Net tests is failing on master branch with the same error. Licenses Headers Error was catched in _ignite-indexing_,which was not changed by me. > SQL: Add Decimal precision and scale constraint > --- > > Key: IGNITE-8331 > URL: https://issues.apache.org/jira/browse/IGNITE-8331 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should support DECIMAL(X, Y) syntax. > Currently, we ignore it. > It affects semantics. > E.g., one can insert a DECIMAL with greater precision into a cache/table > without any problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[
https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647149#comment-16647149
]
Ignite TC Bot commented on IGNITE-8331:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2059981]]
* dll: IgniteConfigurationParityTest.TestIgniteConfiguration - 0,0% fails in
last 100 master runs.
* dll: DataRegionMetricsTest.TestMemoryMetrics - 0,0% fails in last 100 master
runs.
{color:#d04437}Platform .NET{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2059983]]
* exe: IgniteConfigurationParityTest.TestIgniteConfiguration - 0,0% fails in
last 100 master runs.
* exe: DataRegionMetricsTest.TestMemoryMetrics - 0,0% fails in last 100 master
runs.
* exe: MemoryMetricsTest.TestMemoryMetrics - 0,0% fails in last 100 master runs.
{color:#d04437}RDD*{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2059989]]
* org.apache.ignite.spark.IgniteOptimizationDateFuncSpec.Supported optimized
date functions - FORMATDATETIME - 0,0% fails in last 100 master runs.
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2059990]]
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2057810&buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Add Decimal precision and scale constraint
> ---
>
> Key: IGNITE-8331
> URL: https://issues.apache.org/jira/browse/IGNITE-8331
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: PetrovMikhail
>Priority: Major
> Labels: sql-engine
>
> We should support DECIMAL(X, Y) syntax.
> Currently, we ignore it.
> It affects semantics.
> E.g., one can insert a DECIMAL with greater precision into a cache/table
> without any problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9645) [TC Bot] Add comparison of failed tests lists in two date intervals
[ https://issues.apache.org/jira/browse/IGNITE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647129#comment-16647129 ] ASF GitHub Bot commented on IGNITE-9645: ololo3000 opened a new pull request #36: IGNITE-9645 [TC Bot] Add comparison of failed tests lists in two date intervals URL: https://github.com/apache/ignite-teamcity-bot/pull/36 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [TC Bot] Add comparison of failed tests lists in two date intervals > --- > > Key: IGNITE-9645 > URL: https://issues.apache.org/jira/browse/IGNITE-9645 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > > Based on [IGNITE-9541|https://issues.apache.org/jira/browse/IGNITE-9541] It's > needed to add comparison of failed tests lists in two date intervals -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9645) [TC Bot] Add comparison of failed tests lists in two date intervals
[
https://issues.apache.org/jira/browse/IGNITE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647126#comment-16647126
]
ASF GitHub Bot commented on IGNITE-9645:
ololo3000 closed pull request #25: IGNITE-9645 [TC Bot] Add comparison of
failed tests lists in two date intervals
URL: https://github.com/apache/ignite-teamcity-bot/pull/25
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
index 6aa3b60..b0157c8 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
@@ -36,15 +36,18 @@
import org.apache.ignite.ci.tcmodel.conf.BuildType;
import org.apache.ignite.ci.tcmodel.hist.BuildRef;
import org.apache.ignite.ci.tcmodel.result.Build;
+import org.apache.ignite.ci.tcmodel.result.Configurations;
import org.apache.ignite.ci.tcmodel.result.issues.IssuesUsagesList;
import org.apache.ignite.ci.tcmodel.result.problems.ProblemOccurrences;
import org.apache.ignite.ci.tcmodel.result.stat.Statistics;
import org.apache.ignite.ci.tcmodel.result.tests.TestOccurrence;
import org.apache.ignite.ci.tcmodel.result.tests.TestOccurrenceFull;
import org.apache.ignite.ci.tcmodel.result.tests.TestOccurrences;
+import org.apache.ignite.ci.tcmodel.result.tests.TestRef;
import org.apache.ignite.ci.tcmodel.user.User;
import org.apache.ignite.ci.teamcity.pure.ITeamcityConn;
import org.apache.ignite.ci.util.Base64Util;
+import org.apache.ignite.ci.web.rest.parms.FullQueryParams;
import org.jetbrains.annotations.NotNull;
import static com.google.common.base.Strings.isNullOrEmpty;
@@ -152,8 +155,12 @@ default Build getBuild(int id) {
*/
ProblemOccurrences getProblems(Build build);
+ProblemOccurrences getProblems(BuildRef buildId);
+
TestOccurrences getTests(String href, String normalizedBranch);
+TestOccurrences getFailedUnmutedTestsNames(String href, int count, String
normalizedBranch);
+
Statistics getBuildStatistics(String href);
CompletableFuture getTestFull(String href);
@@ -162,6 +169,10 @@ default Build getBuild(int id) {
ChangesList getChangesList(String href);
+CompletableFuture getTestRef(FullQueryParams key);
+
+Configurations getConfigurations(FullQueryParams key);
+
/**
* List of build's related issues.
*
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
index d1e94e4..774e21b 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
@@ -66,16 +66,19 @@
import org.apache.ignite.ci.tcmodel.conf.BuildType;
import org.apache.ignite.ci.tcmodel.hist.BuildRef;
import org.apache.ignite.ci.tcmodel.result.Build;
+import org.apache.ignite.ci.tcmodel.result.Configurations;
import org.apache.ignite.ci.tcmodel.result.issues.IssuesUsagesList;
import org.apache.ignite.ci.tcmodel.result.problems.ProblemOccurrences;
import org.apache.ignite.ci.tcmodel.result.stat.Statistics;
import org.apache.ignite.ci.tcmodel.result.tests.TestOccurrence;
import org.apache.ignite.ci.tcmodel.result.tests.TestOccurrenceFull;
import org.apache.ignite.ci.tcmodel.result.tests.TestOccurrences;
+import org.apache.ignite.ci.tcmodel.result.tests.TestRef;
import org.apache.ignite.ci.tcmodel.user.User;
import org.apache.ignite.ci.util.CacheUpdateUtil;
import org.apache.ignite.ci.util.CollectionUtil;
import org.apache.ignite.ci.util.ObjectInterner;
+import org.apache.ignite.ci.web.rest.parms.FullQueryParams;
import org.jetbrains.annotations.NotNull;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -104,6 +107,8 @@
private static final String BUILD_HIST_FINISHED = "buildHistFinished";
private static final String BUILD_HIST_FINISHED_OR_FAILED =
"buildHistFinishedOrFailed";
public static final String BOT_DETECTED_ISSUES = "botDetectedIssues";
+public static final String TEST_REFS = "testRefs";
+public static final String CONFIGURATIONS = "configurations";
//todo need separate cache or separate key for 'execution time' because it
is placed in statistics
private static final String BUILDS_FAILURE_RUN_STAT =
"buildsFailureRunStat";
@@ -125,6 +130,9 @@
*/
private ConcurrentMap>
testOccFullFutures = new ConcurrentHashMap<>();
+/** Cached loads of test refs.*/
+
[jira] [Updated] (IGNITE-9284) [ML] Add a Standard Scaler
[ https://issues.apache.org/jira/browse/IGNITE-9284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ravil Galeyev updated IGNITE-9284: -- Fix Version/s: 2.8 > [ML] Add a Standard Scaler > -- > > Key: IGNITE-9284 > URL: https://issues.apache.org/jira/browse/IGNITE-9284 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Ravil Galeyev >Priority: Major > Labels: new-feature > Fix For: 2.8 > > > Add analogue of > [http://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.StandardScaler.html] > Please look at the MinMaxScaler or Normalization packages in preprocessing > package. > Add classes if required > 1) Preprocessor > 2) Trainer > 3) custom PartitionData if shuffling is a step of algorithm > > Requirements for successful PR: > # PartitionedDataset usage > # Trainer-Model paradigm support > # Tests for Model and for Trainer (and other stuff) > # Example of usage with small, but famous dataset like IRIS, Titanic or > House Prices > # Javadocs/codestyle according guidelines > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9284) [ML] Add a Standard Scaler
[ https://issues.apache.org/jira/browse/IGNITE-9284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ravil Galeyev updated IGNITE-9284: -- Labels: new-feature (was: ) > [ML] Add a Standard Scaler > -- > > Key: IGNITE-9284 > URL: https://issues.apache.org/jira/browse/IGNITE-9284 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Ravil Galeyev >Priority: Major > Labels: new-feature > > Add analogue of > [http://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.StandardScaler.html] > Please look at the MinMaxScaler or Normalization packages in preprocessing > package. > Add classes if required > 1) Preprocessor > 2) Trainer > 3) custom PartitionData if shuffling is a step of algorithm > > Requirements for successful PR: > # PartitionedDataset usage > # Trainer-Model paradigm support > # Tests for Model and for Trainer (and other stuff) > # Example of usage with small, but famous dataset like IRIS, Titanic or > House Prices > # Javadocs/codestyle according guidelines > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9284) [ML] Add a Standard Scaler
[ https://issues.apache.org/jira/browse/IGNITE-9284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647085#comment-16647085 ] ASF GitHub Bot commented on IGNITE-9284: GitHub user dehasi opened a pull request: https://github.com/apache/ignite/pull/4964 IGNITE-9284 Add standard scaler You can merge this pull request into a Git repository by running: $ git pull https://github.com/dehasi/ignite feature/ignite-9284-add-standard-scaler Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4964.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 #4964 commit 16a51bb2ed820e2c080a9c9d29b1be2ffc0e827b Author: dehasi Date: 2018-10-07T13:25:22Z IGNITE-9284: Create package for standard scaler commit cb93def4914954bd9b5f9529f6153e421dea8ff1 Author: dehasi Date: 2018-10-07T13:42:58Z IGNITE-9284: Implement a standard scaler commit 34450cd6345a3540145d2c43142fd8d995803d5f Author: dehasi Date: 2018-10-07T18:04:30Z IGNITE-9284: Add a standard scaler preprocessor test template commit a9af7030f3792628fd0cf0af70d80d89f65cb055 Author: dehasi Date: 2018-10-09T04:54:04Z IGNITE-9284: Add more data to test commit 834fea10ef6d33257499574de2c1f1b1f66e2298 Author: dehasi Date: 2018-10-09T15:47:12Z IGNITE-9284: Finish preprocessor commit 724aedf7e1afcbafe8c4feb19b3f8bcd51e54ef3 Author: dehasi Date: 2018-10-09T17:57:03Z IGNITE-9284: Add standard scaler trainer commit 9c6f5ce4a98942452cea03ad7108253d747c9e17 Author: dehasi Date: 2018-10-09T18:09:28Z IGNITE-9284: Add trainer test template commit c7bf8d815dd782c703200cdc3373ad299105617a Author: dehasi Date: 2018-10-09T18:21:58Z IGNITE-9284: Extract common part from tests commit f49b66f80fe0b4be83984eafab2ae55956f85866 Author: dehasi Date: 2018-10-09T18:26:06Z IGNITE-9284: Complete test the standard scaler trainer commit 6019c8e00975941d2f36e3c18daeb29a52ff130b Author: dehasi Date: 2018-10-10T04:39:31Z IGNITE-9284: Add trainer example commit 98570cf0461198873a4b9722eaa167042e59fa2e Author: dehasi Date: 2018-10-10T15:46:54Z IGNITE-9284: Count sigma with mean > [ML] Add a Standard Scaler > -- > > Key: IGNITE-9284 > URL: https://issues.apache.org/jira/browse/IGNITE-9284 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Ravil Galeyev >Priority: Major > > Add analogue of > [http://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.StandardScaler.html] > Please look at the MinMaxScaler or Normalization packages in preprocessing > package. > Add classes if required > 1) Preprocessor > 2) Trainer > 3) custom PartitionData if shuffling is a step of algorithm > > Requirements for successful PR: > # PartitionedDataset usage > # Trainer-Model paradigm support > # Tests for Model and for Trainer (and other stuff) > # Example of usage with small, but famous dataset like IRIS, Titanic or > House Prices > # Javadocs/codestyle according guidelines > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9546) Document GROUP_CONCAT aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg reassigned IGNITE-9546:
---
Assignee: Denis Magda (was: Prachi Garg)
> Document GROUP_CONCAT aggregate function
>
>
> Key: IGNITE-9546
> URL: https://issues.apache.org/jira/browse/IGNITE-9546
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.7
>
>
> We need to document GROUP_CONCAT aggregate function.
> # Explain users that {{DISTINCT}} and {{ORDER BY}} is supported only for
> collocated {{GROUP BY}};
> # String concatenation expressions are separated by {{||}} (not by comma as
> described at the
> [draft|https://dash.readme.io/project/apacheignite-sql/v2.6/docs/group_concat]);
> e.g.: {{GROUP_CONCAT(valueId || '=' || value SEPARATOR '; ')}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9546) Document GROUP_CONCAT aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647080#comment-16647080
]
Prachi Garg commented on IGNITE-9546:
-
[~Artem Budnikov], looks good to me.
[~dmagda], please do final review.
> Document GROUP_CONCAT aggregate function
>
>
> Key: IGNITE-9546
> URL: https://issues.apache.org/jira/browse/IGNITE-9546
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> We need to document GROUP_CONCAT aggregate function.
> # Explain users that {{DISTINCT}} and {{ORDER BY}} is supported only for
> collocated {{GROUP BY}};
> # String concatenation expressions are separated by {{||}} (not by comma as
> described at the
> [draft|https://dash.readme.io/project/apacheignite-sql/v2.6/docs/group_concat]);
> e.g.: {{GROUP_CONCAT(valueId || '=' || value SEPARATOR '; ')}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9355) Document new system views (nodes, node attributes, baseline nodes, node metrics)
[
https://issues.apache.org/jira/browse/IGNITE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg reassigned IGNITE-9355:
---
Assignee: Artem Budnikov (was: Prachi Garg)
> Document new system views (nodes, node attributes, baseline nodes, node
> metrics)
>
>
> Key: IGNITE-9355
> URL: https://issues.apache.org/jira/browse/IGNITE-9355
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document three new SQL system views.
> # Explain users that new system SQL schema appeared, named "IGNITE", where
> all views are stored
> # System view NODES - list of current nodes in topology. Columns: ID,
> CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER,
> ADDRESSES, HOSTNAMES
> # System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID,
> NAME, VALUE
> # System view BASELINE_NODES - list of baseline topology nodes. Columns:
> CONSISTENT_ID, ONLINE (whether node is up and running at the moment)
> # System view NODE_METRICS - node metrics. Columns - see
> \{{org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewNodeMetrics}}
> class
> # Explain limitations: views cannot be joined with user tables; it is not
> allowed to create other objects (tables, indexes) in "IGNITE" schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9355) Document new system views (nodes, node attributes, baseline nodes, node metrics)
[
https://issues.apache.org/jira/browse/IGNITE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647071#comment-16647071
]
Prachi Garg commented on IGNITE-9355:
-
[~Artem Budnikov], the Columns table in the Node metrics view section has bold
headers whereas other tables' headers don't. Any reason why this table is
created differently?
> Document new system views (nodes, node attributes, baseline nodes, node
> metrics)
>
>
> Key: IGNITE-9355
> URL: https://issues.apache.org/jira/browse/IGNITE-9355
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> We need to document three new SQL system views.
> # Explain users that new system SQL schema appeared, named "IGNITE", where
> all views are stored
> # System view NODES - list of current nodes in topology. Columns: ID,
> CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER,
> ADDRESSES, HOSTNAMES
> # System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID,
> NAME, VALUE
> # System view BASELINE_NODES - list of baseline topology nodes. Columns:
> CONSISTENT_ID, ONLINE (whether node is up and running at the moment)
> # System view NODE_METRICS - node metrics. Columns - see
> \{{org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewNodeMetrics}}
> class
> # Explain limitations: views cannot be joined with user tables; it is not
> allowed to create other objects (tables, indexes) in "IGNITE" schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6444) Validate that copyOnRead flag is configured with on-heap cache enabled
[
https://issues.apache.org/jira/browse/IGNITE-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647059#comment-16647059
]
Ignite TC Bot commented on IGNITE-6444:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Activate | Deactivate Cluster{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2061921]]
* IgniteStandByClusterSuite:
IgniteStandByClusterTest.testStaticCacheStartAfterActivationWithCacheFilter -
0,0% fails in last 100 master runs.
* IgniteStandByClusterSuite:
JoinActiveNodeToActiveCluster.testJoinClientStaticCacheConfigurationOnJoin -
0,0% fails in last 100 master runs.
{color:#d04437}SPI{color} [[tests
46|https://ci.ignite.apache.org/viewLog.html?buildId=2061954]]
* IgniteSpiTestSuite: GridTcpCommunicationSpiRecoverySelfTest.testBlockRead1 -
0,0% fails in last 100 master runs.
* IgniteSpiTestSuite: GridTcpCommunicationSpiRecoverySelfTest.testBlockRead3 -
0,0% fails in last 100 master runs.
{color:#d04437}PDS (Indexing){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2061978]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint -
0,0% fails in last 100 master runs.
{color:#d04437}Platform .NET (Long Running){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2061969]]
* exe: config.test") - 0,0% fails in last 100 master runs.
* exe: config.test2") - 0,0% fails in last 100 master runs.
* exe: ExecutableTest.TestJvmMemoryOptsCmdCombined - 0,0% fails in last 100
master runs.
* exe: ExecutableTest.TestJvmMemoryOptsCmdCustom - 0,0% fails in last 100
master runs.
{color:#d04437}Cache 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2061998]]
* IgniteCacheTestSuite2:
IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode -
0,0% fails in last 100 master runs.
{color:#d04437}Platform .NET{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2061966]]
* exe: DataStreamerTest.TestObjectGraphs - 0,0% fails in last 100 master runs.
* exe: DataStreamerTest.TestPropertyPropagation - 0,0% fails in last 100 master
runs.
* exe: WindowsServiceTest.TestStopFromJava - 0,0% fails in last 100 master runs.
{color:#d04437}Queries 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2061949]]
* IgniteBinaryCacheQueryTestSuite2:
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testClientReconnect -
0,0% fails in last 100 master runs.
{color:#d04437}Cache 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2061999]]
* IgniteBinaryObjectsCacheTestSuite3:
IgniteCacheGroupsTest.testRestartsAndCacheCreateDestroy - 0,0% fails in last
100 master runs.
{color:#d04437}Basic 2{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2061917]]
* IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest.testNodeSingletonDeploy - 1,0% fails
in last 100 master runs.
* IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest.testKeyAffinityDeploy - 0,0% fails in
last 100 master runs.
{color:#d04437}Platform C++ (Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2061963]]
* IgniteCoreTest: CacheQueryTestSuite: TestSqlFieldsQueryDistributedJoins -
1,0% fails in last 100 master runs.
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2061976]]
* IgnitePdsTestSuite:
IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testGetForInitialWrite -
0,0% fails in last 100 master runs.
{color:#d04437}Cache (Full API){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2061993]]
* IgniteCacheFullApiSelfTestSuite:
GridCacheLocalFullApiSelfTest.testTransformReturnValuePutInTx - 0,0% fails in
last 100 master runs.
* IgniteCacheFullApiSelfTestSuite:
GridCacheLocalWithGroupFullApiSelfTest.testTransformReturnValuePutInTx - 0,0%
fails in last 100 master runs.
{color:#d04437}AOP{color} [[tests
41|https://ci.ignite.apache.org/viewLog.html?buildId=2061915]]
* IgniteAopSelfTestSuite: BasicAopSelfTest.testAop - 0,0% fails in last 100
master runs.
* IgniteAopSelfTestSuite: NonSpringAopSelfTest.testNonDefaultClassContinuous -
0,0% fails in last 100 master runs.
* IgniteAopSelfTestSuite: NonSpringAopSelfTest.testNonDefaultClassIsolated -
0,0% fails in last 100 master runs.
* IgniteAopSelfTestSuite: NonSpringAopSelfTest.testNonDefaultClassPrivate -
0,0% fails in last 100 master runs.
* IgniteAopSelfTestSuite:
NonSpringAopSelfTest.testNonDefaultClassResourceContinuous - 0,0% fails in last
100 master runs.
* IgniteAopSelfTestSuite:
NonSpringAopSelfTest.testNonDefaultClassResourceIsolated - 0,0% fails in last
100 master runs.
* IgniteAopSelfTestSuite:
NonSpringAopSelfTest.testNonDefaultClassResourcePrivate - 0,0
[jira] [Commented] (IGNITE-9525) Ignite + Informatica Integration
[ https://issues.apache.org/jira/browse/IGNITE-9525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647058#comment-16647058 ] Prachi Garg commented on IGNITE-9525: - [~pvinokurov], can you please provide more information regarding the integration? > Ignite + Informatica Integration > > > Key: IGNITE-9525 > URL: https://issues.apache.org/jira/browse/IGNITE-9525 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Prachi Garg >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > > Mentioned in https://cwiki.apache.org/confluence/display/IGNITE/Required+Docs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9525) Ignite + Informatica Integration
[ https://issues.apache.org/jira/browse/IGNITE-9525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-9525: --- Assignee: Pavel Vinokurov (was: Prachi Garg) > Ignite + Informatica Integration > > > Key: IGNITE-9525 > URL: https://issues.apache.org/jira/browse/IGNITE-9525 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Prachi Garg >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > > Mentioned in https://cwiki.apache.org/confluence/display/IGNITE/Required+Docs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9714) Document ODBC streaming mode
[
https://issues.apache.org/jira/browse/IGNITE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg reassigned IGNITE-9714:
---
Assignee: Artem Budnikov (was: Prachi Garg)
> Document ODBC streaming mode
>
>
> Key: IGNITE-9714
> URL: https://issues.apache.org/jira/browse/IGNITE-9714
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Need to document ODBC streaming mode introduced in IGNITE-7855.
> Need to mention that ODBC supports streaming mode now and give a link to a
> {{SET}} command description, pretty much the same way it's done for JDBC:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#section-streaming
> Maybe it makes sense to mention that "array of parameters" feature and
> "data-on-execution" are not supported in the streaming mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9714) Document ODBC streaming mode
[
https://issues.apache.org/jira/browse/IGNITE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647056#comment-16647056
]
Prachi Garg commented on IGNITE-9714:
-
[~Artem Budnikov],
In the 2 callouts - "Flush all data to the cluster" and "Know limitations", are
these statements true for ODBC as well? If so, we should include ODBC there as
well.
> Document ODBC streaming mode
>
>
> Key: IGNITE-9714
> URL: https://issues.apache.org/jira/browse/IGNITE-9714
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> Need to document ODBC streaming mode introduced in IGNITE-7855.
> Need to mention that ODBC supports streaming mode now and give a link to a
> {{SET}} command description, pretty much the same way it's done for JDBC:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#section-streaming
> Maybe it makes sense to mention that "array of parameters" feature and
> "data-on-execution" are not supported in the streaming mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9714) Document ODBC streaming mode
[
https://issues.apache.org/jira/browse/IGNITE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647056#comment-16647056
]
Prachi Garg edited comment on IGNITE-9714 at 10/11/18 9:34 PM:
---
[~Artem Budnikov],
In the 2 callouts - "Flush all data to the cluster" and "Known limitations",
are these statements true for ODBC as well? If so, we should include ODBC there
as well.
was (Author: pgarg):
[~Artem Budnikov],
In the 2 callouts - "Flush all data to the cluster" and "Know limitations", are
these statements true for ODBC as well? If so, we should include ODBC there as
well.
> Document ODBC streaming mode
>
>
> Key: IGNITE-9714
> URL: https://issues.apache.org/jira/browse/IGNITE-9714
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> Need to document ODBC streaming mode introduced in IGNITE-7855.
> Need to mention that ODBC supports streaming mode now and give a link to a
> {{SET}} command description, pretty much the same way it's done for JDBC:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#section-streaming
> Maybe it makes sense to mention that "array of parameters" feature and
> "data-on-execution" are not supported in the streaming mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9714) Document ODBC streaming mode
[
https://issues.apache.org/jira/browse/IGNITE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647056#comment-16647056
]
Prachi Garg edited comment on IGNITE-9714 at 10/11/18 9:35 PM:
---
[~Artem Budnikov],
In the 2 callouts - "Flush all data to the cluster" and "Known limitations",
are the statements true for ODBC as well? If so, we should include ODBC there
as well.
was (Author: pgarg):
[~Artem Budnikov],
In the 2 callouts - "Flush all data to the cluster" and "Known limitations",
are these statements true for ODBC as well? If so, we should include ODBC there
as well.
> Document ODBC streaming mode
>
>
> Key: IGNITE-9714
> URL: https://issues.apache.org/jira/browse/IGNITE-9714
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> Need to document ODBC streaming mode introduced in IGNITE-7855.
> Need to mention that ODBC supports streaming mode now and give a link to a
> {{SET}} command description, pretty much the same way it's done for JDBC:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#section-streaming
> Maybe it makes sense to mention that "array of parameters" feature and
> "data-on-execution" are not supported in the streaming mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7054) S3 IP finder: support client side encryption
[
https://issues.apache.org/jira/browse/IGNITE-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646918#comment-16646918
]
Uday Kale commented on IGNITE-7054:
---
[~vkulichenko],
Thanks for the review. Following are the replies to the requested changes:
# I will change this to take a single argument {{KeyPair}} which holds both
{{PrivateKey}} and {{PublicKey}}. Didn't find any other such cases.
# [No questions]
# I have implemented this on the same lines as
{{TcpDiscoveryS3IpFinder#initClient()}}. Here since, the setters are used to
pass the initialisation params, I will have to check for them and lazy
initialise the clients. If its OK to pass these params from constructor instead
of setters, I can remove such code.
# I have made them package-private for unit test purposes. See
{{AwsKmsEncryptionServiceTest#testEncryptDecrypt() Line:54}}.
# The encrypted bytes under the default java character encoding is returning
some special characters. These special characters are illegal in S3. See
characters to avoid under
[https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html]. Base32
encoding has all characters that are acceptable by AWS S3. See
[https://en.wikipedia.org/wiki/Base32].
> S3 IP finder: support client side encryption
>
>
> Key: IGNITE-7054
> URL: https://issues.apache.org/jira/browse/IGNITE-7054
> Project: Ignite
> Issue Type: Improvement
> Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> In case client side encryption [1] is used, it may be required to use
> {{AmazonS3EncryptionClient}} instead of regular {{AmazonS3Client}}. We need
> to add this option to the S3 IP finder, along with any applicable
> configuration parameters.
> [1]
> http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9861) Authorization object names must always be non-null.
[ https://issues.apache.org/jira/browse/IGNITE-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646890#comment-16646890 ] ASF GitHub Bot commented on IGNITE-9861: GitHub user BiryukovVA opened a pull request: https://github.com/apache/ignite/pull/4963 IGNITE-9861: Authorization object names must always be non-null. You can merge this pull request into a Git repository by running: $ git pull https://github.com/BiryukovVA/ignite IGNITE-9861 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4963.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 #4963 commit f97dfaec3baf9d60ae1c0c8683db2e7281533b6a Author: Vitaliy Biryukov Date: 2018-10-11T18:43:53Z IGNITE-9861: Authorization object names must always be non-null. > Authorization object names must always be non-null. > --- > > Key: IGNITE-9861 > URL: https://issues.apache.org/jira/browse/IGNITE-9861 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.6 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Fix For: 2.8 > > > Currently, sometimes *null* name parameter passing to a method > *GridSecurityProcessor:authorize*. This leads to the fact that it is > impossible to determine the authorization object by authorization event. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9710) Ignite watchdog service handles longrunning cache creation
[
https://issues.apache.org/jira/browse/IGNITE-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646854#comment-16646854
]
ASF GitHub Bot commented on IGNITE-9710:
GitHub user andrey-kuznetsov opened a pull request:
https://github.com/apache/ignite/pull/4962
IGNITE-9710 Ignite watchdog service handles longrunning cache creation
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andrey-kuznetsov/ignite ignite-9710
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4962.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 #4962
commit 2eb31c9d1680ecb7a3c16284c96fc4641e330dba
Author: Andrey Kuznetsov
Date: 2018-10-11T15:09:13Z
IGNITE-9710 Added blocking sections in GridDhtPartitionsExchangeFuture#init.
commit 269bc84894138d654fe448ca93b09369e9878e3d
Author: Andrey Kuznetsov
Date: 2018-10-11T16:21:44Z
Merge branch 'master' into ignite-9710
# Conflicts:
#
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java
commit d667c11853a212fb3bad41d4f7be933f4ff35dc1
Author: Andrey Kuznetsov
Date: 2018-10-11T18:10:33Z
IGNITE-9710 Fixing blocking sections.
> Ignite watchdog service handles longrunning cache creation
> --
>
> Key: IGNITE-9710
> URL: https://issues.apache.org/jira/browse/IGNITE-9710
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Vyacheslav Daradur
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
> Attachments: LongRunningCacheCreationTest.java
>
>
> Ignite watchdog service introduced by IGNITE-6587 handles long running cache
> creation.
> Action in {{GridDhtPartitionsExchangeFuture#init}} may take significant time
> and possibly should be covered by blocking section of warchdog service.
> Reproducer was attached: [^LongRunningCacheCreationTest.java].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9861) Authorization object names must always be non-null.
[ https://issues.apache.org/jira/browse/IGNITE-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov updated IGNITE-9861: - Component/s: security > Authorization object names must always be non-null. > --- > > Key: IGNITE-9861 > URL: https://issues.apache.org/jira/browse/IGNITE-9861 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.6 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Fix For: 2.8 > > > Currently, sometimes *null* name parameter passing to a method > *GridSecurityProcessor:authorize*. This leads to the fact that it is > impossible to determine the authorization object by authorization event. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9861) Authorization object names must always be non-null.
Vitaliy Biryukov created IGNITE-9861: Summary: Authorization object names must always be non-null. Key: IGNITE-9861 URL: https://issues.apache.org/jira/browse/IGNITE-9861 Project: Ignite Issue Type: Improvement Affects Versions: 2.6 Reporter: Vitaliy Biryukov Assignee: Vitaliy Biryukov Fix For: 2.8 Currently, sometimes *null* name parameter passing to a method *GridSecurityProcessor:authorize*. This leads to the fact that it is impossible to determine the authorization object by authorization event. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9430) Add ability to override all caches's "rebalanceThrottle" option via JVM node option
[
https://issues.apache.org/jira/browse/IGNITE-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646826#comment-16646826
]
Ignite TC Bot commented on IGNITE-9430:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2051881&buildTypeId=IgniteTests24Java8_RunAll]
> Add ability to override all caches's "rebalanceThrottle" option via JVM node
> option
>
>
> Key: IGNITE-9430
> URL: https://issues.apache.org/jira/browse/IGNITE-9430
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: ARomantsov
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.8
>
>
> I found ability to set rebalanceThrottle option for any cache , but can we
> have JVM key for override that parameter for all caches at once
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646819#comment-16646819
]
ASF GitHub Bot commented on IGNITE-9739:
GitHub user macrergate opened a pull request:
https://github.com/apache/ignite/pull/4961
IGNITE-9739 don't write non-baseline nodes to wal TxRecord
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9739
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4961.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 #4961
commit 95ee30d9e1c0c69e7a7d251fd61b86fe9f5528d4
Author: Sergey Kosarev
Date: 2018-10-11T17:44:51Z
IGNITE-9739 don't write non-baseline nodes to wal TxRecord
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Priority: Major
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=1983794578, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
> cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
>
[jira] [Created] (IGNITE-9860) Unreliable listener invocation order in GridDhtPartitionsExchangeFuture#onDone
Andrey Kuznetsov created IGNITE-9860:
Summary: Unreliable listener invocation order in
GridDhtPartitionsExchangeFuture#onDone
Key: IGNITE-9860
URL: https://issues.apache.org/jira/browse/IGNITE-9860
Project: Ignite
Issue Type: Bug
Reporter: Andrey Kuznetsov
Fix For: 2.8
Listener being added right before {{super.onDone()}} call is intended to be
invoked earlier than all other listeners. There is a small probability of
breaking this guarantee: some other thread can call {{listen()}} before
future-completing thread enters {{super.onDone()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-8570:
-
Description:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression,
_+Proposed design+_, pseudocode:
{code:java}
public class ListeningTestLogger implements IgniteLogger {
public void registerListener(Consumer lsnr);
public void unregisterListener(Consumer lsnr);
public void clearListeners();
}
{code}
In 99.9% cases we at some point we should validate listener precondition. For
example, default precondition for {{substring listener}} - "_does log have any
messages containing such substring?_". So, listener should support validation.
{code:java}
interface LogListener extends Consumer {
void check() throws AssertionError;
}
{code}
To simplify creation of common case listeners (substring, regular expression
and predicate) should be introduced special listener builder.
+_Sample logger usage_+:
{code:java}
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case
insensitive, at least one time)
LogListener lsnr =
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
// ...
// ...
// ...
lsnr.check(); // throws AssertionError if precodition is not met.
{code}
was:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression,
_+Proposed design+_, pseudocode:
{code:java}
public class ListeningTestLogger implements IgniteLogger {
public void registerListener(Consumer lsnr);
public void unregisterListener(Consumer lsnr);
public void clearListeners();
}
{code}
In 99.9% cases we at some point we should validate listener precondition. For
example, default precondition for {{substring listener}} - "_does log have any
messages containing such substring?_". So, listener should support validation.
{code:java}
interface LogListener extends Consumer {
void check() throws AssertionError;
}
{code}
To simplify creation of common case listeners (substring, regular expression
and predicate) should be introduced special listener builder.
+_Sample logger usage_+:
{code:java}
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case
insensitive, at least one time)
LogListener lsnr =
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
// ...
// ...
// ...
lsnr.check();
{code}
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}
[jira] [Updated] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-8570:
-
Description:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression,
_+Proposed design+_, pseudocode:
{code:java}
public class ListeningTestLogger implements IgniteLogger {
public void registerListener(Consumer lsnr);
public void unregisterListener(Consumer lsnr);
public void clearListeners();
}
{code}
In 99.9% cases we at some point we should validate listener precondition. For
example, default precondition for {{substring listener}} - "_does log have any
messages containing such substring?_". So, listener should support validation.
{code:java}
interface LogListener extends Consumer {
void check() throws AssertionError;
}
{code}
To simplify creation of common case listeners (substring, regular expression
and predicate) should be introduced special listener builder.
+_Sample logger usage_+:
{code:java}
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case
insensitive, at least one time)
LogListener lsnr =
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
// ...
// ...
// ...
lsnr.check();
{code}
was:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression,
_+Proposed design+_, pseudocode:
{code:java}
public class ListeningTestLogger implements IgniteLogger {
public void registerListener(Consumer lsnr);
public void unregisterListener(Consumer lsnr);
public void clearListeners();
}
{code}
In 99.9% cases we at some point we should validate listener precondition. For
example, default precondition for {{substring listener}} - "_does log have any
messages containing such substring?_". So, listener should support validation.
{code:java}
interface LogListener extends Consumer {
void check() throws AssertionError;
}
{code}
To simplify creation of common case listeners (substring, regular expression
and predicate) should be introduced special listener builder.
+_Sample logger usage_+:
{code:java}
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case
insensitive, at least one time)
LogListener lsnr =
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
lsnr.check();
{code}
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log conte
[jira] [Updated] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-8570:
-
Description:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression,
_+Proposed design+_, pseudocode:
{code:java}
public class ListeningTestLogger implements IgniteLogger {
public void registerListener(Consumer lsnr);
public void unregisterListener(Consumer lsnr);
public void clearListeners();
}
{code}
In 99.9% cases we at some point we should validate listener precondition. For
example, default precondition for {{substring listener}} - "_does log have any
messages containing such substring?_". So, listener should support validation.
{code:java}
interface LogListener extends Consumer {
void check() throws AssertionError;
}
{code}
To simplify creation of common case listeners (substring, regular expression
and predicate) should be introduced special listener builder.
+_Sample logger usage_+:
{code:java}
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case
insensitive, at least one time)
LogListener lsnr =
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
lsnr.check();
{code}
was:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression,
_+Proposed design+_, pseudocode:
```
public class ListeningTestLogger implements IgniteLogger {
…
public void registerListener(Consumer lsnr);
public void unregisterListener(Consumer lsnr);
public void clearListeners();
…
}
```
In 99.9% cases we at some point we should validate listener precondition. For
example, default precondition for {{substring listener}} - "_does log have any
messages containing such substring?_". So, listener should support validation.
```
interface LogListener extends Consumer {
void check() throws AssertionError;
}
```
To simplify creation of common case listeners (substring, regular expression
and predicate) should be introduced special listener builder.
+_Sample logger usage_+:
```
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case
insensitive, at least one time)
LogListener lsnr =
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
...
lsnr.check();
```
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustio
[jira] [Updated] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-8570:
-
Description:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression,
_+Proposed design+_, pseudocode:
```
public class ListeningTestLogger implements IgniteLogger {
…
public void registerListener(Consumer lsnr);
public void unregisterListener(Consumer lsnr);
public void clearListeners();
…
}
```
In 99.9% cases we at some point we should validate listener precondition. For
example, default precondition for {{substring listener}} - "_does log have any
messages containing such substring?_". So, listener should support validation.
```
interface LogListener extends Consumer {
void check() throws AssertionError;
}
```
To simplify creation of common case listeners (substring, regular expression
and predicate) should be introduced special listener builder.
+_Sample logger usage_+:
```
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case
insensitive, at least one time)
LogListener lsnr =
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
...
lsnr.check();
```
was:
_+Problem with current GridStringLogger implementation+_:
Most usages of {{GridStringLogger}} in test assumes the following scenario.
First, it is set as a logger for some Ignite node.
Then, after some activity on that node, log content is searched for some
predefined strings.
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
store log contents, older contents gets dropped on exaustion.
Thus, changes that add more logging may damage some independent tests that use
{{GridStringLogger}}.
+_The suggestion for new implementation:_+
The suggestion is to implement and use another test logger conforming to these
requirements:
* It does not accumulate any logs(actually, it will print no logs to anywhere)
* It allows to set the listener that fires when log message matches certain
regular expression, {{Matcher}} can be passed to the listener
_+Proposed design+_, pseudocode:
```
Class GridRegexpLogger implements IgniteLogger{
…
debug(String str){
if (/* str matches pattern. */)
\{ /* notify listeners. */ }
}
…
listen("regexp", IgniteInClosure loggerListener)// listener receives
message
{ /* registers listener. */ }
listenDebug("regexp", loggerListener)
{ /* registers listener for debug output only. */ }
…
}
```
+_Sample regexp logger usage_+:
```
GridRegexpLogger logger;
logger.listen(“regexp”, new GridRegexpListener());
logger.listenDebug("regexp", new GridRegexpListener());
```
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression,
> _+Proposed design+_, pseudocode:
> ```
> public cla
[jira] [Commented] (IGNITE-9561) Optimize affinity initialization for started cache groups
[
https://issues.apache.org/jira/browse/IGNITE-9561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646702#comment-16646702
]
ASF GitHub Bot commented on IGNITE-9561:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4854
> Optimize affinity initialization for started cache groups
> -
>
> Key: IGNITE-9561
> URL: https://issues.apache.org/jira/browse/IGNITE-9561
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Labels: cache
> Fix For: 2.8
>
>
> At the end of
> {noformat}
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#processCacheStartRequests
>
> {noformat}
> method we're initializing affinity for cache groups starting at current
> exchange.
> We do it one-by-one and synchronously wait for AffinityFetchResponse for each
> of the starting groups. This is inefficient. We may parallelize this process
> and speed up caches starting process.
> NOTE: There are also a lot of affinity recalculation methods in:
> {noformat}
> CacheAffinitySharedManager
> {noformat}
> which all looks like iterate over cache groups and recalculate affinity for
> all of them. We can easily speed-up each of such methods executing in
> parallel affinity re-calculation for each of cache groups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[
https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646682#comment-16646682
]
Ignite TC Bot commented on IGNITE-4111:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2057917&buildTypeId=IgniteTests24Java8_RunAll]
> Communication fails to send message if target node did not finish join process
> --
>
> Key: IGNITE-4111
> URL: https://issues.apache.org/jira/browse/IGNITE-4111
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Semen Boikov
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.8
>
> Attachments: test onFirstMessage hang.log
>
>
> Currently this scenario is possible:
> - joining node sent join request and waits for
> TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology
> - others nodes already see this node and can send messages to it (for example
> try to run compute job on this node)
> - joining node can not receive message: TcpCommunicationSpi will hang inside
> 'onFirstMessage' on 'getSpiContext' call, so sending node will get error
> trying to establish connection
> Possible fix: if in onFirstMessage() spi context is not available, then
> TcpCommunicationSpi should send special response which indicates that this
> node is not ready yet, and sender should retry after some time.
> Also need check internal code for places where message can be unnecessarily
> sent to node: one such place is
> GridCachePartitionExchangeManager.refreshPartitions - message is sent to all
> known nodes, but here we can filter by node order / finished exchage version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9561) Optimize affinity initialization for started cache groups
[
https://issues.apache.org/jira/browse/IGNITE-9561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646669#comment-16646669
]
Ignite TC Bot commented on IGNITE-9561:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1956072&buildTypeId=IgniteTests24Java8_RunAll]
> Optimize affinity initialization for started cache groups
> -
>
> Key: IGNITE-9561
> URL: https://issues.apache.org/jira/browse/IGNITE-9561
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Labels: cache
> Fix For: 2.8
>
>
> At the end of
> {noformat}
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#processCacheStartRequests
>
> {noformat}
> method we're initializing affinity for cache groups starting at current
> exchange.
> We do it one-by-one and synchronously wait for AffinityFetchResponse for each
> of the starting groups. This is inefficient. We may parallelize this process
> and speed up caches starting process.
> NOTE: There are also a lot of affinity recalculation methods in:
> {noformat}
> CacheAffinitySharedManager
> {noformat}
> which all looks like iterate over cache groups and recalculate affinity for
> all of them. We can easily speed-up each of such methods executing in
> parallel affinity re-calculation for each of cache groups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646659#comment-16646659 ] ASF GitHub Bot commented on IGNITE-9726: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4859 > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646651#comment-16646651 ] Alexey Goncharuk commented on IGNITE-9726: -- This is indeed a flaky test not related to the change, now looks good. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[
https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646650#comment-16646650
]
Ignite TC Bot commented on IGNITE-9726:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2051438&buildTypeId=IgniteTests24Java8_RunAll]
> GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache
> operations
> ---
>
> Key: IGNITE-9726
> URL: https://issues.apache.org/jira/browse/IGNITE-9726
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Example of timeouts:
> [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog]
> method testConstantTopologyChange can misses interrupt from test runner and
> lock suite
> see that after thread dump put/remove cache operations will continue in test
> testOptimisticSerializableTxConstantTopologyChange
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Attachment: (was: IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch) > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Attachment: IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646621#comment-16646621 ] Alexey Platonov commented on IGNITE-9726: - Hmm It's interesting [https://ci.ignite.apache.org/viewQueued.html?itemId=2061463] - this test was success > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[
https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646619#comment-16646619
]
Ignite TC Bot commented on IGNITE-9726:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 8{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2057923]]
* IgniteCacheTestSuite8:
OffheapCacheMetricsForClusterGroupSelfTest.testGetOffHeapPrimaryEntriesCount -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2051438&buildTypeId=IgniteTests24Java8_RunAll]
> GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache
> operations
> ---
>
> Key: IGNITE-9726
> URL: https://issues.apache.org/jira/browse/IGNITE-9726
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Example of timeouts:
> [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog]
> method testConstantTopologyChange can misses interrupt from test runner and
> lock suite
> see that after thread dump put/remove cache operations will continue in test
> testOptimisticSerializableTxConstantTopologyChange
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[
https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646599#comment-16646599
]
Ignite TC Bot commented on IGNITE-9550:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hadoop{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043851]]
* IgniteHadoopFileSystemClientBasedProxySelfTest.testClientReconnect (last
started)
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043895]]
* IgnitePdsPageEvictionDuringPartitionClearTest.testPageEvictionOnNodeStart
(last started)
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043892]]
* WalRolloverRecordLoggingFsyncTest.testAvoidInfinityWaitingOnRolloverOfSegment
(last started)
{color:#d04437}Cache (Restarts) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2043908]]
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutEightNodesTwoBackups -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2043934&buildTypeId=IgniteTests24Java8_RunAll]
> Get operation returns null for a lost partition with READ_SAFE policy
> -
>
> Key: IGNITE-9550
> URL: https://issues.apache.org/jira/browse/IGNITE-9550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Pavel Vinokurov
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.7
>
> Attachments: PartitionLostReproducer.java
>
>
> See reproduced attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[
https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646600#comment-16646600
]
Ignite TC Bot commented on IGNITE-9550:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hadoop{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043851]]
* IgniteHadoopFileSystemClientBasedProxySelfTest.testClientReconnect (last
started)
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043895]]
* IgnitePdsPageEvictionDuringPartitionClearTest.testPageEvictionOnNodeStart
(last started)
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043892]]
* WalRolloverRecordLoggingFsyncTest.testAvoidInfinityWaitingOnRolloverOfSegment
(last started)
{color:#d04437}Cache (Restarts) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2043908]]
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutEightNodesTwoBackups -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2043934&buildTypeId=IgniteTests24Java8_RunAll]
> Get operation returns null for a lost partition with READ_SAFE policy
> -
>
> Key: IGNITE-9550
> URL: https://issues.apache.org/jira/browse/IGNITE-9550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Pavel Vinokurov
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.7
>
> Attachments: PartitionLostReproducer.java
>
>
> See reproduced attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646602#comment-16646602
]
Ignite TC Bot commented on IGNITE-9532:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2050829]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePersistentStoreCacheGroupsTest.testExpiryPolicy - 0,0% fails in last 100
master runs.
{color:#d04437}Cache 8{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2050861]]
* IgniteCacheTestSuite8:
CacheMetricsForClusterGroupSelfTest.testMetricsStatisticsEnabled - 0,0% fails
in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2050871&buildTypeId=IgniteTests24Java8_RunAll]
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[
https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646598#comment-16646598
]
Ignite TC Bot commented on IGNITE-9550:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hadoop{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043851]]
* IgniteHadoopFileSystemClientBasedProxySelfTest.testClientReconnect (last
started)
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043895]]
* IgnitePdsPageEvictionDuringPartitionClearTest.testPageEvictionOnNodeStart
(last started)
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2043892]]
* WalRolloverRecordLoggingFsyncTest.testAvoidInfinityWaitingOnRolloverOfSegment
(last started)
{color:#d04437}Cache (Restarts) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2043908]]
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutEightNodesTwoBackups -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2043934&buildTypeId=IgniteTests24Java8_RunAll]
> Get operation returns null for a lost partition with READ_SAFE policy
> -
>
> Key: IGNITE-9550
> URL: https://issues.apache.org/jira/browse/IGNITE-9550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Pavel Vinokurov
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.7
>
> Attachments: PartitionLostReproducer.java
>
>
> See reproduced attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646588#comment-16646588 ] Alexey Platonov edited comment on IGNITE-9726 at 10/11/18 3:15 PM: --- This code doesn't even call run-async in tests. I see no reasons for investigating this situation. was (Author: aplatonov): This code doesn't even call run-async in tests. I don't see reasons for investigating this situation. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646588#comment-16646588 ] Alexey Platonov commented on IGNITE-9726: - This code doesn't even call run-async in tests. I don't see reasons for investigating this situation. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Attachment: IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Summary: add debug logging on refreshPartitions cause (was: add debug logging on resendPartitions cause) > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9858) [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
[
https://issues.apache.org/jira/browse/IGNITE-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9858:
-
Description:
SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
Example of such failures on master branch:
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-2762467041583095183&order=TEST_STATUS_DESC&itemsCount=50&branch_IgniteTests24Java8=%3Cdefault%3E]
Typically client node cannot join server, when client discovery SPI initializes
before server discovery, because client ipfinder don't registers local node
addresses (see TcpDiscoveryIpFinderAdapter#initializeLocalAddresses).
{noformat}
[2018-10-11 18:03:49,794][WARN
][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder returned
empty addresses list. Please check IP finder configuration. Will retry every
2000 ms. Change 'reconnectDelay' to configure the frequency of
retries.{noformat}
was:
SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
Example of such failures on master branch:
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-2762467041583095183&order=TEST_STATUS_DESC&itemsCount=50&branch_IgniteTests24Java8=%3Cdefault%3E]
Typically client node cannot join server, when client discovery SPI initializes
before server discovery, because ipfinder don't registers local node addresses
(see TcpDiscoveryIpFinderAdapter#initializeLocalAddresses).
{noformat}
[2018-10-11 18:03:49,794][WARN
][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder returned
empty addresses list. Please check IP finder configuration. Will retry every
2000 ms. Change 'reconnectDelay' to configure the frequency of
retries.{noformat}
> [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
>
>
> Key: IGNITE-9858
> URL: https://issues.apache.org/jira/browse/IGNITE-9858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
> Example of such failures on master branch:
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-2762467041583095183&order=TEST_STATUS_DESC&itemsCount=50&branch_IgniteTests24Java8=%3Cdefault%3E]
> Typically client node cannot join server, when client discovery SPI
> initializes before server discovery, because client ipfinder don't registers
> local node addresses (see
> TcpDiscoveryIpFinderAdapter#initializeLocalAddresses).
> {noformat}
> [2018-10-11 18:03:49,794][WARN
> ][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder
> returned empty addresses list. Please check IP finder configuration. Will
> retry every 2000 ms. Change 'reconnectDelay' to configure the frequency of
> retries.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9859) add debug logging on resendPartitions cause
Max Shonichev created IGNITE-9859: - Summary: add debug logging on resendPartitions cause Key: IGNITE-9859 URL: https://issues.apache.org/jira/browse/IGNITE-9859 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9858) [Test Failed] SystemCacheNotConfiguredTest#test flaky fails on TC (timeout).
Pavel Pereslegin created IGNITE-9858:
Summary: [Test Failed] SystemCacheNotConfiguredTest#test flaky
fails on TC (timeout).
Key: IGNITE-9858
URL: https://issues.apache.org/jira/browse/IGNITE-9858
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin
Fix For: 2.8
SystemCacheNotConfiguredTest hangs sometimes on TeamCity (timeout).
Example of such failures on master branch:
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-2762467041583095183&order=TEST_STATUS_DESC&itemsCount=50&branch_IgniteTests24Java8=%3Cdefault%3E]
Typically client node cannot join server, when client discovery SPI initializes
before server discovery, because ipfinder don't registers local node addresses
(see TcpDiscoveryIpFinderAdapter#initializeLocalAddresses).
{noformat}
[2018-10-11 18:03:49,794][WARN
][tcp-client-disco-msg-worker-#57%client%][TcpDiscoverySpi] IP finder returned
empty addresses list. Please check IP finder configuration. Will retry every
2000 ms. Change 'reconnectDelay' to configure the frequency of
retries.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9823) Create TeamCity suite for PHP thin client
[ https://issues.apache.org/jira/browse/IGNITE-9823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-9823. -- Resolution: Done > Create TeamCity suite for PHP thin client > - > > Key: IGNITE-9823 > URL: https://issues.apache.org/jira/browse/IGNITE-9823 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: php > Fix For: 2.7 > > > Implementation of PHP client is almost ready (IGNITE-7783). We need to figure > out how to integrate it with TeamCity: > 1) New suite for PHP thin client is needed along with required environment > 2) Suite should be able to run tests as described in the readme [1] > 3) Currently all tests rely on manually started external node. We need to > create a set of scripts (bash?) to start/stop nodes locally just like in > IGNITE-8463 > [1] > https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md#tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9823) Create TeamCity suite for PHP thin client
[ https://issues.apache.org/jira/browse/IGNITE-9823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646566#comment-16646566 ] Peter Ivanov commented on IGNITE-9823: -- TC suite is ready: [Thin client: PHP|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ThinClientPhp]. > Create TeamCity suite for PHP thin client > - > > Key: IGNITE-9823 > URL: https://issues.apache.org/jira/browse/IGNITE-9823 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: php > Fix For: 2.7 > > > Implementation of PHP client is almost ready (IGNITE-7783). We need to figure > out how to integrate it with TeamCity: > 1) New suite for PHP thin client is needed along with required environment > 2) Suite should be able to run tests as described in the readme [1] > 3) Currently all tests rely on manually started external node. We need to > create a set of scripts (bash?) to start/stop nodes locally just like in > IGNITE-8463 > [1] > https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md#tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[ https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646560#comment-16646560 ] Ryabov Dmitrii commented on IGNITE-9726: Test looks flaky, but last fail was a week ago. > GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache > operations > --- > > Key: IGNITE-9726 > URL: https://issues.apache.org/jira/browse/IGNITE-9726 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Example of timeouts: > [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog] > method testConstantTopologyChange can misses interrupt from test runner and > lock suite > see that after thread dump put/remove cache operations will continue in test > testOptimisticSerializableTxConstantTopologyChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9726) GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache operations
[
https://issues.apache.org/jira/browse/IGNITE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646553#comment-16646553
]
Ignite TC Bot commented on IGNITE-9726:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 8{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2057923]]
* IgniteCacheTestSuite8:
OffheapCacheMetricsForClusterGroupSelfTest.testGetOffHeapPrimaryEntriesCount -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2051438&buildTypeId=IgniteTests24Java8_RunAll]
> GridCacheAbstractFailoverSelfTest may lock all suite on put/remove cache
> operations
> ---
>
> Key: IGNITE-9726
> URL: https://issues.apache.org/jira/browse/IGNITE-9726
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Example of timeouts:
> [https://ci.ignite.apache.org/viewLog.html?buildId=1944646&buildTypeId=IgniteTests24Java8_CacheFailover2&tab=buildLog]
> method testConstantTopologyChange can misses interrupt from test runner and
> lock suite
> see that after thread dump put/remove cache operations will continue in test
> testOptimisticSerializableTxConstantTopologyChange
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9606) JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
[
https://issues.apache.org/jira/browse/IGNITE-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646505#comment-16646505
]
Pavel Kuznetsov commented on IGNITE-9606:
-
Tests looks good : only flacky fails, havn't reproduced locally. Couldn't run
.net test, but test fail don't seem to be related to changes (JDBC driver)
[~vozerov] Could you please take a look at the patch?
> JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME
> -
>
> Key: IGNITE-9606
> URL: https://issues.apache.org/jira/browse/IGNITE-9606
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Pat Patterson
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> JDBC {{getPrimaryKeys()}} method returns {{_KEY}} as column name rather than
> actual column name. This breaks apps that expect a valid column name as the
> primary key.
> Trivially reproducible:
> {noformat}
> public static void main(String[] args) throws Exception {
> // Register JDBC driver.
> Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
> // Open JDBC connection.
> try (Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
> // Create database tables.
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE TESTER (" + " ID LONG PRIMARY KEY,
> NAME VARCHAR) " + " WITH \"template=replicated\"");
> }
> // Get database metadata
> DatabaseMetaData md = conn.getMetaData();
> // Get primary keys
> ResultSet rs = md.getPrimaryKeys(conn.getCatalog(), "", "TESTER");
> //
> while (rs.next()) {
> // Column 4 is COLUMN_NAME
> System.out.println("Primary key column is " + rs.getString(4));
> }
> }
> }
> {noformat}
> Expected output is:
> {noformat}
> Primary key column is ID
> {noformat}
> Actual output is:
> {noformat}
> Primary key column is _KEY
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9857) .NET: IgniteConfigurationTest.TestSpringXml is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-9857. -- Resolution: Duplicate > .NET: IgniteConfigurationTest.TestSpringXml is flaky in master > -- > > Key: IGNITE-9857 > URL: https://issues.apache.org/jira/browse/IGNITE-9857 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > The test is constantly failing on a specific set of agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9857) .NET: IgniteConfigurationTest.TestSpringXml is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-9857: Assignee: Alexey Goncharuk > .NET: IgniteConfigurationTest.TestSpringXml is flaky in master > -- > > Key: IGNITE-9857 > URL: https://issues.apache.org/jira/browse/IGNITE-9857 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > The test is constantly failing on a specific set of agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9857) .NET: IgniteConfigurationTest.TestSpringXml is flaky in master
Alexey Goncharuk created IGNITE-9857: Summary: .NET: IgniteConfigurationTest.TestSpringXml is flaky in master Key: IGNITE-9857 URL: https://issues.apache.org/jira/browse/IGNITE-9857 Project: Ignite Issue Type: Test Reporter: Alexey Goncharuk The test is constantly failing on a specific set of agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9857) .NET: IgniteConfigurationTest.TestSpringXml is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9857: - Ignite Flags: (was: Docs Required) > .NET: IgniteConfigurationTest.TestSpringXml is flaky in master > -- > > Key: IGNITE-9857 > URL: https://issues.apache.org/jira/browse/IGNITE-9857 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > The test is constantly failing on a specific set of agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9856) Add documentation for control.sh --cache config
Sergey Antonov created IGNITE-9856:
--
Summary: Add documentation for control.sh --cache config
Key: IGNITE-9856
URL: https://issues.apache.org/jira/browse/IGNITE-9856
Project: Ignite
Issue Type: Improvement
Components: documentation
Reporter: Sergey Antonov
Option {{--cache config}} in {{control.sh}} must be documented.
As reference could be used help message:
{noformat}
List caches configuration:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
--cache config cacheNameRegexPattern [--human-readable]
{noformat}
And output example:
{noformat}
Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
2018 Copyright(C) Apache Software Foundation
User: santonov
ignite-sys-cache: {Name=ignite-sys-cache, Group=null, Dynamic Deployment
ID=fb381836661-93ea1b62-7e2c-449d-82f4-ede849a03e22, System=true,
Mode=REPLICATED, Atomicity Mode=TRANSACTIONAL, Statistic Enabled=false,
Management Enabled=false, On-heap cache enabled=false, Partition Loss
Policy=IGNORE, Query Parallelism=1, Copy On Read=false, Listener
Configurations=null, Load Previous Value=false, Memory Policy Name=sysMemPlc,
Node Filter=o.a.i.configuration.CacheConfiguration$IgniteAllNodesPredicate,
Read From Backup=true, Topology Validator=null, Time To Live Eager Flag=true,
Write Synchronization Mode=FULL_SYNC, Invalidate=false, Affinity
Function=o.a.i.cache.affinity.rendezvous.RendezvousAffinityFunction, Affinity
Backups=2147483647, Affinity Partitions=100, Affinity Exclude Neighbors=false,
Affinity Mapper=o.a.i.i.processors.cache.GridCacheDefaultAffinityKeyMapper,
Rebalance Mode=SYNC, Rebalance Batch Size=524288, Rebalance Timeout=1,
Rebalance Delay=0, Time Between Rebalance Messages=0, Rebalance Batches
Count=2, Rebalance Cache Order=-2, Eviction Policy Enabled=false, Eviction
Policy Factory=null, Eviction Policy Max Size=null, Eviction Filter=null, Near
Cache Enabled=false, Near Start Size=0, Near Eviction Policy Factory=null, Near
Eviction Policy Max Size=null, Default Lock Timeout=0, Query Entities=[], Cache
Interceptor=null, Store Enabled=false, Store Class=null, Store Factory
Class=null, Store Keep Binary=false, Store Read Through=false, Store Write
Through=false, Store Write Coalescing=true, Write-Behind Enabled=false,
Write-Behind Flush Size=10240, Write-Behind Frequency=5000, Write-Behind Flush
Threads Count=1, Write-Behind Batch Size=512, Concurrent Asynchronous
Operations Number=500, Loader Factory Class Name=null, Writer Factory Class
Name=null, Expiry Policy Factory Class
Name=javax.cache.configuration.FactoryBuilder$SingletonFactory, Query Execution
Time Threshold=3000, Query Escaped Names=false, Query SQL Schema=null, Query
SQL functions=null, Query Indexed Types=null, Maximum payload size for offheap
indexes=-1, Query Metrics History Size=0}
test-default: {Name=test-default, Group=null, Dynamic Deployment
ID=fb381836661-93ea1b62-7e2c-449d-82f4-ede849a03e22, System=false,
Mode=PARTITIONED, Atomicity Mode=ATOMIC, Statistic Enabled=false, Management
Enabled=false, On-heap cache enabled=false, Partition Loss Policy=IGNORE, Query
Parallelism=1, Copy On Read=true, Listener Configurations=null, Load Previous
Value=false, Memory Policy Name=null, Node
Filter=o.a.i.configuration.CacheConfiguration$IgniteAllNodesPredicate, Read
From Backup=true, Topology Validator=null, Time To Live Eager Flag=true, Write
Synchronization Mode=PRIMARY_SYNC, Invalidate=false, Affinity
Function=o.a.i.cache.affinity.rendezvous.RendezvousAffinityFunction, Affinity
Backups=0, Affinity Partitions=1024, Affinity Exclude Neighbors=false, Affinity
Mapper=o.a.i.i.processors.cache.CacheDefaultBinaryAffinityKeyMapper, Rebalance
Mode=ASYNC, Rebalance Batch Size=524288, Rebalance Timeout=1, Rebalance
Delay=0, Time Between Rebalance Messages=0, Rebalance Batches Count=2,
Rebalance Cache Order=0, Eviction Policy Enabled=false, Eviction Policy
Factory=null, Eviction Policy Max Size=null, Eviction Filter=null, Near Cache
Enabled=false, Near Start Size=0, Near Eviction Policy Factory=null, Near
Eviction Policy Max Size=null, Default Lock Timeout=0, Query Entities=[], Cache
Interceptor=null, Store Enabled=false, Store Class=null, Store Factory
Class=null, Store Keep Binary=false, Store Read Through=false, Store Write
Through=false, Store Write Coalescing=true, Write-Behind Enabled=false,
Write-Behind Flush Size=10240, Write-Behind Frequency=5000, Write-Behind Flush
Threads Count=1, Write-Behind Batch Size=512, Concurrent Asynchronous
Operations Number=500, Loader Factory Class Name=null, Writer Factory Class
Name=null, Expiry Policy Factory Class
Name=javax.cache.configuration.FactoryBuilder$SingletonFactory, Query
[jira] [Commented] (IGNITE-9853) control.sh show more information about cache configuration
[ https://issues.apache.org/jira/browse/IGNITE-9853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646471#comment-16646471 ] ASF GitHub Bot commented on IGNITE-9853: GitHub user antonovsergey93 opened a pull request: https://github.com/apache/ignite/pull/4956 IGNITE-9853 option control.sh --cache config was added You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9853 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4956.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 #4956 commit 22e35b8c25147fdb8156be4b526bec9dbbcbe532 Author: Sergey Antonov Date: 2018-10-11T11:18:04Z GG-14300 First version commit b8d1015004355fd556921300298cdcde37a475d3 Author: Sergey Antonov Date: 2018-10-11T11:20:47Z GG-14300 Rename classes commit 5413c4f435d2714b050aae4aefa87680a5c8bb87 Author: Sergey Antonov Date: 2018-10-11T13:09:31Z GG-14300 Tests added. commit f5a482eec4f450a40a6820622036b198065e7cfb Author: Sergey Antonov Date: 2018-10-11T13:39:33Z GG-14300 Added missing SerialVersionUID > control.sh show more information about cache configuration > -- > > Key: IGNITE-9853 > URL: https://issues.apache.org/jira/browse/IGNITE-9853 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9855) Curious deadlock on shutdown when being polled over Jetty/REST
Paul Anderson created IGNITE-9855: - Summary: Curious deadlock on shutdown when being polled over Jetty/REST Key: IGNITE-9855 URL: https://issues.apache.org/jira/browse/IGNITE-9855 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.6 Reporter: Paul Anderson have a look at this curious stack trace Attaching to process ID 2375242, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.71-b15 Deadlock Detection: No deadlocks found. Thread 2391956: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=175 (Compiled frame) - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2039 (Compiled frame) - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled frame) - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1127 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) Thread 2391794: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=175 (Compiled frame) - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2039 (Compiled frame) - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled frame) - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1127 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) Thread 2391563: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=175 (Compiled frame) - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2039 (Compiled frame) - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled frame) - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1127 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) Thread 2391461: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=175 (Compiled frame) - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2039 (Compiled frame) - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled frame) - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1127 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) Thread 2391460: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=175 (Compiled frame) - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2039 (Compiled frame) - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled frame) - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1127 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) Thread 2383112: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line
[jira] [Created] (IGNITE-9854) NullPointerException in PageMemoryImpl.refreshOutdatedPages during removing from segCheckpointPages
Ivan Daschinskiy created IGNITE-9854:
Summary: NullPointerException in
PageMemoryImpl.refreshOutdatedPages during removing from segCheckpointPages
Key: IGNITE-9854
URL: https://issues.apache.org/jira/browse/IGNITE-9854
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.6
Reporter: Ivan Daschinskiy
Fix For: 2.8
Because of possibility of concurrently setting segCheckpointPages to null of
segment not under segment writeLock (i.e. in PageMemoryImpl#finishCheckpoint),
NullPointerException is possible. This causes immediate node failure.
Example stack trace is attached (failure during iteration in rebalance
supplier).
{code:java}
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.refreshOutdatedPage(PageMemoryImpl.java:840)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.access$5100(PageMemoryImpl.java:120)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.removePageForReplacement(PageMemoryImpl.java:2175)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.access$900(PageMemoryImpl.java:1841)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:686)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:102)
at
org.apache.ignite.internal.processors.cache.tree.DataRow.(DataRow.java:54)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataRowStore.dataRow(CacheDataRowStore.java:73)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.getRow(CacheDataTree.java:146)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.getRow(CacheDataTree.java:41)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer(BPlusTree.java:4660)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.nextPage(BPlusTree.java:4760)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:4689)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9853) control.sh show more information about cache configuration
Sergey Antonov created IGNITE-9853: -- Summary: control.sh show more information about cache configuration Key: IGNITE-9853 URL: https://issues.apache.org/jira/browse/IGNITE-9853 Project: Ignite Issue Type: Bug Reporter: Sergey Antonov Assignee: Sergey Antonov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9853) control.sh show more information about cache configuration
[ https://issues.apache.org/jira/browse/IGNITE-9853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-9853: --- Issue Type: Improvement (was: Bug) > control.sh show more information about cache configuration > -- > > Key: IGNITE-9853 > URL: https://issues.apache.org/jira/browse/IGNITE-9853 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9852) Create TeamCity suite for Python thin client
[ https://issues.apache.org/jira/browse/IGNITE-9852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-9852: --- Assignee: Peter Ivanov > Create TeamCity suite for Python thin client > > > Key: IGNITE-9852 > URL: https://issues.apache.org/jira/browse/IGNITE-9852 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.7 > > > Implementation of Python client is almost ready (IGNITE-7782). We need to > figure out how to integrate it with TeamCity: > 1) New suite for Python thin client is needed along with required environment > 2) Suite should be able to run tests as described in the documentation [1] > 3) Currently all tests rely on manually started external node. We need to > create a set of scripts (bash?) to start/stop nodes locally just like in > IGNITE-8463 > [1] > https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/readme.html#testing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9852) Create TeamCity suite for Python thin client
Igor Sapego created IGNITE-9852: --- Summary: Create TeamCity suite for Python thin client Key: IGNITE-9852 URL: https://issues.apache.org/jira/browse/IGNITE-9852 Project: Ignite Issue Type: Task Components: thin client Reporter: Igor Sapego Fix For: 2.7 Implementation of Python client is almost ready (IGNITE-7782). We need to figure out how to integrate it with TeamCity: 1) New suite for Python thin client is needed along with required environment 2) Suite should be able to run tests as described in the documentation [1] 3) Currently all tests rely on manually started external node. We need to create a set of scripts (bash?) to start/stop nodes locally just like in IGNITE-8463 [1] https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/readme.html#testing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9620) MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch
[
https://issues.apache.org/jira/browse/IGNITE-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646414#comment-16646414
]
Vladimir Ozerov commented on IGNITE-9620:
-
MVCC Queries - OK
Left: ODBC test.
> MVCC: select throwing `Transaction is already completed` exception after
> mvcc missmatch
>
>
> Key: IGNITE-9620
> URL: https://issues.apache.org/jira/browse/IGNITE-9620
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> Using sqlline with autoCommit=false
> {code}
> switch to first user
> - select * from test:
> result: [[1, 1, test_1]]
> switch to second user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> - commit:
> - select * from test:
> result: [[1, 1, test_1], [2, 2, test_2]]
> switch to first user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> error: Mvcc version mismatch.
> - select * from test
> {code}
> During last select throwing exception
> {code}
> 0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
> select * from test;
> [1;31mError: Transaction is already completed. (state=25000,code=0)[m
> java.sql.SQLException: Transaction is already completed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Exception in node logs:
> {code}
> [17:44:36,234][SEVERE][jdbc-request-handler-worker-#61][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select * from test,
> args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:623)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:780)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:761)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:744)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1731)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:2521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2074)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Works for any query which is throwing mvcc missmatch exception
> After commit select query works again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9446) MVCC: Races in Vacuum worker on cache stop.
[ https://issues.apache.org/jira/browse/IGNITE-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646412#comment-16646412 ] ASF GitHub Bot commented on IGNITE-9446: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4940 > MVCC: Races in Vacuum worker on cache stop. > --- > > Key: IGNITE-9446 > URL: https://issues.apache.org/jira/browse/IGNITE-9446 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Minor > Fix For: 2.7 > > > For now, partition store BTree can be destroyed while vacuum in progress > regardless partition reservations which causes VacuumTask failure without > negative side effect (such as worker failure or any hanging). > VacuumTask successfully catch and log the exception, but further check in > afterTest() method reports vacuum failure. > For now vacuum is disabled for this test. > We should fix vacuum failure properly in that case and fix > CacheMvccPartitionedSqlQueriesTest.testDistributedJoinSimple() test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9833) Update Master Trends metrics: add total run time (duration), number of runs
[
https://issues.apache.org/jira/browse/IGNITE-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646407#comment-16646407
]
ASF GitHub Bot commented on IGNITE-9833:
asfgit closed pull request #34: IGNITE-9833 Update Master Trends metrics
URL: https://github.com/apache/ignite-teamcity-bot/pull/34
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/BuildStatisticsSummary.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/BuildStatisticsSummary.java
index 8a428a5..d4a7bf6 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/BuildStatisticsSummary.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/BuildStatisticsSummary.java
@@ -64,8 +64,8 @@
/** List of problem occurrences. */
private List problemOccurrenceList;
-/** Duration printable. */
-public String durationPrintable;
+/** Duration (seconds). */
+public long duration;
/** Short build run result (without snapshot-dependencies printable
result). */
public Map totalProblems;
@@ -95,8 +95,7 @@ public void initialize(@Nonnull final ITeamcity teamcity) {
testOccurrences = build.testOccurrences;
-durationPrintable = TimeUtil
-.millisToDurationPrintable(build.getFinishDate().getTime() -
build.getStartDate().getTime());
+duration = (build.getFinishDate().getTime() -
build.getStartDate().getTime()) / 1000;
List snapshotDependencies =
getSnapshotDependencies(teamcity, build);
@@ -228,13 +227,13 @@ private long getOomeProblemCount(String buildTypeId) {
Objects.equals(startDate, that.startDate) &&
Objects.equals(testOccurrences, that.testOccurrences) &&
Objects.equals(problemOccurrenceList, that.problemOccurrenceList)
&&
-Objects.equals(durationPrintable, that.durationPrintable) &&
+Objects.equals(duration, that.duration) &&
Objects.equals(totalProblems, that.totalProblems);
}
/** {@inheritDoc} */
@Override public int hashCode() {
return Objects.hash(buildId, startDate, testOccurrences,
problemOccurrenceList,
-durationPrintable, totalProblems, isFakeStub);
+duration, totalProblems, isFakeStub);
}
}
diff --git a/ignite-tc-helper-web/src/main/webapp/comparison.html
b/ignite-tc-helper-web/src/main/webapp/comparison.html
index bc24084..fd62a47 100644
--- a/ignite-tc-helper-web/src/main/webapp/comparison.html
+++ b/ignite-tc-helper-web/src/main/webapp/comparison.html
@@ -23,18 +23,27 @@
+
+DURATION
+
+
+
+
+
+
+
+
-
FEATURES
-TESTS
+TESTS
COUNT
-
-
+
+
@@ -43,8 +52,8 @@
PASSED
-
-
+
+
@@ -53,8 +62,8 @@
FAILED
-
-
+
+
@@ -63,8 +72,8 @@
IGNORED
-
-
+
+
@@ -73,19 +82,19 @@
MUTED
-
-
+
+
-PROBLEMS
+PROBLEMS
TOTAL
-
-
+
+
@@ -93,8 +102,8 @@
EXECUTION TIMEOUT
-
-
+
+
@@ -103,8 +112,8 @@
JVM CRASH
-
-
+
+
@@ -113,8 +122,8 @@
OOME
-
-
+
+
@@ -123,26 +132,62 @@
EXIT CODE
-
-
+
+
+OTHER METRICS
+
+RUNS COUNT
+
+
+
+
[jira] [Commented] (IGNITE-9558) Avoid changing AffinityTopologyVersion on client connect when possible
[ https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646395#comment-16646395 ] Alexey Goncharuk commented on IGNITE-9558: -- A few comments for preliminary review: 1) In GridDhtCacheAdapter#needRemap and IgniteTxHandler#needRemap, we need to track partitions which assignments we already checked and skip the check for already checked partitions. 2) Missing javadoc in added method of GridCacheMessage > Avoid changing AffinityTopologyVersion on client connect when possible > -- > > Key: IGNITE-9558 > URL: https://issues.apache.org/jira/browse/IGNITE-9558 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Assignee: Ilya Lantukh >Priority: Major > > Currently a client join event changes discovery topology version which, in > turn, changes AffinityTopologyVersion. > When a client maps transaction on new AffinityTopologyVersion, corresponding > message is not processed on remote node until remote node receives the > corresponding discovery event. If discovery event delivery is delayed for > some reason, this will result in transaction stalls on client joins. > Since the client node does not change partition affinity, we can safely map > transactions on the previous topology version and do not change the affinity > topology version at all. > Some cases need special care and probably do not qualify for this > optimization, such as when client has near cache or client hosts partition > for REPLICATED cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9410) MVCC: add support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-9410: --- Assignee: Igor Sapego > MVCC: add support to thin clients > - > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Task > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8 > > > Currently only ODBC and JDBC drivers support transactions. We need to add > transactional API to .NET, Java, CPP, NodeJS and Python clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8718) Documentation about using of the C++ BinaryWriter/BinaryReader should be updated
[
https://issues.apache.org/jira/browse/IGNITE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Budnikov reassigned IGNITE-8718:
--
Assignee: Igor Sapego (was: Artem Budnikov)
> Documentation about using of the C++ BinaryWriter/BinaryReader should be
> updated
>
>
> Key: IGNITE-8718
> URL: https://issues.apache.org/jira/browse/IGNITE-8718
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Igor Sapego
>Priority: Major
> Labels: c++
> Fix For: 2.7
>
>
> The usage that should be documented:
> 1)In case if you get some writer from BinaryWriter then you started writing
> session. Until method close will not be called for this writer you can't get
> another writer.
>
> For example, next code isn't correct:
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session - error
> {code}
> Should be:
>
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> //do something
> field1Writer.Close() //here you end writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session
> //do something
> field2Writer.Close() //here you end another writing session
> {code}
>
> 2) In case if you get some reader from BinaryWriter then you started reading
> session. Until something will not be read from this reader you can't get
> another reader.
>
> For example, next code isn't correct:
>
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session - error
> {code}
> Should be for example:
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> ...
> field1Reader.GetNext(key, val); //reading done
> ...
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session
> ...
> field2Reader.GetNext(key, val); //reading done
> ...{code}
>
>
>
> In the case of the writer, it looks like expected. In case of the reader, it
> looks a little bit confusing.
>
> These two behaviors should be described in the documentation as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8718) Documentation about using of the C++ BinaryWriter/BinaryReader should be updated
[
https://issues.apache.org/jira/browse/IGNITE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646387#comment-16646387
]
Artem Budnikov edited comment on IGNITE-8718 at 10/11/18 12:54 PM:
---
I think this should be documented in the API docs.
[~isapego] could you please have a look?
was (Author: artem budnikov):
I think this should be documented in the API docs.
> Documentation about using of the C++ BinaryWriter/BinaryReader should be
> updated
>
>
> Key: IGNITE-8718
> URL: https://issues.apache.org/jira/browse/IGNITE-8718
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Artem Budnikov
>Priority: Major
> Labels: c++
> Fix For: 2.7
>
>
> The usage that should be documented:
> 1)In case if you get some writer from BinaryWriter then you started writing
> session. Until method close will not be called for this writer you can't get
> another writer.
>
> For example, next code isn't correct:
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session - error
> {code}
> Should be:
>
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> //do something
> field1Writer.Close() //here you end writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session
> //do something
> field2Writer.Close() //here you end another writing session
> {code}
>
> 2) In case if you get some reader from BinaryWriter then you started reading
> session. Until something will not be read from this reader you can't get
> another reader.
>
> For example, next code isn't correct:
>
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session - error
> {code}
> Should be for example:
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> ...
> field1Reader.GetNext(key, val); //reading done
> ...
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session
> ...
> field2Reader.GetNext(key, val); //reading done
> ...{code}
>
>
>
> In the case of the writer, it looks like expected. In case of the reader, it
> looks a little bit confusing.
>
> These two behaviors should be described in the documentation as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8718) Documentation about using of the C++ BinaryWriter/BinaryReader should be updated
[
https://issues.apache.org/jira/browse/IGNITE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646387#comment-16646387
]
Artem Budnikov commented on IGNITE-8718:
I think this should be documented in the API docs.
> Documentation about using of the C++ BinaryWriter/BinaryReader should be
> updated
>
>
> Key: IGNITE-8718
> URL: https://issues.apache.org/jira/browse/IGNITE-8718
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Artem Budnikov
>Priority: Major
> Labels: c++
> Fix For: 2.7
>
>
> The usage that should be documented:
> 1)In case if you get some writer from BinaryWriter then you started writing
> session. Until method close will not be called for this writer you can't get
> another writer.
>
> For example, next code isn't correct:
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session - error
> {code}
> Should be:
>
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> //do something
> field1Writer.Close() //here you end writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session
> //do something
> field2Writer.Close() //here you end another writing session
> {code}
>
> 2) In case if you get some reader from BinaryWriter then you started reading
> session. Until something will not be read from this reader you can't get
> another reader.
>
> For example, next code isn't correct:
>
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session - error
> {code}
> Should be for example:
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> ...
> field1Reader.GetNext(key, val); //reading done
> ...
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session
> ...
> field2Reader.GetNext(key, val); //reading done
> ...{code}
>
>
>
> In the case of the writer, it looks like expected. In case of the reader, it
> looks a little bit confusing.
>
> These two behaviors should be described in the documentation as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9696) SQL: Remove documentation about bad IN performance
[ https://issues.apache.org/jira/browse/IGNITE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646386#comment-16646386 ] Artem Budnikov edited comment on IGNITE-9696 at 10/11/18 12:50 PM: --- I remove the section: [https://dash.readme.io/project/apacheignite-sql/v2.6/docs/performance-and-debugging-27] The page will be published with Ignite 2.7 release. was (Author: artem budnikov): I remove the section: [https://dash.readme.io/project/apacheignite-sql/v2.6/docs/performance-and-debugging-27] > SQL: Remove documentation about bad IN performance > -- > > Key: IGNITE-9696 > URL: https://issues.apache.org/jira/browse/IGNITE-9696 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > As IGNITE-4150 is merged, we should no longer have problems with IN > statement. Let's remove it. > See > [https://apacheignite-sql.readme.io/docs/performance-and-debugging#sql-performance-and-usability-considerations] > , point 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9696) SQL: Remove documentation about bad IN performance
[ https://issues.apache.org/jira/browse/IGNITE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov resolved IGNITE-9696. Resolution: Fixed > SQL: Remove documentation about bad IN performance > -- > > Key: IGNITE-9696 > URL: https://issues.apache.org/jira/browse/IGNITE-9696 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > As IGNITE-4150 is merged, we should no longer have problems with IN > statement. Let's remove it. > See > [https://apacheignite-sql.readme.io/docs/performance-and-debugging#sql-performance-and-usability-considerations] > , point 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9696) SQL: Remove documentation about bad IN performance
[ https://issues.apache.org/jira/browse/IGNITE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646386#comment-16646386 ] Artem Budnikov commented on IGNITE-9696: I remove the section: [https://dash.readme.io/project/apacheignite-sql/v2.6/docs/performance-and-debugging-27] > SQL: Remove documentation about bad IN performance > -- > > Key: IGNITE-9696 > URL: https://issues.apache.org/jira/browse/IGNITE-9696 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > As IGNITE-4150 is merged, we should no longer have problems with IN > statement. Let's remove it. > See > [https://apacheignite-sql.readme.io/docs/performance-and-debugging#sql-performance-and-usability-considerations] > , point 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9791) Document: SQL query lazy mode is used by default
[
https://issues.apache.org/jira/browse/IGNITE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646368#comment-16646368
]
Artem Budnikov edited comment on IGNITE-9791 at 10/11/18 12:45 PM:
---
I changed the default value for the lazy parameter on the JDBC/ODBC Driver
pages:
[https://dash.readme.io/project/apacheignite-sql/v2.6/docs/jdbc-driver-26]
[https://dash.readme.io/project/apacheignite-sql/v2.6/docs/connection-string-and-dsn-27]
I think this should be enough.
was (Author: artem budnikov):
I changed the default value for the lazy parameter on the JDBC/ODBC Driver
pages:
[https://dash.readme.io/project/apacheignite-sql/v2.6/docs/jdbc-driver-26]
[https://dash.readme.io/project/apacheignite-sql/v2.6/docs/connection-string-and-dsn-27]
I think this should be is enough.
> Document: SQL query lazy mode is used by default
>
>
> Key: IGNITE-9791
> URL: https://issues.apache.org/jira/browse/IGNITE-9791
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document changes in 'lazy' mode SQL query execution:
> - since Ignite 2.7 the lazy mode is ON by default and user should use
> explicit {{lazy=false}} to disable it.
> - but for JDBC, ODBC drivers and thin clients with version less than 2.7 lazy
> mode is false by default because the the default value is kept on the client
> side too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9620) MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch
[
https://issues.apache.org/jira/browse/IGNITE-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-9620:
---
Assignee: Igor Sapego (was: Vladimir Ozerov)
> MVCC: select throwing `Transaction is already completed` exception after
> mvcc missmatch
>
>
> Key: IGNITE-9620
> URL: https://issues.apache.org/jira/browse/IGNITE-9620
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> Using sqlline with autoCommit=false
> {code}
> switch to first user
> - select * from test:
> result: [[1, 1, test_1]]
> switch to second user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> - commit:
> - select * from test:
> result: [[1, 1, test_1], [2, 2, test_2]]
> switch to first user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> error: Mvcc version mismatch.
> - select * from test
> {code}
> During last select throwing exception
> {code}
> 0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
> select * from test;
> [1;31mError: Transaction is already completed. (state=25000,code=0)[m
> java.sql.SQLException: Transaction is already completed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Exception in node logs:
> {code}
> [17:44:36,234][SEVERE][jdbc-request-handler-worker-#61][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select * from test,
> args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:623)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:780)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:761)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:744)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1731)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:2521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2074)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Works for any query which is throwing mvcc missmatch exception
> After commit select query works again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9345) Document custom SQL schemas
[
https://issues.apache.org/jira/browse/IGNITE-9345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646379#comment-16646379
]
Artem Budnikov commented on IGNITE-9345:
I also referenced this page from the CREATE TABLE page:
https://apacheignite-sql.readme.io/v2.6/docs/create-table-27
> Document custom SQL schemas
> ---
>
> Key: IGNITE-9345
> URL: https://issues.apache.org/jira/browse/IGNITE-9345
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.7
>
>
> Key highlights:
> 1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
> \{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
> from docs (if there is such paragraph)
> 2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
> schemas with provided names.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9620) MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch
[
https://issues.apache.org/jira/browse/IGNITE-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646373#comment-16646373
]
Vladimir Ozerov commented on IGNITE-9620:
-
MVCC Cache - OK
> MVCC: select throwing `Transaction is already completed` exception after
> mvcc missmatch
>
>
> Key: IGNITE-9620
> URL: https://issues.apache.org/jira/browse/IGNITE-9620
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Using sqlline with autoCommit=false
> {code}
> switch to first user
> - select * from test:
> result: [[1, 1, test_1]]
> switch to second user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> - commit:
> - select * from test:
> result: [[1, 1, test_1], [2, 2, test_2]]
> switch to first user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> error: Mvcc version mismatch.
> - select * from test
> {code}
> During last select throwing exception
> {code}
> 0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
> select * from test;
> [1;31mError: Transaction is already completed. (state=25000,code=0)[m
> java.sql.SQLException: Transaction is already completed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Exception in node logs:
> {code}
> [17:44:36,234][SEVERE][jdbc-request-handler-worker-#61][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select * from test,
> args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:623)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:780)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:761)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:744)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1731)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:2521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2074)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Works for any query which is throwing mvcc missmatch exception
> After commit select query works again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9791) Document: SQL query lazy mode is used by default
[
https://issues.apache.org/jira/browse/IGNITE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646368#comment-16646368
]
Artem Budnikov commented on IGNITE-9791:
I changed the default value for the lazy parameter on the JDBC/ODBC Driver
pages:
[https://dash.readme.io/project/apacheignite-sql/v2.6/docs/jdbc-driver-26]
[https://dash.readme.io/project/apacheignite-sql/v2.6/docs/connection-string-and-dsn-27]
I think this should be is enough.
> Document: SQL query lazy mode is used by default
>
>
> Key: IGNITE-9791
> URL: https://issues.apache.org/jira/browse/IGNITE-9791
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document changes in 'lazy' mode SQL query execution:
> - since Ignite 2.7 the lazy mode is ON by default and user should use
> explicit {{lazy=false}} to disable it.
> - but for JDBC, ODBC drivers and thin clients with version less than 2.7 lazy
> mode is false by default because the the default value is kept on the client
> side too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9583) PHP thin: php directory should be included in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646352#comment-16646352
]
ASF GitHub Bot commented on IGNITE-9583:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4951
> PHP thin: php directory should be included in binary release
>
>
> Key: IGNITE-9583
> URL: https://issues.apache.org/jira/browse/IGNITE-9583
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Assignee: Peter Ivanov
>Priority: Blocker
> Labels: php
> Fix For: 2.7
>
>
> Currently, php directory is not generated by the {{maven install}} command.
> Need to add appropriate copy steps to {{assembly/release-fabric-base.xml}}
> file.
> The following components should be copied:
> {noformat}
> ignite/modules/platforms/php/composer.json
> ignite/modules/platforms/php/src
> ignite/modules/platforms/php/examples
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9851) Share local node statistics between all nodes
Yury Gerzhedovich created IGNITE-9851: - Summary: Share local node statistics between all nodes Key: IGNITE-9851 URL: https://issues.apache.org/jira/browse/IGNITE-9851 Project: Ignite Issue Type: Task Components: sql Reporter: Yury Gerzhedovich Assignee: Yury Gerzhedovich Each node contains it's local node statistics. User want to know cluster wide statistics for a caches and indexes. Need to share local node statistics between all nodes and expose interface to derive the statistics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
[
https://issues.apache.org/jira/browse/IGNITE-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Stelmak reassigned IGNITE-9840:
--
Assignee: Alexey Stelmak
> Possible deadlock on transactional future on client node in case of network
> problems or long GC pauses
> --
>
> Key: IGNITE-9840
> URL: https://issues.apache.org/jira/browse/IGNITE-9840
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Stelmak
>Priority: Critical
> Fix For: 2.8
>
>
> Steps to reproduce:
> 1)Start the server node with next timeouts. DefaultTxTimeout should be
> greater than other:
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> On the server side you should create a cache with next parameters:
>
>
> {code:java}
>
>
>
>
>
>
> {code}
> 2)After that start the client with the next code:
> {code:java}
> IgniteCache cache = ignite.getOrCreateCache("CACHE");
> try (Transaction tx = ignite.transactions().txStart()) {
> cache.put("Key", new Object());
> System.out.println("Stop me");
> //here we will get long GC pause on server side
> Thread.sleep(1);
> // Commit the transaction.
> tx.commitAsync().get();
> }
> {code}
>
> On step "Stop me" you should suspend all the thread on the server side to
> emulate the networking problem or long GC pause on the server side.
> Finally, you will face in client node next:
> {code:java}
> [2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
> heartbeatTs=1539179057570]]]
> {code}
> Also, the similar issue could be reproduced in 2.4. In both cases looks like
> we have a deadlock during trying to display the TxEntryValueHolder. Looks
> like this values are already used by the transaction with long
> DefaultTxTimeout .
> {code:java}
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
> at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
> at
> org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
> ...{code}
> On the client side, it could be looked like a hanging transaction because we
> waiting on:
> {code:java}
> tx.commitAsync().get();{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
