Re: What are minimal thread pools for grid clients?

[rick_tem]

Thanks for your reply.  Can you answer the 2nd part of the question?

1) UtilityCachePoolSize do and do I care about it if I am a client?
2) ManagementPoolSize do and do I care about it if I am a client?
3) QueryTheadPool (documented) but do I need it on a client?

Would be helpful if these could be documented on the threadpools page
previously mentioned.

Thanks,
Rick



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

What are minimal thread pools for grid clients?

[rick_tem]

Hi,

I am on 2.7.5 version and using the same Spring configuration for both
servers and thick clients.  I do not want to use thin client as I want my
client to be part of the grid.  What I have come to learn is that even if 
Ignition.setClientMode(true); or conf.setClientMode(true); some thread pools
are created that really shouldn't be.  For example, if a cache is configured
for write-behind, with , 32 flusher threads will be created on the client, where the
flushing will only ever happen on the server if I am not mistaken.  So
thread pool creation seems to disregard whether or not I am a client.

In order to trim my client threads, I now load the Spring configuration, and
do the following below.  I have also noticed that if you don't give at least
one thread to the pool, for example IFGS, Ignite will not start and
complains that cnt must be > 0.  Several thread pools in the configuration
aren't documented here (https://apacheignite.readme.io/docs/thread-pools),
so what does:

1) UtilityCachePoolSize do and do I care about it if I am a client?
2) ManagementPoolSize do and do I care about it if I am a client?
3) QueryTheadPool (documented) but do I need it on a client?

It would be helpful if documentation could be added for the missing pools
above and also what the minimal client configuration should be as to
minimize client memory footprint and resource usage.

Thanks!
Rick

conf.setClientMode(true);
// For clients disable as many threads as we can.
Boolean disableConnectorConfig =
Boolean.parseBoolean(TAFJCacheFactory.getCacheProperties().getProperty(CacheConstants.KEY_PROP_IGNITE_CLIENT_DISABLE_CONNECTOR_CONFIG,
CacheConstants.DEFAULT_IGNITE_CLIENT_DISABLE_CONNECTOR_CONFIG));
if(disableConnectorConfig) {
conf.setConnectorConfiguration(null);
}
// Public Thread pool used for compute grid.
   
conf.setPublicThreadPoolSize(Integer.parseInt(TAFJCacheFactory.getCacheProperties().getProperty(CacheConstants.KEY_PROP_IGNITE_CLIENT_PUBLIC_TP_SIZE,
CacheConstants.DEFAULT_IGNITE_CLIENT_PUBLIC_TP_SIZE)));
// Minimum must be one.
   
conf.setDataStreamerThreadPoolSize(Integer.parseInt(TAFJCacheFactory.getCacheProperties().getProperty(CacheConstants.KEY_PROP_IGNITE_CLIENT_DATA_STREAMER_TP_SIZE,
CacheConstants.DEFAULT_IGNITE_CLIENT_DATA_STREAMER_TP_SIZE)));
// Minimum must be one.
   
conf.setIgfsThreadPoolSize(Integer.parseInt(TAFJCacheFactory.getCacheProperties().getProperty(CacheConstants.KEY_PROP_IGNITE_CLIENT_IGFS_TP_SIZE,
CacheConstants.DEFAULT_IGNITE_CLIENT_IGFS_TP_SIZE)));
   
conf.setServiceThreadPoolSize(Integer.parseInt(TAFJCacheFactory.getCacheProperties().getProperty(CacheConstants.KEY_PROP_IGNITE_CLIENT_SERVICE_TP_SIZE,
CacheConstants.DEFAULT_IGNITE_CLIENT_SERVICE_TP_SIZE)));
conf.setDataStorageConfiguration(null);
List configs =
Arrays.asList(conf.getCacheConfiguration());
for(CacheConfiguration config : configs) {
if(config.isWriteBehindEnabled()) {
config.setWriteBehindFlushThreadCount(1);
}
}



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

RE: Data region LRU offheap algo not working

[rick_tem]

Hi,

I have created the following JIRA for this issue.

IGNITE-12215

Thanks,
Rick



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

RE: Data region LRU offheap algo not working

[rick_tem]

Hi, 

Please find enclosed the memory crash with the following configuration along
with the data region metrics just before the crash.  This should be easy to
reproduce.  Simply keep injecting data into the cache at a high rate with a
small data region size.

Thanks,
Rick












 


Ignite-dataregion.png

  
Ignite.log
  



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

RE: Data region LRU offheap algo not working

[rick_tem]

Thanks for your reply Alexandr.

