RE: IGNITE-4548 does not seem to be completely fixed

[Gordon Reid (Nine Mile)]

Hi Mikhail,

Thanks for looking at this. I will create a reproducer for you.

Thanks,
Gordon.

From: Mikhail Cherkasov [mailto:mcherka...@gridgain.com]
Sent: Tuesday, 4 July 2017 2:14 AM
To: user@ignite.apache.org
Subject: Re: IGNITE-4548 does not seem to be completely fixed

Hi Gordon,

Could you please send you pom project to debug it?
Looks like it was changes on purpose by this ticket: 
https://issues.apache.org/jira/browse/IGNITE-4949
but anyway, I want to check it with debugger, I will appreciate if you send 
your test case.

Thanks,
Mikhail.



On Mon, Jul 3, 2017 at 10:37 AM, Gordon Reid (Nine Mile) 
> 
wrote:

Hi Ignite Experts,

I have tested the fix for IGNITE-4548

Say I have enum like this

public enum SecurityType {
All,
Stock,
Future,
Option,
Commodity,
ETF,
Bond,
Unknown,
Equity,
REIT,
StapledSecurity,
CurrencyPair
}

Using this JDBC config


vals.add(new JdbcTypeField(Types.VARCHAR, "securityType", SecurityType.class, 
"securityType"));

And some model class with field

@QuerySqlField(index=true)
private SecurityType securityType;


I can read a varchar from the database of “Bond” from the database into the 
cache, and the securityType field on the cache record will be 
SecurityType.Bond. GREAT.

BUT

When I save the record back to the database the enum ordinal “6” will be saved 
into the securityType column. This is not what we want.

  1.  It makes reading the database difficult. 6 means nothing to someone who 
can’t see the code.
  2.  More importantly, the enum may be refactored over time, and “6” may 
represent something else in future

Reading string value from database into the enum field is working fine. But is 
there a way I can force ignite to save the string value of the Enum into the 
database also?

Thanks,
Gordon.


This email and any attachments are proprietary & confidential and are intended 
solely for the use of the individuals to whom it is addressed. Any views or 
opinions expressed are solely for those of the author and do not necessarily 
reflect those of Nine Mile Financial Pty. Limited. If you have received this 
email in error, please let us know immediately by reply email and delete from 
your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252



--
Thanks,
Mikhail.


This email and any attachments are proprietary & confidential and are intended 
solely for the use of the individuals to whom it is addressed. Any views or 
opinions expressed are solely for those of the author and do not necessarily 
reflect those of Nine Mile Financial Pty. Limited. If you have received this 
email in error, please let us know immediately by reply email and delete from 
your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252

RE: Ignite very very chatty when java server nodes and .net client when using Service Grid

[Gordon Reid (Nine Mile)]

Hi Pavel,

Yes that’s correct, in this case we were calling 
Ignite.GetServices().GetServiceProxy() every second.

When the .NET client is remote from the java server, this caused a large amount 
of traffic. As service descriptors for services that were not even deployed (so 
basically all the services types that we define), was being sent back every 
second.

The reason we were calling like this, is because we didn’t want to have to 
manage a stale service proxy in the case of topology change.

Thanks,
Gordon.

From: Pavel Tupitsyn [mailto:ptupit...@apache.org]
Sent: Thursday, 6 July 2017 6:42 PM
To: user@ignite.apache.org
Subject: Re: Ignite very very chatty when java server nodes and .net client 
when using Service Grid

Hi Gordon,

I see that you solved the problem, but I'm still curious: what did you have and 
what did you change to solve this?
Did you call Ignite.GetServices().GetServiceProxy() every second, or something 
else?

Thanks,

Pavel

On Thu, Jul 6, 2017 at 3:07 AM, Gordon Reid (Nine Mile) 
> 
wrote:
It looks like the problem here is that the Ignite.GetServices is a relatively 
expensive call from the client. We have a pinger which tells the server a 
client is “healthy” every 1 second. Caching the service proxy seems to do the 
trick. And we can manage topology change and refreshing a stale proxy another 
way.
Thanks.

From: Gordon Reid (Nine Mile) 
[mailto:gordon.r...@ninemilefinancial.com]
Sent: Tuesday, 4 July 2017 3:50 PM
To: user@ignite.apache.org
Subject: RE: Ignite very very chatty when java server nodes and .net client 
when using Service Grid

Some additional log which might be useful.

Why is it scanning for services when it’s running in client=true?

