Index

[javastuff....@gmail.com]

Hi,

How to check index is created? How many indexes are present? What is the
definition of index?

Thanks,
--Sambhav



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

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[bintisepaha]

Andrey, in the exception above, we see this

 pendingLocks=[KeyCacheObjectImpl [val=PositionId [fundAbbrev=BVI,
clearBrokerId=12718, insIid=679675, strategy=AFI, traderId=6531,
valueDate=19000101], hasValBytes=true]], super=GridCompoundIdentityFuture
[super=GridCompoundFuture [rdc=Bool reducer: true, initFlag=0, lsnrCalls=0,
done=true, cancelled=false, err=null, futs=[]]]
class
org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException:
Failed to acquire lock within provided timeout for transaction
[timeout=1,
tx=org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter$1@7597f862]

What does this mean? clearly its a pendingLock and we know that be behavior
because every subsequent update to this key fails with a txn timeout. But up
until this point, all updates were fine.

Thanks,
Binti



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Pessimistic-TXN-did-not-release-lock-on-a-key-all-subsequent-txns-failed-tp10536p11968.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[bintisepaha]

We got into the key lock situation again today.
Does the below error help in identifying anything?

Apr 13, 2017 2:16:09 PM org.apache.ignite.logger.java.JavaLogger error
SEVERE:  Failed to acquire lock for request: GridNearLockRequest
[topVer=AffinityTopologyVersion [topVer=1980, minorTopVer=34],
miniId=0628e8f4b51-2d0a76c5-854f-4909-90ed-b12db61a1632, implicitTx=false,
implicitSingleTx=false, onePhaseCommit=false, dhtVers=[null],
subjId=bdd5e4ed-aac9-4769-b241-a2e6f21f7e18, taskNameHash=0,
hasTransforms=false, syncCommit=true, accessTtl=-1, retVal=true,
firstClientReq=false, filter=null, super=GridDistributedLockRequest
[nodeId=bdd5e4ed-aac9-4769-b241-a2e6f21f7e18, nearXidVer=GridCacheVersion
[topVer=103141927, time=1492107359249, order=1492027414045, nodeOrder=13],
threadId=83, futId=e528e8f4b51-2d0a76c5-854f-4909-90ed-b12db61a1632,
timeout=1, isInTx=true, isInvalidate=false, isRead=true,
isolation=REPEATABLE_READ, retVals=[true], txSize=0, flags=0, keysCnt=1,
super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=103141927,
time=1492107359249, order=1492027414045, nodeOrder=13], committedVers=null,
rolledbackVers=null, cnt=0, super=GridCacheMessage [msgId=4632574,
depInfo=null, err=null, skipPrepare=false, cacheId=812449097,
cacheId=812449097
class
org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException:
Failed to acquire lock within provided timeout for transaction
[timeout=1,
tx=org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter$1@7597f862]
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:3924)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:3874)
at
org.apache.ignite.internal.util.future.GridEmbeddedFuture$2.applyx(GridEmbeddedFuture.java:91)
at
org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:297)
at
org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:290)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:263)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:251)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:381)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:752)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$600(GridDhtLockFuture.java:79)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1116)
at
org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:159)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)

