Re: How to prevent Ignite downtime when adding tables & caches

[akorensh]

Yes,
   Tables created dynamically in caches that use a persistent data region
will be stored to disk.

   You can try by enabling persistence for the default data region.
   Create a test table, populate w/data, shutdown ignite then restart, data
should be there.

Thanks, Alex



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: How to prevent Ignite downtime when adding tables & caches

[Devin Bost]

We're using native persistence for each of them. Does dynamic cache
creation work for tables?
Is it possible to create tables dynamically that have persistence?

Devin G. Bost


On Wed, Feb 19, 2020 at 11:16 AM akurbanov  wrote:

> Hello,
>
> There is no need to restart the cluster if you want to create a new cache
> as
> dynamic cache creation is supported:
> https://apacheignite.readme.io/docs/jcache#section-dynamic-cache
>
> Do you use native persistence or do you run in-memory?
>
> If this doesn't work for you, could you please describe the case a bit?
>
> Best regards,
> Anton
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: How to access IGFS file written one node from other node in cluster ??

[Preetiiii]

Then how to create shared file system or is there any way to access/modify
file written by one node in cluster by other node ??



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite yarn resources keep on increasing

[ChandanS]

The problem is I am not able to kill my ignite yarn application even though
exception has been thrown while starting the ignite and the resources of the
ignite-yarn spark job keeps piling up. Please find attached image of spark
web-ui. From my "StartStandalone" spark application I use to submit the
ignite-yarn job "ignite-titan-resourceUP". You can see resources going up
for ignite-yarn job though it was submitted with same resources as parent
spark application. The only difference with negative scenario is I give the
ignite_path wrong.


 

 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Connection reset by peer

[Ilya Kasnacheev]

Hello!

