Re: Ignite SqlFieldQuery Unicode Characters Support

[Ravi Makwana]

Hi,

We have started our ignite nodes (server & client) with mentioned jvm
parameter and it works fine.

Thanks for the quick response.

Regards,
Ravi Makwana

On Mon, 8 Jun 2020 at 18:49, Ilya Kasnacheev 
wrote:

> Hello!
>
> I have met an error like this one, and my recommendation is that on all
> nodes, client and server, you should set file.encoding to the same value
> (UTF-8 usually, however CJK multi-byte encodings should also work).
>
> Make sure all of your JVMs are launched with -Dfile.encoding=UTF-8.
> ignite.sh should do that already. Make sure you are using the same on
> Windows and Linux.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 5 июн. 2020 г. в 14:31, Ravi Makwana :
>
>> Hi,
>>
>> We are using Apache ignite version 2.7 and we have one node cluster with
>> 150 caches out of 150 We have 1 cache which contains Unicode characters
>> like Chinese language.
>>
>> Server node is running on Linux OS & Client node is running on Windows OS.
>>
>> Client side we are using sqlquery & sqlfieldquery to fetch and put &
>> data-streamer to insert data using .net ignite apis.
>>
>> In ignite cache,we have AddressFull property which contains Unicode
>> characters like Chinese language so while inserting we have inserted
>> specified data into AddressFull property which is mentioned below.
>>
>> *"北京市朝阳区安贞西里四区甲1号, 北京, 中国, 100011"*
>>
>> While fetching data from ignite cache we have observed that we are not
>> getting inserted data properly.
>>
>> We have performed below mentioned sqlquery using SqlFieldQuery.
>>
>> SELECT HotelCode,AddressFull FROM HotelOtherLanguageMasterModel WHERE
>> HotelCode = '12345'
>>
>> We got below mentioned result data for AddressFull property.
>>
>> *"北京市�阳区安贞西里四区甲1�, 北京, 中国, 100011"*
>>
>> Based on this test we have couple of questions on the same.
>>
>> 1) Is SqlFieldQuery .net api supporting Unicode characters?
>> 2) If Yes, How do we overcome this issue?
>>
>> Regards,
>> Ravi Makwana
>>
>

Re: How to fix Ignite node segmentation without restart

[Evgenii Zhuravlev]

>I do not want to restart it and I cannot do a failover because a network
issue just happened and the stand-by may be invalid. The fix is to always
restart the slave.
You can enable CacheWriteSynchronizationMode.FULL_SYNC and there will be no
differences between primary and backup partitions. In this case, you can
just restart your master node - the backup node will have valid data.

There is no way to join nodes after segmentation without restarting one of
the nodes.

Evgenii



вт, 16 июн. 2020 г. в 06:26, Actarus :

> Hello,
>
> I'm running Apache Ignite (2.4.0) embedded into a java application that
> runs
> in a master/slave architecture. This means that there are only ever two
> nodes in a grid, in FULL_SYNC, REPLICATED mode. Only the master application
> writes to the grid, the slave only reads from it when it gets promoted to
> master on a failover.
>
> In such an architecture, network segmentation issues mean different things.
> Typically I see that for handling segmentation, the node that experienced
> the issue would need to be restarted. However in this scenario if the
> master
> is segmented, I do not want to restart it and I cannot do a failover
> because
> a network issue just happened and the stand-by may be invalid. The fix is
> to
> always restart the slave.
>
> However I notice that regardless of handling the EVT_NODE_SEGMENTED event,
> adding a SegmentationProcess, running with SegmentationPolicy.NOOP and
> having a segmentation plugin and always returning true/OK, I find that the
> node that runs in master always remains in segmented state, and it is
> impossible for it to re-join a cluster after restarting the slave node.
>
> Is there some mechanism I can use to tell the node within my master process
> to completely ignore segmentation? Or tell it that it is fine so that
> discovery can still happen after I restart the slave node? Currently I used
> port  with TcpDiscoverySpi with hard-coded addresses (master and slave
> IP addresses). When the master node is segmented (by simulating network
> issues on the command-line) it appears there's no way for the discovery to
> recover - port  is shut down, and the slave node always comes up blind
> to the master.
>
> I would appreciate any insights on this issue. Thank you.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Atomic Sequence/Auto Increment via IgniteClient - Thin Client - Ignite 2.8.1

[Denis Magda]

Hi Manesh,

Thin clients don't support this API yet.

As a workaround, see if you can implement a custom SQL function [1] and
call it from an INSERT statement issued by the thin client - "INSERT INTO
table(id, name, age) VALUES (generateIdFunction(), 'Mark', 40)". I haven't
tried this approach and not sure if it will work out. Let me know if it
solves your case.

[1] https://apacheignite-sql.readme.io/docs/custom-sql-functions

-
Denis


On Wed, Jun 17, 2020 at 9:04 AM Mahesh Renduchintala <
mahesh.renduchint...@aline-consulting.com> wrote:

> Hello,
>
> Is there a way to access ignite Atomic Sequence via thin client apis?
> We have a situation where we have thick clients (java micro-services) and
> thin clients (Spark) and both need to generate IDs for inserting data into
> tables.
>
> regards
> Mahesh
>
>
>
>

Re: Best practices for WalArchive when using EFS

[Denis Magda]

Raymond,

I agree with you that the existence of the WAL should be more than enough
to ensure data consistency.

The documentation suggests that the archives help to speed up the
rebalancing procedures (refer to the Pros and Cons of WAL Archiving
callout): https://apacheignite.readme.io/docs/write-ahead-log#wal-archive

As for this statement, "The WAL archive is used to keep WAL segments that
may be needed to recover the node after a crash", I'm not sure if it's
relevant. If Ignite supported the point-in-time-recovery feature then the
purpose of the archives would be clear - we would be able to jump back in
time to any successfully committed operation and roll back the cluster to
that moment in time. @Alexey Goncharuk, could you please clarify this
moment? It sounds like we need to revisit our documentation.

-
Denis


On Wed, Jun 17, 2020 at 4:27 AM Raymond Wilson 
wrote:

> We are deploying an Ignite application to a Kubernetes cluster in AWS EKS
> and are planning to use EFS for persistent data.
>
> I have been reading through the tuning options for the Write Ahead Log
> Archive, trying to understand if we can safely turn off the archive to save
> the IO related to copying a WAL segment to the archive when it is full.
>
> As far as I can tell, the only functional role of the archived segments
> compared to the segments present in the write ahead log is to save
> potential file system slowness in recreating new segments compared to
> overwriting an existing segment once it has been copied to the archive.
> Apart from this, a WAL with 10 segments seems to provide the same
> consistency guarantees in the event of failure as a WAL with one active
> segment and a WAL archive with 10 archived segments.
>
> As we are using EFS we do not have issues with disk space so can define an
> arbitrarily large WAL without the need to copy these files to a separate
> archive which will contend the EFS bandwidth even if copies asynchronously
> within Ignite.
>
> Is my understanding correct here with respect to the EFS use case?
>
> Thanks,
> Raymond.
>
>
>
>
> --
> 
> Raymond Wilson
> Solution Architect, Civil Construction Software Systems (CCSS)
> 11 Birmingham Drive | Christchurch, New Zealand
>
>

Re: sqlline

[Denis Magda]

You can always send a compute task via one of IgniteCompute.affinityX()
methods and run a *local* SQL query on that node:

   - affinity calls:
   
https://apacheignite.readme.io/docs/collocate-compute-and-data#affinity-call-and-run-methods
   - local SQL queries:
   https://apacheignite-sql.readme.io/docs/local-queries

My selects are complex but they do use the primary keys for the partitioned
> tables/caches participating in the query. But they perform poorly if the
> data is distributed across multiple nodes.


If the data is co-located and scattered across cluster nodes then it's
expected that Ignite will execute a query across several nodes. It's a
standard approach of distributed databases that support SQL engines. My
suggestion would be to investigate the root cause of low performance. You
just might need to configure some indexes:
https://apacheignite-sql.readme.io/docs/performance-and-debugging

-
Denis


On Wed, Jun 17, 2020 at 7:33 PM narges saleh  wrote:

> My selects are complex but they do use the primary keys for the
> partitioned tables/caches participating in the query. But they perform
> poorly if the data is distributed across multiple nodes.
>
> On Wed, Jun 17, 2020 at 8:04 PM narges saleh  wrote:
>
>> Thanks Denis. In case of selects, can I push ignite to broadcast the sql
>> to where the data is, say by using employing services deployed on the
>> targeted data nodes, or utilizing affinity calls (with the sql as part of
>> the logic)?
>>
>> On Wed, Jun 17, 2020 at 7:02 PM Denis Magda  wrote:
>>
>>> Narges,
>>>
>>> INSERTS/UPDATES/DELETES will be forwarded to primary nodes based on the
>>> value of primary keys you pass into queries. Ignite maps a primary key to a
>>> partition and, finally, to a primary node that holds that partition. All
>>> this happens transparently in Ignite. You don't need to do anything except
>>> for sending those SQL commands.
>>>
>>> As for SELECTS, most of them will be broadcasted to your server nodes
>>> unless Ignite can pre-select a sub-set of target nodes a query needs to be
>>> executed on. This optimization always takes place for simple queries when
>>> you try to get records based on the value of a primary key, such as "SELECT
>>> * FROM Table WHERE primaryKeyColumn = 2".
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jun 17, 2020 at 12:43 PM narges saleh 
>>> wrote:
>>>
 Thanks Denis. Will watch the video.
 One more question, related to SQL execution. If I issue a SQL from a
 client, how would ignite know which node to run the SQL query on? I assume
 the SQL is parsed on the server nodes, and I will still need to direct the
 SQL to be executed on the right server node (assuming that all the data is
 collocated on a single node). Am I right?

 On Wed, Jun 17, 2020 at 2:26 PM Denis Magda  wrote:

> The collocated flag is an extra optimization hint for SQL queries with
> GROUP BYs. The parameter requests to group records locally on the nodes
> that participated in the query execution. For instance, if your 
> application
> sends a query with GROUP BY to a couple of server nodes, then the nodes
> will group their portions of the result sets locally not making that the
> burden of the application that merges/reduces the result sets into one. 
> The
> description of this parameter here should be helpful as well:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>
> 
>>
>> Should I assume that if the table is defined with affinity set, then
>> compute collocation, including sql execution will happen automatically?
>
>
> That's right. You just need to set up the affinity keys and Ignite
> will take care of the rest. Btw, you might be interested in this SQL
> webinar we delivered recently. The webinar explains our SQL capabilities 
> in
> detail: https://www.youtube.com/watch?v=eYV-tNLzIts
>
> -
> Denis
>
>
> On Wed, Jun 17, 2020 at 11:28 AM narges saleh 
> wrote:
>
>> Then can you please explain what the option collocated=true for JDBC
>> url is for?
>> Should I assume that if the table is defined with affinity set, then
>> compute collocation, including sql execution will happen automatically?
>> I am sorry if this is just a basic question.
>>
>> On Wed, Jun 17, 2020 at 12:57 PM Denis Magda 
>> wrote:
>>
>>> If the data is already co-located you don't need to pass in any
>>> other parameters.
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jun 17, 2020 at 10:13 AM narges saleh 
>>> wrote:
>>>
 Hi Denis. The tables are defined with affinity keys specified. What
 I am asking whether to set the collection option when I insert or 
 query the
 data via SQL line.

 thanks

 On Wed, Jun 17, 2020 at 11:39 AM 

Re: sqlline

[narges saleh]

My selects are complex but they do use the primary keys for the partitioned
tables/caches participating in the query. But they perform poorly if the
data is distributed across multiple nodes.

On Wed, Jun 17, 2020 at 8:04 PM narges saleh  wrote:

