Best Practises for upgrading Ignite versions

[Anand Mehta]

Hi,
We are going to upgrade our Ignite Distributed Clusters from version 2.1 to
version 2.5.3 .
Are there are guidelines on the best practices of upgrading the cluster with
minimal downtime / data loss? 
Is the standard practice to shut down the entire cluster, upgrade and
restart?

Thanks,
Anand



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

Re: Flink Streamer Compatibility.

[Anand Vijai]

Thank you so much for this.

Is there an example demonstrating how the cache is accessible?
Do we have to start a separate client node to inspect the cache and its
contents?




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

Re: Flink Streamer Compatibility.

[Anand Vijai]

Is there a working example of how the integration works to sink Flink data
into an Ignite Cache?



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

Re: Failed to connect to any address from IP finder

[anand]

Thanks @vkulichenko. 
I have tried that earlier giving range from 47000..48000. I will try it
again and update here.
For now, I have updated ignite version to 2.6.0 and it' working fine. Though
I would love to know what was issue with 2.5.0.

Best.
Anand



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

Failed to connect to any address from IP finder

[anand]

Hi All,
I have been through all related thread before posting this message. I'm
facing this issue while running application on CentOS but working fine in
MacOS. any help would be great.

issue: Failed to connect to any address from IP finder (will retry to
join topology every 2000 ms; change 'reconnectDelay' to configure the
frequency of retries): [/127.0.0.1:47500, /172.20.98.77:47500]
   
Details: both the client and server running on same machine. Client node
started using java code while server node started using ignite.sh. please
find attached log.
 
client debug log :   client-debug.log
<http://apache-ignite-users.70518.x6.nabble.com/file/t1938/client-debug.log>  
client info log :  client-info.log
<http://apache-ignite-users.70518.x6.nabble.com/file/t1938/client-info.log>  
client config :  client-config.client-config
<http://apache-ignite-users.70518.x6.nabble.com/file/t1938/client-config.client-config>
  

server log :   server-debug.log
<http://apache-ignite-users.70518.x6.nabble.com/file/t1938/server-debug.log>  
server config :  server-config.server-config
<http://apache-ignite-users.70518.x6.nabble.com/file/t1938/server-config.server-config>
  

Best.
Anand
  








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

Re: Retrieving keys very slow from a partitioned, no backup, no replicated cache

[Anand Vijai]

Hi Alexey,

You are correct. I did not have my own CacheStore implementation.

I am currently writing my own implementation and using the below when
creating the cache:
cfgAcct.setCacheStoreFactory(FactoryBuilder.factoryOf(CacheJDBCAcctFactStore.class));

In the example code we are talking about, can you tell me how writeall will
be called? 
when the entry.setvalue() is called within Cache.invoke?


Regards,
Anand Vijai



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

Re: Retrieving keys very slow from a partitioned, no backup, no replicated cache

[Anand Vijai]

Thank you Alexei!

I have configured my cache with the following properties:
ccfg.setReadThrough(true);
ccfg.setWriteThrough(true);
ccfg.setWriteBehindEnabled(true);
ccfg.setWriteBehindBatchSize(1);
ccfg.setStoreKeepBinary(true);

Even though the batch size is defined as 1, I can see that the updates
are trickled to the DB as soon as the entry.setValue is called.
My update throughput is around 100-200 records/sec. 
Any pointers on this.



Regards,
Anand Vijai



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

Re: Retrieving keys very slow from a partitioned, no backup, no replicated cache

[Anand Vijai]

Hi Alexey,

Thank you for the response.
I changed my code based on your recommendation and i think with all the
different options I was trying I ended up with a sub-par code!
The below code does the update very fast (few secs)


   Collection res = ignite.compute().broadcast(
new IgniteCallable() {
/** Auto-inject ignite instance. */
@IgniteInstanceResource
private Ignite ignite;

@Override public Integer call() {
IgniteCache cache =
ignite.getOrCreateCache("Fact");
Iterator> iterator =
cache.localEntries().iterator();

FactKey key;
Integer cnt = 0;
while (iterator.hasNext()) {
key = iterator.next().getKey();

cache.invoke(key, (entry, args) -> {
Fact val = entry.getValue();
// do some logic
val.setAmount(val.getAmt1() +
val.getAmt2());
return val;
});
cnt++;
if(cnt%100 == 0) {
System.out.println(">>> Update Count: " +
cnt);
}
}
return cnt;
}
}
);