[01:07:25,966][WARNING][tcp-comm-worker-#1%SubScriptionCluster%][TcpCommunicationSpi]
Connect timed out (consider increasing 'failureDetectionTimeout'
configuration property) [addr=/172.16.99.27:47100,
failureDetectionTimeout=10]
Failed to send message (node
may have left the grid or TCP connection cannot be established due to
firewall issues)

Looks like massive network problems to me, or very long GC.

Maybe your firewall is too restrictive? Please note that we expect that all
client and server nodes can open connections to each other.

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 06:16, hulitao198758 :

> Detailed error message：
>
> Established outgoing communication connection [locAddr=/
> 10.122.64.129:40870,
> rmtAddr=/10.122.64.128:48339]
>
> [01:01:59,775][SEVERE][grid-nio-worker-tcp-comm-1-#48%SubScriptionCluster%][TcpCommunicationSpi]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=DirectNioClientWorker [super=AbstractNioClientWorker [idx=1,
> bytesRcvd=1151627, bytesSent=2289496, bytesRcvd0=64, bytesSent0=537,
> select=true, super=GridWorker [name=grid-nio-worker-tcp-comm-1,
> igniteInstanceName=SubScriptionCluster, finished=false, hashCode=440471613,
> interrupted=false,
> runner=grid-nio-worker-tcp-comm-1-#48%SubScriptionCluster%]]],
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> inRecovery=GridNioRecoveryDescriptor [acked=2651, resendCnt=0, rcvCnt=2752,
> sentCnt=2652, reserved=true, lastAck=2752, nodeLeft=false,
> node=TcpDiscoveryNode [id=09e38b03-ea63-47bf-a27b-661a0f0ab8d8,
> addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.16.99.27],
> sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.16.99.27:0],
> discPort=0, order=44, intOrder=26, lastExchangeTime=1581939704719,
> loc=false, ver=2.6.0#20180710-sha1:669feacc, isClient=true],
> connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=225, pairedConnections=false],
> outRecovery=GridNioRecoveryDescriptor [acked=2651, resendCnt=0,
> rcvCnt=2752,
> sentCnt=2652, reserved=true, lastAck=2752, nodeLeft=false,
> node=TcpDiscoveryNode [id=09e38b03-ea63-47bf-a27b-661a0f0ab8d8,
> addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.16.99.27],
> sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.16.99.27:0],
> discPort=0, order=44, intOrder=26, lastExchangeTime=1581939704719,
> loc=false, ver=2.6.0#20180710-sha1:669feacc, isClient=true],
> connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=225, pairedConnections=false],
> super=GridNioSessionImpl [locAddr=/10.122.64.129:48339,
> rmtAddr=/10.122.23.179:33052, createTime=1582183927690, closeTime=0,
> bytesSent=33096, bytesRcvd=29254, bytesSent0=211, bytesRcvd0=0,
> sndSchedTime=1582246566604, lastSndTime=1582246918763,
> lastRcvTime=1582246566604, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter
> [parser=o.a.i.i.util.nio.GridDirectParser@7419c93, directMode=true],
> GridConnectionBytesVerifyFilter], accepted=true]]]
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:192)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at
>
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1250)
> at
>
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2339)
> at
>
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2110)
> at
>
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1764)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>
> [01:01:59,776][WARNING][grid-nio-worker-tcp-comm-1-#48%SubScriptionCluster%][TcpCommunicationSpi]
> Closing NIO session because of unhandled exception [cls=class
> o.a.i.i.util.nio.GridNioException, msg=Connection reset by peer]
>
> [01:02:14,897][WARNING][tcp-comm-worker-#1%SubScriptionCluster%][TcpCommunicationSpi]
> Connect timed out (consider increasing 'failureDetectionTimeout'
> configuration property) [addr=/172.16.99.27:47100,
> failureDetectionTimeout=10]
>
> [01:02:14,898][WARNING][tcp-comm-worker-#1%SubScriptionCluster%][TcpCommunicationSpi]
> Connect timed out (consider increasing 'failureDetectionTimeout'
> configuration property) [addr=/0:0:0:0:0:0:0:1%lo:47100,
> failureDetectionTimeout=10]
>
> [01:02:14,898][WARNING][tcp-comm-worker-#1%SubScriptionCluster%][TcpCommunicationSpi]
> Connect timed out (consider increasing 'failureDetectionTimeout'
> configuration property) [addr=/127.0.0.

Re: Null Pointer Error in GridDhtPartitionsExchangeFuture

[Ilya Kasnacheev]

Hello!

I have no idea, I recommend collecting a heap dump and analyzing it to
locate any leaks. I think that something would indeed happen at the cluster
in that time.

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 06:07, wentat :

> Hi Ilya,
>
> at the time of running the experiments in the logs, there was no queries
> running in the background. Just 30 servers and no clients. What could have
> caused such high heap usage?
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Long running query

[Ilya Kasnacheev]

Hello!

Our current optimizer is not very smart. If you found an USE INDEX which
allows your query to run sufficiently fast, my recommendation is to just
use it.

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 14:45, breathem :

> Hello,
> We have two tables LD (8 000 000 rows) and DRUGS (130 000 rows).
> Following query is executed ~7 minutes that is significantly longer then in
> RDBMS (~1,5 sec):
> select d.drug_id, d.drug_name, ld.price
> from drugs d
> left outer join ld on d.drug_id = ld.drug_id and ld.org_id = 264;
>
> Explain for query:
> SELECT
> D__Z0.DRUG_ID AS __C0_0,
> D__Z0.DRUG_NAME AS __C0_1,
> __Z1.PRICE AS __C0_2
> FROM PUBLIC.DRUGS D__Z0
> /* PUBLIC.IDX_DRUG_ID_NAME */
> LEFT OUTER JOIN PUBLIC.LD __Z1
> /* PUBLIC.IDX_ORG_MEDP_DRUG: ORG_ID = 264
> AND DRUG_ID = D__Z0.DRUG_ID
>  */
> ON (__Z1.ORG_ID = 264)
> AND (D__Z0.DRUG_ID = __Z1.DRUG_ID)
> SELECT
> __C0_0 AS DRUG_ID,
> __C0_1 AS DRUG_NAME,
> __C0_2 AS PRICE
> FROM PUBLIC.__T0
> /* PUBLIC."merge_scan" */
>
> Indexes on table LD: IDX_ORG_MEDP_DRUGS(ORG_ID, MEDP_ID, DRUG_ID),
> IDX_DRUG_ID(DRUG_ID)
> Indexes on table DRUGS: IDX_DRUG_ID_NAME(DRUG_ID, DRUG_NAME)
>
> We try to force IDX_DRUG_ID:
> select d.drug_id, d.drug_name, ld.price
> from drugs d
> left outer join ld use index (idx_drug_id) on d.drug_id = ld.drug_id and
> ld.org_id = 264;
>
> This query is executed 8 sec.
>
> Explain for query:
> SELECT
> D__Z0.DRUG_ID AS __C0_0,
> D__Z0.DRUG_NAME AS __C0_1,
> __Z1.PRICE AS __C0_2
> FROM PUBLIC.DRUGS D__Z0
> /* PUBLIC.IDX_DRUG_ID_NAME */
> LEFT OUTER JOIN PUBLIC.LD __Z1 USE INDEX (IDX_DRUG_ID)
> /* PUBLIC.IDX_DRUG_ID: DRUG_ID = D__Z0.DRUG_ID */
> ON (__Z1.ORG_ID = 264)
> AND (D__Z0.DRUG_ID = __Z1.DRUG_ID)
> SELECT
> __C0_0 AS DRUG_ID,
> __C0_1 AS DRUG_NAME,
> __C0_2 AS PRICE
> FROM PUBLIC.__T0
> /* PUBLIC."merge_scan" */
>
> How to speed up query?
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: How to access IGFS file written one node from other node in cluster ??

[Ilya Kasnacheev]

Hello!

We do not recommend developing new IGFS applications because we are
removing this feature.

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 09:28, Preeti Nidgunde :

>  I have written IGFS java application. I want to write shared file such
> that
> if I write file from one node then it is accessible to all other node in
> cluster. How to do that ??
> I referred stack overflow and configured discovery spi to shared file
> system
> but then also it is not working. The program written is accessible to only
> the node who written that file not to other node (Other terminal).
> When I tried to read by giving IGFS path to the file then I
> received
> IGFS file not found exception. Where IGFS store this file.
>
>
> public class FileExample
> {
> public static void main(String[] args) throws Exception
> {
> Ignite ignite =
>
> Ignition.start("/root/apache-ignite-fabric-2.6.0-bin/examples/config/filesystem/example-igfs.xml");
>
>
> System.out.println("\n");
> System.out.println("IGFS example started.");
>
> IgniteFileSystem fs = ignite.fileSystem("myFileSystem");
> IgfsPath dir = new
> IgfsPath("myFileSystem://192.168.1.5:9060/Preeti");
> fs.mkdirs(dir);
>
> IgfsPath file = new IgfsPath(dir, "myFile.txt");
>
> System.out.println(fs.info(file));
>
>
> try (OutputStream out = fs.create(file, true))
> {
> OutputStreamWriter outputStreamWriter = new
> OutputStreamWriter(out);
> outputStreamWriter.write("This is Apache ignite
> file
> system example  Preeri Nidgunde ..Veriats Infoscale  VXVM");
> System.out.println("Done .");
> outputStreamWriter.close();
> }catch(Exception e){}
>
>
> try (InputStream in = fs.open(file))
>  {
> Reader inputStreamReader = new
> InputStreamReader(in);
> int data = inputStreamReader.read();
> while(data != -1)
> {
>  char theChar = (char) data;
> System.out.print(theChar);
>  data = inputStreamReader.read();
> }
>
> inputStreamReader.close();
> }catch(Exception e){}
>
> System.out.println("Read data from file");
> }
> }
>
> On other node I am trying to read file like
>
> public class ReadFile
> {
> public static void main(String[] args) throws Exception
> {
> Ignite ignite =
>
> Ignition.start("/root/apache-ignite-fabric-2.6.0-bin/examples/config/filesystem/example-igfs.xml");
>
> System.out.println("\n");
> System.out.println("IGFS Read example started.");
>
> IgniteFileSystem fs = ignite.fileSystem("myFileSystem");
>
> try (InputStream in = fs.open(new
> IgfsPath("myFileSystem://192.168.1.5:9060/Preeti/myFile.txt")))
>  {
> Reader inputStreamReader = new
> InputStreamReader(in);
> int data = inputStreamReader.read();
> while(data != -1)
> {
>  char theChar = (char) data;
> System.out.print(theChar);
>  data = inputStreamReader.read();
> }
>
> inputStreamReader.close();
> }catch(Exception e){e.printStackTrace();}
>
> System.out.println("Read data from file");
> }
> }
> But it is not working.
>
> I have written file on one node and I want to access that written file from
> other node.
>
> Please help me.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Is Apache ignite support tiering or it only support caching??

[Ilya Kasnacheev]

Hello!

Ignite has optional on-heap tier and also optional disk tier (Native
Persistence will offload data there as RAM is exhausted).

I wonder if that's enough for your use case.

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 15:21, Preet :

> I want to different tier like DRAM, available devices as a tier. How to
> specify such tier option.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: REST API requests hang with no response

[Devin Anderson]

Hi Ilya,

Thank you very much.  I suspect (1) is the missing piece of information I was 
looking for.  I'll add it when I get a chance and will report back.


Thanks again,

Devin

On 2/21/20 4:24 AM, Ilya Kasnacheev wrote:

Hello!

I'll start in the reverse order:

3. If everything is OK, the process should take around a second (for 
non-persistent cluster).

2. As soon you see "Topology snapshot" in the log, the process is complete.
1. From your configuration I see suspicious that it only lists two other 
nodes and not itself. It is recommended that any node can discover itself and 
start a cluster as 1st node. Try adding [own ip address]


Regards,
--
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 14:52, Devin Anderson >:


Hi Ilya,

That certainly makes sense, but I'm not totally sure how to act on that
information yet.  A couple questions:

1.) Given the configuration file I posted (which is basically the same on
each
node in the cluster, save that the IP addresses of the nodes to discover are
different), should each of the nodes eventually join the cluster?  Am I
missing
anything?
2.) Is there a message that I should see in the logs that identifies that
the
node has successfully joined the cluster?
3.) How long should I expect the process to take with three nodes (just a
loose
estimate)?

Thanks for your ongoing help.  It's much appreciated. :)

Devin

On 2/21/20 3:23 AM, Ilya Kasnacheev wrote:
> Hello!
>
> Your node has never finished joining to cluster nor was able to
self-discover
> to form a cluster of its own, as evident by:
>
>
> "main" #1 prio=5 os_prio=0 tid=0x7f7e8000d000 nid=0x5fed waiting on
> condition [0x7f7e8875f000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at 
org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7778)
> at
>

org.apache.ignite.spi.discovery.tcp.*ServerImpl.sendJoinRequestMessage*(ServerImpl.java:1131)
> at
>

org.apache.ignite.spi.discovery.tcp.*ServerImpl.joinTopology*(ServerImpl.java:910)
> at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:391)
> at
>

org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2020)
> at
>

org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
>

org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
> at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
> at
>

org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
>

org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> - locked <0x0005e8cca5b8> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at
>

org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
> at org.apache.ignite.Ignition.start(Ignition.java:348)
> at
>

org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
>
> Until node is in topology, obviously it can't serve any requests.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 21 февр. 2020 г. в 01:55, Devin Anderson mailto:dande...@akamai.com>
> >>:
>
>     Hi Ilya,
>
>     I'm attaching the `jstack` dump to this message. When I took the dump,
>     there
>     were ten requests that had been made to the Apache Ignite REST API
using
>     POST
>     data of the form:
>
>      cmd=add&key=[key]&value=[value]
>
>     ... where [key] and [value] were proper URI encoded data.
>
>     Thanks in advance for any help.  I'll take a look as well and try to
>     figure out
>     what's going on.
>
>     Devin
>
>     On 2/20/20 5:43 AM, Ilya Kasnacheev wrote:
>     > Hello!
>     >
>     > Please collect thread dump (jstack) from affected node, share it
with us.
>     >
>     > Regards,
>     > --
>     > Ilya Kasnacheev
>     >
>     >
>     > чт, 20 февр. 2020 г. в 16:17, Devin Anderson mailto:dande...@akamai.com>
>     

Re: C++ Node doesnot shut down

[Ilya Kasnacheev]

Hello!

Can you collect stack traces (both JVM with jstack and C with gdb, if
possible)?

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 14:55, F.D. :

> Hi igniters,
> I'm using a client node in C++ to lanch several compute on a cluster, and
> it's working quite well, but when I try to close the node with every king
> of Ignition::Stop/StopAll(true/false), my client remain freezed.
>
> I'm using the 2.7.6. Do you have any suggestions?
>
> Thanks,
>F.D.
>
>

Re: REST API requests hang with no response

[Ilya Kasnacheev]

Hello!

I'll start in the reverse order:

3. If everything is OK, the process should take around a second (for
non-persistent cluster).
2. As soon you see "Topology snapshot" in the log, the process is complete.
1. From your configuration I see suspicious that it only lists two other
nodes and not itself. It is recommended that any node can discover itself
and start a cluster as 1st node. Try adding [own ip address]

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 14:52, Devin Anderson :

> Hi Ilya,
>
> That certainly makes sense, but I'm not totally sure how to act on that
> information yet.  A couple questions:
>
> 1.) Given the configuration file I posted (which is basically the same on
> each
> node in the cluster, save that the IP addresses of the nodes to discover
> are
> different), should each of the nodes eventually join the cluster?  Am I
> missing
> anything?
> 2.) Is there a message that I should see in the logs that identifies that
> the
> node has successfully joined the cluster?
> 3.) How long should I expect the process to take with three nodes (just a
> loose
> estimate)?
>
> Thanks for your ongoing help.  It's much appreciated. :)
>
> Devin
>
> On 2/21/20 3:23 AM, Ilya Kasnacheev wrote:
> > Hello!
> >
> > Your node has never finished joining to cluster nor was able to
> self-discover
> > to form a cluster of its own, as evident by:
> >
> >
> > "main" #1 prio=5 os_prio=0 tid=0x7f7e8000d000 nid=0x5fed waiting on
> > condition [0x7f7e8875f000]
> >java.lang.Thread.State: TIMED_WAITING (sleeping)
> > at java.lang.Thread.sleep(Native Method)
> > at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7778)
> > at
> >
> org.apache.ignite.spi.discovery.tcp.*ServerImpl.sendJoinRequestMessage*(ServerImpl.java:1131)
> > at
> >
> org.apache.ignite.spi.discovery.tcp.*ServerImpl.joinTopology*(ServerImpl.java:910)
> > at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:391)
> > at
> >
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2020)
> > at
> >
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> > at
> >
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
> > at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
> > at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
> > at
> >
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> > at
> >
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> > - locked <0x0005e8cca5b8> (a
> > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> > at
> >
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
> > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
> > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
> > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
> > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
> > at org.apache.ignite.Ignition.start(Ignition.java:348)
> > at
> >
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
> >
> > Until node is in topology, obviously it can't serve any requests.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 21 февр. 2020 г. в 01:55, Devin Anderson  > >:
> >
> > Hi Ilya,
> >
> > I'm attaching the `jstack` dump to this message.  When I took the
> dump,
> > there
> > were ten requests that had been made to the Apache Ignite REST API
> using
> > POST
> > data of the form:
> >
> >  cmd=add&key=[key]&value=[value]
> >
> > ... where [key] and [value] were proper URI encoded data.
> >
> > Thanks in advance for any help.  I'll take a look as well and try to
> > figure out
> > what's going on.
> >
> > Devin
> >
> > On 2/20/20 5:43 AM, Ilya Kasnacheev wrote:
> > > Hello!
> > >
> > > Please collect thread dump (jstack) from affected node, share it
> with us.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 20 февр. 2020 г. в 16:17, Devin Anderson  > 
> > > >>:
> > >
> > > Hi all,
> > >
> > > I'm seeing issues wherein the Apache Ignite REST API appears
> to accept
> > > requests, but doesn't ever reply.  This doesn't always happen;
> for
> > > example, if
> > > I make a request that I expect the API to reject, I get back a
> > response:
> > >
> > > --
> > >
> > > # curl -v -X GET 'http://127.0.0.1:8080/ignite
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-

Re: Is Apache ignite support tiering or it only support caching??

[Preetiiii]

I want to different tier like DRAM, available devices as a tier. How to
specify such tier option.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

C++ Node doesnot shut down

[F.D.]

Hi igniters,
I'm using a client node in C++ to lanch several compute on a cluster, and
it's working quite well, but when I try to close the node with every king
of Ignition::Stop/StopAll(true/false), my client remain freezed.

I'm using the 2.7.6. Do you have any suggestions?

Thanks,
   F.D.

Re: REST API requests hang with no response

[Devin Anderson]

Hi Ilya,

That certainly makes sense, but I'm not totally sure how to act on that 
information yet.  A couple questions:


1.) Given the configuration file I posted (which is basically the same on each 
node in the cluster, save that the IP addresses of the nodes to discover are 
different), should each of the nodes eventually join the cluster?  Am I missing 
anything?
2.) Is there a message that I should see in the logs that identifies that the 
node has successfully joined the cluster?
3.) How long should I expect the process to take with three nodes (just a loose 
estimate)?