> Thanks Denis. In case of selects, can I push ignite to broadcast the sql
> to where the data is, say by using employing services deployed on the
> targeted data nodes, or utilizing affinity calls (with the sql as part of
> the logic)?
>
> On Wed, Jun 17, 2020 at 7:02 PM Denis Magda  wrote:
>
>> Narges,
>>
>> INSERTS/UPDATES/DELETES will be forwarded to primary nodes based on the
>> value of primary keys you pass into queries. Ignite maps a primary key to a
>> partition and, finally, to a primary node that holds that partition. All
>> this happens transparently in Ignite. You don't need to do anything except
>> for sending those SQL commands.
>>
>> As for SELECTS, most of them will be broadcasted to your server nodes
>> unless Ignite can pre-select a sub-set of target nodes a query needs to be
>> executed on. This optimization always takes place for simple queries when
>> you try to get records based on the value of a primary key, such as "SELECT
>> * FROM Table WHERE primaryKeyColumn = 2".
>>
>> -
>> Denis
>>
>>
>> On Wed, Jun 17, 2020 at 12:43 PM narges saleh 
>> wrote:
>>
>>> Thanks Denis. Will watch the video.
>>> One more question, related to SQL execution. If I issue a SQL from a
>>> client, how would ignite know which node to run the SQL query on? I assume
>>> the SQL is parsed on the server nodes, and I will still need to direct the
>>> SQL to be executed on the right server node (assuming that all the data is
>>> collocated on a single node). Am I right?
>>>
>>> On Wed, Jun 17, 2020 at 2:26 PM Denis Magda  wrote:
>>>
 The collocated flag is an extra optimization hint for SQL queries with
 GROUP BYs. The parameter requests to group records locally on the nodes
 that participated in the query execution. For instance, if your application
 sends a query with GROUP BY to a couple of server nodes, then the nodes
 will group their portions of the result sets locally not making that the
 burden of the application that merges/reduces the result sets into one. The
 description of this parameter here should be helpful as well:
 https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters

 
>
> Should I assume that if the table is defined with affinity set, then
> compute collocation, including sql execution will happen automatically?


 That's right. You just need to set up the affinity keys and Ignite will
 take care of the rest. Btw, you might be interested in this SQL webinar we
 delivered recently. The webinar explains our SQL capabilities in detail:
 https://www.youtube.com/watch?v=eYV-tNLzIts

 -
 Denis


 On Wed, Jun 17, 2020 at 11:28 AM narges saleh 
 wrote:

> Then can you please explain what the option collocated=true for JDBC
> url is for?
> Should I assume that if the table is defined with affinity set, then
> compute collocation, including sql execution will happen automatically?
> I am sorry if this is just a basic question.
>
> On Wed, Jun 17, 2020 at 12:57 PM Denis Magda 
> wrote:
>
>> If the data is already co-located you don't need to pass in any other
>> parameters.
>>
>> -
>> Denis
>>
>>
>> On Wed, Jun 17, 2020 at 10:13 AM narges saleh 
>> wrote:
>>
>>> Hi Denis. The tables are defined with affinity keys specified. What
>>> I am asking whether to set the collection option when I insert or query 
>>> the
>>> data via SQL line.
>>>
>>> thanks
>>>
>>> On Wed, Jun 17, 2020 at 11:39 AM Denis Magda 
>>> wrote:
>>>
 Hi,

 You need to pass the required parameters to the JDBC driver's
 connection URL:
 https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters

 However, I'm not quite sure what you mean under the "collocation"
 in the following context. All your data needs to be co-located 
 beforehand
 (ensure you have affinity keys configured) and then just send your 
 queries
 with joins with no additional connection parameters.

 -
 Denis


 On Wed, Jun 17, 2020 at 9:33 AM narges saleh 
 wrote:

> Hi All,
>
> Is collocation enforced when SQL is issues in sqline command line
> or do I need to give the option when I start sqlline?
>
> thanks.
>

Re: Ignite Webconsole (console.gridgain.com) login not not working

[tarunk]

Thanks Dennis for the response and fixing it.



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

Re: sqlline

[narges saleh]

Thanks Denis. In case of selects, can I push ignite to broadcast the sql to
where the data is, say by using employing services deployed on the targeted
data nodes, or utilizing affinity calls (with the sql as part of the logic)?

On Wed, Jun 17, 2020 at 7:02 PM Denis Magda  wrote:

> Narges,
>
> INSERTS/UPDATES/DELETES will be forwarded to primary nodes based on the
> value of primary keys you pass into queries. Ignite maps a primary key to a
> partition and, finally, to a primary node that holds that partition. All
> this happens transparently in Ignite. You don't need to do anything except
> for sending those SQL commands.
>
> As for SELECTS, most of them will be broadcasted to your server nodes
> unless Ignite can pre-select a sub-set of target nodes a query needs to be
> executed on. This optimization always takes place for simple queries when
> you try to get records based on the value of a primary key, such as "SELECT
> * FROM Table WHERE primaryKeyColumn = 2".
>
> -
> Denis
>
>
> On Wed, Jun 17, 2020 at 12:43 PM narges saleh 
> wrote:
>
>> Thanks Denis. Will watch the video.
>> One more question, related to SQL execution. If I issue a SQL from a
>> client, how would ignite know which node to run the SQL query on? I assume
>> the SQL is parsed on the server nodes, and I will still need to direct the
>> SQL to be executed on the right server node (assuming that all the data is
>> collocated on a single node). Am I right?
>>
>> On Wed, Jun 17, 2020 at 2:26 PM Denis Magda  wrote:
>>
>>> The collocated flag is an extra optimization hint for SQL queries with
>>> GROUP BYs. The parameter requests to group records locally on the nodes
>>> that participated in the query execution. For instance, if your application
>>> sends a query with GROUP BY to a couple of server nodes, then the nodes
>>> will group their portions of the result sets locally not making that the
>>> burden of the application that merges/reduces the result sets into one. The
>>> description of this parameter here should be helpful as well:
>>> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>>>
>>> 

 Should I assume that if the table is defined with affinity set, then
 compute collocation, including sql execution will happen automatically?
>>>
>>>
>>> That's right. You just need to set up the affinity keys and Ignite will
>>> take care of the rest. Btw, you might be interested in this SQL webinar we
>>> delivered recently. The webinar explains our SQL capabilities in detail:
>>> https://www.youtube.com/watch?v=eYV-tNLzIts
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jun 17, 2020 at 11:28 AM narges saleh 
>>> wrote:
>>>
 Then can you please explain what the option collocated=true for JDBC
 url is for?
 Should I assume that if the table is defined with affinity set, then
 compute collocation, including sql execution will happen automatically?
 I am sorry if this is just a basic question.

 On Wed, Jun 17, 2020 at 12:57 PM Denis Magda  wrote:

