Re: Ignite Write Behind + .NET + External Cache Store

2024-01-15 Thread Pavel Tupitsyn
1. Write-behind mode invokes cache store in background, so there is no
simple way to confirm if a particular write (cache put) has been persisted,
no matter how many backups.
2. AFAIK, cache store is only invoked on the primary node for the given key

On Tue, Jan 9, 2024 at 5:04 PM  wrote:

> Hi  Pavel,
>
>
>
> Under  Write Behind = true  setting  does  Ignite  will  try  to  save
> data  from  backup  node( partition) if  lets say  one  node crashes while
> writing   into  external  cache store? Document  says  if  node  crashes
> then  some data  can be  lost  from  saving  into  external  cache store
> but  what  if  we set Backup =1 and  WriteSynchronizationMode as  Full
> Sync?  Will  the data  get  written to  cache store  from backup node?
>
>
>
> Regards
>
> Satyajit
>
>
>
>
>
>
>
> Restricted - External
>
> Barclays Execution Services Limited registered in England. Registered No.
> 1767980. Registered office: 1 Churchill Place, London, E14 5HP
>
> Barclays Execution Services Limited provides support and administrative
> services across Barclays group. Barclays Execution Services Limited is an
> appointed representative of Barclays Bank UK plc, Barclays Bank plc and
> Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays
> Bank plc are authorised by the Prudential Regulation Authority and
> regulated by the Financial Conduct Authority and the Prudential Regulation
> Authority. Clydesdale Financial Services Limited is authorised and
> regulated by the Financial Conduct Authority.
>
> This email and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this email
> in error, please notify the sender and immediately delete it and any
> attachments from your system. Do not copy, use, disclose or otherwise act
> on any part of this email or its attachments.
>
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this email may be monitored by the Barclays group for operational or
> business reasons.
>
> Any opinion or other information in this email or its attachments that
> does not relate to the business of the Barclays group is personal to the
> sender and is not given or endorsed by the Barclays group.
>
> Unless specifically indicated, this e-mail is not an offer to buy or sell
> or a solicitation to buy or sell any securities, investment products or
> other financial product or service, an official confirmation of any
> transaction, or an official statement of Barclays.
>


Ignite Write Behind + .NET + External Cache Store

2024-01-09 Thread satyajit.mandal.barclays.com via user
Hi  Pavel,

Under  Write Behind = true  setting  does  Ignite  will  try  to  save  data  
from  backup  node( partition) if  lets say  one  node crashes while writing   
into  external  cache store? Document  says  if  node  crashes  then  some data 
 can be  lost  from  saving  into  external  cache store  but  what  if  we set 
Backup =1 and  WriteSynchronizationMode as  Full  Sync?  Will  the data  get  
written to  cache store  from backup node?

Regards
Satyajit





Restricted - External

Barclays Execution Services Limited registered in England. Registered No. 
1767980. Registered office: 1 Churchill Place, London, E14 5HP

Barclays Execution Services Limited provides support and administrative 
services across Barclays group. Barclays Execution Services Limited is an 
appointed representative of Barclays Bank UK plc, Barclays Bank plc and 
Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank 
plc are authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale 
Financial Services Limited is authorised and regulated by the Financial Conduct 
Authority.

This email and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this email in error, please 
notify the sender and immediately delete it and any attachments from your 
system. Do not copy, use, disclose or otherwise act on any part of this email 
or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any internet communications by 
any third party, or from the transmission of any viruses. Replies to this email 
may be monitored by the Barclays group for operational or business reasons.

Any opinion or other information in this email or its attachments that does not 
relate to the business of the Barclays group is personal to the sender and is 
not given or endorsed by the Barclays group.

Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays.


Re: Ignite Write Behind performance

2016-06-09 Thread amitpa
We use it to conservative 2 now in our current setting



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


Re: Ignite Write Behind performance

2016-06-08 Thread bintisepaha
Thanks for that. we were setting flushsize to 0. how about flush thread
count?



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


Re: Ignite Write Behind performance

2016-06-06 Thread amitpa
I did test this...For us I think Write behind gets called fine.



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


Re: Ignite Write Behind performance

2016-06-06 Thread bintisepaha
amitpa, We would be interested in learning how did this perform for you?
We have implemented spring txn to insert in database for write-behind.
Hoever, we see that sometiems write-behind is not even called for some
objects that we are certain were just updated in the cache. have you noticed
that?



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


Re: Ignite Write Behind performance

2016-06-04 Thread amitpa
Thanks we are considering implementing JDBC batch inserts



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


Re: Ignite Write Behind performance

2016-06-03 Thread Alexey Goncharuk
Ignite _does_ use a separate thread pool to persist data in write-behind
mode, this is the essential difference between write-through and
write-behind. However, if your cache load rate is significantly higher than
the database insert rate, the write queue will grow faster than background
threads can flush data, so eventually you will get an OOME.

In this situation you can
 - block and wait until there is some space in the write queue
 - persist your own data synchronously
Ignite choses the second option and writes transaction data synchronously.

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


2016-06-03 10:26 GMT-07:00 amitpa <ami...@nrifintech.com>:

> I understood this perfectly.
>
> What I mean is :-
>
> Shouldnt the write behind use a separete thread pool so that slow write
> behind process does not impact the whole grid ?
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-tp5385p5412.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Ignite Write Behind performance

2016-06-03 Thread amitpa
I understood this perfectly.