Apr 13, 2017 2:16:09 PM org.apache.ignite.logger.java.JavaLogger error
SEVERE:  Future execution resulted in error: GridDhtEmbeddedFuture
[super=GridEmbeddedFuture [embedded=GridEmbeddedFuture
[embedded=GridDhtLockFuture
[nearNodeId=bdd5e4ed-aac9-4769-b241-a2e6f21f7e18,
nearLockVer=GridCacheVersion [topVer=103141927, time=1492107359249,
order=1492027414045, nodeOrder=13], topVer=AffinityTopologyVersion
[topVer=1980, minorTopVer=34], threadId=83,
futId=ee848215b51-be4c49fc-3ecf-43d8-a667-8bbe34fa045d,
lockVer=GridCacheVersion [topVer=103141927, time=1492107359742,
order=1492027414057, nodeOrder=17], read=true, err=null, timedOut=true,
timeout=1, tx=GridDhtTxLocal
[nearNodeId=bdd5e4ed-aac9-4769-b241-a2e6f21f7e18,
nearFutId=e528e8f4b51-2d0a76c5-854f-4909-90ed-b12db61a1632,
nearMiniId=0628e8f4b51-2d0a76c5-854f-4909-90ed-b12db61a1632,
nearFinFutId=d088e8f4b51-2d0a76c5-854f-4909-90ed-b12db61a1632,
nearFinMiniId=e088e8f4b51-2d0a76c5-854f-4909-90ed-b12db61a1632,
nearXidVer=GridCacheVersion [topVer=103141927, time=1492107359249,
order=1492027414045, nodeOrder=13], super=GridDhtTxLocalAdapter
[nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
depEnabled=false, txState=IgniteTxStateImpl [activeCacheIds=GridLongList
[idx=1, arr=[812449097]], txMap={IgniteTxKey [key=KeyCacheObjectImpl
[val=PositionId [fundAbbrev=BVI, clearBrokerId=12718, insIid=679675,
strategy=AFI, traderId=6531, valueDate=19000101], hasValBytes=true],
cacheId=812449097]=IgniteTxEntry [key=KeyCacheObjectImpl [val=PositionId
[fundAbbrev=BVI, clearBrokerId=12718, insIid=679675, strategy=AFI,
traderId=6531, valueDate=19000101], hasValBytes=true], 

Re: Error During data Loading using Ignite Data Streamer in Parallel

[vdpyatkov]

Hi,

Ignite DataStreamer with IgniteDataStreamer#allowOverwrite is false does not
work correct on instable topology until latest version.

If you want to Failover SPI will be used, you can set the property
(IgniteDataStreamer#allowOverwrite) is true.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Error-During-data-Loading-using-Ignite-Data-Streamer-in-Parallel-tp11912p11966.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

When is CacheStoreAdapter sessionEnd method called?

[waterg]

Hello, 

When is CacheStoreAdapter sessionEnd method called?
I implemented a persistent store with a overriding sessionEnd mothod like
this.

@Override
public void sessionEnd(boolean commit) {
Connection conn = null;
System.out.println("CALL me ");
try  {
conn = ses.attachment();
if (conn != null && ses.isWithinTransaction()) {
if (commit)
conn.commit();
else
conn.rollback();
conn.close();
}
}
catch (SQLException e) {
throw new CacheWriterException("Failed to end store session.",
e);
}
}

But it was never called. Which then may lead to connection not properly
closed
And could be a reason that led to this error.
http://apache-ignite-users.70518.x6.nabble.com/visor-failed-to-connect-to-cluster-td11919.html

What I noticed below is that almost 20K, waiting on port.

username@servername:~> netstat -ntu | grep  | grep WAIT | wc -l
19711
tcp0  0 :55699 :  TIME_WAIT
tcp0  0 :34312 :  TIME_WAIT
tcp0  0 :42490 : TIME_WAIT
tcp0  0 :60265 :  TIME_WAIT

appreciate your help!




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/When-is-CacheStoreAdapter-sessionEnd-method-called-tp11965.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Persistent store connection pool xml configuration

[waterg]

Thank you! I'll give it a try.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Persistent-store-connection-pool-xml-configuration-tp11959p11964.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Persistent store connection pool xml configuration

[Alexey Kuznetsov]

Hi,

May be this:
https://apacheignite.readme.io/docs/persistent-store#section-cachejdbcpojostore



On Fri, Apr 14, 2017 at 12:27 AM, waterg 
wrote:

> Hello,
>
> I'm looking into using connection pool for persistent store and found the
> example below.
>
> https://github.com/apache/ignite/blob/master/examples/
> src/main/java/org/apache/ignite/examples/datagrid/store/jdbc/
> CacheJdbcStoreExample.java
>
> What would be equivalent configuration in xml?
>
> Thank you!
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Persistent-store-connection-pool-xml-configuration-
> tp11959.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Alexey Kuznetsov

Persistent store connection pool xml configuration

[waterg]

Hello,

I'm looking into using connection pool for persistent store and found the
example below.

https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/datagrid/store/jdbc/CacheJdbcStoreExample.java

What would be equivalent configuration in xml?

Thank you!




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Persistent-store-connection-pool-xml-configuration-tp11959.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: visor failed to connect to cluster

[waterg]

thank you. That's spot on



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/visor-failed-to-connect-to-cluster-tp11919p11958.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite Node Discovery IP config

[Ramzinator]

Hi all,

I'm trying to configure my Ignite nodes in such a way that:
Node1 sees Node 3 but does not see Node 2
Node2 sees Node 3 but does not see Node 1
Node3 sees Node 1 & 2

You can find the code here:

Test.java
  

However the output is as follows:

Node 1: 1
Node 2: 2
Node 3: 2

For some reason, after multiple runs, Node 3 consistently only detects one
of Node1 and Node2.

Am I missing any configuration to ensure the detection of both nodes by Node
3?

Thanks,
Ramzinator



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

Re: OOM when using Ignite as HDFS Cache

[dkarachentsev]

Hi Shuai,

Could you please take heap dump on OOME and find what objects consume
memory? There would be a lot of byte[] objects, please find the nearest GC
root for them.

Thanks!

-Dmitry.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/OOM-when-using-Ignite-as-HDFS-Cache-tp11900p11956.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Lots of cache creation become slow

[ctranxuan]

Well, actually we were interesting in having continuous queries listening
multi-tenant caches.

This was the postulate for the architecture of a PoC project. Based on this
discussion, we are switching to another architecture postulate where we have
one cache with thousands continuous queries listening the changes of
thousands keys of the cache (basically 1 continuous query per key).

So, at the beginning, we were investigating how many caches / continuous
queries could be supported by a node. May be, it's not the right way to
evaluate this?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Lots-of-cache-creation-become-slow-tp11875p11955.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[Tolga HOŞGÖR]

It is not applicable because it will require too much effort to convert the
rest of the system for ACTIVE/ACTIVE set-up.

On Thu, Apr 13, 2017 at 5:10 PM vkulichenko 
wrote:

> Why not create two equal C++ nodes and use both of them? You will give you
> data redundancy and load balancing, without any custom affinity functions.
>
> Your model seems to be worse and also requires more effort. I would
> recommend to use abilities provided by Ignite out of the box.
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/How-do-I-provide-AffinityFunction-BackupFilter-when-mainly-using-C-bindings-tp11930p11953.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[vkulichenko]

Why not create two equal C++ nodes and use both of them? You will give you
data redundancy and load balancing, without any custom affinity functions.

Your model seems to be worse and also requires more effort. I would
recommend to use abilities provided by Ignite out of the box.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/How-do-I-provide-AffinityFunction-BackupFilter-when-mainly-using-C-bindings-tp11930p11953.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Cluster Groups with Affinity Behaviour

[Ramzinator]

Hi all,

I have a question regarding the behavior of affinity calls with cluster
groups.
Consider the following test:

Test.java
  

In the test I have 2 ignite nodes: N1 & N2 belonging to the same topology.
Each with a user attribute: 
N1: ROLE --> role1
N2: ROLE --> role2

When I do:

ClusterGroup clusterGroup = node1.cluster().forAttribute(ROLE, "role2");
node2.compute(clusterGroup).affinityCall(CACHE_NAME, "some key", callable);

I would expect the computation to take place on node2 ONLY since it's the
only node in the Cluster.
However, it seems that the affinity of the cache overrides the clusterGroup
and it proceeds to execute on node 1 regardless of the API of
compute(clusterGroup) which states: 

"All operations on the returned IgniteCompute instance will only include
nodes from this cluster group."

Would appreciate your input on this, and also if anyone has an idea on how I
can do an affinityCall on a specific sub-cluster, it would be a great help.

Another question: Is it possible to specify what nodes a cache can use. So
that I can be sure when doing an affinityCall on the cache, I am sure of the
nodes involves in executing the callable?

Thanks a lot,
Ramzinator





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Cluster-Groups-with-Affinity-Behaviour-tp11952.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[Tolga HOŞGÖR]

This will do it. I have found out ClusterNode::attribute also includes
environment variables so I can even further identify my nodes.

I also want to make sure if I get *setAffinityBackupFilter* right. Let's
say I have two nodes and I return *false* for one of them and *true* for
the other. I assume the one with *false* return will be assigned as
*PRIMARY* and the one I return *true* will be assigned as *BACKUP*. Is it
correct or the false one is not eligible to hold data at all and a primary
is chosen among backups?

On Thu, Apr 13, 2017 at 4:23 PM Igor Sapego  wrote:

> Well, there is a way to get C++ nodes. You can use the following code for
> this:
>
> IgniteCluster#forAttribute("org.apache.ignite.platform", "cpp");
>
> That returns you a cluster group of C++ nodes if that's what you need.
>
> Best Regards,
> Igor
>
> On Thu, Apr 13, 2017 at 4:05 PM, Tolga HOŞGÖR 
> wrote:
>
>> I have managed to put a AffinityFunction implementation in ./libs and
>> load/use it. But I still could not figure out how to detect my C++ node.
>>
>> I see C++ API allows you to name my node via *Ignition::Start(const
>> IgniteConfiguration , const char *name)* but ClusterNode
>> 
>>  does
>> not have a method to get the node's name. It allows you to get the
>> attributes but C++ does not provide anything to set the attribute on the
>> node. What would you recommend to distinguish my C++ node?
>>
>> On Thu, Apr 13, 2017 at 4:04 PM tolga  wrote:
>>
>>> I have managed to put a AffinityFunction implementation in ./libs and
>>> load/use it. But I still could not figure out how to detect my C++ node.
>>>
>>> I see C++ API allows you to name my node via /Ignition::Start(const
>>> IgniteConfiguration , const char *name)/ but  ClusterNode
>>> <
>>> https://www.gridgain.com/sdk/pe/latest/javadoc/org/apache/ignite/cluster/ClusterNode.html
>>> >
>>> does not have a method to get the node's name. It allows you to get the
>>> attributes but C++ does not provide anything to set the attribute on the
>>> node. What would you recommend to distinguish my C++ node?
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-ignite-users.70518.x6.nabble.com/How-do-I-provide-AffinityFunction-BackupFilter-when-mainly-using-C-bindings-tp11930p11945.html
>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>>
>>
>

Re: Ignite server showing this error class org.apache.ignite.IgniteCheckedException: Failed to send message (node may have left the grid or TCP connection cannot be established due to firewall issue

[vdpyatkov]

Hi,

1) Yes, default configuration failower SPI should by fit. Not need to
configure it specify at most cases.

2) Why are you think so? If it is, what are results when you try to execute
task, but node is out of topology?
Can you provide reproducer?

3) The information often contains in the logs from other nodes from cluster
and specific message in the node which leave the grid.
If a node get out of topology, this mean when Discovery SPI could not save
all nodes in cluster. You should concentrate on message from the service.

Usually node fail by reason of log time GC pause. Lock at the article[1] and
configure your system as recommended.

PS:

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.


[1]: https://apacheignite.readme.io/docs/jvm-and-system-tuning



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-server-showing-this-error-class-org-apache-ignite-IgniteCheckedException-Failed-to-send-messa-tp11871p11950.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[Igor Sapego]

Well, there is a way to get C++ nodes. You can use the following code for
this:

IgniteCluster#forAttribute("org.apache.ignite.platform", "cpp");

That returns you a cluster group of C++ nodes if that's what you need.

Best Regards,
Igor

On Thu, Apr 13, 2017 at 4:05 PM, Tolga HOŞGÖR  wrote:

> I have managed to put a AffinityFunction implementation in ./libs and
> load/use it. But I still could not figure out how to detect my C++ node.
>
> I see C++ API allows you to name my node via *Ignition::Start(const
> IgniteConfiguration , const char *name)* but ClusterNode
> 
>  does
> not have a method to get the node's name. It allows you to get the
> attributes but C++ does not provide anything to set the attribute on the
> node. What would you recommend to distinguish my C++ node?
>
> On Thu, Apr 13, 2017 at 4:04 PM tolga  wrote:
>
>> I have managed to put a AffinityFunction implementation in ./libs and
>> load/use it. But I still could not figure out how to detect my C++ node.
>>
>> I see C++ API allows you to name my node via /Ignition::Start(const
>> IgniteConfiguration , const char *name)/ but  ClusterNode
>> > ignite/cluster/ClusterNode.html>
>> does not have a method to get the node's name. It allows you to get the
>> attributes but C++ does not provide anything to set the attribute on the
>> node. What would you recommend to distinguish my C++ node?
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.
>> 70518.x6.nabble.com/How-do-I-provide-AffinityFunction-
>> BackupFilter-when-mainly-using-C-bindings-tp11930p11945.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>

Re: Huge delays while returning data back from remote callable's

[Nikolai Tikhonov]

Yuriy,

I don't have any ideas. Could you create simple maven project which
reproduce the behaviour and share it?

On Tue, Apr 4, 2017 at 4:23 PM, Nikolai Tikhonov 
wrote:

> I've tried reproduce the behaviour on my side (used your code snippet
> above) but without success. Could you profile your application by fly
> recorder? You can use the following settings https://apacheignite.
> readme.io/docs/jvm-and-system-tuning#section-flightrecorder-settings.
>
> On Fri, Mar 31, 2017 at 4:21 PM, Nikolai Tikhonov 
> wrote:
>
>> Let's try to increase  the following parameter
>> TcpCommunicationSpi#setUnacknowledgedMessagesBufferSize to 1_000_000.
>>
>> On Fri, Mar 31, 2017 at 2:03 PM, yishchuk  wrote:
>>
>>> I've enabled GC logging as you suggested, and attached the results.
>>>
>>> gc-L01.log
>>> 
>>> gc-L02.log
>>> 
>>> gc-L03.log
>>> 
>>> gc-L05.log
>>> 
>>> gc-L06.log
>>> 
>>>
>>> gc-CLIENT.log
>>> >> gc-CLIENT.log>
>>>
>>> last call took on server L06 3.21271845s, and on the client -
>>> 30.815496906s
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://apache-ignite-users.705
>>> 18.x6.nabble.com/Huge-delays-while-returning-data-back-from-
>>> remote-callable-s-tp11561p11606.html
>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>>
>>
>>
>

Re: Slow on 1st time query "SQL Join"

[afedotov]

Created a ticket for the issue IGNITE-4957


Kind regards,
Alex.

On Thu, Apr 13, 2017 at 3:18 PM, Sergi Vladykin [via Apache Ignite Users] <
ml-node+s70518n11942...@n6.nabble.com> wrote:

> Alex, I think we have to create an issue in Jira. This behavior looks
> suboptimal to me.
>
> Sergi
>
> 2017-04-13 15:12 GMT+03:00 afedotov <[hidden email]
> >:
>
>> Charles,
>>
>> In your case, you have many caches registered on server nodes (debug
>> shows me about 80) which are to be created on
>> the client. These caches don't participate in common activities, instead
>> they are used to prepare execution plan.
>> As for now, a separate request is sent to remote nodes for each
>> unregistered cache.
>> You can use client mode, but you need to register all the missing caches
>> before running queries.
>> After loading missing caches explicitly the time reduced to 50-60ms in
>> client mode.
>>
>> I've used a trick to avoid declaring all the caches in configuration file
>> or calling getOrCreateCache for each of them.
>> To give it a try, just add the line below before the queries execution
>> logic in your example.
>> IgniteStorage.getInstance().getIgniteCache(Quote.class.getName(), 0
>> ).unwrap(IgniteCacheProxy.class).context().kernalContext().
>> cache().createMissingCaches();
>>
>> Kind regards,
>> Alex.
>>
>> On Thu, Apr 13, 2017 at 10:08 AM, woo charles [via Apache Ignite Users] 
>> <[hidden
>> email] > wrote:
>>
>>> "If you select some data from the joined table it leads to all dynamic
>>> cache creation requests being sent" <-- is that mean the client node will
>>> copy the selected table to local?
>>>
>>> If I set false to client mode, it will become server node and
>>> start participate in caching, compute execution, stream processing, etc.,
>>> Then it will affect the performance of my client program. How can I
>>> prevent this?
>>>
>>> 2017-04-13 14:24 GMT+08:00 afedotov <[hidden email]
>>> >:
>>>
 Hi,

 Sergi, when join query is called from client
 It leads to createMissingCaches being called which makes a remote
 requests of a dynamic cache creation for each registered but not enabled
 cache and since there is a cache for each entity there are many requests to
 server nodes.

 Charles,
 If you select some data from the joined table it leads to all dynamic
 cache creation requests being sent therefore allowing to skip these on the
 next query runs.
 To disable client mode in your example just pass false to
 Ignition.setClientMode(true)

 Kind regards,
 Alex



 13 апр. 2017 г. 5:22 AM пользователь "woo charles [via Apache Ignite
 Users]" <[hidden email]
 > написал:

 I found that this time can be reduced to a value below 100ms if I
 already selected some data from join query related table.
 For example,
 if I run 2 query "select * from Quote where stock_id = xxx" & "Select *
 from StockInfo where stock_id = xxx"  first and then run the join query,
 the time for 1st join query will become similar to other(around 10 -20
 ms).
 Why will it happen?

 Also, How to run queries from a server node? I had try
 "ignite.compute().run()" but it doesn't work.


 thanks& best regards,
 Charles

 2017-04-13 0:48 GMT+08:00 Sergi Vladykin <[hidden email]
 >:

> Alex,
>
> Why do we have such a huge difference between client nodes and server
> nodes? Looks like we should fix it if possible. Even 7 seconds looks too
> much for me.
>
> Sergi
>
> 2017-04-12 18:11 GMT+03:00 afedotov <[hidden email]
> >:
>
>> Hi Charles,
>>
>> You are running the query from a client node what implies additional
>> network round trips.
>> Try to run queries from a server node. In my environment it reduced
>> the time from about 7 seconds to 220ms for the first run.
>>
>> Kind regards,
>> Alex.
>>
>> On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite
>> Users] <[hidden email]
>> > wrote:
>>
>>> *Sorry for wrong calculation *
>>> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60
>>> table] data)*
>>>
>>> *Best Regards,*
>>> *Charles*
>>>
>>> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
>>> >:
>>>
 *Source
 code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
 *

 *Below is a 

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[Tolga HOŞGÖR]

I have managed to put a AffinityFunction implementation in ./libs and
load/use it. But I still could not figure out how to detect my C++ node.

I see C++ API allows you to name my node via *Ignition::Start(const
IgniteConfiguration , const char *name)* but ClusterNode

does
not have a method to get the node's name. It allows you to get the
attributes but C++ does not provide anything to set the attribute on the
node. What would you recommend to distinguish my C++ node?

On Thu, Apr 13, 2017 at 4:04 PM tolga  wrote:

> I have managed to put a AffinityFunction implementation in ./libs and
> load/use it. But I still could not figure out how to detect my C++ node.
>
> I see C++ API allows you to name my node via /Ignition::Start(const
> IgniteConfiguration , const char *name)/ but  ClusterNode
> <
> https://www.gridgain.com/sdk/pe/latest/javadoc/org/apache/ignite/cluster/ClusterNode.html
> >
> does not have a method to get the node's name. It allows you to get the
> attributes but C++ does not provide anything to set the attribute on the
> node. What would you recommend to distinguish my C++ node?
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/How-do-I-provide-AffinityFunction-BackupFilter-when-mainly-using-C-bindings-tp11930p11945.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[tolga]

I have managed to put a AffinityFunction implementation in ./libs and
load/use it. But I still could not figure out how to detect my C++ node.

I see C++ API allows you to name my node via /Ignition::Start(const
IgniteConfiguration , const char *name)/ but  ClusterNode

  
does not have a method to get the node's name. It allows you to get the
attributes but C++ does not provide anything to set the attribute on the
node. What would you recommend to distinguish my C++ node?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/How-do-I-provide-AffinityFunction-BackupFilter-when-mainly-using-C-bindings-tp11930p11945.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

UnSubscribe

[pavan agrawal]

-- 
Thanks & Regards
Pavan Agrawal

Re: Repeatable cache updates

[nskovpin]

Thank you for your answer. I have additional question: I wrote code with
CacheInterceptor and i can easely react on igniteCache.put(key, value)
method. But what should i do to listen IgniteDataStreamer.addData(k,v)
method. The only one decision i've found - create receiver and explicitly
call cache.put. Am i missing something?



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

Re: Slow on 1st time query "SQL Join"

[Sergi Vladykin]

Alex, I think we have to create an issue in Jira. This behavior looks
suboptimal to me.

Sergi

2017-04-13 15:12 GMT+03:00 afedotov :

> Charles,
>
> In your case, you have many caches registered on server nodes (debug shows
> me about 80) which are to be created on
> the client. These caches don't participate in common activities, instead
> they are used to prepare execution plan.
> As for now, a separate request is sent to remote nodes for each
> unregistered cache.
> You can use client mode, but you need to register all the missing caches
> before running queries.
> After loading missing caches explicitly the time reduced to 50-60ms in
> client mode.
>
> I've used a trick to avoid declaring all the caches in configuration file
> or calling getOrCreateCache for each of them.
> To give it a try, just add the line below before the queries execution
> logic in your example.
> IgniteStorage.getInstance().getIgniteCache(Quote.class.getName(), 0
> ).unwrap(IgniteCacheProxy.class).context().kernalContext().
> cache().createMissingCaches();
>
> Kind regards,
> Alex.
>
> On Thu, Apr 13, 2017 at 10:08 AM, woo charles [via Apache Ignite Users] 
> <[hidden
> email] > wrote:
>
>> "If you select some data from the joined table it leads to all dynamic
>> cache creation requests being sent" <-- is that mean the client node will
>> copy the selected table to local?
>>
>> If I set false to client mode, it will become server node and
>> start participate in caching, compute execution, stream processing, etc.,
>> Then it will affect the performance of my client program. How can I
>> prevent this?
>>
>> 2017-04-13 14:24 GMT+08:00 afedotov <[hidden email]
>> >:
>>
>>> Hi,
>>>
>>> Sergi, when join query is called from client
>>> It leads to createMissingCaches being called which makes a remote
>>> requests of a dynamic cache creation for each registered but not enabled
>>> cache and since there is a cache for each entity there are many requests to
>>> server nodes.
>>>
>>> Charles,
>>> If you select some data from the joined table it leads to all dynamic
>>> cache creation requests being sent therefore allowing to skip these on the
>>> next query runs.
>>> To disable client mode in your example just pass false to
>>> Ignition.setClientMode(true)
>>>
>>> Kind regards,
>>> Alex
>>>
>>>
>>>
>>> 13 апр. 2017 г. 5:22 AM пользователь "woo charles [via Apache Ignite
>>> Users]" <[hidden email]
>>> > написал:
>>>
>>> I found that this time can be reduced to a value below 100ms if I
>>> already selected some data from join query related table.
>>> For example,
>>> if I run 2 query "select * from Quote where stock_id = xxx" & "Select *
>>> from StockInfo where stock_id = xxx"  first and then run the join query,
>>> the time for 1st join query will become similar to other(around 10 -20
>>> ms).
>>> Why will it happen?
>>>
>>> Also, How to run queries from a server node? I had try
>>> "ignite.compute().run()" but it doesn't work.
>>>
>>>
>>> thanks& best regards,
>>> Charles
>>>
>>> 2017-04-13 0:48 GMT+08:00 Sergi Vladykin <[hidden email]
>>> >:
>>>
 Alex,

 Why do we have such a huge difference between client nodes and server
 nodes? Looks like we should fix it if possible. Even 7 seconds looks too
 much for me.

 Sergi

 2017-04-12 18:11 GMT+03:00 afedotov <[hidden email]
 >:

> Hi Charles,
>
> You are running the query from a client node what implies additional
> network round trips.
> Try to run queries from a server node. In my environment it reduced
> the time from about 7 seconds to 220ms for the first run.
>
> Kind regards,
> Alex.
>
> On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users]
> <[hidden email] >
> wrote:
>
>> *Sorry for wrong calculation *
>> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60
>> table] data)*
>>
>> *Best Regards,*
>> *Charles*
>>
>> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
>> >:
>>
>>> *Source
>>> code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
>>> *
>>>
>>> *Below is a screen cap on GridGain's web console & the log of my
>>> client program. *
>>> *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30
>>> table] data)*
>>> [image: 內置圖片 2]
>>>
>>> Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
>>> SEVERE: Failed to resolve default logging config file:
>>> config/java.util.logging.properties
>>> [09:50:10]   