Thanks for your ongoing help.  It's much appreciated. :)

Devin

On 2/21/20 3:23 AM, Ilya Kasnacheev wrote:

Hello!

Your node has never finished joining to cluster nor was able to self-discover 
to form a cluster of its own, as evident by:



"main" #1 prio=5 os_prio=0 tid=0x7f7e8000d000 nid=0x5fed waiting on 
condition [0x7f7e8875f000]

   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7778)
at 
org.apache.ignite.spi.discovery.tcp.*ServerImpl.sendJoinRequestMessage*(ServerImpl.java:1131)
at 
org.apache.ignite.spi.discovery.tcp.*ServerImpl.joinTopology*(ServerImpl.java:910)

at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:391)
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2020)
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)

at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
- locked <0x0005e8cca5b8> (a 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)

at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)

at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)


Until node is in topology, obviously it can't serve any requests.

Regards,
--
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 01:55, Devin Anderson >:


Hi Ilya,

I'm attaching the `jstack` dump to this message.  When I took the dump,
there
were ten requests that had been made to the Apache Ignite REST API using
POST
data of the form:

 cmd=add&key=[key]&value=[value]

... where [key] and [value] were proper URI encoded data.

Thanks in advance for any help.  I'll take a look as well and try to
figure out
what's going on.

