from:"Andrei Aleksandrov"


Denis,

I can check it out soon. The mentioned problem can probably only be 
related to JDBC data frames. In this case, I will create a JIRA ticket. 
But as I know using OPTION_CREATE_TABLE_PRIMARY_KEY_FIELDS should be the 
same as I showed in my example.


BR,
Andrei

10/30/2020 6:01 PM, Denis Magda пишет:

Andrey,

Do we need to update our docs? It feels like the docs miss these 
details or have an outdated example.


-
Denis


On Fri, Oct 30, 2020 at 7:03 AM Andrei Aleksandrov 
mailto:aealexsand...@gmail.com>> wrote:


Hi,

Here's an example with correct syntax that should work fine:

|DataFrameWriter < Row > df = resultDF .write()
.format(IgniteDataFrameSettings.FORMAT_IGNITE())
.option(IgniteDataFrameSettings.OPTION_CONFIG_FILE(), configPath)
.option(IgniteDataFrameSettings.OPTION_TABLE(), "Person")
.option(IgniteDataFrameSettings.OPTION_CREATE_TABLE_PRIMARY_KEY_FIELDS(),
"id, city_id")
.option(IgniteDataFrameSettings.OPTION_CREATE_TABLE_PARAMETERS(),
"template=partitioned,backups=1") .mode(Append); |

Please let me know if something is wrong here.

BR,
Andrei

10/30/2020 2:20 AM, Humphrey пишет:

Hello guys this question has been asked on  Stack Overflow
<https://stackoverflow.com/questions/64554684/how-to-create-a-table-with-primary-key-using-jdbc-spark-connector-to-ignite>  <https://stackoverflow.com/questions/64554684/how-to-create-a-table-with-primary-key-using-jdbc-spark-connector-to-ignite>   
but yet no answer is a provided.


I'm facing the same issue (trying to insert data in ignite using
spark.jdbc):
Exception in thread "main" java.sql.SQLException: No PRIMARY KEY defined for
CREATE TABLE
at

org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1004)

Code:
 println("-- writing using jdbc --")
 val prop = Properties()
 prop["driver"] = "org.apache.ignite.IgniteJdbcThinDriver"

 df.write().apply {
 mode(SaveMode.Overwrite)
 format("jdbc")
 option("url", "jdbc:ignite:thin://127.0.0.1  
<http://127.0.0.1>")
 option("dbtable", "comments")

option(IgniteDataFrameSettings.OPTION_CREATE_TABLE_PRIMARY_KEY_FIELDS(),

"last_name")
 }.save()

The last option doesn't seem to work/help.



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

Re: Ignite Cluster Issue on 2.7.6


Hi,

Did you remove the code with ignite.cluster().active(*true*); ?

However, yes, all of your data nodes should be in baseline topology. 
Could you collect logs from your servers?


BR,
Andrei

10/30/2020 2:28 PM, Gurmehar Kalra пишет:


Hi,

I tried changes suggested by you , waited for nodes  and then tried to 
start cluster , but only 1 node is  joins cluster other node  does not 
participates in cluster.


Do I have to add all nodes into BLT ?

Regards,

Gurmehar Singh

*From:*Andrei Aleksandrov 
*Sent:* 29 October 2020 20:11
*To:* user@ignite.apache.org
*Subject:* Re: Ignite Cluster Issue on 2.7.6

[CAUTION: This Email is from outside the Organization. Unless you 
trust the sender, Don’t click links or open attachments as it may be a 
Phishing email, which can steal your Information and compromise your 
Computer.]


Hi,

Do you use cluster with persistence? After first actication all your 
data will be located on the first activated node.


In this case, you also should track your baseline.

https://www.gridgain.com/docs/latest/developers-guide/baseline-topology 
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gridgain.com%2Fdocs%2Flatest%2Fdevelopers-guide%2Fbaseline-topology=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cb6b965fa945e4a7f9b2608d87c189df1%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637395793215914323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=vlUsoU0O2U8cW1aqojX29MmnxvhnVfL%2B4AbVGem5wIs%3D=0>


Baseline topology is a subset of nodes where you cache data located.

The recommendations are the following:

1)you should activate the cluster only when all server nodes were started
2)If the topology changes, you must either restore the failed nodes or 
reset to the base topology to trigger partition reassignment and 
rebalancing.
3)If some new node should contain the cache data then you should add 
this node to baseline topology:


using java code:

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCluster.html#setBaselineTopology-java.util.Collection 
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Freleases%2Flatest%2Fjavadoc%2Forg%2Fapache%2Fignite%2FIgniteCluster.html%23setBaselineTopology-java.util.Collection=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cb6b965fa945e4a7f9b2608d87c189df1%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637395793215914323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=i470Z%2FOz7uOPcm8dgQXSJYNhrlUXfcv6fTn%2BQlnfeVk%3D=0>-


using utility tool:

https://www.gridgain.com/docs/latest/administrators-guide/control-script#adding-nodes-to-baseline-topology 
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gridgain.com%2Fdocs%2Flatest%2Fadministrators-guide%2Fcontrol-script%23adding-nodes-to-baseline-topology=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cb6b965fa945e4a7f9b2608d87c189df1%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637395793215924318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=Z2SLId9kSjQhXA0SWmMMu5uEq3OHT1YX5v30OM5ckTM%3D=0>


4)In case if some node from baseline can't be started (e.g because its 
data on the disk was destroyed) it should be removed from baseline:


https://www.gridgain.com/docs/latest/administrators-guide/control-script#removing-nodes-from-baseline-topology 
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gridgain.com%2Fdocs%2Flatest%2Fadministrators-guide%2Fcontrol-script%23removing-nodes-from-baseline-topology=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cb6b965fa945e4a7f9b2608d87c189df1%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637395793215924318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=EiZeVORdR03LAr%2BUworeIBxeP3%2F3LfosUg5izvFylu0%3D=0>


If you are not using persistence, please provide additional 
information that "data is being added to the cache but not available 
to any of the modules." means:


1) How you access data
2) What do you see in the logs

BR,
Andrei

10/29/2020 4:19 PM, Gurmehar Kalra пишет:

Hi,

I have two module(Web and Engine)  and want to share data b/w the
modules , but when I run  web and engine together , data is added
to cache  but is not available to either of modules.
below is my ignite config, which is same in both modules

config.setActiveOnStart(*true*);

config.setAutoActivationEnabled(*true*);


config.setIgniteHome(propertyReader.getProperty("spring.ignite.storage.path"));

config.setFailureHandler(*new*StopNodeOrHaltFailureHandler());

config.setDataStorageConfiguration(getDataStorageConfiguration());


