Ray, I think to avoid excessive GC and OOM you could try switching to a lazy result set: https://apacheignite-sql.readme.io/docs/performance-and-debugging#result-set-lazy-load
- Nick On Wed, Nov 29, 2017, 7:19 AM Anton Vinogradov <avinogra...@gridgain.com> wrote: > Ray, > > Seems you're looking > for org.apache.ignite.cache.query.SqlFieldsQuery#timeout? > > On Tue, Nov 28, 2017 at 5:30 PM, Alexey Kukushkin < > kukushkinale...@gmail.com> wrote: > >> Ignite Developers, >> >> I know community is developing an "Internal Problems Detection" feature >> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-7%3A+Ignite+internal+problems+detection>. >> Do you know if it addresses the problem Ray described below? May be we >> already have a setting to prevent this from happening? >> >> On Tue, Nov 28, 2017 at 5:13 PM, Ray <ray...@cisco.com> wrote: >> >>> I try to fetch all the results of a table with billions of entries using >>> sql >>> like this "select * from table_name". >>> As far as my understanding, Ignite will prepare all the data on the node >>> running this query then return the results to the client. >>> The problem is that after a while, the node crashes(probably because of >>> long >>> GC pause or running out of memory). >>> Is node crashing the expected behavior? >>> I mean it's unreasonable that Ignite node crashes after this kind of >>> query. >>> >>> From my experience with other databases, running this kind of full table >>> scan will not crash the node. >>> >>> The optimal way for handling this kind of situation is Ignite node stays >>> alive, the query will be stopped by Ignite node when the node find out it >>> will run out of memory soon. >>> Then an error response shall be returned to the client. >>> >>> Please advice me if this mechanism already exists and there is hidden >>> switch >>> to turn it on. >>> Thanks >>> >>> >>> >>> -- >>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >>> >> >> >> >> -- >> Best regards, >> Alexey >> > >