In regards to your comment on cache will not get updated using invoke. How
do I ensure that the new computed value gets stored in the cache. 
The first goal is to iterate through the cache and update a specific data
field in the cache in the fastest way possible. 
The second goal is to - the cache has writethrough/writebehind enabled and
hence the updates will need to be propagated to the database as well.





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

Re: Retrieving keys very slow from a partitioned, no backup, no replicated cache

[Anand Vijai]

Hi Andrew,


I did try with the Iterator implementation using iterator.hasNext() (you can
see that its commented in the code i shared) but the performance is only
slightly higher (hence gave the range 10-100 keys per second)

Do you want me to try to use a cursor explicitly instead of using an
iterator.
I need to go through all the keys and perform the computation.


Regards
Anand Vijai



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

Retrieving keys very slow from a partitioned, no backup, no replicated cache

[Anand Vijai]

I have a cache with approx 1MM rows and is partitioned across 3 server nodes.
I am trying to retrieve all the keys from the cache and then trying to
perform an update operation using cache.invoke.
The cache.invoke itself is very fast but the retrieval of the keys takes a
lot of time - approximately 10-100 keys per second is the throughput I am
getting.
The cache has 15 fields and 4 of them are defined as key fields and are
indexed but since I am using Scanquery i am guessing that the indexes arent
used?

What is the best/correct way to retrieve all keys and perform an update to
the cache within the server nodes without returning any data back to the
client node. 

Originally i had iterated through the iterator one key at a time and thought
the update operation was taking time. But i changed the code to create a
keyset first and then did a cache.invoke in separate blocks of code as
below:

// Execute the query.
Iterator> iterator =
cache.query(scanQuery).iterator();
Set KEYS_SET = new HashSet();
FactKey key = new FactKey();
Fact val = null;
ExecutionTimer t = new ExecutionTimer(); // this is just to track
time taken in seconds
t.start();