config.setGridLogger(*new*JavaLogger(java.util.logging.Logger./getLogger/(*/LOG/*.getClass().getCanonicalName(;

Ignite ignite= Ignition./start/(config);

ignite.cluster().active

Re: IgniteSpiOperationTimeoutException: Operation timed out [timeoutStrategy= ExponentialBackoffTimeoutStrategy

Hi,

Often, problems with establishing a communication connection can be
solved with the following configuration:

1)You may have multiple network interfaces and the wrong one could be
used. Solved by changing the SPI communication timeouts.:

class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">

...
...

Otherwise, you can wait more than 10 minutes when trying to create a
connection (due to the ExponentialBackoffTimeoutStrategy strategy).

2)Some operations in the cluster require communication with clients
through communication. In case you have communication problems, but you
can still access through the discovery SPI, such operations may hang. To
avoid it please set the following property:

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_ENABLE_FORCIBLE_NODE_KILL

If these recommendations do not help, then yes, as Ilya said, we require
a loudspeaker on your part.

BR,
Andrei

10/30/2020 2:20 PM, Ilya Kasnacheev пишет:

Hello!

Do you have a reproducer for this behaviour that I could run and see
it failing?

Regards,
--
Ilya Kasnacheev

вт, 27 окт. 2020 г. в 22:02, VeenaMithare >:

Hi Ilya, The node communication issue is because one of the node
is being restarted - and not due to network failure . The original
issue is as below : Our setup : Servers - 3 node cluster Reader
clients : wait for an update on an entry of a cache ( around 20 of
them ) Writer Client : 1 If one of the reader client restarts
while the writer is writing into the entry of the cache , the
server attempts to send the update to the failed client's local
listener . It keeps attempting to communicate with the failed
client ( client's continous query local listener ? ) till it
timesout as per
connTimeoutStrategy=ExponentialBackoffTimeoutStrategy . ( Please
find the snippet of the exception below. The complete log is
attached as an attachment ) This delays the completion of the
transaction that was started by the writer client. Is there any
way the writer client could complete the transaction without
getting impacted by the reader client restarts ? regards, Veena.

Sent from the Apache Ignite Users mailing list archive
at Nabble.com.

Re: Ignite instances frequently failing - BUG: soft lockup - CPU#1 stuck


Hello,

Too little information has been provided on your part:

1) Could you provide the screenshot from the web console at this time?
2) Could you collect Ignite logs during this period?
3) What tool shows that the processors are frozen? Have you checked 
other tools?


BR,
Andrew

10/30/2020 3:07 PM, bbellrose пишет:

Ignite instances keep failing. Server indicates CPU stuck. However monitoring
shows very little CPU usage. This happens almost every day on different
nodes of the cluster.





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

Re: Inserting date into ignite with spark jdbc


Hi,

Here's an example with correct syntax that should work fine:

|DataFrameWriter < Row > df = resultDF .write() 
.format(IgniteDataFrameSettings.FORMAT_IGNITE()) 
.option(IgniteDataFrameSettings.OPTION_CONFIG_FILE(), configPath) 
.option(IgniteDataFrameSettings.OPTION_TABLE(), "Person") 
.option(IgniteDataFrameSettings.OPTION_CREATE_TABLE_PRIMARY_KEY_FIELDS(), 
"id, city_id") 
.option(IgniteDataFrameSettings.OPTION_CREATE_TABLE_PARAMETERS(), 
"template=partitioned,backups=1") .mode(Append); |


Please let me know if something is wrong here.

BR,
Andrei

10/30/2020 2:20 AM, Humphrey пишет:

Hello guys this question has been asked on  Stack Overflow

but yet no answer is a provided.

I'm facing the same issue (trying to insert data in ignite using
spark.jdbc):
Exception in thread "main" java.sql.SQLException: No PRIMARY KEY defined for
CREATE TABLE
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1004)

Code:
 println("-- writing using jdbc --")
 val prop = Properties()
 prop["driver"] = "org.apache.ignite.IgniteJdbcThinDriver"

 df.write().apply {
 mode(SaveMode.Overwrite)
 format("jdbc")
 option("url", "jdbc:ignite:thin://127.0.0.1")
 option("dbtable", "comments")

option(IgniteDataFrameSettings.OPTION_CREATE_TABLE_PRIMARY_KEY_FIELDS(),

"last_name")
 }.save()

The last option doesn't seem to work/help.



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

Re: Ignite Cluster Issue on 2.7.6

2020-10-29 Thread Andrei Aleksandrov


Hi,

Do you use cluster with persistence? After first actication all your 
data will be located on the first activated node.


In this case, you also should track your baseline.

https://www.gridgain.com/docs/latest/developers-guide/baseline-topology

Baseline topology is a subset of nodes where you cache data located.

The recommendations are the following:

1)you should activate the cluster only when all server nodes were started
2)If the topology changes, you must either restore the failed nodes or 
reset to the base topology to trigger partition reassignment and 
rebalancing.
3)If some new node should contain the cache data then you should add 
this node to baseline topology:


using java code:

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCluster.html#setBaselineTopology-java.util.Collection-

using utility tool:

https://www.gridgain.com/docs/latest/administrators-guide/control-script#adding-nodes-to-baseline-topology

4)In case if some node from baseline can't be started (e.g because its 
data on the disk was destroyed) it should be removed from baseline:


https://www.gridgain.com/docs/latest/administrators-guide/control-script#removing-nodes-from-baseline-topology

If you are not using persistence, please provide additional information 
that "data is being added to the cache but not available to any of the 
modules." means:


1) How you access data
2) What do you see in the logs

BR,
Andrei

10/29/2020 4:19 PM, Gurmehar Kalra пишет:


Hi,

I have two module(Web and Engine)  and want to share data b/w the 
modules , but when I run  web and engine together , data is added to 
cache  but is not available to either of modules.

below is my ignite config, which is same in both modules

config.setActiveOnStart(*true*);

config.setAutoActivationEnabled(*true*);

config.setIgniteHome(propertyReader.getProperty("spring.ignite.storage.path"));

config.setFailureHandler(*new*StopNodeOrHaltFailureHandler());

config.setDataStorageConfiguration(getDataStorageConfiguration());

config.setGridLogger(*new*JavaLogger(java.util.logging.Logger./getLogger/(*/LOG/*.getClass().getCanonicalName(;

Ignite ignite= Ignition./start/(config);

ignite.cluster().active(*true*);

All Caches created have below properties |

cache.setWriteSynchronizationMode(CacheWriteSynchronizationMode.*/FULL_ASYNC/*);

cache.setAtomicityMode(CacheAtomicityMode.*/TRANSACTIONAL/*);

cache.setCacheMode(CacheMode.*/REPLICATED/*);

cache.setGroupName("EngineGroup");

Both Modules  are running on  IP List : 
127.0.0.1:47501,127.0.0.1:47502,127.0.0.1:47503,127.0.0.1:47504


Please suggest..

Regards,

Gurmehar Singh

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. E-mail transmission is not 
guaranteed to be secure or error-free as information could be 
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
may contain viruses in transmission. The e mail and its contents (with 
or without referred errors) shall therefore not attach any liability 
on the originator or HCL or its affiliates. Views or opinions, if any, 
presented in this email are solely those of the author and may not 
necessarily reflect the views or opinions of HCL or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of this message 
without the prior written consent of authorized representative of HCL 
is strictly prohibited. If you have received this email in error 
please delete it and notify the sender immediately. Before opening any 
email and/or attachments, please check them for viruses and other defects.

Re: Large Heap with lots of BinaryMetaDataHolders

2020-10-29 Thread Andrei Aleksandrov


Hello,

Let's start from the very beginning.

1) Could you please share the server and client config?
2) Java code of what you have in your client launcher application

I will try to investigate your case.

BR,
Andrew

10/28/2020 7:19 PM, ssansoy пишет:

Hi, could anyone please help understand why the heap of a client app has such
large amounts of data pertaining to binary meta data?

Here it takes up 30mb but in our UAT environment we have approx 50 caches.
The binary meta data that gets added to the client's heap equats to around
220mb (even for a very simple app that doesn't do any subscriptions - it
just calls Igition.start() to connect to the cluster)

It seems meta is kept on the client for every cache even if the client app
needs it or not. Is there any way to tune this at all - e.g. knowing that a
particular client is only interested in a particular cache?

Screenshot:



Thanks



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

Re: High number of Exception Unexpected response ID with setTimeout

2020-09-28 Thread Andrei Aleksandrov


Hi,

It will be great to take a look at full logs that contain these errors.

BR,
Andrei

9/28/2020 12:35 PM, AravindJP пишет:

Thank you stepan for your reply , problem is the parent thread calling ignite
cache get has a timeout of 120 ms , hence we allow a max of 100 ms for every
cache read . We are seeing that during non peak time , 80% of cache read is
< 20 ms only . But during peak load application is crashing with some
threads going beyond 400 to 500 ms . That's the reason why we had to limit
timeout to 50 . But why such an exception occurs ? Why such an exception
occurs from Ignite side ?



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

Re: OutOfMemoryException with Persistence and Eviction Enabled

2020-09-25 Thread Andrei Aleksandrov


Hi,

It looks like that I found the issue:

https://issues.apache.org/jira/browse/IGNITE-8917

When you use *put *or *removeAll *in persistence cache with more data 
than data region size throw IgniteOutOfMemoryException. Data streamer 
looks like don't affected by this ticket.


The WA is pretty simple - use bigger data region.

BR,
Andrei

9/24/2020 11:44 PM, Mitchell Rathbun (BLOOMBERG/ 731 LEX) пишет:
I tried doubling it from 200 MB to 400 MB. My initial test worked, but 
as I increased the number of fields that I was writing per entry, the 
same issue occurred again. So it seems to just increase the capacity 
of what can be written, not actually prevent the exception from 
occurring. I guess my main question is why is it possible for Ignite 
to get an OOME when persistence and eviction are enabled? It seems 
like if there are a lot of writes, performance should degrade as the 
in memory cache evicts members of the cache, but no exceptions should 
occur. The error is always "Failed to find a page for eviction", which 
doesn't really make sense when eviction is enabled. What are the 
internal structures that Ignite holds in Off-heap memory?
Also, why isn't this an issue when using IgniteDataStreamer if the 
issue has to do with space for internal structures? Wouldn't Ignite 
need the same internal structures for either case?

From: user@ignite.apache.org At: 09/24/20 11:42:21
To: user@ignite.apache.org  Subject: 
Re: OutOfMemoryException with Persistence and Eviction Enabled


Hi, Did you try to increase the DataRegion size a little bit? It
looks like 190 MB isn't enough for some internal structures that
Ignite stores in OFF-HEAP except the data. I suggest you increase
the data region size to for example 512 MB - 1024 MB and take a
look at how it will work. If you still will see the issue then I
guess we should create the ticket: 1)Collect the logs 2)Provide
the java code example 3)Provide the configuration of the nodes
After that, we can take a look more deeply into it and if it's an
issue then file JIRA. BR, Andrei

9/23/2020 7:36 PM, Mitchell Rathbun (BLOOMBERG/ 731 LEX) пишет:

Here is the exception:
Sep 22, 2020 7:58:22 PM java.util.logging.LogManager$RootLogger log
SEVERE: Critical system error detected. Will be handled
accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler
[ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class
o.a.i.i.mem.IgniteOutOfMemoryException: Out of memory in data
region [name=customformulacalcrts, initSize=190.7 MiB,
maxSize=190.7 MiB, persistenceEnabled=true] Try the following:
^-- Increase maximum off-heap memory size
(DataRegionConfiguration.maxSize)
^-- Enable Ignite persistence
(DataRegionConfiguration.persistenceEnabled)
^-- Enable eviction or expiration policies]]
class org.apache.ignite.internal.mem.IgniteOutOfMemoryException:
Out of memory in data region [name=customformulacalcrts,
initSize=190.7 MiB, maxSize=190.7 MiB, persistenceEnabled=true]
Try the following:
^-- Increase maximum off-heap memory size
(DataRegionConfiguration.maxSize)
^-- Enable Ignite persistence
(DataRegionConfiguration.persistenceEnabled)
^-- Enable eviction or expiration policies
at

org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:607)
at

org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.allocateDataPage(AbstractFreeList.java:464)
at

org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:491)
at

org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.insertDataRow(CacheFreeListImpl.java:59)
at

org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.insertDataRow(CacheFreeListImpl.java:35)
at

org.apache.ignite.internal.processors.cache.persistence.RowStore.addRow(RowStore.java:103)
at

org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.createRow(IgniteCacheOffheapManagerImpl.java:1691)
at

org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.createRow(GridCacheOffheapManager.java:1910)
at

org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:5701)
at

org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:5643)
at

org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3719)
at

Re: IgniteCache.size() is hanging

2020-09-24 Thread Andrei Aleksandrov


Hi,

Highly likely some of the nodes go offline and try to connect again. 
Probably you had some network issues. I think I will see this and other 
information in the logs. Can you provide them?


BR,
Andrei

9/24/2020 6:54 PM, Alan Ward пишет:
The only log I see is from one of the server nodes, which is spewing 
at a very high rate:


[grid-nio-worker-tcp-comm-...][TcpCommunicationSpi] Accepted incoming 
communication connection [locAddr=/:47100, rmtAddr=:


Note that each time the log is printed, i see a different value for 
.


Also note  that I only see these logs when i try to run 
ignitevisorcmd's "cache" command. When I run the java application that 
calls IgniteCache.size(), I don't see any such logs. But in both 
cases, the result is that the operation is just hanging.


The cluster is active and I am able to insert data (albeit at a pretty 
slow rate), so it's not like things are completely non-functional. 
It's really confusing :\


On Thu, Sep 24, 2020 at 11:04 AM aealexsandrov 
mailto:aealexsand...@gmail.com>> wrote:


Hi,

Can you please provide the full server logs?

BR,
Andrei



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

Re: OutOfMemoryException with Persistence and Eviction Enabled

2020-09-24 Thread Andrei Aleksandrov


Hi,

Did you try to increase the DataRegion size a little bit? It looks like 
190 MB isn't enough for some internal structures that Ignite stores in 
OFF-HEAP except the data.


I suggest you increase the data region size to for example 512 MB - 1024 
MB and take a look at how it will work.


If you still will see the issue then I guess we should create the ticket:

1)Collect the logs
2)Provide the java code example
3)Provide the configuration of the nodes

After that, we can take a look more deeply into it and if it's an issue 
then file JIRA.


BR,
Andrei

9/23/2020 7:36 PM, Mitchell Rathbun (BLOOMBERG/ 731 LEX) пишет:

Here is the exception:
Sep 22, 2020 7:58:22 PM java.util.logging.LogManager$RootLogger log
SEVERE: Critical system error detected. Will be handled accordingly to 
configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, 
timeout=0, super=AbstractFailureHandler 
[ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class 
o.a.i.i.mem.IgniteOutOfMemoryException: Out of memory in data region 
[name=customformulacalcrts, initSize=190.7 MiB, maxSize=190.7 MiB, 
persistenceEnabled=true] Try the following:
^-- Increase maximum off-heap memory size 
(DataRegionConfiguration.maxSize)

^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
^-- Enable eviction or expiration policies]]
class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Out 
of memory in data region [name=customformulacalcrts, initSize=190.7 
MiB, maxSize=190.7 MiB, persistenceEnabled=true] Try the following:
^-- Increase maximum off-heap memory size 
(DataRegionConfiguration.maxSize)

^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
^-- Enable eviction or expiration policies
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:607)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.allocateDataPage(AbstractFreeList.java:464)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:491)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.insertDataRow(CacheFreeListImpl.java:59)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.insertDataRow(CacheFreeListImpl.java:35)
at 
org.apache.ignite.internal.processors.cache.persistence.RowStore.addRow(RowStore.java:103)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.createRow(IgniteCacheOffheapManagerImpl.java:1691)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.createRow(GridCacheOffheapManager.java:1910)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:5701)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:5643)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3719)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5900(BPlusTree.java:3613)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1895)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1872)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1779)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1638)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1621)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1935)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:428)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:4248)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:4226)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdateLocal(GridCacheMapEntry.java:2106)
at 
org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.updateAllInternal(GridLocalAtomicCache.java:929)
at 
org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.access$100(GridLocalAtomicCache.java:86)
at 
org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache$6.call(GridLocalAtomicCache.java:776)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6817)
at

Re: Performance on Windows vs Linux

Got it. If everything is the same then it looks like I can't suggest 
something to you here but as I know most users run their solutions on 
Linux OS. Probably it can be related to some performance benefits of 
Linux OS but I don't think that this difference should be significant.


7/23/2020 7:34 PM, njcstreet пишет:

Thanks. Not so easy to describe the PoC due to confidentiality. But it
involves writing a lot of data as fast as possible at the start of the day,
with persistence enabled, then with incremental updates throughout the day,
and with many user queries on top through SQL (sorry I know that is probably
not that helpful).

I have 6 machines all with decent specification, SSD storage and 10gb
network connectivity. I was just wondering if there is a particular benefit
to deploying one OS over another. If there isn’t much in it, I will go with
the one I am familiar with.

Regards,

Nigel



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

Re: Performance on Windows vs Linux


Hi,

I guess that you should take a look from another point of view. You have 
two servers that should be compared to each other. Take a look at the 
following things:


1)Disk speed and size
2)Network latency
3)CPU and RAM capacities

I guess that these things will be more important than the used operation 
system.


However, can you describe your POC details? Probably it can help us to 
advise you something else.


BR,
Andrei

7/23/2020 12:45 PM, njcstreet пишет:

Hi,

I am about to start a proof of concept on Ignite and we have the option of
deploying either on Windows Server 2016 or Red Hat Linux 7. I know that
Ignite can be deployed on both, but is there reason to pick one over the
other?

Is performance better on a particular environment? We are using native
persistence -  think that Direct IO can be enabled but only on Linux?

Thanks.



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

Re: 2.8.1 : Ignite Security : Cache_Put event generated from a remote_client user action has subject uuid of Node that executes the request


Hi Veena,

Indeed it looks like that current problem wasn't solved. It looks like 
there are not enough people interested in the current fix. However, 
Ignite is the open-source community. You can make a patch for you or 
even provide it to the community.


Unfortunately, I don't think that somebody on the user mail list can 
help here. You can try to ask one more time on the developer mail list.


Also, you can try to investigate some third party security plugins in 
case if it's important to you.


BR,
Andrei

7/22/2020 4:17 PM, VeenaMithare пишет:

Hi Team,

1. I noticed that this issue (
https://issues.apache.org/jira/browse/IGNITE-12781) is not resolved in
2.8.1.

Could you guide how can we get audit information if a cache record
modification is done on dbeaver and the cache_put event contains the node id
instead of the remote_client subject id ?

Please note this is a blocker issue for us to use Apache Ignite , since we
use dbeaver to update records sometimes.
If this is not resolved, could we kindly ask this to be included in the next
release.

2. Even if the cache_put event did contain the remote_client user id , how
are we supposed to fetch it from the auditstoragespi ?

The below link mentions
http://apache-ignite-users.70518.x6.nabble.com/JDBC-thin-client-incorrect-security-context-td31354.html

public class EventStorageSpi extends IgniteSpiAdapter implements
EventStorageSpi {
 @LoggerResource
 private IgniteLogger log;

 @Override
 public  Collection localEvents(IgnitePredicate p)
{
 return null;
 }

 @Override
 public void record(Event evt) throws IgniteSpiException {
 if (evt.type() == EVT_MANAGEMENT_TASK_STARTED) {
 TaskEvent taskEvent = (TaskEvent) evt;

 SecuritySubject subj = taskEvent.subjectId() != null
 ?
getSpiContext().authenticatedSubject(taskEvent.subjectId())
 : null;

 log.info("Management task started: [" +
 "name=" + taskEvent.taskName() + ", " +
 "eventNode=" + taskEvent.node() + ", " +
 "timestamp=" + taskEvent.timestamp() + ", " +
 "info=" + taskEvent.message() + ", " +
 "subjectId=" + taskEvent.subjectId() + ", " +
 "secureSubject=" + subj +
 "]");
 }
 }

 @Override
 public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
 /* No-op. */
 }

 @Override
 public void spiStop() throws IgniteSpiException {
 /* No-op. */
 }
}

IgniteSpiContext exposes authenticatedSubject which according to some
discussions gets the subject *only for node* . (
http://apache-ignite-developers.2346864.n4.nabble.com/Security-Subject-of-thin-client-on-remote-nodes-td46029.html#a46412
)

/*securityContext(uuid ) was added to the GridSecurityProcessor to get the
securitycontext of the thin client. However this is not exposed via the
IgniteSpiContext.* /


3. The workaround I did was as follows. Please let me know if you see any
concerns on this approach -
a. Add the remoteclientsubject into the authorizationcontext of the
authenticationcontext in the authenticate method of the securityprocessor.

b. This authorizationcontext is now put in a threadlocal variable ( Check
the class AuthorizationContext )
private static ThreadLocal actx = new ThreadLocal<>();

c. The following has been done in the storagespi when a change is made in
the dbeaver,
c1. capture the EVT_TX_STARTED in the storage spi. The thread that generates
this event contains the subject in its threadlocal authorizationcontext.
Store this in a cache that holds the mapping transaction id to security
subject.

c2. capture the cache_put event and link the transaction id in the cache_put
event to the transaction id in the EVT_TX_STARTED and get the subject by
this mapping.

c3. The transactionid in cache_put and the transactionid in EVT_TX_STARTED
could be same, in which case it is a direct mapping

c4. The transactionid in cache_put and the transactionid in EVT_TX_STARTED
could be different, in which case it is a case of finding the nearxid of the
transactionid in the cacheput event. And then find the security subject of
the nearxid


regards,
Veena.





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

Re: third-party persistance and junction table


Hi,

Unfortunately, Ignite doesn't support such kind of relations out of the 
box. Ignite just translates it to third party data storage that used as 
cache-store.


It's expected that inserts and updates will be rejected in case if they 
break some rules.


BR,
Andrei
7/21/2020 11:16 AM, Bastien Durel пишет:

Hello,

I have a junction table in my model, and used the web console to
generate ignite config and classes from my SQL database

-> There is a table user with id (long) and some data
-> There is a table role with id (long) and some data
-> There is a table user_role with user_id (fk) and role_id (fk)

Reading cache from table works, I can query ignite with jdbc and I get
my relations as expected.

But if I want to add a new relation, the query :
insert into "UserRoleCache".user_role(USER_ID, ROLE_ID) values(6003, 2)
is translated into this one, sent to postgresql :
UPDATE public.user_role SET  WHERE (user_id=$1 AND role_id=$2)

Which obviously is rejected.

The web console generated a cache for this table, with UserRole
& UserRoleKey types, which each contains userId and roleId Long's.

Is there a better (correct) way to handle these many-to-many relations
in ignite (backed by RDBMS) ?

Regards,

Re: Cache query exception when using generic type: class java.util.ArrayList cannot be cast to


Hi,

You can put different types of objects in your cache because of the 
specific of its implementation. But this possibility can break your 
ScanQuery because you are going to see in cache only StationDto objects.


I guess that previously you put ArrayList inside the cache and then you 
put StationDto.


Please note that in case if you are going to change the ValueType of the 
cache then you must destroy it and then create with a new configuration.


I guess values of different types in the same cache are a reason of your 
issue.


BR,
Andrei

7/16/2020 4:41 PM, xingjl6280 пишет:

hi team,

Please kindly advise.
Below is my code and exception.
Btw, if I use ScanQuery and List, no error.

Something wrong with classloader? the normal cache put and get work well for
my class,  data could be deserialised to my class automatically.


thank you


My code:
***
cache.put(ProjectCacheConst.STATION_PREFIX+"1", new StationDto());
cache.put(ProjectCacheConst.STATION_PREFIX+"2", new StationDto());
cache.put(ProjectCacheConst.STATION_PREFIX+"3", new StationDto());

ScanQuery scanQuery = new ScanQuery<>(
 (k, v) -> k.startsWith(ProjectCacheConst.STATION_PREFIX) &&
nonNull(v));

List list = getCache(projectCode).query(scanQuery,
Cache.Entry::getValue).getAll();
***

Exception:

org.apache.ignite.IgniteException: class java.util.ArrayList cannot be cast
to class com.hh.sd.rtms.h_dto.map.StationDto (java.util.ArrayList is in
module java.base of loader 'bootstrap'; com.hh.sd.rtms.h_dto.map.StationDto
is in unnamed module of loader
org.apache.catalina.loader.ParallelWebappClassLoader @597bc1c6)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$InternalScanFilter.apply(GridCacheQueryManager.java:3232)
~[ignite-core-2.8.1.jar:2.8.1]
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3108)
~[ignite-core-2.8.1.jar:2.8.1]
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
~[ignite-core-2.8.1.jar:2.8.1]
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
~[ignite-core-2.8.1.jar:2.8.1]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
~[ignite-core-2.8.1.jar:2.8.1]
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:123)
~[ignite-core-2.8.1.jar:2.8.1]
at
com.hh.sd.rtms.f_data_service.ProjectCacheServiceBean.getAllStations(ProjectCacheServiceBean.java:166)
~[rtms-core-0.1-SNAPSHOT.jar:na]
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) ~[na:na]
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[na:na]
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:na]
at java.base/java.lang.reflect.Method.invoke(Method.java:566) ~[na:na]
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
~[spring-aop-5.2.3.RELEASE.jar:5.2.3.RELEASE]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
~[spring-aop-5.2.3.RELEASE.jar:5.2.3.RELEASE]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
~[spring-aop-5.2.3.RELEASE.jar:5.2.3.RELEASE]
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
~[spring-aop-5.2.3.RELEASE.jar:5.2.3.RELEASE]





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

Re: cache.getAsync() blocks if cluster is not activated.


Hi,

I don't think that it should hang because there are no cache operations 
allowed when the cluster isn't activated. It should be some kind of 
CacheExcdption.


Is it possible to prepare some reproducer or unit test? Otherwise please 
provide some details:


1)What Ignite version was used?
2)Can you please share a server and cache configuration?

BR,
Andrei
7/15/2020 9:57 PM, John Smith пишет:

Hi, testing some failover scenarios etc...

When we call cache.getAsync() and the state of the cluster is not 
active. It seems to block.


I implemented a cache repository as follows and using Vertx.io. It 
seems to block at the cacheOperation.apply(cache)


So when I call myRepo.get(myKey) which underneath applies the 
cache.getAsync() function it blocks.


public class IgniteCacheRepository implements CacheRepository {
 public final long DEFAULT_OPERATION_TIMEOUT =1000; private final 
TimeUnitDEFAULT_TIMEOUT_UNIT = TimeUnit.MILLISECONDS; private Vertxvertx; private 
IgniteCache cache; public IgniteCacheRepository(Vertx vertx, IgniteCache cache) {
 this.vertx = vertx; this.cache = cache; }

 @Override public Futureput(K key, V value) {
 return executeAsync(cache -> cache.putAsync(key, value), 
DEFAULT_OPERATION_TIMEOUT, DEFAULT_TIMEOUT_UNIT); }

 @Override public Future get(K key) {
 return executeAsync(cache -> cache.getAsync(key), 
DEFAULT_OPERATION_TIMEOUT, DEFAULT_TIMEOUT_UNIT); }

 @Override public  Future invoke(K key, EntryProcessor 
processor, Object... arguments) {
 return executeAsync(cache -> cache.invokeAsync(key, processor, 
arguments), DEFAULT_OPERATION_TIMEOUT, DEFAULT_TIMEOUT_UNIT); }

 @Override public  T cache() {
 return (T)cache; }

 /** * Adapt Ignite async operation to vertx futures. * * @param 
cacheOperation The ignite operation to execute async. * @return The 
value from the cache operation. */ private  Future executeAsync(Function, IgniteFuture> cacheOperation, long timeout, TimeUnit unit) {

 Future future = Future.future(); try {
 IgniteFuture value = cacheOperation.apply(cache); 
value.listenAsync(result -> {
 try {
 future.complete(result.get(timeout, unit)); 
}catch(Exception ex) {
 future.fail(ex); }
 }, 
VertxIgniteExecutorAdapter.getOrCreate(vertx.getOrCreateContext())); 
}catch(Exception ex) {
 // Catch some RuntimeException that can be thrown by Ignite cache. 
future.fail(ex); }

 return future; }
}

