Re: SqlQuery Deprecated Since 2.8, please use SqlFieldsQuery instead....How to get result as passing model Type with SqlFieldsQuery?
Hello!
Why not:
SELECT t.*, t._val from materials t INNER JOIN ...
Regards,
--
Ilya Kasnacheev
чт, 21 янв. 2021 г. в 19:19, siva :
> Hi,
>
> It's working fine in "select _val from mytesttable" query but in case of
> sub
> query or joins it's failing with an error like column not found
>
> It's failing access column with and without table Aliases.
> for example
>
> Query::>
>
> SELECT t.* from (select _val FROM materials ) as t INNER JOIN
>
> "F2DEDF6E-393E-42BC-9BB3-E835A1063B30_862C7264-8C8A-4217-AFA4-30CD49AC050F_SECURITY".SecurityGroups
> ON t.EntityId = SecurityGroups.SGEntityId WHERE securityGroupId in
> ('25c8eff1-1607-4a57-bd88-b4be9a1c3b73') order by t.MaterialName offset 0
> rows fetch next 7000 rows only
>
> Exception::>
>
> Failed to parse query. Column "T.MATERIALNAME" not found; SQL statement:
> SELECT t.* from (select _val FROM materials ) as t INNER JOIN
>
> "F2DEDF6E-393E-42BC-9BB3-E835A1063B30_862C7264-8C8A-4217-AFA4-30CD49AC050F_SECURITY".SecurityGroups
> ON t.EntityId = SecurityGroups.SGEntityId WHERE securityGroupId in
> ('25c8eff1-1607-4a57-bd88-b4be9a1c3b73') order by t.MaterialName offset 0
> rows fetch next 7000 rows only [42122-197]
>
> Thanks.
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
Re: Ignite with Docker on Raspberry Pi
Hello!
This does look like some control.sh issue, such as that it is unable to
complete request and activation never happens. Can you try to activate this
node in some other way, such as connecting a thick client node to it and
doing client.cluster().state(ACTIVE) from there?
Regards,
--
Ilya Kasnacheev
пн, 25 янв. 2021 г. в 16:35, Edwind :
> Hello!
>
> Here is my full logs with Stephen's image :) I think I have enabled INFO
> logging but I'm not sure tell me if you need more.
>
>
> Ignite Logs wrote
> > [15:55:08]__
> > [15:55:08] / _/ ___/ |/ / _/_ __/ __/
> > [15:55:08] _/ // (7 7// / / / / _/
> > [15:55:08] /___/\___/_/|_/___/ /_/ /___/
> > [15:55:08]
> > [15:55:08] ver. 2.8.1#20200521-sha1:86422096
> > [15:55:08] 2020 Copyright(C) Apache Software Foundation
> > [15:55:08]
> > [15:55:08] Ignite documentation: http://ignite.apache.org
> > [15:55:08]
> > [15:55:08] Quiet mode.
> > [15:55:08] ^-- Logging to file
> > '/opt/ignite/apache-ignite/work/log/ignite-2b0807c4.0.log'
> > [15:55:08] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
> > [15:55:08] ^-- To see **FULL** console log here add
> -DIGNITE_QUIET=false
> > or "-v" to ignite.{sh|bat}
> > [15:55:08]
> > [15:55:09] OS: Linux 5.4.79-v7+ arm
> > [15:55:09] VM information: OpenJDK Runtime Environment 1.8.0_212-b04
> > IcedTea OpenJDK Zero VM 25.212-b04
> > [15:55:09] Please set system property '-Djava.net.preferIPv4Stack=true'
> to
> > avoid possible problems in mixed environments.
> > [15:55:09] Initial heap size is 16MB (should be no less than 512MB, use
> > -Xms512m -Xmx512m).
> > [15:55:11] Configured plugins:
> > [15:55:11] ^-- None
> > [15:55:11]
> > [15:55:11] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
> > [tryStop=false, timeout=0, super=AbstractFailureHandler
> > [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> > SYSTEM_CRITICAL_OPERATION_TIMEOUT
> > [15:55:14] Message queue limit is set to 0 which may lead to potential
> > OOMEs when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes
> > due to message queues growth on sender and receiver sides.
> > [15:55:15] Security status [authentication=off, tls/ssl=off]
> > [15:56:30] Nodes started on local machine require more than 80% of
> > physical RAM what can lead to significant slowdown due to swapping
> (please
> > decrease JVM heap size, data region size or checkpoint buffer size)
> > [required=574MB, available=924MB]
> > [15:56:46,041][SEVERE][tcp-disco-msg-worker-[crd]-#2][G] Blocked
> > system-critical thread has been detected. This can lead to cluster-wide
> > undefined behaviour [workerName=disco-notifier-worker,
> > threadName=disco-notifier-worker-#43, blockedFor=15s]
> > [15:56:46] Possible failure suppressed accordingly to a configured
> handler
> > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> > failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> > o.a.i.IgniteException: GridWorker [name=disco-notifier-worker,
> > igniteInstanceName=null, finished=false, heartbeatTs=1611417390753]]]
> > [15:56:58,064][SEVERE][tcp-disco-msg-worker-[crd]-#2][G] Blocked
> > system-critical thread has been detected. This can lead to cluster-wide
> > undefined behaviour [workerName=disco-notifier-worker,
> > threadName=disco-notifier-worker-#43, blockedFor=27s]
> > [15:56:58] Possible failure suppressed accordingly to a configured
> handler
> > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> > failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> > o.a.i.IgniteException: GridWorker [name=disco-notifier-worker,
> > igniteInstanceName=null, finished=false, heartbeatTs=1611417390753]]]
> > [15:57:09] Performance suggestions for grid (fix if possible)
> > [15:57:09] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> > [15:57:09] ^-- Enable server mode for JVM (add '-server' to JVM
> options)
> > [15:57:09] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM
> > options)
> > [15:57:09] ^-- Specify JVM heap max size (add '-Xmx
> >
> > [g|G|m|M|k|K]' to JVM options)
> > [15:57:09] ^-- Set max direct memory size if getting 'OOME: Direct
> > buffer memory' (add '-XX:MaxDirectMemorySize=
> >
> > [g|G|m|M|k|K]' to JVM options)
> > [15:57:09] ^-- Disable processing of calls to System.gc() (add
> > '-XX:+DisableExplicitGC' to JVM options)
> > [15:57:09] Refer to this page for more performance suggestions:
> > https://apacheignite.readme.io/docs/jvm-and-system-tuning
> > [15:57:09]
> > [15:57:09] To start Console Management & Monitoring run
> > ignitevisorcmd.{sh|bat}
> > [15:57:09] Data Regions Configured:
> > [15:57:09] ^-- default_region [initSize=
Re: Ignite with Docker on Raspberry Pi
Hello!
Here is my full logs with Stephen's image :) I think I have enabled INFO
logging but I'm not sure tell me if you need more.
Ignite Logs wrote
> [15:55:08]__
> [15:55:08] / _/ ___/ |/ / _/_ __/ __/
> [15:55:08] _/ // (7 7// / / / / _/
> [15:55:08] /___/\___/_/|_/___/ /_/ /___/
> [15:55:08]
> [15:55:08] ver. 2.8.1#20200521-sha1:86422096
> [15:55:08] 2020 Copyright(C) Apache Software Foundation
> [15:55:08]
> [15:55:08] Ignite documentation: http://ignite.apache.org
> [15:55:08]
> [15:55:08] Quiet mode.
> [15:55:08] ^-- Logging to file
> '/opt/ignite/apache-ignite/work/log/ignite-2b0807c4.0.log'
> [15:55:08] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
> [15:55:08] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
> or "-v" to ignite.{sh|bat}
> [15:55:08]
> [15:55:09] OS: Linux 5.4.79-v7+ arm
> [15:55:09] VM information: OpenJDK Runtime Environment 1.8.0_212-b04
> IcedTea OpenJDK Zero VM 25.212-b04
> [15:55:09] Please set system property '-Djava.net.preferIPv4Stack=true' to
> avoid possible problems in mixed environments.
> [15:55:09] Initial heap size is 16MB (should be no less than 512MB, use
> -Xms512m -Xmx512m).
> [15:55:11] Configured plugins:
> [15:55:11] ^-- None
> [15:55:11]
> [15:55:11] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
> [tryStop=false, timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT
> [15:55:14] Message queue limit is set to 0 which may lead to potential
> OOMEs when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes
> due to message queues growth on sender and receiver sides.
> [15:55:15] Security status [authentication=off, tls/ssl=off]
> [15:56:30] Nodes started on local machine require more than 80% of
> physical RAM what can lead to significant slowdown due to swapping (please
> decrease JVM heap size, data region size or checkpoint buffer size)
> [required=574MB, available=924MB]
> [15:56:46,041][SEVERE][tcp-disco-msg-worker-[crd]-#2][G] Blocked
> system-critical thread has been detected. This can lead to cluster-wide
> undefined behaviour [workerName=disco-notifier-worker,
> threadName=disco-notifier-worker-#43, blockedFor=15s]
> [15:56:46] Possible failure suppressed accordingly to a configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> o.a.i.IgniteException: GridWorker [name=disco-notifier-worker,
> igniteInstanceName=null, finished=false, heartbeatTs=1611417390753]]]
> [15:56:58,064][SEVERE][tcp-disco-msg-worker-[crd]-#2][G] Blocked
> system-critical thread has been detected. This can lead to cluster-wide
> undefined behaviour [workerName=disco-notifier-worker,
> threadName=disco-notifier-worker-#43, blockedFor=27s]
> [15:56:58] Possible failure suppressed accordingly to a configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> o.a.i.IgniteException: GridWorker [name=disco-notifier-worker,
> igniteInstanceName=null, finished=false, heartbeatTs=1611417390753]]]
> [15:57:09] Performance suggestions for grid (fix if possible)
> [15:57:09] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [15:57:09] ^-- Enable server mode for JVM (add '-server' to JVM options)
> [15:57:09] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM
> options)
> [15:57:09] ^-- Specify JVM heap max size (add '-Xmx
>
> [g|G|m|M|k|K]' to JVM options)
> [15:57:09] ^-- Set max direct memory size if getting 'OOME: Direct
> buffer memory' (add '-XX:MaxDirectMemorySize=
>
> [g|G|m|M|k|K]' to JVM options)
> [15:57:09] ^-- Disable processing of calls to System.gc() (add
> '-XX:+DisableExplicitGC' to JVM options)
> [15:57:09] Refer to this page for more performance suggestions:
> https://apacheignite.readme.io/docs/jvm-and-system-tuning
> [15:57:09]
> [15:57:09] To start Console Management & Monitoring run
> ignitevisorcmd.{sh|bat}
> [15:57:09] Data Regions Configured:
> [15:57:09] ^-- default_region [initSize=50.0 MiB, maxSize=50.0 MiB,
> persistence=false, lazyMemoryAllocation=true]
> [15:57:09] ^-- persistence_region [initSize=100.0 MiB, maxSize=100.0
> MiB, persistence=true, lazyMemoryAllocation=true]
> [15:57:09]
> [15:57:09] Ignite node started OK (id=2b0807c4)
> [15:57:09] >>> Ignite cluster is not active (limited functionality
> available). Use control.(sh|bat) script or IgniteCluster interface to
> activate.
> [15:57:09] Topology snapshot [ver=1, locNode=2b0807c4, servers=1,
> clients=0, state=INACTIVE, CPUs=4, offheap=0.15G
Re: Ignite with Docker on Raspberry Pi
Hello! 52 seconds response time suggests you have a timeout here. Maybe you run out of memory when checkpoint page buffer is considered? Maybe your system starts swapping? Can you enable INFO logging and share complete log from your server node? Regards, -- Ilya Kasnacheev сб, 23 янв. 2021 г. в 20:40, Edwind : > Hi! > > I'm currently working on a school project involving a distributed Apache > Ignite DB on a cluster of Raspberry Pi. I want to have 2 separate data > regions including one with persistence enabled. Here is my custom config : > > http://www.springframework.org/schema/beans"; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd";> > > id="ignite.cfg"> > > > > > > > class="org.apache.ignite.configuration.DataRegionConfiguration"> > > > > > > > > > > > > > > class="org.apache.ignite.configuration.DataRegionConfiguration"> > > > > > > > > > > > > > > > > > > > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder"> > > > > > > > > > So I've been trying to build my own Docker image to make it run. I've used > the official image and just changed the base image to use OpenJDK Alpine > arm32v7 and I lowered the JVM heap size to 512Mb. > My problem starts here: when I'm using the a basic config without > authentication and persistence everything seems to work fine but when I use > my config with persistence I have some weird issues with activation and > it's > impossible to reach the cluster... > > For example sometimes when I try to activate the cluster I have this issue > (I typed the right password I promise) : > > ./control.sh --activate > user: ignite > password: > Control utility [ver. 2.8.1#20200521-sha1:86422096] > 2020 Copyright(C) Apache Software Foundation > User: root > Time: 2021-01-23T15:59:10.789 > Command [ACTIVATE] started > Arguments: --activate > > > Failed to activate cluster. > This cluster requires authentication. > Command [ACTIVATE] started > Arguments: --activate > > > Failed to activate cluster. > Connection to cluster failed. Latest topology update failed. > Command [ACTIVATE] finished with code: 2 > Control utility has completed execution at: 2021-01-23T16:00:19.968 > Execution time: 69179 ms > > And then Apache send me some weird stuff : > > [16:05:22,842][SEVERE][rest-#109][GridTcpRestProtocol] Failed to process > client request [ses=GridSelectorNioSessionImpl > [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=0 > lim=8192 cap=8192], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, > bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker > [name=grid-nio-worker-tcp-rest-1, igniteInstanceName=null, finished=false, > heartbeatTs=1611417921389, hashCode=4009713, interrupted=false, > runner=grid-nio-worker-tcp-rest-1-#36]]], writeBuf=null, readBuf=null, > inRecovery=null, outRecovery=null, closeSocket=true, > outboundMessagesQueueSizeMetric=null, super=GridNioSessionImpl > [locAddr=/127.0.0.1:11211, rmtAddr=/127.0.0.1:33872, > createTime=1611417824153, closeTime=1611417905352, bytesSent=633, > bytesRcvd=519, bytesSent0=5, bytesRcvd0=5, sndSchedTime=1611417922803, > lastSndTime=1611417901655, lastRcvTime=1611417901655, readsPaused=false, > filterChain=FilterChain[filters=[GridNioCodecFilter > [parser=GridTcpRestParser [marsh=JdkMarshaller > [clsFilter=o.a.i.marshaller.MarshallerUtils$1@1864f0b], > routerClient=false], > directMode=false]], accepted=true, markedForClose=false]], > msg=GridClientAuthenticationRequest [super=GridClientAbstractMessage > [reqId=3, id=227a26f2-3ada-4be3-8150-5879fdfb48c1, destId=null, > > super=o.a.i.i.processors.rest.client.message.GridClientAuthenticationRequest@177bade > ]]] > class org.apache.ignite.IgniteCheckedException: Failed to send message > (connection was closed): GridSelectorNioSessionImpl > [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=0 > lim=8192 cap=8192], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, > bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker > [name=grid-nio-worker-tcp-rest-1, igniteInstanceName=null, finished=false, > heartbeatTs=1611417921389, hashCode=4009713, interrupted=false, > runner=grid-nio-worker-tcp-rest-1-#36]]], writeBuf=null, readBuf=null, > inRecovery=null, outRecovery=null, closeSocket=true, > outboundMessagesQueueSizeMetric=null,
Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes
HI Andrei, Some more points : 1. Also the javadocs for the querycursor says : https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/QueryCursor.html#getAll-- List getAll() Gets all query results and stores them in the collection. Use this method when you know in advance that query result is relatively small and will not cause memory utilization issues. /Since all the results will be fetched, all the resources will be closed automatically after this call, e.g. there is no need to call close() method in this case. / We are closing the cursor as mentioned in my previous comment - but according to this comment, if the cursor is not closed it shouldnt be a issue since a invocation of the getall method will close it . Please let me know if we are missing something. 2. Some observations- On all the nodes where I got the wrong count : Between the time it executes cache.query and cur.getall, I see this log : 2021-01-15T15:37:15,167 INFO o.a.i.s.c.t.TcpCommunicationSpi [grid-nio-worker-tcp-comm-2-#62%InstanceName%]: Established outgoing communication connection [locAddr=/a.b.c.153:50546, rmtAddr=machinename003.cmc.local/a.b.c.202:47130 ] Not sure why it is trying to connect to another server between the cache.query and cur.getall On the nodes where the count has been right, I dont see that line. 3. Could this be linked to this issue here : http://apache-ignite-users.70518.x6.nabble.com/Regarding-Connection-timed-out-observed-during-client-startup-td35157.html -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: SQL strategy for Apache Ignite 3.0
Hello! Please do not overestimate the extent in which we rely on H2 in Apache Ignite. We mostly use it for query parsing/planning while the rest is done by our own code/ 1) I think that the usage of MERGE is not recommended, since it is not providing additional guarantees from SELECT and then INSERT/UPDATE. I don't think we're going to change the MERGE syntax that we have currently. I didn't even know that there's something wrong with it. 2) I've not heard of having an entirely new type of SYS schema. I think SYS is here to stay for the meantime. 3) Absolutely makes sense, Apache Ignite 3.0 is in a very early stage where only a handful of features are being prototyped. 2.x will remain being the workhorse in the observable future in my opinion. Regards, -- Ilya Kasnacheev пн, 25 янв. 2021 г. в 11:50, Lukas Eder : > Hello folks, > > I'm currently working on the jOOQ integration for Apache Ignite's SQL > language support. I was invited by Denis Magda to post my questions here, > see: > https://twitter.com/denismagda/status/1352316238806958080 > > From what I understand, you're going to use calcite to parse and run your > SQL queries. My questions evolve only around syntax, not optimisation. > > While H2 (which you're currently using in some way) has become quite > standards compliant over the past years, I still think that there will be > substantial differences in syntax. With the syntax not being documented > very well, I wonder what differences one may expect? Will 3.0 be akin to a > complete rewrite of the SQL support also for users, or will you try to stay > backwards compatible to some extent? > > In particular: > > - You're currently supporting H2's rather esoteric MERGE statement, which > even H2 have deprecated themselves in favour of the standard SQL MERGE > statement. I'm assuming you'll follow suit? > - Will the SYS schema be maintained as it is, or will there be an entirely > new type of SYS schema (this is relevant to me to reverse engineer schema > meta data). > - For how long will the 2.x branch be maintained once 3.0 ships? Does it > even make sense to start supporting Ignite 2.x at this point? > > Cheers, > Lukas >
RE: Implementing HA among Ignite Clusters
Hi Alex This got ignored for a while But the known drawbacks of this approach, can you please let me know as I need to finalize an approach on how to route requests to secondary site if primary is not in working condition etc Thanks -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
SQL strategy for Apache Ignite 3.0
Hello folks, I'm currently working on the jOOQ integration for Apache Ignite's SQL language support. I was invited by Denis Magda to post my questions here, see: https://twitter.com/denismagda/status/1352316238806958080 >From what I understand, you're going to use calcite to parse and run your SQL queries. My questions evolve only around syntax, not optimisation. While H2 (which you're currently using in some way) has become quite standards compliant over the past years, I still think that there will be substantial differences in syntax. With the syntax not being documented very well, I wonder what differences one may expect? Will 3.0 be akin to a complete rewrite of the SQL support also for users, or will you try to stay backwards compatible to some extent? In particular: - You're currently supporting H2's rather esoteric MERGE statement, which even H2 have deprecated themselves in favour of the standard SQL MERGE statement. I'm assuming you'll follow suit? - Will the SYS schema be maintained as it is, or will there be an entirely new type of SYS schema (this is relevant to me to reverse engineer schema meta data). - For how long will the 2.x branch be maintained once 3.0 ships? Does it even make sense to start supporting Ignite 2.x at this point? Cheers, Lukas