for (int i = 0; i < cache.size(CachePeekMode.ALL); i++) {
//while (iterator.hasNext()) {
key = iterator.next().getKey();

KEYS_SET.add(iterator.next().getKey());

if(i%1000 == 0)
{
System.out.println(">>> Update Count: " + i);
t.end();
System.out.println("Time taken for: " + i + " " + t.duration());
t.start();
cache.invokeAll(KEYS_SET, (entry, args) -> {
val = entry.getValue();
val.setAmount(val.getAmt1() + val.getAmt2());
;
return null;
});
KEYS_SET.clear();
System.out.println(">>> Updating ADB: " + i);
t.end();
System.out.println("Timer for cache invoke: " + t.duration());
t.start();
}



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

unsubscribe

[Anand Kumar Sankaran]

Re: SPI has already been started (always create new configuration instance for each starting Ignite instances) Error

[Anand Kumar Sankaran]

Hi Val

Got it.  Thanks.


On 8/29/16, 1:24 PM, "vkulichenko" <valentin.kuliche...@gmail.com> wrote:

Anand,

Copy constructor does not make a deep copy, so instances of SPIs is the
same. This is by design, because I'm not sure this is even possible in
general case (SPIs can be provided by users and in this case we know nothing
about them - sounds risky). I would not recommend to use copy constructor in
user code at all, but always construct a new instance instead.

-Val



--
View this message in context: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_SPI-2Dhas-2Dalready-2Dbeen-2Dstarted-2Dalways-2Dcreate-2Dnew-2Dconfiguration-2Dinstance-2Dfor-2Deach-2Dstarting-2DIgnite-2Dinstar-2Dtp7360p7385.html=DQICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc=NxR9R85X95K_GPN2S2Tcp9z3UPm9snUYcHLszxZfss4=Kt_GyKHT_IY3dtLQMifmSsyD5uEiBCSJfaw9RM_6E0M=
 
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: failureDetectionTimeout tuning

[Anand Kumar Sankaran]

http://apacheignite.gridgain.org/v1.7/docs/cluster-config#failure-detection-timeout

Most likely a hardware or network issue (or your node could be very busy as 
well).


On 8/29/16, 8:54 AM, "bintisepaha"  wrote:

We see this message logged in our logs from time to time. Is this a 
potential
issue with one of the nodes? 


[tcp-disco-sock-reader-#41%DataGridServer-Staging%] ERROR
(Log4JLogger.java:495) Failed to initialize connection
[sock=Socket[addr=/10.22.50.193,port=35612,localport=47501]]
class org.apache.ignite.spi.IgniteSpiOperationTimeoutException: Network
operation timed out. Increase 'failureDetectionTimeout' configuration
property [failureDetectionTimeout=1]
at

org.apache.ignite.spi.IgniteSpiOperationTimeoutHelper.nextTimeoutChunk(IgniteSpiOperationTimeoutHelper.java:81)
at

org.apache.ignite.spi.discovery.tcp.ServerImpl$SocketReader.body(ServerImpl.java:5035)
at
org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)

How do you recommend fixing it? We are not using networkDetection or
failureDetection timeout yet in our configs.

This is what we have
 



  
  



Thanks,
Binti



--
View this message in context: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_failureDetectionTimeout-2Dtuning-2Dtp7374.html=DQICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc=cM4HLc8iuz3WYqm2spb6ArVFF13MZgY5kaWXaY3gVWU=PBK9WPMK9Qc5uFqsoylEQRbsOGL93Y2oWiBfNckRRb4=
 
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Simulating network outage in tests

[Anand Kumar Sankaran]

Hi

I am implementing a segmentation resolver to handle split brain scenarios.  I 
need to simulate network outages to unit test this behavior.  Any suggestions 
on how to simulate this?  I see that the TcpDiscoverySpi has timeouts, is there 
a way to mock TcpDiscoverySpi to think that there is a network outage to 
simulate such conditions?

Thanks.

--
anand

Re: SPI has already been started (always create new configuration instance for each starting Ignite instances) Error

[Anand Kumar Sankaran]

Hi Vladislav

Thanks.  I got this to work by re-constructing the IgniteConfiguration.  
However, the Javadoc of the IgniteConfiguration copy constructor is incorrect 
or there is a bug in the copy constructor.  I will create a JIRA.

http://ignite.apache.org/releases/1.0.0/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#IgniteConfiguration(org.apache.ignite.configuration.IgniteConfiguration)

--
anand

From: Vladislav Pyatkov <vldpyat...@gmail.com>
Reply-To: "user@ignite.apache.org" <user@ignite.apache.org>
Date: Monday, August 29, 2016 at 2:00 AM
To: "user@ignite.apache.org" <user@ignite.apache.org>
Subject: Re: SPI has already been started (always create new configuration 
instance for each starting Ignite instances) Error

Hello Anand,

Ignite configuration is not reusable, because SPI stores data in internal 
fields. You can made copy of configuration before first start of Ignite 
instance.

I see a solution do it, using Spring scope bean attribute (if youuse Spring 
configuration) like this:



On Sun, Aug 28, 2016 at 7:19 PM, Anand Kumar Sankaran 
<anand.sanka...@workday.com<mailto:anand.sanka...@workday.com>> wrote:
Hi

I am coding a segmentation resolver that’s restarting Ignite in the case of a 
Segmentation Event.

I copy the current Ignite Configuration and use it to start a new Ignite.


this.ignite.close();

final org.apache.ignite.configuration.IgniteConfiguration copy = new 
org.apache.ignite.configuration.IgniteConfiguration(this.config);


this.ignite = Ignition.start(copy);


This still fails with the following message:

java.lang.IllegalStateException: SPI has already been started (always create 
new configuration instance for each starting Ignite instances) 
[spi=TcpCommunicationSpi 
[connectGate=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$ConnectGateway@7106a8d2,
 
srvLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2@240b62af, 
locAddr=null, 
locHost=0.0.0.0/0.0.0.0<https://urldefense.proofpoint.com/v2/url?u=http-3A__0.0.0.0_0.0.0.0=DQMFaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc=OzHCeE6fHmkLcfV-YDXzlidXXHsqe7e-YZH1O2wOGyM=DvDpKrtPZ6iJAk_aKX200UfNd6wYKuHgxCQodbGSwoc=>,
 locPort=16500, locPortRange=50, shmemPort=-1, directBuf=true, 
directSndBuf=false, idleConnTimeout=3, connTimeout=5000, 
maxConnTimeout=60, reconCnt=10, sockSndBuf=32768, sockRcvBuf=32768, 
msgQueueLimit=1024, slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, 
tcpNoDelay=true, ackSndThreshold=16, unackedMsgsBufSize=0, 
sockWriteTimeout=2000, lsnr=null, boundTcpPort=-1, boundTcpShmemPort=-1, 
selectorsCnt=2, addrRslvr=null, rcvdMsgsCnt=103, sentMsgsCnt=105, 
rcvdBytesCnt=134129, sentBytesCnt=214242, 
ctxInitLatch=java.util.concurrent.CountDownLatch@6bc31a98[Count = 0], 
stopping=true, 
metricsLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3@57e640a9]]
at 
org.apache.ignite.spi.IgniteSpiAdapter.onBeforeStart(IgniteSpiAdapter.java:129)
   at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:217)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:243)