Re: Slow on 1st time query "SQL Join"

[afedotov]

Charles,

In your case, you have many caches registered on server nodes (debug shows
me about 80) which are to be created on
the client. These caches don't participate in common activities, instead
they are used to prepare execution plan.
As for now, a separate request is sent to remote nodes for each
unregistered cache.
You can use client mode, but you need to register all the missing caches
before running queries.
After loading missing caches explicitly the time reduced to 50-60ms in
client mode.

I've used a trick to avoid declaring all the caches in configuration file
or calling getOrCreateCache for each of them.
To give it a try, just add the line below before the queries execution
logic in your example.
IgniteStorage.getInstance().getIgniteCache(Quote.class.getName(), 0
).unwrap(IgniteCacheProxy.class
).context().kernalContext().cache().createMissingCaches();

Kind regards,
Alex.

On Thu, Apr 13, 2017 at 10:08 AM, woo charles [via Apache Ignite Users] <
ml-node+s70518n11926...@n6.nabble.com> wrote:

> "If you select some data from the joined table it leads to all dynamic
> cache creation requests being sent" <-- is that mean the client node will
> copy the selected table to local?
>
> If I set false to client mode, it will become server node and
> start participate in caching, compute execution, stream processing, etc.,
> Then it will affect the performance of my client program. How can I
> prevent this?
>
> 2017-04-13 14:24 GMT+08:00 afedotov <[hidden email]
> >:
>
>> Hi,
>>
>> Sergi, when join query is called from client
>> It leads to createMissingCaches being called which makes a remote
>> requests of a dynamic cache creation for each registered but not enabled
>> cache and since there is a cache for each entity there are many requests to
>> server nodes.
>>
>> Charles,
>> If you select some data from the joined table it leads to all dynamic
>> cache creation requests being sent therefore allowing to skip these on the
>> next query runs.
>> To disable client mode in your example just pass false to
>> Ignition.setClientMode(true)
>>
>> Kind regards,
>> Alex
>>
>>
>>
>> 13 апр. 2017 г. 5:22 AM пользователь "woo charles [via Apache Ignite
>> Users]" <[hidden email]
>> > написал:
>>
>> I found that this time can be reduced to a value below 100ms if I already
>> selected some data from join query related table.
>> For example,
>> if I run 2 query "select * from Quote where stock_id = xxx" & "Select *
>> from StockInfo where stock_id = xxx"  first and then run the join query,
>> the time for 1st join query will become similar to other(around 10 -20
>> ms).
>> Why will it happen?
>>
>> Also, How to run queries from a server node? I had try
>> "ignite.compute().run()" but it doesn't work.
>>
>>
>> thanks& best regards,
>> Charles
>>
>> 2017-04-13 0:48 GMT+08:00 Sergi Vladykin <[hidden email]
>> >:
>>
>>> Alex,
>>>
>>> Why do we have such a huge difference between client nodes and server
>>> nodes? Looks like we should fix it if possible. Even 7 seconds looks too
>>> much for me.
>>>
>>> Sergi
>>>
>>> 2017-04-12 18:11 GMT+03:00 afedotov <[hidden email]
>>> >:
>>>
 Hi Charles,

 You are running the query from a client node what implies additional
 network round trips.
 Try to run queries from a server node. In my environment it reduced the
 time from about 7 seconds to 220ms for the first run.

 Kind regards,
 Alex.

 On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users]
 <[hidden email] >
 wrote:

> *Sorry for wrong calculation *
> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60
> table] data)*
>
> *Best Regards,*
> *Charles*
>
> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
> >:
>
>> *Source
>> code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
>> *
>>
>> *Below is a screen cap on GridGain's web console & the log of my
>> client program. *
>> *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30
>> table] data)*
>> [image: 內置圖片 2]
>>
>> Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
>> SEVERE: Failed to resolve default logging config file:
>> config/java.util.logging.properties
>> [09:50:10]__  
>> [09:50:10]   /  _/ ___/ |/ /  _/_  __/ __/
>> [09:50:10]  _/ // (7 7// /  / / / _/
>> [09:50:10] /___/\___/_/|_/___/ /_/ /___/
>> [09:50:10]
>> [09:50:10] ver. 1.8.0#20161205-sha1:9ca40dbe
>> [09:50:10] 2016 Copyright(C) Apache Software Foundation
>> [09:50:10]
>> 

Re: Ignite on FreeBSD 11 and OpenJDK

[Andrey Gura]

Kamil,

thanks a lot for your help. As I told before I need some time for
problem analyse. After it I'll create JIRA ticket and share link to it
in this thread.

Thank you again!

On Wed, Apr 12, 2017 at 11:56 PM, Kamil Misuth  wrote:
> Hi Andrey,
>
> I've built ignite-3477-master (commit hash 5839f481b7) today.
> Apart from the fact that some other Configuration APIs changed,
> CacheMemoryMode disapeared. I guess this is related to
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-4758-introducing-cache-memory-policies-td14957.html
>
> Anyway, I've got the following exception on the first try, since
> ignite-indexing 2.0.0 is compiled against H2 1.4.191 and Spring Boot
> 1.5.2.RELEASE managed H2 version is 1.4.193 and apparently org.h2.result.Row
> changed from abstract class to an interface between the two versions.
>
> Caused by: java.lang.IncompatibleClassChangeError: class
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Row has interface
> org.h2.result.Row as super class
>
> After fixing the dependency issue, I've tried to create two node cluster and
> JVM SIGSEGVed in DirectNioClientWorker just as before.
>
> Attaching crash logs from both nodes (running on the same machine FreeBSD
> 11) to this e-mail.
>
> Kamil
>
>
> On 2017-04-12 00:49, Kamil Misuth wrote:
>>
>> Sure thing.
>>
>> I will check out ignite-3477-master as soon as I have some time tomorrow.
>>
>> Kamil
>>
>>
>> On 04/11/2017 05:48 PM, Andrey Gura wrote:
>>>
>>> Thanks for provided information. I need additional time for problem
>>> investigation.
>>>
>>> You can also try code from ignite-3477-master branch. This branch
>>> contains many memory related fixes but it isn't stable yet.
>>>
>>> On Mon, Apr 10, 2017 at 11:37 PM, kimec.ethome.sk 
>>> wrote:

 Hi Andrey,

 sorry, I've got ahead of my self.

 I am on FreeBSD 11.0-RELEASE-p1 amd64
 With OpenJDK Runtime Environment 1.8.0_121-b13 Oracle Corporation
 OpenJDK
 64-Bit Server VM 25.121-b13
 hw.model: Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
 hw.machine_arch: amd64
 hw.ncpu: 8
 hw.physmem: 8251813888

 Core dump is 1 GB, so I guess that is no go. I am attaching crash log to
 this e-mail.
 I have uploaded the project I've used during my testing here
 https://github.com/kimec/ignite-spring-boot .
 The sample works perfectly well with stock ignite-core on Linux OpenJDK
 8
 xs64 CentOS 7 .

 Kamil



 On 2017-04-10 12:24, Andrey Gura wrote:
