Thank you Ilya.
Instead of configuring individual store dir on kubernetes pvc, I pointed the
workDirectory to the pvd and there is no more NPE, but after restarting the
whole cluster a new SQL class has been generated to represent the SQL cache.
visor> cache -scan -c=@c0
Entries in cache:
Hi,
We have been running ignite v2.5.0 snapshot (2018/5/11) fine for about two
weeks.
But suddenly, the grid stopped responding with massive infinite log spams,
/
2018/05/24 18:56:14.909 [INFO
][grid-nio-worker-tcp-comm-5-#46][TcpCommunicationSpi] Accepted incoming
communication connection
I am trying to connect Tableau to my Ignite (version 2.2) cache in a
different host.
I have followed the steps mentioned here
https://apacheignite-sql.readme.io/docs/tableau , and everything worked
well.
However, when I try to connect to the Apache Ignite Driver, as described in
this section:
Hello,
Hello,
To unsubscribe from the user mailing list send a letter to
user-unsubscr...@ignite.apache.org with a word "Unsubscribe" without quotes as
a subject.
If you have a mailing client, follow an unsubscribe link here:
https://ignite.apache.org/community/resources.html#mail-lists
Hi Andrew,
I have found what is causing problem here and moved it into a more specific
thread:
http://apache-ignite-users.70518.x6.nabble.com/QueryCursor-getAll-performance-is-very-very-low-td21691.html
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Great , Thank You (
I will try to do it and test it to see how it works.
Thank You again for the clarification .
Vladik
On 5/29/18, 16:08, "aealexsandrov" wrote:
Hi,
I think that it could work. But I think you in case if you see that you
should change the list of nodes
--
E-MAIL CONFIDENTIALITY NOTICE: The information transmitted in this e-mail and
in any replies and forwards are for the sole use of the above individual(s) or
entities and may contain proprietary, privileged and/or highly
Hi Andrew,
I had analyzed this further and found out that actually ther cursor getAll
is making it slow. I have pointed this out in the thread below:
http://apache-ignite-users.70518.x6.nabble.com/QueryCursor-getAll-performance-is-very-very-low-td21691.html
--
Sent from:
Hi,
Why you think the performance is slow?
Ignite SQL has an H2 underneath and have some overhead as it is a distributed
system at first. So, local query latency can be slightly higher.
How do you measure query latency?
You may need to warm grid up to all components involved in query initialize.
Hi,
I have 200 caches loaded into a single data region. Among that I have a
customerCache which has 300K records. It has many indexed fields, including
customer number.
When I query using *SQLFieldsQuery *on this particular cache (where
condition has just customer number = ?), it takes
Thank You
The current behavior when it runs only from coordinator is good enough.
I have modified you example to run the predicate on nodes to check for example
some file existence .
I think it stateless but for sure not idempotent .
See below it just returns nodes that has some file on the
Hi,
I have 200 caches loaded into a single data region. Among that I have a
customerCache which has 300K records. It has many indexed fields, including
customer number.
When I query using *SQLFieldsQuery *on this particular cache (where
condition has just customer number = ?), it takes around
Hi,
I checked next code:
Ignite ignite =
IgnitionEx.start("examples/config/example-ignite.xml", "ignite-1");
Ignite ignite2 =
IgnitionEx.start("examples/config/example-ignite.xml", "ignite-2");
ClusterGroup cg = ignite2.cluster().forPredicate(new
IgnitePredicate() {
Hi David,
Described behaviour (when too much time is spend on locks) was fixed in
Ignite 2.5 by 3 or 4 optimization changes.
IMO release will be published soon,so new Ignite vesion should get
performance boost in this case.
Yes, 'times 4' should be removed from the doc
14 matches
Mail list logo