Devin

On 2/20/20 5:43 AM, Ilya Kasnacheev wrote:
> Hello!
>
> Please collect thread dump (jstack) from affected node, share it with us.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 20 февр. 2020 г. в 16:17, Devin Anderson mailto:dande...@akamai.com>
> >>:
>
>     Hi all,
>
>     I'm seeing issues wherein the Apache Ignite REST API appears to accept
>     requests, but doesn't ever reply.  This doesn't always happen; for
>     example, if
>     I make a request that I expect the API to reject, I get back a
response:
>
>     --
>
>     # curl -v -X GET 'http://127.0.0.1:8080/ignite


>   
 
'
>     * Hostname was NOT found in DNS cache
>     *   Trying 127.0.0.1...
>     * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
>      > GET /ignite HTTP/1.1
>      > User-Agent: curl/7.35.0
>      > Host: 127.0.0.1:8080

Long running query

[breathem]

Hello,
We have two tables LD (8 000 000 rows) and DRUGS (130 000 rows).
Following query is executed ~7 minutes that is significantly longer then in
RDBMS (~1,5 sec):
select d.drug_id, d.drug_name, ld.price
from drugs d
left outer join ld on d.drug_id = ld.drug_id and ld.org_id = 264;

Explain for query: 
SELECT
D__Z0.DRUG_ID AS __C0_0,
D__Z0.DRUG_NAME AS __C0_1,
__Z1.PRICE AS __C0_2
FROM PUBLIC.DRUGS D__Z0
/* PUBLIC.IDX_DRUG_ID_NAME */
LEFT OUTER JOIN PUBLIC.LD __Z1
/* PUBLIC.IDX_ORG_MEDP_DRUG: ORG_ID = 264
AND DRUG_ID = D__Z0.DRUG_ID
 */