2017-07-04 15:33:27,304 [11] DEBUG 
org.apache.ignite.internal.processors.resource.GridResourceProcessor - 
Injecting resources: 
org.apache.ignite.internal.cluster.ClusterGroupAdapter$AttributeFilter@3398bf2d
2017-07-04 15:33:27,304 [11] DEBUG 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter - 
 Executing query [query=GridCacheQueryAdapter [type=SCAN, 
clsName=null, clause=null, filter=ServiceDeploymentPredicate [], 
transform=null, part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter 
[minTime=9223372036854775807, maxTime=0, sumTime=0, avgTime=0.0, execs=0, 
completed=0, fails=0], pageSize=1024, timeout=0, keepAll=false, 
incBackups=false, dedup=false, 
prj=org.apache.ignite.internal.cluster.ClusterGroupAdapter@628833ed,
 keepBinary=false, subjId=null, taskHash=0], nodes=[TcpDiscoveryNode 
[id=386f9b12-4dc3-48b4-a174-95a28387d624, addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 
172.31.21.182], sockAddrs=[/0:0:0:0:0:0:0:1%lo:48900, 
/127.0.0.1:48900, 
/172.31.21.182:48900], discPort=48900, order=1, 
intOrder=1, lastExchangeTime=1499146293372, loc=false, 
ver=2.0.0#20170430-sha1:d4eef3c6, isClient=false]]]
2017-07-04 15:33:27,304 [11] DEBUG 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager
 -  Executing distributed query: GridCacheQueryBean 
[qry=GridCacheQueryAdapter [type=SCAN, clsName=null, clause=null, 
filter=ServiceDeploymentPredicate [], transform=null, part=null, incMeta=false, 
metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0, 
sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, 
timeout=0, keepAll=false, incBackups=false, dedup=false, 
prj=org.apache.ignite.internal.cluster.ClusterGroupAdapter@628833ed,
 keepBinary=false, subjId=d30c7fa6-7a8e-4fe0-9bae-efb67d014a1e, taskHash=0], 
rdc=null, trans=null]
2017-07-04 15:33:27,305 [11] DEBUG 
org.apache.ignite.internal.processors.cache.GridCacheIoManager - Sending cache 
message [msg=GridCacheQueryRequest [id=4766, cacheName=ignite-sys-cache, 
type=SCAN, fields=false, clause=null, clsName=null, 
keyValFilter=ServiceDeploymentPredicate [], rdc=null, trans=null, 
pageSize=1024, incBackups=false, cancel=false, incMeta=false, all=false, 
keepPortable=false, subjId=d30c7fa6-7a8e-4fe0-9bae-efb67d014a1e, taskHash=0, 
part=-1, topVer=AffinityTopologyVersion [topVer=18, minorTopVer=0], 
super=GridCacheMessage [msgId=4767, depInfo=null, err=null, skipPrepare=false, 
cacheId=-2100569601, cacheId=-2100569601]], nodes=Grid nodes [cnt=1, 
ClusterNode [id=386f9b12-4dc3-48b4-a174-95a28387d624, order=1, 
addr=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.21.182], daemon=false]]]
2017-07-04 15:33:27,305 [11] DEBUG 
org.apache.ignite.internal.processors.cache.GridCacheIoManager - Sent cache 
message [msg=GridCacheQueryRequest [id=4766, cacheName=ignite-sys-cache, 

Re: High heap on ignite client

[Anil]

Hi Alex,

Thanks.

i have changed the swapiness to avoid sys time > user time. and did test
but no luck.

What do you mean by "apps/containers running on same physical machine" ?

You mean on kube instance ? if yes, yes there are number of
services/containers running on same kube cluster/instance.

Ignite client need high CPU ?

Thanks,
Anil

On 6 July 2017 at 17:39, afedotov  wrote:

> Hi,
>
> I've taken a look at the logs.
> I don't see huge heap consumption but from the GC log for node1 I can see
> that in a couple of GCs real time is greater than user and sys time, as
> well as
> in some cases sys time is higher than the user time. Taking into account
> that you are running kubernetes and probably in a virtual environment, I
> suspect that
> overselling takes place here. Please check if there are other
> apps/containers running on the same physical machine.
>
> Kind regards,
> Alex.
>
> On Thu, Jul 6, 2017 at 7:23 AM, Anil [via Apache Ignite Users] <[hidden
> email] > wrote:
>
>> Hi Alex,
>>
>> Did you get a chance to look into it ? thanks.
>>
>> Regards,
>> Anil
>>
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://apache-ignite-users.70518.x6.nabble.com/High-heap-on-
>> ignite-client-tp13594p14372.html
>> To start a new topic under Apache Ignite Users, email [hidden email]
>> 
>> To unsubscribe from Apache Ignite Users, click here.
>> NAML
>> 
>>
>
>
> --
> View this message in context: Re: High heap on ignite client
> 
> Sent from the Apache Ignite Users mailing list archive
>  at Nabble.com.
>

Re: Connecting to remote host from client gives error

[vkulichenko]

Then it might be blocked by firewall. These messages simply mean that client
can't establish connection with this socket address.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Connecting-to-remote-host-from-client-gives-error-tp14395p1.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: cassandra cache store with port

[vkulichenko]

Srini,

Please refer to [1] for information on how to use the store and
configuration examples.

If default port is not 9042, then I don't see an issue. You have to either
explicitly specify your default port, or provide all addresses as host:port
strings.

[1] https://apacheignite-mix.readme.io/docs/ignite-with-apache-cassandra

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/cassandra-cache-store-with-port-tp14412p14443.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: frequet disconnection in ignite cluster

[tysli2016]

Hi Rishi,

seems it's not a good idea to connect ignite repeatedly, I observed a
similar memory issue.
would you mind to share your server configurations (cores, memory)?

http://apache-ignite-users.70518.x6.nabble.com/Ignite-1-6-0-suspected-memory-leak-from-DynamicCacheDescriptor-td9443i20.html

http://apache-ignite-users.70518.x6.nabble.com/OOME-on-2-node-cluster-with-visor-running-repeatedly-Ignite-1-9-tt12409.html

Tom



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

Re: frequet disconnection in ignite cluster

[ignite_user2016]

Thank you.. Val for all your help.

I will investigate further..

We are monitoring ignite every 5 mins with shell script could that cause memory 
to go high ?

Take Care,
Rishi

> On Jul 6, 2017, at 4:50 PM, vkulichenko [via Apache Ignite Users] 
>  wrote:
> 
> Rishi, 
> 
> This is usually caused by either network or memory issues. Check that you 
> don't have any network glitches and that there are no GC pauses, memory 
> leaks, etc. on the nodes. 
> 
> -Val 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://apache-ignite-users.70518.x6.nabble.com/frequet-disconnection-in-ignite-cluster-tp14411p14420.html
> To start a new topic under Apache Ignite Users, email 
> ml+s70518n1...@n6.nabble.com 
> To unsubscribe from Apache Ignite Users, click here.
> NAML




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

Re: cache partitions

[Alexey Kuznetsov]

Hi!

What Ignite version do you use?
Also attach server and clients nodes configuration.
We will try to reproduce.



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

Re: Ignite web console

[Alexey Kuznetsov]

What version of ignite are you using?

May be Docker will be more suitable for you?
See: https://apacheignite-tools.readme.io/docs/docker-deployment



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

Re: Connecting to remote host from client gives error

[Abhishek Gupta]

Yes I do have a server nodes which is hosted on this ip address port
10.133.71.210:47500", I have run it by running ignite.sh.

It does not seem to be working. Any idea?

-Abhishek

On Fri, Jul 7, 2017 at 4:24 AM, vkulichenko 
wrote:

> You're starting a client node and it connect to server cluster. Do you have
> any server nodes?
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Connecting-to-remote-host-from-client-gives-error-
> tp14395p14434.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Event Listeners

[javastuff....@gmail.com]

Cached data change notifications are used in multiple use-cases. Here is one
-

We have OFFHEAP distributed Ignite cache fronted by JVM level local copy. It
is similar to what Near cache would work. However, Ignite Near cache (JVM
level local copy) also get serialized/de-serialized. which results in
latency compared to direct object access. So we are not using Ignite Near
cache but simulating same. To invalidate cache we rely on event
notifications. In some case, we need to clear all cached entries and that is
where we use cache.clear().

There are other scenarios where change event notifications are the
preliminary indication of data change, which needs to be notified to all
nodes to keep data and process consistency.  Message passing can be another
approach but it won't be completely consistent and tightly bound to data
change. 

Can I assume cache.clear() does not generate any event notification and need
to move away from it? Can you please help optimizing clear vs remove?

Thanks,
-Sam 

   



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

Re: cassandra cache store with port

[srini kandula]

Hi Val,

Yes, Cassandra listening to port other than 9042. 

Yes, I'm following the the tests approach. Should I explicitly create
cache configuration at runtime
and set it to the ignite instance?

Looking at the hibernate example, cache config instance is created with
in. Should I follow this way 
Or is there other way?

thanks,
 -Srini. 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/cassandra-cache-store-with-port-tp14412p14436.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cache refresh because of hibernate versioning mechanism.

[vkulichenko]

Hi Czeslaw,

Please properly subscribe to the mailing list so that the community can
receive email notifications for your messages. To subscribe, send empty
email to user-subscr...@ignite.apache.org and follow simple instructions in
the reply.


cszczotka wrote
> I’m using cache with read-through/write-through configuration and with
> database persistent store handled by hibernate Dao –s. Hibernate Dao –s (
> it is legacy code) also handling versioning and optimistic locking. 
> So situation looks like when I put into cache some entity this entity is
> written to database with version 1 set by hibernate but in cache I have
> entity with version 0. Calling get method on cache doesn’t help because
> this entity is in cache and load method from persistance store is not
> called.
> Do you have good way how to force ignite to refresh cache from DB ? I see
> in ignite documentation that I can subscribe on event
> EventType.EVT_CACHE_OBJECT_PUT and programmatically call load method on
> cache. Do you see better way ?  

I think it's better to configure CacheInterceptor and implement reload logic
in onAfterPut method. However, this will be a performance overhead.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Cache-refresh-because-of-hibernate-versioning-mechanism-tp14394p14435.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Connecting to remote host from client gives error

[vkulichenko]

You're starting a client node and it connect to server cluster. Do you have
any server nodes?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Connecting-to-remote-host-from-client-gives-error-tp14395p14434.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Compute Node computation on data node

[vkulichenko]

Hi,

Please take a look and play with examples provided by Ignite:
https://github.com/apache/ignite/tree/master/examples/src/main/java/org/apache/ignite/examples/computegrid

They show how to do this kind of basic operations.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Compute-Node-computation-on-data-node-tp14396p14433.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite 2.0 vs Ignite 1.7 (or later)

[vkulichenko]

Hi,

What exactly is consuming the memory? Do you have a heap dump?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-0-vs-Ignite-1-7-or-later-tp14401p14432.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Event Listeners

[vkulichenko]

Sam,

What is the business use case behind this?

-Val



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

Re: Ignite 1.6.0 suspected memory leak from DynamicCacheDescriptor

[vkulichenko]

Tom,

It sounds like these jobs are triggered pretty frequently. So why not create
a small application that will create an embedded client once and also have
an internal timer or cron based scheduler to execute jobs periodically. You
can do the topology check within this application as well, instead of using
Visor.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-1-6-0-suspected-memory-leak-from-DynamicCacheDescriptor-tp9443p14430.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Optimum CacheConfiguration for cross cache join SQL queries

[vkulichenko]

iostream wrote
> Hi,
> 
> I have 2 caches, each with POJO values that look like -
> 
> public class Value1 {
> 
>   @QuerySqlField(index = true)
>   private Long a;
> 
>   @QuerySqlField(index = true)
>   private String b;
> 
> }
> 
> public class Value2 {
> 
>   @QuerySqlField(index = true)
>   private Long a;
> 
>   @QuerySqlField(index = true)
>   private String c;
> 
> }
> 
> I have to run the following SQL query on my Ignite Cluster -
> 
> SELECT * from Value1 v1, Value2 v2 WHERE v1.a = v2.a
> 
> To test the query performance, I configured my Ignite Cluster to have only
> 1 server node and used 4 clients nodes to run the query. Added 50,000
> Value1 objects and around 800,000 Value2 objects in the cache. I used a
> single node cluster in order to avoid using affinity collocation problems
> when performing cross cache joins. The average response time of the query
> was around 150 seconds! :(
> 
> Server node - 4 CPUs, 8 GB Heap
> Client node - 4 CPUs / client, 1 GB Heap / client
> 
> I am quite surprised to see the SQL perform poorly. I am posting my
> cacheConfiguration for your reference (same for both the caches).
> 
> cacheConfig.setAtomicityMode("transactional");
> cacheConfig.setCacheMode("partitioned");
> cacheConfig.setBackups(1);
> cacheConfig.setCopyOnRead(false);
> cacheConfig.setIndexedTypes(Long.class, Value1.class);
> 
> I am wondering if the query performed poorly because of my cache
> configuration or is Ignite not very efficient with cross cache joins
> (given that I used only 1 node to avoid non-collcation)
> 
> Any help is appreciated!
> 
> Thank you.

First of all, your configuration doesn't look valid. Atomicity mode and
cache mode are enums not strings, code you provided will not compile.

As for performance, this query doesn't have any condition, so it scans at
least one of the tables. For such queries you should apply proper
collocation between two tables and scale it out by adding more nodes and/or
setting CacheConfiguration#queryParallelism to value more than 1. This will
parallelize execution and make it faster.

In addition I would check the execution and verify that it scans the smaller
table. If not, you can set SqlFieldsQuery#enforceJoinOrder to true and
rewrite the query to use explicit joins in preferred order.

And finally, my recommendation would be to pick a query that is closer to to
realistic use case. Queries like provided here will never be very fast as
they imply a lot of scanning. Scaling out is the only way to effectively
increase performance for them.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Optimum-CacheConfiguration-for-cross-cache-join-SQL-queries-tp14371p14429.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Optimum CacheConfiguration for cross cache join SQL queries

[vkulichenko]

Hi,

Please properly subscribe to the mailing list so that the community can
receive email notifications for your messages. To subscribe, send empty
email to user-subscr...@ignite.apache.org and follow simple instructions in
the reply.





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Optimum-CacheConfiguration-for-cross-cache-join-SQL-queries-tp14371p14428.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

RE: Dynamically update the Cache Configuration without restsrting client and serve

[vkulichenko]

Priya,

There are no configuration properties that can be changed in runtime.
However, most of your requirements seem to be related to dynamic schema
change. This already happens transparently on object level thanks to binary
format [1] used as a default data storage format. On SQL level this will be
possible when we have full DDL support.

[1] https://apacheignite.readme.io/docs/binary-marshaller

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Dynamically-update-the-Cache-Configuration-without-restsrting-client-and-serve-tp14303p14427.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Mix in cache keys objects with different types.

[vkulichenko]

Alexander,

It doesn't matter if you use SQL. Without SQL it should work though. Did you
get any exception when you tried this?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Mix-in-cache-keys-objects-with-different-types-tp14354p14426.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: The client does not receive response after closure completion...

[vkulichenko]

Hi Alexander,

Ticket for this already exists for a while:
https://issues.apache.org/jira/browse/IGNITE-5189

You can try to set java.net.preferIPv4Stack=true system property, usually it
helps to avoid this exception.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/The-client-does-not-receive-response-after-closure-completion-tp14334p14425.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: FairAffinityFunction in Ignite 2.0

[vkulichenko]

Hi Alexander,

This function provided inconsistent mapping for caches created on different
topology versions. Basically this means that collocation was not working
properly in some scenario, so we decided to get rid of this function. Please
use RendezvousAffinityFunction instead.

-Val



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

Re: Ignite Information

[vkulichenko]

Hi,

See CacheConfiguration#nodeFilter property. It's just a predicate that
filters out nodes, cache will be deployed only on those for which filter
returns true. The easiest way would be to set custom attributes via
IgniteConfiguration#userAttributes and filter out using AttributeNodeFilter
which is provided out of the box.

-Val



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

Re: Starting the Server

[vkulichenko]

Try to set java.net.preferIPv4Stack=true system property on all nodes.

-Val



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

Re: Unable to connect from Windows Java client to Linux server cluster (ignite 2.0.0)

[vkulichenko]

Hi Roger,

This is a known issue: https://issues.apache.org/jira/browse/IGNITE-5189

Try to set java.net.preferIPv4Stack=true system property.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Unable-to-connect-from-Windows-Java-client-to-Linux-server-cluster-ignite-2-0-0-tp14410p14421.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: frequet disconnection in ignite cluster

[vkulichenko]

Rishi,

This is usually caused by either network or memory issues. Check that you
don't have any network glitches and that there are no GC pauses, memory
leaks, etc. on the nodes.

-Val



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

Re: cassandra cache store with port

[vkulichenko]

Hi Srini,

Is Cassandra listening to port other than 9042?

Also how do you configure Cassandra store? connection.properties file is
used only in tests, Ignite doesn't actually provide this way of configuring.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/cassandra-cache-store-with-port-tp14412p14419.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Volatile Kubernetes Node Discovery

[vkulichenko]

Hi Stephen,

Please properly subscribe to the mailing list so that the community can
receive email notifications for your messages. To subscribe, send empty
email to user-subscr...@ignite.apache.org and follow simple instructions in
the reply.


macdonagh wrote
> Are there logs which will show the Kubernetes IP finder doing its job ?
> 
> I am running a similar scenario but i do not get as far.
> I expected to see traces from TcpDiscoveryKubernetesIpFinder in the ignite
> log but i do not.
> 
> Instead i see a warning 
> 
> [16:47:22,838][WARNING][main][TcpDiscoveryMulticastIpFinder]
> TcpDiscoveryMulticastIpFinder has no pre-configured addresses (it is
> recommended in production to specify at least one address in
> TcpDiscoveryMulticastIpFinder.getAddresses() configuration property)
> 
> even though my configuration file only contains the KubernetesIPFinder
> bean class.

You most likely misconfigured something. There is no way you will see logs
from TcpDiscoveryMulticastIpFinder if TcpDiscoveryKubernetesIpFinder is
configured. Check that correct configuration file is used.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Volatile-Kubernetes-Node-Discovery-tp12357p14418.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Large Key, eg UUID or String

[Roger Fischer (CW)]

Hello,

are there any concerns about larg-ish keys, like a UUID?

What if even larger, like a string of variable length?

I am using Ignite SQL.

Some objects have a single primary key, and in most cases it is a UUID. I am 
trying to decide if we should
a) create an artificial key (long) and have an id field (the UUID), or
b) use the UUID as the key (and have no query field for id, only the Java POJO 
field).

Other objects have a composite primary key. Again I have the choice to either
a) use an artificial Long as the key, or
b) concatenate the fields into a string and us the string as the key.
In this case I also need the individual fields as query fields. All queries are 
by field predicates (never by key).

