Re: Call for presentations for ApacheCon North America 2020 now open

[Denis Magda]

Congrats, Saikat! I received a similar message that my talk (In-memory
computing essentials for software engineers) was accepted as well. So, at
least two talks by the Ignite folks.

Once you share the time your presentation is scheduled for, I'll go ahead
and update on the events' page on the website.
https://ignite.apache.org/events.html

-
Denis


On Tue, Aug 4, 2020 at 6:40 PM Saikat Maitra 
wrote:

> Hi,
>
> I learned that my proposal for talk about Data Streaming using Apache
> Ignite
> and Apache Flink has been accepted.
>
> I have not yet received the schedule yet. I will share as soon as I have
> it.
>
> Regards,
> Saikat
>
> On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra 
> wrote:
>
> > Hi Denis,
> >
> > Thank you for your email. I have submitted a talk about Data Streaming
> > using Apache Ignite and Apache Flink.
> >
> > I would also like to co-present on Ignite internals and usecases deep
> dive.
> >
> > Regards,
> > Saikat
> >
> > On Wed, Jan 22, 2020 at 6:22 PM Denis Magda  wrote:
> >
> >> Igniters,
> >>
> >> I was submitting an Ignite talk to the conference and found out that
> this
> >> time ASF created a separate category for Ignite-specific proposals. You
> can
> >> see an abstract submitted by me:
> >>
> https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing
> >>
> >> Who else is ready to submit? It can be a deep-dive about Ignite
> internals
> >> or Ignite use case overview. We can co-present. Also, GridGain is ready
> to
> >> sponsor your trip if the talk is accepted.
> >>
> >>
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Tue, Jan 21, 2020 at 5:22 PM Denis Magda  wrote:
> >>
> >>> Ignite folks, just bringing to your attention and encourage anybody
> >>> interested to submit an Ignite-related session. Both Alex Zinoviev and
> I
> >>> presented at ApacheCons the previous year -- the events are worth
> attending
> >>> and speaking at.
> >>>
> >>> -
> >>> Denis
> >>>
> >>>
> >>> -- Forwarded message -
> >>> From: Rich Bowen 
> >>> Date: Tue, Jan 21, 2020 at 7:06 AM
> >>> Subject: Call for presentations for ApacheCon North America 2020 now
> open
> >>> To: plann...@apachecon.com 
> >>>
> >>>
> >>> Dear Apache enthusiast,
> >>>
> >>> (You’re receiving this message because you are subscribed to one or
> more
> >>> project mailing lists at the Apache Software Foundation.)
> >>>
> >>> The call for presentations for ApacheCon North America 2020 is now open
> >>> at https://apachecon.com/acna2020/cfp
> >>>
> >>> ApacheCon will be held at the Sheraton, New Orleans, September 28th
> >>> through October 2nd, 2020.
> >>>
> >>> As in past years, ApacheCon will feature tracks focusing on the various
> >>> technologies within the Apache ecosystem, and so the call for
> >>> presentations will ask you to select one of those tracks, or “General”
> >>> if the content falls outside of one of our already-organized tracks.
> >>> These tracks are:
> >>>
> >>> Karaf
> >>> Internet of Things
> >>> Fineract
> >>> Community
> >>> Content Delivery
> >>> Solr/Lucene (Search)
> >>> Gobblin/Big Data Integration
> >>> Ignite
> >>> Observability
> >>> Cloudstack
> >>> Geospatial
> >>> Graph
> >>> Camel/Integration
> >>> Flagon
> >>> Tomcat
> >>> Cassandra
> >>> Groovy
> >>> Web/httpd
> >>> General/Other
> >>>
> >>> The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time).
> >>>
> >>> Submit early, submit often, at https://apachecon.com/acna2020/cfp
> >>>
> >>> Rich, for the ApacheCon Planners
> >>>
> >>
>

Re: Call for presentations for ApacheCon North America 2020 now open

[Saikat Maitra]

Hello Prasad,

Yes sure, I will share the slides.

Regards,
Saikat

On Tue, Aug 4, 2020 at 9:35 PM Prasad Bhalerao 
wrote:

> Hi Saikat,
> Can you please share the slides for both presentations, streaming as well
> as ignite internals?
> Thanks,
> Prasad
>
> On Wed 5 Aug, 2020, 7:10 AM Saikat Maitra 
>> Hi,
>>
>> I learned that my proposal for talk about Data Streaming using Apache Ignite
>> and Apache Flink has been accepted.
>>
>> I have not yet received the schedule yet. I will share as soon as I have
>> it.
>>
>> Regards,
>> Saikat
>>
>> On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra 
>> wrote:
>>
>>> Hi Denis,
>>>
>>> Thank you for your email. I have submitted a talk about Data Streaming
>>> using Apache Ignite and Apache Flink.
>>>
>>> I would also like to co-present on Ignite internals and usecases deep
>>> dive.
>>>
>>> Regards,
>>> Saikat
>>>
>>> On Wed, Jan 22, 2020 at 6:22 PM Denis Magda  wrote:
>>>
 Igniters,

 I was submitting an Ignite talk to the conference and found out that
 this time ASF created a separate category for Ignite-specific proposals.
 You can see an abstract submitted by me:
 https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing

 Who else is ready to submit? It can be a deep-dive about Ignite
 internals or Ignite use case overview. We can co-present. Also, GridGain is
 ready to sponsor your trip if the talk is accepted.



 -
 Denis


 On Tue, Jan 21, 2020 at 5:22 PM Denis Magda  wrote:

> Ignite folks, just bringing to your attention and encourage anybody
> interested to submit an Ignite-related session. Both Alex Zinoviev and I
> presented at ApacheCons the previous year -- the events are worth 
> attending
> and speaking at.
>
> -
> Denis
>
>
> -- Forwarded message -
> From: Rich Bowen 
> Date: Tue, Jan 21, 2020 at 7:06 AM
> Subject: Call for presentations for ApacheCon North America 2020 now
> open
> To: plann...@apachecon.com 
>
>
> Dear Apache enthusiast,
>
> (You’re receiving this message because you are subscribed to one or
> more
> project mailing lists at the Apache Software Foundation.)
>
> The call for presentations for ApacheCon North America 2020 is now
> open
> at https://apachecon.com/acna2020/cfp
>
> ApacheCon will be held at the Sheraton, New Orleans, September 28th
> through October 2nd, 2020.
>
> As in past years, ApacheCon will feature tracks focusing on the
> various
> technologies within the Apache ecosystem, and so the call for
> presentations will ask you to select one of those tracks, or “General”
> if the content falls outside of one of our already-organized tracks.
> These tracks are:
>
> Karaf
> Internet of Things
> Fineract
> Community
> Content Delivery
> Solr/Lucene (Search)
> Gobblin/Big Data Integration
> Ignite
> Observability
> Cloudstack
> Geospatial
> Graph
> Camel/Integration
> Flagon
> Tomcat
> Cassandra
> Groovy
> Web/httpd
> General/Other
>
> The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time).
>
> Submit early, submit often, at https://apachecon.com/acna2020/cfp
>
> Rich, for the ApacheCon Planners
>

Re: Enabling swapPath causes invoking shutdown hook

[38797715]

Hi Ilya,

If so, there are two ways to implement ignite's swap space:
1. maxSize > physical memory, which will use the swap mechanism of the 
OS, can be used *vm.swappiness* Adjust.
2. Configure the *swapPath* property, which is implemented by Ignite 
itself, is independent of the OS and has no optimization parameters.


There's a choice between these two models, right? Then I think there may 
be many problems in the description of the document. I hope you can 
check it again:

https://apacheignite.readme.io/docs/swap-space

After our initial testing, the performance of swap space is much better 
than native persistence, so I think this pattern is valuable in some 
scenarios.


在 2020/8/4 下午10:16, Ilya Kasnacheev 写道:

Hello!

From the docs:

To avoid this situation with the swapping capabilities, you need to :

  * Set |maxSize = bigger_ than_RAM_size|, in which case, the OS will
take care of the swapping.
  * Enable swapping by setting the
|DataRegionConfiguration.swapPath| property.


I actually think these are either-or. You should either do the first 
(and configure OS swapping) or the second part.


Having said that, I recommend setting proper Native Persistence instead.

Regards,
--
Ilya Kasnacheev


сб, 25 июл. 2020 г. в 04:49, 38797715 <38797...@qq.com 
>:


Hi,

https://apacheignite.readme.io/docs/swap-space


According to the above document, if the physical memory is small,
you can solve this problem by opening the swap space,The specific
method is to configure maxSize to a larger value (i.e. larger than
the physical memory), and the swapPath property needs to be
configured.

But from the test results, the node is terminated.

I think the correct result should be that even if the amount of
data exceeds the physical memory, the node should still be able to
run normally, but the data is exchanged to the disk.

I want to know what parameters affect the behavior of this
configuration? *vm.swappiness* or others?

在 2020/7/24 下午9:55, aealexsandrov 写道:

Hi,

Can you please clarify your expectations? You expected that JVM process will
be killed instead of gracefully stopping? What you are going to achieve?

BR,
Andrei



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

Re: Call for presentations for ApacheCon North America 2020 now open

[Prasad Bhalerao]

Hi Saikat,
Can you please share the slides for both presentations, streaming as well
as ignite internals?
Thanks,
Prasad

