Total cache entries count

[shivakumar]

Hi 

I have 2.7.0 ignite running is K8s environment, I ingested large number of
records to the table by enabling native persistence and I'am monitoring
total cache entries in that table using visor by running *visor> cache
-c=Cache_name* as well as sqlline by running *select count(*) from
table_name;*
both are giving aroung 15 crore entries and i configured 12GB for default
data region/off-heap and it is full by this time.

My question is, is that count 15 crore is the cache entries available only
in *RAM/Off-heap* or cache entries available both in *RAM/Off-heap + disk
(persistence)* ?

regards,
shiva 



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

Segmentation Plugin blog or article?

[joseheitor]

Is there a blog or article that describes the use-cases and usage of the
Segmentation Plugin:
https://github.com/luqmanahmad/ignite-plugins
  

Also, does the community have any step-by-step recommendations for managing
and recovering from split-brain conditions without the loss of data?



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

Re: Total cache entries count

[Ilya Kasnacheev]

Hello!

This is number of entries available both on disk and in RAM.

Regards,
-- 
Ilya Kasnacheev


пн, 22 апр. 2019 г. в 10:14, shivakumar :

> Hi
>
> I have 2.7.0 ignite running is K8s environment, I ingested large number of
> records to the table by enabling native persistence and I'am monitoring
> total cache entries in that table using visor by running *visor> cache
> -c=Cache_name* as well as sqlline by running *select count(*) from
> table_name;*
> both are giving aroung 15 crore entries and i configured 12GB for default
> data region/off-heap and it is full by this time.
>
> My question is, is that count 15 crore is the cache entries available only
> in *RAM/Off-heap* or cache entries available both in *RAM/Off-heap + disk
> (persistence)* ?
>
> regards,
> shiva
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Table not getting dropped

[shivakumar]

Hi all,
I created one table with JDBC connection, batch inserted around 13 crore
records to that table then I'am trying to drop the table from sqlline, but
it hangs for some time and gives *java.sql.SQLException: Statement is
closed* exception and if i check number of records using *select count(*)
from Cell;* statements then all 13 crore records still exists in that table
but if I try to drop again it says table not exists.

[root@ignite-st-controller bin]# ./sqlline.sh --verbose=true -u
"jdbc:ignite:thin://10.*.*.*:10800;user=ignite;password=ignite;"
issuing: !connect
jdbc:ignite:thin://10.*.*.*:10800;user=ignite;password=ignite; '' ''
org.apache.ignite.IgniteJdbcThinDriver
Connecting to jdbc:ignite:thin://10.*.*.*:10800;user=ignite;password=ignite;
Connected to: Apache Ignite (version 2.7.0#19700101-sha1:)
Driver: Apache Ignite Thin JDBC Driver (version
2.7.0#20181130-sha1:256ae401)
Autocommit status: true
Transaction isolation: TRANSACTION_REPEATABLE_READ
sqlline version 1.3.0
0: jdbc:ignite:thin://10.*.*.*:10800> DROP TABLE IF EXISTS CELL;
Error: Statement is closed. (state=,code=0)
java.sql.SQLException: Statement is closed.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.ensureNotClosed(JdbcThinStatement.java:862)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.getWarnings(JdbcThinStatement.java:454)
at sqlline.Commands.execute(Commands.java:849)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
0: jdbc:ignite:thin://10.*.*.*:10800>
0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from CELL;
++
|COUNT(*)|
++
| 131471437  |
++
1 row selected (4.564 seconds)
0: jdbc:ignite:thin://10.*.*.*:10800> DROP TABLE CELL;
Error: Table doesn't exist: CELL (state=42000,code=3001)
java.sql.SQLException: Table doesn't exist: CELL
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
0: jdbc:ignite:thin://10.*.*.*:10800> select count(*) from CELL;
++
|COUNT(*)|
++
| 131482007  |
++
1 row selected (1.264 seconds)
0: jdbc:ignite:thin://10.*.*.*:10800>




regards,
shiva






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

Re: Segmentation Plugin blog or article?

[Denis Magda]

Hello,

Ignite community offers to enable ZooKeeper-based discovery for those who'd
like to come around split-brain easily:
https://apacheignite.readme.io/docs/zookeeper-discovery#section-failures-and-split-brain-handling

Also, the chances to lose partitions are high during network segmentation.
Set up a partition less policy suited for your use case:
https://apacheignite.readme.io/docs/partition-loss-policies

-
Denis


On Mon, Apr 22, 2019 at 1:39 AM joseheitor  wrote:

> Is there a blog or article that describes the use-cases and usage of the
> Segmentation Plugin:
> https://github.com/luqmanahmad/ignite-plugins
> 
>
> Also, does the community have any step-by-step recommendations for managing
> and recovering from split-brain conditions without the loss of data?
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

What happens when a client gets disconnected

[Matt Nohelty]

I already posted this question to stack overflow here
https://stackoverflow.com/questions/55801760/what-happens-in-apache-ignite-when-a-client-gets-disconnected
but this mailing list is probably more appropriate.

We use Apache Ignite for caching and are seeing some unexpected behavior
across all of the clients of cluster when one of the clients fails. The
Ignite cluster itself has three servers and there are approximately 12
servers connecting to that cluster as clients. The cluster has persistence
disabled and many of the caches have near caching enabled.

What we are seeing is that when one of the clients fail (out of memory,
high CPU, network connectivity, etc.), threads on all the other clients
block for a period of time. During these times, the Ignite servers
themselves seem fine but I see things like the following in the logs:

Topology snapshot [ver=123, servers=3, clients=11, CPUs=XXX,
offheap=XX.XGB, heap=XXX.GB]Topology snapshot [ver=124, servers=3,
clients=10, CPUs=XXX, offheap=XX.XGB, heap=XXX.GB]

The topology itself is clearly changing when a client connects/disconnects
but is there anything happening internally inside the cluster that could
cause blocking on other clients? I would expect re-balancing of data when a
server disconnects but not a client.

>From a thread dump, I see many threads stuck in the following state:

java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)- parking to wait for
<0x00078a86ff18> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7452)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.awaitAllReplies(GridReduceQueryExecutor.java:1056)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1339)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1403)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at java.lang.Iterable.forEach(Iterable.java:74)...

Any ideas, suggestions, or further avenues to investigate would be much
appreciated.