However, looking at the log, memory continues to be lost.  You continue to
see loss of memory after this message:
2019-09-09 11:04:03.557 WARN  [sys-stripe-5-#6%TemenosGrid%]
IgniteCacheDatabaseSharedManager - Page-based evictions started. Consider
increasing 'maxSize' on Data Region configuration: 1G_Region

Log is: 
http://apache-ignite-users.70518.x6.nabble.com/file/t869/dateRepo1.out

While not in this log, this eventually causes an out of memory issue stack
trace that is unrecoverable.  I'll get the log that shows that and turn on
the metrics to get better information.  It's pretty easy for me to
reproduce.

Thanks,
Rick








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

RE: Topology snapshot explanation

[rick_tem]

Hi,

So you are saying clients too are using the data region settings and
reserving gigs of data for offheap (if gigs of data are configured) even if
I don't have near-cache configured?  I am using the same Spring
configuration for clients and servers, can I override that behavior at
runtime?  

Thanks,
Rick



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

Topology snapshot explanation

[rick_tem]

Hello,

I am wondering why offheap/heap memory continues to grow as the topology
shapshot evolves.  It must be client and server included.  Why is it being
reported for client?  Why would a client use offheap?  

Thanks,
Rick

event-processor_1| [16:01:08] Topology snapshot [ver=5,
locNode=91131045, servers=1, clients=4, state=ACTIVE, CPUs=20,
offheap=11.0GB, heap=9.0GB]
event-processor_1| [16:01:08] Topology snapshot [ver=6,
locNode=91131045, servers=1, clients=5, state=ACTIVE, CPUs=24,
offheap=13.0GB, heap=10.0GB]
event-processor_1| [16:01:08] Topology snapshot [ver=7,
locNode=91131045, servers=1, clients=6, state=ACTIVE, CPUs=28,
offheap=15.0GB, heap=11.0GB]
event-processor_1| [16:01:08] Topology snapshot [ver=8,
locNode=91131045, servers=1, clients=7, state=ACTIVE, CPUs=32,
offheap=17.0GB, heap=12.0GB]
event-processor_1| [16:01:11] Performance suggestions for grid
'TemenosGrid' (fix if possible)
event-processor_1| [16:01:11] To disable, set
-DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
event-processor_1| [16:01:11]   ^-- Disable grid events (remove
'includeEventTypes' from configuration)
event-processor_1| [16:01:11]   ^-- Set max direct memory size if
getting 'OOME: Direct buffer memory' (add
'-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
event-processor_1| [16:01:11]   ^-- Disable processing of calls to
System.gc() (add '-XX:+DisableExplicitGC' to JVM options)
event-processor_1| [16:01:11]   ^-- Decrease number of backups (set
'backups' to 0)
event-processor_1| [16:01:11] Refer to this page for more
performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
event-processor_1| [16:01:11]
event-processor_1| [16:01:11] To start Console Management &
Monitoring run ignitevisorcmd.{sh|bat}
event-processor_1| [16:01:11] Data Regions Configured:
event-processor_1| [16:01:11]   ^-- default [initSize=256.0 MiB,
maxSize=1.7 GiB, persistence=false]
event-processor_1| [16:01:11]   ^-- 1G_Region [initSize=100.0 MiB,
maxSize=500.0 MiB, persistence=false]
event-processor_1| [16:01:11]
event-processor_1| [16:01:11] Ignite node started OK (id=91131045,
instance name=TemenosGrid)
event-processor_1| [16:01:11] Topology snapshot [ver=4,
locNode=91131045, servers=1, clients=3, state=ACTIVE, CPUs=16,
offheap=8.7GB, heap=8.0GB]
event-processor_1| [16:01:26] Topology snapshot [ver=9,
locNode=91131045, servers=1, clients=8, state=ACTIVE, CPUs=36,
offheap=20.0GB, heap=13.0GB]
event-processor_1| [16:01:28] Topology snapshot [ver=10,
locNode=91131045, servers=1, clients=9, state=ACTIVE, CPUs=40,
offheap=22.0GB, heap=14.0GB]



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

Re: Cache expiry policy not deleting records from disk(native persistence)

[rick_tem]

This is very troublesome.  Persistence will kill your disk and LRU doesn't
seem to work for offheap with persistence disabled (see "Data region LRU
offheap algo not working")It seems the only way to expire items is to
keep it on heap with an expiry policy

Regards,
Rick



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

Re: Data region LRU offheap algo not working

[rick_tem]

Hi, it's in the log 2.7.5...Thanks for any help here!
Thanks,
Rick



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

Data region LRU offheap algo not working

[rick_tem]

Hi,

I am trying to find out why it appears the RANDOM_LRU algo doesn't seem to
work with the following config.  Log attached, as well...after the log of
the below...

2019-09-09 11:04:03.557 WARN  [sys-stripe-5-#6%TemenosGrid%]
IgniteCacheDatabaseSharedManager - Page-based evictions started. Consider
increasing 'maxSize' on Data Region configuration: 1G_Region

after a few minutes you see memory steadily decrease.  What information in
the log will help me determine how many pages are freed, etc?

Thanks,
Rick

dateRepo1.out
  
dataRepo2.out
  

























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

Re: Thick client/thin client difference and how to get thin client port

[rick_tem]

Thanks for your response.  I tried 10801 and it failed.  My question is how
do I find out which port it is using?

Thanks,
Rick



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

Thick client/thin client difference and how to get thin client port

[rick_tem]

Hi,

I am seeing that a thin client cannot reconnect (on the same port) after a
server shutdown.  I have 1 backup enabled and load some data in the cache on
startup.  Replication procedure is:
1) Start server 1
2) Try thin client --> it retrieves data
3) Start server 2
4) Kill server 1 (Server 2 output below)
5) Try thin client --> fails with :
org.apache.ignite.client.ClientConnectionException: Ignite cluster is
unavailable
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
~[ignite-core-2.7.5.jar:2.7.5]
6) Try thick client --> works fine

Almost certainly this is due to the connection port for the thin client (as
server 2 thin client listener cannot start on the same port).  But how do I
discover which port is opened on server 2 for thin clients?

Thanks,
Rick