On Wed 5 Aug, 2020, 7:10 AM Saikat Maitra  Hi,
>
> I learned that my proposal for talk about Data Streaming using Apache Ignite
> and Apache Flink has been accepted.
>
> I have not yet received the schedule yet. I will share as soon as I have
> it.
>
> Regards,
> Saikat
>
> On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra 
> wrote:
>
>> Hi Denis,
>>
>> Thank you for your email. I have submitted a talk about Data Streaming
>> using Apache Ignite and Apache Flink.
>>
>> I would also like to co-present on Ignite internals and usecases deep
>> dive.
>>
>> Regards,
>> Saikat
>>
>> On Wed, Jan 22, 2020 at 6:22 PM Denis Magda  wrote:
>>
>>> Igniters,
>>>
>>> I was submitting an Ignite talk to the conference and found out that
>>> this time ASF created a separate category for Ignite-specific proposals.
>>> You can see an abstract submitted by me:
>>> https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing
>>>
>>> Who else is ready to submit? It can be a deep-dive about Ignite
>>> internals or Ignite use case overview. We can co-present. Also, GridGain is
>>> ready to sponsor your trip if the talk is accepted.
>>>
>>>
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Tue, Jan 21, 2020 at 5:22 PM Denis Magda  wrote:
>>>
 Ignite folks, just bringing to your attention and encourage anybody
 interested to submit an Ignite-related session. Both Alex Zinoviev and I
 presented at ApacheCons the previous year -- the events are worth attending
 and speaking at.

 -
 Denis


 -- Forwarded message -
 From: Rich Bowen 
 Date: Tue, Jan 21, 2020 at 7:06 AM
 Subject: Call for presentations for ApacheCon North America 2020 now
 open
 To: plann...@apachecon.com 


 Dear Apache enthusiast,

 (You’re receiving this message because you are subscribed to one or
 more
 project mailing lists at the Apache Software Foundation.)

 The call for presentations for ApacheCon North America 2020 is now open
 at https://apachecon.com/acna2020/cfp

 ApacheCon will be held at the Sheraton, New Orleans, September 28th
 through October 2nd, 2020.

 As in past years, ApacheCon will feature tracks focusing on the various
 technologies within the Apache ecosystem, and so the call for
 presentations will ask you to select one of those tracks, or “General”
 if the content falls outside of one of our already-organized tracks.
 These tracks are:

 Karaf
 Internet of Things
 Fineract
 Community
 Content Delivery
 Solr/Lucene (Search)
 Gobblin/Big Data Integration
 Ignite
 Observability
 Cloudstack
 Geospatial
 Graph
 Camel/Integration
 Flagon
 Tomcat
 Cassandra
 Groovy
 Web/httpd
 General/Other

 The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time).

 Submit early, submit often, at https://apachecon.com/acna2020/cfp

 Rich, for the ApacheCon Planners

>>>

Re: Call for presentations for ApacheCon North America 2020 now open

[Saikat Maitra]

Hi,

I learned that my proposal for talk about Data Streaming using Apache Ignite
and Apache Flink has been accepted.

I have not yet received the schedule yet. I will share as soon as I have it.

Regards,
Saikat

On Wed, Jan 22, 2020 at 8:09 PM Saikat Maitra 
wrote:

> Hi Denis,
>
> Thank you for your email. I have submitted a talk about Data Streaming
> using Apache Ignite and Apache Flink.
>
> I would also like to co-present on Ignite internals and usecases deep dive.
>
> Regards,
> Saikat
>
> On Wed, Jan 22, 2020 at 6:22 PM Denis Magda  wrote:
>
>> Igniters,
>>
>> I was submitting an Ignite talk to the conference and found out that this
>> time ASF created a separate category for Ignite-specific proposals. You can
>> see an abstract submitted by me:
>> https://drive.google.com/file/d/1woaEOWaIFxN8UIJ7nvFbYoc53mYsUsSN/view?usp=sharing
>>
>> Who else is ready to submit? It can be a deep-dive about Ignite internals
>> or Ignite use case overview. We can co-present. Also, GridGain is ready to
>> sponsor your trip if the talk is accepted.
>>
>>
>>
>> -
>> Denis
>>
>>
>> On Tue, Jan 21, 2020 at 5:22 PM Denis Magda  wrote:
>>
>>> Ignite folks, just bringing to your attention and encourage anybody
>>> interested to submit an Ignite-related session. Both Alex Zinoviev and I
>>> presented at ApacheCons the previous year -- the events are worth attending
>>> and speaking at.
>>>
>>> -
>>> Denis
>>>
>>>
>>> -- Forwarded message -
>>> From: Rich Bowen 
>>> Date: Tue, Jan 21, 2020 at 7:06 AM
>>> Subject: Call for presentations for ApacheCon North America 2020 now open
>>> To: plann...@apachecon.com 
>>>
>>>
>>> Dear Apache enthusiast,
>>>
>>> (You’re receiving this message because you are subscribed to one or more
>>> project mailing lists at the Apache Software Foundation.)
>>>
>>> The call for presentations for ApacheCon North America 2020 is now open
>>> at https://apachecon.com/acna2020/cfp
>>>
>>> ApacheCon will be held at the Sheraton, New Orleans, September 28th
>>> through October 2nd, 2020.
>>>
>>> As in past years, ApacheCon will feature tracks focusing on the various
>>> technologies within the Apache ecosystem, and so the call for
>>> presentations will ask you to select one of those tracks, or “General”
>>> if the content falls outside of one of our already-organized tracks.
>>> These tracks are:
>>>
>>> Karaf
>>> Internet of Things
>>> Fineract
>>> Community
>>> Content Delivery
>>> Solr/Lucene (Search)
>>> Gobblin/Big Data Integration
>>> Ignite
>>> Observability
>>> Cloudstack
>>> Geospatial
>>> Graph
>>> Camel/Integration
>>> Flagon
>>> Tomcat
>>> Cassandra
>>> Groovy
>>> Web/httpd
>>> General/Other
>>>
>>> The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time).
>>>
>>> Submit early, submit often, at https://apachecon.com/acna2020/cfp
>>>
>>> Rich, for the ApacheCon Planners
>>>
>>

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