> If the data is already co-located you don't need to pass in any other
> parameters.
>
> -
> Denis
>
>
> On Wed, Jun 17, 2020 at 10:13 AM narges saleh 
> wrote:
>
>> Hi Denis. The tables are defined with affinity keys specified. What I
>> am asking whether to set the collection option when I insert or query the
>> data via SQL line.
>>
>> thanks
>>
>> On Wed, Jun 17, 2020 at 11:39 AM Denis Magda 
>> wrote:
>>
>>> Hi,
>>>
>>> You need to pass the required parameters to the JDBC driver's
>>> connection URL:
>>> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>>>
>>> However, I'm not quite sure what you mean under the "collocation" in
>>> the following context. All your data needs to be co-located beforehand
>>> (ensure you have affinity keys configured) and then just send your 
>>> queries
>>> with joins with no additional connection parameters.
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jun 17, 2020 at 9:33 AM narges saleh 
>>> wrote:
>>>
 Hi All,

 Is collocation enforced when SQL is issues in sqline command line
 or do I need to give the option when I start sqlline?

 thanks.

>>>

Re: sqlline

[Denis Magda]

Narges,

INSERTS/UPDATES/DELETES will be forwarded to primary nodes based on the
value of primary keys you pass into queries. Ignite maps a primary key to a
partition and, finally, to a primary node that holds that partition. All
this happens transparently in Ignite. You don't need to do anything except
for sending those SQL commands.

As for SELECTS, most of them will be broadcasted to your server nodes
unless Ignite can pre-select a sub-set of target nodes a query needs to be
executed on. This optimization always takes place for simple queries when
you try to get records based on the value of a primary key, such as "SELECT
* FROM Table WHERE primaryKeyColumn = 2".

-
Denis


On Wed, Jun 17, 2020 at 12:43 PM narges saleh  wrote:

> Thanks Denis. Will watch the video.
> One more question, related to SQL execution. If I issue a SQL from a
> client, how would ignite know which node to run the SQL query on? I assume
> the SQL is parsed on the server nodes, and I will still need to direct the
> SQL to be executed on the right server node (assuming that all the data is
> collocated on a single node). Am I right?
>
> On Wed, Jun 17, 2020 at 2:26 PM Denis Magda  wrote:
>
>> The collocated flag is an extra optimization hint for SQL queries with
>> GROUP BYs. The parameter requests to group records locally on the nodes
>> that participated in the query execution. For instance, if your application
>> sends a query with GROUP BY to a couple of server nodes, then the nodes
>> will group their portions of the result sets locally not making that the
>> burden of the application that merges/reduces the result sets into one. The
>> description of this parameter here should be helpful as well:
>> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>>
>> 
>>>
>>> Should I assume that if the table is defined with affinity set, then
>>> compute collocation, including sql execution will happen automatically?
>>
>>
>> That's right. You just need to set up the affinity keys and Ignite will
>> take care of the rest. Btw, you might be interested in this SQL webinar we
>> delivered recently. The webinar explains our SQL capabilities in detail:
>> https://www.youtube.com/watch?v=eYV-tNLzIts
>>
>> -
>> Denis
>>
>>
>> On Wed, Jun 17, 2020 at 11:28 AM narges saleh 
>> wrote:
>>
>>> Then can you please explain what the option collocated=true for JDBC url
>>> is for?
>>> Should I assume that if the table is defined with affinity set, then
>>> compute collocation, including sql execution will happen automatically?
>>> I am sorry if this is just a basic question.
>>>
>>> On Wed, Jun 17, 2020 at 12:57 PM Denis Magda  wrote:
>>>
 If the data is already co-located you don't need to pass in any other
 parameters.

 -
 Denis


 On Wed, Jun 17, 2020 at 10:13 AM narges saleh 
 wrote:

> Hi Denis. The tables are defined with affinity keys specified. What I
> am asking whether to set the collection option when I insert or query the
> data via SQL line.
>
> thanks
>
> On Wed, Jun 17, 2020 at 11:39 AM Denis Magda 
> wrote:
>
>> Hi,
>>
>> You need to pass the required parameters to the JDBC driver's
>> connection URL:
>> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>>
>> However, I'm not quite sure what you mean under the "collocation" in
>> the following context. All your data needs to be co-located beforehand
>> (ensure you have affinity keys configured) and then just send your 
>> queries
>> with joins with no additional connection parameters.
>>
>> -
>> Denis
>>
>>
>> On Wed, Jun 17, 2020 at 9:33 AM narges saleh 
>> wrote:
>>
>>> Hi All,
>>>
>>> Is collocation enforced when SQL is issues in sqline command line or
>>> do I need to give the option when I start sqlline?
>>>
>>> thanks.
>>>
>>

Re: Achieve uniform data distribution easily

[akorensh]

Hi,
  see:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/Affinity.html

   Can you see the key to partition mappings:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/Affinity.html#mapKeyToPrimaryAndBackups-K-
  to see what your distribution look like.


  you can also see how these same partitions are spread among the nodes.
  Can you use the mapPartitionsToNodes:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/Affinity.html#mapPartitionsToNodes-java.util.Collection-

   You can look at how partitions are mapped to nodes here:
https://github.com/andyglick/apache-ignite/blob/c864fe443284508c7eb1d2341d9fdc2a5a844c45/modules/core/src/main/java/org/apache/ignite/cache/affinity/rendezvous/RendezvousAffinityFunction.java#L497


  In general, it is not a good idea to modify the partition function in
order to create a pseudo key for partition assignments. This creates
dependencies that are hard to untangle later on.

  Best to work on the level of caches/keys, and use an alternate key for
storage.
  Look into affinity collocation to see if it helps your use
case:https://apacheignite.readme.io/docs/affinity-collocation#collocate-data-with-data
Thanks, Alex






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

Re: HashMap warning when using PutAll()

[Raymond Wilson]

Hi Ilya,

