[jira] [Commented] (IGNITE-12810) [IEP-39] Management API to cancel compute tasks.
[ https://issues.apache.org/jira/browse/IGNITE-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065372#comment-17065372 ] Anton Vinogradov commented on IGNITE-12810: --- [~nizhikov], Looks good to me. Don't forget to obtain the Visa before the merge. > [IEP-39] Management API to cancel compute tasks. > > > Key: IGNITE-12810 > URL: https://issues.apache.org/jira/browse/IGNITE-12810 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-39 > Time Spent: 10m > Remaining Estimate: 0h > > Ignite provides many API to deploy and execute user-provided code on the > server nodes inside the same JVM as the Ignite process runs. > Ignite has many APIs that allocate many resources on the server nodes, also. > In case of some buggy code that consumes many system resources(CPU, RAM, > flood network) or heavy query the whole cluster can become unstable. > We should provide to the cluster administrator the ability to stop any user > deployed task. > JMX beans to cancel listed tasks should be introduced: > * Compute task > In the scope of IEP-35 System view API introduced. > A new API should use the same identifier that is used in corresponding System > View. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ostanin reassigned IGNITE-12832:
-
Assignee: Oleg Ostanin
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add such an ability by
> adding {{--attr-some-attr-name=attrValue}} command line option.
> To prevent command line pollution I also suggest to implement {{.properties}}
> file support, so that command line arguments (including {{--attr*}}
> arguments) could be hidden in a file specified by {{--config
> filename.properties}}. In case of duplication explicit command line arguments
> should take precedence over arguments set in {{.properties}} file.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065393#comment-17065393
]
Stepachev Maksim commented on IGNITE-12220:
---
The code is LGTM again, but I add comments about style. Please fix it.
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12811) [IEP-39] Management API to cancel services.
[ https://issues.apache.org/jira/browse/IGNITE-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-12811: Assignee: Nikolay Izhikov > [IEP-39] Management API to cancel services. > --- > > Key: IGNITE-12811 > URL: https://issues.apache.org/jira/browse/IGNITE-12811 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-39 > > Ignite provides many API to deploy and execute user-provided code on the > server nodes inside the same JVM as the Ignite process runs. > Ignite has many APIs that allocate many resources on the server nodes, also. > In case of some buggy code that consumes many system resources(CPU, RAM, > flood network) or heavy query the whole cluster can become unstable. > We should provide to the cluster administrator the ability to stop any user > deployed task. > JMX beans to cancel listed tasks should be introduced: > * Services > In the scope of IEP-35 System view API introduced. > A new API should use the same identifier that is used in corresponding System > View. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065420#comment-17065420
]
Ignite TC Bot commented on IGNITE-12220:
{panel:title=Branch: [pull/6904/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=5150426&buildTypeId=IgniteTests24Java8_RunAll]
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12805) Node fails to restart
[
https://issues.apache.org/jira/browse/IGNITE-12805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12805:
-
Ignite Flags: (was: Release Notes Required)
> Node fails to restart
> -
>
> Key: IGNITE-12805
> URL: https://issues.apache.org/jira/browse/IGNITE-12805
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Sarunas Valaskevicius
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
>
> 1. nodes have default persistence false, but there is a cache region with
> persistence on.
> 2. a cluster starts ok with ignite data directory clean
> 3. but when the nodes are restarted, they fail and can never join the cluster
> again:
>
> {code:java}
> 12:352020-03-19_13:34:30.273 [main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12784) Server Node comes down with : (err) Failed to notify listener: GridDhtTxPrepareFuture Error
[ https://issues.apache.org/jira/browse/IGNITE-12784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Veena Mithare updated IGNITE-12784: --- Affects Version/s: 2.8 > Server Node comes down with : (err) Failed to notify listener: > GridDhtTxPrepareFuture Error > --- > > Key: IGNITE-12784 > URL: https://issues.apache.org/jira/browse/IGNITE-12784 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8, 2.7.6 >Reporter: Veena Mithare >Priority: Major > > We have a 3 node server cluster ( Issue observed in 2.7.6, could not test in > 2.8.0 because I am unable to bring up the dbeaver in 2.8.0 with > securityplugin enabled > )([http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html]) > A 4th node joins as a client with a continuous query on a Table A( > Transaction_mode = transactional ). > Now If I bring the client down and issue an update to the Table A within > failureDetectionTimeout 3 , I get the following error and *this error* > *brings the server down:* > "(err) Failed to notify listener: GridDhtTxPrepareFuture Error" > === > Basically the server , tries to update the record on the Table A, and tries > to notify Client since it had registered a continuous query for Table A. > But since the Client Node has been brought down, it undeploys the > remotefilterfactory lambda. Hence the server is no longer able to complete the > transaction . > */This also brings the server down./ > * > How can I resolve this issue ? > === > Please find the complete stack trace for this error : > 2020-03-13 17:13:40,145 [sys-stripe-19-#20] ERROR [] - Critical system error > detected. Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED, > SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext > [type=CRITICAL_ERROR, err=java.lang.NoClassDefFoundError: > com/companyname/projectname/Module/helper/ContinuousQueryHelper]] > java.lang.NoClassDefFoundError: > com/companyname/projectname/Module/helper/ContinuousQueryHelper > at > com.companyname.projectname.Module.helper.ContinuousQueryHelper$ModuleTableRemoteFilterFactory$1.evaluate(ContinuousQueryHelper.java:289) > ~[?:?] > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.filter(CacheContinuousQueryHandler.java:833) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2.onEntryUpdated(CacheContinuousQueryHandler.java:422) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:426) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:1584) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:741) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3788) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:3782) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:497) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56) > ~[ignite-core-2.7.6.jar:2.7.6] > at > org.ap
[jira] [Created] (IGNITE-12834) [TeamCity] Suites fails with the execution timeout
Nikolay Izhikov created IGNITE-12834: Summary: [TeamCity] Suites fails with the execution timeout Key: IGNITE-12834 URL: https://issues.apache.org/jira/browse/IGNITE-12834 Project: Ignite Issue Type: Bug Reporter: Nikolay Izhikov Right now it's a common case when some random suite ends with the execution timeout error. Examples: * https://ci.ignite.apache.org/viewLog.html?buildId=5152046&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache7 * https://ci.ignite.apache.org/viewLog.html?buildId=5151963&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_JavaThinClient We need to investigate those failures and fix the root cause of it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12833) JDBC thin client SELECT hangs under 2.8.0
Veena Mithare created IGNITE-12833:
--
Summary: JDBC thin client SELECT hangs under 2.8.0
Key: IGNITE-12833
URL: https://issues.apache.org/jira/browse/IGNITE-12833
Project: Ignite
Issue Type: Bug
Components: security
Affects Versions: 2.8
Reporter: Veena Mithare
|
|When security is enabled, and an update or select sql is issued from dbeaver,
the security context in
class GridIOManager ,
method -createGridIoMessage -
line - ctx.security().securityContext() returns the securitycontext of the
thin client.
The message generated out of createGridIoMessage is passed on to the next
node.
This is used in
class - IgniteSecurityProcessor
method - ( withContext)
line - ctx.discovery().node(uuid)
on the next node :
@Override public OperationSecurityContext withContext(UUID nodeId)
{ return withContext( secCtxs.computeIfAbsent(nodeId,
uuid -> nodeSecurityContext( marsh,
U.resolveClassLoader(ctx.config()), ctx.discovery().node(uuid)
) ) ); }
The ctx.discovery().node(uuid) used to
determine the ClusterNode that is passed into nodeSecurityContext() returns
null, since the uuid is that of the remote client id not the remote node id.
Hence
class: SecurityUtils.java
method : nodeSecurityContext
line : byte[] subjBytes =
node.attribute(IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_V2);
Throws null pointer exception since node is null.
Related ticket :
IGNITE-12579
Related discussion :
[http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html#a31847]|
|
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-12832:
--
Description:
Change [1] introduced user attributes for various thin clients.
{{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
impossible to set user attributes in corresponding {{GridClientConfiguration}}
currenly. I suggest to add {{.properties}} file support, so that user
attributes could be set in a file specified by {{--user-attrs-file
/path/to/filename.properties}} as {{attrName=attrValue}} lines.
[1] https://issues.apache.org/jira/browse/IGNITE-12049
was:
Change [1] introduced user attributes for various thin clients.
{{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
impossible to set user attributes in corresponding {{GridClientConfiguration}}
currenly. I suggest to add such an ability by adding
{{--attr-some-attr-name=attrValue}} command line option.
To prevent command line pollution I also suggest to implement {{.properties}}
file support, so that command line arguments (including {{--attr*}} arguments)
could be hidden in a file specified by {{--config filename.properties}}. In
case of duplication explicit command line arguments should take precedence over
arguments set in {{.properties}} file.
[1] https://issues.apache.org/jira/browse/IGNITE-12049
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12833) JDBC thin client SELECT hangs under 2.8.0
[
https://issues.apache.org/jira/browse/IGNITE-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Garus updated IGNITE-12833:
-
Labels: iep-41 (was: )
> JDBC thin client SELECT hangs under 2.8.0
> -
>
> Key: IGNITE-12833
> URL: https://issues.apache.org/jira/browse/IGNITE-12833
> Project: Ignite
> Issue Type: Bug
> Components: security
>Affects Versions: 2.8
>Reporter: Veena Mithare
>Priority: Major
> Labels: iep-41
>
> |
> |When security is enabled, and an update or select sql is issued from
> dbeaver, the security context in
> class GridIOManager ,
> method -createGridIoMessage -
> line - ctx.security().securityContext() returns the securitycontext of the
> thin client.
> The message generated out of createGridIoMessage is passed on to the next
> node.
> This is used in
> class - IgniteSecurityProcessor
> method - ( withContext)
> line - ctx.discovery().node(uuid)
> on the next node :
> @Override public OperationSecurityContext withContext(UUID nodeId)
> { return withContext( secCtxs.computeIfAbsent(nodeId,
>
> uuid -> nodeSecurityContext( marsh,
> U.resolveClassLoader(ctx.config()), ctx.discovery().node(uuid)
> ) ) ); }
> The ctx.discovery().node(uuid) used to
> determine the ClusterNode that is passed into nodeSecurityContext() returns
> null, since the uuid is that of the remote client id not the remote node id.
> Hence
> class: SecurityUtils.java
> method : nodeSecurityContext
> line : byte[] subjBytes =
> node.attribute(IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_V2);
> Throws null pointer exception since node is null.
> Related ticket :
> IGNITE-12579
>
> Related discussion :
> [http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html#a31847]|
> |
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12808) Allow create tables for existing caches
[ https://issues.apache.org/jira/browse/IGNITE-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-12808: - Assignee: Ivan Daschinskiy > Allow create tables for existing caches > --- > > Key: IGNITE-12808 > URL: https://issues.apache.org/jira/browse/IGNITE-12808 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Mikhail Cherkasov >Assignee: Ivan Daschinskiy >Priority: Major > > If you have a big cache with a lot of data and you need to index it, right > now you have to destroy cache and create a new one to index your data. Or > create a new cache with a table and reload it to data to the new cache which > definitely is time-consuming and super inconvenient. > I believe we can allow users to create tables for existing caches. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12810) [IEP-39] Management API to cancel compute tasks.
[
https://issues.apache.org/jira/browse/IGNITE-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065801#comment-17065801
]
Ignite TC Bot commented on IGNITE-12810:
{panel:title=Branch: [pull/7555/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=5152531&buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-39] Management API to cancel compute tasks.
>
>
> Key: IGNITE-12810
> URL: https://issues.apache.org/jira/browse/IGNITE-12810
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-39
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite provides many API to deploy and execute user-provided code on the
> server nodes inside the same JVM as the Ignite process runs.
> Ignite has many APIs that allocate many resources on the server nodes, also.
> In case of some buggy code that consumes many system resources(CPU, RAM,
> flood network) or heavy query the whole cluster can become unstable.
> We should provide to the cluster administrator the ability to stop any user
> deployed task.
> JMX beans to cancel listed tasks should be introduced:
> * Compute task
> In the scope of IEP-35 System view API introduced.
> A new API should use the same identifier that is used in corresponding System
> View.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12789) Tracking page repairing has no WAL record associated with it
[ https://issues.apache.org/jira/browse/IGNITE-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065837#comment-17065837 ] Andrey N. Gura commented on IGNITE-12789: - [~ibessonov] LGTM. Merged to master branch. Thanks for your contribution. > Tracking page repairing has no WAL record associated with it > > > Key: IGNITE-12789 > URL: https://issues.apache.org/jira/browse/IGNITE-12789 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) > > In order for tracking pages to work properly they should be persisted on > disk, it means that failed checkpoint scenario should be supported. Tracking > pages restoration has no associated WAL record so in that case binary > recovery could leave them broken after a valid repair. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
[
https://issues.apache.org/jira/browse/IGNITE-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065898#comment-17065898
]
Andrey N. Gura commented on IGNITE-12769:
-
[~nizhikov] LGTM. Thanks for this fix.
I think IGNITE-12767 could be also resolved.
Please, proceed with merge.
> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
> To the following maps values add but never remove (i.e. on remove
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12828) Intermittent [Failed to notify direct custom event listener] exception on node shutdown
[ https://issues.apache.org/jira/browse/IGNITE-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-12828: -- Summary: Intermittent [Failed to notify direct custom event listener] exception on node shutdown (was: Intermittent "Failed to notify direct custom event listener" exception on node shutdown) > Intermittent [Failed to notify direct custom event listener] exception on > node shutdown > --- > > Key: IGNITE-12828 > URL: https://issues.apache.org/jira/browse/IGNITE-12828 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: sbcf > > +*Reproducer*+: > Run a server node > Run a client node that: > * Creates cache "cache1" > * Deploys a grid service that starts a continuous query against "cache1" in > method init() > * Leaves the cluster > +*Actual result*+ > Intermittent exception in the client node: > [16:54:38,758][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager] > Failed to notify direct custom event listener: StartRoutineDiscoveryMessage > [startReqData=StartRequestData > [prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@63ae71a9, > clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler > [returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@594bf5b8, > cacheName=CALC_REQUESTS, rmtFilter=null, rmtFilterDep=null, internal=false, > notifyExisting=false, oldValRequired=true, sync=false, ignoreExpired=true, > taskHash=0, skipPrimaryCheck=false, locOnly=false, keepBinary=true, > ackBuf=null, cacheId=-1608655250, initTopVer=null, nodeLeft=false, > ignoreClsNotFound=false, nodeId=null, routineId=null], bufSize=1, interval=0, > autoUnsubscribe=true], keepBinary=true, > routineId=021dd2ce-3d8a-41c1-a4d0-b625ea1284f4] > java.lang.NullPointerException > at > org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82) > at > org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96) > at > org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424) > at > org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110) > at > org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202) > at > org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:722) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2683) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2721) > at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) > at java.lang.Thread.run(Thread.java:745) > [16:54:39,725][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager] > Failed to notify direct custom event listener: StartRoutineDiscoveryMessage > [startReqData=StartRequestData > [prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@7462c96c, > clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler > [returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@6451dd70, > cacheName=DISTRIBUTED_REQUESTS, rmtFilter=null, rmtFilterDep=null, > internal=false, notifyExisting=false, oldValRequired=true, sync=false, > ignoreExpired=true, taskHash=0, skipPrimaryCheck=false, locOnly=false, > keepBinary=true, ackBuf=null, cacheId=1419803136, initTopVer=null, > nodeLeft=false, ignoreClsNotFound=false, nodeId=null, routineId=null], > bufSize=1, interval=0, autoUnsubscribe=true], keepBinary=true, > routineId=1fca5f04-d220-49ac-850a-0d4527e22eef] > java.lang.NullPointerException > at > org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82) > at > org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96) > at > org.apache.ignite.inte
[jira] [Resolved] (IGNITE-12767) MetricRegistryMBean is not thread safe
[
https://issues.apache.org/jira/browse/IGNITE-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-12767.
--
Resolution: Duplicate
> MetricRegistryMBean is not thread safe
> --
>
> Key: IGNITE-12767
> URL: https://issues.apache.org/jira/browse/IGNITE-12767
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
>
> {{MetricRegistryMBean}} is not thread safe due to usage of {{histogramNames}}
> instance of {{HashMap}} class. Changing {{HashMap}} to {{ConcurrentHashMap}}
> will not help a lot (likely) because method
> {{MetricUtils.histogramBucketNames()}} uses just {{put}} method
> ({{putIfAbsent}} will help I believe).
> {{OpenCensusExporterSpi}} uses the same
> {{MetricUtils.histogramBucketNames()}} method. But it isn't issue for this
> exporter because it is single threaded.
> Also {{MetricUtils.histogramBucketNames()}} method is responsible for
> histogram bucket's name representation. I believe that it is responsibility
> of metric exporter and this method should be removed from {{MetricUtils}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066438#comment-17066438
]
Oleg Ostanin commented on IGNITE-12832:
---
I'll remove spaces from lines like
```
list.add(optional(CMD_SSL_PROTOCOL, "SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]"));
```
because it's misleading, we should divide parameters in a list only with single
comma.
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066438#comment-17066438
]
Oleg Ostanin edited comment on IGNITE-12832 at 3/25/20, 6:48 AM:
-
I'll remove spaces from lines like
{code:java}
// code placeholder
list.add(optional(CMD_SSL_PROTOCOL, "SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]"));
{code}
because it's misleading, we should divide parameters in a list only with single
comma.
was (Author: oleg-a-ostanin):
I'll remove spaces from lines like
```
list.add(optional(CMD_SSL_PROTOCOL, "SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]"));
```
because it's misleading, we should divide parameters in a list only with single
comma.
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066438#comment-17066438
]
Oleg Ostanin edited comment on IGNITE-12832 at 3/25/20, 6:48 AM:
-
I'll remove spaces from lines like
list.add(optional(CMD_SSL_PROTOCOL, "SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]"));
because it's misleading, we should divide parameters in a list only with single
comma.
was (Author: oleg-a-ostanin):
I'll remove spaces from lines like
{code:java}
// code placeholder
list.add(optional(CMD_SSL_PROTOCOL, "SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]"));
{code}
because it's misleading, we should divide parameters in a list only with single
comma.
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066438#comment-17066438
]
Oleg Ostanin edited comment on IGNITE-12832 at 3/25/20, 6:50 AM:
-
I'll remove spaces from lines like
{code:java}
list.add(optional(CMD_SSL_PROTOCOL, "SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]"));
{code}
because it's misleading, we should divide parameters in a list only with single
comma.
was (Author: oleg-a-ostanin):
I'll remove spaces from lines like
list.add(optional(CMD_SSL_PROTOCOL, "SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]"));
because it's misleading, we should divide parameters in a list only with single
comma.
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