>
> Hi,
>
> could you please share core dump file? If not, it would be helpful to
> know what is CPU architecture on this server.
>
> On Mon, Apr 10, 2017 at 2:53 AM, Kamil Misuth  wrote:
>>
>> Greetings,
>>
>> OpenJDK (7 and 8) HotSpot JVM SIGSEGVs on FreeBSD 11 as soon as node
>> joins a
>> topology and starts to communicate via DirectNioClientWorker.
>> The root cause is DirectByteBufferStreamImpl (both versions) which
>> uses
>> GridUnsafe.getXXX/putXXX(Object object, offset, value) methods to
>> manipulate
>> DirectByteBuffer, whereas it should really be using
>> GridUnsafe.getXXX/putXXX(address, value), since DirectByteBuffer is
>> allocated on C heap (off java heap).
>> Notice that at least one instance of the same problem is known to
>> exist
>> in
>> another project using Unsafe
>> https://issues.apache.org/jira/browse/CASSANDRA-8325 .
>> The OpenJDK source of Unsafe is more or less clear on this
>>
>>
>> http://hg.openjdk.java.net/jdk8u/jdk8u60/jdk/file/935758609767/src/share/classes/sun/misc/Unsafe.java#l391
>> I have prepared a simple fix here
>>
>>
>> https://github.com/apache/ignite/compare/1.9.0-rc2...kimec:freebsd-support
>>  .
>> However, I am not sure if the solution is right in regard to overall
>> ignite
>> performance.
>> I've tried to compile ignite-core with tests and after applying my
>> changes
>> was able to pass all the basic stuff until the performance test stage
>> at
>> which point my machine run out of RAM and swap space (some 10 GB)...
>> Not
>> sure if this is how the tests are supposed to be. After compiling with
>> -DskipTests I was able to create FreeBSD 11 - CentOS 7 two node
>> cluster
>> and
>> everything seemed OK (the two nodes shared an IGFS instance backed by
>> replicated caches).
>> Please note that OpenJDK on different systems as well as Oracle JDK
>> (via
>> Linux compatility layer) on FreeBSD seem to be more forgiving and does
>> not
>> SIGSEGV.
>> I've based my branch on 1.9.0-rc2 since tag 1.9.0 has already POM with
>> version 2.0.
>>
>> Kamil

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[Tolga HOŞGÖR]