at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1478)
at 
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:828)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1740)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1590)
at 
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1043)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:570)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:517)
at org.apache.ignite.Ignition.start(Ignition.java:322)


How can I restart an Ignite with the same configuration in such a case?

--
anand



--
Vladislav Pyatkov

SPI has already been started (always create new configuration instance for each starting Ignite instances) Error

[Anand Kumar Sankaran]

Hi

I am coding a segmentation resolver that’s restarting Ignite in the case of a 
Segmentation Event.

I copy the current Ignite Configuration and use it to start a new Ignite.


this.ignite.close();

final org.apache.ignite.configuration.IgniteConfiguration copy = new 
org.apache.ignite.configuration.IgniteConfiguration(this.config);


this.ignite = Ignition.start(copy);


This still fails with the following message:

java.lang.IllegalStateException: SPI has already been started (always create 
new configuration instance for each starting Ignite instances) 
[spi=TcpCommunicationSpi 
[connectGate=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$ConnectGateway@7106a8d2,
 
srvLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2@240b62af, 
locAddr=null, locHost=0.0.0.0/0.0.0.0, locPort=16500, locPortRange=50, 
shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=3, 
connTimeout=5000, maxConnTimeout=60, reconCnt=10, sockSndBuf=32768, 
sockRcvBuf=32768, msgQueueLimit=1024, slowClientQueueLimit=0, nioSrvr=null, 
shmemSrv=null, tcpNoDelay=true, ackSndThreshold=16, unackedMsgsBufSize=0, 
sockWriteTimeout=2000, lsnr=null, boundTcpPort=-1, boundTcpShmemPort=-1, 
selectorsCnt=2, addrRslvr=null, rcvdMsgsCnt=103, sentMsgsCnt=105, 
rcvdBytesCnt=134129, sentBytesCnt=214242, 
ctxInitLatch=java.util.concurrent.CountDownLatch@6bc31a98[Count = 0], 
stopping=true, 
metricsLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3@57e640a9]]
at 
org.apache.ignite.spi.IgniteSpiAdapter.onBeforeStart(IgniteSpiAdapter.java:129)
   at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:217)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:243)
at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1478)
at 
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:828)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1740)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1590)
at 
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1043)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:570)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:517)
at org.apache.ignite.Ignition.start(Ignition.java:322)


How can I restart an Ignite with the same configuration in such a case?

--
anand

cluster node attribute based authorization

[Anand Kumar Sankaran]

All

I implemented a ClusterNode.userAttributes() based authorization mechanism.  I 
used a JWT Token to establish trust (passed via the userAttribute). This works 
fine.

The problem I have is that the JWT Token expires shortly after initial use.  
Now, if the node leaves the cluster and joins it again, the JWT Token in that 
node would be invalid.

How should I fix this?  Is there a callback I can implement when a node leaves 
a cluster that I can use to create a new JWT token and attach to it?

Any guidance would be appreciated.

--
anand

Re: Custom GridSecurityProcessor plugin question

[Anand Kumar Sankaran]

