Re: Ignite client node raises "Sequence was removed from cache" after Ignite Server node restarts

[xmw45688]

Hi Ilya,

Tried your suggestion, removing the userSeq field from the class.  It still
raise the same exception -
org.apache.ignite.IgniteException: Cannot start/stop cache within lock
or transaction.
 
The error is thrown when trying to get igniteInstance.atomicLong("userSeq",
maxId, true); 

Thanks.



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

Feature request: method to test active connection in Ignite thin client

[Scott Prater]

Hello,

I'm a new Ignite user, and with just a little bit of exposure, I'm quite
impressed with it -- it did not take me long to get a single standalone
remote node up and running and start using it as a durable memory key-value
store.

I created a connection pool for ClientCache in Java, using Apache Commons
Pool 2.  So far it's working well, but I had to fudge overriding the
commons-pool2 "validateObject()" method, which is a method to test that
your pooled object is still alive and well:  I used
clientCache.getName().equals("MY_CACHE") as a test, but I have no idea if
this indicates whether the connection to my remote cache is active or not.

In some future release, could you add a "isConnected()" method or similar
to ClientCache or IgniteClient (if it makes more sense there), for ease of
testing connections and determining when to discard bad client objects?

thanks,

-- Scott

Re: Map 10 caches to 10 different ignite nodes

[Denis Magda]

Take a look at this documentation

page that share a bit more detail on how to use the node filters.

-
Denis


On Fri, Sep 11, 2020 at 5:19 AM abhi2703  wrote:

> Thanks a lot Vladimir, that's exactly what I was searching for.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: ClusterGroupEmptyException: Topology projection is empty.

[Michael Cherkasov]

visor, WebConsole or ControlCenter use the same mechanisms for cluster
monitoring, so if you use any of it see such kind of errors, you can ignore
them, they are harmless for your cluster.

чт, 10 сент. 2020 г. в 06:42, kay :

> Hello,
>
> I don't use Visor for cluster monitoring.. then Why that log is showing
> up..?
>
>
> Thank you so much!
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Ignite Segmentation Behaviour

[Michael Cherkasov]

BTW,  you can try zookeeper discovery, I think it's the easier way to
resolve split-brain problem:
https://www.gridgain.com/docs/latest/developers-guide/clustering/zookeeper-discovery

пт, 11 сент. 2020 г. в 14:13, Michael Cherkasov :

> Make sure first you stop all nodes in one segment and only then start
> them, rolling restart might not fix cluster segmentation.
>
>
> пт, 11 сент. 2020 г. в 09:08, Denis Magda :
>
>> Hi Samuel,
>>
>> With the current behavior, the segments will not rejoin automatically.
>> Once the network is recovered from a network partitioning event, you need
>> to restart all the nodes of one of the segments. Those nodes will join the
>> other nodes and the cluster will become fully operational.
>>
>> Let me know if you have any other questions or guidance with this.
>>
>> -
>> Denis
>>
>>
>> On Fri, Sep 11, 2020 at 7:38 AM Samuel Ueltschi <
>> samuel.uelts...@bsi-software.com> wrote:
>>
>>> Hi
>>>
>>>
>>>
>>> I've been testing Ignite (2.8.1) and it's behaviour under network
>>> segmentation.
>>>
>>> According to the docs, Ignite nodes should be able to detect network
>>> segmentation and apply the configured SegmentationPolicy.
>>>
>>>
>>>
>>> However the segmentation handling didn't trigger as I would have
>>> expected it to do.
>>>
>>> For my tests, I setup three cluster nodes c1, c2 and c3 running in
>>> docker containers, all competing for a shared IgniteLock instance in a loop.
>>>
>>> Then I used iptables in container c2 to drop all incoming and outgoing
>>> packages on that node.
>>>
>>> After a few seconds I got the following events:
>>>
>>>
>>>
>>> c1:
>>>
>>> - EVT_NODE_FAILED for c2
>>>
>>>
>>>
>>> c2:
>>>
>>> - EVT_NODE_FAILED for c1
>>>
>>> - EVT_NODE_FAILED for c3
>>>
>>>
>>>
>>> c3:
>>>
>>> - EVT_NODE_FAILED for c2
>>>
>>>
>>>
>>> Then I reset the iptables rules expecting that c2 would rejoin the
>>> cluster and detect segmentation.
>>>
>>> However this didn't happen, c2 just keeps running as a second standalone
>>> cluster instance.
>>>
>>> Only after restarting c2 it rejoined the cluster.
>>>
>>>
>>>
>>> Eventually I was able to trigger the EVT_NODE_SEGMENTED event by pausing
>>> the c2 container for 1minute. After resuming, c2 detects the segmentation
>>> and runs the segmentation policy as excepcted.
>>>
>>>
>>>
>>> Is this behaviour correct? Shouldn't the Ignite cluster be able to
>>> recover from the first scenario?
>>>
>>> During a network segmentation no packages would be able to move between
>>> nodes, so the iptables approach should be realistic in my oppinion.
>>>
>>>
>>>
>>> Maybe I have some wrong assumptions about network segmentation so any
>>> feedback would be greatly appreciated.
>>>
>>>
>>>
>>> Cheers Sam
>>>
>>>
>>>
>>> --
>>> Software Engineer
>>> BSI Business Systems Integration AG
>>> Erlachstrasse 16B, CH-3012 Bern
>>> Telefon +41 31 850 12 06
>>>
>>> www.bsi-software.com
>>>
>>>
>>>
>>