Re: Ignite node log file setup

2020-06-10 Thread Andrei Aleksandrov


Hi,

Can you please attach the whole log file?

BR,
Andrei

6/9/2020 5:14 AM, kay пишет:

Hello!

I start up

sh ./ignite.sh -J-DgridName=testGridName -v ./config/config-cache.xml

and in config-cache.xml


but server start failed.

Is that not proper to set igniteInstanceName??

log is here
class org.apache.ignite.IgniteException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.communication.GridIoManager]
  at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1067)
  at org.apache.ignite.Ignition.start(Ignition.java:349)
  at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:300)
  Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
manager: GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.communication.GridIoManager]
  at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1965)
  at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1173)
  at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
  at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
  at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
  at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659)
  at org.apache.ignite.Ignition.start(Ignition.java:346)
  ... 1 more
  Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
SPI: TcpCommunicationSpi [connectGate=null,
connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@6622fc65,
chConnPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$4@299321e2,
enableForcibleNodeKill=false, enableTroubleshootingLog=false,
locAddr=42.1.188.128, locHost=intdev01/42.1.188.128, locPort=48722,
locPortRange=1, shmemPort=-1, directBuf=true, directSndBuf=false,
idleConnTimeout=60, connTimeout=5000, maxConnTimeout=60,
reconCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
slowClientQueueLimit=0, nioSrvr=GridNioServer [selectorSpins=0,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=org.apache.ignite.internal.util.nio.GridDirectParser@2f17e30d,
directMode=true], GridConnectionBytesVerifyFilter], closed=false,
directBuf=true, tcpNoDelay=true, sockSndBuf=32768, sockRcvBuf=32768,
writeTimeout=2000, idleTimeout=60, skipWrite=false, skipRead=false,
locAddr=intdev01/42.1.188.128:48722, order=LITTLE_ENDIAN, sndQueueLimit=0,
directMode=true,
mreg=org.apache.ignite.internal.processors.metric.MetricRegistry@71cf1b07,
rcvdBytesCntMetric=org.apache.ignite.internal.processors.metric.impl.LongAdderMetric@a9be6fa5,
sentBytesCntMetric=org.apache.ignite.internal.processors.metric.impl.LongAdderMetric@489b09ce,
outboundMessagesQueueSizeMetric=org.apache.ignite.internal.processors.metric.impl.LongAdderMetric@69a257d1,
sslFilter=null, msgQueueLsnr=null, readerMoveCnt=0, writerMoveCnt=0,
readWriteSelectorsAssign=false], shmemSrv=null, usePairedConnections=false,
connectionsPerNode=1, tcpNoDelay=true, filterReachableAddresses=false,
ackSndThreshold=32, unackedMsgsBufSize=0, sockWriteTimeout=2000,
boundTcpPort=48722, boundTcpShmemPort=-1, selectorsCnt=8, selectorSpins=0,
addrRslvr=null,
ctxInitLatch=java.util.concurrent.CountDownLatch@181e731e[Count = 1],
stopping=false,
metricsLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationMetricsListener@19648c40]
  at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
  at