ON (__Z1.ORG_ID = 264)
AND (D__Z0.DRUG_ID = __Z1.DRUG_ID)
SELECT
__C0_0 AS DRUG_ID,
__C0_1 AS DRUG_NAME,
__C0_2 AS PRICE
FROM PUBLIC.__T0
/* PUBLIC."merge_scan" */

Indexes on table LD: IDX_ORG_MEDP_DRUGS(ORG_ID, MEDP_ID, DRUG_ID),
IDX_DRUG_ID(DRUG_ID)
Indexes on table DRUGS: IDX_DRUG_ID_NAME(DRUG_ID, DRUG_NAME)

We try to force IDX_DRUG_ID:
select d.drug_id, d.drug_name, ld.price
from drugs d
left outer join ld use index (idx_drug_id) on d.drug_id = ld.drug_id and
ld.org_id = 264;

This query is executed 8 sec.

Explain for query:
SELECT
D__Z0.DRUG_ID AS __C0_0,
D__Z0.DRUG_NAME AS __C0_1,
__Z1.PRICE AS __C0_2
FROM PUBLIC.DRUGS D__Z0
/* PUBLIC.IDX_DRUG_ID_NAME */
LEFT OUTER JOIN PUBLIC.LD __Z1 USE INDEX (IDX_DRUG_ID)
/* PUBLIC.IDX_DRUG_ID: DRUG_ID = D__Z0.DRUG_ID */
ON (__Z1.ORG_ID = 264)
AND (D__Z0.DRUG_ID = __Z1.DRUG_ID)
SELECT
__C0_0 AS DRUG_ID,
__C0_1 AS DRUG_NAME,
__C0_2 AS PRICE
FROM PUBLIC.__T0
/* PUBLIC."merge_scan" */

