Re: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
Hello. Yes,u are right.Thanks a lot for u reply. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Data Isolation during Ignite Cache load
Yes, SQL queries use data that was already preloaded only. Evgenii ср, 18 мар. 2020 г. в 01:23, nithin91 < nithinbharadwaj.govindar...@franklintempleton.com>: > Hi , > > Filter in the sense, SQL Fields Query with where clause is executed. I > hope > the following example helps you understand my query. > > *Scenario:* > > For example there is a cache named Products which has 1 million records > with > two distinct product categories(i.e. Furniture,Electronics) among these 1 > million records. > > Now once the Data load is started , if i execute a sql fields query like > below, will i get the count as 1 million or only the count of records that > are loaded so far. > > select count(1) from Products where category='Electronics' > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Unsafe usage of org.h2.util.JdbcUtils in Ignite
Hello, org.h2.util.JdbcUtils is utility class with all static methods and configured via System.properties. So it system wide resource. It is incorrect inject Ignite specific settings in it. this - value: org.apache.ignite.internal.IgniteKernal #1 <- grid - class: org.apache.ignite.internal.GridKernalContextImpl, value: org.apache.ignite.internal.IgniteKernal #1 <- ctx - class: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing, value: org.apache.ignite.internal.GridKernalContextImpl #2 <- this$0 - class: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$10, value: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing #2 <- serializer - class: org.h2.util.JdbcUtils, value: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$10 #1 <- [5395] - class: java.lang.Object[], value: org.h2.util.JdbcUtils class JdbcUtils <- elementData - class: java.util.Vector, value: java.lang.Object[] #37309 <- classes - class: sun.misc.Launcher$AppClassLoader, value: java.util.Vector #31 <- contextClassLoader (thread object) - class: java.lang.Thread, value: sun.misc.Launcher$AppClassLoader #1 1. It cause problems, if it need to work with H2 databases from same JVM where ignite run. 2. It cause problems, when some Ignites run in same JVM 3. It makes closed IgniteKernal reachable from GC root. I think it is bad architecture solution to use this class and use H2 related system properties at all. Andrey.
Ignite memory leaks in 2.8.0
Hello, There are at least two way link to IgniteKernal leaks to GC root and makes it unavailable for GC. The first one: this - value: org.apache.ignite.internal.IgniteKernal #1 <- grid - class: org.apache.ignite.internal.GridKernalContextImpl, value: org.apache.ignite.internal.IgniteKernal #1 <- ctx - class: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing, value: org.apache.ignite.internal.GridKernalContextImpl #2 <- this$0 - class: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$10, value: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing #2 <- serializer - class: org.h2.util.JdbcUtils, value: org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$10 #1 <- [5395] - class: java.lang.Object[], value: org.h2.util.JdbcUtils class JdbcUtils <- elementData - class: java.util.Vector, value: java.lang.Object[] #37309 <- classes - class: sun.misc.Launcher$AppClassLoader, value: java.util.Vector #31 <- contextClassLoader (thread object) - class: java.lang.Thread, value: sun.misc.Launcher$AppClassLoader #1 org.h2.util.JdbcUtils has static field JavaObjectSerializer serializer, which see IgniteKernal via IgniteH2Indexing. It make closed and stopped IgniteKernal non collectable by GC. If some Ignites run in same JVM, JdbcUtils will always use only one, and it can cause some races. The second way: this - value: org.apache.ignite.internal.IgniteKernal #2 <- grid - class: org.apache.ignite.internal.GridKernalContextImpl, value: org.apache.ignite.internal.IgniteKernal #2 <- ctx - class: org.apache.ignite.internal.processors.cache.GridCacheContext, value: org.apache.ignite.internal.GridKernalContextImpl #1 <- cctx - class: org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry, value: org.apache.ignite.internal.processors.cache.GridCacheContext #24 <- parent - class: org.apache.ignite.internal.processors.cache.GridCacheMvccCandidate, value: org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry #4 <- [0] - class: java.lang.Object[], value: org.apache.ignite.internal.processors.cache.GridCacheMvccCandidate #1 <- elements - class: java.util.ArrayDeque, value: java.lang.Object[] #43259 <- value - class: java.lang.ThreadLocal$ThreadLocalMap$Entry, value: java.util.ArrayDeque #816 <- [119] - class: java.lang.ThreadLocal$ThreadLocalMap$Entry[], value: java.lang.ThreadLocal$ThreadLocalMap$Entry #51 <- table - class: java.lang.ThreadLocal$ThreadLocalMap, value: java.lang.ThreadLocal$ThreadLocalMap$Entry[] #21 <- threadLocals (thread object) - class: java.lang.Thread, value: java.lang.ThreadLocal$ThreadLocalMap #2 Link to IgniteKernal leaks to ThreadLocal variable, so when we start/stop many instances of Ignite in same jvm during testing, we got many stopped “zomby” ignites on ThreadLocal context of main test thread and it cause OutOfMemory after some dozens of tests. Andrey.
Re: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
Hi, Looks like the issue is related to https://issues.apache.org/jira/browse/IGNITE-12800. I've not fixed it yet in Ignite. Hmm. I guess the error is happen when you select from REPLICATED cache. Am I right? Now I recommend don't use 'lazy' mode via JDBC client for local queries and for query from replicated caches (because it is transforms to local query). I suppose we'll fix it at 2.8.1. On 17.03.2020 4:32, yangjiajun wrote: Hello.Thanks for u reply. Actually I am using Hakaricp connection pool.I think my threads can't use same connection at same time.The threads can only reuse same connection at different time.My code works well in ignite 2.7 and it also works when I set lazy=false in ignite 2.8. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/ -- Taras Ledkov Mail-To: tled...@gridgain.com
Re: Ignite 2.8.0. Heap mem issue
Hi Alex, i did another test and collected all the logs, GC logs, Heap mem dump, fiew screenshots. All files are in zip file. File is to big for upload, please download from Jumbo mail link. https://jumboiskon.tportal.hr/download/eeab9848-2494-4ab7-a2cb-88766db0fafa Thanks, Dren -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Ignite 2.8.0. Heap mem issue
Hi Evgeny,
I can share pseudo code, not all developed code and python modules.
Syslog messages are inseted into cache via Flume.
Python daemons process messages ( read from CACHE ) and make
insert/update/delete in fiew Ignite tables via SQL.
Number of syslog messages and python code is same on prod and test.
##
# scan CACHE, fetch k/v from CACHE, SQL insert/update/delete ...
while True:
try:
ig_connection = new_ignite_connection(config_params,
logger)
stream_cache = ig_connection.get_cache("XY_CACHE_NAME")
# cache is
created by code with get_or_create_cache
CACHE_SIZE = stream_cache.get_size()
if CACHE_SIZE > 0:
# returns a generator, that yields two-tuples
of key and value
cache_list = stream_cache.scan()
for k, v in cache_list:
# parse k, v and make some
INSERT/UPDATE in TABLES
# TABLE ALERTS ~ 50 colums
SQL_EVENT_INSERT_QUERY =
"INSERT INTO ALERTS (%s) VALUES (%s)" %
(alerts_insert_column_names(), alerts_insert_parameters() )
ig_connection.sql(SQL_EVENT_INSERT_QUERY, query_args =
var_EVENT_INSERT_QUERY)
# remove
stream_cache.remove_key(k)
ig_connection.close()
time.sleep(POLL_INTERVAL)
except (OSError, SocketError) as e:
logger.error('ERROR in client connection: %s , client
status: %s ' %(e,
ig_connection))
##
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Failed to bind to any [host:port] from the range portFrom=10900 , portTo=11000
Hi ,I have setup a Ignite cluster in google cloud following document :
https://apacheignite.readme.io/docs/google-cloud-deployment. My Ignite
client code which connects to 10800 works fine . ie//THIS WORKS
!!ClientConfiguration ccfg = new
ClientConfiguration().setAddresses("xx.xx.xx.xx:10800");IgniteClient
igniteClient = Ignition.startClient(ccfg);ClientCache
clientcache =
igniteClient.getOrCreateCache(CACHE_NAME);clientcache.put(key,address);clientcache.get(key)But
when i tried to connect as a client node , it doesn't work at all ! Can
someone tell me what could be the reason ?//tried 10800 and
10900ClientConnectorConfiguration cfg=new ClientConnectorConfiguration()
.setHost("xx.xx.xx.xx")
.setPort(10900);IgniteConfiguration ignitecfg =
new IgniteConfiguration();
ignitecfg.setClientConnectorConfiguration(cfg);IgniteDataStreamer
dataSteamer=ignite.dataStreamer("put-get-example");Address val = new
Address("sample address", 94612);Integer key = 1;
dataSteamer.addData(key, val);fails to run with below exception
org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter [] at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1981)
~[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1213)
~[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.Ignition.start(Ignition.java:321)
[ignite-core-2.8.0.jar:2.8.0] at
com.mainad.userlistignitesetup.UserListIgniteSetupApplication.main(UserListIgniteSetupApplication.java:50)
[classes/:na]Caused by: org.apache.ignite.IgniteCheckedException: Failed to
start client connector processor. at
org.apache.ignite.internal.processors.odbc.ClientListenerProcessor.start(ClientListenerProcessor.java:209)
~[ignite-core-2.8.0.jar:2.8.0] at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1978)
~[ignite-core-2.8.0.jar:2.8.0] ... 8 common frames omittedCaused by:
org.apache.ignite.IgniteCheckedException: Failed to bind to any [host:port]
from the range [host=xx.xx.xx.xx, portFrom=10900, portTo=11000,
lastErr=class org.apache.ignite.IgniteCheckedException: Failed to initialize
NIO selector.] at
org.apache.ignite.internal.processors.odbc.ClientListenerProcessor.start(ClientListenerProcessor.java:197)
~[ignite-core-2.8.0.jar:2.8.0] ... 9 common frames omitted
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: HOW TO CHANGE IGNITE JAVA THIN CLIENT PASSWORD
igniteClient.query(new SqlFieldsQuery(" ALTER USER 'ignite' WITH PASSWORD
'password' "));
igniteClient.query(new SqlFieldsQuery(" ALTER USER "ignite'' WITH PASSWORD
'password' "));
1) Both give the same result. i.e query runs without throwing any
error/exception.
2) Unable to connect with the new password.
3) Again tried with 'ignite' as password, it connects back.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Data Isolation during Ignite Cache load
Hi , Filter in the sense, SQL Fields Query with where clause is executed. I hope the following example helps you understand my query. *Scenario:* For example there is a cache named Products which has 1 million records with two distinct product categories(i.e. Furniture,Electronics) among these 1 million records. Now once the Data load is started , if i execute a sql fields query like below, will i get the count as 1 million or only the count of records that are loaded so far. select count(1) from Products where category='Electronics' -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