Hi Denis

Thanks!

I was doing two things wrong.

GridSecurityProcessor.enabled() was returning false and my security processor 
implemented both DiscoverySpiNodeAuthenticator and GridSecurityProcessor

Once I fixed both, authenticateNode was getting called.

I think for my requirements (prevent a node from joining and not fine grained 
entitlement), validateNode is sufficient (and using ClusterNode.attribute to 
pass in parameters).  A quick test along those lines seem to work.

I need to add a few comments to 
http://smartkey.co.uk/development/securing-an-apache-ignite-cluster explaining 
this.

--
anand

From: Denis Magda <dma...@gridgain.com>
Reply-To: "user@ignite.apache.org" <user@ignite.apache.org>
Date: Monday, May 16, 2016 at 6:13 AM
To: "user@ignite.apache.org" <user@ignite.apache.org>
Subject: Re: Custom GridSecurityProcessor plugin question

Hi Anand,

GridSecurityProcessor.authenticateNode(…) has to be called on your side. Please 
double check that GridSecurityProcessor.enabled() returns true. If it returns 
true then your GridSecurityProcessor will be registered in 
GridDiscoveryManager.start() method.

If this doesn’t happen please debug GridDiscoveryManager.start() method at the 
place when discovery SPI authenticator is set and places where 
DiscoverySpiNodeAuthenticator.authenticateNode is used and share the results 
with us.

—
Denis

On May 16, 2016, at 12:01 AM, Anand Kumar Sankaran 
<anand.sanka...@workday.com<mailto:anand.sanka...@workday.com>> wrote:

I went past this.  Turns out if everything is ok, validateNode has to return 
null ☹.

That brings me to another question.  validateNode callback only provides us 
with the ClusterNode. We were thinking the information needed to let a node 
join the cluster or not would be part of a custom SecurityCredentials object, 
which is available only at the authenticateNode level and not the validateNode.

If I want to prevent a node from joining the cluster, and if validateNode is 
the way to do it, should I add custom node attributes to ClusterNode and use 
that information?

--
thanks

anand

From: Anand Kumar Sankaran 
<anand.sanka...@workday.com<mailto:anand.sanka...@workday.com>>
Reply-To: "user@ignite.apache.org<mailto:user@ignite.apache.org>" 
<user@ignite.apache.org<mailto:user@ignite.apache.org>>
Date: Friday, May 13, 2016 at 10:22 PM
To: "user@ignite.apache.org<mailto:user@ignite.apache.org>" 
<user@ignite.apache.org<mailto:user@ignite.apache.org>>
Subject: Custom GridSecurityProcessor plugin question

Hi

I following the instructions in 
http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/<https://urldefense.proofpoint.com/v2/url?u=http-3A__smartkey.co.uk_development_securing-2Dan-2Dapache-2Dignite-2Dcluster_=CwMGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc=01Qixfyc18kKvq_I--s3PC9YgCsFRGlWT2LbskWFrqg=xLqLvdGDPFbP4OEHKMwhhYU4FuLd638U4oQ0YZ12IUI=>
 and implemented a custom GridSecurityProcessor plugin.  I got Ignite to 
recognize the custom provider and the provider is returning my custom 
GridSecurityProcessor like this:

@Nullable
@Override
@SuppressWarnings("unchecked")
public  T createComponent(PluginContext ctx, Class cls) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
called for class " + cls.toString());
if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning TenantGroupSecurityProcessor");
return (T) new TenantGroupSecurityProcessor();
}
else {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning null");
return null;
}
}

All is fine when the first node starts up.  When the second node starts up, 
TenantGroupSecurityProcessor.authenticateNode does not get called, but 
TenantGroupSecurityProcessor.validateNode gets called which is implemented like 
this:


@Nullable
@Override
public IgniteNodeValidationResult validateNode(ClusterNode node) {
System.out.println("TenantGroupSecurityProcessor:validateNode called");
return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access 
Denied");
}


Because of this, the second node is unable to join the cluster and it dies.