Server 2
[08:51:40] Topology snapshot [ver=2, locNode=3da900bd, servers=2, clients=0,
state=ACTIVE, CPUs=4, offheap=9.3GB, heap=7.9GB]
StartIgnite-->Ignite Initialization.  Got cache Tables from Ignite.
[08:51:56] Topology snapshot [ver=3, locNode=3da900bd, servers=1, clients=0,
state=ACTIVE, CPUs=4, offheap=4.6GB, heap=4.0GB]
[08:51:56] Coordinator changed [prev=TcpDiscoveryNode
[id=ae5f19f3-2cfe-477b-b16d-4d12fb95aaad, addrs=[10.0.75.1, 127.0.0.1,
172.27.252.225, 192.168.1.123, 192.168.32.1],
sockAddrs=[/172.27.252.225:47500, /10.0.75.1:47500, /127.0.0.1:47500,
/192.168.32.1:47500, L2SG9M32.europe.temenosgroup.com/192.168.1.123:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1561704688821,
loc=false, ver=2.7.5#20190603-sha1:be4f2a15, isClient=false],
cur=TcpDiscoveryNode [id=3da900bd-79b3-4b49-a0d4-4b6cbe134b54,
addrs=[10.0.75.1, 10.30.200.76, 127.0.0.1, 172.27.252.225, 192.168.1.123,
192.168.32.1],
sockAddrs=[L2SG9M32.europe.temenosgroup.com/192.168.1.123:47501,
L2SG9M32.mshome.net/172.27.252.225:47501, /10.30.200.76:47501,
/127.0.0.1:47501, /192.168.32.1:47501, /10.0.75.1:47501], discPort=47501,
order=2, intOrder=2, lastExchangeTime=1561704716259, loc=true,
ver=2.7.5#20190603-sha1:be4f2a15, isClient=false]]



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

Re: Ignite client failing in indexing

[rick_tem]

Hi Ilya,

Thanks for your reply but it doesn't really answer my question.  What's a
client doing in indexing code trying to drop a cache?  I don't see why a
client would be in any indexing code.

Thanks,
Rick



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

Ignite client failing in indexing

[rick_tem]

Hi, 

We are running Ignite 2.7.5 and received the following error with an Ignite
client.  What I don't understand is why it appears to be trying to drop my
cache if it is a client and why it is messing around with any indexing if a
client.  Is there a way around this error?  We are not using persistence. 
Any insight appreciated. 

Thanks, 
Rick 

IgniteH2Indexing - Failed to drop schema on cache stop (will ignore):
FDataEventCache 
event-router_1   | 2019-06-24T19:07:49.029838093Z
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
execute statement: DROP SCHEMA IF EXISTS "FDataEventCache" 


Full stack trace 

event-router_1   | 2019-06-24T19:07:15.737563399Z
[19:07:15] (wrn) Failed to resolve IGNITE_HOME automatically for class
codebase [class=class o.a.i.i.util.IgniteUtils, e=URI is not hierarchical] 
event-router_1   | 2019-06-24T19:07:15.737563499Z 
event-router_1   | 2019-06-24T19:07:16.056472666Z
[19:07:16]__   
event-router_1   | 2019-06-24T19:07:16.056515767Z
[19:07:16]   /  _/ ___/ |/ /  _/_  __/ __/ 
event-router_1   | 2019-06-24T19:07:16.056524167Z
[19:07:16]  _/ // (7 7// /  / / / _/   
event-router_1   | 2019-06-24T19:07:16.056530967Z
[19:07:16] /___/\___/_/|_/___/ /_/ /___/   
event-router_1   | 2019-06-24T19:07:16.056612268Z
[19:07:16] 
event-router_1   | 2019-06-24T19:07:16.056622468Z
[19:07:16] ver. 2.7.5#20190603-sha1:be4f2a15 
event-router_1   | 2019-06-24T19:07:16.056629868Z
[19:07:16] 2018 Copyright(C) Apache Software Foundation 
event-router_1   | 2019-06-24T19:07:16.056637268Z
[19:07:16] 
event-router_1   | 2019-06-24T19:07:16.056644668Z
[19:07:16] Ignite documentation: http://ignite.apache.org
event-router_1   | 2019-06-24T19:07:16.056651968Z
[19:07:16] 
event-router_1   | 2019-06-24T19:07:16.056658968Z
[19:07:16] Quiet mode. 
event-router_1   | 2019-06-24T19:07:16.080533928Z
[19:07:16]   ^-- Logging by 'Log4JLogger [quiet=true, config=null]' 
event-router_1   | 2019-06-24T19:07:16.080574228Z
[19:07:16]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
or "-v" to ignite.{sh|bat} 
event-router_1   | 2019-06-24T19:07:16.080584528Z
[19:07:16] 
event-router_1   | 2019-06-24T19:07:16.080593028Z
[19:07:16] OS: Linux 3.10.0-862.9.1.el7.x86_64 amd64 
event-router_1   | 2019-06-24T19:07:16.080601829Z
[19:07:16] VM information: OpenJDK Runtime Environment 1.8.0_151-b12 Oracle
Corporation OpenJDK 64-Bit Server VM 25.151-b12 
event-router_1   | 2019-06-24T19:07:16.129002955Z
[19:07:16] Initial heap size is 504MB (should be no less than 512MB, use
-Xms512m -Xmx512m). 
event-router_1   | 2019-06-24T19:07:16.306281782Z
[19:07:16] Configured plugins: 
event-router_1   | 2019-06-24T19:07:16.306354983Z
[19:07:16]   ^-- WhiteListSecurity 1.0.0 
event-router_1   | 2019-06-24T19:07:16.306383384Z
[19:07:16]   ^-- Temenos 
event-router_1   | 2019-06-24T19:07:16.306390584Z
[19:07:16] 
event-router_1   | 2019-06-24T19:07:16.311492439Z
[19:07:16] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
[tryStop=false, timeout=0, super=AbstractFailureHandler
[ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT 
event-router_1   | 2019-06-24T19:07:16.665959693Z
[19:07:16] 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. 
event-router_1   | 2019-06-24T19:07:16.909769544Z
[19:07:16] Security status [authentication=off, tls/ssl=off] 
event-router_1   | 2019-06-24T19:07:18.129403106Z
[19:07:18] REST protocols do not start on client node. To start the
protocols on client node set '-DIGNITE_REST_START_ON_CLIENT=true' system
property. 
event-router_1   | 2019-06-24T19:07:48.679876788Z
[19:07:48] Topology snapshot [ver=16, locNode=95065a31, servers=1,
clients=7, state=ACTIVE, CPUs=48, offheap=44.0GB, heap=13.0GB] 
event-router_1   | 2019-06-24T19:07:48.698074685Z
[19:07:48] Topology snapshot [ver=17, locNode=95065a31, servers=1,
clients=8, state=ACTIVE, CPUs=56, offheap=51.0GB, heap=14.0GB] 
event-router_1   | 2019-06-24T19:07:48.702450233Z
[19:07:48] Topology snapshot [ver=18, locNode=95065a31, servers=1,
clients=7, state=ACTIVE, CPUs=56, offheap=51.0GB, heap=14.0GB] 
event-router_1   | 2019-06-24T19:07:48.743392078Z
[19:07:48] Topology snapshot [ver=19, locNode=95065a31, servers=1,
clients=6, state=ACTIVE, CPUs=56, offheap=51.0GB, heap

Spring Indexing example

[rick_tem]

Hi,
With the below index definition, is there a way to sort createdTime
descending and processedTime ascending?  What would the definition look
like?

Thanks!
Rick





recId

createdTime

processedTime

partitionId








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

Re: Do we require to set MaxDirectMemorySize JVM parameter?

[rick_tem]

Oh, that is great.  I wasn't aware of that.  Thanks for the link!



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

Re: Do we require to set MaxDirectMemorySize JVM parameter?

[rick_tem]

Yes, we have a similar reluctance to use persistent store.  Ouruse case is
that Gigs of data will be running through it with several caches that we
don't necessarily want to keep around in a docker environment.  Some caches,
however, we would like persistent.  Is there a plan to have persistence
configurable at the cache level, or will it be all or nothing in the
forseeable future?



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

Re: Do elements with EternalExpiryPolicy in cache ever get evicted?

[rick_tem]

Hi,

Does anyone know the answer to this?

Thanks!



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

Do elements with EternalExpiryPolicy in cache ever get evicted?

[rick_tem]

Hi,

I am on Ignite version 2.5, not using Ignite persistence, and I have some
data in a cache which I want to keep around in memory so I've set up an
EternalExpiryPolicy on the particular cache.  Will this stay in memory then
so my cache queries will work (provided I have enough memory)?  I really
don't want elements in this cache evicted.  I assume cache queries will not
work as anticipated if some elements are evicted and one is not using Ignite
persistence.

Thanks for your response,
Rick



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

Re: Custom CacheStoreAdapter implementation - fields are null

[rick_tem]

I put my shared per-thread stuff in thread local and reference it from
CacheStoreAdapter.  That will hopefully work for you.  For example, I have
connections I want to re-use within the same transaction and don't want them
returned to the pool until the transaction ends.  That means multiple
put-->write calls until I finally get a sessionEnd() call with write-through
cache.

Best,
Rick



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

Re: Custom CacheStoreAdapter implementation - fields are null

[rick_tem]

Could be because there are two instances of your cacheStore created?  At
least that's what I see in the debugger with my particular CacheStoreAdapter
in version 2.0.  Could you break in the constructor and see if that is the
case?  I had an issue with static and noticed two instances being created.

Best,
Rick



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

Write Behind Performance

[rick_tem]

Hi,
I'm trying to find information on write behind performance and I found this
thread:

http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-td5385.html

The thread says:

"As Denis pointer out, you should tune write-behind parameters to make sure
that background threads are working at sufficient insert rate. Also make
sure that you use batched inserts in your CacheStore implementation.

Hope this helps,
AG"

I've done that in my CacheStore implementation.  So my questions are:

1)  How can I monitor the queue size?  Is there a way to do that?  I want to
be able to see when it is backing up due to the database taking too much
time.
2)  Do you have any suggested parameters if the database can handle inserts
at a high pace?  I would imagine you would want writeBehindBatchSize to be
very large if doing batch inserts and writeBehindFlushFrequency to be not so
frequent (a second?) Are the defaults the best to use or would you suggest
something else?

Thanks for any suggestions.  As well, if you could point me to any other
performance links overall I'd appreciate it.

Best,
Rick



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

Re: work around for problem where ignite query does not include objects added into Cache from within a transaction

[rick_tem]

Okay, thank you.  Nice to know it is under development.

Best,
Rick



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

Re: work around for problem where ignite query does not include objects added into Cache from within a transaction

[rick_tem]

I see that as a huge problem.  Certainly one of the functions of Ignite is to
be faster than the database, but if it fails to meet all of the requirements
of what a database will do for you, what is the point of using it? Clearly a
database will keep read consistency between transactions.  Most applications
I've worked with require that as well.  If I understand correctly, this hole
makes querying the grid almost useless as I can't count it being consistent.



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

Write-Behind Cache configuration and custom cache store

[rick_tem]

Hi,

I am using Ignite 2.0.0 with a cache configurations shown below.  First, I
noticed that writeAll() or any write() was not called on my cache store when
writeBehindEnabled=true but writeThrough=false.  Seems like if
writeBehindEnabled set to true, it should override writeThrough, but anyway,
I got around that.  With my writeBehind cache now calling writeAll() in my
cache store I noticed sessionEnd() is not called even when my cache is
TRANSACTIONAL.  Does this mean I have to call commit() on the connection at
the end of writeAll()?  How would I then differentiate a call to writeAll()
from putAll()?  It seems like sessionEnd() should be called when a flush
occurs if I am specifying a TRANSACTIONAL cache.  Is this a bug?  I am not
explicitly using transactions (i.e. try (Transaction tx =
transactions.txStart()) )...When I just use write through caching,
sessionEnd() is called without an explicit transaction and as well behaves
in a JTA environment.

Thanks for any clarification.

Best,
Rick













 



















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

Re: Why is custom cacheStore.write() being called in clientMode?

[rick_tem]

Thanks to Ilya and Nikolai for your replies...Okay, as long as I can
guarantee a consistent transaction should be fine...I will look into
org.apache.ignite.lifecycle.LifecycleAware for my other problem.  Thanks!



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Why-is-custom-cacheStore-write-being-called-in-clientMode-tp13309p13453.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Why is custom cacheStore.write() being called in clientMode?

[rick_tem]

Hi Nikolai,

Thanks for your reply.  It is appreciated!  Thanks for your answer to 2) I
will look into it. 3) and 4) are really the same issue I am trying to
understand how it works.

With regards to 1) below, we aren't speaking about distributed databases,
but distributed caches that are java JVMs.  But isn't that what a JTA
transaction manager is supposed to do?  ie handle distributed transactions?
if I enlist MQ and Jboss in the same transaction that is two seperate JVMs
and I believe should work with one atomic transaction...

But regardless, I believe this is what you are saying here:  Please correct
me if I am wrong.  Say I have keys 1, 2, 3 on node 1 and keys 4, 5, 6 on
node 2.  What you are saying is that I cannot update keys 2 and 4 in the
same transaction, correct?  This is because they live in two different
JVMs...If this is the case, that is a severe limitation as then I need to
know which node my data is on.  What would your recommendation be here then
for write-through cache?  Have everything replicated?  It is a requirement
that the transaction be rock solid in whatever model I implement.  I cannot
afford to lose writes or have half-committed data.

Thanks,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Why-is-custom-cacheStore-write-being-called-in-clientMode-tp13309p13424.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Why is custom cacheStore.write() being called in clientMode?

[rick_tem]

Hi Yakov,

Thanks for you reply, it is appreciated, but I still have questions.

When you say: 1) we don't have an option to write-through from dht nodes? 
What is a dht node?  Are you saying I can't write my own write-through cache
store?
2) I agree that initialization isn't the best in loadCache.  But how do I
then do it?  It is Ignite that is creating this class and the cache returned
from ignite.getCache is not an instance of my class.
3) Client mode seems inconsistent.  It is not calling loadCache() as
expected but why would it call write()...It should be a proxy to the server
node, not acting as a server.
4) Are you saying Ignite does not keep transactional state consistent across
nodes for write-through?  For any cache store?  Even JDBC cache store?