Lastly, can Ignite generate a unique one on insert?

Thanks...

Roger

Getting Started with Apache® Ignite™ (Part 5)

[Dieds]

Getting Started with Apache® Ignite™ (Part 5). Akmal Chaudhri pens the fifth
article in this blog series focusing this time on the support for a
distributed SQL database. http://bit.ly/2suoIMc



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Getting-Started-with-Apache-Ignite-Part-5-tp14415.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Use AtomicLong or AtomicSequence in Streaming

[waterg]

Hi Val, yes, this is the same issue. Appreciate helping out.

Jessie



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Use-AtomicLong-or-AtomicSequence-in-Streaming-tp14350p14413.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

cassandra cache store with port

[srini kandula]

Hi,

   I'm using spring based cassandra cache store.
   In connection.properties, 
   contact.points=some-ip-address (working)
   contact.point=some-host-name(working)

   contact.points=some-ip-address:9042 (not working)
   contact.point=some-host-name:9042(not working)
 

   Tried with different versions of casssadra driver, cassandra with
Ignite 2.0.

   Inputs highly appreciated.

-Srini.
---
[WARN ][main][CassandraCacheStore] Host availability problem detected, CQL
execution attempt 1, sleeping extra 500 milliseconds
class org.apache.ignite.IgniteException: Failed to establish session with
Cassandra database
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.session(CassandraSessionImpl.java:549)
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:597)
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:133)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:275)
at
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.put(GridCacheStoreManagerAdapter.java:568)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:4404)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4226)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:3966)
at
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:2966)
at
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2860)
at
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.invokeDown(BPlusTree.java:1696)
at
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.invoke(BPlusTree.java:1585)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:925)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:326)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2386)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1792)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:480)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:440)
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.update0(GridDhtAtomicCache.java:1162)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:651)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2345)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2322)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1519)
at
com.optzed.ignite.cassandra.sample.IgniteCassandraPerson1.main(IgniteCassandraPerson1.java:69)
Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All
host(s) tried for query failed (tried: 192.168.1.107:9042
(com.datastax.driver.core.exceptions.TransportException: [null] Cannot
connect))
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:231)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1414)
at com.datastax.driver.core.Cluster.init(Cluster.java:162)
at 