I am trying to create an ACTIVE/PASSIVE redundant environment, passive node
being the vanilla .sh node. I would like to have control on what node is
appointed as primary.

According to what you are saying, for a moment I have to have only one node
(that being C++ node) online for it to be primary node at switchover. I
would like to avoid that because if a crash happens at that time, the data
will be lost.

Is there a tutorial on writing a plugin in ./libs folder that defines a
custom affinity function and configuring it? There is also the matter of
identifying the C++ node.

On Thu, Apr 13, 2017, 12:32 PM vkulichenko 
wrote:

> Hi,
>
> There is no way to do this unless you implement your own affinity function.
> Out of the box you can control whether a particular node can be used as a
> partition backup having primary node for this partition already assigned.
>
> What is the purpose of such deployment? What are you trying to achieve with
> this?
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/How-do-I-provide-AffinityFunction-BackupFilter-when-mainly-using-C-bindings-tp11930p11938.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[vkulichenko]

Hi,

There is no way to do this unless you implement your own affinity function.
Out of the box you can control whether a particular node can be used as a
partition backup having primary node for this partition already assigned.

What is the purpose of such deployment? What are you trying to achieve with
this?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/How-do-I-provide-AffinityFunction-BackupFilter-when-mainly-using-C-bindings-tp11930p11938.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Help with Web agent

[vkulichenko]

Harish,

You need to put JDBC driver for you database into jdbc-drivers folder.

-Val



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

Re: Ignite client deployed on Tomcat is not able to make secure connection with standalone Ignite Server

[vkulichenko]

Hi Ankit,

This configuration is done on Ignite level, there is nothing specific to
Tomcat. Is there any difference between Ignite configurations on different
clients? Are all certificates available, etc.? How does the issue looks
like? Is there an exception?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-deployed-on-Tomcat-is-not-able-to-make-secure-connection-with-standalone-Ignite-Server-tp11928p11936.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Concurrent job execution and FifoQueueCollisionSpi.parallelJobsNumber=1

[vkulichenko]

Hi Ryan,

I will take a look at your sample in the next few days.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Concurrent-job-execution-and-FifoQueueCollisionSpi-parallelJobsNumber-1-tp8697p11935.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Help with Web agent

[Harish Patibandla]

Hi
  I am able to get the agent running but i am getting the below error when
trying to use the web-console.
Domain model could not be imported

   - Agent failed to find JDBC drivers
   - Copy required JDBC drivers into agent 'jdbc-drivers' folder and try
   again


On Thu, Apr 13, 2017 at 1:55 PM, ArcherUnicorn <969959...@qq.com> wrote:

> No, I just add one of server nodes'address of ignite cluster. My
> default.properties is as below:
>
> tokens=uJ5q0ISJUBJq5efvJYyO
> server-uri=https://console.gridgain.com
> #Uncomment following options if needed:
> node-uri=http://192.168.2.201:8080
> #driver-folder=./jdbc-drivers
>
>
>
>
> -- 原始邮件 --
> *发件人:* "woo charles [via Apache Ignite Users]";<[hidden email]
> >;
> *发送时间:* 2017年4月13日(星期四) 下午4:19
> *收件人:* "下奈若"<[hidden email]
> >;
> *主题:* Re: Help with Web agent
>
> Did you update the token in default.properties?
> The Security token in your new setup web console should be different from
> GridGain web console one.
>
> 2017-04-13 16:13 GMT+08:00 ArcherUnicorn <[hidden email]
> >:
>
>> My "URI to Ignite node REST server:" is "https://console.gridgain.com; ,
>> and
>> I can see my Ignite cluster status from web.
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Help-with-Web-agent-tp11924p11929.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Help-with-
> Web-agent-tp11924p11931.html
> To unsubscribe from Help with Web agent, click here.
> NAML
> 
>
> --
> View this message in context: 回复： Help with Web agent
> 
>
> Sent from the Apache Ignite Users mailing list archive
>  at Nabble.com.
>

Re: Ignite Affinity & Binary Configuration Issues

[dkarachentsev]

Hi Addo,

There is no need to explicitly specify IdentityResolver. On marshaling step,
hash code is got from object and recorded in BinaryObject, and it will be
used for any affinity mapping, e.g. affinity run. Use IdentityResolver if
you need customize hash code calculation, f.e. exclude some fields or in
case of using BinaryObjectBuilder. So you may remove custom
BinaryConfiguration.

Ignite tries to avoid redundant serialization/deserialization, and for
proper work there is no need to do it. According to this rule Ignite passes
BinaryObject in AffinityKeyMapper. You don't need to deserialize the whole
object, it's enough to read just required field: 