Re: Ignite Segmentation Behaviour

[Michael Cherkasov]

Make sure first you stop all nodes in one segment and only then start them,
rolling restart might not fix cluster segmentation.


пт, 11 сент. 2020 г. в 09:08, Denis Magda :

> Hi Samuel,
>
> With the current behavior, the segments will not rejoin automatically.
> Once the network is recovered from a network partitioning event, you need
> to restart all the nodes of one of the segments. Those nodes will join the
> other nodes and the cluster will become fully operational.
>
> Let me know if you have any other questions or guidance with this.
>
> -
> Denis
>
>
> On Fri, Sep 11, 2020 at 7:38 AM Samuel Ueltschi <
> samuel.uelts...@bsi-software.com> wrote:
>
>> Hi
>>
>>
>>
>> I've been testing Ignite (2.8.1) and it's behaviour under network
>> segmentation.
>>
>> According to the docs, Ignite nodes should be able to detect network
>> segmentation and apply the configured SegmentationPolicy.
>>
>>
>>
>> However the segmentation handling didn't trigger as I would have expected
>> it to do.
>>
>> For my tests, I setup three cluster nodes c1, c2 and c3 running in docker
>> containers, all competing for a shared IgniteLock instance in a loop.
>>
>> Then I used iptables in container c2 to drop all incoming and outgoing
>> packages on that node.
>>
>> After a few seconds I got the following events:
>>
>>
>>
>> c1:
>>
>> - EVT_NODE_FAILED for c2
>>
>>
>>
>> c2:
>>
>> - EVT_NODE_FAILED for c1
>>
>> - EVT_NODE_FAILED for c3
>>
>>
>>
>> c3:
>>
>> - EVT_NODE_FAILED for c2
>>
>>
>>
>> Then I reset the iptables rules expecting that c2 would rejoin the
>> cluster and detect segmentation.
>>
>> However this didn't happen, c2 just keeps running as a second standalone
>> cluster instance.
>>
>> Only after restarting c2 it rejoined the cluster.
>>
>>
>>
>> Eventually I was able to trigger the EVT_NODE_SEGMENTED event by pausing
>> the c2 container for 1minute. After resuming, c2 detects the segmentation
>> and runs the segmentation policy as excepcted.
>>
>>
>>
>> Is this behaviour correct? Shouldn't the Ignite cluster be able to
>> recover from the first scenario?
>>
>> During a network segmentation no packages would be able to move between
>> nodes, so the iptables approach should be realistic in my oppinion.
>>
>>
>>
>> Maybe I have some wrong assumptions about network segmentation so any
>> feedback would be greatly appreciated.
>>
>>
>>
>> Cheers Sam
>>
>>
>>
>> --
>> Software Engineer
>> BSI Business Systems Integration AG
>> Erlachstrasse 16B, CH-3012 Bern
>> Telefon +41 31 850 12 06
>>
>> www.bsi-software.com
>>
>>
>>
>