frequet disconnection in ignite cluster

[ignite_user2016]

hello Igniters,

we are seeing frequent disconnection between ignite instances, we have IP
based clusters which has following configuration - 

Ignite version - 1.7.0

 









HOST_IP1:47500..47509
HOST_IP2:47500..47509







See the error log - 

[09:53:46,139][WARN ][tcp-disco-msg-worker-#2%WebGrid%][TcpDiscoverySpi]
Local node has detected failed nodes and started cluster-wide procedure. To
speed up failure detection please see 'Failure Detection' section under
javadoc for 'TcpDiscoverySpi'

[09:54:56,060][WARN
][exchange-worker-#54%WebGrid%][GridCachePartitionExchangeManager] Failed to
wait for partition map exchange [topVer=AffinityTopologyVersion
[topVer=22132, minorTopVer=0], node=d3719fe1-84cf-4fe5-91dd-2d10abb1b3d2].
Dumping pending objects that might be the cause:
[09:54:56,060][WARN
][exchange-worker-#54%WebGrid%][GridCachePartitionExchangeManager] Ready
affinity version: AffinityTopologyVersion [topVer=22131, minorTopVer=0]
[09:54:56,062][WARN
][exchange-worker-#54%WebGrid%][GridCachePartitionExchangeManager] Last
exchange future: GridDhtPartitionsExchangeFuture [dummy=false,
forcePreload=false, reassign=false, discoEvt=DiscoveryEvent
[evtNode=TcpDiscoveryNode [id=d2ffb86c-5305-4cb3-96a0-874be73d610a,
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, host_ip2],
sockAddrs=[host2/host_ip2:47501, 0:0:0:0:0:0:0:1%lo:47501,
/127.0.0.1:47501], discPort=47501, order=22131, intOrder=11068,
lastExchangeTime=1499352867440, loc=false, ver=1.7.0#20160801-sha1:383273e3,
isClient=false], topVer=22132, nodeId8=d3719fe1, msg=Node left:
TcpDiscoveryNode [id=d2ffb86c-5305-4cb3-96a0-874be73d610a,
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, host_ip2],
sockAddrs=[host2/host_ip2:47501, 0:0:0:0:0:0:0:1%lo:47501,
/127.0.0.1:47501], discPort=47501, order=22131, intOrder=11068,
lastExchangeTime=1499352867440, loc=false, ver=1.7.0#20160801-sha1:383273e3,
isClient=false], type=NODE_LEFT, tstamp=1499352886042], crd=TcpDiscoveryNode
[id=64ce302c-9743-47bc-bf27-641015a37b81, addrs=[127.0.0.1, host_ip1],
sockAddrs=[/127.0.0.1:47500, host1/host_ip1:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1498849915139, loc=false,
ver=1.7.0#20160801-sha1:383273e3, isClient=false],
exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion
[topVer=22132, minorTopVer=0], nodeId=d2ffb86c, evt=NODE_LEFT], added=true,
initFut=GridFutureAdapter [resFlag=2, res=true, startTime=1499352886042,
endTime=1499352886052, ignoreInterrupts=false, state=DONE],init=true,
topSnapshot=null, lastVer=null, partReleaseFut=GridCompoundFuture [rdc=null,
initFlag=1, lsnrCalls=3, done=true, cancelled=false, err=null, futs=[true,
true, true]], affChangeMsg=null, skipPreload=false,
clientOnlyExchange=false, initTs=1499352886042, centralizedAff=true,
evtLatch=0, remaining=[64ce302c-9743-47bc-bf27-641015a37b81],
srvNodes=[TcpDiscoveryNode [id=64ce302c-9743-47b
c-bf27-641015a37b81, addrs=[127.0.0.1, host_ip1],
sockAddrs=[/127.0.0.1:47500, host1/host_ip1:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1498849915139, loc=false,
ver=1.7.0#20160801-sha1:383273e3, isClient=false], TcpDiscoveryNode
[id=d3719fe1-84cf-4fe5-91dd-2d10abb1b3d2, addrs=[127.0.0.1, host_ip2],
sockAddrs=[/127.0.0.1:47500, host2/host_ip2:47500], discPort=47500, order=4,
intOrder=3, lastExchangeTime=1499352895809, loc=true,
ver=1.7.0#20160801-sha1:383273e3, isClient=false]], super=GridFutureAdapter
[resFlag=0, res=nul
l, startTime=1499352886042, endTime=0, ignoreInterrupts=false, state=INIT]]

[10:08:37,232][WARN
][exchange-worker-#54%WebGrid%][GridCachePartitionExchangeManager] Failed to
wait for partition map exchange [topVer=AffinityTopologyVersion
[topVer=22134, minorTopVer=0], node=
d3719fe1-84cf-4fe5-91dd-2d10abb1b3d2]. Dumping pending objects that might be
the cause:
[10:08:47,287][WARN
][exchange-worker-#54%WebGrid%][GridCachePartitionExchangeManager] Failed to
wait for partition map exchange [topVer=AffinityTopologyVersion
[topVer=22134, minorTopVer=0], node=
d3719fe1-84cf-4fe5-91dd-2d10abb1b3d2]. Dumping pending objects that might be
the cause:

class org.apache.ignite.IgniteException: Failed to wait for affinity ready
future for topology version: AffinityTopologyVersion [topVer=22134,
minorTopVer=0]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:526)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:434)
at

Unable to connect from Windows Java client to Linux server cluster (ignite 2.0.0)

[Roger Fischer (CW)]

Hello,

I am unable to make a connection from a client on Windows to an Ignite server 
cluster running on 3 Linux machines. I have checked firewall settings on both.

I am running a 3-node cluster of Ignite (2.0.0) on Centos 7. The nodes are 
connected to the same Ethernet switch. The cluster is established properly and 
everything works fine. I can connect (using my client) when it is running on 
any of the 3 linux machines.

I reduced the cluster to two nodes, and run the client on the third node. Again 
the client connects successfully.

There is no problem as long as I stay on the linux boxes.

I have tried 3 Windows PCs, with quite different configurations. None of them 
can connect to the Ignite cluster on the Linux machines.

PC1 runs Win7 Home, and is connected to the same Ethernet switch as the linux 
machines.

PC2 is a corporate laptop running Win7 Enterprise, connected over WiFi. I 
configured the firewall to allow in and outbound connections on 47100-47199 and 
47500-47599.

PC3 is another corporate laptop running Win10 Enterprise, also connected over 
WiFi. I verified that I can connect to port 47100 and 47500 on the linux boxes 
using Test-NetConnection.

Here is a snipped from the config file I use for the client. It is the same as 
the one used for the server (except for the client mode).











192.168.1.221
192.168.1.231




   





When starting the client (Java), the server log shows a client connected, but 
then disconnecting again.

[10:14:23] Topology snapshot [ver=11, servers=2, clients=1, CPUs=8, heap=3.8GB]
[10:14:49] Topology snapshot [ver=12, servers=2, clients=0, CPUs=4, heap=2.0GB]

The error I get when running the client:

$ java -Xms512m -Xmx2048m -jar target/igniteclient-1.0-SNAPSHOT.jar  
config/config-client-nodes-2-3.xml
[10:14:21]__  
[10:14:21]   /  _/ ___/ |/ /  _/_  __/ __/
[10:14:21]  _/ // (7 7// /  / / / _/
[10:14:21] /___/\___/_/|_/___/ /_/ /___/
[10:14:21]
[10:14:21] ver. 2.0.0#20170430-sha1:d4eef3c6
[10:14:21] 2017 Copyright(C) Apache Software Foundation
[10:14:21]
[10:14:21] Ignite documentation: http://ignite.apache.org
[10:14:21]
[10:14:21] Quiet mode.
[10:14:21]   ^-- Logging to file 
'C:\Utils\apache-ignite-fabric-1.8.0-bin\work\log\ignite-2aefb227.0.log'
[10:14:21]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or 
"-v" to ignite.{sh|bat}
[10:14:21]
[10:14:21] OS: Windows 7 6.1 amd64
[10:14:21] VM information: Java(TM) SE Runtime Environment 1.8.0_101-b13 Oracle 
Corporation Java HotSpot(TM) 64-Bit Server VM 25.101-b13
[10:14:21] Configured plugins:
[10:14:21]   ^-- None
[10:14:21]
[10:14:21] Message queue limit is set to 0 which may lead to potential OOMEs 
when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to 
message queues growth on sender and receiver sides.
[10:14:21] Security status [authentication=off, tls/ssl=off]
[10:14:22] REST protocols do not start on client node. To start the protocols 
on client node set '-DIGNITE_REST_START_ON_CLIENT=true' system property.
[10:14:49,257][SEVERE][exchange-worker-#24%null%][GridDhtPartitionsExchangeFuture]
 Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11, 
minorTopVer=0], nodeId=2aefb227, evt=NODE_JOINED]
class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
may have left the grid or TCP connection cannot be established due to firewall 
issues) [node=TcpDiscoveryNode [id=8abb0a7d-ae0e-4750-be9c-b00abbe03e64, 
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 192.168.1.221, 192.168.122.1, 
2001:569:7386:8b00:51f5:da65:665a:e3c6%enp2s0], 
sockAddrs=[/192.168.1.221:47500, /192.168.122.1:47500, 
/0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, 
node-1w7jr9qjyqppcanu92l72r5qe.ipv6.telus.net/2001:569:7386:8b00:51f5:da65:665a:e3c6:47500,
 2001:569:7386:8b00:51f5:da65:665a:e3c6%enp2s0:47500], discPort=47500, order=1, 
intOrder=1, lastExchangeTime=1499361263272, loc=false, 
ver=2.0.0#20170430-sha1:d4eef3c6, isClient=false], topic=TOPIC_CACHE, 
msg=GridDhtPartitionsSingleMessage [parts={-2100569601=GridDhtPartitionMap 
[moving=0, size=0], 689859866=GridDhtPartitionMap [moving=0, size=0], 
-399170495=GridDhtPartitionMap [moving=0, size=0]}, partCntrs={-2100569601={}, 
689859866={}, -399170495={}}, ex=null, client=true, compress=true, 
super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=11, minorTopVer=0], nodeId=2aefb227, 
evt=NODE_JOINED], lastVer=GridCacheVersion [topVer=0, order=1499361262057, 
nodeOrder=0], flags=1, super=GridCacheMessage [msgId=7, depInfo=null, err=null, 

Re: Passing parameters to IgniteBiPredicate

[Guilherme Melo]

Hello Taras,
thanks, this example is showing a normal query with a fixed value, this is
working, the problem is passing a parameter to the predicate.

Cheers,

Guilherme Melo
www.gmelo.org

On 6 July 2017 at 22:18, Taras Ledkov  wrote:

> Hi,
>
> Sure, please take a look at the example:
> https://github.com/apache/ignite/blob/master/examples/
> src/main/java/org/apache/ignite/examples/datagrid/
> CacheQueryExample.java#L155
>
> On 06.07.2017 11:13, Guilherme Melo wrote:
>
> Hello, I am having problems submitting a query to the service from a
> client. Using the example from the documentation:
>
> IgniteCache cache = ignite.cache("mycache");
> int sal = 100// Find only persons earning more than 1,000.try (QueryCursor 
> cursor = cache.query(new ScanQuery((k, p) -> p.getSalary() > sal)) {
>   for (Person p : cursor)
> System.out.println(p.toString());
> }
>
>
> It fails silently. I have also tried creating a class that implements the
>  IgniteBiPredicate that takes the value as a parameter on the constructor.
> Has anyone had experience pushing a scan query with parameters?
> Thanks !
>
>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>

Starting the Server

[sanaraya]

Hi ,
 I am getting below Exception while starting the ignite.sh .
 
  at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1334)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1398)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:946)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1094)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendPartitions(GridDhtPartitionsExchangeFuture.java:1142)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:874)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:573)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1806)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
