Re: Cluster can not let more than one client to do continuous queries

[ght230]

I think perhaps our test produres are Inconsistent.

My test produre as following:

Test RemoteFilterFactory without parameter.
1. In host 192.168.137.6, run ignite.sh -i(choose the example-cache.xml)
2. In host 192.168.137.31, run jar -cp continueclient.jar
com.test.CacheContinuousAsyncQueryClient21, query running normally.
3. In host 192.168.137.32, run jar -cp continueclient.jar
com.test.CacheContinuousAsyncQueryClient22, query running normally.

Test RemoteFilterFactory with a parameter.
1. In host 192.168.137.6, run ignite.sh -i(choose the example-cache.xml)
2. In host 192.168.137.31, run jar -cp continueclient.jar
com.test.CacheContinuousAsyncQueryClient11, query running normally.
3. In host 192.168.137.32, run jar -cp continueclient.jar
com.test.CacheContinuousAsyncQueryClient12, query can not be started.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Cluster-can-not-let-more-than-one-client-to-do-continuous-queries-tp9124p9188.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cassandra basic setup

[Riccardo Iacomini]

Hi Igor,
thanks for your reply. I've both tried building ignite from source and
removing CassandraAdminCredentials class specifying username and password
in the bean's properties. Anyway, I cannot get it work. Ignite still cannot
find the required classes, this time
*org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource.
*The class is indeed located in the jar ignite-cassandra-1.7.0.jar in
IGNITE_HOME/modules/cassandra/target. I tried adding the path to USER_LIBS
and CLASSPATH, no different behavior. Maybe the environment variables got
ignored?


Riccardo Iacomini


*RDSLab*

On Wed, Nov 23, 2016 at 7:41 PM, Igor Rudyak  wrote:

> Hi Riccardo,
>
> *CassandraAdminCredentials *class is only available in Ignite unit tests
> sources. If you want to use it you should build Ignite from source code.
> Such way, it will create *ignite-cassandra-tests-${project.version}.zip*
> where jar may find jar file containing all the test classes.
>
> Also if you want to use Cassandra as a persistent store you actually don't
> need *CassandraAdminCredentials  *cause it's just used for tests.
>
> Igor
>
> On Wed, Nov 23, 2016 at 7:33 AM, Riccardo Iacomini <
> riccardo.iacom...@rdslab.com> wrote:
>
>> Following the example 
>> provided in the docs, I am trying to setup a basic Ignite cluster using
>> Cassandra as persistent store. I've downloaded ignite 1.7 and created the
>> configuration files. Ignite does read them at startup, but I get this error
>> message:
>>
>> *class org.apache.ignite.IgniteException: Failed to instantiate Spring
>> XML application context (make sure all classes used in Spring configuration
>> are present at CLASSPATH*
>>
>> CassandraAdminCredentials is the class not being found. Commenting the
>> bean, I get the same for the next class. I tried adding the path to the jar 
>> *ignite-cassandra-1.7.0.jar
>> *to both CLASSPATH and USER_LIBS, still not getting found. Opening the
>> jar I cannot find the requested class. Am I missing some dependencies?
>>
>> Thank you for your help.
>>
>> Riccardo Iacomini
>>
>>
>> *RDSLab*
>>
>
>

Re: Cache Memory Behavior \ GridDhtLocalPartition

[dkarachentsev]

Hi,

Yes, you're right, this is a cache that holds data for distributed
datastructures, and IgniteQueue as well. Is it possible that you add items
to queue faster than poll?

TxCommittedVersionsSize and TxRolledbackVersionsSize are common for all
caches and just store versions of finished transactions, so if you have
transactional cache you'll find that values greater than zero if there was
made transactions. Don't worry about size, it's number finite (default is
262144) and takes small amount of memory.



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

Re: Failed to running hadoop accelerator

[Kaiming Wan]

I solved the problem by myself.

Is it ignite's bug? Though I have set the following variable in .bashrc,
ignite still can't get the related hadoop jar.


*export IGNITE_LIBS=$IGNITE_LIBS:"$IGNITE_HOME/libs/*":$HADOOP_CLASSPATH*


Now I have solved this problem by copying related hadoop jars mannually:

cp $HADOOP_HOME/share/hadoop/common/hadoop-common-2.7.2.jar
$IGNITE_HOME/libs
cp $HADOOP_HOME/share/hadoop/common/lib/commons*  $IGNITE_HOME/libs
cp $HADOOP_HOME/share/hadoop/common/lib/guava-11.0.2.jar  $IGNITE_HOME/libs
cp
$HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-client-core-2.7.2.jar
$IGNITE_HOME/libs




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failed-to-running-hadoop-accelerator-tp9174p9184.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Throwing and catching user exceptions in Ignite Services

[BenVee]

Done, any idea when this bug might be resolved? It's kind of a deal breaker
for our microservice architecture.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Throwing-and-catching-user-exceptions-in-Ignite-Services-tp9143p9183.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cluster can not let more than one client to do continuous queries

[dkarachentsev]

Hi,

Thanks for the reproducer, but it works for both tests. I think your issue
entails in too large timeouts, for example, you set 5 min timeout for join,
so it may take too long to connect. Is there any reason for such decision?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Cluster-can-not-let-more-than-one-client-to-do-continuous-queries-tp9124p9182.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite user architecture question - Node Roles

[russ]

Hi, I'm new to Ignite and I'm looking for some basic getting started advice
for an architecture on the scenario below. 

My use case is; I want to load data from 3 SQL Server databases into an
Ignite data grid and be able to do distributed SQL queries across the 3 sets
of data from client apps. Also I want to implement write-through updates on
the data so any client cache will get updated when the database does.

Question: How should I architect this? Would you create 4 "Worker Nodes"
containing zero custom code (say you wanted the grid to have 4 nodes) and
then create 3 "Loader Nodes", one for each database to load the data into
caches? My problem with this approach is what if a ''Loader Node" fails -
when i have the write-through updates working there will be no redundancy
having a single node for a given source of data.

Or would you put the data loading code into each of the nodes so all nodes
can load the data. But I'm thinking in this case all nodes would load the
data on start-up which is unnecessary in a standard start-up scenario. 

If you could advice on a node setup architecture for this that would be
great.

Thanks, Russ







--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-user-architecture-question-Node-Roles-tp9181.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

How is the book "High Performance in-memory computing with Apache Ignite"

[胡永亮/Bob]

The book is in the web site: https://leanpub.com/ignite



Bob


---
Confidentiality Notice: The information contained in this e-mail and any 
accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential 
and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of 
this communication is
not the intended recipient, unauthorized use, forwarding, printing,  storing, 
disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this 
communication in error,please
immediately notify the sender by return e-mail, and delete the original message 
and all copies from
your system. Thank you.
---