[akurbanov]

Hello,

This case seems to be correct, it logs the event of client state updated
from DISCONNECTED to RECONNECTED because the node succeeded to join the
topology back within some time, the node was not segmented from the
topology. What timeouts do you use in your nodes configuration?

I would suggest to perform a test with different timeouts and check that if
node stays offline for too long, the node gets segmented from the topology.

Best regards,
Anton



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

Re: IgniteTxOptimisticCheckedException

[Ilya Kasnacheev]

Hello!

Optimistic transactions are supposed to be retry-able. Why won't you retry
such transactions upon getting the exception?

Regards,
-- 
Ilya Kasnacheev


пт, 31 июл. 2020 г. в 10:56, marble.zh...@coinflex.com <
marble.zh...@coinflex.com>:

> Hi Guru,
>
> We met below two kinds of Optimistic exceptions when doing the
> transactions,
> we use OPTIMISTIC and SERIALIZABLE isolation, do you have any suggestions,
> or if we change to PESSIMISTIC, any risks on that, such as performance or
> other exceptions? thanks.
>
> {"log":"Caused by:
> org.apache.ignite.internal.transactions.IgniteTxOptimisticCheckedException:
> Failed to prepare transaction, read/write conflict [key=92-USD,
> keyCls=java.lang.String, val=Balance(accountId=92,
> instrumentId=USD,
> quantity=2307.812920282500, reserved=0, lastUpdated=2020-07-31
> 03:10:36.889, lastUpdatedEvent=TRANSFER, tradeType=null),
> valCls=ignite.entity.Balance, cache=Balance, thread=IgniteThread
> [compositeRwLockIdx=7, stripe=4, plc=-1, holdsTopLock=false,
> forbiddenToRequestBinaryMetadata=false,
>
> name=sys-stripe-4-#5]]\n","stream":"stderr","time":"2020-07-31T03:10:36.953698541Z"}
>
>
> {"log":"Caused by:
> org.apache.ignite.internal.transactions.IgniteTxOptimisticCheckedException:
> Failed to prepare transaction (lock conflict): GridDhtTxLocal
> [nearNodeId=7e3589a0-c829-42a2-8fb4-115c57ba64f5,
> nearFutId=3077cc2a371-7364caca-357e-49f2-840e-a101e7c64fa8, nearMiniId=1,
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion
> [topVer=207644034, order=1596164732765, nodeOrder=2], lb=null,
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false,
> nearNodes=KeySetView [], dhtNodes=KeySetView [], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxStateImpl [activeCacheIds=[1325467324],
> recovery=false, mvccEnabled=false, mvccCachingCacheIds=[], txMap=ArrayList
> [IgniteTxEntry [txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=45,
> val=92-USD, hasValBytes=true], cacheId=1325467324], val=[op=UPDATE,
> val=ignite.entity.Balance [idHash=1055847466, hash=-1577210704,
> accountId=92, lastUpdated=2020-07-31 03:10:36.943,
> quantity=1204.259920282500, reserved=null, instrumentId=USD,
> tradeType=null, lastUpdatedEvent=TRANSFER]], prevVal=[op=NOOP, val=null],
> oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
> filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=false,
> entry=GridDhtCacheEntry [rdrs=ReaderId[] [], part=45,
> super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=45, val=92-USD, hasValBytes=true],
> val=null, ver=GridCacheVersion [topVer=207644034, order=1596164732830,
> nodeOrder=1], hash=-148923086, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=2147483647, order=0, nodeOrder=0]],
> flags=2]]], prepared=1, locked=false, nodeId=null, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
> serReadVer=GridCacheVersion [topVer=207644034, order=1596164732670,
> nodeOrder=1], xidVer=null], IgniteTxEntry [txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [part=504, val=1380978-USD, hasValBytes=true],
> cacheId=1325467324], val=[op=UPDATE, val=ignite.entity.Balance
> [idHash=577969755, hash=-2001853349, accountId=1380978,
> lastUpdated=2020-07-31 03:10:36.95, quantity=13614077.57624000,
> reserved=null, instrumentId=USD, tradeType=null,
> lastUpdatedEvent=TRANSFER]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP,
> val=null], entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1,
> conflictVer=null, explicitVer=null, dhtVer=null,
> filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=false,
> entry=GridDhtCacheEntry [rdrs=ReaderId[] [], part=504,
> super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=504, val=1380978-USD, hasValBytes=true],
> val=null, ver=GridCacheVersion [topVer=0, order=0, nodeOrder=0],
> hash=1004605465, extras=null, flags=0]]], prepared=0, locked=false,
> nodeId=null, locMapped=false, expiryPlc=null, transferExpiryPlc=false,
> flags=0, partUpdateCntr=0, serReadVer=GridCacheVersion [topVer=207644034,
> order=1596164732670, nodeOrder=1], xidVer=null]]], super=IgniteTxAdapter
> [xidVer=GridCacheVersion [topVer=207644034, order=1596164732835,
> nodeOrder=1], writeVer=null, implicit=false, loc=true, threadId=146,
> startTime=1596165036958, nodeId=990fbcf8-4105-4aee-b03f-bef9141f5533,
> startVer=GridCacheVersion [topVer=207644034, order=1596164732835,
> nodeOrder=1], endVer=null, isolation=SERIALIZABLE, concurrency=OPTIMISTIC,
> timeout=0, sysInvalidate=false, sys=false, plc=2, commitVer=null,
> finalizing=NONE, invalidParts=null, state=MARKED_ROLLBACK, timedOut=false,
> topVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
> 

Re: question about collation with an ignite set

[Ilya Kasnacheev]

Hello!

Why don't you set cacheMode to REPLICATED?

Partitions in replicated caches should not be lost.

Regards,
-- 
Ilya Kasnacheev


пн, 3 авг. 2020 г. в 08:35, scottmf :

> hi, If I setup my *Ignite Set* as specified below what will happen when a
> node leaves the cluster topology forever? Will I simply lose the elements
> which are stored locally - via collation = true - or will I run into
> problems?
>
> Overall I want the all cluster nodes to be aware of all elements in the
> distributed set. If a node leaves the topology i want the elements
> associated with said node to simply disappear from the set.
>
> Will this configuration achieve that functionality?
>
> CollectionConfiguration cacheConfiguration = new 
> CollectionConfiguration();
> cacheConfiguration.setCollocated(true);
> cacheConfiguration.setBackups(0);
> cacheConfiguration.setGroupName("grp");
> this.countQueriesSet = ignite.set("myset", cacheConfiguration);
>
>
> --
> Sent from the Apache Ignite Users mailing list archive
>  at Nabble.com.
>

Re: What does all partition owners have left the grid, partition data has been lost mean?

[Ilya Kasnacheev]

Hello!

What is your baseline topology at this moment? It means just that: you have
lost enough nodes of your distributed grid that data is nowhere to be found
now.

Regards,
-- 
Ilya Kasnacheev


пн, 3 авг. 2020 г. в 19:12, John Smith :

> I get the below exception on my client...
>
> #1 I rebooted the cache nodes error still continued.
> #2 restarted the client node error went away.
> #3 this seems to happen every few weeks.
> #4 is there some sort of timeout values and retries I can put?
> #5 cache operations seem to block when rebooting the nodes (I have 3
> nodes). Is there a way not to block?
>
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute cache operation (all partition owners have left the grid,
> partition data has been lost) [cacheName=xx, part=273, key=16479796986]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:157)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$executeAsync$394d953f$1(IgniteCacheRepository.java:59)
> at
> org.apache.ignite.internal.util.future.AsyncFutureListener$1.run(AsyncFutureListener.java:53)
> at
> com.xx.common.vertx.ext.data.impl.VertxIgniteExecutorAdapter.lambda$execute$0(VertxIgniteExecutorAdapter.java:18)
> at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
> at
> io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute cache operation (all partition owners have left the grid,
> partition data has been lost) [cacheName=xx, part=273, key=16479796986]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validatePartitionOperation(GridDhtTopologyFutureAdapter.java:161)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:116)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$26.apply(GridDhtAtomicCache.java:1146)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$26.apply(GridDhtAtomicCache.java:1144)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1144)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:641)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2828)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2809)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAsync0(IgniteCacheProxyImpl.java:1125)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAsync(IgniteCacheProxyImpl.java:1114)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAsync(GatewayProtectedCacheProxy.java:832)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$put$0(IgniteCacheRepository.java:27)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.executeAsync(IgniteCacheRepository.java:55)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.put(IgniteCacheRepository.java:27)
> at com.xx.service.impl.xx.put(xx.java:52)
> at com.xx.impl.xx.moV1(xx.java:134)
> at com.xx.api.xx.moV1(xx.java:100)
> at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1034)
> at
> 