message to remote node: TcpDiscoveryNode
[id=608c6f81-7857-40c0-9894-5612ecb6be20, addrs=[0:0:0:0:0:0:0:1%lo,
10.133.7.253, 10.133.75.143, 127.0.0.1, 172.17.0.1, 192.168.122.1],
sockAddrs=[hnas02-admin-evs.bmc.com/172.17.0.1:47500,
ips-egr-ind-pun5-dmz-lb-srv.bmc.com/192.168.122.1:47500,
/10.133.7.253:47500, 0:0:0:0:0:0:0:1%lo:47500, /10.133.75.143:47500,
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
lastExchangeTime=1499349577445, loc=false, ver=2.0.0#20170430-sha1:d4eef3c6,
isClient=false]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2483)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2419)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1329)
... 9 more
Caused by: class org.apache.ignite.IgniteCheckedException:
java.lang.NullPointerException
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2630)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2455)
... 11 more




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

Re: Passing parameters to IgniteBiPredicate

[Taras Ledkov]

Hi,

Sure, please take a look at the example:
https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheQueryExample.java#L155


On 06.07.2017 11:13, Guilherme Melo wrote:
Hello, I am having problems submitting a query to the service from a 
client. Using the example from the documentation:


|IgniteCache cache = ignite.cache("mycache"); int sal = 
100 // Find only persons earning more than 1,000. try (QueryCursor 
cursor = cache.query(new ScanQuery((k, p) -> p.getSalary() > sal)) { 
for (Person p : cursor) System.out.println(p.toString()); }|