Re: Ignite Segmentation Behaviour

[Denis Magda]

Hi Samuel,

With the current behavior, the segments will not rejoin automatically. Once
the network is recovered from a network partitioning event, you need to
restart all the nodes of one of the segments. Those nodes will join the
other nodes and the cluster will become fully operational.

Let me know if you have any other questions or guidance with this.

-
Denis


On Fri, Sep 11, 2020 at 7:38 AM Samuel Ueltschi <
samuel.uelts...@bsi-software.com> wrote:

> Hi
>
>
>
> I've been testing Ignite (2.8.1) and it's behaviour under network
> segmentation.
>
> According to the docs, Ignite nodes should be able to detect network
> segmentation and apply the configured SegmentationPolicy.
>
>
>
> However the segmentation handling didn't trigger as I would have expected
> it to do.
>
> For my tests, I setup three cluster nodes c1, c2 and c3 running in docker
> containers, all competing for a shared IgniteLock instance in a loop.
>
> Then I used iptables in container c2 to drop all incoming and outgoing
> packages on that node.
>
> After a few seconds I got the following events:
>
>
>
> c1:
>
> - EVT_NODE_FAILED for c2
>
>
>
> c2:
>
> - EVT_NODE_FAILED for c1
>
> - EVT_NODE_FAILED for c3
>
>
>
> c3:
>
> - EVT_NODE_FAILED for c2
>
>
>
> Then I reset the iptables rules expecting that c2 would rejoin the cluster
> and detect segmentation.
>
> However this didn't happen, c2 just keeps running as a second standalone
> cluster instance.
>
> Only after restarting c2 it rejoined the cluster.
>
>
>
> Eventually I was able to trigger the EVT_NODE_SEGMENTED event by pausing
> the c2 container for 1minute. After resuming, c2 detects the segmentation
> and runs the segmentation policy as excepcted.
>
>
>
> Is this behaviour correct? Shouldn't the Ignite cluster be able to recover
> from the first scenario?
>
> During a network segmentation no packages would be able to move between
> nodes, so the iptables approach should be realistic in my oppinion.
>
>
>
> Maybe I have some wrong assumptions about network segmentation so any
> feedback would be greatly appreciated.
>
>
>
> Cheers Sam
>
>
>
> --
> Software Engineer
> BSI Business Systems Integration AG
> Erlachstrasse 16B, CH-3012 Bern
> Telefon +41 31 850 12 06
>
> www.bsi-software.com
>
>
>

Re: DC replication via Kafka Connect for Apache Ignite

[ibelyakov]

Ignite Kafka sink connector doesn't support removals processing. I've created
a ticket to implement this improvement:
https://issues.apache.org/jira/browse/IGNITE-13442

But, as I know, such functionality is implemented in GridGain Kafka
Connector, you can find more details regarding it and data replication,
here:
https://www.gridgain.com/docs/latest/integrations/kafka/kc-ex-replication

Igor



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

Ignite Segmentation Behaviour

[Samuel Ueltschi]

Hi

I've been testing Ignite (2.8.1) and it's behaviour under network segmentation.
According to the docs, Ignite nodes should be able to detect network 
segmentation and apply the configured SegmentationPolicy.

However the segmentation handling didn't trigger as I would have expected it to 
do.
For my tests, I setup three cluster nodes c1, c2 and c3 running in docker 
containers, all competing for a shared IgniteLock instance in a loop.
Then I used iptables in container c2 to drop all incoming and outgoing packages 
on that node.
After a few seconds I got the following events:

c1:
- EVT_NODE_FAILED for c2

c2:
- EVT_NODE_FAILED for c1
- EVT_NODE_FAILED for c3

c3:
- EVT_NODE_FAILED for c2

Then I reset the iptables rules expecting that c2 would rejoin the cluster and 
detect segmentation.
However this didn't happen, c2 just keeps running as a second standalone 
cluster instance.
Only after restarting c2 it rejoined the cluster.

Eventually I was able to trigger the EVT_NODE_SEGMENTED event by pausing the c2 
container for 1minute. After resuming, c2 detects the segmentation and runs the 
segmentation policy as excepcted.