Thanks,
Rick
 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Why-is-custom-cacheStore-write-being-called-in-clientMode-tp13309p13317.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Why is custom cacheStore.write() being called in clientMode?

[rick_tem]

I'm sorry, what you are saying doesn't make sense.  I don't want a near
cache.  I'm not sure why it is a near cache.  I haven't specified that
anywhere in the config.  It is showing up as a client in the topology.  You
are saying it isn't possible to write your own write-through cacheStore?

Thanks,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Why-is-custom-cacheStore-write-being-called-in-clientMode-tp13309p13314.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Why is custom cacheStore.write() being called in clientMode?

[rick_tem]

Hello,

I have a written a cache store and started it up on one node and call
loadCache() and the output is shown below.

public class IgniteXMLClobCacheStoreimplements CacheStore { 

}

IgniteXMLClobCacheStore::loadCache Loading: LAYOUT
IgniteXMLClobCacheStore::loadCache Loading: RISK
IgniteXMLClobCacheStore::loadCache Loading: TOP_ACCOUNT
IgniteXMLClobCacheStore::loadCache finished loading. Now listening...
[11:27:14] Topology snapshot [ver=2, servers=1, clients=1, CPUs=4,
heap=1.3GB]

I start another in client mode (see above topology snapshot), in this case
loadCache() is not called (as expected), however write() is called.  I
eventually get a null pointer as something isn't initialized when I call
loadCache.  In the stack trace below it looks like it is treating it as a
nearCache.  Shouldn't write() be called on my server node and not my client? 
If I am doing something wrong, how then would I then initialize something as
this object is created by Ignite and I can't pass it via loadCache() since
it isn't called in client mode.  ie,








 