How to speed up query?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: ERROR: h2 Unsupported connection setting "MULTI_THREADED"

[Ilya Kasnacheev]

Hello!

I've heard about issues with e.g. Spring Boot overriding h2 database
version and breaking our runtime. I'm not sure who else does that.

Regards,





































-- 
Ilya Kasnacheev


чт, 20 февр. 2020 г. в 19:24, Andrew Munn :

> Thanks.  Adding this runtime dependency to build.gradle fixed it:
>
> dependencies {
> runtime("com.h2database:h2:1.4.197")
> ...
> compile group: 'org.apache.ignite', name: 'ignite-spring', version:
> '2.7.6'
> compile group: 'org.apache.ignite', name: 'ignite-core', version:
> '2.7.6'
> }
>
> But I suspect this should be getting enforced automatically if using h2
> ver1.4.200 breaks something.  Am I specifying the Ignite dependency
> incorrectly?
>
>
> On Thu, Feb 20, 2020 at 4:08 AM Taras Ledkov  wrote:
>
>> Hi,
>>
>> Ignite uses H2 version 1.4.197 (see [1]).
>>
>>
>> [1]. https://github.com/apache/ignite/blob/master/parent/pom.xml#L74
>>
>> On 20.02.2020 4:36, Andrew Munn wrote:
>> > I'm building/running my client app w/Gradle and I'm seeing this
>> > error.  Am I overloading the Ingite H2 fork with the real H2 or
>> > something?  It appears I have the latest h2:
>> >
>> > [.gradle]$ find ./ -name *h2*
>> > ./caches/modules-2/metadata-2.82/descriptors/com.h2database
>> > ./caches/modules-2/metadata-2.82/descriptors/com.h2database/h2
>> > ./caches/modules-2/files-2.1/com.h2database
>> > ./caches/modules-2/files-2.1/com.h2database/h2
>> >
>> ./caches/modules-2/files-2.1/com.h2database/h2/1.4.200/6178ecda6e9fea8739a3708729efbffd88be43e3/h2-1.4.200.pom
>> >
>> ./caches/modules-2/files-2.1/com.h2database/h2/1.4.200/f7533fe7cb8e99c87a43d325a77b4b678ad9031a/h2-1.4.200.jar
>> >
>> >
>> >
>> > 2020-02-19 19:59:28.229 ERROR 102356 --- [   main]
>> > o.a.i.internal.IgniteKernal%dev-cluster  : Exception during start
>> > processors, node will be stopped and close connections
>> > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
>> > to initialize system DB connection:
>> >
>> jdbc:h2:mem:b52dce26-ba01-4051-9130-e087e19fab4f;LOCK_MODE=3;MULTI_THREADED=1;DB_CLOSE_ON_EXIT=FALSE;DEFAULT_LOCK_TIMEOUT=1;FUNCTIONS_IN_SCHEMA=true;OPTIMIZE_REUSE_RESULTS=0;QUERY_CACHE_SIZE=0;MAX_OPERATION_MEMORY=0;BATCH_JOINS=1;ROW_FACTORY="org.apache.ignite.internal.processors.query.h2.opt.GridH2PlainRowFactory";DEFAULT_TABLE_ENGINE=org.apache.ignite.internal.processors.query.h2.opt.GridH2DefaultTableEngine
>> > at
>> >
>> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.systemConnection(IgniteH2Indexing.java:434)
>>
>> > ~[ignite-indexing-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSystemStatement(IgniteH2Indexing.java:699)
>>
>> > ~[ignite-indexing-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.createSchema0(IgniteH2Indexing.java:646)
>>
>> > ~[ignite-indexing-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.start(IgniteH2Indexing.java:3257)
>>
>> > ~[ignite-indexing-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.processors.query.GridQueryProcessor.start(GridQueryProcessor.java:248)
>>
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1700)
>>
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> > org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1017)
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
>>
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
>>
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> > org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> >
>> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
>>
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at org.apache.ignite.Ignition.start(Ignition.java:348)
>> > ~[ignite-core-2.7.6.jar:2.7.6]
>> > at
>> >
>> com.centiva.ig.etl.loader.LoaderApplication.main(LoaderApplication.java:14)
>> > ~[main/:na]
>> > Caused by: org.h2.jdbc.JdbcSQLNonTransientConnectionException:
>> > Unsupported connection setting "MULTI_THREADED" [90113-200]
>> > at
>> > org.h2.message.DbException

Re: REST API requests hang with no response

[Ilya Kasnacheev]

Hello!

Your node has never finished joining to cluster nor was able to
self-discover to form a cluster of its own, as evident by:


"main" #1 prio=5 os_prio=0 tid=0x7f7e8000d000 nid=0x5fed waiting on
condition [0x7f7e8875f000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7778)
at org.apache.ignite.spi.discovery.tcp.*ServerImpl.sendJoinRequestMessage*
(ServerImpl.java:1131)
at org.apache.ignite.spi.discovery.tcp.*ServerImpl.joinTopology*
(ServerImpl.java:910)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:391)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2020)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:939)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1066)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
- locked <0x0005e8cca5b8> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)