Is this behaviour correct? Shouldn't the Ignite cluster be able to recover from 
the first scenario?
During a network segmentation no packages would be able to move between nodes, 
so the iptables approach should be realistic in my oppinion.

Maybe I have some wrong assumptions about network segmentation so any feedback 
would be greatly appreciated.

Cheers Sam

--
Software Engineer
BSI Business Systems Integration AG
Erlachstrasse 16B, CH-3012 Bern
Telefon +41 31 850 12 06
www.bsi-software.com



smime.p7s
Description: S/MIME cryptographic signature

Network Segmentation Behaviour

[sue]

Hi 

I've been testing Ignite (2.8.1) and it's behaviour under network
segmentation. 
According to the docs, Ignite nodes should be able to detect network
segmentation and apply the configured SegmentationPolicy.

However the segmentation handling didn't trigger as I would have expected it
to do.
For my tests, I setup three cluster nodes c1, c2 and c3 running in docker
containers, all competing for a shared IgniteLock instance in a loop.
Then I used iptables in container c2 to drop all incoming and outgoing
packages on that node.
After a few seconds I got the following events:

c1:
- EVT_NODE_FAILED for c2

c2:
- EVT_NODE_FAILED for c1
- EVT_NODE_FAILED for c3

c3:
- EVT_NODE_FAILED for c2

Then I reset the iptables rules expecting that c2 would rejoin the cluster
and detect segmentation. 
However this didn't happen, c2 just keeps running as a second standalone
cluster instance.
Only after restarting c2 it rejoined the cluster.

Eventyally I was able to trigger the EVT_NODE_SEGMENTED event by pausing the
c2 container for 1minute. After resuming, c2 detects the segmentation and
runs the segmentation policy as excepcted.

Is this behaviour correct? Shouldn't the Ignite cluster be able to recover
from the first scenario?
During a network segmentation no packages would be able to move between
nodes, so the iptables approach should be realistic in my oppinion.

Maybe I have some wrong assumptions about network segmentation so any
feedback would be greatly appreciated. 

Cheers Sam





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

RE: Unable to read fields value from BinaryObject

[Alexandr Shapkin]

Hi, Just for the record, I noticed that the following tickets has been filed: https://issues.apache.org/jira/browse/IGNITE-13415 https://issues.apache.org/jira/browse/IGNITE-13436 Also seems like the consumer would work if you do at least one cache#put operation. From: Alexandr ShapkinSent: Thursday, September 10, 2020 3:04 PMTo: user@ignite.apache.orgSubject: Re: Unable to read fields value from BinaryObject Hi, Yes, I can reproduce the behavior. It could be an issue with the custombinary mappers.  The weird thing is that the CustomBinaryIdMapper works fine with a singlenode, i.e. if it reads and writes the value from a cache, then the mapper isworking. But fails on the other node. Meanwhile, it's quite interesting, why do you want to replace the defaultmapper with a custom one? What tasks are you trying to solve?   -Alex Shapkin--Sent from: http://apache-ignite-users.70518.x6.nabble.com/ 

RE: Null Pointer exception error caught during grid runnable execution

[Alexandr Shapkin]