Thank you for the SortedDictionary pointer.

I am not sure what you mean by 'size-1 collections'. Is there an issue here
that requires fixing in Ignite, or just the use of SortedDIctionary in my
client code?

Thanks,
Raymond.

On Thu, Jun 18, 2020 at 3:45 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> The warning should not be issued for size-1 collections.
> In dotnet, you should use SortedDictionary with putAll.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> сб, 13 июн. 2020 г. в 09:43, Raymond Wilson :
>
>> If the answer is that the consumer of the C# client should order the
>> items before calling PutAll(), how does the consumer of the C# client
>> ensure that is the case before calling PutAll()?
>>
>> On Sat, Jun 13, 2020 at 4:13 PM Raymond Wilson <
>> raymond_wil...@trimble.com> wrote:
>>
>>> Hi Evgenii,
>>>
>>> Thanks for the quick response and clarification :)
>>>
>>> Does this mean the C# client is looking at the collection provided to it
>>> and choosing treemap vs hashmap for an internal call to the Ignite Java
>>> layer based on whether the content of the collection provided is sorted?
>>>
>>> Thanks,
>>> Raymond.
>>>
>>>
>>> On Sat, Jun 13, 2020 at 2:23 AM Evgenii Zhuravlev <
>>> e.zhuravlev...@gmail.com> wrote:
>>>
 The same works for other operations too(like removeAll).

 Evgenii

 пт, 12 июн. 2020 г. в 07:22, Evgenii Zhuravlev <
 e.zhuravlev...@gmail.com>:

> Raymond,
>
> Collections used in putAll should be sorted, because otherwise if they
> have the same entries but in a different order, it can lead to the classic
> deadlock. It is expected behavior.
>
> Best Regards,
> Evgenii
>
> чт, 11 июн. 2020 г. в 21:38, Raymond Wilson <
> raymond_wil...@trimble.com>:
>
>> We are using Ignite v2.8.0 and the C# client. Some of our operations
>> use PutAll() to save a collection of items in a single operation. This
>> operation is emitting the following warning into the log:
>>
>> 2020-06-10 15:04:14,199 [77] WRN [ImmutableClientServer]
>>  Unordered map java.util.HashMap is
>> used for putAll operation on cache Spatial-SubGridDirectory-Immutable. 
>> This
>> can lead to a distributed deadlock. Switch to a sorted map like TreeMap
>> instead.
>>
>> Does this require a Jira ticket?
>>
>> Thanks,
>> Raymond.
>>
>>
>> --
>> 
>> Raymond Wilson
>> Solution Architect, Civil Construction Software Systems (CCSS)
>> 11 Birmingham Drive | Christchurch, New Zealand
>> +64-21-2013317 Mobile
>> raymond_wil...@trimble.com
>>
>>
>> 
>>
>
>>>
>>> --
>>> 
>>> Raymond Wilson
>>> Solution Architect, Civil Construction Software Systems (CCSS)
>>> 11 Birmingham Drive | Christchurch, New Zealand
>>> +64-21-2013317 Mobile
>>> raymond_wil...@trimble.com
>>>
>>>
>>> 
>>>
>>
>>
>> --
>> 
>> Raymond Wilson
>> Solution Architect, Civil Construction Software Systems (CCSS)
>> 11 Birmingham Drive | Christchurch, New Zealand
>> +64-21-2013317 Mobile
>> raymond_wil...@trimble.com
>>
>>
>> 
>>
>

-- 

Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wil...@trimble.com

Re: Size of an object in Ignite cache

[akorensh]

Hi, 
   Ignite converts your object to a binaryObject before storing it:
https://apacheignite.readme.io/docs/binary-marshaller
   You can take a look at the binary object format:
https://cwiki.apache.org/confluence/display/IGNITE/Binary+object+format
  
   Also see this answer:  
https://stackoverflow.com/questions/49780044/apache-ignite-binaryobject-bloat/49780396

Thanks, Alex



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

Re: sqlline

[narges saleh]

Thanks Denis. Will watch the video.
One more question, related to SQL execution. If I issue a SQL from a
client, how would ignite know which node to run the SQL query on? I assume
the SQL is parsed on the server nodes, and I will still need to direct the
SQL to be executed on the right server node (assuming that all the data is
collocated on a single node). Am I right?

On Wed, Jun 17, 2020 at 2:26 PM Denis Magda  wrote:

> The collocated flag is an extra optimization hint for SQL queries with
> GROUP BYs. The parameter requests to group records locally on the nodes
> that participated in the query execution. For instance, if your application
> sends a query with GROUP BY to a couple of server nodes, then the nodes
> will group their portions of the result sets locally not making that the
> burden of the application that merges/reduces the result sets into one. The
> description of this parameter here should be helpful as well:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>
> 
>>
>> Should I assume that if the table is defined with affinity set, then
>> compute collocation, including sql execution will happen automatically?
>
>
> That's right. You just need to set up the affinity keys and Ignite will
> take care of the rest. Btw, you might be interested in this SQL webinar we
> delivered recently. The webinar explains our SQL capabilities in detail:
> https://www.youtube.com/watch?v=eYV-tNLzIts
>
> -
> Denis
>
>
> On Wed, Jun 17, 2020 at 11:28 AM narges saleh 
> wrote:
>
>> Then can you please explain what the option collocated=true for JDBC url
>> is for?
>> Should I assume that if the table is defined with affinity set, then
>> compute collocation, including sql execution will happen automatically?
>> I am sorry if this is just a basic question.
>>
>> On Wed, Jun 17, 2020 at 12:57 PM Denis Magda  wrote:
>>
>>> If the data is already co-located you don't need to pass in any other
>>> parameters.
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jun 17, 2020 at 10:13 AM narges saleh 
>>> wrote:
>>>
 Hi Denis. The tables are defined with affinity keys specified. What I
 am asking whether to set the collection option when I insert or query the
 data via SQL line.

 thanks

 On Wed, Jun 17, 2020 at 11:39 AM Denis Magda  wrote:

> Hi,
>
> You need to pass the required parameters to the JDBC driver's
> connection URL:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>
> However, I'm not quite sure what you mean under the "collocation" in
> the following context. All your data needs to be co-located beforehand
> (ensure you have affinity keys configured) and then just send your queries
> with joins with no additional connection parameters.
>
> -
> Denis
>
>
> On Wed, Jun 17, 2020 at 9:33 AM narges saleh 
> wrote:
>
>> Hi All,
>>
>> Is collocation enforced when SQL is issues in sqline command line or
>> do I need to give the option when I start sqlline?
>>
>> thanks.
>>
>

Re: sqlline

[Denis Magda]

The collocated flag is an extra optimization hint for SQL queries with
GROUP BYs. The parameter requests to group records locally on the nodes
that participated in the query execution. For instance, if your application
sends a query with GROUP BY to a couple of server nodes, then the nodes
will group their portions of the result sets locally not making that the
burden of the application that merges/reduces the result sets into one. The
description of this parameter here should be helpful as well:
https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters


>
> Should I assume that if the table is defined with affinity set, then
> compute collocation, including sql execution will happen automatically?


That's right. You just need to set up the affinity keys and Ignite will
take care of the rest. Btw, you might be interested in this SQL webinar we
delivered recently. The webinar explains our SQL capabilities in detail:
https://www.youtube.com/watch?v=eYV-tNLzIts

-
Denis


On Wed, Jun 17, 2020 at 11:28 AM narges saleh  wrote:

> Then can you please explain what the option collocated=true for JDBC url
> is for?
> Should I assume that if the table is defined with affinity set, then
> compute collocation, including sql execution will happen automatically?
> I am sorry if this is just a basic question.
>
> On Wed, Jun 17, 2020 at 12:57 PM Denis Magda  wrote:
>
>> If the data is already co-located you don't need to pass in any other
>> parameters.
>>
>> -
>> Denis
>>
>>
>> On Wed, Jun 17, 2020 at 10:13 AM narges saleh 
>> wrote:
>>
>>> Hi Denis. The tables are defined with affinity keys specified. What I am
>>> asking whether to set the collection option when I insert or query the data
>>> via SQL line.
>>>
>>> thanks
>>>
>>> On Wed, Jun 17, 2020 at 11:39 AM Denis Magda  wrote:
>>>
 Hi,

 You need to pass the required parameters to the JDBC driver's
 connection URL:
 https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters

 However, I'm not quite sure what you mean under the "collocation" in
 the following context. All your data needs to be co-located beforehand
 (ensure you have affinity keys configured) and then just send your queries
 with joins with no additional connection parameters.

 -
 Denis


 On Wed, Jun 17, 2020 at 9:33 AM narges saleh 
 wrote:

> Hi All,
>
> Is collocation enforced when SQL is issues in sqline command line or
> do I need to give the option when I start sqlline?
>
> thanks.
>

Achieve uniform data distribution easily

[VincentCE]

In our project a lot of data records share the same keys, i.e. a given key
might exist in several of our caches (with different values though). We
suspect that this is the reason for our non-uniform data-distribution over
the cluster-nodes that we are facing since all data-records that share the
same keys should finally be placed on the same cluster-nodes. Concerning the
latter an important note: So far our keys are just strings and we have not
used affinity keys so far to influence the assignments to partitions
respectively nodes.

In order to achieve roughly uniform data-distribution but keep the impact in
terms of code refactoring small we thought of extending
RendezvousAffinityFunction in the following manner.

public class CustomizedRendezvousAffinityFunction extends
RendezvousAffinityFunction {

private static final long serialVersionUID = 1L;
private final String cacheName;

/**
 * Constructor.
 * 
 * @param cacheName name of cache
 */
public CustomizedRendezvousAffinityFunction(String cacheName) {
this.cacheName = cacheName;
}

@Override
public int partition(Object key) {
key = new 
StringBuilder(cacheName).append(key.toString()).toString();
return super.partition(key);
}

}

followed by cc.setAffinity(new
CustomizedRendezvousAffinityFunction(cacheName)); for a given
cache-configuration. The concatenation key= cacheName/key is then indeed
unique and the assignment to a partition should be (pseudo-)random.

Unfortunately the result for 10 cluster-nodes is not as expected, i.e. there
is a lot of variance, e.g. between node1 and node7: 

node1 : ^-- Off-heap [used=23633MB, free=34.43%, comm=35920MB]
node2 : ^-- Off-heap [used=29234MB, free=18.88%, comm=35920MB]
node3 : ^-- Off-heap [used=25834MB, free=28.32%, comm=35920MB]
node4 : ^-- Off-heap [used=27847MB, free=22.73%, comm=35920MB]
node5 : ^-- Off-heap [used=28189MB, free=21.78%, comm=35920MB]
node6 : ^-- Off-heap [used=26167MB, free=27.39%, comm=35920MB]
node7: ^-- Off-heap [used=29565MB, free=17.96%, comm=35920MB]
node8 : ^-- Off-heap [used=25628MB, free=28.89%, comm=35920MB]
node9 : ^-- Off-heap [used=26583MB, free=26.24%, comm=35920MB]
node10 : ^-- Off-heap [used=24573MB, free=31.82%, comm=35920MB]

Is our approach flawed or what might be the reason for the remaining
imbalance? We use ignite 2.7.6.

Thanks in advance!




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

Re: sqlline

[narges saleh]

Then can you please explain what the option collocated=true for JDBC url is
for?
Should I assume that if the table is defined with affinity set, then
compute collocation, including sql execution will happen automatically?
I am sorry if this is just a basic question.

On Wed, Jun 17, 2020 at 12:57 PM Denis Magda  wrote:

> If the data is already co-located you don't need to pass in any other
> parameters.
>
> -
> Denis
>
>
> On Wed, Jun 17, 2020 at 10:13 AM narges saleh 
> wrote:
>
>> Hi Denis. The tables are defined with affinity keys specified. What I am
>> asking whether to set the collection option when I insert or query the data
>> via SQL line.
>>
>> thanks
>>
>> On Wed, Jun 17, 2020 at 11:39 AM Denis Magda  wrote:
>>
>>> Hi,
>>>
>>> You need to pass the required parameters to the JDBC driver's connection
>>> URL:
>>> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>>>
>>> However, I'm not quite sure what you mean under the "collocation" in the
>>> following context. All your data needs to be co-located beforehand (ensure
>>> you have affinity keys configured) and then just send your queries with
>>> joins with no additional connection parameters.
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jun 17, 2020 at 9:33 AM narges saleh 
>>> wrote:
>>>
 Hi All,

 Is collocation enforced when SQL is issues in sqline command line or do
 I need to give the option when I start sqlline?

 thanks.

