Re: [2.10 branch]cpp thin client transaction :Transaction with id 1 not found.

[18624049226]

Hi Igor,

1.The actual test environment uses static IP address directly.

2.Three IP addresses are specified as follows:

cfg.SetEndPoints("172.16.100.71,172.16.100.72,172.16.100.73");

在 2021/2/4 下午7:40, Igor Sapego 写道:

Thanks,

I've a few more questions, just to be clear:
1. Are servers behind NAT or some kind of balancer, or do they have 
distinct static IP addresses?
2. Do you specify all servers addresses in 
cfg.SetEndPoints("X.X.X.X");, or only one?


Best Regards,
Igor


On Thu, Feb 4, 2021 at 4:47 AM 18624049226 <18624049...@163.com 
> wrote:


Hello Igor,

If start two nodes on two hosts and create a cluster, you can
reproduce this problem. If start multiple server nodes on one
host, it seems that there is no problem.
Thin clients only need one.

在 2021/2/3 下午10:02, Igor Sapego 写道:

Hi, I've tried to reproduce an issue you described and could not
reproduce it.

Can you share more details? How many nodes do you run? How many
clients
are run? Do you run any other operations in parallel?

Best Regards,
Igor


On Wed, Feb 3, 2021 at 3:00 PM 18624049226 <18624049...@163.com
> wrote:

Hi team,

Using the 2.10 branch code and the transaction function of
cpp thin client, the transaction with id 1 not found error
will be throw. the reproduce steps are as follows:

1.start a node use the following config file:


http://www.springframework.org/schema/beans;

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;

xsi:schemaLocation="
http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd
">




























2.test code are as follows:

Usually only the first few loop operations may throw an
exception, and the subsequent operations are normal.

#include
#include
#include
#include
#include"ignite/examples/organization.h"
usingnamespaceignite;
usingnamespacethin;
usingnamespacecache;
usingnamespaceexamples;
intmain()
{
IgniteClientConfiguration cfg;
cfg.SetEndPoints("X.X.X.X");
try
{
IgniteClient client = IgniteClient::Start(cfg);
CacheClient cache =
client.GetOrCreateCache("PutGetExample");
cache.Clear();
intloop = 100;
for(inti = 0; i < loop; i++)
{
ignite::thin::transactions::ClientTransaction transaction =
client.ClientTransactions().TxStart();
Organization org("Microsoft", Address("1096 Eddy Street, San
Francisco, CA", i));
cache.Put(1, org);
transaction.Commit();
}
Organization orgFromCache = cache.Get(1);
}
catch(IgniteError& err)
{
std::cout << "An error occurred: "<< err.GetText() << std::endl;
returnerr.GetCode();
}
return0;
}

3.server side's log are as follows:

[11:25:35,496][SEVERE][client-connector-#117][ClientListenerNioListener]
Failed to process client request
[req=o.a.i.i.processors.platform.client.tx.ClientTxEndRequest@569bc2e0]
class

org.apache.ignite.internal.processors.platform.client.IgniteClientException:
Transaction with id 1not found.
at

org.apache.ignite.internal.processors.platform.client.tx.ClientTxEndRequest.process(ClientTxEndRequest.java:59)
at

org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:98)
at

org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:195)
at

org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:49)
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

Rebalancing Errors

[nasim mombini]

Hello Folks

The attempts to partition rebalancing in my ignite clusters fail with the
following errors. Any help would be greatly appreciated. I am using ignite
2.8.1.