Re: Ignite client node hangs while IgniteAtomicLong is created

[Ilya Kasnacheev]

Hello!

Can you collect thread dumps from all nodes once you get them hanging?

Can you throw together a reproducer project?

Regards,
-- 
Ilya Kasnacheev


вт, 4 авг. 2020 г. в 12:51, Ilya Roublev :

> We are developing Jira cloud app using Apache Ignite both as data storage
> and as job scheduler. This is done via a standard Ignite client node. But
> we need to use Atlassian Connect Spring Boot to be able to communicate with
> Jira. In short, all is done exactly as in our article Boosting Jira Cloud
> app development with Apache Ignite
> .
> At first we used simple Ignite JDBC driver
>  just for Atlassian
> Connect Spring Boot along with a separate Ignite client node for our own
> purposes. But this turned out to be very unstable being deployed in our
> local Kubernetes cluster (built via Kubespray) due to constant exceptions
>
> java.net.SocketException: Connection reset
>
> occuring from time to time (in fact, this revealed only in our local
> cluster, in AWS EKS all worked fine). To make all this more stable we tried
> to use Ignite JDBC Client driver
>  exactly as
> described in the article mentioned above. Thus, now our backend uses two
> Ignite client nodes per single JVM: the first one for JDBC used by
> Atlassian Connect Spring Boot, the second one for our own purposes. This
> solution turned out to be good enough, because our app works now very
> stable both in our local cluster and in AWS EKS. But when we deploy our app
> in Docker for testing and developing purposes, our Ignite client nodes hang
> from time to time. After some investigation we were able to see that this
> occurs exactly at the instant when an object of IgniteAtomicLong is
> created. Below are logs both for successful initialization of our app and
> for the case when Ignite client node hanged. Logs when all is ok
> ignite-appclientnode-successful.log
> 
> ignite-jdbcclientnode-successful.log
> 
>  Logs
> when both client node hang ignite-appclientnode-failed.log
> 
> ignite-jdbcclientnode-failed.log
> 
>  Some
> analysis and questions From logs one can see that caches default,
> tenants, atlassian_host_audit, SQL_PUBLIC_ATLASSIAN_HOST are manipulated,
> in fact, default is given in client configuration: client.xml
> ,
> the cache SQL_PUBLIC_ATLASSIAN_HOST contains atlassian_host table mentioned
> in Boosting Jira Cloud app development with Apache Ignite
> 
> and is created in advance even before the app starts. Further,
> atlassian_host_audit is a copy of atlassian_host, in any case it is not yet
> created when the app hangs. What concerns other entities processed by
> Ignite, they are created by the following code:
>
> CacheConfiguration tenantCacheCfg = new 
> CacheConfiguration<>();
> tenantCacheCfg.setName("tenants");
> tenantCacheCfg.setSqlSchema("PROD");
> tenantCacheCfg.setIndexedTypes(Long.class, Tenant.class);
> tenantCacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> tenantCacheCfg.setEncryptionEnabled(true);
>
> IgniteCache tenantCache = 
> ignite.getOrCreateCache(tenantCacheCfg);
> IgniteAtomicLong idGen = ignite.atomicLong("PROD_tenants_seq", 0, 
> true);
>
> And from the logs of the app itself it is clear that the app hangs exactly
> on the last line. This is confirmed by the fact that the in
> ignite-jdbcclientnode-successful.log we have the following lines:
>
> [2020-07-31 09:52:12,237][INFO ][exchange-worker-#43][GridCacheProcessor] 
> Started cache [name=ignite-sys-atomic-cache@default-ds-group, id=1481046058, 
> group=default-ds-group, dataRegionName=null, mode=PARTITIONED, 
> atomicity=TRANSACTIONAL, backups=1, mvcc=false]
> [2020-07-31 09:52:12,263][INFO ][exchange-worker-#43][time] Finished exchange 
> init [topVer=AffinityTopologyVersion [topVer=6, minorTopVer=2], crd=false]
> [2020-07-31 09:52:12,631][INFO 
> ][sys-#109%ignite-jdbc-driver-e1f562e1-5127-4f55-80d2-18661982769c%][GridDhtPartitionsExchangeFuture]
>  Received full message, will finish exchange 
> [node=c7d1e091-da48-46a3-98ea-6971e8a811e0, resVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=2]]
> [2020-07-31 09:52:12,634][INFO ][sys-#54][GridDhtPartitionsExchangeFuture] 
> Received full 

Re: Reconnect is not allowed due to applied throttling

[Alex Plehanov]

Hello,

Ignite thin client applies connection throttling if you have several
failed attempts to connect to some server (this server will be skipped for
some time to avoid waiting for connection timeouts on each attempt to
connect, the client will try to connect to the next servers if they are
configured).
By default, if your server is unavailable and you have 3 in a row
ClientConnectionException during 30 seconds on the same channel throttling
will be applied. The next real attempt to connect to this server will be
made after 30 seconds from the time of the first exception.
Connection throttling parameters can be changed by ClientConfiguration (see
reconnectThrottlingPeriod and reconnectThrottlingRetries).


вт, 4 авг. 2020 г. в 13:37, AravindJP :

> Hi ,
> I am getting below exception after running an Ignite client running
> continuously for 48 hrs . My client is running on java (spring boot) . I am
> using singleton  instance of IgniteClient object to connect and persist
> data.
>
> Ignite version 2.8.0
>
> 020-08-04 10:02:18.520 ERROR 1 --- [sub-subscriber3]: Exception with
> org.
> apache.ignite.client.ClientConnectionException: Reconnect is not allowed
> due
> to applied throttling
> at
>
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableCha
> nnel.java:448)
> at
>
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableCha
> nnel.java:439)
> at
>
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.access$100(ReliableChannel.jav
> a:395)
> at
>
> org.apache.ignite.internal.client.thin.ReliableChannel.channel(ReliableChannel.java:318)
> at
>
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:158)
> at
>
> org.apache.ignite.internal.client.thin.ReliableChannel.request(ReliableChannel.java:187)
> at
>
> org.apache.ignite.internal.client.thin.TcpClientCache.putAll(TcpClientCache.java:210)
> a
>
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: integrated with Ignite and HBase