org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:435)
  at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960)
  ... 11 more
  Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
register SPI MBean: null
  at
org.apache.ignite.spi.IgniteSpiAdapter.registerMBean(IgniteSpiAdapter.java:421)
  at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.spiStart(TcpCommunicationSpi.java:2397)
  at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
  ... 13 more
  Caused by: javax.management.MalformedObjectNameException: Invalid character
':' in value part of property
  at javax.management.ObjectName.construct(ObjectName.java:618)
  at javax.management.ObjectName.(ObjectName.java:1382)
  at
org.apache.ignite.internal.util.IgniteUtils.makeMBeanName(IgniteUtils.java:4719)

Re: Cache_Put event generated from a remote_client user action has subject uuid of Node that executes the request sometimes

2020-06-10 Thread Andrei Aleksandrov


Hi,

Your approach is correct as for me.

IgniteCache can help to hold all the 
information about started transactions and users.


Using EventStorageSpi is a good way to handle the events.

BR,
Andrei

6/9/2020 10:06 AM, VeenaMithare пишет:

Cache_Put event generated from a remote_client user action has subject uuid
of Node that executes the request sometimes.
The Jira IGNITE-12781 was created by me for this. Some related conversation
on this could be found at
  (
http://apache-ignite-developers.2346864.n4.nabble.com/Security-Subject-of-thin-client-on-remote-nodes-td46029.html#a46406
and the last few comments on this post :
http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html)