It fails silently. I have also tried creating a class that implements 
the IgniteBiPredicate that takes the value as a parameter on the 
constructor.

Has anyone had experience pushing a scan query with parameters?
Thanks !


--
Taras Ledkov
Mail-To: tled...@gridgain.com

Compute Node computation on data node

[abhishek dutta gupta]

How I can do the computation on compute node and data node?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Compute-Node-computation-on-data-node-tp14396.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: verify me

[Pavel Tupitsyn]

Verified! :)

On Thu, Jul 6, 2017 at 4:26 PM, Abhishek Gupta <
abhishekduttagupta2...@gmail.com> wrote:

> Hi,
>
> Please verify me
>

Re: Poor cross cache join SQL performance (v2.0.0)

[iostream]

Hi Alex,

Yes Value2.class was already added to indextypes.

I am only reading the value which is why copyOnRead is set to "false".



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Poor-cross-cache-join-SQL-performance-v2-0-0-tp14373p14382.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Passing parameters to IgniteBiPredicate

[Guilherme Melo]

Hello, I am having problems submitting a query to the service from a
client. Using the example from the documentation:

IgniteCache cache = ignite.cache("mycache");
int sal = 100// Find only persons earning more than 1,000.try
(QueryCursor cursor = cache.query(new ScanQuery((k, p) ->
p.getSalary() > sal)) {
  for (Person p : cursor)
System.out.println(p.toString());
}


It fails silently. I have also tried creating a class that implements the
 IgniteBiPredicate that takes the value as a parameter on the constructor.
Has anyone had experience pushing a scan query with parameters?
Thanks !

Re: Poor cross cache join SQL performance (v2.0.0)

[afedotov]

Hi,

Add Value2 to the list of the indexed classes (setIndexedTypes).
What is the reason for setting copyOnRead(false)?

If the problem still stands after the fix, please check GC or take a JFR.

Kind regards,
Alex

6 июля 2017 г. 7:29 AM пользователь "iostream [via Apache Ignite Users]" <
ml+s70518n14373...@n6.nabble.com> написал:

Hi,

I have 2 caches, each with POJO values that look like -

public class Value1 {

@QuerySqlField(index = true)
private Long a;

@QuerySqlField(index = true)
private String b;

}

public class Value2 {

@QuerySqlField(index = true)
private Long a;

@QuerySqlField(index = true)
private String c;

}

I have to run the following SQL query on my Ignite Cluster -

SELECT * from Value1 v1, Value2 v2 WHERE v1.a = v2.a

To test the query performance, I configured my Ignite Cluster to have only
1 server node and used 4 clients nodes to run the query. Added 50,000
Value1 objects and around 800,000 Value2 objects in the cache. I used a
single node cluster in order to avoid using affinity collocation problems
when performing cross cache joins. The average response time of the query
was around 150 seconds! :(

Server node - 4 CPUs, 8 GB Heap
Client node - 4 CPUs / client, 1 GB Heap / client

I am quite surprised to see the SQL perform poorly. I am posting my
cacheConfiguration for your reference (same for both the caches).

cacheConfig.setAtomicityMode("transactional");
cacheConfig.setCacheMode("partitioned");
cacheConfig.setBackups(1);
cacheConfig.setCopyOnRead(false);
cacheConfig.setIndexedTypes(Long.class, Value1.class);

I am wondering if the query performed poorly because of my cache
configuration or is Ignite not very efficient with cross cache joins (given
that I used only 1 node to avoid non-collcation)

Any help is appreciated!

Thank you.

--
If you reply to this email, your message will be added to the discussion
below:
http://apache-ignite-users.70518.x6.nabble.com/Poor-cross-cache-join-SQL-
performance-v2-0-0-tp14373.html
To start a new topic under Apache Ignite Users, email
ml+s70518n1...@n6.nabble.com
To unsubscribe from Apache Ignite Users, click here

.
NAML





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Poor-cross-cache-join-SQL-performance-v2-0-0-tp14373p14379.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: The client does not receive response after closure completion...

[Alexander Ivanov]

Hi, Val!

The problem is solved in that such modifications in filterReachable()
method:

for (Future fut : futs) {
try {
fut.get();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();

throw new IgniteException("Thread has been interrupted.",
e);
} catch (ExecutionException e) {
*//throw new IgniteException(e);
   continue;
*}
}

One null make unreachable all address list...

Александр



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/The-client-does-not-receive-response-after-closure-completion-tp14334p14378.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.