[22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: 
GridManagerAdapter [enabled=true, 
name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
  at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
 

Re: Custom GridSecurityProcessor plugin question

[Anand Kumar Sankaran]

I went past this.  Turns out if everything is ok, validateNode has to return 
null ☹.

That brings me to another question.  validateNode callback only provides us 
with the ClusterNode. We were thinking the information needed to let a node 
join the cluster or not would be part of a custom SecurityCredentials object, 
which is available only at the authenticateNode level and not the validateNode.

If I want to prevent a node from joining the cluster, and if validateNode is 
the way to do it, should I add custom node attributes to ClusterNode and use 
that information?

--
thanks

anand

From: Anand Kumar Sankaran <anand.sanka...@workday.com>
Reply-To: "user@ignite.apache.org" <user@ignite.apache.org>
Date: Friday, May 13, 2016 at 10:22 PM
To: "user@ignite.apache.org" <user@ignite.apache.org>
Subject: Custom GridSecurityProcessor plugin question

Hi

I following the instructions in 
http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/<https://urldefense.proofpoint.com/v2/url?u=http-3A__smartkey.co.uk_development_securing-2Dan-2Dapache-2Dignite-2Dcluster_=CwMGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc=01Qixfyc18kKvq_I--s3PC9YgCsFRGlWT2LbskWFrqg=xLqLvdGDPFbP4OEHKMwhhYU4FuLd638U4oQ0YZ12IUI=>
 and implemented a custom GridSecurityProcessor plugin.  I got Ignite to 
recognize the custom provider and the provider is returning my custom 
GridSecurityProcessor like this:

@Nullable
@Override
@SuppressWarnings("unchecked")
public  T createComponent(PluginContext ctx, Class cls) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
called for class " + cls.toString());
if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning TenantGroupSecurityProcessor");
return (T) new TenantGroupSecurityProcessor();
}
else {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning null");
return null;
}
}

All is fine when the first node starts up.  When the second node starts up, 
TenantGroupSecurityProcessor.authenticateNode does not get called, but 
TenantGroupSecurityProcessor.validateNode gets called which is implemented like 
this:


@Nullable
@Override
public IgniteNodeValidationResult validateNode(ClusterNode node) {
System.out.println("TenantGroupSecurityProcessor:validateNode called");
return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access 
Denied");
}


Because of this, the second node is unable to join the cluster and it dies.

[22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: 
GridManagerAdapter [enabled=true, 
name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
  at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
  at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
  at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
  at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1485)
  at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
  at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
  at org.apache.ignite.Ignition.start(Ignition.java:346)
  at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Access Denied
  at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:1627)
  at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:879)
  at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:328)
  at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1815)
  at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:252)
  ... 13 more

Why isn’t the authenticateNode callback did not get called back?  Did I miss 
anything?

Thanks for the help.

--
anand

Custom GridSecurityProcessor plugin question

[Anand Kumar Sankaran]

Hi

I following the instructions in 
http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/ and 
implemented a custom GridSecurityProcessor plugin.  I got Ignite to recognize 
the custom provider and the provider is returning my custom 
GridSecurityProcessor like this:

@Nullable
@Override
@SuppressWarnings("unchecked")
public  T createComponent(PluginContext ctx, Class cls) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
called for class " + cls.toString());
if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning TenantGroupSecurityProcessor");
return (T) new TenantGroupSecurityProcessor();
}
else {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning null");
return null;
}
}

All is fine when the first node starts up.  When the second node starts up, 
TenantGroupSecurityProcessor.authenticateNode does not get called, but 
TenantGroupSecurityProcessor.validateNode gets called which is implemented like 
this:


@Nullable
@Override
public IgniteNodeValidationResult validateNode(ClusterNode node) {
System.out.println("TenantGroupSecurityProcessor:validateNode called");
return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access 
Denied");
}


Because of this, the second node is unable to join the cluster and it dies.

[22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: 
GridManagerAdapter [enabled=true, 
name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
  at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
  at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
  at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
  at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1485)
  at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
  at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
  at org.apache.ignite.Ignition.start(Ignition.java:346)
  at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Access Denied
  at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:1627)
  at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:879)
  at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:328)
  at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1815)
  at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:252)
  ... 13 more

Why isn’t the authenticateNode callback did not get called back?  Did I miss 
anything?

Thanks for the help.

--
anand