To tackle the issue till this jira is fixed I have used the approach as
below .
Kindly confirm if you see any concerns with this :

1.If the cache_put event holds the subject id of the remoteclient, then
fetch it using getSpiContext().authenticatedSubject(uuid ) method. ( This in
turn will check the AuthenticationContext.context() and match the subjectId
in of the event with the one in the AuthenticationContext.context() )
2.If it holds the subjectId of the node instead of the remoteclient( In this
case, the subject returned by point 1 will be null ) -

1.Create a cache( transactionIdToSubjectCache) that holds xid vs security
subject information where xid is the id of the transaction started event.
The subject Id on this event always holds the remote client id for cache put
events generated on dbeaver.
2.When a cacheput event is sent to the storage spi - match the xid as
follows
a.Get the subject from transactionIdToSubjectCache using the xid.
b.If the above is null, get the originating xid of the event xid and get the
subject using the originating xid.



  


I am able to get the subject using this approach- could you kindly verify if
I am missing anything.

Here is a pseudo code :

public class AuditSpi extends IgniteSpiAdapter implements EventStorageSpi {
 private IgniteCache
transactionIdSubjectMapCache;

  


 @Override
 public void record(Event evt) throws IgniteSpiException {
 assert evt != null;
 ignite = Ignition.ignite(igniteInstanceName);
 transactionIdSubjectMapCache =
ignite.cache("transactionIdSubjectMapCache");




 if (evt instanceof TransactionStateChangedEvent && (evt.type()
 == EventType.EVT_TX_STARTED
 )) {

 //populate the transactionIdSubjectMapCache for events generated
from dbeaver. This always contains the remote_client subject id.
 if (AuthorizationContext.context() != null)
{
transactionIdSubjectMapCache.put(((TransactionStateChangedEvent)
evt).tx().xid(),
((ProjectAuthorizationContext) AuthorizationContext.context()) .subject());
 }
 return;

 }

 if (evt instanceof CacheEvent) {

 SecuritySubject subj =
getSpiContext().authenticatedSubject(((CacheEvent) evt).subjectId())l;
 IgniteUuid transactionId = null;
 if (subj == null)
{
SecuritySubject sub =
getSecuritySubjectFromTransactionMap((CacheEvent) evt,  transactionId);
   // more logic to store it in the audit cache here.

}
 }

 }

