[jira] [Created] (IGNITE-13960) Starvation in mgmt pool caused by MetadataTask execution
Pavel Vinokurov created IGNITE-13960:
Summary: Starvation in mgmt pool caused by MetadataTask execution
Key: IGNITE-13960
URL: https://issues.apache.org/jira/browse/IGNITE-13960
Project: Ignite
Issue Type: Bug
Components: compute
Affects Versions: 2.9.1
Reporter: Pavel Vinokurov
Assignee: Pavel Vinokurov
*Issue:*
Requesting cache metadata from multiple threads causes starvation in the mgmt
pool.
*Root Cause:*
>From the mgmt pool GridCacheCommandHandler.MetadataJob calls
>GridCacheQueryManager#sqlMetadata() and
>GridClosureProcessor#callAsyncNoFailover().get() that executes and waits an
>another internal task. The job response of this task should be also handled
>from the mgmt pool. It causes starvation.
*Proposed Fix:*
Make GridCacheQueryManager#sqlMetadata() asynchronous and apply continuation
for GridCacheCommandHandler.MetadataJob to release a mgmt thread for the time
of completing the future returned by sqlMetadata().
Attached threads with hanging threads:
{code:java}
"mgmt-#10633" #14311 prio=5 os_prio=0 tid=0x560c79117000 nid=0x134c6
waiting on condition [0x7f15baa77000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.sqlMetadata(GridCacheQueryManager.java:1803)
at
org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$MetadataJob.execute(GridCacheCommandHandler.java:1123)
at
org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$MetadataJob.execute(GridCacheCommandHandler.java:1088)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:567)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7069)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:561)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:490)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1270)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2088)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1635)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1255)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:144)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1144)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
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)
"mgmt-#81" #270 prio=5 os_prio=0 tid=0x562323c3c800 nid=0x592 waiting on
condition [0x7fba5f378000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor$ClientChangeGlobalStateComputeRequest.run(GridClusterStateProcessor.java:1979)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4.execute(GridClosureProcessor.java:1943)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:567)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7069)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:561)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:490)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1270)
at
org.apache.ig
Re: Error Codes
Val, excellent, thanks. Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-3690 Mike, feel free to put useful pointers there. - Denis On Tue, Jan 5, 2021 at 2:31 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Mike, Denis, > > Having error codes certainly makes sense. Please send the ticket link, and > we'll go from there. > > -Val > > On Mon, Jan 4, 2021 at 7:50 PM Denis Magda wrote: > > > Do back this idea up of having a glossary of common errors. There is even > > a ticket for that I created a couple of years ago. Can search for it > later. > > > > Val, how about the 3.0 suggestion? Let’s introduce error codes. > > > > On Monday, January 4, 2021, Michael Cherkasov < > michael.cherka...@gmail.com> > > wrote: > > > >> Hi Ilya, > >> > >> It's about logs only, I don't think we need this at the API level. Error > >> codes will make the solutions more searchable. > >> Plus we can build troubleshooting guides based on it, it will help us > >> gather information from user list and StackOverflow. > >> > >> Even a solution for trivial cases will be helpful, once I was requested > >> to join the call late evening because ignite failed to copy WAL file and > >> there just was no space on the disk. > >> While the error was obvious for me, it's not obvious for all users. > >> > >> Let's start from something simple, just assign error codes to > >> absolutely all exceptions first. So next year or two user list will > full of > >> error codes and solutions for them. > >> > >> Might be it's a change for Ignite 3.0? @Val, I think you can help with > >> this question. > >> > >> Any thoughts/comments? > >> > >> Thanks, > >> Mike. > >> > >> сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev >: > >> > >>> Hello! > >>> > >>> I don't think there's a direct link between an exception thrown in > >>> depths of Ignite code, and specific error which may be reported to > user. > >>> > >>> A notorious example is CorruptedTreeException which is known to be > >>> thrown due to incorrect field type in binary object or bad SQL cast. > So we > >>> could document it "If you get IGN13 error this means your persistence > is > >>> corrupted beyond repair. This, or you have a typo in your SQL." - of > course > >>> it will not help anyone. > >>> > >>> This means we can't get to the desired result by application of 1. > >>> > >>> There's got to be a different plan. First of all, we need to decide > >>> what's our target. Is it log, or is it API? > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov < > >>> michael.cherka...@gmail.com>: > >>> > Hi folks, > > I was thinking how we can simplify Ignite clusters troubleshooting and > the best of course if the cluster can do self-healing, like > transaction > cancellation if tx blocks exchange or note restart on OOM error. > However, > sometimes those mechanisms don't work well or user interaction is > required. > Not all errors are obvious for users and it's not clear what actions > required to restore the cluster. > If you google exceptions or error messages and the results can be > ambiguous and not certain because different errors can have similar > exceptions and you need to analyze stack trace to distinguish them. So > googling isn't a straight and easy process in this case. > Almost all major DBs have error codes[1][2][3] > Let's do the same for Ignite, error codes easy to google, so user/dev > list will be significantly more useful. We can have documentation > with an > error code registry and solutions for the errors. > > To implement this we need to do the following: > 1. all error messages/exceptions must have a unique error code(so, all > new PR must NOT be accepted if any exceptions/errors don't have error > codes.) > 2. to avoid error code duplication, all error codes will be stored as > files under some folder. > 3. those files can be a source of documentation for this error code. > > All this files can be empty, but futher, if exception will apper on > user list and someone will find solution, first, other people can > easialy > google it by error code, and second, we can build documentation for > this > error code base on user-list thread/stackoverflow/other source. > > Any thoughts? > > [1] Mysql > https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html > [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search > [3] PostgreSQL > https://www.postgresql.org/docs/10/errcodes-appendix.html > > Thanks, > Mike. > > >>> > > > > -- > > - > > Denis > > > > >
Re: Error Codes
Mike, Denis, Having error codes certainly makes sense. Please send the ticket link, and we'll go from there. -Val On Mon, Jan 4, 2021 at 7:50 PM Denis Magda wrote: > Do back this idea up of having a glossary of common errors. There is even > a ticket for that I created a couple of years ago. Can search for it later. > > Val, how about the 3.0 suggestion? Let’s introduce error codes. > > On Monday, January 4, 2021, Michael Cherkasov > wrote: > >> Hi Ilya, >> >> It's about logs only, I don't think we need this at the API level. Error >> codes will make the solutions more searchable. >> Plus we can build troubleshooting guides based on it, it will help us >> gather information from user list and StackOverflow. >> >> Even a solution for trivial cases will be helpful, once I was requested >> to join the call late evening because ignite failed to copy WAL file and >> there just was no space on the disk. >> While the error was obvious for me, it's not obvious for all users. >> >> Let's start from something simple, just assign error codes to >> absolutely all exceptions first. So next year or two user list will full of >> error codes and solutions for them. >> >> Might be it's a change for Ignite 3.0? @Val, I think you can help with >> this question. >> >> Any thoughts/comments? >> >> Thanks, >> Mike. >> >> сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev : >> >>> Hello! >>> >>> I don't think there's a direct link between an exception thrown in >>> depths of Ignite code, and specific error which may be reported to user. >>> >>> A notorious example is CorruptedTreeException which is known to be >>> thrown due to incorrect field type in binary object or bad SQL cast. So we >>> could document it "If you get IGN13 error this means your persistence is >>> corrupted beyond repair. This, or you have a typo in your SQL." - of course >>> it will not help anyone. >>> >>> This means we can't get to the desired result by application of 1. >>> >>> There's got to be a different plan. First of all, we need to decide >>> what's our target. Is it log, or is it API? >>> >>> Regards, >>> -- >>> Ilya Kasnacheev >>> >>> >>> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov < >>> michael.cherka...@gmail.com>: >>> Hi folks, I was thinking how we can simplify Ignite clusters troubleshooting and the best of course if the cluster can do self-healing, like transaction cancellation if tx blocks exchange or note restart on OOM error. However, sometimes those mechanisms don't work well or user interaction is required. Not all errors are obvious for users and it's not clear what actions required to restore the cluster. If you google exceptions or error messages and the results can be ambiguous and not certain because different errors can have similar exceptions and you need to analyze stack trace to distinguish them. So googling isn't a straight and easy process in this case. Almost all major DBs have error codes[1][2][3] Let's do the same for Ignite, error codes easy to google, so user/dev list will be significantly more useful. We can have documentation with an error code registry and solutions for the errors. To implement this we need to do the following: 1. all error messages/exceptions must have a unique error code(so, all new PR must NOT be accepted if any exceptions/errors don't have error codes.) 2. to avoid error code duplication, all error codes will be stored as files under some folder. 3. those files can be a source of documentation for this error code. All this files can be empty, but futher, if exception will apper on user list and someone will find solution, first, other people can easialy google it by error code, and second, we can build documentation for this error code base on user-list thread/stackoverflow/other source. Any thoughts? [1] Mysql https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search [3] PostgreSQL https://www.postgresql.org/docs/10/errcodes-appendix.html Thanks, Mike. >>> > > -- > - > Denis > >
[VOTE] Release Apache Ignite 3.0.0-alpha1 RC3
Dear Community, The release candidate is uploaded here: https://dist.apache.org/repos/dist/dev/ignite/3.0.0-alpha1-rc3/ Maven staging: https://repository.apache.org/content/repositories/orgapacheignite-1504/ Git tag: https://github.com/apache/ignite-3/tree/3.0.0-alpha1-rc3 For more information on the purpose and the scope of the release, see this discussion: http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-3-0-0-Alpha-release-td50744.html Included Jira tickets: https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%203.0.0-alpha1 Fixes included on top of 3.0.0-alpha1 RC2: - https://issues.apache.org/jira/browse/IGNITE-13959 (ignite.sh doesn't work under 'ksh' or 'fish' shells) - Updated DEVNOTES with a smoke test procedure that can be used for a release candidate. Fixes included on top of 3.0.0-alpha1 RC1: - https://issues.apache.org/jira/browse/IGNITE-13950 (IgniteCliInterfaceTest can fail on Windows) DEVNOTES: https://github.com/apache/ignite-3/blob/3.0.0-alpha1-rc3/DEVNOTES.md The vote is formal, see voting guidelines: https://www.apache.org/foundation/voting.html +1 - accept Apache Ignite 3.0.0-alpha1 RC3 0 - don't care either way -1 - DO NOT accept Apache Ignite 3.0.0-alpha1 RC3 (explain why) See notes on how to verify release here: https://www.apache.org/info/verification.html This vote will be open for 72 hours and will close on January 8th at 12:00 am UTC: https://www.timeanddate.com/countdown/generic?iso=20210108T13&p0=224&font=cursive -Val
Re: [VOTE] Release Apache Ignite 3.0.0-alpha1 RC2
I've created a ticket for the shell issue: https://issues.apache.org/jira/browse/IGNITE-13959. Will fix it and restart the vote. -Val On Tue, Jan 5, 2021 at 9:34 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Hi Ilya, > > Please see my comments below. > > -Val > > On Tue, Jan 5, 2021 at 2:09 AM Ilya Kasnacheev > wrote: > >> Hello! >> >> -1 (binding) >> >> After doing mvn clean install, the modules/cli/target/ignite executable >> file is malformed, it would not run. >> >> When running it with zsh, the following error is seen: >> ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% ./ignite >> ./ignite: 17: set: Illegal option -o pipefail >> >> When running it with another popular shell, fish, the following error is >> seen: >> ikasnacheev@ikasnacheev-ThinkPad-P51s ~/D/a/m/c/target> ./ignite >> Failed to execute process './ignite'. Reason: >> exec: Exec format error >> The file './ignite' is marked as an executable but could not be run by the >> operating system. >> >> The reason for this, the file starts with Apache license, and then the >> #!/usr/bin/env marker is seen. >> However, by UNIX conventions, the shebang line has to be the very first. >> And only then you can specify the license. >> >> I would have thought that it will finally run as explicit bash script, but >> it won't either: >> ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% bash ignite >> ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% echo $? >> 1 >> >> It won't even run as "bash ignite" even if you log in to bash first. The >> only way of running it is doing ./ignite while in bash. >> > > Which OS are you running on? The tool was quite rigorously tested on bash > under Ubuntu and MacOS. I'm not sure about other shells though, will check. > > Either way, does moving the env marker to the top help under all those > shells? If that's the case, the fix is easy and it might make sense to > include it and restart the vote. Please let me know if you have the fix. > > >> This aside, I don't really understand how we are going to publish this >> release. Will we offer downloads from ignite.apache.org? What if people >> start actually downloading it and see that it basically does nothing? >> Do we have documentation for this release? README.md is a one-liner. >> DEVNOTES.md does not even explain how to run it. There's `./docs' but no >> explanation how to use them. I have tried to go through the "Getting >> started" in the docs but also has failed miserably: >> ~/Downloads/apache-ignite-3.0.0-alpha1-src% mkdir ignite3 && cd ignite3 >> ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% curl -L " >> >> https://www.apache.org/dyn/mirrors/mirrors.cgi?action=download&filename=ignite/3.0.0-alpha1/ignite >> " >> -o ignite && chmod +x ignite >> >> % Total% Received % Xferd Average Speed TimeTime Time >> Current >> Dload Upload Total SpentLeft >> Speed >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- >> 0 >> 100 10170 10170 0 1040 0 --:--:-- --:--:-- --:--:-- >> 1040 >> ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% ls >> ignite >> ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% ./ignite >> ./ignite: 2: Syntax error: newline unexpected >> ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% head ignite >> >> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> >> http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> >> >> Object not found! >> mailto:%5bno%20address%20given%5d"; /> >>
Re: [VOTE] Release Apache Ignite 3.0.0-alpha1 RC2
Hi Ilya, Please see my comments below. -Val On Tue, Jan 5, 2021 at 2:09 AM Ilya Kasnacheev wrote: > Hello! > > -1 (binding) > > After doing mvn clean install, the modules/cli/target/ignite executable > file is malformed, it would not run. > > When running it with zsh, the following error is seen: > ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% ./ignite > ./ignite: 17: set: Illegal option -o pipefail > > When running it with another popular shell, fish, the following error is > seen: > ikasnacheev@ikasnacheev-ThinkPad-P51s ~/D/a/m/c/target> ./ignite > Failed to execute process './ignite'. Reason: > exec: Exec format error > The file './ignite' is marked as an executable but could not be run by the > operating system. > > The reason for this, the file starts with Apache license, and then the > #!/usr/bin/env marker is seen. > However, by UNIX conventions, the shebang line has to be the very first. > And only then you can specify the license. > > I would have thought that it will finally run as explicit bash script, but > it won't either: > ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% bash ignite > ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% echo $? > 1 > > It won't even run as "bash ignite" even if you log in to bash first. The > only way of running it is doing ./ignite while in bash. > Which OS are you running on? The tool was quite rigorously tested on bash under Ubuntu and MacOS. I'm not sure about other shells though, will check. Either way, does moving the env marker to the top help under all those shells? If that's the case, the fix is easy and it might make sense to include it and restart the vote. Please let me know if you have the fix. > This aside, I don't really understand how we are going to publish this > release. Will we offer downloads from ignite.apache.org? What if people > start actually downloading it and see that it basically does nothing? > Do we have documentation for this release? README.md is a one-liner. > DEVNOTES.md does not even explain how to run it. There's `./docs' but no > explanation how to use them. I have tried to go through the "Getting > started" in the docs but also has failed miserably: > ~/Downloads/apache-ignite-3.0.0-alpha1-src% mkdir ignite3 && cd ignite3 > ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% curl -L " > > https://www.apache.org/dyn/mirrors/mirrors.cgi?action=download&filename=ignite/3.0.0-alpha1/ignite > " > -o ignite && chmod +x ignite > > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0 > 100 10170 10170 0 1040 0 --:--:-- --:--:-- --:--:-- > 1040 > ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% ls > ignite > ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% ./ignite > ./ignite: 2: Syntax error: newline unexpected > ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% head ignite > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> > > Object not found! > mailto:%5bno%20address%20given%5d"; /> >
[jira] [Created] (IGNITE-13958) .Net: Avoid binary configuration on Compute invocation
Nikolay Izhikov created IGNITE-13958: Summary: .Net: Avoid binary configuration on Compute invocation Key: IGNITE-13958 URL: https://issues.apache.org/jira/browse/IGNITE-13958 Project: Ignite Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.10 Currently, it's required to explicitly register any custom user type as a binary type to be able to invoke some compute API method with this type as a parameter or return value. We should use the same technique as in IGNITE-10075 to avoid explicit binary type registration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Ignite 3.0.0-alpha1 RC2
Hello! -1 (binding) After doing mvn clean install, the modules/cli/target/ignite executable file is malformed, it would not run. When running it with zsh, the following error is seen: ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% ./ignite ./ignite: 17: set: Illegal option -o pipefail When running it with another popular shell, fish, the following error is seen: ikasnacheev@ikasnacheev-ThinkPad-P51s ~/D/a/m/c/target> ./ignite Failed to execute process './ignite'. Reason: exec: Exec format error The file './ignite' is marked as an executable but could not be run by the operating system. The reason for this, the file starts with Apache license, and then the #!/usr/bin/env marker is seen. However, by UNIX conventions, the shebang line has to be the very first. And only then you can specify the license. I would have thought that it will finally run as explicit bash script, but it won't either: ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% bash ignite ~/Downloads/apache-ignite-3.0.0-alpha1-src/modules/cli/target% echo $? 1 It won't even run as "bash ignite" even if you log in to bash first. The only way of running it is doing ./ignite while in bash. This aside, I don't really understand how we are going to publish this release. Will we offer downloads from ignite.apache.org? What if people start actually downloading it and see that it basically does nothing? Do we have documentation for this release? README.md is a one-liner. DEVNOTES.md does not even explain how to run it. There's `./docs' but no explanation how to use them. I have tried to go through the "Getting started" in the docs but also has failed miserably: ~/Downloads/apache-ignite-3.0.0-alpha1-src% mkdir ignite3 && cd ignite3 ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% curl -L " https://www.apache.org/dyn/mirrors/mirrors.cgi?action=download&filename=ignite/3.0.0-alpha1/ignite"; -o ignite && chmod +x ignite % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 10170 10170 0 1040 0 --:--:-- --:--:-- --:--:-- 1040 ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% ls ignite ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% ./ignite ./ignite: 2: Syntax error: newline unexpected ~/Downloads/apache-ignite-3.0.0-alpha1-src/ignite3% head ignite http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> Object not found! mailto:%5bno%20address%20given%5d"; />
[jira] [Created] (IGNITE-13957) GridQueryProcessor.validateKeyAndValue attempts to deserialize key and value when QueryEntity.fields is not set
Pavel Tupitsyn created IGNITE-13957:
---
Summary: GridQueryProcessor.validateKeyAndValue attempts to
deserialize key and value when QueryEntity.fields is not set
Key: IGNITE-13957
URL: https://issues.apache.org/jira/browse/IGNITE-13957
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.9.1, 2.9
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.10
{{GridQueryProcessor.validateKeyAndValue}} attempts to deserialize cache key
and value on {{put}} when {{QueryEntity.fields}} is not set, and fails when
corresponding classes can't be found.
* The bug was introduced in 2.9
* There is no problem when some query entity fields are defined
Reproducer in .NET (TODO: add both .NET and Java tests for this)
{code}
// CacheQueriesCodeConfigurationTest
///
/// Tests query entity validation when no has been set.
///
[Test]
public void TestMissingQueryAttributes()
{
using (var ignite =
Ignition.Start(TestUtils.GetTestConfiguration()))
{
var cfg = new CacheConfiguration(
TestUtils.TestName,
new QueryEntity(typeof(string),
typeof(MissingAttributesTest)));
var cache = ignite.GetOrCreateCache(cfg);
cache["1"] = new MissingAttributesTest {Foo = "Bar"};
}
}
///
/// Class without any attributes.
///
private class MissingAttributesTest
{
/** */
public string Foo { get; set; }
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
