[jira] [Comment Edited] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916143#comment-16916143
]
Ivan Pavlukhin edited comment on IGNITE-7285 at 8/26/19 9:24 PM:
-
[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like
IgniteCacheReplicatedQuerySelfTest,
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is
passed. Can you share an example in which Query or execution mode you can see
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout
propagation
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
It seems that _default timeout_ is not used in that class in PR. But I must
say that I do not fully understand why query timeout is used by transactional
commands.
bq. 2. I observed that QueryParameters initialization is occurring in
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does
not have GridKernalContext reference so it will not be feasible to access the
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is
used only in {{QueryParser}}, we can make it aware of ignite configuration by
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class
responsible for {{QueryParameters}} construction in presence of default values
in configuration (only timeout so far). Are there major disadvantages of such
approach?
.bq 3. If you observe timeout in SqlFieldsQuery get validated in
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is
not so trivial. But I am still concerned how usable it would be? It is
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when
default timeout is configured. Actually, to distinguish between _unset_ vs
_disabled_ timeout I thought about using -1 to indicate that a user did not
call {{setTimeout}}. Of course some care is needed to implement such approach
properly.
One more additional note. We have
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should
consider a _default timeout_ for it, at least roughly estimate how challenging
is it.
was (Author: pavlukhin):
[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like
IgniteCacheReplicatedQuerySelfTest,
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is
passed. Can you share an example in which Query or execution mode you can see
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout
propagation
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
It seems that _default timeout_ is not used in that class in PR. But I must
say that I do not fully understand why query timeout is used by transactional
commands.
bq. 2. I observed that QueryParameters initialization is occurring in
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does
not have GridKernalContext reference so it will not be feasible to access the
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is
used only in {{QueryParser}}, we can make it aware of ignite configuration by
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class
responsible for {{QueryParameters}} construction in presence of default values
in configuration (only timeout so far). Are there major disadvantages of such
approach?
.bq If you observe timeout in SqlFieldsQuery get validated in
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is
not so trivial. But I am still concerned how usable it would be? It is
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when
default timeout is configured. Actually, to distinguish between _unset_ vs
_disabled_ timeout I thought about using -1 to indicate that a user did not
call {{setTimeout}}. Of course some care is needed to implement such approach
properly.
One more additional note. We have
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we sho
[jira] [Comment Edited] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916143#comment-16916143
]
Ivan Pavlukhin edited comment on IGNITE-7285 at 8/26/19 9:24 PM:
-
[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like
IgniteCacheReplicatedQuerySelfTest,
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is
passed. Can you share an example in which Query or execution mode you can see
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout
propagation
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
It seems that _default timeout_ is not used in that class in PR. But I must
say that I do not fully understand why query timeout is used by transactional
commands.
bq. 2. I observed that QueryParameters initialization is occurring in
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does
not have GridKernalContext reference so it will not be feasible to access the
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is
used only in {{QueryParser}}, we can make it aware of ignite configuration by
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class
responsible for {{QueryParameters}} construction in presence of default values
in configuration (only timeout so far). Are there major disadvantages of such
approach?
bq. 3. If you observe timeout in SqlFieldsQuery get validated in
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is
not so trivial. But I am still concerned how usable it would be? It is
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when
default timeout is configured. Actually, to distinguish between _unset_ vs
_disabled_ timeout I thought about using -1 to indicate that a user did not
call {{setTimeout}}. Of course some care is needed to implement such approach
properly.
One more additional note. We have
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should
consider a _default timeout_ for it, at least roughly estimate how challenging
is it.
was (Author: pavlukhin):
[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like
IgniteCacheReplicatedQuerySelfTest,
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is
passed. Can you share an example in which Query or execution mode you can see
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout
propagation
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
It seems that _default timeout_ is not used in that class in PR. But I must
say that I do not fully understand why query timeout is used by transactional
commands.
bq. 2. I observed that QueryParameters initialization is occurring in
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does
not have GridKernalContext reference so it will not be feasible to access the
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is
used only in {{QueryParser}}, we can make it aware of ignite configuration by
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class
responsible for {{QueryParameters}} construction in presence of default values
in configuration (only timeout so far). Are there major disadvantages of such
approach?
.bq 3. If you observe timeout in SqlFieldsQuery get validated in
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is
not so trivial. But I am still concerned how usable it would be? It is
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when
default timeout is configured. Actually, to distinguish between _unset_ vs
_disabled_ timeout I thought about using -1 to indicate that a user did not
call {{setTimeout}}. Of course some care is needed to implement such approach
properly.
One more additional note. We have
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and w
[jira] [Commented] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916143#comment-16916143
]
Ivan Pavlukhin commented on IGNITE-7285:
[~samaitra],
bq. 1. I ran tests for Distributed Query and local query like
IgniteCacheReplicatedQuerySelfTest,
IgniteCacheLocalQueryCancelOrTimeoutSelfTest and I see that timeout value is
passed. Can you share an example in which Query or execution mode you can see
that timeout is not passed?
Good to know that it works for different cases. I am concerned about timeout
propagation
{{org.apache.ignite.internal.processors.query.h2.CommandProcessor#processTxCommand}}.
It seems that _default timeout_ is not used in that class in PR. But I must
say that I do not fully understand why query timeout is used by transactional
commands.
bq. 2. I observed that QueryParameters initialization is occurring in
QueryParameters.fromQuery(SqlFieldsQuery qry) method and QueryParameters does
not have GridKernalContext reference so it will not be feasible to access the
ctx.config().getDefaultQueryTimeout() upon QueryParameters initialization.
{{org.apache.ignite.internal.processors.query.h2.QueryParameters#fromQuery}} is
used only in {{QueryParser}}, we can make it aware of ignite configuration by
placing {{fromQuery}} method to {{QueryParser}} or by introducing a class
responsible for {{QueryParameters}} construction in presence of default values
in configuration (only timeout so far). Are there major disadvantages of such
approach?
.bq If you observe timeout in SqlFieldsQuery get validated in
QueryUtils.validateTimeout(timeout, timeUnit) and it asserts that timeout value
of SqlFieldsQuery is more than equal 0. Now if we allow feature to disable
timeout of particular query using (SqlFieldsQuery.setTimeout(0)) then
ctx.config().getDefaultQueryTimeout() will never get used.
I understood that disabling a timeout in presence of non-zero default value is
not so trivial. But I am still concerned how usable it would be? It is
desirable to protect a user from surprising behavior of {{setTimeout(0)}} when
default timeout is configured. Actually, to distinguish between _unset_ vs
_disabled_ timeout I thought about using -1 to indicate that a user did not
call {{setTimeout}}. Of course some care is needed to implement such approach
properly.
One more additional note. We have
{{org.apache.ignite.internal.sql.command.SqlBulkLoadCommand}} and we should
consider a _default timeout_ for it, at least roughly estimate how challenging
is it.
> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be
> very useful to have default timeout value provided on cache startup. Let's
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12107) Docs: request setting IGNITE_HOME to permanent location in Docker
Denis Magda created IGNITE-12107: Summary: Docs: request setting IGNITE_HOME to permanent location in Docker Key: IGNITE-12107 URL: https://issues.apache.org/jira/browse/IGNITE-12107 Project: Ignite Issue Type: Bug Components: documentation Reporter: Denis Magda Fix For: 2.7.6 Update Ignite Docker and Kubernetes documentation stating that IGNITE_HOME, as well as WAL and persistent store directories, must point to the volumes that are not erased or destroyed on restarts. Please refer to this thread for more details: http://apache-ignite-developers.2346864.n4.nabble.com/Metastore-disappears-in-Docker-on-restarts-td43107.html -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12106) Rework ignite binary metadata exception for ease of troubleshooting
Denis Magda created IGNITE-12106:
Summary: Rework ignite binary metadata exception for ease of
troubleshooting
Key: IGNITE-12106
URL: https://issues.apache.org/jira/browse/IGNITE-12106
Project: Ignite
Issue Type: Bug
Components: cache, persistence
Affects Versions: 2.7.5, 2.7.6
Reporter: Denis Magda
Fix For: 2.7.6
An exception of this kind happens regularly and its message doesn't suggest why
it took place and how to fix the issue:
{noformat}
Cannot find metadata for object with compact footer: 2097659979
{noformat}
See this thread for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Metastore-disappears-in-Docker-on-restarts-td43107.html
As a solution, let's rework this exception to ensure that the way like that
"Ignite work directory might be cleared on restarts. Ensure that IGNITE_HOME
doesn't point to a temp folder or any other folder that is destroyed/erased on
restarts. Presently, IGNITE_HOME points to..."
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12102) idle_verify should show info about lost partitions
[
https://issues.apache.org/jira/browse/IGNITE-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916063#comment-16916063
]
Ignite TC Bot commented on IGNITE-12102:
{panel:title=Branch: [pull/6810/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=4537835&buildTypeId=IgniteTests24Java8_RunAll]
> idle_verify should show info about lost partitions
> --
>
> Key: IGNITE-12102
> URL: https://issues.apache.org/jira/browse/IGNITE-12102
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the current implementation, idle_verify do not show lost partitions, and
> check shows that everything is fine but it is not true.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12105) [ML] Implement projection vector.
Ravil Galeyev created IGNITE-12105: -- Summary: [ML] Implement projection vector. Key: IGNITE-12105 URL: https://issues.apache.org/jira/browse/IGNITE-12105 Project: Ignite Issue Type: Task Components: ml Reporter: Ravil Galeyev Assignee: Ravil Galeyev According to the discussion in [PR|[https://github.com/apache/ignite/pull/6567]] it's nice to have a vector projecting by some filter. Such kind of preprocessor should be implemented. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-9410) Add transactions support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16915902#comment-16915902 ] Igor Sapego commented on IGNITE-9410: - [~alex_pl] Added 2 minor comments to PR. > Add transactions support to thin clients > > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Task > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Fix For: 2.8 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently only ODBC and JDBC drivers support transactions and in not very > efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS > and Python clients. > Key pieces: > # Add API to relevant clients > # Review listener logic - currently we create separate threads. But is it > really needed? > ## If there is an implicit operation and no ongoing transaction, then > operation might be executed right away > ## If cache operations are decoupled from threads, then we can resort to > reactive approach, when multiple transactions could be executed from the same > thread -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (IGNITE-12104) Check deployment from cache before to load it from local or version storage
[
https://issues.apache.org/jira/browse/IGNITE-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-12104:
--
Assignee: Vladislav Pyatkov
> Check deployment from cache before to load it from local or version storage
> ---
>
> Key: IGNITE-12104
> URL: https://issues.apache.org/jira/browse/IGNITE-12104
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> In several cases, when using p2p class loading, consume a lot of time
> checking loader hierarchy.
> This scenario easy to see by that stack in samples of profile:
> {noformat}
> "pub-#3217917%DPL_GRID%DplGridNodeName%" #3223897 prio=5 os_prio=0
> tid=0x7f47a414f800 nid=0x1dca46 runnable [0x7eaca31b]
> java.lang.Thread.State: RUNNABLE
> at java.lang.String.concat(String.java:2034)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:364)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> - locked <0x7f4c8dd6c888> (a java.lang.Object)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
> - locked <0x7f4c8db4f530> (a java.lang.Object)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
> - locked <0x7f4ba0138340> (a
> com.sbt.core.envelope.container.loader.NamedClassLoader)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
> - locked <0x7f4ba012a800> (a
> com.sbt.core.envelope.container.loader.ImplClassLoader)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:462)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:983)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> We can to put down the issue by searching class from deployment cache (it
> will give a result if class was loaded earlier) before to go to class loader.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12104) Check deployment from cache before to load it from local or version storage
[
https://issues.apache.org/jira/browse/IGNITE-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12104:
---
Description:
In several cases, when using p2p class loading, consume a lot of time checking
loader hierarchy.
This scenario easy to see by that stack in samples of profile:
{noformat}
"pub-#3217917%DPL_GRID%DplGridNodeName%" #3223897 prio=5 os_prio=0
tid=0x7f47a414f800 nid=0x1dca46 runnable [0x7eaca31b]
java.lang.Thread.State: RUNNABLE
at java.lang.String.concat(String.java:2034)
at java.net.URLClassLoader$1.run(URLClassLoader.java:364)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked <0x7f4c8dd6c888> (a java.lang.Object)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4c8db4f530> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba0138340> (a
com.sbt.core.envelope.container.loader.NamedClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba012a800> (a
com.sbt.core.envelope.container.loader.ImplClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:462)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:983)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
We can to put down the issue by searching class from deployment cache (it will
give a result if class was loaded earlier) before to go to class loader.
was:
In several cases, when using p2p class loading, consume a lot of time checking
loader hierarchy.
This scenario easy to see by that stack in samples of profile:
{noformat}
"pub-#3217917%DPL_GRID%DplGridNodeName%" #3223897 prio=5 os_prio=0
tid=0x7f47a414f800 nid=0x1dca46 runnable [0x7eaca31b]
java.lang.Thread.State: RUNNABLE
at java.lang.String.concat(String.java:2034)
at java.net.URLClassLoader$1.run(URLClassLoader.java:364)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked <0x7f4c8dd6c888> (a java.lang.Object)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4c8db4f530> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba0138340> (a
com.sbt.core.envelope.container.loader.NamedClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba012a800> (a
com.sbt.core.envelope.container.loader.ImplClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:462)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:983)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.j
[jira] [Updated] (IGNITE-12104) Check deployment from cache before to load it from local or version storage
[
https://issues.apache.org/jira/browse/IGNITE-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12104:
---
Description:
In several cases, when using p2p class loading, consume a lot of time checking
loader hierarchy.
This scenario easy to see by that stack in samples of profile:
{noformat}
"pub-#3217917%DPL_GRID%DplGridNodeName%" #3223897 prio=5 os_prio=0
tid=0x7f47a414f800 nid=0x1dca46 runnable [0x7eaca31b]
java.lang.Thread.State: RUNNABLE
at java.lang.String.concat(String.java:2034)
at java.net.URLClassLoader$1.run(URLClassLoader.java:364)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked <0x7f4c8dd6c888> (a java.lang.Object)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4c8db4f530> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba0138340> (a
com.sbt.core.envelope.container.loader.NamedClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba012a800> (a
com.sbt.core.envelope.container.loader.ImplClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:462)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:983)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
We can to put down the issue by searching class from deployment cache (it will
give a result if class was loaded before) before to go to class loader.
was:
{noformat}
"pub-#3217917%DPL_GRID%DplGridNodeName%" #3223897 prio=5 os_prio=0
tid=0x7f47a414f800 nid=0x1dca46 runnable [0x7eaca31b]
java.lang.Thread.State: RUNNABLE
at java.lang.String.concat(String.java:2034)
at java.net.URLClassLoader$1.run(URLClassLoader.java:364)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked <0x7f4c8dd6c888> (a java.lang.Object)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4c8db4f530> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba0138340> (a
com.sbt.core.envelope.container.loader.NamedClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba012a800> (a
com.sbt.core.envelope.container.loader.ImplClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:462)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:983)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.interna
[jira] [Created] (IGNITE-12104) Check deployment from cache before to load it from local or version storage
Vladislav Pyatkov created IGNITE-12104:
--
Summary: Check deployment from cache before to load it from local
or version storage
Key: IGNITE-12104
URL: https://issues.apache.org/jira/browse/IGNITE-12104
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
Fix For: 2.8
{noformat}
"pub-#3217917%DPL_GRID%DplGridNodeName%" #3223897 prio=5 os_prio=0
tid=0x7f47a414f800 nid=0x1dca46 runnable [0x7eaca31b]
java.lang.Thread.State: RUNNABLE
at java.lang.String.concat(String.java:2034)
at java.net.URLClassLoader$1.run(URLClassLoader.java:364)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked <0x7f4c8dd6c888> (a java.lang.Object)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4c8db4f530> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba0138340> (a
com.sbt.core.envelope.container.loader.NamedClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba012a800> (a
com.sbt.core.envelope.container.loader.ImplClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:462)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:983)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-5355) Create task with release tools
[ https://issues.apache.org/jira/browse/IGNITE-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16915669#comment-16915669 ] Dmitriy Pavlov commented on IGNITE-5355: [~lexa] last 2 releases I was release manager. I've collected notes manually, and I described it here: https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.0.PrepareReleaseNotes But I have an idea to ask INFRA for additional field Release Notes (and flag Release Notes Required). So once we have these fields it is easier to automate RN collection. > Create task with release tools > -- > > Key: IGNITE-5355 > URL: https://issues.apache.org/jira/browse/IGNITE-5355 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Chetaev >Assignee: Aleksey Chetaev >Priority: Major > > 1. Create task for auto-generate HTML formatted releases notes -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12103) Change the default ignite work directory once again to avoid writing to ~/work
Ilya Kasnacheev created IGNITE-12103:
Summary: Change the default ignite work directory once again to
avoid writing to ~/work
Key: IGNITE-12103
URL: https://issues.apache.org/jira/browse/IGNITE-12103
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7.5
Reporter: Ilya Kasnacheev
Fix For: 2.7.6
While testing 2.7.6-RC1 it came up that we no longer write data to
/tmp/ignite/work, which is good, but now we would instead write to
/home/username/work, which is bad. ~/work is a generic directory not linked to
Ignite in any obvious way, and users will be puzzled by its appearance with
possibilities of data loss or, even worse, their own documents loss if they
happen to have something in Work dir and it gets clobbered/removed by accident.
I suggest changing this default once more, to use either
/home/username/ignite/{work,logs,etc} or ./ignite/{work,logs,etc} by leveraging
user.dir property pointing to current working dir.
Please note that user.dir has its own problems since it is supposed to not be
changeable after JVM is up, but some code still tries to change it.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (IGNITE-12102) idle_verify should show info about lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-12102: --- Assignee: Dmitriy Govorukhin > idle_verify should show info about lost partitions > -- > > Key: IGNITE-12102 > URL: https://issues.apache.org/jira/browse/IGNITE-12102 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > > In the current implementation, idle_verify do not show lost partitions, and > check shows that everything is fine but it is not true. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (IGNITE-12102) idle_verify should show info about lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-12102: --- Assignee: Anton Kalashnikov (was: Dmitriy Govorukhin) > idle_verify should show info about lost partitions > -- > > Key: IGNITE-12102 > URL: https://issues.apache.org/jira/browse/IGNITE-12102 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Govorukhin >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > In the current implementation, idle_verify do not show lost partitions, and > check shows that everything is fine but it is not true. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12102) idle_verify should show info about lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-12102: Fix Version/s: 2.8 > idle_verify should show info about lost partitions > -- > > Key: IGNITE-12102 > URL: https://issues.apache.org/jira/browse/IGNITE-12102 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > > In the current implementation, idle_verify do not show lost partitions, and > check shows that everything is fine but it is not true. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12102) idle_verify should show info about lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-12102: Ignite Flags: (was: Docs Required) > idle_verify should show info about lost partitions > -- > > Key: IGNITE-12102 > URL: https://issues.apache.org/jira/browse/IGNITE-12102 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Govorukhin >Priority: Major > > In the current implementation, idle_verify do not show lost partitions, and > check shows that everything is fine but it is not true. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12102) idle_verify should show info about lost partitions
Dmitriy Govorukhin created IGNITE-12102: --- Summary: idle_verify should show info about lost partitions Key: IGNITE-12102 URL: https://issues.apache.org/jira/browse/IGNITE-12102 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Govorukhin In the current implementation, idle_verify do not show lost partitions, and check shows that everything is fine but it is not true. -- This message was sent by Atlassian Jira (v8.3.2#803003)