 private SecuritySubject getSecuritySubjectFromTransactionMap(CacheEvent
evt,
   
IgniteUuid transactionId) {

 SecuritySubject subj = transactionIdSubjectMapCache.get(evt.xid());
 


 if (subj == null) {

 IgniteTxManager tm = ((IgniteEx)
ignite).context().cache().context().tm();

 for (IgniteInternalTx transaction : tm.activeTransactions()) {

 if (transaction.xid().equals(evt.xid())) {
 if (transaction.nearXidVersion() != null)
{ subj = transactionIdSubjectMapCache
.get(transaction.nearXidVersion().asGridUuid()); }
 }
 }
 }
 return subj;

 }

  


}

  


regards,

Veena.




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

Re: Ignite.cache.loadcache.Does this method do Increamental Load?

2020-03-26 Thread Andrei Aleksandrov

Hi,

loadCache - will load all the keys and values from third party store
into Ignite. It can be used for initial loading and for restore of the
Ignite cache.

There are no incremental updates.

In case if you are going to do updates in the third party store not
using Ignite API then you also should do the same for Ignite.

However, you can use read-through and write-through properties. They can
help you to make your updates in 3-rd party store using Ignite API:

https://apacheignite.readme.io/docs/3rd-party-store#section-read-through-and-write-through

BR,
Andrei

3/23/2020 9:34 PM, nithin91 пишет:

I am trying to load the data into ignite cache using JDBC Pojo Store method
ignite.cache("cacheName").loadCache(null).I have used this method and got
the following results for the following scenarios.

*Scenario-1:Trying to load the same key which is available in cache*

In this case, the value part corresponding to the key is not updated in the
cache based on the latest available record.

*Scenario -2:When loading a key which is not present in cache.*

in this case, it is appending the new key and value pair to the cache and
preserving the old data.

But my doubt is why in scenario-1, it is not updating the value
corresponding to the when i am trying to load the same key.

Does this method do incremental load?.
Is this the expected behavior or do i need to set any additional property in
the bean file.Attaching you the bean configuration of the cache.

cache.xml

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

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

2020-02-24 Thread Andrei Aleksandrov


Hi,

I can suggest to use the cache store implementation. For example current 
guide 
 
shows how Hive schema can be imported using web console.


In case if you require to work with files (not tables) then please use 
HDFS or Spark API directly. Ignite provides good Spark integration:


https://apacheignite-fs.readme.io/docs/ignite-data-frame

BR,
Andrei

2/21/2020 6:52 PM, Preet пишет:

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: Slow cache updates with indexing module enabled

2020-02-14 Thread Andrei Aleksandrov


Hi,

Some recommendations should be applied to every SQL query:

1)You should avoid using __SCAN_
2)You should use LAZY if the result set is big.
3)You should inline the indexes

Please read my comments:

1)My question is what is happening with all those indexes when an entry is
updated but, none of the indexed fields (except one) are being changed? In
our case, we are only flipping a boolean value of only 1 field. Is this
change triggering updates in ALL the indexes associated with the cache?

Yes, all your indexes will be rebuilt (new value will be inserted in the 
index tree).


2)When we update entry field SEGMENT_1 field with a True, are the other 99
indexes updated?

It looks like yes.

3)Those tickets I mentioned seem to be related but I would like to have your
confirmation.

Yes, https://issues.apache.org/jira/browse/IGNITE-7015 is related to 
this behavior. You can try to highlite it on the development mail list.


BR,
Andrei
2/13/2020 5:50 PM, xero пишет:

Hi Andrei, thanks for taking the time to answer my question. I will consider
your suggestion if we decide to switch to a multiple tables approach that
will require those JOIN considerations. But, in this case we have only 1
cache and the operation that we are executing is an update. We tried using
SQL-Update but we also tried using a CacheEntryProcessor directly. My
question is what is happening with all those indexes when an entry is
updated but, none of the indexed fields (except one) are being changed? In
our case, we are only flipping a boolean value of only 1 field. Is this
change triggering updates in ALL the indexes associated with the cache?

Cache is like this (with indexes on all fields):
id|(other fields)|segment_1|segment_2|segment_2|...|segment_99|segment_100

Then we try updating a batch of entries with an invokeAll using a
CacheEntryProcessor:
public Void process(MutableEntry entry, Object...
arguments) {
final BinaryObjectBuilder builder =
entry.getValue().toBuilder().setField("SEGMENT_1", true);
entry.setValue(builder.build());

return null;
}
When we update entry field SEGMENT_1 field with a True, are the other 99
indexes updated?
Those tickets I mentioned seem to be related but I would like to have your
confirmation.



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

