[jira] [Created] (IGNITE-13341) OOME is ignored if thrown in a client connector thread
Stanislav Lukyanov created IGNITE-13341:
---
Summary: OOME is ignored if thrown in a client connector thread
Key: IGNITE-13341
URL: https://issues.apache.org/jira/browse/IGNITE-13341
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Stanislav Lukyanov
If a thin client operation causes OOME then the thread will die and an error
will be logged, but that's all. The clients are left hanging and waiting for
reply until timeout.
Correct behavior in this case would be to trigger Failure Handler.
Example of the error:
{code}
Exception in thread "client-connector-#69%xxx%" java.lang.OutOfMemoryError:
Java heap space
Aug 08, 2020 7:08:43 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Runtime error caught during grid runnable execution: GridWorker
[name=message-received-notify, igniteInstanceName=xxx, finished=false,
heartbeatTs=1596859722580, hashCode=1209004925, interrupted=false,
runner=client-connector-#66%xxx%]
java.lang.OutOfMemoryError: Java heap space
at
org.apache.ignite.internal.binary.streams.BinaryMemoryAllocatorChunk.reallocate(BinaryMemoryAllocatorChunk.java:68)
at
org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.ensureCapacity(BinaryHeapOutputStream.java:64)
at
org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.unsafeEnsure(BinaryAbstractOutputStream.java:261)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteBinaryObject(BinaryWriterExImpl.java:970)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:756)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:231)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:164)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:151)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:523)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObject(BinaryWriterExImpl.java:1502)
at
org.apache.ignite.internal.processors.platform.client.ClientObjectResponse.encode(ClientObjectResponse.java:43)
at
org.apache.ignite.internal.processors.platform.client.ClientMessageParser.encode(ClientMessageParser.java:459)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:203)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:49)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:278)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:108)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:135)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:69)
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)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13340) copyOnRead=false doesn't work for byte array values
Stanislav Lukyanov created IGNITE-13340: --- Summary: copyOnRead=false doesn't work for byte array values Key: IGNITE-13340 URL: https://issues.apache.org/jira/browse/IGNITE-13340 Project: Ignite Issue Type: Bug Components: cache Reporter: Stanislav Lukyanov If near cache is used and copyOnRead=false is set then the Java object should only be created on the first read, and all subsequent reads must use the same copy. However, when byte array value is used (e.g. `put(42, new byte[100]`) then the copying is done on every read. It seems that the reason is that byte array values have their own implementation of `CacheObject` - `CacheObjectByteArrayImpl`. That implementation doesn't use `CacheObjectValueContext::storeValue` which controls whether copying needs to be done; CacheObjectImpl uses it. Need to correctly implement copyOnRead=false for caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Apache Ignite 3.0
Igniters, I've created the page: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 That's not everything I have in mind, but I believe there is already a lot to talk about :) Please take a look let me know if you have any concerns, objections, or questions. Once we reach the consensus on the proposed changes, I will start creating tickets in Jira and a more detailed plan. -Val On Thu, Aug 6, 2020 at 6:28 PM Saikat Maitra wrote: > Hi Denis, Val > > Thank you for your reply and really appreciate it. It will be very cool to > be able to connect and plan release together and learn more about Ignite in > the process :) > > Regards > Saikat > > > > On Thu, Aug 6, 2020 at 7:12 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Hi Saikat, > > > > That surely is a great idea. We will work together with Denis on setting > > this up in the nearest future. > > > > -Val > > > > On Thu, Aug 6, 2020 at 10:21 AM Denis Magda wrote: > > > > > Saikat, > > > > > > Fully support your idea on a virtual meetup! Once Val collects and > > outlines > > > the main changes with directions on wiki, we’ll go ahead and schedule > the > > > meetup to talk things out in a bit more detail. We’ll use our new > Virtual > > > Ignite Meetup group for that inviting both Ignite contributors and > > > application developers. > > > > > > Denis > > > > > > On Thursday, August 6, 2020, Saikat Maitra > > > wrote: > > > > > > > Hi Valentin > > > > > > > > Thank you for sharing and starting the thread. I am thinking if it > will > > > be > > > > a good idea to have a virtual meet setup to discuss on the release > > > > planning. > > > > > > > > It will help to learn more individual features to be added and also > to > > > > understand about features that have been deprecated and scheduled for > > > > removal in Ignite 3.0 release. Also it will help community member to > > > > connect in real time and ask questions and share feedback. > > > > > > > > Regards, > > > > Saikat > > > > > > > > On Thu, Aug 6, 2020 at 3:51 AM Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com> > > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > I hope to see Apache Ignite release 3.0 as API trimming release. > Let > > us > > > > > correct external and internal APIs for which we have better ideas > > now, > > > as > > > > > well as remove old and deprecated code. > > > > > > > > > > We may also introduce new configuration mechanisms and user-facing > > API > > > > > (such as cache-less native SQL queries), but this we could > prototype > > > > before > > > > > starting the 3.0 task. > > > > > > > > > > I will advise against targeting large new features at 3.0. They can > > be > > > > > added in subsequent point releases, whereas we can't really remove > or > > > > > remodel stuff in point releases. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > чт, 6 авг. 2020 г. в 03:54, Valentin Kulichenko < > > > > > valentin.kuliche...@gmail.com>: > > > > > > > > > > > Igniters, > > > > > > > > > > > > I would like to kick off a discussion regarding Ignite 3.0. > Ignite > > > 2.0 > > > > > > exists for more than 3 years now and we've already collected a > > > > > significant > > > > > > list [1] of changes that we would like to have, but cannot > > implement > > > > > > without breaking compatibility. > > > > > > > > > > > > I think it's time to start planning for the next major release > and > > > > > > discussing what should be included. I've already gathered some > > > > > information > > > > > > and feedback, and have some thoughts on how to approach this. In > > the > > > > next > > > > > > few days, I will put everything into a Wiki page and will share > it > > > once > > > > > > this is done. Stay tuned! > > > > > > > > > > > > I'm willing to drive the 3.0 activities going forward as well. > > > > > > > > > > > > In the meantime, if there are any immediate thoughts or ideas, > > please > > > > > feel > > > > > > free to join the thread and share them. > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/ > > > > Apache+Ignite+3.0+Wishlist > > > > > > > > > > > > Regards, > > > > > > Val > > > > > > > > > > > > > > > > > > > > > > > > -- > > > - > > > Denis > > > > > >
[MTCGA]: new failures in builds [5509408] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Test with high flaky rate in master IgniteClusterIdTagTest.testInMemoryClusterTag https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2444565365384645281=%3Cdefault%3E=testDetails Changes may lead to failure were done by - pavel tupitsyn https://ci.ignite.apache.org/viewModification.html?modId=905248 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:14:21 07-08-2020
Re: Node.js, Python, PHP thin clients place in release cycle
Hello, I agree with Ilya. Currently, the last commit to the Node.JS thin client was 15 months ago, the last commit to the PHP thin client was 2 years ago, the last commit to the Python thin client was 17 months ago. 5 releases in a row (2.7.5, 2.7.6, 2.8.0, 2.8.1, 2.9.0) there were no updates to any of these clients. What are we going to upload to repos? The same old versions with a new version number? пт, 7 авг. 2020 г. в 18:08, Petr Ivanov : > I guess we should ask PMC chair to help with corresponding accounts. > > > > On 7 Aug 2020, at 15:55, Igor Sapego wrote: > > > > Guys, > > > > Currently, Node.js, Python and PHP thin clients are not included in > > Ignite release process, meaning we do not publish them on pip, npm, > > etc during release and do not publish API references for these clients. > > > > I propose to add steps to build and publish these client packages and > > API documentation and upload them automatically to repos during > > Ignite release process. Thoughts? > > > > Best Regards, > > Igor > >
Re: Node.js, Python, PHP thin clients place in release cycle
I guess we should ask PMC chair to help with corresponding accounts. > On 7 Aug 2020, at 15:55, Igor Sapego wrote: > > Guys, > > Currently, Node.js, Python and PHP thin clients are not included in > Ignite release process, meaning we do not publish them on pip, npm, > etc during release and do not publish API references for these clients. > > I propose to add steps to build and publish these client packages and > API documentation and upload them automatically to repos during > Ignite release process. Thoughts? > > Best Regards, > Igor
Re: Re[2]: Please grant me privileges to edit ignite wiki pages.
Hello! You should now be able to edit. Regards, -- Ilya Kasnacheev пт, 7 авг. 2020 г. в 09:01, Zhenya Stanilovsky : > > > Ilya, thanks ! > full name : evgeny stanilovsky , short : zstan > > > > >> > >>>Hello! > >>> > >>>Do you have a Wiki account? What's its username? > >>> > >>>Thanks, > >>>-- > >>>Ilya Kasnacheev > >>> > >>> > >>>чт, 6 авг. 2020 г. в 11:01, Zhenya Stanilovsky < > arzamas...@mail.ru.invalid >: > >>> > > I`m currently working on cpp thin client transactions support [1] and > need > to edit, for example this page [2]. > Can someone grant me this privileges ? > thanks ! > > [1] https://issues.apache.org/jira/browse/IGNITE-13308 > [2] > > https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features > > > >> > >> > >> > >>
Re: Node.js, Python, PHP thin clients place in release cycle
Hello! I think that eventually they should have their own release cycle. Released when there are new features. Be compatible with wide range of Ignite versions. Regards, -- Ilya Kasnacheev пт, 7 авг. 2020 г. в 15:55, Igor Sapego : > Guys, > > Currently, Node.js, Python and PHP thin clients are not included in > Ignite release process, meaning we do not publish them on pip, npm, > etc during release and do not publish API references for these clients. > > I propose to add steps to build and publish these client packages and > API documentation and upload them automatically to repos during > Ignite release process. Thoughts? > > Best Regards, > Igor >
Node.js, Python, PHP thin clients place in release cycle
Guys, Currently, Node.js, Python and PHP thin clients are not included in Ignite release process, meaning we do not publish them on pip, npm, etc during release and do not publish API references for these clients. I propose to add steps to build and publish these client packages and API documentation and upload them automatically to repos during Ignite release process. Thoughts? Best Regards, Igor
Re: [DISCUSSION] Cache warmup
Hi, Stan! Yes, that's right. > On the interface structure. > So, as a user I'll see one interface, WarmUpConfiguration, with no methods. > I choose an implementation and configure it like > cfg.setWarmUpConfiguration(new LoadEverythingWarmupConfiguration()); > Ignite tries to map the LoadEverythingWarmupConfiguration to an > implementations it knows - either to a built-in one or to a plugin. > If it finds the implementation, it passes the configuration to it and it > handles the warmup. > If it doesn't find an existing implementation, it throws an exception. > The implementation will use any internal API of Ignite that it needs to > perform the warmup. It is up to the plugin maintainer to track code changes > in Ignite and adjust the plugin to be compatible from version to version. > Is all of the above correct? If we need to configure heating, a string constant will not work for us. > How about > cfg.setWarmUpConfiguration(IgniteWarmupStrategies.LOAD_EVERYTHING); > instead of > cfg.setWarmUpConfiguration(new LoadEverythingWarmupConfiguration()); > ? > Or do we expect having POJO instead of a string constant to be beneficial? It seems to me that if you need to specify regions for a strategy, you can add them to strategy settings. It would be more natural for user to do configuration by caches, but due to internal feature of Ignite, it just doesn't work(yet), so it seems to me that you can add additional options for each setting. 06.08.2020, 20:41, "Stanislav Lukyanov" : > Hi Kirill, Alexey, > > On the interface structure. > So, as a user I'll see one interface, WarmUpConfiguration, with no methods. > I choose an implementation and configure it like > cfg.setWarmUpConfiguration(new LoadEverythingWarmupConfiguration()); > Ignite tries to map the LoadEverythingWarmupConfiguration to an > implementations it knows - either to a built-in one or to a plugin. > If it finds the implementation, it passes the configuration to it and it > handles the warmup. > If it doesn't find an existing implementation, it throws an exception. > The implementation will use any internal API of Ignite that it needs to > perform the warmup. It is up to the plugin maintainer to track code changes > in Ignite and adjust the plugin to be compatible from version to version. > Is all of the above correct? > How about > cfg.setWarmUpConfiguration(IgniteWarmupStrategies.LOAD_EVERYTHING); > instead of > cfg.setWarmUpConfiguration(new LoadEverythingWarmupConfiguration()); > ? > Or do we expect having POJO instead of a string constant to be beneficial? > > Agree about preloadPartition(). Fair enough, let's leave it be. > > On IgniteConfiguration vs DataRegionConfiguration. > I like DataRegionConfiguration more because it allows to specify different > strategies for different regions naturally. > We already say that all cache groups in the same region share memory > management (e.g. share space and participate in page replacement together). > So it's natural to say that if I want different memory warmup semantics for > two groups then I should be putting them in different regions. > Do you see a good way to have distinct warmup configuration for different > regions while the config is on IgniteConfiguration level? > > Thanks, > Stan > >> On 6 Aug 2020, at 15:39, ткаленко кирилл wrote: >> >> Hello, Alexey! >> >> Your comments are fair. >> >> 05.08.2020, 15:51, "Alexey Goncharuk" : >>> Kirill, >>> >>> Thank you for driving this discussion and implementation. >>> >>> A few points from my side: >>> * Agree that it will be best to keep the strategy interface private because >>> it will be very dependent on the persistent storage implementation. We >>> would need to expose page IDs and types to public API, which is very >>> restrictive. The configuration part obviously needs to be public, and >>> ability to pull the strategy implementation from plugin is a good idea. >>> * I was also thinking of adding the warmup configuration straight to the >>> IgniteConfiguration, but I like Stan's idea of adding it to >>> DataRegionConfiguration. No strong preference here. >>> * I do not think we need to deprecate preloadPartition() method. One of the >>> use-cases for this method was to process partitions sequentially while a >>> node is running. This method is able to fetch the partition from disk much >>> (from times to orders of magnitude) faster than sequential scan. >>> * Being able to cancel the warmup during startup is a great feature. We >>> should be able to support it from control.sh because the warmup runs before >>> discovery which starts the last, so the control.sh handler should be >>> already running.
Re: Orphaned, duplicate, and main-class tests!
Hello! I have uncommented yet another batch, plus some minor code improvement. Please review: https://issues.apache.org/jira/browse/IGNITE-9215 https://issues.apache.org/jira/browse/IGNITE-9215 Regards, -- Ilya Kasnacheev ср, 5 февр. 2020 г. в 17:30, Ilya Kasnacheev : > Hello! > > Just to resurrect this old thread: > > I have uncommented another batch of tests, would appreciate a review of > PR: https://issues.apache.org/jira/browse/IGNITE-9216 > > Regards, > -- > Ilya Kasnacheev > > > ср, 31 окт. 2018 г. в 15:22, Ilya Kasnacheev : > >> Hello! >> >> So we have uncommented 4 batches out of 10! 6 to go. Some broken >> functionality were exposed. >> >> There is still work to do, so do not hesitate to assign a subtask to >> yourself. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> ср, 15 авг. 2018 г. в 19:42, Ilya Kasnacheev : >> >>> Hello! >>> >>> So we have enabled a first batch of tests: >>> https://github.com/apache/ignite/pull/4504 >>> >>> How it was done: I have uncommented classes. Some of these were absent >>> in code base, so I have checked if we didn't lose anything important - they >>> were testing CLOCK mode which isn't with us for some time, so I removed >>> their entries. >>> Then I have ran them, some were broken. Most of those were testing >>> on-heap caching with copy=false, which now requires setOnheapCaching(true), >>> which I did. After that, cache.invoke() still didn't work, so I commented >>> this part out. >>> The remaining test was broken due to dependence on hash map iteration >>> order, which was changed in Java 8. So I have got the remaining tests >>> working, checking important parts of our system. >>> >>> Please do not hesitate to assign subtasks of >>> https://issues.apache.org/jira/browse/IGNITE-9210 to yourself, dabble >>> with tests. IMO it's the best way for a novice developer to become >>> acquainted with Ignite code base, tests and history, while helping the >>> project. >>> >>> Thanks, >>> >>> -- >>> Ilya Kasnacheev >>> >>> 2018-08-07 16:54 GMT+03:00 Ilya Kasnacheev : >>> Hello! Thank you Dmitriy, and thanks to everybody who participated in discussions. I have created tickets for next steps: https://issues.apache.org/jira/browse/IGNITE-9210 (with subtasks) https://issues.apache.org/jira/browse/IGNITE-9222 https://issues.apache.org/jira/browse/IGNITE-9223 As usual, feedback will be very welcome. Regards, -- Ilya Kasnacheev 2018-08-07 13:58 GMT+03:00 Dmitriy Pavlov : > Hi Igniters, > > I've merged chages for following tickets > IGNITE-7615: Find orphaned tests without test suites, create separate > test > suite for them; > IGNITE-8344: Remove duplicate tests and suites; > IGNITE-8345: Streamline tests' class names: mark Abstract and Load > tests > obviously so; > > After including these suites we have now more than 100 occurrences of > //suite.addTest > > These tests were created early but not executed on TeamCity. If you are > interseted in test coverage increase and can contribute each of these > suite > actualization, please feel free to create ticket for such suites > resurrection (or group of suites). > > Ilya, thank you for contribution and for your efforts to make this > happen. > > Sincerely, > Dmitriy Pavlov > > ср, 1 авг. 2018 г. в 12:52, Dmitriy Pavlov : > > > Hi Ilya, > > > > could you please actualize this PR. TC Bot can now detect newly > > contributed tests' failures, so I think it is best point to apply you > > change. > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 25 мая 2018 г. в 18:16, Eduard Shangareev < > eduard.shangar...@gmail.com > > >: > > > >> Igniters, > >> > >> While making review I checked next main-method tests: > >> > >> org.apache.ignite.loadtests.mapper.GridContinuousMapperLoadTest1 > >> org.apache.ignite.loadtests.mapper.GridContinuousMapperLoadTest2 > >> > >> And I have found that they are totally outdated! > >> They use config which was changed a long time ago. > >> And use localPeek with parameters which don't make sense now. > >> > >> So, I suggest to delete them. > >> > >> If there wouldn't be any objection I will do it myself. > >> > >> > >> > >> > >> On Tue, May 22, 2018 at 6:59 PM, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com> > >> wrote: > >> > >> > Hello, Igniters! > >> > > >> > One moment more of your time. One, we seem to have a consensus > now that > >> > tests should be added to suites, but commented out. They should be > >> > uncommented out later, for which numerous tickets will be > created. This > >> way > >> > we can tackle. > >> > > >> > Another issue sprang up, just now I have discovered an > 'ignored-tests' > >> >
[jira] [Created] (IGNITE-13339) Sql query fails with NullPointerException caused by calling CAST in order by clause
Taras Ledkov created IGNITE-13339:
-
Summary: Sql query fails with NullPointerException caused by
calling CAST in order by clause
Key: IGNITE-13339
URL: https://issues.apache.org/jira/browse/IGNITE-13339
Project: Ignite
Issue Type: Test
Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.9
Sql statements to reproduce:
CREATE TABLE Person(ID INTEGER PRIMARY KEY, NAME VARCHAR(100));
INSERT INTO Person(ID, NAME) VALUES (1, 'Ed'), (2, 'Ann'), (3, 'Emma');
select name,id from Person order by CAST(id as long)
Result:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2572)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2505)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2463)
at
org.apache.ignite.internal.visor.query.VisorQueryUtils.lambda$scheduleQueryStart$0(VisorQueryUtils.java:409)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7157)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
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)
Caused by: class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3050)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2531)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2569)
... 9 more
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlFunction.getSQL(GridSqlFunction.java:124)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuery.getSortLimitSQL(GridSqlQuery.java:171)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlSelect.getSQL(GridSqlSelect.java:182)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:371)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split0(GridSqlQuerySplitter.java:280)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:212)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:501)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:173)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:132)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1115)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2515)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2511)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:35)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3027)
... 11 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re[2]: Please grant me privileges to edit ignite wiki pages.
Ilya, thanks ! full name : evgeny stanilovsky , short : zstan > >> >>>Hello! >>> >>>Do you have a Wiki account? What's its username? >>> >>>Thanks, >>>-- >>>Ilya Kasnacheev >>> >>> >>>чт, 6 авг. 2020 г. в 11:01, Zhenya Stanilovsky < arzamas...@mail.ru.invalid : >>> I`m currently working on cpp thin client transactions support [1] and need to edit, for example this page [2]. Can someone grant me this privileges ? thanks ! [1] https://issues.apache.org/jira/browse/IGNITE-13308 [2] https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features >> >> >> >>