[akurbanov]

Hello,

Google immediately gives this repo in search:
https://github.com/bakdata/ignite-hbase

It's 2017, but could be used as a base for your implementation or give you
an idea how to do this.

The cache store implementation is very straightforward, you just need to
delegate the calls to the underlying database.

https://apacheignite.readme.io/docs/3rd-party-store#custom-cachestore

Best regards,
Anton



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

Re: Reconnect is not allowed due to applied throttling

[akurbanov]

Hello,

This was implemented as a part of
https://issues.apache.org/jira/browse/IGNITE-11898.

Please check the javadocs for the ClientConfiguration class: 
https://github.com/apache/ignite/commit/d72a123e122ffe1b4f715f98c2db5d79293f0c90
https://github.com/apache/ignite/blob/d72a123e122ffe1b4f715f98c2db5d79293f0c90/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java

See reconnectThrottlingPeriod, reconnectThrottlingRetries.

Best regards,
Anton



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

Re: 2.8.1 - Loading Plugin Provider - Conflicting documentation

[Ilya Kasnacheev]

Hello!

You do this with IgniteConfiguration.setPluginConfiguration().

Regards,
-- 
Ilya Kasnacheev


вт, 28 июл. 2020 г. в 13:04, VeenaMithare :

> Okay.
>
> >>   The recommended way is to use the service provider as detailed here:
>
> How do we pass configuration for the provider in this approach.
>
> regards,
> Veena.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: [External]Re: Node left from running cluster due to org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException: Runtime failure on search row