Re: Scheduling Cache Refresh using Ignite

2020-02-14 Thread Andrei Aleksandrov


Hi Nithin,

You face current message because your client lost the connection to the 
server. It tries to get the acknowledge message on some operation (I 
guess it should be some cache operation).


You can see that IgniteClientDisconnectedException was thrown. In this 
case, you can get the reconnect future and wait for the client reconnection:


https://apacheignite.readme.io/docs/clients-vs-servers#reconnecting-a-client

Please add try/catch blocks around your cache operation and add next logic:

|catch (IgniteClientDisconnectedException e) { 
e.reconnectFuture().get(); // Wait for reconnect. // Can proceed and use 
the same IgniteCompute instance. }|



I can't say why your client was disconnected. Highly likely it's because 
of some network issues. You can try to take a look at server logs and 
find there *NODE_LEFT *or *NODE_FAILED *messages.


BR,
Andrei

2/14/2020 8:08 AM, nithin91 пишет:

Hi

I am unable to attach any file as a result of which i pasted the code and
bean file in my previous messages.

Following is error i get.

Feb 13, 2020 11:34:40 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Failed to send message: null
java.io.IOException: Failed to get acknowledge for message:
TcpDiscoveryClientMetricsUpdateMessage [super=TcpDiscoveryAbstractMessage

  


[sndNodeId=null, id=b9bb52d3071-613fd9b8-0c00-4dde-ba8f-8f5341734a3c,
verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null,
isClient=true]]
 at
org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketWriter.body(ClientImpl.java:1398)
 at
org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)

Feb 13, 2020 11:34:47 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Failed to reconnect to cluster (consider increasing 'networkTimeout'
configuration property) [networkTimeout=5000]
[11:34:52] Ignite node stopped OK [uptime=00:00:24.772]
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteClientDisconnectedException: Failed to execute
dynamic cache change request, client node disconnected.
 at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
 at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache0(IgniteKernal.java:3023)
 at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2992)
 at Load.OrdersLoad.main(OrdersLoad.java:82)
Caused by: class org.apache.ignite.IgniteClientDisconnectedException: Failed
to execute dynamic cache change request, client node disconnected.
 at
org.apache.ignite.internal.util.IgniteUtils$15.apply(IgniteUtils.java:952)
 at
org.apache.ignite.internal.util.IgniteUtils$15.apply(IgniteUtils.java:948)
 ... 4 more
Caused by: class
org.apache.ignite.internal.IgniteClientDisconnectedCheckedException: Failed
to execute dynamic cache change request, client node disconnected.
 at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDisconnected(GridCacheProcessor.java:1180)
 at
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3949)
 at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:821)
 at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:604)
 at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2667)
 at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2705)
 at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
 at java.lang.Thread.run(Thread.java:748)




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

Re: Ignite yarn resources keep on increasing


Hi,

Could you please provide more details:

1)Your configurations and environment variables (IGNITE_PATH?)
2)The logs of your Ignite nodes where you see the mentioned exception.

IGNITE_PATH - a path to unzipped Ignite distribution instead of the URL. 
Is it possible that you didn't unzip the binaries or forget to copy 
binaries to some node?


BR,
Andrei

2/13/2020 1:12 PM, ChandanS пишет:

I am using ignite 2.7 version for ignite yarn deployment. I have my own spark
application that start ignite yarn cluster and load data to ignite. It works
fine in positive scenarios, but whenever there is an exception from the
ignite-yarn.jar side like giving wrong path for some properties
(IGNITE_PATH), the resource uses keep on increasing with some time interval.
I have started my application with --num-executors 40 --executor-cores 2,
currently after keeping the application up for last 10 hrs number of
executors is 461 and cores 921 with increasing in memory as well. I am
getting the below exception from ignite-yarn application:

class org.apache.ignite.IgniteException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]



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

Re: Scheduling Cache Refresh using Ignite


Hi,

Can you please attach the full logs with the mentioned exception? BTW I 
don't see any attaches in the previous message (probably user list can't 
do it).


BR,
Andrei

2/13/2020 3:44 PM, nithin91 пишет:

Attached the bean file used



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

Re: Slow cache updates with indexing module enabled


Hi,

SQL query performance can be not great because of several cases:

1)Incorrect indexes. Please check that your EXPLAIN contains indexes and 
doesn't have scans for joins:


INNER JOIN PUBLIC.PERSON P__Z1
    /* PUBLIC.PERSON.__SCAN_ */

Probably the inline size for used index is incorrect or wrong index used.

To solve this problem you should calculate the Inline for every index 
and check that your correct index used in EXPLAIN of your query. Here is 
the example of how inline for the field can be calculated:


**

*long*

*

0     1   9

| tag | value |

Total: 9 bytes


int

0     1   5

| tag | value |

Total: 5 bytes


String

0     1 3             N

| tag | size | UTF-8 value |

Total: 3 + string length


POJO (BinaryObejct)

0     1 3     4 8     12 16 20       24 32 N

| tag | size | tag | size | BO flags | type ID | hash | length | schema 
info | BO body |


  |               Binary object header         
      |


Total: 32 + N

*
2)GC pauses because of query execution without *LAZY *flag.

3)In the case of multiple joins the order of these joins can be 
incorrect because of H2 optimizer specific used in Ignite.


To fix this problem you should prepare the correct join order and set 
the *"enforce join order"* flag. When the BIG table will be joined to 
SMALL then it will be faster than otherwise:


select * from SMALLTABLE, BIGTABLE where SMALLTABLE.id = BIGTABLE.id - 
correct
select * from BIGTABLE , SMALLTABLEwhere SMALLTABLE.id = BIGTABLE.id - 
incorrect


Check the join order using the EXPLAIN command.

BR,
Andrei

2/12/2020 11:24 PM, xero пишет:

Hi,
We are experiencing slow updates to a cache with multiple indexed fields
(around 25 indexes during testing but we expect to have many more) for
updates that are only changing one field. Basically, we have a
customer*->belongsto->*segment relationship and we have one column per
segment. Only one column is updated with a 1 or 0 if the customer belongs to
the segment.

During testing, we tried dropping half of the unrelated indexes (indexes
over fields that are not being updated) and we duplicate the performance. We
went from 1k ops to 2k ops approximately.

We found these cases may be related:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-19%3A+SQL+index+update+optimizations
https://issues.apache.org/jira/browse/IGNITE-7015?src=confmacro

Could you please confirm us if IGNITE-7015 could be related to this
scenario? If yes, do you have any plans to continue the development of the
fix?


We are using Ignite 2.7.6 with 10 nodes, 2 backups, indexing module enabled
and persistence.

Cache Configuration: [name=xdp-contactcomcast-1, grpName=null,
memPlcName=xdp, storeConcurrentLoadAllThreshold=5, rebalancePoolSize=2,
rebalanceTimeout=1, evictPlc=null, evictPlcFactory=null,
onheapCache=false, sqlOnheapCache=false, sqlOnheapCacheMaxSize=0,
evictFilter=null, eagerTtl=true, dfltLockTimeout=0, nearCfg=null,
writeSync=PRIMARY_SYNC, storeFactory=null, storeKeepBinary=false,
loadPrevVal=false, aff=RendezvousAffinityFunction [parts=1024, mask=1023,
exclNeighbors=false, exclNeighborsWarn=false, backupFilter=null,
affinityBackupFilter=null], cacheMode=PARTITIONED, atomicityMode=ATOMIC,
backups=2, invalidate=false, tmLookupClsName=null, rebalanceMode=ASYNC,
rebalanceOrder=0, rebalanceBatchSize=524288, rebalanceBatchesPrefetchCnt=2,
maxConcurrentAsyncOps=500, sqlIdxMaxInlineSize=-1, writeBehindEnabled=false,
writeBehindFlushSize=10240, writeBehindFlushFreq=5000,
writeBehindFlushThreadCnt=1, writeBehindBatchSize=512,
writeBehindCoalescing=true, maxQryIterCnt=1024,
affMapper=org.apache.ignite.internal.processors.cache.CacheDefaultBinaryAffinityKeyMapper@db5e319,
rebalanceDelay=0, rebalanceThrottle=0, interceptor=null,
longQryWarnTimeout=3000, qryDetailMetricsSz=0, readFromBackup=true,
nodeFilter=IgniteAllNodesPredicate [], sqlSchema=XDP_CONTACTCOMCAST_1,
sqlEscapeAll=false, cpOnRead=true, topValidator=null, partLossPlc=IGNORE,
qryParallelism=1, evtsDisabled=false, encryptionEnabled=false]