Until node is in topology, obviously it can't serve any requests.

Regards,
-- 
Ilya Kasnacheev


пт, 21 февр. 2020 г. в 01:55, Devin Anderson :

> Hi Ilya,
>
> I'm attaching the `jstack` dump to this message.  When I took the dump,
> there
> were ten requests that had been made to the Apache Ignite REST API using
> POST
> data of the form:
>
>  cmd=add&key=[key]&value=[value]
>
> ... where [key] and [value] were proper URI encoded data.
>
> Thanks in advance for any help.  I'll take a look as well and try to
> figure out
> what's going on.
>
> Devin
>
> On 2/20/20 5:43 AM, Ilya Kasnacheev wrote:
> > Hello!
> >
> > Please collect thread dump (jstack) from affected node, share it with us.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 20 февр. 2020 г. в 16:17, Devin Anderson  > >:
> >
> > Hi all,
> >
> > I'm seeing issues wherein the Apache Ignite REST API appears to
> accept
> > requests, but doesn't ever reply.  This doesn't always happen; for
> > example, if
> > I make a request that I expect the API to reject, I get back a
> response:
> >
> > --
> >
> > # curl -v -X GET 'http://127.0.0.1:8080/ignite
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1-3A8080_ignite&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=O-a0zsxmvZZBVCsKS7owS9oPa3AKjd7Xpau8laEriDM&m=0D1iM7MuHAG3uQxX5V8Iv_9kNyO25FNACjcqQnHaaLs&s=Q3T6HlQSi3TnKwaRcPsb0MWMRbFNexaNfrucVQSrTkI&e=
> >'
> > * Hostname was NOT found in DNS cache
> > *   Trying 127.0.0.1...
> > * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> >  > GET /ignite HTTP/1.1
> >  > User-Agent: curl/7.35.0
> >  > Host: 127.0.0.1:8080
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1-3A8080&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=O-a0zsxmvZZBVCsKS7owS9oPa3AKjd7Xpau8laEriDM&m=0D1iM7MuHAG3uQxX5V8Iv_9kNyO25FNACjcqQnHaaLs&s=gS2lm03jyjMVp9ZTWC259JI_RG9y4l9QsuvxX4Cz85c&e=
> >
> >  > Accept: */*
> >  >
> > < HTTP/1.1 400 Bad Request
> > < Date: Thu, 20 Feb 2020 11:21:22 GMT
> > < Content-Type: application/json;charset=utf-8
> > < Content-Length: 0
> > * Server Jetty(9.4.11.v20180605) is not blacklisted
> > < Server: Jetty(9.4.11.v20180605)
> > <
> > * Connection #0 to host 127.0.0.1 left intact
> >
> > --
> >
> > I expect the (above) request above to fail because I don't supply the
> > required
> > `cmd` parameter.
> >
> > However, if I make a request that I believe should succeed, I never
> > receive a
> > response:
> >
> > --
> >
> > # curl -v 'http://127.0.0.1:8080/ignite?cmd=version
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1-3A8080_ignite-3Fcmd-3Dversion&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=O-a0zsxmvZZBVCsKS7owS9oPa3AKjd7Xpau8laEriDM&m=0D1iM7MuHAG3uQxX5V8Iv_9kNyO25FNACjcqQnHaaLs&s=USDfyc0TCRCJRx4vzXe9ezgsCMJ8YfFh2IK983DMgrc&e=
> >'
> > * Hostname was NOT found in DNS cache
> > *   Trying 127.0.0.1..

Re: Is Apache ignite support tiering or it only support caching??

[Stephen Darlington]

What are you trying to achieve? You can do read/write through with an external 
third-party database, you can use Ignite’s transactional persistence, both of 
which allow you to have different tiers with varied speeds/volumes of data.

Regards,
Stephen

> On 21 Feb 2020, at 09:58, Preet  wrote:
> 
> I am looking for tiering facility. If Ignite support then send some links or
> info.
> Thanks in advance.
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Is Apache ignite support tiering or it only support caching??

[Preetiiii]

I am looking for tiering facility. If Ignite support then send some links or
info.
Thanks in advance.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/