[ERROR] 2017-06-01 11:27:42,652 [sys-stripe-3-#4%TemenosGrid%] CACHE -
IgniteXMLClobCacheStore::Error in write with Key: BLA*RANK
java.lang.NullPointerException: null
at
com.temenos.tafj.cache.impl.IgniteXMLClobCacheStore.write(IgniteXMLClobCacheStore.java:451)
[TAFJCache.jar:18.1.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.put(GridCacheStoreManagerAdapter.java:568)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.putAll(GridCacheStoreManagerAdapter.java:609)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.batchStoreCommit(IgniteTxAdapter.java:1326)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:500)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3021)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:405)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$16.apply(GridNearTxLocal.java:3171)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$16.apply(GridNearTxLocal.java:3163)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:494)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:473)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:295)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:273)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:72)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:278)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:148)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
[ignite-core-2.0.0.jar:2.0.0]
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
[ignite

Re: Correct Way to Store Data

[rick_tem]

As well, for companies that have a large number of tables (as does ours),
using a cache per table would probably not be ideal.

Best,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Correct-Way-to-Store-Data-tp13163p13187.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Transaction management with Jboss and Ignite

[rick_tem]

Hi,

I'm trying to enlist an Ignite transaction in a different JVM with the
Transaction Manager for Jboss 7 EAP JVM up and running for write-through
cache.  

My transaction configuration is shown below which I found from a previous
thread.  I know this is configured correctly because I see the lookup trying
to occur on the strings [java:comp/TransactionManager,
java:appserver/TransactionManager, java:pm/TransactionManager,
java:/TransactionManager] in CacheJndiTmFactory.  They all fail after
creating the InitialContext and then doing the lookup.  On further
investigation I found that the java:/TransactionManager is not exposed
remotely in Jboss.  So my question (which I'll probably have to take to the
Jboss people) is: has anyone done this before and if so the steps to do it? 
Other appserver instructions for Websphere and Weblogic would also be
helpful.  I imagine this should be a common question for those using app
servers alongside Ignite.  As well, will my datasources in the remote Ignite
JVM be automatically enlisted in the transaction if they are XA?  I imagine
they should be.

Thanks for any help!


  














*Cache Config is as follows.*













 




















--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Transaction-management-with-Jboss-and-Ignite-tp12976.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: PutIfAbsent issues

[rick_tem]

Hi Andrey,

Yes, I figured out what this issue was and it was not Ignite related.

Thanks for your reply.

Best,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/PutIfAbsent-issues-tp12633p12876.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

PutIfAbsent issues

[rick_tem]

Hi,

I am using Ignite 2.0 and wondering if there are any known putIfAbsent(key,
value) issues where on occassion the value on a subsequent get(key) on
another thread will come back null when a value was actually put in the
cache.  If not, I'll try to reproduce it.  My cache setup is as follows.

   








I have 2 servers and 1 client up.

Best,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/PutIfAbsent-issues-tp12633.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite Version 2.0 startup H2 error

[rick_tem]

Hi Denis,

It's probably because when I remove my H2 dependency from my maven pom it
gives me H2 version 173 (probably from the parent maven pom) so I have to
explicitly tell which version to use where I'm building caching.

Thanks,
Rick




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Version-2-0-startup-H2-error-tp12532p12542.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite Version 2.0 startup H2 error

[rick_tem]

Hi Andrey,

Great.  Thanks.  Updating to H2 1.4.195 did the trick.  I searched through
the docs and could not find where H2 version is mentioned, but thanks!

Best,
Rick




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Version-2-0-startup-H2-error-tp12532p12539.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite Version 2.0 startup H2 error

[rick_tem]

Hi,

I am trying to move from 1.9 to 2.0 version of Ignite and running into the
following error.  My maven dependency for H2 is as follows.  According to
the doc here https://apacheignite.readme.io/v2.0/docs/maven-setup H2 isn't
part of the dependencies, but if it is removed an error on RowSet is seen. 
Has the maven dependency for H2 moved for 2.0?  Any idea what could cause
this?  Finally, correct me if I'm wrong, but isn't Ignite reliant on a
particular H2 version?


com.h2database
h2
1.4.191
provided


Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 21.891 sec
<<< FAILURE! - in 
java.lang.AssertionError: Failure in testIgniteCache: Failed to initialize
DB connection: jdbc:h2:mem:3b272f8f-cc82-4cfa-83bd-5131ad613f1e;LOCK_MODE=3
;MULTI_THREADED=1;DB_CLOSE_ON_EXIT=FALSE;DEFAULT_LOCK_TIMEOUT=1;FUNCTIONS_IN_SCHEMA=true;OPTIMIZE_REUSE_RESULTS=0;QUERY_CACHE_SIZE=0;RECOMPILE_ALW
AYS=1;MAX_OPERATION_MEMORY=0;NESTED_JOINS=0;BATCH_JOINS=1;ROW_FACTORY="org.apache.ignite.internal.processors.query.h2.opt.GridH2RowFactory";DEFAULT_TA
BLE_ENGINE=org.apache.ignite.internal.processors.query.h2.opt.GridH2DefaultTableEngine
at org.junit.Assert.fail(Assert.java:88)

Thanks,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Version-2-0-startup-H2-error-tp12532.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Thanks Andrey.  I'll see how it behaves when 2.0 comes out in a few weeks.

Thanks again and kind regards,
Rick




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IgniteCacheProxy-connection-failure-in-REPLICATAED-mode-tp11769p12235.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Veracode identifies Insufficient Entropy issue in Apache Ignite Classes

[rick_tem]

Hi,

Yes, I'm aware that you can use SSL.  That only secures data going between
nodes, however.  Haven't tried it yet, but it isn't going to help you with
seeing all the values in the cache through Visor.

Best,
Rick
 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Veracode-identifies-Insufficient-Entropy-issue-in-Apache-Ignite-Classes-tp12159p12233.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Veracode identifies Insufficient Entropy issue in Apache Ignite Classes

[rick_tem]

We've implemented our own security plugin.  But that doesn't protect you if
you start Ignite from $IGNITE_HOME/bin with Ignite.sh and haven't configured
a plugin.  The node will start fine and bypass it.  One of the problems with
Ignite is that I can connect with Visor without any security and see all of
the values in a cache.  My question would be:  What does Ignite team
recommend in terms of security?  Certainly, I think you want to use known
hosts and known ports, but is there anything else one could do besides
writing a plugin?

Best,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Veracode-identifies-Insufficient-Entropy-issue-in-Apache-Ignite-Classes-tp12159p12201.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Hi Andrey,

Yes, it is directly after I stop the Ignite node.  The output is from the
Jboss console (where the other Ignite server node is running in the same
JVM) and is the full stack trace before our proprietary code calling
remove().  We are not calling any transaction within our proprietary code,
simply cache.remove(key).  Would it help if I try to reproduce with a test
case?  Should I try changing anything with the below config?

Thanks,
Rick






























--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IgniteCacheProxy-connection-failure-in-REPLICATAED-mode-tp11769p12191.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Hey Andre,

Here's what the stack trace looks like inside jboss.

Topology snapshot [ver=46, servers=1, clients=2, CPUs=8, heap=7.1GB]

2017-04-20 11:23:41,575 ERROR [stderr] (tSA 6_1968933222) [11:23:41] (err)
*Failed to execute compound future reducer: GridNearTxFinishFuture*
[futId=bcd3eba8b51-55bc7836-f114-41d7-b0d0-44a14beb441f, tx=GridNearTxLocal
[mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
[entries=[IgniteTxEntry [key=KeyCacheObjectImpl
[val=FBNK_STATIC_CHANGE_000*360494.0008100.01, hasValBytes=true],
cacheId=-1750629716, partId=-1, txKey=IgniteTxKey [key=KeyCacheObjectImpl
[val=FBNK_STATIC_CHANGE_000*360494.0008100.01, hasValBytes=true],
cacheId=-1750629716], val=[op=DELETE, val=null], prevVal=[op=NOOP,
val=null], oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl
[val=FBNK_STATIC_CHANGE_000*360494.0008100.01, hasValBytes=true], val=null,
startVer=1492681260390, ver=GridCacheVersion [topVer=104082481,
time=1492680221503, order=1492681260390, nodeOrder=44], hash=-852679692,
extras=null, flags=0]]], prepared=0, locked=false,
nodeId=b992bdfd-1f6e-45d0-ac6e-de4c1355eb34, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=104082481,
time=1492680221502, order=1492681260388, nodeOrder=44]]],
explicitLock=false, dhtVer=null, last=false, near=false, clientFirst=false,
node=b992bdfd-1f6e-45d0-ac6e-de4c1355eb34]], nearLocallyMapped=false,
colocatedLocallyMapped=false, needCheckBackup=false, hasRemoteLocks=false,
thread=tSA 6_1968933222, mappings=IgniteTxMappingsSingleImpl
[mapping=GridDistributedTxMapping [entries=[IgniteTxEntry
[key=KeyCacheObjectImpl [val=FBNK_STATIC_CHANGE_000*360494.0008100.01,
hasValBytes=true], cacheId=-1750629716, partId=-1, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [val=FBNK_STATIC_CHANGE_000*360494.0008100.01,
hasValBytes=true], cacheId=-1750629716], val=[op=DELETE, val=null],
prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
explicitVer=null, dhtVer=null, filters=[], filtersPassed=false,
filtersSet=true, entry=GridDhtDetachedCacheEntry
[super=GridDistributedCacheEntry [super=GridCacheMapEntry
[key=KeyCacheObjectImpl [val=FBNK_STATIC_CHANGE_000*360494.0008100.01,
hasValBytes=true], val=null, startVer=1492681260390, ver=GridCacheVersion
[topVer=104082481, time=1492680221503, order=1492681260390, nodeOrder=44],
hash=-852679692, extras=null, flags=0]]], prepared=0, locked=false,
nodeId=b992bdfd-1f6e-45d0-ac6e-de4c1355eb34, locMapped=false,
expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=null, xidVer=GridCacheVersion [topVer=104082481,
time=1492680221502, order=1492681260388, nodeOrder=44]]],
explicitLock=false, dhtVer=null, last=false, near=false, clientFirst=false,
node=b992bdfd-1f6e-45d0-ac6e-de4c1355eb34]], super=GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true],
super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=104082481,
time=1492680221502, order=1492681260388, nodeOrder=44], writeVer=null,
implicit=true, loc=true, threadId=391, startTime=1492680221473,
nodeId=9e9758d1-8dbf-44e2-8181-6f9b454cf61c, startVer=GridCacheVersion
[topVer=104082481, time=1492680221502, order=1492681260388, nodeOrder=44],
endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion
[topVer=104082481, time=1492680221502, order=1492681260388, nodeOrder=44],
finalizing=NONE, preparing=false, invalidParts=null, state=PREPARED,
timedOut=false, topVer=AffinityTopologyVersion [topVer=45, minorTopVer=0],
duration=95ms, onePhaseCommit=true], size=1]]], commit=true,
mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
[entries=[IgniteTxEntry [key=KeyCacheObjectImpl
[val=FBNK_STATIC_CHANGE_000*360494.0008100.01, hasValBytes=true],
cacheId=-1750629716, partId=-1, txKey=IgniteTxKey [key=KeyCacheObjectImpl
[val=FBNK_STATIC_CHANGE_000*360494.0008100.01, hasValBytes=true],
cacheId=-1750629716], val=[op=DELETE, val=null], prevVal=[op=NOOP,
val=null], oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=[], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl
[val=FBNK_STATIC_CHANGE_000*360494.0008100.01, hasValBytes=true], val=null,
startVer=1492681260390, ver=GridCacheVersion [topVer=104082481

Re: What is the difference between starting a node using Java application, and manual starting?

[rick_tem]

Is that entirely true?  Plugins don't start when you simply just start Ignite
with Ignite.bat or Ignite.sh unless you package your particular class among
the Ignite jars and add an org.apache.ignite.plugin.Pluginprovider file to
META-INF/services.  Or am I missing something.

Best,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/What-is-the-difference-between-starting-a-node-using-Java-application-and-manual-starting-tp12143p12157.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Hi Andrey,

Thanks for you response.  Still seems to be problematic.  See below.  Any
idea when 2.0 will be available?  Recall I had one Ignite as a client in
Jboss and two Ignite servers.  What I've done is force the Jboss into a
server, and start one other Ignite instance (two Ignite server nodes, 0
clients).  Now when I kill the Ignite node, I did get some exceptions in the
Jboss console and at least once I had some remove cache operations fail.  I
don't believe this should happen in replicated mode and assume this is the
same bug.  So to get around that, I catch any exception around the
cache.remove(key) and retry, but since, I haven't been able to reproduce it. 
I'll try to see if I can write a test case for it.  Regardless, whether
client or server, I think we shouldn't expect failures in replicated mode
with the below config, correct?  Oracle Coherence doesn't fail when you take
down a node in replicated mode.

Thanks,
Rick























C:\java\GitHub\ignite1.9\ignite-1.9\modules [ignite-1.9 ≡ +20 ~14 -0 !]> git
apply --verbose --check 4473.patch
Checking patch
modules/core/src/main/java/org/apache/ignite/internal/IgniteNeedReconnectException.java...
error: while searching for:

error: patch failed:
modules/core/src/main/java/org/apache/ignite/internal/IgniteNeedReconnectException.java:0
error:
modules/core/src/main/java/org/apache/ignite/internal/IgniteNeedReconnectException.java:
patch does not apply
Checking patch
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java...
error: while searching for:
return ignite().configuration().getSslContextFactory() != null;
}

/**
 * FOR TEST ONLY!!!
 */

error: patch failed:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:1933
error:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java:
patch does not apply
Checking patch
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteClientReconnectTestSuite.java...
error: while searching for:
import org.apache.ignite.internal.IgniteClientReconnectServicesTest;
import org.apache.ignite.internal.IgniteClientReconnectStopTest;
import org.apache.ignite.internal.IgniteClientReconnectStreamerTest;

/**
 *

error: patch failed:
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteClientReconnectTestSuite.java:29
error:
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteClientReconnectTestSuite.java:
patch does not apply
Checking patch
modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java...
error: while searching for:
/** Periodic starvation check interval. */
private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30;

/** */
@GridToStringExclude
private GridKernalContextImpl ctx;

error: patch failed:
modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java:253
error:
modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java:
patch does not apply
Checking patch
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java...
error: while searching for:
throw new UnsupportedOperationException();
}

/** {@inheritDoc} */
@Override protected IgniteSpiThread workerThread() {
return msgWorker;

error: patch failed:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java:1589
error:
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java:
patch does not apply
Checking patch
modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectCacheTest.java...
error: while searching for:
try {
   
Ignition.start(optimize(getConfiguration(getTestGridName(SRV_CNT;

fail();

return false;
}
catch (IgniteClientDisconnectedException e) {
log.info("Expected start error: " + e);

error: patch failed:
modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectCacheTest.java:700
error:
modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectCacheTest.java:
pat

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Hi,

I appreciate the last response to this.  I've checked out the 1.9 branch
(ie. git clone -b ignite-1.9 --single-branch
https://github.com/apache/ignite.git ignite-1.9)...I'm new to github so bear
with me.  In seeing if this patch will apply, I get the following error. 
I'm not exactly sure why.  Is there a procedure somewhere of how to apply
patches?  As well, any documentation links for beginner contributors would
be appreciated.

Thanks!

C:\java\GitHub\ignite1.9\ignite-1.9\modules [ignite-1.9 ≡ +1 ~0 -0 !]> git
apply --check IGNITE_4473___Client_should_re_
try_connection_attempt_in_case_of_concurrent_network_failur.patch
error: patch failed:
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeMa
nager.java:1836
error:
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java:
pa
tch does not apply
error: patch failed:
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtAssig
nmentFetchFuture.java:17
error:
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtAssignmentFetchFutu
re.java: patch does not apply
*error: patch failed:
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/Gr
idDhtPartitionsExchangeFuture.java:54*
error:
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartition
sExchangeFuture.java: patch does not apply



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IgniteCacheProxy-connection-failure-in-REPLICATAED-mode-tp11769p12030.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Thanks Andrey.  I'll figure out how to patch the branch and give it a try.

Appreciate it.

Best,
Rick




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IgniteCacheProxy-connection-failure-in-REPLICATAED-mode-tp11769p11819.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

IgniteCacheProxy connection failure in REPLICATAED mode

[rick_tem]

Hi,

I have a cache configuration that looks like this:




















I've started two Ignite servers and within JBOSS application server set
Ignition.setClientMode(true); such that I have 2 servers and 1 client
(JBOSS) shown in my topology.  When I then terminate one of the Ignite
servers, I receive the following exception below when my JBOSS app is
manipulating the cache.  If I am in REPLICATED mode, why doesn't the Ignite
proxy try the other server automatically on connection failure?  Is there a
mechanism I should use to protect against connection failure, or how should
I ensure (in this case a remove operation on the cache) my actions complete
successfully?

Thanks!
Rick

Caused by: org.apache.ignite.IgniteClientDisconnectedException: Client node
disconnected: TGrid
... 88 more
[ERROR] 2017-04-05 14:11:35,675 [tSA 4_1037028145] LOCKING - IgniteCache
Error 
javax.cache.CacheException: class
org.apache.ignite.IgniteClientDisconnectedException: Client node
disconnected: TGrid
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.checkState(GridCacheGateway.java:92)
~[ignite-core-1.9.0.jar!/:1.9.0]
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:173)
~[ignite-core-1.9.0.jar!/:1.9.0]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:2264)
~[ignite-core-1.9.0.jar!/:1.9.0]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.remove(IgniteCacheProxy.java:1463)
~[ignite-core-1.9.0.jar!/:1.9.0]




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IgniteCacheProxy-connection-failure-in-REPLICATAED-mode-tp11769.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite Logger error

[rick_tem]

Hi,

I have the following code where log4JFile is a valid log4j2 conf file...If
however, ignite-log4j2-1.9.0.jar is not copied into the CLASSPATH, I never
hit the exception below...The program aborts with ClassNotFound.  The java
doc says this should throw an IgniteCheckedException in case "logger can't
be created".  I consider this a bug.  Do you agree? Ignite version is 1.9


try {
log = new
org.apache.ignite.logger.log4j2.Log4J2Logger(log4JFile);
conf.setGridLogger(log);
} catch (Exception e) {
// In version 1.9 this exception not caught.
logger.error("Failed instantiating Ignite logger.  Is
the ignite-log4j2 jar in your classpath?", e);
}

Thanks,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Logger-error-tp11702.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: SecurityContext in Ignite

[rick_tem]

SecurityContext is an interface (and doesn't appear to be in the JavaDoc). 
What implements it that I should create?

Thanks,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/SecurityContext-in-Ignite-tp10353p10357.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

SecurityContext in Ignite

[rick_tem]

Hi,

I'm new to Ignite.  I'm creating a WhiteListSecurityProcessor and it is all
working fine, but when authorize is being called, I get a null
SecurityContext.  Debugging I found that it is null coming from
GridCacheContext...Is this a bug?

public void checkSecurity(SecurityPermission op) throws
SecurityException {
if (CU.isSystemCache(name()))
return;

ctx.security().authorize(name(), op, *null*);
}

I am aware of GridGain, but want to create my own plugin as we have our own
security needs...All of the documentation out on the net is dated..Is there
anywhere I set this up in the Spring configuration?  Below is the stacktrace
up to the authorize call

Thread [TEST_FBNK_CURRENCY_109548147] (Suspended (breakpoint at line 182 in
WhiteListSecurityProcessor))
WhiteListSecurityProcessor.authorize(String, SecurityPermission,
SecurityContext) line: 182  
GridCacheContext.checkSecurity(SecurityPermission) line: 735   
GridDhtAtomicCache.get(K, String, boolean, boolean) line: 468  
GridDhtAtomicCache(GridCacheAdapter).get(K, boolean, boolean)
line: 4783  
GridDhtAtomicCache(GridCacheAdapter).get(K) line: 1395
IgniteCacheProxy.get(K) line: 1118 




Thanks,
Rick



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/SecurityContext-in-Ignite-tp10353.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.