>>>

Re: sqlline

[Denis Magda]

If the data is already co-located you don't need to pass in any other
parameters.

-
Denis


On Wed, Jun 17, 2020 at 10:13 AM narges saleh  wrote:

> Hi Denis. The tables are defined with affinity keys specified. What I am
> asking whether to set the collection option when I insert or query the data
> via SQL line.
>
> thanks
>
> On Wed, Jun 17, 2020 at 11:39 AM Denis Magda  wrote:
>
>> Hi,
>>
>> You need to pass the required parameters to the JDBC driver's connection
>> URL:
>> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>>
>> However, I'm not quite sure what you mean under the "collocation" in the
>> following context. All your data needs to be co-located beforehand (ensure
>> you have affinity keys configured) and then just send your queries with
>> joins with no additional connection parameters.
>>
>> -
>> Denis
>>
>>
>> On Wed, Jun 17, 2020 at 9:33 AM narges saleh 
>> wrote:
>>
>>> Hi All,
>>>
>>> Is collocation enforced when SQL is issues in sqline command line or do
>>> I need to give the option when I start sqlline?
>>>
>>> thanks.
>>>
>>

Re: sqlline

[narges saleh]

Hi Denis. The tables are defined with affinity keys specified. What I am
asking whether to set the collection option when I insert or query the data
via SQL line.

thanks

On Wed, Jun 17, 2020 at 11:39 AM Denis Magda  wrote:

> Hi,
>
> You need to pass the required parameters to the JDBC driver's connection
> URL:
> https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters
>
> However, I'm not quite sure what you mean under the "collocation" in the
> following context. All your data needs to be co-located beforehand (ensure
> you have affinity keys configured) and then just send your queries with
> joins with no additional connection parameters.
>
> -
> Denis
>
>
> On Wed, Jun 17, 2020 at 9:33 AM narges saleh  wrote:
>
>> Hi All,
>>
>> Is collocation enforced when SQL is issues in sqline command line or do I
>> need to give the option when I start sqlline?
>>
>> thanks.
>>
>

Re: sqlline

[Denis Magda]

Hi,

You need to pass the required parameters to the JDBC driver's connection
URL:
https://apacheignite-sql.readme.io/docs/jdbc-driver#parameters

However, I'm not quite sure what you mean under the "collocation" in the
following context. All your data needs to be co-located beforehand (ensure
you have affinity keys configured) and then just send your queries with
joins with no additional connection parameters.

-
Denis


On Wed, Jun 17, 2020 at 9:33 AM narges saleh  wrote:

> Hi All,
>
> Is collocation enforced when SQL is issues in sqline command line or do I
> need to give the option when I start sqlline?
>
> thanks.
>

sqlline

[narges saleh]

Hi All,

Is collocation enforced when SQL is issues in sqline command line or do I
need to give the option when I start sqlline?

thanks.

Atomic Sequence/Auto Increment via IgniteClient - Thin Client - Ignite 2.8.1

[Mahesh Renduchintala]

Hello,

Is there a way to access ignite Atomic Sequence via thin client apis?
We have a situation where we have thick clients (java micro-services) and thin 
clients (Spark) and both need to generate IDs for inserting data into tables.

regards
Mahesh

Re: Data streamer hangs

[akorensh]

Hi,
Are you seeing pool starvation messages? How long does it stay in this
state?

   Are you not seeing any data saved, even when you close the jdbc
connection?
   Are you able to reproduce this scenario? If so please describe steps/send
a reproducer and send full logs.


   Data Streamer pool config:
https://apacheignite.readme.io/docs/thread-pools#data-streamer-pool

info on data streamer:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteDataStreamer.html
   see: 
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteDataStreamer.html#perNodeBufferSize-int-

   from the doc: https://apacheignite-sql.readme.io/docs/set#description
   When streaming is enabled, JDBC/ODBC driver will pack your commands in
batches and send them to the server (Ignite cluster). On the server side,
the batch is converted into a stream of cache update commands which are
distributed asynchronously between server nodes.

   In a JDBC SET STREAMING ON/OFF, this buffer is set internally to, and you
need to flush the data by closing the connection.

  see : https://apacheignite-sql.readme.io/docs/set#example

Thanks, Alex



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

Re: HashMap warning when using PutAll()

[Ilya Kasnacheev]

Hello!

The warning should not be issued for size-1 collections.
In dotnet, you should use SortedDictionary with putAll.

Regards,
-- 
Ilya Kasnacheev


сб, 13 июн. 2020 г. в 09:43, Raymond Wilson :

> If the answer is that the consumer of the C# client should order the items
> before calling PutAll(), how does the consumer of the C# client ensure that
> is the case before calling PutAll()?
>
> On Sat, Jun 13, 2020 at 4:13 PM Raymond Wilson 
> wrote:
>
>> Hi Evgenii,
>>
>> Thanks for the quick response and clarification :)
>>
>> Does this mean the C# client is looking at the collection provided to it
>> and choosing treemap vs hashmap for an internal call to the Ignite Java
>> layer based on whether the content of the collection provided is sorted?
>>
>> Thanks,
>> Raymond.
>>
>>
>> On Sat, Jun 13, 2020 at 2:23 AM Evgenii Zhuravlev <
>> e.zhuravlev...@gmail.com> wrote:
>>
>>> The same works for other operations too(like removeAll).
>>>
>>> Evgenii
>>>
>>> пт, 12 июн. 2020 г. в 07:22, Evgenii Zhuravlev >> >:
>>>
 Raymond,

 Collections used in putAll should be sorted, because otherwise if they
 have the same entries but in a different order, it can lead to the classic
 deadlock. It is expected behavior.

 Best Regards,
 Evgenii

 чт, 11 июн. 2020 г. в 21:38, Raymond Wilson >>> >:

> We are using Ignite v2.8.0 and the C# client. Some of our operations
> use PutAll() to save a collection of items in a single operation. This
> operation is emitting the following warning into the log:
>
> 2020-06-10 15:04:14,199 [77] WRN [ImmutableClientServer]
>  Unordered map java.util.HashMap is
> used for putAll operation on cache Spatial-SubGridDirectory-Immutable. 
> This
> can lead to a distributed deadlock. Switch to a sorted map like TreeMap
> instead.
>
> Does this require a Jira ticket?
>
> Thanks,
> Raymond.
>
>
> --
> 
> Raymond Wilson
> Solution Architect, Civil Construction Software Systems (CCSS)
> 11 Birmingham Drive | Christchurch, New Zealand
> +64-21-2013317 Mobile
> raymond_wil...@trimble.com
>
>
> 
>

>>
>> --
>> 
>> Raymond Wilson
>> Solution Architect, Civil Construction Software Systems (CCSS)
>> 11 Birmingham Drive | Christchurch, New Zealand
>> +64-21-2013317 Mobile
>> raymond_wil...@trimble.com
>>
>>
>> 
>>
>
>
> --
> 
> Raymond Wilson
> Solution Architect, Civil Construction Software Systems (CCSS)
> 11 Birmingham Drive | Christchurch, New Zealand
> +64-21-2013317 Mobile
> raymond_wil...@trimble.com
>
>
> 
>

Re: Ignite Webconsole (console.gridgain.com) login not not working

[Denis Mekhanikov]

Tarun,

Thanks for the report!
We've had an issue with the service. It's back on now.

Denis

ср, 17 июн. 2020 г. в 16:17, tarunk :

> Hi All,
>
> I have been using ignite webconsole with my login hosted at
> https://console.gridgain.com/signin.
> I remember using it till ~a month back, while logging in today, am getting
> below error.
>
> 404 Not Found
> --
> nginx
>
> Has there been any changes to this ?
>
> Even trying to setup a new user giving same error, tried with
> chrome/chrome.
>
> Thanks,
> Tarun
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: PIVOT with SQL

[akorensh]

Hi,
  At present, PIVOT functionn is not supported.
   SQL function reference:
https://apacheignite-sql.readme.io/docs/sql-reference-overview

Thanks, Alex



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

Problem with writeBehind Apache Ignite 2.8.1

[manueltg89]

Hello, I use Apache Ignite with MariaDB (RDBMS Integration), all works
properly except "writeBehind", if I activate "writeBehind" and I insert for
example 200 instances with PHP PDO I receive a exception on console of
Ignite, the exception is the following: 

jun 17, 2020 4:03:45 PM org.apache.ignite.logger.java.JavaLogger error
GRAVE: Failed to execute SQL query [reqId=0, req=OdbcQueryExecuteRequest
[schema=PUBLIC, sqlQry=INSERT INTO scrapy_brand(id, name, keyname) VALUES
(brandId(), ?, ?), autoCommit=true, timeout=0, args=Object[] [manuela4939,
manuela4939]]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
to execute DML statement [stmt=INSERT INTO scrapy_brand(id, name, keyname)
VALUES (brandId(), ?, ?), params=[manuela4939, manuela4939]]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1247)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1144)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2406)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2402)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2919)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2422)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2460)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2396)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2323)
at
org.apache.ignite.internal.processors.odbc.odbc.OdbcRequestHandler.executeQuery(OdbcRequestHandler.java:403)
at
org.apache.ignite.internal.processors.odbc.odbc.OdbcRequestHandler.doHandle(OdbcRequestHandler.java:233)
at
org.apache.ignite.internal.processors.odbc.odbc.OdbcRequestHandler.handle(OdbcRequestHandler.java:196)
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)
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
a186692c271--0c27-0020--0001
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4365)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2599)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2580)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putIfAbsent(GridCacheAdapter.java:3007)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:197)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:168)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2920)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2774)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2704)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1218)
... 22 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to load
object [table=scrapybd.scrapy_brand, key=12689]
at
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:335)
at

Ignite Webconsole (console.gridgain.com) login not not working

[tarunk]

Hi All,

I have been using ignite webconsole with my login hosted at
https://console.gridgain.com/signin.
I remember using it till ~a month back, while logging in today, am getting
below error.

404 Not Found
--
nginx

Has there been any changes to this ?

Even trying to setup a new user giving same error, tried with chrome/chrome.

Thanks,
Tarun



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

Best practices for WalArchive when using EFS

[Raymond Wilson]

We are deploying an Ignite application to a Kubernetes cluster in AWS EKS
and are planning to use EFS for persistent data.

I have been reading through the tuning options for the Write Ahead Log
Archive, trying to understand if we can safely turn off the archive to save
the IO related to copying a WAL segment to the archive when it is full.

As far as I can tell, the only functional role of the archived segments
compared to the segments present in the write ahead log is to save
potential file system slowness in recreating new segments compared to
overwriting an existing segment once it has been copied to the archive.
Apart from this, a WAL with 10 segments seems to provide the same
consistency guarantees in the event of failure as a WAL with one active
segment and a WAL archive with 10 archived segments.

As we are using EFS we do not have issues with disk space so can define an
arbitrarily large WAL without the need to copy these files to a separate
archive which will contend the EFS bandwidth even if copies asynchronously
within Ignite.

Is my understanding correct here with respect to the EFS use case?

Thanks,
Raymond.




-- 

Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand

Non collocated subqueries

[Andrey Davydov]

Hello, It seems that SqlFieldsQuery.setCollocated and SqlFieldsQuery.setDistributedJoins has no affect on subqueries under IN and EXISTS expressions. I didn’t find any information about subqueries specific in actual documentation. Subqueries is important part of sql, please describe it in documents.For example, EXISTS subqueries is usefull with hibernate criteria, when you need select “child” entity but filter by field in “parent” entity Andrey. 

Size of an object in Ignite cache

[ashishb888]

How one can know the exact size of an object stored on Ignite cache?

Can we use below to get the size?
byte[] arr = ignite.configuration().getMarshaller().marshal(new Person(10L,
"first", "last"));




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