Re: Inserting data into Ignite thread is hung
Hi,
I don't think there is a network issue, since at that moment other clients
are able to access the data from the Ignite cluster. But some times the
inserting thread is hung for 15 mins, after that it has proceeded further.
If the thread is hung which is inserting, we are canceling the thread
explicitly by the below code.
That's why you can see IgniteInterruptedException in the logs.
But why the thread is becoming hung while inserting the data[ max 10
records].
if(futureReturn.size() > 0){
for(Future future :
futureReturn){
try{
Boolean result =
future.get(20, TimeUnit.MINUTES);
if(!result){
dataSyncSucces
= false;
break;
}
}catch(Exception e){
future.cancel(true);
dataSyncSucces = false;
}
}
}
Even the same issue i observed in local services also but at different piece
of code.
Thanks,
Praveen
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Conflict resolution during rebalancing
Hello! At this point you will have two clusters and they will not join back. It is expected that your server nodes are "near" network-wise and if split still occurs, it's up to you to shut down incorrect (smaller) cluster. Only a single node can join the cluster on cluster's terms. This means you will either join S2 to S1 and throw away everything on S2, or join S1 to S2 and throw away everything on S1. Regards, -- Ilya Kasnacheev пн, 22 окт. 2018 г. в 18:50, Ariel Tubaltsev : > I guess my question is rather about networking partition. > Let's say you have 2 servers S1, S2 and 2 clients C1, C2 > Let's say network is partitioned [C1,S1] , [C2,S2]. > We allow topology of a single node, so both servers stay functional. > Let's say C1 writes and C2 writes . > What will happen when the network is fixed and S1 and S2 join back? Will > the > value be V, V2 or something else? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
RE: Cannot query cache by affinity key when custom cache template is used
Also crossposting from SO :)
https://stackoverflow.com/questions/52879064/cannot-query-cache-by-affinity-key-when-custom-cache-template-is-used/52935802#52935802
Apparently, it's a bug in Ignite. Filed
https://issues.apache.org/jira/browse/IGNITE-9964. Thanks for reporting!
The issue only appears when you put data via withKeepBinary(). If you use SQL
INSERT instead, SELECT works fine.
I suggest you use INSERT instead of constructing BinaryObjects manually - it's
much easier and allows to workaround the bug. If you have to use BinaryObjects
then you can try added the first row via INSERT and use binary afterwards -
this also worked in my tests.
Stan
From: adam
Sent: 18 октября 2018 г. 21:39
To: user@ignite.apache.org
Subject: Cannot query cache by affinity key when custom cache template is used
I am crossposting this from StackOverflow.
I noticed that when I query a cache which was created with a custom cache
template and include the cache's affinity key in the WHERE clause, no
results are returned.
I am running Ignite 2.5 with the following configuration:
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;>
And here is my test code. The code creates 3 caches. The first one is a
"root" cache which defines colocation for the others. The other two are
caches colocated by the root's key. The first colocated cache
(colocated_default) uses the PARTITIONED template and works as expected. The
second (colocated_custom) uses the "myCacheTemplate" created in the above
configuration. I insert one cache entry into each cache, where the entries
in the colocated cache have an affinity key equal to the root cache entry's
key.
I then query the caches. I first run a query to ensure there is one entry in
each cache. Then I run a query where the affinity key is equal to value
inserted. The results for me show that I am able to select from by affinity
from both of the PARTITIONED caches, but get no results for the
"colocated_custom" cache. Here is the code:
/**
* Test which shows that creating a cache with a custom cache
configuration template doesn't allow
* for SQL queries to use an affinity key in the WHERE clause.
*/
public class App {
public static void main(String[] args) {
// Start Ignite.
Ignition.setClientMode(true);
final Ignite ignite = Ignition.start(new IgniteConfiguration());
// Create caches. Create a root entity, and two entities which are
colocated by the root's ID.
// One uses the custom cache template and one just uses the
PARTITIONED template.
final List createTableStringBuilders = new
ArrayList<>();
final StringBuilder createRoot = new StringBuilder();
createRoot.append("CREATE TABLE IF NOT EXISTS root (\n");
createRoot.append(" \"key\" VARCHAR(24) NOT NULL,\n");
createRoot.append(" \"data\" VARCHAR(100),\n");
createRoot.append(" PRIMARY KEY(\"key\"))\n");
createRoot.append(
"WITH \"template=PARTITIONED, affinity_key=key,
cache_name=root, value_type=root\";");
createTableStringBuilders.add(createRoot);
final StringBuilder createColocatedDefault = new StringBuilder();
createColocatedDefault.append("CREATE TABLE IF NOT EXISTS
colocated_default (\n");
createColocatedDefault.append(" \"root_key\" VARCHAR(24) NOT
NULL,\n");
createColocatedDefault.append(" \"key\" VARCHAR(24) NOT
NULL,\n");
createColocatedDefault.append(" \"data\" VARCHAR(100),\n");
createColocatedDefault.append(" PRIMARY KEY(\"root_key\",
\"key\"))\n");
createColocatedDefault.append(
"WITH \"template=PARTITIONED, affinity_key=root_key,
cache_name=colocated_default, key_type=colocated_default_key,
value_type=colocated_default\";");
createTableStringBuilders.add(createColocatedDefault);
final StringBuilder createColocatedCustom = new StringBuilder();
createColocatedCustom.append("CREATE TABLE IF NOT EXISTS
colocated_custom (\n");
createColocatedCustom.append(" \"root_key\" VARCHAR(24) NOT
NULL,\n");
createColocatedCustom.append(" \"key\" VARCHAR(24) NOT NULL,\n");
createColocatedCustom.append(" \"data\" VARCHAR(100),\n");
createColocatedCustom.append(" PRIMARY KEY(\"root_key\",
\"key\"))\n");
createColocatedCustom.append(
"WITH \"template=myCacheTemplate, affinity_key=root_key,
cache_name=colocated_custom, key_type=colocated_custom_key,
value_type=colocated_custom\";");
createTableStringBuilders.add(createColocatedCustom);
Re: Conflict resolution during rebalancing
I guess my question is rather about networking partition. Let's say you have 2 servers S1, S2 and 2 clients C1, C2 Let's say network is partitioned [C1,S1] , [C2,S2]. We allow topology of a single node, so both servers stay functional. Let's say C1 writes and C2 writes . What will happen when the network is fixed and S1 and S2 join back? Will the value be V, V2 or something else? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Keycloak integration with Ignite
Hi, As far as I know, Ignite doesn't support all operations that needed for initial schema creation for Keycloak as now, because there is a lot of operations with table changing. However, you can try to rewrite these SQL scripts or create this schema in other DBs and then dump schema from 3rd party DB and apply it to Ignite. Evgenii пн, 22 окт. 2018 г. в 12:04, Venkata Bhagavatula : > Hi, > > Does apache ignite support for Keycloak integration? where can i find > steps for the same? > > Thanks n Regards > chalapathi. >
Re: Query execution too long even after providing index
Well, looks like you trying to find the segments that intersects defined segment, but you're complicating it. You don't need 3 conditions here - it will be enough to have only one - ipStart <= MAX and ipEnd >= MIN. I've checked it for your case and got absolutely the same results as you have with a too complex query. Aditionally, you have the same subscriptionId AND moduleId in your test data, which means that you will have a bad selectivity when you will filter by these fields at first. Do you really have such data in your production? Also, when you will measure something again - do operation a lot of times - that how benchmarks work. Ignite initialize internal structures at first executions, so, it will not give an idea of overall latency if you will measure it just once. Best Regards, Evgenii пн, 22 окт. 2018 г. в 6:56, Prasad Bhalerao : > Hi Evgenii, > > Did you get time to check the reproducer? > > Can you please suggest solution for this? > > > Thanks, > Prasad > > > On Fri, Oct 19, 2018, 4:46 PM Prasad Bhalerao < > prasadbhalerao1...@gmail.com> wrote: > >> Hi Evgenii, >> >> I have created a reproducer and uploaded it to GitHub. I have created 5 >> cases to test the sql execution time. >> >> GitHub project: https://github.com/prasadbhalerao1983/IgniteTestPrj.git >> >> Please run IgniteQueryTester class. >> >> Thanks, >> Prasad >> >> On Wed, Oct 17, 2018 at 7:46 PM ezhuravlev >> wrote: >> >>> How much data do you have? What is the amount of heap and offheap >>> memory? >>> Can you share the reproducer with the community? >>> >>> Evgenii >>> >>> >>> >>> -- >>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >>> >>
Re: Inserting data into Ignite thread is hung
Hello! This might be due genuine network problems between two nodes, or maybe it is something like https://issues.apache.org/jira/browse/IGNITE-8153 - a very rare SSL bug which will only manifest under specific conditions. Regards, -- Ilya Kasnacheev пн, 22 окт. 2018 г. в 13:53, praveeng : > Hi , > > I have forgot to specify the below points. > > 1. This issue is happening every time at the same place of code for the > same > cache. > 2. The cache to which we are inserting is not at all used by any other > service [ cache instance is created in other services but we will not be > making any call to this cache. At present we are just inserting the data > into the cache by client1 and other clients just creating the cache > instance > to this cache but not making any call.] > > > Thanks, > Praveen > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Inserting data into Ignite thread is hung
Hi , I have forgot to specify the below points. 1. This issue is happening every time at the same place of code for the same cache. 2. The cache to which we are inserting is not at all used by any other service [ cache instance is created in other services but we will not be making any call to this cache. At present we are just inserting the data into the cache by client1 and other clients just creating the cache instance to this cache but not making any call.] Thanks, Praveen -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Inserting data into Ignite thread is hung
Hi , Version: 1.8 Java: 1.7.0_45-b18 [ we can't upgrade the java version to 1.8 due to some internal restriction.] We are facing that the ignite thread is hung when we are trying to insert the data. This is not happening that much frequently. We don't see any exceptions in ignite except below that too the below exception has come only on one server. Can you please check and suggest us. *Exception in ignite server:* [02:15:14,320][WARN ][grid-nio-worker-1-#10%CasinoApacheIgniteServices%][TcpCommunicationSpi] Failed to process selector key (will close): GridSelectorNioSessionImpl [selectorIdx=1, queueSize=0, writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], recovery=GridNioRecoveryDescriptor [acked=2060041, resendCnt=0, rcvCnt=2060037, sentCnt=2060041, reserved=true, lastAck=2060032, nodeLeft=false, node=TcpDiscoveryNode [id=62c088cc-f6a8-49b2-8eee-911f147d99b2, addrs=[10.166.161.111, 127.0.0.1], sockAddrs=[/127.0.0.1:0, gi2p1xrcds001.gi02.bpty/10.166.161.111:0], discPort=0, order=109, intOrder=61, lastExchangeTime=1539342673260, loc=false, ver=1.8.0#20161205-sha1:9ca40dbe, isClient=true], connected=true, connectCnt=0, queueLimit=10, reserveCnt=68], super=GridNioSessionImpl [locAddr=/10.166.186.158:9090, rmtAddr=/10.166.161.111:45006, createTime=1539921738152, closeTime=0, bytesSent=6593820, bytesRcvd=20615839, sndSchedTime=1539929665103, lastSndTime=1539921785427, lastRcvTime=1539929665103, readsPaused=false, filterChain=FilterChain[filters=[GridNioCodecFilter [parser=o.a.i.i.util.nio.GridDirectParser@40e27086, directMode=true], GridConnectionBytesVerifyFilter, SSL filter], accepted=true]] [02:15:14,320][WARN ][grid-nio-worker-1-#10%CasinoApacheIgniteServices%][TcpCommunicationSpi] Closing NIO session because of unhandled exception [cls=class o.a.i.i.util.nio.GridNioException, msg=Connection timed out] When we timed out the hung thread, we can see the below stack trace in client service. 02:08:40,697 - ERROR - pool-45-thread-1 - CASINO_DATASYNC_LOGGER Exception in Syncing the Data for LMTEMPLATECONFIG javax.cache.CacheException: class org.apache.ignite.IgniteInterruptedException: null at org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1440) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2183) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putAll(IgniteCacheProxy.java:1430) at com.pg.casino.service.datasync.DataSyncManager.syncDataIntoIgnite(DataSyncManager.java:835) at com.pg.casino.service.datasync.LMDataSyncManager.syncGenericLobbyTemplateConfig(LMDataSyncManager.java:327) at com.pg.casino.service.datasync.DataSyncCallable.call(DataSyncCallable.java:118) at com.pg.casino.service.datasync.DataSyncCallable.call(DataSyncCallable.java:22) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: class org.apache.ignite.IgniteInterruptedException: null at org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:766) at org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:764) ... 11 more Caused by: java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:996) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:160) at org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAll(GridDhtAtomicCache.java:704) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putAll(IgniteCacheProxy.java:1423) *cache info in Ignite xml :* * Ignite 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;>
Keycloak integration with Ignite
Hi, Does apache ignite support for Keycloak integration? where can i find steps for the same? Thanks n Regards chalapathi.
Re: Conflict resolution during rebalancing
Hello! As far as my understanding goes, there should be no conflicts after rebalance is finished, nor during normal cluster operation. Regards, -- Ilya Kasnacheev пт, 19 окт. 2018 г. в 20:52, Ariel Tubaltsev : > I'm looking for pointers on how conflicts in key/values are resolved during > rebalancing. > Theoretically, if I have a cluster of 2 nodes, > CacheWriteSynchronizationMode > - FULL_SYNC, CacheRebalanceMode - SYNC. > > Let's say nodes are partitioned in the network and valid topology is 1 > node, > so they continue to update values from clients and may have different > content. > > After nodes reconnect and rebalance, how conflicts in keys/values are > resolved? > > Thank you > Ariel > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: close method must be called on IgniteCache?
Hello! My guess is that it will occupy some memory structures on client, but it should not decrease performance. You will probably lose more performance by trying to stop/start the cache on client on demand. Regards, -- Ilya Kasnacheev сб, 20 окт. 2018 г. в 4:55, kcheng.mvp : > thank your reply very much! > > I suppose this method `close` is intended for resource release. > > by the way, keep the `cache` there would occupy system resource/decrease > system performance? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: npe: Failed to reinitialize local partition
Hello! I'm not very familiar with the area of Persistence FS layout, but I imagine this might be caused by the bug we are discussing. Regards, -- Ilya Kasnacheev пт, 19 окт. 2018 г. в 18:00, wangsan : > Thanks! > The ticket description is especially like my scene. I will apply the patch! > > I have a little confused about the persistence file. > If I have a default region without persistence. and cache2a use default > region. the db file(directory) won't be created. > > But if I have > > region1 (with persistence) > region2 (without persistence) > > cache1a from region1 > cache2a fom region2 > > cache2a use region2 without persistence.Why cache2a still have db > file(directory) in file system? > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Cluster freeze with SSL enabled and JDK 11
Hello! I would suggest regular (or DEBUG) Ignite logs + SSL debug logs. https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html Regards, -- Ilya Kasnacheev пт, 19 окт. 2018 г. в 20:58, Loredana Radulescu Ivanoff : > Definitely - do you want debug logs, and if yes, should I enable them on > all Ignite packages, or just for certain ones? Any other diagnostic flags > that I should set? > > On Fri, Oct 19, 2018 at 7:48 AM Ilya Kasnacheev > wrote: > >> Hello! >> >> Apache Ignite does not claim support JDK 11 at this moment. However, I >> was able to run SSL test (TcpDiscoverySslTrustedUntrustedTest) and it >> turned out mostly fine. >> >> More info is needed from your side, such as full instances logs. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> пт, 19 окт. 2018 г. в 0:56, Loredana Radulescu Ivanoff < >> lradu...@tibco.com>: >> >>> Hello, >>> >>> I can consistently reproduce this issue with Ignite 2.6.0, JDK 11 and >>> SSL enabled: >>> >>> >>>- the second node that I bring up joins, and then shortly after >>>freezes and prints this message every minute: >>> >>> "WARN ...[*Initialization*] >>> processors.cache.GridCachePartitionExchangeManager: Still waiting for >>> initial partition map exchange" >>> >>> >>>- once the second node joins, the first node starts experiencing >>>very frequent 100% CPU spikes; these are the messages I see: >>> >>> WARN 2018-10-18T13:50:52,728-0700 [] >>> communication.tcp.TcpCommunicationSpi: Communication SPI session write >>> timed out (consider increasing 'socketWriteTimeout' configuration property) >>> [remoteAddr=/10.100.36.82:51620, writeTimeout=15000] >>> WARN 2018-10-18T13:50:52,737-0700 [] >>> communication.tcp.TcpCommunicationSpi: Failed to shutdown SSL session >>> gracefully (will force close) [ex=javax.net.ssl.SSLException: Incorrect SSL >>> engine status after closeOutbound call [status=OK, >>> handshakeStatus=NEED_WRAP, >>> WARN 2018-10-18T13:51:01,441-0700 [] >>> dht.preloader.GridDhtPartitionsExchangeFuture: Unable to await partitions >>> release latch within timeout: ServerLatch [permits=1, >>> pendingAcks=[aeba8bb7-c9b8-4d46-be8a-df361eaa8fc5], super=CompletableLatch >>> [id=exchange, topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0]]] >>> >>> Other observations: >>> >>> I can reproduce this every time I start the nodes, and it doesn't matter >>> which node comes up first. >>> >>> >>> The issue goes away if I disable SSL. >>> >>> >>> Increasing the socketWriteTimeout, networkTimeout or the >>> failureDetectionTimeout does not help. >>> >>> It seems to be happening only with JDK 11, and not with JDK 8. >>> >>> >>> Do you have any suggestions/known issues about this? >>> >>> Thank you, >>> >>> Loredana >>> >>> >>> >>> >>>
Re: IO implications of ScanQuery
Hello! I would assume the answer is no, but you can also store some named fields with regular binary writer and then store the rest with raw binary writer. This way you should be able to index/query the former. Can you try both approaches, see what works for you? Regards. -- Ilya Kasnacheev чт, 18 окт. 2018 г. в 23:12, Raymond Wilson : > Hi Ilya, > > > > Thanks for the clarification. I assume this not the case if the cache is > represented as an SQL table as the SQL table will construct a primary key > from the entire key of the ICache cache. > > > > Shifting the question a little, if the keys are serialized via a raw > IBinarizable interface implemented on the key types (so the field names are > not included in the serialization) do SQL queries still allow predicate > functions that refer to those fields in the key? My assumption is ‘yes’ > . > > > > Thanks, > > Raymond. > > > > *From:* Ilya Kasnacheev > *Sent:* Thursday, October 18, 2018 11:06 PM > *To:* user@ignite.apache.org > *Subject:* Re: IO implications of ScanQuery > > > > Hello! > > > > As far as my understanding goes, Keys are stored alongside Values in > Durable Memory pages, and they are likely both pulled from pages on scan > query. > > > > This means the latter explanation is closer to reality. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 17 окт. 2018 г. в 23:05, Raymond Wilson : > > I have a potential work flow where I may need to find a set of elements in > a cache where the values are not be small (1-100Kb say), and where the > numbers of elements in the cache may be large (many millions). > > > > Each key contains fields the scan query could use to select the entries I > want. > > > > Will the scan query only read keys from the store while it is determining > which items in the cache match the query, and then pull the matching values > to return back to the scan query client? Or does scan query read all > key/value data then apply its conditions before returning the matching > items? > > > > Thanks, > > Raymond. > > > >
