[jira] [Commented] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
[ https://issues.apache.org/jira/browse/IGNITE-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034177#comment-17034177 ] Stanilovsky Evgeny commented on IGNITE-11949: - Seems correct, [~Artukhov] may be you check here too ? thanks ! > Yardstick benchmarks for WAL page snapshot compression > -- > > Key: IGNITE-11949 > URL: https://issues.apache.org/jira/browse/IGNITE-11949 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-20, yardstick > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > WAL page snapshots compression (implemented by IGNITE-11336) can be enabled > by modifying config.xml file. It will be better to configure benchmarks by > command line options. > Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12582) It is needed to set used cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034144#comment-17034144 ] Ivan Pavlukhin commented on IGNITE-12582: - [~schernolyas], [~mstepachev], it looks like that new test classes were not added to any test suite. All tests must be added to a test suite in order to run them in CI. I suppose Maksim can help to choose a proper suite. Maksim, please do a code review carefully. > It is needed to set used cache for Spring Data dynamically > -- > > Key: IGNITE-12582 > URL: https://issues.apache.org/jira/browse/IGNITE-12582 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.7.6 >Reporter: Sergey Chernolyas >Assignee: Sergey Chernolyas >Priority: Major > > Hi! > My project needs to configure used cache by property, like > ""[spring.data|http://spring.data/].mongodb.uri: > mongodb://:@:/" from Spring Data for > MongoDB. Now, I can set cache for particular repository by annotation > "RepositoryConfig" only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12582) It is needed to set used cache for Spring Data dynamically
[
https://issues.apache.org/jira/browse/IGNITE-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033881#comment-17033881
]
Ignite TC Bot commented on IGNITE-12582:
{panel:title=Branch: [pull/7381/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5037403&buildTypeId=IgniteTests24Java8_RunAll]
> It is needed to set used cache for Spring Data dynamically
> --
>
> Key: IGNITE-12582
> URL: https://issues.apache.org/jira/browse/IGNITE-12582
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.7.6
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Major
>
> Hi!
> My project needs to configure used cache by property, like
> ""[spring.data|http://spring.data/].mongodb.uri:
> mongodb://:@:/" from Spring Data for
> MongoDB. Now, I can set cache for particular repository by annotation
> "RepositoryConfig" only.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10698) Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
[
https://issues.apache.org/jira/browse/IGNITE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033829#comment-17033829
]
Ivan Pavlukhin edited comment on IGNITE-10698 at 2/10/20 6:16 PM:
--
[~agoncharuk], [~agura], as long we have a patch, I suppose we should set _fix
version_ to 2.9.
was (Author: pavlukhin):
[~agoncharuk], [~agura], as long we have a patch, I suppose should set _fix
version_ to 2.9.
> Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
> ---
>
> Key: IGNITE-10698
> URL: https://issues.apache.org/jira/browse/IGNITE-10698
> Project: Ignite
> Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Lev Kiselev
>Priority: Major
> Labels: newbie, pull-request-available, usability
> Fix For: 3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> @MXBeanDescription("Returns or kills transactions matching the filter
> conditions.")
> @MXBeanParametersNames(
> {
> "minDuration",
> "minSize",
> "prj",
> "consistentIds",
> "xid",
> "lbRegex",
> "limit",
> "order",
> "detailed",
> "kill"
> }
> )
> @MXBeanParametersDescriptions(
> {
> "Minimum duration (seconds).",
> "Minimum size.",
> "Projection (servers|clients).",
> "Consistent ids (separated by comma).",
> "Transaction XID.",
> "Label regexp.",
> "Limit a number of transactions collected on each node.",
> "Order by DURATION|SIZE.",
> "Show detailed description, otherwise only count.",
> "Kill matching transactions (be careful)."
> }
> )
> {noformat}
> Above looks pretty ugly and is very error prone due to messing names and
> descr order or number of strings.
> I would suggest to introduce individual parameters annotations and get them
> via mtd.getParamterAnnotations() at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10698) Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
[
https://issues.apache.org/jira/browse/IGNITE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033829#comment-17033829
]
Ivan Pavlukhin commented on IGNITE-10698:
-
[~agoncharuk], [~agura], as long we have a patch, I suppose should set _fix
version_ to 2.9.
> Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
> ---
>
> Key: IGNITE-10698
> URL: https://issues.apache.org/jira/browse/IGNITE-10698
> Project: Ignite
> Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Lev Kiselev
>Priority: Major
> Labels: newbie, pull-request-available, usability
> Fix For: 3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> @MXBeanDescription("Returns or kills transactions matching the filter
> conditions.")
> @MXBeanParametersNames(
> {
> "minDuration",
> "minSize",
> "prj",
> "consistentIds",
> "xid",
> "lbRegex",
> "limit",
> "order",
> "detailed",
> "kill"
> }
> )
> @MXBeanParametersDescriptions(
> {
> "Minimum duration (seconds).",
> "Minimum size.",
> "Projection (servers|clients).",
> "Consistent ids (separated by comma).",
> "Transaction XID.",
> "Label regexp.",
> "Limit a number of transactions collected on each node.",
> "Order by DURATION|SIZE.",
> "Show detailed description, otherwise only count.",
> "Kill matching transactions (be careful)."
> }
> )
> {noformat}
> Above looks pretty ugly and is very error prone due to messing names and
> descr order or number of strings.
> I would suggest to introduce individual parameters annotations and get them
> via mtd.getParamterAnnotations() at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[
https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033794#comment-17033794
]
Andrey N. Gura commented on IGNITE-6804:
[~ilyak] It seems you missed the following comment:
{quote}
@alamar It seems we call checkKeysOrdered before syncOp method. But implicit
transactions always start in syncOp method. So curTxDeadlockDetecting will
always return false for any implicit transaction.
{quote}
> Print a warning if HashMap is passed into bulk update operations
>
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: usability
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap,
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element.
> However, we should make sure that we only print that warning once and not
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
[ https://issues.apache.org/jira/browse/IGNITE-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033765#comment-17033765 ] Stanilovsky Evgeny commented on IGNITE-11949: - will check it tomorrow. > Yardstick benchmarks for WAL page snapshot compression > -- > > Key: IGNITE-11949 > URL: https://issues.apache.org/jira/browse/IGNITE-11949 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-20, yardstick > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > WAL page snapshots compression (implemented by IGNITE-11336) can be enabled > by modifying config.xml file. It will be better to configure benchmarks by > command line options. > Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12656) Cleanup GridCacheProcessor from functionality not related to its responsibility
[
https://issues.apache.org/jira/browse/IGNITE-12656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033748#comment-17033748
]
Ivan Pavlukhin commented on IGNITE-12656:
-
[~slava.koptilin], would be great to define {{GridCacheProcessor}}
responcibilities e.g. in javadocs. Sincerely existing desing seems very
compicated to me. Would be totally great to improve it.
> Cleanup GridCacheProcessor from functionality not related to its
> responsibility
> ---
>
> Key: IGNITE-12656
> URL: https://issues.apache.org/jira/browse/IGNITE-12656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> Currently, we have a couple of functionality in GridCacheProcessor not
> directly related to its responsibility, like:
> * initQueryStructuresForNotStartedCache
> * addRemovedItemsCleanupTask
> * setTxOwnerDumpRequestsAllowed
> * longTransactionTimeDumpThreshold
> * transactionTimeDumpSamplesCoefficient
> * longTransactionTimeDumpSamplesPerSecondLimit
> * broadcastToNodesSupportingFeature
> * LocalAffinityFunction
> * RemovedItemsCleanupTask
> * TxTimeoutOnPartitionMapExchangeChangeFuture
> * enableRebalance
> We need to move them to the right places and make GridCacheProcessor code
> cleaner.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12656) Cleanup GridCacheProcessor from functionality not related to its responsibility
Vyacheslav Koptilin created IGNITE-12656: Summary: Cleanup GridCacheProcessor from functionality not related to its responsibility Key: IGNITE-12656 URL: https://issues.apache.org/jira/browse/IGNITE-12656 Project: Ignite Issue Type: Improvement Affects Versions: 2.8 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.9 Currently, we have a couple of functionality in GridCacheProcessor not directly related to its responsibility, like: * initQueryStructuresForNotStartedCache * addRemovedItemsCleanupTask * setTxOwnerDumpRequestsAllowed * longTransactionTimeDumpThreshold * transactionTimeDumpSamplesCoefficient * longTransactionTimeDumpSamplesPerSecondLimit * broadcastToNodesSupportingFeature * LocalAffinityFunction * RemovedItemsCleanupTask * TxTimeoutOnPartitionMapExchangeChangeFuture * enableRebalance We need to move them to the right places and make GridCacheProcessor code cleaner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12655) Remove setting explicit page size in IgnitePdsDestroyCacheAbstractTest
Alexey Scherbakov created IGNITE-12655: -- Summary: Remove setting explicit page size in IgnitePdsDestroyCacheAbstractTest Key: IGNITE-12655 URL: https://issues.apache.org/jira/browse/IGNITE-12655 Project: Ignite Issue Type: Bug Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Fix For: 2.9 It causes test failures in IgnitePdsCompressionTestSuite: org.apache.ignite.IgniteCheckedException: Page size (now configured to 1024 bytes) must be at least 2 times larger than the underlying storage block size (detected to be 4096 bytes at '/opt/buildagent/work/7bc1c54bc719b67c/work/db') for page compression. at org.apache.ignite.internal.processors.cache.persistence.IgnitePdsDestroyCacheTest.testDestroyCaches(IgnitePdsDestroyCacheTest.java:46) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12582) It is needed to set used cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033691#comment-17033691 ] Stepachev Maksim commented on IGNITE-12582: --- LGTM, Please add the visa. [~irakov] Please merge it after the visa. > It is needed to set used cache for Spring Data dynamically > -- > > Key: IGNITE-12582 > URL: https://issues.apache.org/jira/browse/IGNITE-12582 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.7.6 >Reporter: Sergey Chernolyas >Assignee: Sergey Chernolyas >Priority: Major > > Hi! > My project needs to configure used cache by property, like > ""[spring.data|http://spring.data/].mongodb.uri: > mongodb://:@:/" from Spring Data for > MongoDB. Now, I can set cache for particular repository by annotation > "RepositoryConfig" only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12654) Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge number of eviction callbacks
[
https://issues.apache.org/jira/browse/IGNITE-12654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12654:
-
Description:
Example of heap dump:
||Class Name||Shallow Heap||Retained Heap||
|top
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
@ 0x809f03d0|88|1 381 118 968|
|grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
0x809f04c8|96|1 381 121 912|
|locParts java.util.concurrent.atomic.AtomicReferenceArray @ 0x81656c30|16|1
380 925 496|
|array java.lang.Object[1024] @ 0x81656c40|4 112|1 380 925 480|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f2bcd8|24|318 622 384|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f28d90|96|318 618 624|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5ed4ac8|24|318 618 576|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f2e7f8|24|318 618 528|
|grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
0x809f04c8|96|1 381 121 912|
|state org.apache.ignite.internal.util.future.GridFutureAdapter$Node @
0xe8ed4cd0|24|318 618 624|
|val
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl$$Lambda$58
@ 0xe8ed4cb8|24|24|
|arg$1
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
@ 0x809f03d0|88|1 381 118 968|
The number of {{GridFutureAdapter$Node}}'s and
{{GridDhtPartitionTopologyImpl$$Lambda$58}}'s looks weird. It seems that the
following code is the root cause:
{code:java|title=GridDhtPartitionTopologyImpl.java}
/**
* Finds local partitions which don't belong to affinity and runs eviction
process for such partitions.
*
* @param updateSeq Update sequence.
* @param aff Affinity assignments.
* @return {@code True} if there are local partitions need to be evicted.
*/
private boolean checkEvictions(long updateSeq, AffinityAssignment aff) {
...
// After all rents are finished resend partitions.
if (!rentingFutures.isEmpty()) {
final AtomicInteger rentingPartitions = new
AtomicInteger(rentingFutures.size());
for (IgniteInternalFuture rentingFuture : rentingFutures) {
rentingFuture.listen(f -> {
int remaining = rentingPartitions.decrementAndGet();
if (remaining == 0) {
lock.writeLock().lock();
try {
this.updateSeq.incrementAndGet();
if (log.isDebugEnabled())
log.debug("Partitions have been scheduled to
resend [reason=" +
"Evictions are done [grp=" +
grp.cacheOrGroupName() + "]");
ctx.exchange().scheduleResendPartitions();
}
finally {
lock.writeLock().unlock();
}
}
});
}
}
return hasEvictedPartitions;
}
{code}
was:
Example of heap dump:
||Class Name||Shallow Heap||Retained Heap||
|top
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
@ 0x809f03d0|88|1 381 118 968|
|grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
0x809f04c8|96|1 381 121 912|
|locParts java.util.concurrent.atomic.AtomicReferenceArray @ 0x81656c30|16|1
380 925 496|
|array java.lang.Object[1024] @ 0x81656c40|4 112|1 380 925 480|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f2bcd8|24|318 622 384|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f28d90|96|318 618 624|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5ed4ac8|24|318 618 576|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f2e7f8|24|318 618 528|
|grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
0x809f04c8|96|1 381 121 912|
|state org.apache.ignite.internal.util.future.GridFutureAdapter$Node @
0xe8ed4cd0|24|318 618 624|
|val
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl$$Lambda$58
@ 0xe8ed4cb8|24|24|
|arg$1
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
@ 0x809f03d0|88|1 381 118 968|
The number of {{GridFutureAdapter$Node}}'s and
{{GridDhtPartitionTopologyImpl$$Lambda$58}}'s looks weird. It seems that the
following code is the root cause:
{code:java|GridDhtPartitionTopologyImpl.java}
/**
* Finds local partitions which don't belong to affinity and runs eviction
process for such
[jira] [Updated] (IGNITE-12654) Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge number of eviction callbacks
[
https://issues.apache.org/jira/browse/IGNITE-12654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12654:
-
Description:
Example of heap dump:
||Class Name||Shallow Heap||Retained Heap||
|top
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
@ 0x809f03d0|88|1 381 118 968|
|grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
0x809f04c8|96|1 381 121 912|
|locParts java.util.concurrent.atomic.AtomicReferenceArray @ 0x81656c30|16|1
380 925 496|
|array java.lang.Object[1024] @ 0x81656c40|4 112|1 380 925 480|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f2bcd8|24|318 622 384|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f28d90|96|318 618 624|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5ed4ac8|24|318 618 576|
|org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
@ 0xb5f2e7f8|24|318 618 528|
|grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
0x809f04c8|96|1 381 121 912|
|state org.apache.ignite.internal.util.future.GridFutureAdapter$Node @
0xe8ed4cd0|24|318 618 624|
|val
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl$$Lambda$58
@ 0xe8ed4cb8|24|24|
|arg$1
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
@ 0x809f03d0|88|1 381 118 968|
The number of {{GridFutureAdapter$Node}}'s and
{{GridDhtPartitionTopologyImpl$$Lambda$58}}'s looks weird. It seems that the
following code is the root cause:
{code:java|GridDhtPartitionTopologyImpl.java}
/**
* Finds local partitions which don't belong to affinity and runs eviction
process for such partitions.
*
* @param updateSeq Update sequence.
* @param aff Affinity assignments.
* @return {@code True} if there are local partitions need to be evicted.
*/
private boolean checkEvictions(long updateSeq, AffinityAssignment aff) {
...
// After all rents are finished resend partitions.
if (!rentingFutures.isEmpty()) {
final AtomicInteger rentingPartitions = new
AtomicInteger(rentingFutures.size());
for (IgniteInternalFuture rentingFuture : rentingFutures) {
rentingFuture.listen(f -> {
int remaining = rentingPartitions.decrementAndGet();
if (remaining == 0) {
lock.writeLock().lock();
try {
this.updateSeq.incrementAndGet();
if (log.isDebugEnabled())
log.debug("Partitions have been scheduled to
resend [reason=" +
"Evictions are done [grp=" +
grp.cacheOrGroupName() + "]");
ctx.exchange().scheduleResendPartitions();
}
finally {
lock.writeLock().unlock();
}
}
});
}
}
return hasEvictedPartitions;
}
{code}
was:
||Heading 1||Heading 2||
|\|text\|test\|text|Col A2|
> Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge
> number of eviction callbacks
> -
>
> Key: IGNITE-12654
> URL: https://issues.apache.org/jira/browse/IGNITE-12654
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> Example of heap dump:
> ||Class Name||Shallow Heap||Retained Heap||
> |top
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl
> @ 0x809f03d0|88|1 381 118 968|
> |grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
> 0x809f04c8|96|1 381 121 912|
> |locParts java.util.concurrent.atomic.AtomicReferenceArray @ 0x81656c30|16|1
> 380 925 496|
> |array java.lang.Object[1024] @ 0x81656c40|4 112|1 380 925 480|
> |org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
> @ 0xb5f2bcd8|24|318 622 384|
> |org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
> @ 0xb5f28d90|96|318 618 624|
> |org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
> @ 0xb5ed4ac8|24|318 618 576|
> |org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition
> @ 0xb5f2e7f8|24|318 618 528|
> |grp org.apache.ignite.internal.processors.cache.CacheGroupContext @
> 0x809f04c8|96|1 381 121 912|
> |state org.apa
[jira] [Updated] (IGNITE-12653) Add example of baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-12653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-12653: --- Labels: newbie (was: ) > Add example of baseline auto-adjust feature > --- > > Key: IGNITE-12653 > URL: https://issues.apache.org/jira/browse/IGNITE-12653 > Project: Ignite > Issue Type: Task > Components: examples >Reporter: Anton Kalashnikov >Priority: Major > Labels: newbie > > Work on the Phase II of IEP-4 (Baseline topology) [1] has finished. It makes > sense to implement some examples of "Baseline auto-adjust" [2]. > "Baseline auto-adjust" feature implements mechanism of auto-adjust baseline > corresponding to current topology after event join/left was appeared. It is > required because when a node left the grid and nobody would change baseline > manually it can lead to lost data(when some more nodes left the grid on > depends in backup factor) but permanent tracking of grid is not always > possible/desirible. Looks like in many cases auto-adjust baseline after some > timeout is very helpfull. > Distributed metastore[3](it is already done): > First of all it is required the ability to store configuration data > consistently and cluster-wide. Ignite doesn't have any specific API for such > configurations and we don't want to have many similar implementations of the > same feature in our code. After some thoughts is was proposed to implement it > as some kind of distributed metastorage that gives the ability to store any > data in it. > First implementation is based on existing local metastorage API for > persistent clusters (in-memory clusters will store data in memory). > Write/remove operation use Discovery SPI to send updates to the cluster, it > guarantees updates order and the fact that all existing (alive) nodes have > handled the update message. As a way to find out which node has the latest > data there is a "version" value of distributed metastorage, which is > basically . All updates history until > some point in the past is stored along with the data, so when an outdated > node connects to the cluster it will receive all the missing data and apply > it locally. If there's not enough history stored or joining node is clear > then it'll receive shapshot of distributed metastorage so there won't be > inconsistencies. > Baseline auto-adjust: > Main scenario: > - There is a grid with the baseline is equal to the current topology > - New node joins to grid or some node left(failed) the grid > - New mechanism detects this event and it add a task for changing > baseline to queue with configured timeout > - If a new event happens before baseline would be changed task would > be removed from the queue and a new task will be added > - When a timeout is expired the task would try to set new baseline > corresponded to current topology > First of all we need to add two parameters[4]: > - baselineAutoAdjustEnabled - enable/disable "Baseline auto-adjust" > feature. > - baselineAutoAdjustTimeout - timeout after which baseline should be > changed. > These parameters are cluster-wide and can be changed in real-time because it > is based on "Distributed metastore". > Restrictions: > - This mechanism handling events only on active grid > - for in-memory nodes - enabled by default. For persistent nodes - > disabled. > - If lost partitions was detected this feature would be disabled > - If baseline was adjusted manually on baselineNodes != gridNodes the > exception would be thrown > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches > [2] https://issues.apache.org/jira/browse/IGNITE-8571 > [3] https://issues.apache.org/jira/browse/IGNITE-10640 > [4] https://issues.apache.org/jira/browse/IGNITE-8573 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12652) Add example of failure handling
[ https://issues.apache.org/jira/browse/IGNITE-12652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-12652: --- Labels: newbie (was: ) > Add example of failure handling > --- > > Key: IGNITE-12652 > URL: https://issues.apache.org/jira/browse/IGNITE-12652 > Project: Ignite > Issue Type: Task > Components: examples >Reporter: Anton Kalashnikov >Priority: Major > Labels: newbie > > Ignite has the following feature - > https://apacheignite.readme.io/docs/critical-failures-handling, but there is > not an example of how to use it correctly. So it is good to add some examples. > Also, Ignite has DiagnosticProcessor which invokes when the failure handler > is triggered. Maybe it is a good idea to add to this example some samples of > diagnostic work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9829) Add validation errors distinction to TcpDiscoveryCheckFailedMessage
[ https://issues.apache.org/jira/browse/IGNITE-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-9829: -- Labels: newbie (was: ) > Add validation errors distinction to TcpDiscoveryCheckFailedMessage > --- > > Key: IGNITE-9829 > URL: https://issues.apache.org/jira/browse/IGNITE-9829 > Project: Ignite > Issue Type: Improvement > Components: messaging >Reporter: Alexey Platonov >Priority: Major > Labels: newbie > Fix For: 3.0 > > > There is no way to define validation error type during joining on client side > after node validation on server side. TcpDiscoveryCheckFailedMessage just > aggregates error messages to one string. For example: if there was auth error > while joining then client receive TcpDiscoveryCheckFailedMessage instead of > TcpDiscoveryAuthFailedMessage. This is due to server validation protocol > supports just IgniteNodeValidationResult as string-wrapper without additional > information about types of validation errors. Set of enum values representing > validation errors may be good solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6664) Memcached example refactoring
[
https://issues.apache.org/jira/browse/IGNITE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov updated IGNITE-6664:
--
Labels: newbie (was: )
> Memcached example refactoring
> -
>
> Key: IGNITE-6664
> URL: https://issues.apache.org/jira/browse/IGNITE-6664
> Project: Ignite
> Issue Type: Task
> Components: examples
>Affects Versions: 2.2
>Reporter: Sergey Kozlov
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> The memcached example {{examples/memcached/memcached-example.php}} looks like
> outpdated and doesn't work for php 7.0/7.1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9325) Add to all command-line utility ability to make sound after complite execution
[ https://issues.apache.org/jira/browse/IGNITE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-9325: -- Labels: command-line newbie (was: command-line) > Add to all command-line utility ability to make sound after complite execution > -- > > Key: IGNITE-9325 > URL: https://issues.apache.org/jira/browse/IGNITE-9325 > Project: Ignite > Issue Type: Improvement > Components: examples >Affects Versions: 2.5 >Reporter: ARomantsov >Priority: Major > Labels: command-line, newbie > Fix For: 2.9 > > > Often I work simultaneously on several clusters over ssh and there are > situations when I forget to check that the first cluster has completed the > command (for example, activation), while working on the second. > Because of this, I would like to have same functionality in the product -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12654) Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge number of eviction callbacks
[ https://issues.apache.org/jira/browse/IGNITE-12654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-12654: - Description: ||Heading 1||Heading 2|| |\|text\|test\|text|Col A2| > Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge > number of eviction callbacks > - > > Key: IGNITE-12654 > URL: https://issues.apache.org/jira/browse/IGNITE-12654 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.9 > > > ||Heading 1||Heading 2|| > |\|text\|test\|text|Col A2| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12654) Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge number of eviction callbacks
[ https://issues.apache.org/jira/browse/IGNITE-12654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-12654: - Ignite Flags: (was: Docs Required,Release Notes Required) > Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge > number of eviction callbacks > - > > Key: IGNITE-12654 > URL: https://issues.apache.org/jira/browse/IGNITE-12654 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.9 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
[ https://issues.apache.org/jira/browse/IGNITE-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033676#comment-17033676 ] Maxim Muzafarov commented on IGNITE-11949: -- [~alex_pl], [~ustas], [~zstan] Can we proceed with this patch? > Yardstick benchmarks for WAL page snapshot compression > -- > > Key: IGNITE-11949 > URL: https://issues.apache.org/jira/browse/IGNITE-11949 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-20, yardstick > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > WAL page snapshots compression (implemented by IGNITE-11336) can be enabled > by modifying config.xml file. It will be better to configure benchmarks by > command line options. > Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
[ https://issues.apache.org/jira/browse/IGNITE-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11949: - Fix Version/s: 2.9 > Yardstick benchmarks for WAL page snapshot compression > -- > > Key: IGNITE-11949 > URL: https://issues.apache.org/jira/browse/IGNITE-11949 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-20, yardstick > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > WAL page snapshots compression (implemented by IGNITE-11336) can be enabled > by modifying config.xml file. It will be better to configure benchmarks by > command line options. > Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12654) Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge number of eviction callbacks
Vyacheslav Koptilin created IGNITE-12654: Summary: Some of rentingFutures in GridDhtPartitionTopologyImpl may accumulate a huge number of eviction callbacks Key: IGNITE-12654 URL: https://issues.apache.org/jira/browse/IGNITE-12654 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12651) Non-comparable keys for eviction policy cause failure handle and node shutdown
[
https://issues.apache.org/jira/browse/IGNITE-12651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12651:
-
Description:
Non-comparable keys in the same cache (for instance, Integer and Double) and
eviction policy enabled results in node failure with the following exception:
{code:java}
java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Doublejava.lang.ClassCastException: java.lang.Integer cannot be cast
to java.lang.Double at java.lang.Double.compareTo(Double.java:49) at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:360)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:348)
at
java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
at
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:835)
at
java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1962)
at
org.apache.ignite.internal.util.GridConcurrentSkipListSet.add(GridConcurrentSkipListSet.java:143)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$GridConcurrentSkipListSetEx.add(SortedEvictionPolicy.java:398)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy.touch(SortedEvictionPolicy.java:176)
at
org.apache.ignite.cache.eviction.AbstractEvictionPolicy.onEntryAccessed(AbstractEvictionPolicy.java:88)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:321)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:199)
{code}
was:
Non-comparable keys in the same cache (for instance, Integer and Double) and
eviction policy enabled results in node failure with the following exception:
{code:java}
Unexpected exception during cache updateUnexpected exception during cache
updatejava.lang.ClassCastException: java.lang.Double cannot be cast to
java.lang.Integer at java.lang.Integer.compareTo(Integer.java:52) at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:364)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:351)
at
java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
at
java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:682)
at
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:823)
at
java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
at
org.apache.ignite.internal.util.GridConcurrentSkipListSet.add(GridConcurrentSkipListSet.java:143)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$GridConcurrentSkipListSetEx.add(SortedEvictionPolicy.java:402)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy.touch(SortedEvictionPolicy.java:176)
at
org.apache.ignite.cache.eviction.AbstractEvictionPolicy.onEntryAccessed(AbstractEvictionPolicy.java:88)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:225)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.touch(GridCacheMapEntry.java:4441)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3013)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1818)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1638)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:487)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:447)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1124)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:613)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(G
[jira] [Commented] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033649#comment-17033649
]
Ignite TC Bot commented on IGNITE-12610:
{panel:title=Branch: [pull/7385/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4994087&buildTypeId=IgniteTests24Java8_RunAll]
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033647#comment-17033647
]
Ignite TC Bot commented on IGNITE-12610:
{panel:title=Branch: [pull/7385/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4994087&buildTypeId=IgniteTests24Java8_RunAll]
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12653) Add example of baseline auto-adjust feature
Anton Kalashnikov created IGNITE-12653: -- Summary: Add example of baseline auto-adjust feature Key: IGNITE-12653 URL: https://issues.apache.org/jira/browse/IGNITE-12653 Project: Ignite Issue Type: Task Components: examples Reporter: Anton Kalashnikov Work on the Phase II of IEP-4 (Baseline topology) [1] has finished. It makes sense to implement some examples of "Baseline auto-adjust" [2]. "Baseline auto-adjust" feature implements mechanism of auto-adjust baseline corresponding to current topology after event join/left was appeared. It is required because when a node left the grid and nobody would change baseline manually it can lead to lost data(when some more nodes left the grid on depends in backup factor) but permanent tracking of grid is not always possible/desirible. Looks like in many cases auto-adjust baseline after some timeout is very helpfull. Distributed metastore[3](it is already done): First of all it is required the ability to store configuration data consistently and cluster-wide. Ignite doesn't have any specific API for such configurations and we don't want to have many similar implementations of the same feature in our code. After some thoughts is was proposed to implement it as some kind of distributed metastorage that gives the ability to store any data in it. First implementation is based on existing local metastorage API for persistent clusters (in-memory clusters will store data in memory). Write/remove operation use Discovery SPI to send updates to the cluster, it guarantees updates order and the fact that all existing (alive) nodes have handled the update message. As a way to find out which node has the latest data there is a "version" value of distributed metastorage, which is basically . All updates history until some point in the past is stored along with the data, so when an outdated node connects to the cluster it will receive all the missing data and apply it locally. If there's not enough history stored or joining node is clear then it'll receive shapshot of distributed metastorage so there won't be inconsistencies. Baseline auto-adjust: Main scenario: - There is a grid with the baseline is equal to the current topology - New node joins to grid or some node left(failed) the grid - New mechanism detects this event and it add a task for changing baseline to queue with configured timeout - If a new event happens before baseline would be changed task would be removed from the queue and a new task will be added - When a timeout is expired the task would try to set new baseline corresponded to current topology First of all we need to add two parameters[4]: - baselineAutoAdjustEnabled - enable/disable "Baseline auto-adjust" feature. - baselineAutoAdjustTimeout - timeout after which baseline should be changed. These parameters are cluster-wide and can be changed in real-time because it is based on "Distributed metastore". Restrictions: - This mechanism handling events only on active grid - for in-memory nodes - enabled by default. For persistent nodes - disabled. - If lost partitions was detected this feature would be disabled - If baseline was adjusted manually on baselineNodes != gridNodes the exception would be thrown [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches [2] https://issues.apache.org/jira/browse/IGNITE-8571 [3] https://issues.apache.org/jira/browse/IGNITE-10640 [4] https://issues.apache.org/jira/browse/IGNITE-8573 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12652) Add example of failure handling
Anton Kalashnikov created IGNITE-12652: -- Summary: Add example of failure handling Key: IGNITE-12652 URL: https://issues.apache.org/jira/browse/IGNITE-12652 Project: Ignite Issue Type: Task Components: examples Reporter: Anton Kalashnikov Ignite has the following feature - https://apacheignite.readme.io/docs/critical-failures-handling, but there is not an example of how to use it correctly. So it is good to add some examples. Also, Ignite has DiagnosticProcessor which invokes when the failure handler is triggered. Maybe it is a good idea to add to this example some samples of diagnostic work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11368) use the same information about indexes for JDBC drivers as for system view INDEXES
[ https://issues.apache.org/jira/browse/IGNITE-11368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11368: --- Summary: use the same information about indexes for JDBC drivers as for system view INDEXES (was: use the same information about indexes for ODBC JDBC drivers as for system view INDEXES) > use the same information about indexes for JDBC drivers as for system view > INDEXES > -- > > Key: IGNITE-11368 > URL: https://issues.apache.org/jira/browse/IGNITE-11368 > Project: Ignite > Issue Type: Task > Components: jdbc, odbc, sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: newbie > Fix For: 2.9 > > > As of now indexes information for JDBC drivers get by another way then system > SQL view INDEXES. Need to use single source of the information to have > consistent picture. > So, JDBC drivers should use the same source as SQL view INDEXES > (org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes) > Start point for JDBC index metadata is > org.apache.ignite.internal.processors.odbc.jdbc.JdbcMetadataInfo#getIndexesMeta -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11368) use the same information about indexes for ODBC JDBC drivers as for system view INDEXES
[ https://issues.apache.org/jira/browse/IGNITE-11368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11368: --- Description: As of now indexes information for JDBC drivers get by another way then system SQL view INDEXES. Need to use single source of the information to have consistent picture. So, JDBC drivers should use the same source as SQL view INDEXES (org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes) Start point for JDBC index metadata is org.apache.ignite.internal.processors.odbc.jdbc.JdbcMetadataInfo#getIndexesMeta was: As of now indexes information for ODBC/JDBC drivers get by another way then system SQL view INDEXES. Need to use single source of the information to have consistent picture. So, ODBC/JDBC drivers should use the same source as SQL view INDEXES (org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes) > use the same information about indexes for ODBC JDBC drivers as for system > view INDEXES > --- > > Key: IGNITE-11368 > URL: https://issues.apache.org/jira/browse/IGNITE-11368 > Project: Ignite > Issue Type: Task > Components: jdbc, odbc, sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: newbie > Fix For: 2.9 > > > As of now indexes information for JDBC drivers get by another way then system > SQL view INDEXES. Need to use single source of the information to have > consistent picture. > So, JDBC drivers should use the same source as SQL view INDEXES > (org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes) > Start point for JDBC index metadata is > org.apache.ignite.internal.processors.odbc.jdbc.JdbcMetadataInfo#getIndexesMeta -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10698) Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
[
https://issues.apache.org/jira/browse/IGNITE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lev Kiselev updated IGNITE-10698:
-
Labels: newbie pull-request-available usability (was: newbie usability)
> Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
> ---
>
> Key: IGNITE-10698
> URL: https://issues.apache.org/jira/browse/IGNITE-10698
> Project: Ignite
> Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Lev Kiselev
>Priority: Major
> Labels: newbie, pull-request-available, usability
> Fix For: 3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> @MXBeanDescription("Returns or kills transactions matching the filter
> conditions.")
> @MXBeanParametersNames(
> {
> "minDuration",
> "minSize",
> "prj",
> "consistentIds",
> "xid",
> "lbRegex",
> "limit",
> "order",
> "detailed",
> "kill"
> }
> )
> @MXBeanParametersDescriptions(
> {
> "Minimum duration (seconds).",
> "Minimum size.",
> "Projection (servers|clients).",
> "Consistent ids (separated by comma).",
> "Transaction XID.",
> "Label regexp.",
> "Limit a number of transactions collected on each node.",
> "Order by DURATION|SIZE.",
> "Show detailed description, otherwise only count.",
> "Kill matching transactions (be careful)."
> }
> )
> {noformat}
> Above looks pretty ugly and is very error prone due to messing names and
> descr order or number of strings.
> I would suggest to introduce individual parameters annotations and get them
> via mtd.getParamterAnnotations() at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12650) Mark MVCC with @IgniteExperimental annotation
[ https://issues.apache.org/jira/browse/IGNITE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12650: - Ignite Flags: (was: Docs Required,Release Notes Required) > Mark MVCC with @IgniteExperimental annotation > - > > Key: IGNITE-12650 > URL: https://issues.apache.org/jira/browse/IGNITE-12650 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Priority: Major > Fix For: 2.8 > > > MVCC should be marked with the @IgniteExperimental annotation. > * Beta version of Transactional SQL and MVCC > * In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to > allow users to experiment and share feedback. > * This version of Transactional SQL and MVCC should not be considered for > production. > [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12651) Non-comparable keys for eviction policy cause failure handle and node shutdown
Vyacheslav Koptilin created IGNITE-12651:
Summary: Non-comparable keys for eviction policy cause failure
handle and node shutdown
Key: IGNITE-12651
URL: https://issues.apache.org/jira/browse/IGNITE-12651
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.9
Non-comparable keys in the same cache (for instance, Integer and Double) and
eviction policy enabled results in node failure with the following exception:
{code:java}
Unexpected exception during cache updateUnexpected exception during cache
updatejava.lang.ClassCastException: java.lang.Double cannot be cast to
java.lang.Integer at java.lang.Integer.compareTo(Integer.java:52) at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:364)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:351)
at
java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
at
java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:682)
at
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:823)
at
java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
at
org.apache.ignite.internal.util.GridConcurrentSkipListSet.add(GridConcurrentSkipListSet.java:143)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$GridConcurrentSkipListSetEx.add(SortedEvictionPolicy.java:402)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy.touch(SortedEvictionPolicy.java:176)
at
org.apache.ignite.cache.eviction.AbstractEvictionPolicy.onEntryAccessed(AbstractEvictionPolicy.java:88)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:225)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.touch(GridCacheMapEntry.java:4441)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3013)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1818)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1638)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:487)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:447)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1124)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:613)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:1980)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:1957)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1285)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:786)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerCacheUpdaters$Individual.receive(DataStreamerCacheUpdaters.java:121)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:400)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:305)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:60)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:90)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1565)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
at
org.apache.ignite.internal.managers.
[jira] [Updated] (IGNITE-12650) Mark MVCC with @IgniteExperimental annotation
[ https://issues.apache.org/jira/browse/IGNITE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12650: - Fix Version/s: 2.8 > Mark MVCC with @IgniteExperimental annotation > - > > Key: IGNITE-12650 > URL: https://issues.apache.org/jira/browse/IGNITE-12650 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Priority: Major > Fix For: 2.8 > > > MVCC should be marked with the @IgniteExperimental annotation. > * Beta version of Transactional SQL and MVCC > * In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to > allow users to experiment and share feedback. > * This version of Transactional SQL and MVCC should not be considered for > production. > [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12651) Non-comparable keys for eviction policy cause failure handle and node shutdown
[
https://issues.apache.org/jira/browse/IGNITE-12651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12651:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Non-comparable keys for eviction policy cause failure handle and node shutdown
> --
>
> Key: IGNITE-12651
> URL: https://issues.apache.org/jira/browse/IGNITE-12651
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> Non-comparable keys in the same cache (for instance, Integer and Double) and
> eviction policy enabled results in node failure with the following exception:
> {code:java}
> Unexpected exception during cache updateUnexpected exception during cache
> updatejava.lang.ClassCastException: java.lang.Double cannot be cast to
> java.lang.Integer at java.lang.Integer.compareTo(Integer.java:52) at
> org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:364)
> at
> org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:351)
> at
> java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
> at
> java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:682)
> at
> java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:823)
> at
> java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
> at
> org.apache.ignite.internal.util.GridConcurrentSkipListSet.add(GridConcurrentSkipListSet.java:143)
> at
> org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$GridConcurrentSkipListSetEx.add(SortedEvictionPolicy.java:402)
> at
> org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy.touch(SortedEvictionPolicy.java:176)
> at
> org.apache.ignite.cache.eviction.AbstractEvictionPolicy.onEntryAccessed(AbstractEvictionPolicy.java:88)
> at
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:225)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.touch(GridCacheMapEntry.java:4441)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3013)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1818)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1638)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:487)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:447)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1124)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:613)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:1980)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:1957)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1285)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:786)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerCacheUpdaters$Individual.receive(DataStreamerCacheUpdaters.java:121)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:400)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:305)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcess
[jira] [Created] (IGNITE-12650) Mark MVCC with @IgniteExperimental annotation
Maxim Muzafarov created IGNITE-12650: Summary: Mark MVCC with @IgniteExperimental annotation Key: IGNITE-12650 URL: https://issues.apache.org/jira/browse/IGNITE-12650 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov MVCC should be marked with the @IgniteExperimental annotation. * Beta version of Transactional SQL and MVCC * In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to allow users to experiment and share feedback. * This version of Transactional SQL and MVCC should not be considered for production. [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12590) MERGE INTO query is failing on Ignite client node
[
https://issues.apache.org/jira/browse/IGNITE-12590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033581#comment-17033581
]
Ignite TC Bot commented on IGNITE-12590:
{panel:title=Branch: [pull/7321/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4967439&buildTypeId=IgniteTests24Java8_RunAll]
> MERGE INTO query is failing on Ignite client node
> -
>
> Key: IGNITE-12590
> URL: https://issues.apache.org/jira/browse/IGNITE-12590
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Precondition: server nodes (any amount), webconsole is running.
> 1. Create the table as following:
> CREATE TABLE USERPUBSTATICDATA (BOOK VARCHAR, DESK VARCHAR, TRADERS VARCHAR,
> REGION VARCHAR, LOB VARCHAR, EXCLUDE VARCHAR, TRANSIT VARCHAR,
> MAPBOOKTOTHISBOOK VARCHAR, CONSTRAINT USERPUBSTATICDATA_PK PRIMARY KEY
> (BOOK,DESK)) WITH "template=replicated"
> 2. Execute merge into query:
> MERGE INTO USERPUBSTATICDATA(BOOK, DESK, TRADERS, REGION, LOB, EXCLUDE,
> TRANSIT, MAPBOOKTOTHISBOOK) VALUES('CADOIS', 'FRT TOR', 'Robin Das/Dave
> Carlson', 'Toronto', 'FRT', null, null, 'CADOIS');
> Step 2 is successfull on Web Console and called on IgniteCache from the
> server node, but fails when called from the Ignite client node with exception:
> {code}
> javax.cache.CacheException: Invalid column name in KEYS clause of MERGE - it
> may include only key and/or affinity columns: BOOK
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12649) HibernateL2CacheExample throws IllegalArgumentException for ignite-hibernate_5.3
[
https://issues.apache.org/jira/browse/IGNITE-12649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033565#comment-17033565
]
Vyacheslav Koptilin commented on IGNITE-12649:
--
I see no reason to trigger RunAll. I think examples would be enough:
[https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Examples?branch=pull%2F7393%2Fhead&buildTypeTab=overview&mode=builds#all-projects]
> HibernateL2CacheExample throws IllegalArgumentException for
> ignite-hibernate_5.3
>
>
> Key: IGNITE-12649
> URL: https://issues.apache.org/jira/browse/IGNITE-12649
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
> {code:java}
> Exception in thread "main" java.lang.IllegalArgumentException: Cache is not
> started: default-update-timestamps-regionException in thread "main"
> java.lang.IllegalArgumentException: Cache is not started:
> default-update-timestamps-region at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicCache(GridCacheProcessor.java:4439)
> at org.apache.ignite.internal.IgniteKernal.getCache(IgniteKernal.java:3246)
> at
> org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:192)
> at
> org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:171)
> at
> org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:200)
> at
> org.apache.ignite.cache.hibernate.IgniteGeneralDataRegion.putIntoCache(IgniteGeneralDataRegion.java:70)
> at
> org.hibernate.cache.internal.TimestampsCacheEnabledImpl.preInvalidate(TimestampsCacheEnabledImpl.java:60)
> at
> org.hibernate.engine.spi.ActionQueue.invalidateSpaces(ActionQueue.java:666)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:628)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
> at
> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
> at
> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
> at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) at
> org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at
> org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283)
> at
> org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479)
> at
> org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473)
> at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:178)
> at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$300(JdbcResourceLocalTransactionCoordinatorImpl.java:39)
> at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271)
> at
> org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98)
> at
> org.apache.ignite.examples.datagrid.hibernate.HibernateL2CacheExample.main(HibernateL2CacheExample.java:145)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12649) HibernateL2CacheExample throws IllegalArgumentException for ignite-hibernate_5.3
[
https://issues.apache.org/jira/browse/IGNITE-12649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12649:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> HibernateL2CacheExample throws IllegalArgumentException for
> ignite-hibernate_5.3
>
>
> Key: IGNITE-12649
> URL: https://issues.apache.org/jira/browse/IGNITE-12649
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> {{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
> {code:java}
> Exception in thread "main" java.lang.IllegalArgumentException: Cache is not
> started: default-update-timestamps-regionException in thread "main"
> java.lang.IllegalArgumentException: Cache is not started:
> default-update-timestamps-region at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicCache(GridCacheProcessor.java:4439)
> at org.apache.ignite.internal.IgniteKernal.getCache(IgniteKernal.java:3246)
> at
> org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:192)
> at
> org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:171)
> at
> org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:200)
> at
> org.apache.ignite.cache.hibernate.IgniteGeneralDataRegion.putIntoCache(IgniteGeneralDataRegion.java:70)
> at
> org.hibernate.cache.internal.TimestampsCacheEnabledImpl.preInvalidate(TimestampsCacheEnabledImpl.java:60)
> at
> org.hibernate.engine.spi.ActionQueue.invalidateSpaces(ActionQueue.java:666)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:628)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
> at
> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
> at
> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
> at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) at
> org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at
> org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283)
> at
> org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479)
> at
> org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473)
> at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:178)
> at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$300(JdbcResourceLocalTransactionCoordinatorImpl.java:39)
> at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271)
> at
> org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98)
> at
> org.apache.ignite.examples.datagrid.hibernate.HibernateL2CacheExample.main(HibernateL2CacheExample.java:145)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12649) HibernateL2CacheExample throws IllegalArgumentException for ignite-hibernate_5.3
[
https://issues.apache.org/jira/browse/IGNITE-12649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12649:
-
Description:
{{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
{code:java}
Exception in thread "main" java.lang.IllegalArgumentException: Cache is not
started: default-update-timestamps-regionException in thread "main"
java.lang.IllegalArgumentException: Cache is not started:
default-update-timestamps-region at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicCache(GridCacheProcessor.java:4439)
at org.apache.ignite.internal.IgniteKernal.getCache(IgniteKernal.java:3246) at
org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:192)
at
org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:171)
at
org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:200)
at
org.apache.ignite.cache.hibernate.IgniteGeneralDataRegion.putIntoCache(IgniteGeneralDataRegion.java:70)
at
org.hibernate.cache.internal.TimestampsCacheEnabledImpl.preInvalidate(TimestampsCacheEnabledImpl.java:60)
at org.hibernate.engine.spi.ActionQueue.invalidateSpaces(ActionQueue.java:666)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:628) at
org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at
org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) at
org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at
org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283)
at
org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479)
at
org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473)
at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:178)
at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$300(JdbcResourceLocalTransactionCoordinatorImpl.java:39)
at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271)
at
org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98)
at
org.apache.ignite.examples.datagrid.hibernate.HibernateL2CacheExample.main(HibernateL2CacheExample.java:145)
{code}
was:
{{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Cache is not
started: default-update-timestamps-regionException in thread "main"
java.lang.IllegalArgumentException: Cache is not started:
default-update-timestamps-region at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicCache(GridCacheProcessor.java:4439)
at org.apache.ignite.internal.IgniteKernal.getCache(IgniteKernal.java:3246) at
org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:192)
at
org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:171)
at
org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:200)
at
org.apache.ignite.cache.hibernate.IgniteGeneralDataRegion.putIntoCache(IgniteGeneralDataRegion.java:70)
at
org.hibernate.cache.internal.TimestampsCacheEnabledImpl.preInvalidate(TimestampsCacheEnabledImpl.java:60)
at org.hibernate.engine.spi.ActionQueue.invalidateSpaces(ActionQueue.java:666)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:628) at
org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at
org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) at
org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at
org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283)
at
org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479)
at
org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473)
a
[jira] [Updated] (IGNITE-12649) HibernateL2CacheExample throws IllegalArgumentException for ignite-hibernate_5.3
[
https://issues.apache.org/jira/browse/IGNITE-12649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12649:
-
Description:
{{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Cache is not
started: default-update-timestamps-regionException in thread "main"
java.lang.IllegalArgumentException: Cache is not started:
default-update-timestamps-region at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicCache(GridCacheProcessor.java:4439)
at org.apache.ignite.internal.IgniteKernal.getCache(IgniteKernal.java:3246) at
org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:192)
at
org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:171)
at
org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:200)
at
org.apache.ignite.cache.hibernate.IgniteGeneralDataRegion.putIntoCache(IgniteGeneralDataRegion.java:70)
at
org.hibernate.cache.internal.TimestampsCacheEnabledImpl.preInvalidate(TimestampsCacheEnabledImpl.java:60)
at org.hibernate.engine.spi.ActionQueue.invalidateSpaces(ActionQueue.java:666)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:628) at
org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at
org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) at
org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at
org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283)
at
org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479)
at
org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473)
at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:178)
at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$300(JdbcResourceLocalTransactionCoordinatorImpl.java:39)
at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271)
at
org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98)
at
org.apache.ignite.examples.datagrid.hibernate.HibernateL2CacheExample.main(HibernateL2CacheExample.java:145){noformat}
was:{{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
> HibernateL2CacheExample throws IllegalArgumentException for
> ignite-hibernate_5.3
>
>
> Key: IGNITE-12649
> URL: https://issues.apache.org/jira/browse/IGNITE-12649
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> {{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Cache is not
> started: default-update-timestamps-regionException in thread "main"
> java.lang.IllegalArgumentException: Cache is not started:
> default-update-timestamps-region at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.publicCache(GridCacheProcessor.java:4439)
> at org.apache.ignite.internal.IgniteKernal.getCache(IgniteKernal.java:3246)
> at
> org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:192)
> at
> org.apache.ignite.cache.hibernate.HibernateAccessStrategyFactory$LazyCacheSupplier.get(HibernateAccessStrategyFactory.java:171)
> at
> org.apache.ignite.cache.hibernate.HibernateCacheProxy.put(HibernateCacheProxy.java:200)
> at
> org.apache.ignite.cache.hibernate.IgniteGeneralDataRegion.putIntoCache(IgniteGeneralDataRegion.java:70)
> at
> org.hibernate.cache.internal.TimestampsCacheEnabledImpl.preInvalidate(TimestampsCacheEnabledImpl.java:60)
> at
> org.hibernate.engine.spi.ActionQueue.invalidateSpaces(ActionQueue.java:666)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:628)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478)
> at
> org.hibernate.event.internal.Abs
[jira] [Created] (IGNITE-12649) HibernateL2CacheExample throws IllegalArgumentException for ignite-hibernate_5.3
Vyacheslav Koptilin created IGNITE-12649:
Summary: HibernateL2CacheExample throws IllegalArgumentException
for ignite-hibernate_5.3
Key: IGNITE-12649
URL: https://issues.apache.org/jira/browse/IGNITE-12649
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.9
{{HibernateL2CacheExample does not work with }}ignite-hibernate_5.3.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12649) HibernateL2CacheExample throws IllegalArgumentException for ignite-hibernate_5.3
[
https://issues.apache.org/jira/browse/IGNITE-12649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12649:
-
Description: {{HibernateL2CacheExample}} does not work with
{{ignite-hibernate_5.3}}. (was: {{HibernateL2CacheExample does not work with
}}ignite-hibernate_5.3.)
> HibernateL2CacheExample throws IllegalArgumentException for
> ignite-hibernate_5.3
>
>
> Key: IGNITE-12649
> URL: https://issues.apache.org/jira/browse/IGNITE-12649
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> {{HibernateL2CacheExample}} does not work with {{ignite-hibernate_5.3}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033493#comment-17033493 ] Ryabov Dmitrii commented on IGNITE-12049: - Done. > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Fix For: 2.9 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryabov Dmitrii updated IGNITE-12049: Description: Add user attributes to thin clients (like node attributes for server nodes). (was: Add user attributes to thin clients (like node attributes for server nodes). Make sure that custom authenticators can use these attributes.) > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Fix For: 2.9 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12648) Add user attributes to non-Java thin clients
Ryabov Dmitrii created IGNITE-12648: --- Summary: Add user attributes to non-Java thin clients Key: IGNITE-12648 URL: https://issues.apache.org/jira/browse/IGNITE-12648 Project: Ignite Issue Type: Task Reporter: Ryabov Dmitrii Add user attributes to non-Java thin clients (like node attributes for server nodes). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-12049: --- Fix Version/s: 2.9 > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Fix For: 2.9 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). > Make sure that custom authenticators can use these attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033481#comment-17033481 ] Alexey Scherbakov commented on IGNITE-12049: [~SomeFire] Looks good. Merged to master b76686a17b49e2631e21ec1ba7c4583bad707ec7. Can you create and link a ticket for support of user attributes for other language clients ? > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). > Make sure that custom authenticators can use these attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12647) Get rid of IGFS and Hadoop Accelerator
[ https://issues.apache.org/jira/browse/IGNITE-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov resolved IGNITE-12647. Resolution: Duplicate > Get rid of IGFS and Hadoop Accelerator > -- > > Key: IGNITE-12647 > URL: https://issues.apache.org/jira/browse/IGNITE-12647 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > > There is no single committer who maintains the > integrations; they are no longer tested and, even more, the community > stopped providing the binaries since Ignite 2.6.0 release (look for > In-Memory Hadoop Accelerator table). > So it makes sense to get rid of IGFS and Hadoop Accelerator -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11942) IGFS and Hadoop Accelerator Discontinuation
[ https://issues.apache.org/jira/browse/IGNITE-11942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov reassigned IGNITE-11942: -- Assignee: Anton Kalashnikov > IGFS and Hadoop Accelerator Discontinuation > --- > > Key: IGNITE-11942 > URL: https://issues.apache.org/jira/browse/IGNITE-11942 > Project: Ignite > Issue Type: Task >Reporter: Denis A. Magda >Assignee: Anton Kalashnikov >Priority: Blocker > Fix For: 2.9 > > > The community has voted for the following decision: > * IGFS and In-Memory Hadoop Accelerator components are to be discontinued and > no longer supported by the community > * The existing source code of IGFS and In-Memory Hadoop Accelerator is to be > removed from Ignite master. Before that, a special branch like > "ignite-igfs-and-hadoop-accelerator" to be forked off the master in order to > preserve the sources in Git history for those who might need it. > The voting thread: > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42405.html > Once the changes are made for Ignite 2.8, please contact Denis Magda to > update a public documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12647) Get rid of IGFS and Hadoop Accelerator
Anton Kalashnikov created IGNITE-12647: -- Summary: Get rid of IGFS and Hadoop Accelerator Key: IGNITE-12647 URL: https://issues.apache.org/jira/browse/IGNITE-12647 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov There is no single committer who maintains the integrations; they are no longer tested and, even more, the community stopped providing the binaries since Ignite 2.6.0 release (look for In-Memory Hadoop Accelerator table). So it makes sense to get rid of IGFS and Hadoop Accelerator -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033445#comment-17033445 ] Alexey Goncharuk commented on IGNITE-8617: -- Agree on the javadoc part comment. Otherwise looks good to me (though, I'm not an expert in Amazon services). > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Emmanouil Gkatziouras >Priority: Critical > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12499) Node took a long time to start after kill
[ https://issues.apache.org/jira/browse/IGNITE-12499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12499: -- Release Note: Improved node recovery time by executing partition state restore phase in parallel > Node took a long time to start after kill > - > > Key: IGNITE-12499 > URL: https://issues.apache.org/jira/browse/IGNITE-12499 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Test scenario: > 1) Start 4 node cluster > 2) Activate > 3) Load 1k rows to each cache > 4) Stop node > 5) Return it back without index.bin files > 6) Wait until start > Somehow the first node takes Waiting for topology snapshot: server(s) 4/4, > client(s) 0/*, timeout 1166/1800 sec to start. > [10:47:21,360][INFO][main][G] Node started : [stage="Configure system pool" > (129 ms),stage="Start managers" (440 ms),stage="Configure binary metadata" > (86 ms),stage="Start processors" (39341 ms),stage="Start 'GridGain' plugin" > (16 ms),s > tage="Init and start regions" (210 ms),stage="Restore binary memory" (228224 > ms),stage="Restore logical state" (859694 ms),stage="Finish recovery" (8938 > ms),stage="Join topology" (6024 ms),stage="Await transition" (16 > ms),stage="Await e > xchange" (14855 ms),stage="Total time" (1157973 ms)] > h3. Clarification: > "Restore logical state" stage is the longest one and it uses one thread, so > CPU/IO utilization is very low. Execution of "restorePartitionStates" in some > ExecutorService would drastically speed up the whole node startup process > because it's the main reason of restore being slow in this particular case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12499) Node took a long time to start after kill
[ https://issues.apache.org/jira/browse/IGNITE-12499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033438#comment-17033438 ] Alexey Goncharuk commented on IGNITE-12499: --- [~ibessonov] thanks for the contribution, merged to master. > Node took a long time to start after kill > - > > Key: IGNITE-12499 > URL: https://issues.apache.org/jira/browse/IGNITE-12499 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Test scenario: > 1) Start 4 node cluster > 2) Activate > 3) Load 1k rows to each cache > 4) Stop node > 5) Return it back without index.bin files > 6) Wait until start > Somehow the first node takes Waiting for topology snapshot: server(s) 4/4, > client(s) 0/*, timeout 1166/1800 sec to start. > [10:47:21,360][INFO][main][G] Node started : [stage="Configure system pool" > (129 ms),stage="Start managers" (440 ms),stage="Configure binary metadata" > (86 ms),stage="Start processors" (39341 ms),stage="Start 'GridGain' plugin" > (16 ms),s > tage="Init and start regions" (210 ms),stage="Restore binary memory" (228224 > ms),stage="Restore logical state" (859694 ms),stage="Finish recovery" (8938 > ms),stage="Join topology" (6024 ms),stage="Await transition" (16 > ms),stage="Await e > xchange" (14855 ms),stage="Total time" (1157973 ms)] > h3. Clarification: > "Restore logical state" stage is the longest one and it uses one thread, so > CPU/IO utilization is very low. Execution of "restorePartitionStates" in some > ExecutorService would drastically speed up the whole node startup process > because it's the main reason of restore being slow in this particular case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033434#comment-17033434 ] Ryabov Dmitrii commented on IGNITE-12049: - [~ascherbakov], I expanded description of setters and created ticket for readme's page [1]. [1] https://issues.apache.org/jira/browse/IGNITE-12640 > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Time Spent: 2h > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). > Make sure that custom authenticators can use these attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12557) Destroy of big cache which is not only cache in cache group causes IgniteOOME
[
https://issues.apache.org/jira/browse/IGNITE-12557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12557:
--
Fix Version/s: 2.9
> Destroy of big cache which is not only cache in cache group causes IgniteOOME
> -
>
> Key: IGNITE-12557
> URL: https://issues.apache.org/jira/browse/IGNITE-12557
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Aleksey Plekhanov
>Assignee: Alexey Scherbakov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When {{destroyCache()}} is invoked {{checkpointReadLock}} is held by exchange
> thread during all time cache entries are cleaning. Meanwhile,
> {{db-checkpoint-thread}} can't acquire checkpoint write lock and can't start
> checkpoint. After some time all page-memory has filled with dirty pages and
> attempt to acquire a new page causes IgniteOOM exception:
> {noformat}
> class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Failed to
> find a page for eviction [segmentCapacity=40485, loaded=15881,
> maxDirtyPages=11910, dirtyPages=15881, cpPages=0, pinnedInSegment=0,
> failedToPrepare=15881]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.tryToFindSequentially(PageMemoryImpl.java:2420)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.removePageForReplacement(PageMemoryImpl.java:2314)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:743)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:679)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:158)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:5872)
> at
> org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compareKeys(CacheDataTree.java:435)
> at
> org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:384)
> at
> org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:63)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:5214)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:5134)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:298)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5723)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run(BPlusTree.java:278)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5709)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:364)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read(BPlusTree.java:5910)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2077)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:2007)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1838)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.clear(IgniteCacheOffheapManagerImpl.java:2963)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.clear(GridCacheOffheapManager.java:2611)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.removeCacheData(IgniteCacheOffheapManagerImpl.java:296)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.stopCache(IgniteCacheOffheapManagerImpl.java:258)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.stopCache(CacheGroupContext.java:825)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1070)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2617)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2596)
> at
> org.apache.ignite.int