[Ilya Kasnacheev]

Hello!

You can't do that in runtime, but you can certainly remove index.bin as
bulk operation.

Regards,
-- 
Ilya Kasnacheev


вт, 28 июл. 2020 г. в 08:48, Kamlesh Joshi :

> Thanks for the update Andrei. We upgraded from 2.6.0 to 2.7.6.
>
> We followed the same approach and it worked properly.
>
> Can we change INLINE SIZE for every cache at runtime ?
>
> Thanks and Regards,
> Kamlesh Joshi
>
>
> -Original Message-
> From: aealexsandrov 
> Sent: 27 July 2020 19:35
> To: user@ignite.apache.org
> Subject: [External]Re: Node left from running cluster due to
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on search row
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> Hi,
>
> Can you please clarify the version from which you upgraded?
>
> I know that it's possible that if you used a pretty old version then you
> should also rebuild your indexes during the upgrade because inline size
> calculation logic was changed in last releases.
>
> It can be done by removing index.bin files. So the logic should be the
> following:
>
> 1)Stop the Ignite nodes.
> 2)Remove index.bin files from
> $IGNITE_HOME/db///index.bin
> 3)Start Ignite nodes one by one. For each node wait for the following
> message:
>
> [2020-05-29 07:55:04,984][INFO
> ][build-idx-runner-#61][GridCacheDatabaseSharedManager] Indexes rebuilding
> completed for all caches.
>
> I guess that it can help you with your upgrade. Please test it before
> applying it to your production because the reason can be different.
>
> BR,
> Andrei
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
> "Confidentiality Warning: This message and any attachments are intended
> only for the use of the intended recipient(s).
> are confidential and may be privileged. If you are not the intended
> recipient. you are hereby notified that any
> review. re-transmission. conversion to hard copy. copying. circulation or
> other use of this message and any attachments is
> strictly prohibited. If you are not the intended recipient. please notify
> the sender immediately by return email.
> and delete this message and any attachments from your system.
>
> Virus Warning: Although the company has taken reasonable precautions to
> ensure no viruses are present in this email.
> The company cannot accept responsibility for any loss or damage arising
> from the use of this email or attachment."
>
>

Re: Enabling swapPath causes invoking shutdown hook

[Ilya Kasnacheev]

Hello!

>From the docs:

To avoid this situation with the swapping capabilities, you need to :

   - Set maxSize = bigger_ than_RAM_size, in which case, the OS will take
   care of the swapping.
   - Enable swapping by setting the DataRegionConfiguration.swapPath
property.


I actually think these are either-or. You should either do the first (and
configure OS swapping) or the second part.

Having said that, I recommend setting proper Native Persistence instead.

Regards,
-- 
Ilya Kasnacheev


сб, 25 июл. 2020 г. в 04:49, 38797715 <38797...@qq.com>:

> Hi,
>
> https://apacheignite.readme.io/docs/swap-space
>
> According to the above document, if the physical memory is small, you can
> solve this problem by opening the swap space,The specific method is to
> configure maxSize to a larger value (i.e. larger than the physical memory),
> and the swapPath property needs to be configured.
>
> But from the test results, the node is terminated.
>
> I think the correct result should be that even if the amount of data
> exceeds the physical memory, the node should still be able to run normally,
> but the data is exchanged to the disk.
>
> I want to know what parameters affect the behavior of this configuration?
> *vm.swappiness* or others?
> 在 2020/7/24 下午9:55, aealexsandrov 写道:
>
> Hi,
>
> Can you please clarify your expectations? You expected that JVM process will
> be killed instead of gracefully stopping? What you are going to achieve?
>
> BR,
> Andrei
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
>

Re: Block until partition map exchange is complete

[Ilya Kasnacheev]

Hello!

It is supposed to be fixed in 2.8. Did you check that?

Thanks.
-- 
Ilya Kasnacheev


ср, 22 июл. 2020 г. в 12:24, ssansoy :

> Hi, could the behaviour I have observed be captured by this bug:
>
> https://issues.apache.org/jira/browse/IGNITE-9841
>
> "Note, ScanQuery exhibits the same behavior - returns partial results when
> some partitions are lost.  Not sure if solution would be related or needs
> to
> be tracked and fixed under a separate ticket."
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Reconnect is not allowed due to applied throttling

[AravindJP]

Hi ,
I am getting below exception after running an Ignite client running
continuously for 48 hrs . My client is running on java (spring boot) . I am
using singleton  instance of IgniteClient object to connect and persist
data. 

Ignite version 2.8.0 

020-08-04 10:02:18.520 ERROR 1 --- [sub-subscriber3]: Exception with
org.
apache.ignite.client.ClientConnectionException: Reconnect is not allowed due
to applied throttling
at
org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableCha
nnel.java:448)
at
org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableCha
nnel.java:439)
at
org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.access$100(ReliableChannel.jav
a:395)
at
org.apache.ignite.internal.client.thin.ReliableChannel.channel(ReliableChannel.java:318)
at
org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:158)
at
org.apache.ignite.internal.client.thin.ReliableChannel.request(ReliableChannel.java:187)
at
org.apache.ignite.internal.client.thin.TcpClientCache.putAll(TcpClientCache.java:210)
a






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