[2021-02-02 19:57:03,428][WARN ][tcp-disco-msg-worker-[ef238b3f
10.244.69.14:47500]-#2][root] Possible failure suppressed accordingly to a
configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
timeout=0, super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
[name=partition-exchanger, igniteInstanceName=null, finished=false,
heartbeatTs=1612295797718]]]
class org.apache.ignite.IgniteException: GridWorker
[name=partition-exchanger, igniteInstanceName=null, finished=false,
heartbeatTs=1612295797718]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$3.apply(IgnitionEx.java:1810)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$3.apply(IgnitionEx.java:1805)
at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:234)
at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2858)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7759)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2946)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7697)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
[2021-02-02 19:57:03,437][WARN ][tcp-disco-msg-worker-[ef238b3f
10.244.69.14:47500]-#2][CacheDiagnosticManager] Page locks dump:

Thread=[name=checkpoint-runner-#57, id=107], state=WAITING
Locked pages = []
Locked pages log: name=checkpoint-runner-#57 time=(1612295823428,
2021-02-02 19:57:03.428)

..
.
[2021-02-02 19:58:43,446][WARN ][grid-timeout-worker-#23][G] >>> Possible
starvation in striped pool.
Thread name: sys-stripe-0-#1
Queue: [Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE,
topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false,
msg=CacheContinuousQueryBatchAck
[routineId=d5b79564-d336-4b10-895f-f3f59651754c, updateCntrs=HashMap
{713=691}
Deadlock: false
Completed: 5
Thread [name="sys-stripe-0-#1", id=13, state=WAITING, blockCnt=0, waitCnt=8]
Lock
[object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@1c908a6f,
ownerName=null, ownerId=-1]
at java.base@11.0.9.1/jdk.internal.misc.Unsafe.park(Native Method)
at
java.base@11.0.9.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at
java.base@11.0.9.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
at
java.base@11.0.9.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:1009)
at
java.base@11.0.9.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1324)
at
java.base@11.0.9.1/java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:738)
at
app//o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1631)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxManager.lockMultiple(IgniteTxManager.java:1906)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxManager.prepareTx(IgniteTxManager.java:1136)
at
app//o.a.i.i.processors.cache.distributed.GridDistributedTxRemoteAdapter.prepareRemoteTx(GridDistributedTxRemoteAdapter.java:432)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxHandler.startRemoteTx(IgniteTxHandler.java:1858)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1201)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxHandler.access$400(IgniteTxHandler.java:123)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
at
app//o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
app//o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
app//o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
app//o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
app//o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at

Re: putAll() performance big difference, 2.7.5 vs 2.9.1

[Ping Hao]

Thanks for heads up. Although for my case, the cache configuration is all by 
default, partition/atomic/zero backup. I guess some general logic was changed 
in 2.9.1 impact all type of atomicity modes.

On 2021/02/04 09:27:31, jjimeno  wrote: 
> Hi,
> 
> Maybe it has to do with this:
> 
> Performance of Ignite as key-value datastore. C++ Thin Client
> 
>   
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
> 

Re: putAll() performance big difference, 2.7.5 vs 2.9.1

[haoping]

Update with DataStreamer, Ignite 2.7.5 still much better than 2.9.1 on
throughput. However, my OP with putAll() in fact deliver highest throughput.

gist
https://gist.github.com/PingHao/f104c02e86bfbea9c0bd8d1abcfdb912

10 working threads, shared same DataStreamer instance, 40 thread pool size
of datastreamer in all ignite configuration. server nodes 4, driver nodes 1.
2.7.5: 1.8M/s
2.9.1: 0.46M/s




On Thu, Feb 4, 2021 at 8:43 AM haoping  wrote:

> I don't know data-streaming, but will check it out later.
> Here it is ignite config on one server node, same as other nodes.
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
>
>  class="org.apache.ignite.configuration.IgniteConfiguration">
> 
> 
> 
> 
> 
>
> 
> 
> 
>
> 
>  class="org.apache.ignite.failure.StopNodeOrHaltFailureHandler">
> 
> 
>  name="ignoredFailureTypes">
> 
> 
>
> 
>  class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
> 
> 
> 
> 
>
> 
>  class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> 
> 
>  class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
> 
> 
> 2s1b:37205
> 2s1c:37205
> 2s1d:37205
> exp1:37205
> 
> 
> 
> 
> 
> 
> 
>  class="org.apache.ignite.configuration.DataStorageConfiguration">
> 
>  class="org.apache.ignite.configuration.DataRegionConfiguration">
> 
> 
> 
> 
> 
> 
> 
> 
>
> On Thu, Feb 4, 2021 at 7:27 AM Pavel Tupitsyn 
> wrote:
>
>> Hi,
>>
>> 1. Can you please attach the CacheConfiguration as well?
>> 2. Have you tried DataStreamer
>> https://ignite.apache.org/docs/latest/data-streaming?
>>
>> On Thu, Feb 4, 2021 at 12:27 PM jjimeno  wrote:
>>
>>> Hi,
>>>
>>> Maybe it has to do with this:
>>>
>>> Performance of Ignite as key-value datastore. C++ Thin Client
>>> <
>>> http://apache-ignite-users.70518.x6.nabble.com/Performance-of-Ignite-as-key-value-datastore-C-Thin-Client-tt35274.html>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>
>>

Persistent atomics

[Kathryn Hogg]

I'm using Ignite.Net 2.9.1.

Is there any way to create Atomic Types in persistent storage on a per entity 
basis?


--
Kathryn Hogg
Principal Technology Architect

Re: [External]Re: Exporter usage of Ignite 2.8.0

[VincentCE]

Thanks for providing the config!
I copied/pasted it into my example-default.xml. Afterwards I started a
server node using ./ignite.sh ../examples/config/example-default.xml. I am
using Ignite 2.8.1 btw.

Unfortunately I am still getting no result. The root cause must lie
somewhere else.
Interestingly enough
https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java
works totally fine. In fact the above config is entirely based on it.

Best,
Vincent



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

Re: data rebalancing and partition map exchange with persistence

[Вячеслав Коптилин]

Hi Alan,

I am sorry for the typo in your name, it was done unintentionally.

Thanks,
S.

чт, 4 февр. 2021 г. в 19:10, Вячеслав Коптилин :

> Hello Allan,
>
> > Does data rebalancing occur when a node leaves or joins, or only when
> you manually change the baseline topology (assuming automatic baseline
> adjustment is disabled)? Again, this is on a cluster with persistence
> enabled.
> Yes, this can happen when a node joins the cluster, for instance.
> Let's consider the following scenario: you shut down a node that is a part
> of the current baseline topology, and so, this node cannot apply updates.
> After a while, this node was restarted and returned to the cluster. In
> this case, rebalancing can be triggered in order to transfer that updates.
>
> > 2. Sometimes I look at the partition counts of a cache across all the
> nodes using
> Arrays.stream(ignite.affinity(cacheName).primaryPartitions(severNode) and I
> see 0 partition
> > After a while it returns to a balanced state. What's going on here?
> Well, when a partition needs to be rebalanced from one node (supplier) to
> another one (demander) we create a partition on the demander in a MOVING
> state (this means a backup that applies updates but cannot be used for
> reads).
> When this partition fully rebalanced it is switched to OWNING state and
> the next PME (Late Affinity Assignment) may mark this partition as a
> primary.
>
> > 3. Is there a way to manually invoke the partition map exchange process?
> I don't think so.
>
> > 4. Sometimes I see 'partition lost' errors. If i am using persistence
> and all the baseline nodes are online and connected, is it safe to assume
> no data has been lost and just call cache.resetLostPartitions(myCaches)?
> If I am not mistaken, the answer is yes. Please take a look at
> https://ignite.apache.org/docs/latest/configuring-caches/partition-loss-policy#recovering-from-a-partition-loss
>
> Thanks,
> S.
>
> пт, 29 янв. 2021 г. в 15:56, Alan Ward :
>
>> I'm using Ignite 2.9.1, a 5 node cluster with persistence enabled,
>> partitioned caches with 1 backup.
>>
>> I'm a bit confused about the difference between data rebalancing and
>> partition map exchange in this context.
>>
>> 1. Does data rebalancing occur when a node leaves or joins, or only when
>> you manually change the baseline topology (assuming automatic baseline
>> adjustment is disabled)? Again, this is on a cluster with persistence
>> enabled.
>>
>> 2. Sometimes I look at the partition counts of a cache across all the
>> nodes using
>> Arrays.stream(ignite.affinity(cacheName).primaryPartitions(severNode) and I
>> see 0 partitions on one or even two nodes for some of the caches. After a
>> while it returns to a balanced state. What's going on here? Is this data
>> rebalancing at work, or is this the result of the partition map exchange
>> process determining that one node is/was down and thus switching to use the
>> backup partitions?
>>
>> 3. Is there a way to manually invoke the partition map exchange process?
>> I figured it would happen on cluster restart, but even after restarting the
>> cluster and seeing all baseline nodes connect I still observe the partition
>> imbalance. It often takes hours for this to resolve.
>>
>> 4. Sometimes I see 'partition lost' errors. If i am using persistence and
>> all the baseline nodes are online and connected, is it safe to assume no
>> data has been lost and just call cache.resetLostPartitions(myCaches)? Is
>> there a way calling that method would lead to data loss with persistence
>> enabled?
>>
>> thanks for your help!
>>
>

Re: data rebalancing and partition map exchange with persistence

[Вячеслав Коптилин]

Hello Allan,

> Does data rebalancing occur when a node leaves or joins, or only when you
manually change the baseline topology (assuming automatic baseline
adjustment is disabled)? Again, this is on a cluster with persistence
enabled.
Yes, this can happen when a node joins the cluster, for instance.
Let's consider the following scenario: you shut down a node that is a part
of the current baseline topology, and so, this node cannot apply updates.
After a while, this node was restarted and returned to the cluster. In this
case, rebalancing can be triggered in order to transfer that updates.

> 2. Sometimes I look at the partition counts of a cache across all the
nodes using
Arrays.stream(ignite.affinity(cacheName).primaryPartitions(severNode) and I
see 0 partition
> After a while it returns to a balanced state. What's going on here?
Well, when a partition needs to be rebalanced from one node (supplier) to
another one (demander) we create a partition on the demander in a MOVING
state (this means a backup that applies updates but cannot be used for
reads).
When this partition fully rebalanced it is switched to OWNING state and the
next PME (Late Affinity Assignment) may mark this partition as a primary.

> 3. Is there a way to manually invoke the partition map exchange process?
I don't think so.

> 4. Sometimes I see 'partition lost' errors. If i am using persistence and
all the baseline nodes are online and connected, is it safe to assume no
data has been lost and just call cache.resetLostPartitions(myCaches)?
If I am not mistaken, the answer is yes. Please take a look at
https://ignite.apache.org/docs/latest/configuring-caches/partition-loss-policy#recovering-from-a-partition-loss

Thanks,
S.

пт, 29 янв. 2021 г. в 15:56, Alan Ward :

> I'm using Ignite 2.9.1, a 5 node cluster with persistence enabled,
> partitioned caches with 1 backup.
>
> I'm a bit confused about the difference between data rebalancing and
> partition map exchange in this context.
>
> 1. Does data rebalancing occur when a node leaves or joins, or only when
> you manually change the baseline topology (assuming automatic baseline
> adjustment is disabled)? Again, this is on a cluster with persistence
> enabled.
>
> 2. Sometimes I look at the partition counts of a cache across all the
> nodes using
> Arrays.stream(ignite.affinity(cacheName).primaryPartitions(severNode) and I
> see 0 partitions on one or even two nodes for some of the caches. After a
> while it returns to a balanced state. What's going on here? Is this data
> rebalancing at work, or is this the result of the partition map exchange
> process determining that one node is/was down and thus switching to use the
> backup partitions?
>
> 3. Is there a way to manually invoke the partition map exchange process? I
> figured it would happen on cluster restart, but even after restarting the
> cluster and seeing all baseline nodes connect I still observe the partition
> imbalance. It often takes hours for this to resolve.
>
> 4. Sometimes I see 'partition lost' errors. If i am using persistence and
> all the baseline nodes are online and connected, is it safe to assume no
> data has been lost and just call cache.resetLostPartitions(myCaches)? Is
> there a way calling that method would lead to data loss with persistence
> enabled?
>
> thanks for your help!
>

Re: [External]Re: Exporter usage of Ignite 2.8.0

[Stephen Darlington]

I more-or-less just copy-and-pasted your example:

https://github.com/GridGain-Demos/ignite-prometheus/blob/main/src/main/resources/ignite-prometheus.xml

Regards,
Stephen

> On 4 Feb 2021, at 15:41, VincentCE  wrote:
> 
> Hi Stephen,
> 
> I am glad to here that the configuration works for you! Unfortunately I
> already tried different ports but this didn't solve my problem, also I am
> not running ignites REST server. Could you possibly share the ignite
> configuration which is working for you?
> 
> Best,
> Vincent
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: [External]Re: Exporter usage of Ignite 2.8.0

[VincentCE]

Hi Stephen,

I am glad to here that the configuration works for you! Unfortunately I
already tried different ports but this didn't solve my problem, also I am
not running ignites REST server. Could you possibly share the ignite
configuration which is working for you?

Best,
Vincent



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

Re: [External]Re: Exporter usage of Ignite 2.8.0

[Stephen Darlington]

That’s a good trick! I couldn’t figure out the Spring magic required to call a 
static method, but that works for me. (I had written a small lifecycle bean, 
which also works, but this is better.)

I would try to have your collector running on a port other than 8080. That’s a 
pretty common port for web services, including Ignite’s own REST server if you 
have that running.

Regards,
Stephen

> On 4 Feb 2021, at 14:19, VincentCE  wrote:
> 
> Hi!
> 
> We would like to use the prometheus/opencensus exporter for our server nodes
> which we start using an xml configuration. Facundo.maldonado mentioned
> before that this can be done wrapping the collector and http server in
> another bean. This is what I tried which is probably not exactly as
> suggested:
> 
> 
> http://www.springframework.org/schema/beans;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xmlns:util="http://www.springframework.org/schema/util;
>   xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd
>http://www.springframework.org/schema/util
>http://www.springframework.org/schema/util/spring-util.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
> 
>
> 
>
> class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
>
>
> 
>127.0.0.1:47500..47509
>
>
>
>
>
>
> 
>
> class="org.apache.ignite.spi.metric.opencensus.OpenCensusMetricExporterSpi">
>  
>
>
>
> 
> class="org.springframework.beans.factory.config.MethodInvokingBean">
>   value="io.opencensus.exporter.stats.prometheus.PrometheusStatsCollector.createAndRegister"
> />
>
> 
>   
>  
>  
>  
>  
> 
> 
> Using this config the ignite server node starts as desired and the same
> holds for the inner http server. However no metrics are collected (Nothing
> is displayed on http://localhost:8080/), it seems as if
> prometheusStatsCollector is not successfully registering with the internally
> used default registry. Can someone see the issue with the above
> configuration? 
> 
> Thanks!
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: putAll() performance big difference, 2.7.5 vs 2.9.1

[haoping]

I don't know data-streaming, but will check it out later.
Here it is ignite config on one server node, same as other nodes.

http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="
   http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans.xsd;>


































2s1b:37205
2s1c:37205
2s1d:37205
exp1:37205



















On Thu, Feb 4, 2021 at 7:27 AM Pavel Tupitsyn  wrote:

> Hi,
>
> 1. Can you please attach the CacheConfiguration as well?
> 2. Have you tried DataStreamer
> https://ignite.apache.org/docs/latest/data-streaming?
>
> On Thu, Feb 4, 2021 at 12:27 PM jjimeno  wrote:
>
>> Hi,
>>
>> Maybe it has to do with this:
>>
>> Performance of Ignite as key-value datastore. C++ Thin Client
>> <
>> http://apache-ignite-users.70518.x6.nabble.com/Performance-of-Ignite-as-key-value-datastore-C-Thin-Client-tt35274.html>
>>
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>

[MEETUP] Apache Ignite at Dutch Railways. Join the talk on February 16

[Kseniya Romanova]

Hi Igniters!

Here’s the cool case of Ignite in production. Every day, millions of people
travel by train through the Netherlands—on one of the busiest rail
infrastructures in Europe. More than 10,000 train movements are performed
daily. Planning for all these train rides and designing a timetable that
avoids hazardous situations is a challenge.

Pim Dorrestijn, a solution architect at JDriven, will tell us on February
16 how Apache Ignite is used for detecting potential hazardous situations
in Dutch railway planning.

Check your timezone start time and RSVP here [1]

If you have an Ignite story to share, please contact me or submit the talk
via the form [2]

[1] https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/276125392/

 [2]
https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform

-- 
Cheers,
Kseniya

Devrel at GridGain
Don't miss upcoming community events, join
https://www.meetup.com/Apache-Ignite-Virtual-Meetup/

Re: [External]Re: Exporter usage of Ignite 2.8.0

[VincentCE]

Hi!

We would like to use the prometheus/opencensus exporter for our server nodes
which we start using an xml configuration. Facundo.maldonado mentioned
before that this can be done wrapping the collector and http server in
another bean. This is what I tried which is probably not exactly as
suggested:


http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xmlns:util="http://www.springframework.org/schema/util;
   xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util.xsd;>











127.0.0.1:47500..47509









  





  


   
  
  
  
  


Using this config the ignite server node starts as desired and the same
holds for the inner http server. However no metrics are collected (Nothing
is displayed on http://localhost:8080/), it seems as if
prometheusStatsCollector is not successfully registering with the internally
used default registry. Can someone see the issue with the above
configuration? 

Thanks!



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

Re: putAll() performance big difference, 2.7.5 vs 2.9.1

[Pavel Tupitsyn]

Hi,

1. Can you please attach the CacheConfiguration as well?
2. Have you tried DataStreamer
https://ignite.apache.org/docs/latest/data-streaming?

On Thu, Feb 4, 2021 at 12:27 PM jjimeno  wrote:

> Hi,
>
> Maybe it has to do with this:
>
> Performance of Ignite as key-value datastore. C++ Thin Client
> <
> http://apache-ignite-users.70518.x6.nabble.com/Performance-of-Ignite-as-key-value-datastore-C-Thin-Client-tt35274.html>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: [2.10 branch]cpp thin client transaction :Transaction with id 1 not found.

[Igor Sapego]

Thanks,

I've a few more questions, just to be clear:
1. Are servers behind NAT or some kind of balancer, or do they have
distinct static IP addresses?
2. Do you specify all servers addresses in cfg.SetEndPoints("X.X.X.X");, or
only one?

Best Regards,
Igor


On Thu, Feb 4, 2021 at 4:47 AM 18624049226 <18624049...@163.com> wrote:

> Hello Igor,
>
> If start two nodes on two hosts and create a cluster, you can reproduce
> this problem. If start multiple server nodes on one host, it seems that
> there is no problem.
> Thin clients only need one.
> 在 2021/2/3 下午10:02, Igor Sapego 写道:
>
> Hi, I've tried to reproduce an issue you described and could not reproduce
> it.
>
> Can you share more details? How many nodes do you run? How many clients
> are run? Do you run any other operations in parallel?
>
> Best Regards,
> Igor
>
>
> On Wed, Feb 3, 2021 at 3:00 PM 18624049226 <18624049...@163.com> wrote:
>
>> Hi team,
>>
>> Using the 2.10 branch code and the transaction function of cpp thin
>> client, the transaction with id 1 not found error will be throw. the
>> reproduce steps are as follows:
>>
>> 1.start a node use the following config file:
>> 
>> http://www.springframework.org/schema/beans;
>> 
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>> 
>> xsi:schemaLocation="
>> http://www.springframework.org/schema/beans
>> http://www.springframework.org/schema/beans/spring-beans.xsd;>
>> > "org.apache.ignite.configuration.IgniteConfiguration">
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> 2.test code are as follows:
>>
>> Usually only the first few loop operations may throw an exception, and
>> the subsequent operations are normal.
>> #include 
>> #include 
>> #include 
>> #include 
>> #include "ignite/examples/organization.h"
>> using namespace ignite;
>> using namespace thin;
>> using namespace cache;
>> using namespace examples;
>> int main()
>> {
>> IgniteClientConfiguration cfg;
>> cfg.SetEndPoints("X.X.X.X");
>> try
>> {
>> IgniteClient client = IgniteClient::Start(cfg);
>> CacheClient cache = client.GetOrCreateCache<
>> int32_t, Organization>("PutGetExample");
>> cache.Clear();
>> int loop = 100;
>> for (int i = 0; i < loop; i++)
>> {
>> ignite::thin::transactions::ClientTransaction transaction = client.
>> ClientTransactions().TxStart();
>> Organization org("Microsoft", Address("1096 Eddy Street, San Francisco,
>> CA", i));
>> cache.Put(1, org);
>> transaction.Commit();
>> }
>> Organization orgFromCache = cache.Get(1);
>> }
>> catch (IgniteError& err)
>> {
>> std::cout << "An error occurred: " << err.GetText() << std::endl;
>> return err.GetCode();
>> }
>> return 0;
>> }
>>
>> 3.server side's log are as follows:
>> [11:25:35,496][SEVERE][client-connector-#117][ClientListenerNioListener]
>> Failed to process client request [req=
>> o.a.i.i.processors.platform.client.tx.ClientTxEndRequest@569bc2e0]
>> class
>> org.apache.ignite.internal.processors.platform.client.IgniteClientException:
>> Transaction with id 1 not found.
>> at
>> org.apache.ignite.internal.processors.platform.client.tx.ClientTxEndRequest.process(ClientTxEndRequest.java:59)
>> at
>> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:98)
>> at
>> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:195)
>> at
>> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:49)
>> 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)
>>
>>
>>

Re: Ignite thick client triggering PME in 2.8.0 ?

[Shiva Kumar]

Even i observed the same, during thick client or visor joining cluster
looks like something related to PME happens but not data rebalancing, and
also it is putting some lock on WAL archive segment which never gets
released and causing WAL disk running out of space.

On Thu, 4 Feb, 2021, 4:59 pm Hemambara,  wrote:

> Hi, can anyone please check and respond on this..appreciate your help in
> advance
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Ignite thick client triggering PME in 2.8.0 ?

[Hemambara]

Hi, can anyone please check and respond on this..appreciate your help in
advance



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

Long transaction suspended

[jjimeno]

Hi all,

I'm trying to commit a very large transaction (8M keys and ~4GB of data).

After a while, I can see this diagnostics message in node log:
[08:56:31,721][WARNING][sys-#989][diagnostic] >>> Transaction
[startTime=08:55:22.095, curTime=08:56:31.712, ... *state=SUSPENDED* ... 

Does anyone know why it is suspended, and how to avoid it?

Thanks in advance
José





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

Re: putAll() performance big difference, 2.7.5 vs 2.9.1

[jjimeno]

Hi,

Maybe it has to do with this:

Performance of Ignite as key-value datastore. C++ Thin Client

  



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