Hi, It looks like a known issue when a server node is not fully initialized but clients are trying to connect to it [1] I’d suggest you try the latest version (2.8.1) and check if the error will be gone. [1] - https://issues.apache.org/jira/browse/IGNITE-11671 From: SanjayaSent: Friday, September 11, 2020 10:06 AMTo: user@ignite.apache.orgSubject: Null Pointer exception error caught during grid runnable execution Hi All, we are using apache ignite 2.7.6 with pesistence enable inside AzureKubernetes cluster in production.we have 2 pods having persistence enable, The pods have below resourcesassgined to it CPU : 3 coreheap: 3 GBPeristence : SSD 15 GBWAL : SSD 5 GB   We are reading / writting throigh JDBC thin clinet. The client are outsideof  kubernetes, so they connect through kubernetes LoadBlancer IP. The loading data part (from PostGres to Ignite) is quite OK, and it runs asscheduled. But we are facing below issue(Null pointer exception) when the clients aretrying to connect through jdbc thin client. Once the issue occurres, ignitetriggers a complete restart, so clients are not able to connect that timeand everything goes for toss. We never faces this issue in lower enviornment. We are stuck with the issue,request help on thios.  STACK TRACE[05:18:39,803][WARNING][main][GridCacheDatabaseSharedManager] Ignite nodestopped in the middle of checkpoint. Will restore memory state and finishcheckpoint on node start.[05:18:42,276][SEVERE][client-connector-#40][ClientListenerProcessor]Runtime error caught during grid runnable execution: GridWorker[name=message-received-notify, igniteInstanceName=null, finished=false,heartbeatTs=1599801522271, hashCode=1044207064, interrupted=false,runner=client-connector-#40]java.lang.NullPointerException  atorg.apache.ignite.internal.processors.odbc.ClientListenerNioListener.nextConnectionId(ClientListenerNioListener.java:306)  atorg.apache.ignite.internal.processors.odbc.ClientListenerNioListener.prepareContext(ClientListenerNioListener.java:285)  atorg.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onHandshake(ClientListenerNioListener.java:223)  atorg.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:129)  atorg.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:45)  atorg.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)  atorg.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)  atorg.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)  atorg.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)  atorg.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)  atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)  atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)  at java.lang.Thread.run(Thread.java:748)   --Sent from: http://apache-ignite-users.70518.x6.nabble.com/ 

Re: Map 10 caches to 10 different ignite nodes

[abhi2703]

Thanks a lot Vladimir, that's exactly what I was searching for.



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

Re: Block until partition map exchange is complete

[Ilya Kasnacheev]

Hello!

I think that you need to start a new isolated transaction from callback
(possibly in another thread) to get proper isolation.

Regards,
-- 
Ilya Kasnacheev


пт, 21 авг. 2020 г. в 18:34, ssansoy :