What I mean is :-

Shouldnt the write behind use a separete thread pool so that slow write
behind process does not impact the whole grid ?



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


Re: Ignite Write Behind performance

2016-06-03 Thread Denis Magda
As I explained in the situation when the write-behind queue is full a Thread 
that updates a cache and propagates the changes into the write-behind store can 
be used to flush the write-behind queue since the queue is full. This situation 
can affect the performance especially if this happens too often.

—
Denis
> On Jun 3, 2016, at 11:30 AM, amitpa <ami...@nrifintech.com> wrote:
> 
> Danis,
> 
> Thanks. I am trying that.
> 
> However shouldnt the write behinds not impact the GRID performance at all. 
> Since we are writing in write behin dmode to avoid the cost of slow disk IO.
> I understand that theres a limit, but shouldnt this thread pool be different
> if technically possible, allowing ignite to continue processing in case of
> slow write behind  performance.
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-tp5385p5400.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.



Re: Ignite Write Behind performance

2016-06-03 Thread amitpa
Danis,

Thanks. I am trying that.

However shouldnt the write behinds not impact the GRID performance at all. 
Since we are writing in write behin dmode to avoid the cost of slow disk IO.
I understand that theres a limit, but shouldnt this thread pool be different
if technically possible, allowing ignite to continue processing in case of
slow write behind  performance.



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


Re: Ignite Write Behind performance

2016-06-02 Thread Denis Magda
Hi,

Most likely your write-behind Threads can’t keep up with volume of data that is 
aggregated in the write-behind buffer and you get with the situation when from 
time to time writing to the DB is performed in the sync mode from system 
Thread(s).
 
I would suggest you playing with the following write-behind configuration to 
avoid the situation above:
- CacheConfiguration.setWriteBehindFlushSize - increase size of the 
write-behind buffer;
- CacheConfiguration.setWriteBehindFlushThreadCount;
- CacheConfiguration.setWriteBehindFlushFrequence - decrease this value 
triggering the flushing more frequently. Default value is 5 seconds.

—
Denis

> On Jun 2, 2016, at 7:23 PM, amitpa <ami...@nrifintech.com> wrote:
> 
> Hello,
> 
> I am struggling with improving ignite transaction performance. However this
> is another problem
> 
> However if I am doing write behind and the writes are slow, I am seeing that
> the over all performance of teh grid drops.
> 
> Is there any configuration that I can do to make ignite performance stable
> even when the writes are being slow in write behind (due to slow DB)
> 
> Currently I have 10 threads in write behind mode.
> 
> What should be my system threadpool size assuming I have two caches which
> participate in transactions and 2 nodes in 10G network.
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Write-Behind-performance-tp5385.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.



Ignite Write Behind performance

2016-06-02 Thread amitpa
Hello,

I am struggling with improving ignite transaction performance. However this
is another problem

However if I am doing write behind and the writes are slow, I am seeing that
the over all performance of teh grid drops.

Is there any configuration that I can do to make ignite performance stable
even when the writes are being slow in write behind (due to slow DB)

Currently I have 10 threads in write behind mode.

What should be my system threadpool size assuming I have two caches which
participate in transactions and 2 nodes in 10G network.







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


Re: Ignite WRite Behind

2016-05-05 Thread amitpa
does write behind work without this setting :- 
cacheCfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_ASYNC);

Here is my cache setting :- 

cacheCfg.setReadThrough(true);
cacheCfg.setWriteThrough(true);
cacheCfg.setWriteBehindEnabled(true);
cacheCfg.setWriteBehindFlushThreadCount(1);
cacheCfg.setAtomicityMode(TRANSACTIONAL);
cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_TIERED);
cacheCfg.setCacheMode(CacheMode.PARTITIONED);
cacheCfg.setBackups(0);
cacheCfg.setSwapEnabled(false);
cacheCfg.setWriteBehindFlushFrequency(5000);
cacheCfg.setOffHeapMaxMemory(0);

Do I need to add something to it? 



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


Re: Ignite WRite Behind

2016-05-05 Thread amitpa
I undrestand that WriteAll will be called per cache.

But my undrestanding is this :-

1) There are two configs for write behind  1) No of Entries and Time

2) SO if I make three cache entries in three transaction before the time
(which is configured to lets say 4000 ms ) then the writeAll should be
called for the 3 entries.

My transaction level is Optimistic with Serializable. Does this affect
something?



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


Re: Ignite WRite Behind

2016-05-04 Thread Vladimir Ozerov
Hi,

writeAll() method is only executed for entries located in the same cache.
As you have only 1 entry per cache in transaction, this is expected
behavior that writeAll() is not called. Normally, you should make your
logic dependent on whether write() or writeAll() is called, because it is
up to Ignite to decide which method to call.

Vladimir.

On Wed, May 4, 2016 at 5:54 AM, amitpa <ami...@nrifintech.com> wrote:

> Hi,
>
> I have 2 nodes setup and there are around 5 different caches involved, with
> 1 entry per cache per transaction.
>
> I have writeThrough set to true and writeBehindEnabled set to true.
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-WRite-Behind-tp4741p4748.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Ignite WRite Behind

2016-05-03 Thread amitpa
Hi,

I have 2 nodes setup and there are around 5 different caches involved, with
1 entry per cache per transaction. 

I have writeThrough set to true and writeBehindEnabled set to true.



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