if (CacheKeyOne.class.getName().equals(bo.type().typeName()))
return bo.field("key");

You should avoid using other marshalers, because BinaryMarshaller is highly
optimized for use in Ignite.

-Dmitry.




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

回复： Help with Web agent

[ArcherUnicorn]

No, I just add one of server nodes'address of ignite cluster. My 
default.properties is as below:

tokens=uJ5q0ISJUBJq5efvJYyO
server-uri=https://console.gridgain.com
#Uncomment following options if needed:
node-uri=http://192.168.2.201:8080
#driver-folder=./jdbc-drivers








-- 原始邮件 --
发件人: "woo charles [via Apache Ignite 
Users]";;
发送时间: 2017年4月13日(星期四) 下午4:19
收件人: "下奈若"<969959...@qq.com>; 

主题: Re: Help with Web agent



Did you update the token in default.properties?The Security token in 
your new setup web console should be different from GridGain web console one.


2017-04-13 16:13 GMT+08:00 ArcherUnicorn <[hidden email]>:
My "URI to Ignite node REST server:" is "https://console.gridgain.com; , and
 I can see my Ignite cluster status from web.
 
 
 
 --
 View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Help-with-Web-agent-tp11924p11929.html
 Sent from the Apache Ignite Users mailing list archive at Nabble.com.
 





If you reply to this email, your message will be added 
to the discussion below:

http://apache-ignite-users.70518.x6.nabble.com/Help-with-Web-agent-tp11924p11931.html
   
To unsubscribe from Help with Web 
agent, click here.
NAML



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

Re: Help with Web agent

[woo charles]

Did you update the token in default.properties?
The Security token in your new setup web console should be different from
GridGain web console one.

2017-04-13 16:13 GMT+08:00 ArcherUnicorn <969959...@qq.com>:

> My "URI to Ignite node REST server:" is "https://console.gridgain.com; ,
> and
> I can see my Ignite cluster status from web.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Help-with-Web-agent-tp11924p11929.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

How do I provide AffinityFunction.BackupFilter when mainly using C++ bindings

[Tolga HOŞGÖR]

Hello,

I am in a similar situation with the following unanswered SO question:
http://stackoverflow.com/questions/43386765/how-do-i-provide-affinityfunction-backupfilter-when-mainly-using-c-bindings

How can I achieve this? Quoting the question:

I am using the C++ bindings to have redundancy in my application. Alongside
the main C++ node, I am running a vanilla Java node via ignite.sh as a
backup on another node. I would like appoint this vanilla Java node to
always stay a *backup* node and never a primary node as long as there is a
C++ node running. Also, I need the C++ nodes to always stay as primary
nodes. A little data loss is acceptable with the PRIMARY_SYNC
synchronization.

My research led me to AffinityFunction.BackupFilter property to filter C++
nodes as primary. It seems that there is also some functions to give
*attributes* to nodes. So I guess I can set a specific attribute on C++
nodes and filter them to always stay as primary nodes.

However, C++ bindings apparently neither provide a way to set backup filter
nor allow setting attributes on the launched node. I have noticed some
modules get plugged through ignite-dir/libs but there is no tutorial about
that approach to add AffinityFunction. How can I achieve what I need? I
need to plug a custom affinity function while using C++ as the main and a
way to distinguish the C++ nodes.

Re: Help with Web agent

[ArcherUnicorn]

My "URI to Ignite node REST server:" is "https://console.gridgain.com; , and
I can see my Ignite cluster status from web.



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

Ignite client deployed on Tomcat is not able to make secure connection with standalone Ignite Server

[Ankit Singhai]

Hi All,
In my environment I have Ignite Server(s) running as Standalone program(s)
configured to use SSL. 
My standalone programs are able to connect securely to Server's. However one
of my client which is deployed is not able to connect to server.

What additional changes I have to do in Tomcat config files to enable TLS
between this client and server?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-deployed-on-Tomcat-is-not-able-to-make-secure-connection-with-standalone-Ignite-Server-tp11928.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Help with Web agent

[woo charles]

For my testing web console, its console server is pointed to 9000 port not
3000 port.

2017-04-13 13:42 GMT+08:00 Harish Patibandla :

> Hi Everyone,
>I am unable to run web agent on the server , web console is up and
> running but was unable to get the agent running .I am getting below error
> [05:38:44,159][INFO ][main][AgentLauncher] Starting Apache Ignite Web
> Console Agent...
> [05:38:44,309][WARN ][main][AgentLauncher] Failed to find agent property
> file: default.properties
>
> Agent configuration:
> URI to Ignite node REST server: http://localhost:8080
> URI to Ignite Console server  : http://localhost:3000
> Path to agent property file   : default.properties
> Path to JDBC drivers folder   : /home/hpatiba/apache-ignite-1.
> 9.0-src/modules/web-console/web-agent/target/ignite-web-
> agent-1.9.0/jdbc-drivers
>
> Security token is required to establish connection to the web console.
> It is available on the Profile page: https://localhost/profile
> Enter security tokens separated by comma:
> [05:38:49,733][INFO ][EventThread][AgentLauncher] Connecting to:
> http://localhost:3000
> [05:38:49,820][INFO ][EventThread][AgentLauncher] Connection established.
> [05:38:49,855][ERROR][EventThread][AgentLauncher] Connection closed:
> Agent is failed to authenticate. Please check agent's token(s).
>
> Regards
> Harish
>

Re: Slow on 1st time query "SQL Join"

[woo charles]

"If you select some data from the joined table it leads to all dynamic
cache creation requests being sent" <-- is that mean the client node will
copy the selected table to local?

If I set false to client mode, it will become server node and
start participate in caching, compute execution, stream processing, etc.,
Then it will affect the performance of my client program. How can I prevent
this?

2017-04-13 14:24 GMT+08:00 afedotov :

> Hi,
>
> Sergi, when join query is called from client
> It leads to createMissingCaches being called which makes a remote requests
> of a dynamic cache creation for each registered but not enabled cache and
> since there is a cache for each entity there are many requests to server
> nodes.
>
> Charles,
> If you select some data from the joined table it leads to all dynamic
> cache creation requests being sent therefore allowing to skip these on the
> next query runs.
> To disable client mode in your example just pass false to
> Ignition.setClientMode(true)
>
> Kind regards,
> Alex
>
>
>
> 13 апр. 2017 г. 5:22 AM пользователь "woo charles [via Apache Ignite
> Users]" <[hidden email]
> > написал:
>
> I found that this time can be reduced to a value below 100ms if I already
> selected some data from join query related table.
> For example,
> if I run 2 query "select * from Quote where stock_id = xxx" & "Select *
> from StockInfo where stock_id = xxx"  first and then run the join query,
> the time for 1st join query will become similar to other(around 10 -20 ms).
> Why will it happen?
>
> Also, How to run queries from a server node? I had try
> "ignite.compute().run()" but it doesn't work.
>
>
> thanks& best regards,
> Charles
>
> 2017-04-13 0:48 GMT+08:00 Sergi Vladykin <[hidden email]
> >:
>
>> Alex,
>>
>> Why do we have such a huge difference between client nodes and server
>> nodes? Looks like we should fix it if possible. Even 7 seconds looks too
>> much for me.
>>
>> Sergi
>>
>> 2017-04-12 18:11 GMT+03:00 afedotov <[hidden email]
>> >:
>>
>>> Hi Charles,
>>>
>>> You are running the query from a client node what implies additional
>>> network round trips.
>>> Try to run queries from a server node. In my environment it reduced the
>>> time from about 7 seconds to 220ms for the first run.
>>>
>>> Kind regards,
>>> Alex.
>>>
>>> On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users] 
>>> <[hidden
>>> email] > wrote:
>>>
 *Sorry for wrong calculation *
 *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60
 table] data)*

 *Best Regards,*
 *Charles*

 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
 >:

> *Source
> code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
> *
>
> *Below is a screen cap on GridGain's web console & the log of my
> client program. *
> *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30 table]
> data)*
> [image: 內置圖片 2]
>
> Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> [09:50:10]__  
> [09:50:10]   /  _/ ___/ |/ /  _/_  __/ __/
> [09:50:10]  _/ // (7 7// /  / / / _/
> [09:50:10] /___/\___/_/|_/___/ /_/ /___/
> [09:50:10]
> [09:50:10] ver. 1.8.0#20161205-sha1:9ca40dbe
> [09:50:10] 2016 Copyright(C) Apache Software Foundation
> [09:50:10]
> [09:50:10] Ignite documentation: http://ignite.apache.org
> [09:50:10]
> [09:50:10] Quiet mode.
> [09:50:10]   ^-- To see **FULL** console log here add
> -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat}
> [09:50:10]
> [09:50:10] OS: Linux 3.10.0-123.el7.x86_64 amd64
> [09:50:10] VM information: Java(TM) SE Runtime Environment
> 1.8.0_121-b13 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM
> 25.121-b13
> [09:50:10] Initial heap size is 128MB (should be no less than 512MB,
> use -Xms512m -Xmx512m).
> [09:50:10] Configured plugins:
> [09:50:10]   ^-- None
> [09:50:10]
> [09:50:10] Security status [authentication=off, tls/ssl=off]
> [09:50:11] To start Console Management & Monitoring run
> ignitevisorcmd.{sh|bat}
> [09:50:11]
> [09:50:11] Ignite node started OK (id=b663472c)
> [09:50:11] Topology snapshot [ver=19, servers=3, clients=1, CPUs=8,
> heap=3.1GB]
> PreLoadDataSize = 1
> NumOfTest = 2
> /--- Test 0 ---\
> Name = SQL_Select_2_Join_10
> ActionType = SQL_SELECT_2_JOIN
> Object class = 

Re: Slow on 1st time query "SQL Join"

[afedotov]

Hi,

Sergi, when join query is called from client
It leads to createMissingCaches being called which makes a remote requests
of a dynamic cache creation for each registered but not enabled cache and
since there is a cache for each entity there are many requests to server
nodes.

Charles,
If you select some data from the joined table it leads to all dynamic cache
creation requests being sent therefore allowing to skip these on the next
query runs.
To disable client mode in your example just pass false to
Ignition.setClientMode(true)

Kind regards,
Alex



13 апр. 2017 г. 5:22 AM пользователь "woo charles [via Apache Ignite
Users]"  написал:

I found that this time can be reduced to a value below 100ms if I already
selected some data from join query related table.
For example,
if I run 2 query "select * from Quote where stock_id = xxx" & "Select *
from StockInfo where stock_id = xxx"  first and then run the join query,
the time for 1st join query will become similar to other(around 10 -20 ms).
Why will it happen?

Also, How to run queries from a server node? I had try
"ignite.compute().run()" but it doesn't work.


thanks& best regards,
Charles

2017-04-13 0:48 GMT+08:00 Sergi Vladykin <[hidden email]
>:

> Alex,
>
> Why do we have such a huge difference between client nodes and server
> nodes? Looks like we should fix it if possible. Even 7 seconds looks too
> much for me.
>
> Sergi
>
> 2017-04-12 18:11 GMT+03:00 afedotov <[hidden email]
> >:
>
>> Hi Charles,
>>
>> You are running the query from a client node what implies additional
>> network round trips.
>> Try to run queries from a server node. In my environment it reduced the
>> time from about 7 seconds to 220ms for the first run.
>>
>> Kind regards,
>> Alex.
>>
>> On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users] 
>> <[hidden
>> email] > wrote:
>>
>>> *Sorry for wrong calculation *
>>> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60
>>> table] data)*
>>>
>>> *Best Regards,*
>>> *Charles*
>>>
>>> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
>>> >:
>>>
 *Source
 code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
 *

 *Below is a screen cap on GridGain's web console & the log of my client
 program. *
 *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30 table]
 data)*
 [image: 內置圖片 2]

 Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
 SEVERE: Failed to resolve default logging config file:
 config/java.util.logging.properties
 [09:50:10]__  
 [09:50:10]   /  _/ ___/ |/ /  _/_  __/ __/
 [09:50:10]  _/ // (7 7// /  / / / _/
 [09:50:10] /___/\___/_/|_/___/ /_/ /___/
 [09:50:10]
 [09:50:10] ver. 1.8.0#20161205-sha1:9ca40dbe
 [09:50:10] 2016 Copyright(C) Apache Software Foundation
 [09:50:10]
 [09:50:10] Ignite documentation: http://ignite.apache.org
 [09:50:10]
 [09:50:10] Quiet mode.
 [09:50:10]   ^-- To see **FULL** console log here add
 -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat}
 [09:50:10]
 [09:50:10] OS: Linux 3.10.0-123.el7.x86_64 amd64
 [09:50:10] VM information: Java(TM) SE Runtime Environment
 1.8.0_121-b13 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM
 25.121-b13
 [09:50:10] Initial heap size is 128MB (should be no less than 512MB,
 use -Xms512m -Xmx512m).
 [09:50:10] Configured plugins:
 [09:50:10]   ^-- None
 [09:50:10]
 [09:50:10] Security status [authentication=off, tls/ssl=off]
 [09:50:11] To start Console Management & Monitoring run
 ignitevisorcmd.{sh|bat}
 [09:50:11]
 [09:50:11] Ignite node started OK (id=b663472c)
 [09:50:11] Topology snapshot [ver=19, servers=3, clients=1, CPUs=8,
 heap=3.1GB]
 PreLoadDataSize = 1
 NumOfTest = 2
 /--- Test 0 ---\
 Name = SQL_Select_2_Join_10
 ActionType = SQL_SELECT_2_JOIN
 Object class = com.performance.test.dao.Quote
 Thread Size = 80
 [09:50:20] New version is available at ignite.apache.org: 1.9.0
 MaxTime(First Time): 12710
 Thread [SQL_Select_2_Join_10] Average Time: 18.913ms - 0.018913s, Max
 Time: 183ms
 \-/
 /--- Test 1 ---\
 Name = QUERY_Quote_price_large_1000_Small_950
 ActionType = QUERY
 Object class = com.performance.test.dao.Quote
 Thread Size = 80
 MaxTime(First Time): 30
 Thread [QUERY_Quote_price_large_1000_Small_950] Average Time:
 118.752ms - 0.118752s, Max Time: 1094ms