> Still seeing the same issue in 2.8.1 unfortunately.
>
> I have a related question however.
>
> Assuming I perform the following operation on node 1 of my 3 node cluster
> (All caches use CacheRebalanceMode.SYNC,
> CacheWriteSynchronizationMode.FULL_SYNC, CacheAtomicityMode.TRANSACTIONAL):
>
>
>   try (Transaction tx = ignite.transactions().txStart(
> TransactionConcurrency.PESSIMISTIC,
> TransactionIsolation.READ_COMMITTED,
> transactionTimeout, igniteTransactionBatchSize)) {
>
> // write 1 record to cache A
> // write 11 records to cache B
>
> tx.commit()
>
> }
>
>
> How should I expect the updated A and B records to appear on some other
> node, e.g. node 2.
> I was expecting them to both become visible together at exactly the same
> time. I am using CacheMode.REPLICATED.
>
> On node 2, I am performing a scan query on A, and in the local listen for
> A,
> I am getting those 11 B records (using an SQLFieldsQuery) that were updated
> in the same transaction. However, they don't seem to always be visible
> until
> some time after the local listen for A has been entered. If I put a sleep
> in
> there and try again, I do get all the B's
>
> 2020-08-21 16:25:05,484 [callback-#192] DEBUG x.TableDataSelector [] -
> Executing SQL query SqlFieldsQuery [sql=SELECT * FROM B WHERE A_FK =
> 'TEST4', args=null, collocated=false, timeout=-1, enforceJoinOrder=false,
> distributedJoins=false, replicatedOnly=false, lazy=false, schema=null,
> updateBatchSize=1]
> 2020-08-21 16:25:05,486 [callback-#192] DEBUG x.TableDataSelector [] -
> Received 3 results
> 2020-08-21 16:25:05,486 [callback-#192] DEBUG x.TableDataSelector [] -
> Trying again in 5 seconds
> 2020-08-21 16:25:10,486 [callback-#192] DEBUG x.TableDataSelector [] -
> Received 11 results
>
>
> My local listen for A is annotated with @IgniteAsyncCallback incase that
> matters. Anything obviously wrong here?
> My requirement is that node 2 has access to A and all the updated B's that
> were written on node 1.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Map 10 caches to 10 different ignite nodes

[Vladimir Pligin]

Yes, it's possible to achieve that with a node filter.
You should change your cache configurations.
Here's the  javadoc

 
. After that you'll be able to leverage attributes to filter nodes. A cache
will start on on certain nodes for which the predicate return true.



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

Map 10 caches to 10 different ignite nodes

[abhi2703]

Hi All,

I am new to ignite.

Is it possible to store 10 different caches to 10 different nodes. 

I am using Ignite clusters and it is exposed to actual code via Ignite
Client.
is it possible to configure this in java code?

Thanks,
abhi



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

Re: Ignite 2.8.1 ContinuousQuery: ClassNotFoundException on a client node

[Ivan.Fedorenkov]

Thank you very much Michael!

From: Michael Cherkasov 
Reply-To: "user@ignite.apache.org" 
Date: Thursday, September 10, 2020 at 9:00 PM
To: "user@ignite.apache.org" 
Subject: Re: Ignite 2.8.1 ContinuousQuery: ClassNotFoundException on a client 
node

Hello Ivan,

Right now CQ deployed remote filter on all nodes, even on client nodes that 
don't store any data and this doesn't make sense, I think Ignite should not 
deploy it at all on non-affinity nodes. I filed a ticket for this:
https://issues.apache.org/jira/browse/IGNITE-13432

Regarding the warning, the CQ is already deployed, but if you will try to 
deploy a new one while the client is online it will fail, just make sure that 
you deploy all CQ while clients are offline or put a remote filter to client 
nodes too, btw peer class loading can help with this.

Thanks,
Mike.
чт, 10 сент. 2020 г. в 10:14, 
mailto:ivan.fedoren...@tdameritrade.com>>:
Hi everyone!

I am getting ClassNotFoundException on a client node when a server node 
registers a new ContinuousQuery with a remote filter class that is not in the 
classpath of a client node. Could someone please clarify if this is the 
expected behavior and all the client nodes must have all remove filters in 
their classpath? I wonder if it is correct that client nodes are participating 
in continuous query execution at all?

According to the ticket 
(https://issues.apache.org/jira/browse/IGNITE-11907)
 it looks like a client node can even break some functionality on a server node 
that tries to initialize a new continuous query.

At the same time I see the following message when a new client node enters the 
topology:

55>
10.09.20 18:55:00.407 [tcp-client-disco-msg-worker-#4]  WARN 
tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on 
client node. Can be ignored.
10.09.20 18:55:00.410 [tcp-client-disco-msg-worker-#4]  WARN 
tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on 
client node. Can be ignored.

So in case when a new client node joins all the running queries continue to 
work as expected (at least it is written in the log).

Best regards,
Ivan Fedorenkov

Null Pointer exception error caught during grid runnable execution

[Sanjaya]

Hi All,

we are using apache ignite 2.7.6 with pesistence enable inside Azure
Kubernetes cluster in production.
we have 2 pods having persistence enable, The pods have below resources
assgined to it

CPU : 3 core
heap: 3 GB
Peristence : SSD 15 GB
WAL : SSD 5 GB 


We are reading / writting throigh JDBC thin clinet. The client are outside
of  kubernetes, so they connect through kubernetes LoadBlancer IP.

The loading data part (from PostGres to Ignite) is quite OK, and it runs as
scheduled.

But we are facing below issue(Null pointer exception) when the clients are
trying to connect through jdbc thin client. Once the issue occurres, ignite
triggers a complete restart, so clients are not able to connect that time
and everything goes for toss.

We never faces this issue in lower enviornment. We are stuck with the issue,
request help on thios.


STACK TRACE

[05:18:39,803][WARNING][main][GridCacheDatabaseSharedManager] Ignite node
stopped in the middle of checkpoint. Will restore memory state and finish
checkpoint on node start.
[05:18:42,276][SEVERE][client-connector-#40][ClientListenerProcessor]
Runtime error caught during grid runnable execution: GridWorker
[name=message-received-notify, igniteInstanceName=null, finished=false,
heartbeatTs=1599801522271, hashCode=1044207064, interrupted=false,
runner=client-connector-#40]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.nextConnectionId(ClientListenerNioListener.java:306)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.prepareContext(ClientListenerNioListener.java:285)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onHandshake(ClientListenerNioListener.java:223)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:129)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:45)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)



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