Thanks,








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

Re: Scheduling Cache Refresh using Ignite

Hi,

Please read my comments:

1)Ignite generally doesn't support changing of the cache configuration
without re-creation of the the cache. But for SQL caches that were
created via QueryEntity or CREATE TABLE you can add and remove the
columns using ALTER TABLE commands:

https://apacheignite-sql.readme.io/docs/alter-table
https://apacheignite.readme.io/docs/cache-queries#query-configuration-using-queryentity
https://apacheignite-sql.readme.io/docs/create-table
2)First of all, you can use the following options:

https://apacheignite.readme.io/docs/3rd-party-store#section-read-through-and-write-through

Read through can load the requested keys from DB
Write through will load all the updates to DB.

In case if you require some cache invalidation or refresh then you can
create some cron job for it.

3)I guess that loadCache is the only to do it. It will filter the values
that have already existed in the cache.

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#loadCache-org.apache.ignite.lang.IgniteBiPredicate-java.lang.Object...-

4)You can use a different subset of integrations that can do distributed
streaming to Ignite like Spark or Kafka:

https://apacheignite-mix.readme.io/docs/getting-started

BR,
Andrei
2/12/2020 9:11 PM, nithin91 пишет:

We are doing a a POC on exploring the Ignite in memory capabilities and
building a rest api on
top of it using node express.

Currently as a part of POC, installed Ignite in UNIX and trying to load the
data from Oracle DB
to Ignite Cache using Cache JDBC Pojo Store.

Can someone help me whether the following scenarios can be handled using
Ignite as i couldn't find this in the official documentation.

1. If we want to add/drop/modify a column to the cache, can we
update the
bean file directly
when the node is running or do we need to stop the node and
then again
restart.
It would be really helpful if you can share sample code or
documentation link.

2. How to refresh the ignite cache automatically or schedule
the cache
refresh.
It would be really helpful if you can share sample code or
documentation link.

3. Is incremental refresh allowed? It would be really helpful
if you can
share sample code or
documentation link.

4. Is there any other way to load the caches fast other Cache
JDBC POJO
Store.
It would be really helpful if you can share sample code or
documentation link.

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

Re: Ignite on yarn doesn't started


Hi,

I asked you to check it because I see the next option:

IGNITE_PATH = /tmp/ignite/apache-ignite-2.7.6-bin.zip

This option should be a path to *unzipped *Ignite distribution instead 
of the URL (you set zip)


Also I see commented IGNITE_URL option:

#IGNITE_URL =
http://ambari1.dmz.loc:/filebrowser/view=/tmp/ignite/apache-ignite-2.7.6-bin.zip

So it looks like you don't provide the Ignite binaries to your YARN 
deployment.


BR,
Andrei

2/11/2020 9:19 PM, v.shinkevich пишет:

aealexsandrov wrote

1) check that Ignite libs (from ignite_binaries/libs) are available for
your YARN deployment.
2) check that path to the configuration file is reachable from every node

1) I don't understand what I need to check. Where should these libs be ?  Do
I need to unpack the distribution? To a local folder or to HDFS?

My /tmp/ignite folder (on HDFS, on local the same content + unpacked distro
for local run check)

On HDFS I don't have any logs. Only one jar in workdir.


Log of local run:
[root@dn07 /tmp/ignite/apache-ignite-2.7.6-bin/bin]# ./ignite.sh

[20:54:37]__  
[20:54:37]   /  _/ ___/ |/ /  _/_  __/ __/
[20:54:37]  _/ // (7 7// /  / / / _/
[20:54:37] /___/\___/_/|_/___/ /_/ /___/
[20:54:37]
[20:54:37] ver. 2.7.6#20190911-sha1:21f7ca41
[20:54:37] 2019 Copyright(C) Apache Software Foundation
[20:54:37]
[20:54:37] Ignite documentation: http://ignite.apache.org
[20:54:37]
[20:54:37] Quiet mode.
[20:54:37]   ^-- Logging to file
'/tmp/ignite/apache-ignite-2.7.6-bin/work/log/ignite-e2eeb3da.0.log'
[20:54:37]   ^-- Logging by 'JavaLogger [quiet=true, config=null]'
[20:54:37]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
or "-v" to ignite.{sh|bat}
[20:54:37]
[20:54:37] OS: Linux 3.10.0-693.el7.x86_64 amd64
[20:54:37] VM information: Java(TM) SE Runtime Environment 1.8.0_141-b15
Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.141-b15
[20:54:38] Please set system property '-Djava.net.preferIPv4Stack=true' to
avoid possible problems in mixed environments.
[20:54:38] Configured plugins:
[20:54:38]   ^-- None
[20:54:38]
[20:54:38] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
[tryStop=false, timeout=0, super=AbstractFailureHandler
[ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT
Java HotSpot(TM) 64-Bit Server VM warning: sched_getaffinity failed (Invalid
argument)- using online processor count (192) which may exceed available
processors
[20:54:38] Message queue limit is set to 0 which may lead to potential OOMEs
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
message queues growth on sender and receiver sides.
[20:54:39] Security status [authentication=off, tls/ssl=off]
[20:54:44] Performance suggestions for grid  (fix if possible)
[20:54:44] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[20:54:44]   ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM
options)
[20:54:44]   ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
JVM options)
[20:54:44]   ^-- Set max direct memory size if getting 'OOME: Direct buffer
memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[20:54:44]   ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[20:54:44]   ^-- Speed up flushing of dirty pages by OS (alter
vm.dirty_expire_centisecs parameter by setting to 500)
[20:54:44] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[20:54:44]
[20:54:44] To start Console Management & Monitoring run
ignitevisorcmd.{sh|bat}
[20:54:44] Data Regions Configured:
[20:54:44]   ^-- default [initSize=256.0 MiB, maxSize=403.0 GiB,
persistence=false]
[20:54:44]
[20:54:44] Ignite node started OK (id=e2eeb3da)
^C
[20:55:19] Ignite node stopped OK [uptime=00:00:35.686]




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

Re: Using EntryProcessor arguments recommendations


Hi,

I suggest to read the documentation:

EntryProcessor:

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheEntry.html
Invoke java doc:

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke-K-org.apache.ignite.cache.CacheEntryProcessor-java.lang.Object...-

CacheAtomicityMode specific:

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheAtomicityMode.html

Note, that using invoke and invokeAll you will block the keys. It means 
that deadlock is possible in the following cases:


1)You use external keys inside EntryProcessor
2)Use unordered maps for invokeAll. TreeMap is suggested.

BR,
Andrei

2/12/2020 12:18 AM, Григорий Доможиров пишет:

I see two options of using EntryProcessor:
1. Pass arguments like this:
cache.invoke(key, new CustomProcessor(), someValue)
2. Pass stateful EntryProcessor like this:
  cache.invoke(key, new CustomProcessor(someValue))

Is there any recommendations?

Re: JDBC thin client incorrect security context