Ignite client node hangs while IgniteAtomicLong is created

[Ilya Roublev]

We are developing Jira cloud app using Apache Ignite both as data storage and
as job scheduler. This is done via a standard Ignite client node. But we
need to use Atlassian Connect Spring Boot to be able to communicate with
Jira. In short, all is done exactly as in our article  Boosting Jira Cloud
app development with Apache Ignite

 
.At first we used simple  Ignite JDBC driver
   just for Atlassian
Connect Spring Boot along with a separate Ignite client node for our own
purposes. But this turned out to be very unstable being deployed in our
local Kubernetes cluster (built via Kubespray) due to constant exceptions 
occuring from time to time (in fact, this revealed only in our local
cluster, in AWS EKS all worked fine). To make all this more stable we tried
to use  Ignite JDBC Client driver
   exactly as
described in the article mentioned above. Thus, now our backend uses two
Ignite client nodes per single JVM: the first one for JDBC used by Atlassian
Connect Spring Boot, the second one for our own purposes.This solution
turned out to be good enough, because our app works now very stable both in
our local cluster and in AWS EKS. But when we deploy our app in Docker for
testing and developing purposes, our Ignite client nodes hang from time to
time. After some investigation we were able to see that this occurs exactly
at the instant when an object of IgniteAtomicLong is created. Below are logs
both for successful initialization of our app and for the case when Ignite
client node hanged.
Logs when all is ok
ignite-appclientnode-successful.log

  
ignite-jdbcclientnode-successful.log

  
Logs when both client node hang
ignite-appclientnode-failed.log

  
ignite-jdbcclientnode-failed.log

  
Some analysis and questions
>From logs one can see that caches default, tenants, atlassian_host_audit,
SQL_PUBLIC_ATLASSIAN_HOST  are manipulated, in fact, default is given in
client configuration:  client.xml
  ,
the cache SQL_PUBLIC_ATLASSIAN_HOST contains atlassian_host table mentioned
in  Boosting Jira Cloud app development with Apache Ignite

  
and is created in advance even before the app starts. Further,
atlassian_host_audit is a copy of atlassian_host, in any case it is not yet
created when the app hangs.What concerns other entities processed by Ignite,
they are created by the following code:And from the logs of the app itself
it is clear that the app hangs exactly on the last line. This is confirmed
by the fact that the in ignite-jdbcclientnode-successful.log we have the
following lines:while in ignite-jdbcclientnode-failed.log all the lines
starting the first time the cache ignite-sys-atomic-cache@default-ds-group
(the cache used for atomics) was mentioned are as follows:In particular, the
following line from ignite-jdbcclientnode-successful.log is absent in
ignite-jdbcclientnode-failed.log:But it should be noted that for the failure
case there are other client nodes executed in separate containers executed
simultaneously with the backend app and with the same code creating the
cache tenants and IgniteAtomicLong idGen what concerns the logs below (see
above for the code), their node ids are 653143b2-6e80-49ff-9e9a-ae10237b32e8
and 30e24e06-ab76-4053-a36e-548e87ffe5d1, respectively (and it can be easily
seen that all the lines in ignite-jdbcclientnode-failed.log with
ignite-sys-atomic-cache@default-ds-group relate namely to these nodes), the
logs for the time segment when the code with tenants and idGen is executed
are as follows:And the code creating tenants and idGen is executed
successfully. But is it possible that this simultaneous creation of idGen
may hang some nodes? (As for the case when all was executed successfully,
there we also have two separate containers, but they are executed strictly
after all is done in the main app, so the simultaneous execution of the same
code in several client nodes may be the reason of hanging, isn't it?) And in
the case the answer is positive, what is to do? Certainly it is possible to
set a delay for those separate containers, but this does not look as a
rather safe solution...And we have another small question, when we have two
separate client nodes in our app, both configured for logging, why starting
from some instant only the 

integrated with Ignite and HBase

[38797715]

Hi community,

Does the community have a demo integrated with Ignite and HBase? Such as 
the implementation of CacheStore or other implementation patterns?