Exception in calculating cache size

[naresh.goty]

Hi All,

We are seeing an issue with calculating size of few caches in our
application, only when there 
are more than one server node is started at the same time.  
As part of startup routine, we have a custom load routine to load data to
cache, and once load is successfully complete, then cache size is
calculated. 

Below is the error observed in the log when the size() method is invoked:

{"eventTime" : "Oct 20 2017 10:50:25.698 AM PDT", "thread" :
"CacheExecutor-3", "level" : "ERROR", "class" : "com.service.CacheManager",
"method" : "lambda$doLoad$146", "message" : ""} 
java.lang.ClassCastException: org.apache.ignite.lang.IgniteBiTuple cannot be
cast to java.lang.Integer
at
java.util.stream.ReferencePipeline$4$1.accept(ReferencePipeline.java:210)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.IntPipeline.reduce(IntPipeline.java:456)
at java.util.stream.IntPipeline.sum(IntPipeline.java:414)
at com.cache.RangeCache.size(RangeCache.java:369)



public int size() {

return((IgniteCache)cache)
  .query(new ScanQuery(), 
(entry) ->
((CompositeEntity)entry.getValue()).size())
  .getAll()
  .stream()
  .mapToInt(Integer::intValue)
  .sum();
  
}
Note: Entity is a custom interface for cache entities, and 
CompositeEntity
implements Entity.

Please let us know if there if you find any issue with above method of
calculating cache size.



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

Renentrant Lock & deadlock

[rajivgandhi]

Hi,
In line with a deadlock reported  earlier
  , please see below
another deadlock scenario, this time with renetrant locks:
private void start2() {
Ignite ignite = null; 
try{
ignite = Ignition.start("ignite-deadlock.xml"); 
IgniteCache cache1 =
ignite.getOrCreateCache(getConfig("cache1"));   
IgniteCache cache2 =
ignite.getOrCreateCache(getConfig("cache2"));
//  ignite.l
CountDownLatch latch1 = new CountDownLatch(1);
CountDownLatch latch2 = new CountDownLatch(1);
Thread t = new Thread(() -> {
Lock lock = cache2.lock("fake");
try
{ lock.lock(); System.out.println("Locked"); latch1.countDown();
latch2.await(); cache1.clear(); }
catch(InterruptedException e)
{ Thread.currentThread().interrupt(); e.printStackTrace(); throw new
RuntimeException(e); }
catch(Exception e)
{   e.printStackTrace(); throw new RuntimeException(e); }
finally
{ lock.unlock(); }

});
t.start();
latch1.await(); 
ignite.reentrantLock("blah", true, true, true);
latch2.countDown(); 
t.join();
System.out.println("No deadlock");
}catch(InterruptedException e)
{ Thread.currentThread().interrupt(); e.printStackTrace(); throw new
RuntimeException(e); }
finally
{ if(ignite!=null) ignite.close(); }

}


If you could please triage and accept this as a defect.





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

JDBC Thin Client with Transactions

[iostream]

Hi,

Is it possible to perform Transactional SQL INSERT, UPDATE, DELETE
statements with IgniteJdbcThinDriver?



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

Re: Ignite Events Remote Filter

[Valentin Kulichenko]

Alexey,

Yes, seems to be the case. Unsubscription happens if *local listener*
returns false not remote filter.

-Val

On Fri, Oct 27, 2017 at 3:12 AM, Alexey Kukushkin  wrote:

> Also, I ran our CacheEventsExample and I confirm the remote filter is NOT
> unsubscribed when it returns false. So it looks like a documentation bug
> only.
>
> On Fri, Oct 27, 2017 at 1:10 PM, Alexey Kukushkin <
> kukushkinale...@gmail.com> wrote:
>
>> Hi,
>>
>> I think it is a documentation bug. I do not think remote listener will be
>> unsubscribed if it returns false. Let's confirm with the developers
>> community.
>>
>> *Ignite Developers*,
>>
>> We have this comment for the remoteListener argument of the
>> IgniteEvents#remoteListen(...):
>>
>> rmtFilter - Filter callback that is called on remote node. Only events
>> that pass the remote filter will be sent to local node. If null, all events
>> of specified types will be sent to local node. This remote filter can be
>> used to pre-handle events remotely, before they are passed in to local
>> callback. *It will be auto-unsubsribed on the node where event occurred
>> in case if it returns false*.
>>
>> The documentation in bold looks like a bug to me. Why we would do it that
>> way? To get only the first event? I think the idea is to listen until
>> either master node leaves or you call remoteUnsubscribe(). I feel we just
>> need to remove that sentence from the comments. Could you please confirm?
>>
>>
>> On Fri, Oct 27, 2017 at 4:25 AM, rajivgandhi 
>> wrote:
>>
>>> Hi,
>>> We wish to listen to remote events with a remote filter and local
>>> listener:
>>> https://apacheignite.readme.io/docs/events#section-remote-events
>>>
>>> Our requirement is to entertain only those events on local listener which
>>> are allowed by remote filter. This is the API we are trying to use:
>>> https://ignite.apache.org/releases/latest/javadoc/org/apache
>>> /ignite/IgniteEvents.html#remoteListen(org.apache.ignite.
>>> lang.IgniteBiPredicate,%20org.apache.ignite.lang.IgnitePredi
>>> cate,%20int...)
>>>
>>> As per this API:
>>> "rmtFilter - Filter callback that is called on remote node. Only events
>>> that
>>> pass the remote filter will be sent to local node. If null, all events of
>>> specified types will be sent to local node. This remote filter can be
>>> used
>>> to pre-handle events remotely, before they are passed in to local
>>> callback.
>>> *It will be auto-unsubsribed on the node where event occurred in case if
>>> it
>>> returns false.*"
>>>
>>> As per the bolded part, it seems the remote listener will be
>>> unsubscribed as
>>> soon as the remote filter returns false. Is that right? We want to be
>>> able
>>> to continue listening even after the remote filter has once
>>> filtered/blocked
>>> the event on remote nodes. If that is indeed the case (remote filter
>>> stops
>>> listening), are there any other work arounds?
>>>
>>> thanks!
>>> Rajeev Gandhi
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>
>>
>>
>>
>> --
>> Best regards,
>> Alexey
>>
>
>
>
> --
> Best regards,
> Alexey
>

Re: Query performance against table with/out backup

[blackfield]

@Andrew Mashenkov, I notice that you opened IGNITE-6781. 
However, I actually destroyed the original cache with backup == 1, recreate
a new cache with backup ==2 and repopulate the table.



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

Re: Retrieving keys very slow from a partitioned, no backup, no replicated cache

[Anand Vijai]

Thank you Alexei!

I have configured my cache with the following properties:
ccfg.setReadThrough(true);
ccfg.setWriteThrough(true);
ccfg.setWriteBehindEnabled(true);
ccfg.setWriteBehindBatchSize(1);
ccfg.setStoreKeepBinary(true);

Even though the batch size is defined as 1, I can see that the updates
are trickled to the DB as soon as the entry.setValue is called.
My update throughput is around 100-200 records/sec. 
Any pointers on this.



Regards,
Anand Vijai



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

Re: cache closed or destroyed issue

[Andrey Mashenkov]

Hi,

Seems, you start ignite in some bean that has dies by some reason and your
cache proxy become obsolete.
Can you share logs?

On Fri, Oct 27, 2017 at 3:03 AM, Pradeep Badiger 
wrote:

> Hi,
>
>
>
> We are facing an issue with Ignite cache where it throws an
> IllegalArgumentException with Cache closed or destroyed.
>
>
>
> I have two java applications that start the ignite cache in an embedded
> mode. The cache instances form a cache cluster with the help of zookeeper
> plugin for discovery.
>
>
>
> The cache is partitioned. I don’t think there is any memory related issues
> within two applications.
>
>
>
> I have few entries in the cache. But after sometime, if I try to get an
> entry from the cache in the application, I get an exception with cache
> closed or destroyed.
>
>
>
> I am not sure what would cause this issue.
>
>
>
> I found this issue in jira. I am not sure if this is applicable for 1.7.0.
>
>
>
> https://issues.apache.org/jira/browse/IGNITE-2766
>
>
>
> Can someone help me with this?
>
>
>
> Thanks,
>
> Pradeep V.B.
> This email and any files transmitted with it are confidential, proprietary
> and intended solely for the individual or entity to whom they are
> addressed. If you have received this email in error please delete it
> immediately.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Ignite Events Remote Filter

[rajivgandhi]

Thank you Guys!



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

Re: Ignite/Cassandra failing to use supplied value for where clause

[Kenan Dalley]

So can someone try to take my example and actually get it to work?  It's
baffling to me why this fails as it does.



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

Re: Query performance against table with/out backup

[Vladimir Ozerov]

Hi,

We know one serious source of slowdown when backups are enabled. See [1]
and [2]. It will be fixed in 2.4.

Vladimir.

[1] https://issues.apache.org/jira/browse/IGNITE-6624
[2] https://issues.apache.org/jira/browse/IGNITE-6626

On Thu, Oct 19, 2017 at 9:29 PM, blackfield 
wrote:

> Here, I am trying to ascertain that I set backup == 2 properly as I
> mentioned
> above that I do not see query performance difference between backup ==1 and
> backup == 2.
>
> I want to make sure that I configure my cache properly.
>
> When I set the backup==2 (to have three copies), I notice the following via
> visor.
>
> The Affinity Backups is still equal to 1. Is this a different property than
> number of backups? If it is not, how do one see the number of backups a
> cache is configured for?
>
> Invoking "cache -a" to see the detail cache stat, with backup==2, under the
> size column, the sum of entries on all nodes is equal to the number of rows
> in the table * 2.  It appears this is the case for backup >= 1?
>
> As in, only one set of backup will be stored in off heap regardless the
> number of backups are specified?
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: ComputeGrid API in C++

[asingh]

Ok, so, i first need to wrap ignite within an application that will register
my user functions and start ignite.
I launch that application on every machine that I have.
Then, I can launch another calling application that will call RunASync() and
dispatch tasks to each ignite node and collect their responses.

Is that how it should be?



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

Re: Ignite 2.3 - replicated cache lost data after restart cluster nodes with persistence enabled

[Dmitry Pavlov]

Hi Denis,

I had short chat with Alex G.

 You're right, It may be a bug. I'll prepare my reproducer and add is as
test. Also I will raise the ticket if count(*) will give incorrect result.

Sincerely,
Dmitry Pavlov

пт, 27 окт. 2017 г., 1:48 Denis Magda :

> Dmitriy,
>
> I don’t see why a result of a simple query such as “select count(*) from
> t;” should be different if a rebalancing is in progress or after a cluster
> restart. Ignite’s SQL engine claims that its fault-tolerant and returns a
> consistent result set all the times unless a partition loss happened. Here
> is we don’t have a partition loss, thus, seems we caught a bug.
>
> Vladimir O., please chime in.
>
> —
> Denis
>
> On Oct 26, 2017, at 3:34 PM, Dmitry Pavlov  wrote:
>
> Hi Denis
>
> It seems to me that this is not a bug for my scenario, because the data
> was not loaded within the same transaction using transactional cache. In
> this case it is ok that cache data is rebalanced according to partition
> update counters,isn't it?
>
> I suppose in this case the data was not lost ,it was just not completely
> transferred to the second node.
>
> Sincerely,
>
> чт, 26 окт. 2017 г., 21:09 Denis Magda :
>
>> + dev list
>>
>> This scenario has to be handled automatically by Ignite. Seems like a
>> bug. Please refer to the initial description of the issue. Alex G, please
>> have a look:
>>
>> To reproduce:
>> 1. create a replicated cache with multiple indexedtypes, with some indexes
>> 2. Start first server node
>> 3. Insert data into cache (100 entries)
>> 4. Start second server node
>>
>> At this point, seems all is ok, data is apparently successfully rebalanced
>> making sql queries (count(*))
>>
>> 5. Stop server nodes
>> 6. Restart server nodes
>> 7. Doing sql queries (count(*)) returns less data
>>
>> —
>> Denis
>>
>> > On Oct 23, 2017, at 5:11 AM, Dmitry Pavlov 
>> wrote:
>> >
>> > Hi,
>> >
>> > I tried to write the same code that will execute the described
>> scenario. The results are as follows:
>> > If I do not give enough time to completely rebalance partitions, then
>> the newly launched node will not have enough data to count(*).
>> > If I do not wait for enough time to allow to distribute the data on the
>> grid, the query will return a smaller number - the number of records that
>> have been uploaded to the node. I guess there is
>> GridDhtPartitionDemandMessage’s can be found in Ignite debug log in this
>> moment.
>> >
>> > If I wait for a sufficient amount of time or directly call the wait on
>> the newly joined node
>> > ignite2.cache (CACHE) .rebalance (). get ();
>> > then all results will be correct.
>> >
>> > About your question>  what's happen if one cluster node crashes in the
>> middle of rebalance process?
>> > In this case normal failover scenario is started, data is rebalanced
>> within cluster. And if there is enought WAL records on nodes representing
>> history from crash point, then only recent changes (delta) will be send
>> over network. If there is no enought history to apply rebalance with most
>> recent changes, then partition will be rebalanced from scratch to new node.
>> >
>> > Sincerely,
>> > Pavlov Dmitry
>> >
>> >
>> > сб, 21 окт. 2017 г. в 2:07, Manu > maxn...@hotmail.com>>:
>> > Hi,
>> >
>> > after restart data seems not be consistent.
>> >
>> > We have been waiting until rebalance was fully completed to restart the
>> > cluster to check if durable memory data rebalance works correctly and
>> sql
>> > queries still work.
>> > Another question (it´s not this case), what's happen if one cluster node
>> > crashes in the middle of rebalance process?
>> >
>> > Thanks!
>> >
>> >
>> >
>> > --
>> > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ <
>> http://apache-ignite-users.70518.x6.nabble.com/>
>
>
>

Re: when client node connect to server node, server node throws NotSerializableException

[Andrey Mashenkov]

Hi Jeff,


Looks weird.
Can you share a StoreFactory code and cache config?
Is factory stateless? Or may be there is smth else not stateless in cache
configuration that is missed in log?

On Fri, Oct 27, 2017 at 10:50 AM, Jeff Jiao 
wrote:

> hi guys,
>
> can anyone give some advice...
> what can you see from this exception server side log when client connect to
> it:
> Caused by: java.io.NotSerializableException:
> org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl
>
> why it says IgniteBinaryImpl is not serializable?
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Incorrect map query built when joining with a subquery with group by statement

[Andrey Mashenkov]

Hi Alin,

Ignite have no support for non-collocated subqueries [1] [2], here is a
ticket [3].
Try to set collocated flag to true [4] to hint Ignite your query is
collocated.


[1]
http://apache-ignite-users.70518.x6.nabble.com/Does-Ignite-support-nested-SQL-Queries-td1714.html
[2]
http://apache-ignite-users.70518.x6.nabble.com/SQL-query-result-variation-td2889.html
[3] https://issues.apache.org/jira/browse/IGNITE-5359
[4] https://apacheignite.readme.io/docs/jdbc-driver

On Fri, Oct 27, 2017 at 3:32 PM, alin-corodescu 
wrote:

> Hello,
>
> While experimenting around with Ignite, I came across a bug regarding the
> map query building. (the queries that run on each individual node).
> Consider
> the following dummy query (this is a reproduction of the error I found
> while
> testing actual production queries):
>
> SELECT t1.name, count(1)
> FROM "default".Persons t1
>  JOIN (SELECT name from "default".Persons group by name) t2
>  on t1.name = t2.name
>  group by t1.name
>
> This query cannot be run on nodes because of how the map query is built.
> When using explain for this query, the first line, which represents the map
> query to be run on remote nodes, looks like this :
>
> SELECT
> T1__Z0.NAME AS __C0_0,
> COUNT(1) AS __C0_1
> FROM "default".PERSONS T1__Z0
> /* "default".PERSONS.__SCAN_ */
>
> which is obviously an incorrect SQL query, as there an aggregation function
> called without a group by clause. Thus, on each remote node, the following
> exception will be thrown:
>
> Caused by: org.h2.jdbc.JdbcSQLException: Column "T1__Z0.NAME" must be in
> the
> GROUP BY list; SQL statement
>
>  This is only happening (as far as I observed) only when joining with a
> subquery containing a group by clause, and the error can be reproduced with
> virtually any table. Has anyone else discovered encountered this behaviour
> before?
>
> As a side note, enabling an index on the "name" column seems to overcome
> the
> problem, but it is not a viable solution for production systems with many
> different queries.
>
> Thanks,
> Alin
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Andrey V. Mashenkov

Incorrect map query built when joining with a subquery with group by statement

[alin-corodescu]

Hello,

While experimenting around with Ignite, I came across a bug regarding the
map query building. (the queries that run on each individual node). Consider
the following dummy query (this is a reproduction of the error I found while
testing actual production queries):

SELECT t1.name, count(1)
FROM "default".Persons t1
 JOIN (SELECT name from "default".Persons group by name) t2
 on t1.name = t2.name
 group by t1.name

This query cannot be run on nodes because of how the map query is built. 
When using explain for this query, the first line, which represents the map
query to be run on remote nodes, looks like this :

SELECT
T1__Z0.NAME AS __C0_0,
COUNT(1) AS __C0_1
FROM "default".PERSONS T1__Z0
/* "default".PERSONS.__SCAN_ */

which is obviously an incorrect SQL query, as there an aggregation function
called without a group by clause. Thus, on each remote node, the following
exception will be thrown:

Caused by: org.h2.jdbc.JdbcSQLException: Column "T1__Z0.NAME" must be in the
GROUP BY list; SQL statement

 This is only happening (as far as I observed) only when joining with a
subquery containing a group by clause, and the error can be reproduced with
virtually any table. Has anyone else discovered encountered this behaviour
before? 

As a side note, enabling an index on the "name" column seems to overcome the
problem, but it is not a viable solution for production systems with many
different queries.

Thanks,
Alin




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

Re: Ignite log

[Andrey Mashenkov]

Hi,

Would you please attach full log as partial screenshot attaches is not
informative?

On Fri, Oct 27, 2017 at 12:33 PM, deleerhai <185961...@qq.com> wrote:

> hello!
>
> Following the launch of the ignite has been following the log output, what
> is the reason? Why is there a timeout?
> 
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Ignite Events Remote Filter

[Alexey Kukushkin]

Also, I ran our CacheEventsExample and I confirm the remote filter is NOT
unsubscribed when it returns false. So it looks like a documentation bug
only.

On Fri, Oct 27, 2017 at 1:10 PM, Alexey Kukushkin  wrote:

> Hi,
>
> I think it is a documentation bug. I do not think remote listener will be
> unsubscribed if it returns false. Let's confirm with the developers
> community.
>
> *Ignite Developers*,
>
> We have this comment for the remoteListener argument of the
> IgniteEvents#remoteListen(...):
>
> rmtFilter - Filter callback that is called on remote node. Only events
> that pass the remote filter will be sent to local node. If null, all events
> of specified types will be sent to local node. This remote filter can be
> used to pre-handle events remotely, before they are passed in to local
> callback. *It will be auto-unsubsribed on the node where event occurred
> in case if it returns false*.
>
> The documentation in bold looks like a bug to me. Why we would do it that
> way? To get only the first event? I think the idea is to listen until
> either master node leaves or you call remoteUnsubscribe(). I feel we just
> need to remove that sentence from the comments. Could you please confirm?
>
>
> On Fri, Oct 27, 2017 at 4:25 AM, rajivgandhi 
> wrote:
>
>> Hi,
>> We wish to listen to remote events with a remote filter and local
>> listener:
>> https://apacheignite.readme.io/docs/events#section-remote-events
>>
>> Our requirement is to entertain only those events on local listener which
>> are allowed by remote filter. This is the API we are trying to use:
>> https://ignite.apache.org/releases/latest/javadoc/org/apache
>> /ignite/IgniteEvents.html#remoteListen(org.apache.ignite
>> .lang.IgniteBiPredicate,%20org.apache.ignite.lang.Ignit
>> ePredicate,%20int...)
>>
>> As per this API:
>> "rmtFilter - Filter callback that is called on remote node. Only events
>> that
>> pass the remote filter will be sent to local node. If null, all events of
>> specified types will be sent to local node. This remote filter can be used
>> to pre-handle events remotely, before they are passed in to local
>> callback.
>> *It will be auto-unsubsribed on the node where event occurred in case if
>> it
>> returns false.*"
>>
>> As per the bolded part, it seems the remote listener will be unsubscribed
>> as
>> soon as the remote filter returns false. Is that right? We want to be able
>> to continue listening even after the remote filter has once
>> filtered/blocked
>> the event on remote nodes. If that is indeed the case (remote filter stops
>> listening), are there any other work arounds?
>>
>> thanks!
>> Rajeev Gandhi
>>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>
>
>
> --
> Best regards,
> Alexey
>



-- 
Best regards,
Alexey

Re: Ignite Events Remote Filter

[Alexey Kukushkin]

Hi,

I think it is a documentation bug. I do not think remote listener will be
unsubscribed if it returns false. Let's confirm with the developers
community.

*Ignite Developers*,

We have this comment for the remoteListener argument of the
IgniteEvents#remoteListen(...):

rmtFilter - Filter callback that is called on remote node. Only events that
pass the remote filter will be sent to local node. If null, all events of
specified types will be sent to local node. This remote filter can be used
to pre-handle events remotely, before they are passed in to local callback. *It
will be auto-unsubsribed on the node where event occurred in case if it
returns false*.

The documentation in bold looks like a bug to me. Why we would do it that
way? To get only the first event? I think the idea is to listen until
either master node leaves or you call remoteUnsubscribe(). I feel we just
need to remove that sentence from the comments. Could you please confirm?


On Fri, Oct 27, 2017 at 4:25 AM, rajivgandhi  wrote:

> Hi,
> We wish to listen to remote events with a remote filter and local listener:
> https://apacheignite.readme.io/docs/events#section-remote-events
>
> Our requirement is to entertain only those events on local listener which
> are allowed by remote filter. This is the API we are trying to use:
> https://ignite.apache.org/releases/latest/javadoc/org/
> apache/ignite/IgniteEvents.html#remoteListen(org.apache.
> ignite.lang.IgniteBiPredicate,%20org.apache.ignite.lang.
> IgnitePredicate,%20int...)
>
> As per this API:
> "rmtFilter - Filter callback that is called on remote node. Only events
> that
> pass the remote filter will be sent to local node. If null, all events of
> specified types will be sent to local node. This remote filter can be used
> to pre-handle events remotely, before they are passed in to local callback.
> *It will be auto-unsubsribed on the node where event occurred in case if it
> returns false.*"
>
> As per the bolded part, it seems the remote listener will be unsubscribed
> as
> soon as the remote filter returns false. Is that right? We want to be able
> to continue listening even after the remote filter has once
> filtered/blocked
> the event on remote nodes. If that is indeed the case (remote filter stops
> listening), are there any other work arounds?
>
> thanks!
> Rajeev Gandhi
>
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Alexey

Re: ComputeGrid API in C++

[Igor Sapego]

Hi,
Yes, you are right, Ignition::Start(cfg, "node1"). You don't need to
set any specific properties, all you need to do is to register your
classes on all nodes on all machines after you start them.

> It just launches node1 within the same process as the application.
That's right. You need to write an application that starts node and
registers your classes.

What is the problem?

Best Regards,
Igor

On Thu, Oct 26, 2017 at 10:26 PM, asingh  wrote:

> Ignite node = Ignition::Start("node1");
>
> The first argument to Start() needs to be an xml file. Are there any
> specific properties that need to be set in the xml for this case?
> If I call Start(cfg, "node1"), it just launches node1 within the same
> process as the application.
>
> In the below diagram, what do I have to do to dispatch C1, C2, C3 to nodes
> 1, 2 and 3, specially when nodes 1,2 and 3 are running on different
> physical
> machines?
>
>   Compute Grid 
>
>  t1405/1db96a3-in_memory_compute.png>
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Ignite log

[deleerhai]

hello!

Following the launch of the ignite has been following the log output, what
is the reason? Why is there a timeout?
 



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

Re: Grid freezing

[Eduard Shangareev]

Hi, guys.

It looks like https://issues.apache.org/jira/browse/IGNITE-6313.

On Fri, Oct 27, 2017 at 10:28 AM, Evgenii Zhuravlev <
e.zhuravlev...@gmail.com> wrote:

> In logs i see messages:
>
> WARNING: Job is being cancelled because master task node left grid (as there 
> is no one waiting for results, job will not be failed over)
>
> Most possible that it's a root cause of problem you've described earlier
>
>
> 2017-10-26 21:27 GMT+03:00 smurphy :
>
>> Here is an additional log message that suggests that rolling back the
>> transaction is not working.
>> I do not know why the isolation level in this log is marked as
>> READ_COMMITTED. All transactions are configured to be Optimistic and
>> Serializable..:
>>
>>
>> 2017-10-26 10:49:12,524 ERROR [dna-scan-engine 172.29.11.197]
>> progress_monitor_1   {Log4JLogger.java:495} -  Failed to
>> add
>> cause to the end of cause chain (cause is printed here but will not be
>> propagated to callee): class o.a.i.i.transactions.IgniteTx
>> TimeoutCheckedException: Failed to acquire lock within provided timeout
>> for
>> transaction [timeout=1, tx=GridNearTxLocal
>> [mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
>> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [part=311, val=311, hasVal
>> Bytes=true], cacheId=-211228266, txKey=IgniteTxKey [key=KeyCacheObjectImpl
>> [part=311, val=311, hasValBytes=true], cacheId=-211228266],
>> val=[op=DELETE,
>> val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
>> entryProcessorsCol=null, ttl=-1, conflictExpireTi
>> me=-1, conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
>> filtersPassed=false, filtersSet=true, entry=GridDhtDetachedCacheEntry
>> [super=GridDistributedCacheEntry [super=GridCacheMapEntry
>> [key=KeyCacheObjectImpl [part=311, val=311, hasValBytes=true], val=null,
>>  startVer=1509032890673, ver=GridCacheVersion [topVer=120512802,
>> order=1509032890673, nodeOrder=4], hash=311, extras=null, flags=0]]],
>> prepared=0, locked=false, nodeId=790731d7-c002-436f-ae3e-9a3bd7944581,
>> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flag
>> s=0, partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion
>> [topVer=120512802, order=1509032890671, nodeOrder=4]]],
>> explicitLock=false,
>> dhtVer=null, last=false, nearEntries=0, clientFirst=false,
>> node=790731d7-c002-436f-ae3e-9a3bd7944581]], nearLocallyMapped=false,
>>  colocatedLocallyMapped=false, needCheckBackup=null, hasRemoteLocks=false,
>> thread=,
>> mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
>> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [part=311, val=311,
>> hasValBytes=
>> true], cacheId=-211228266, txKey=IgniteTxKey [key=KeyCacheObjectImpl
>> [part=311, val=311, hasValBytes=true], cacheId=-211228266],
>> val=[op=DELETE,
>> val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
>> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1,
>>  conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
>> filtersPassed=false, filtersSet=true, entry=GridDhtDetachedCacheEntry
>> [super=GridDistributedCacheEntry [super=GridCacheMapEntry
>> [key=KeyCacheObjectImpl [part=311, val=311, hasValBytes=true], val=null,
>> start
>> Ver=1509032890673, ver=GridCacheVersion [topVer=120512802,
>> order=1509032890673, nodeOrder=4], hash=311, extras=null, flags=0]]],
>> prepared=0, locked=false, nodeId=790731d7-c002-436f-ae3e-9a3bd7944581,
>> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0, p
>> artUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion
>> [topVer=120512802,
>> order=1509032890671, nodeOrder=4]]], explicitLock=false, dhtVer=null,
>> last=false, nearEntries=0, clientFirst=false,
>> node=790731d7-c002-436f-ae3e-9a3bd7944581]], super=GridDhtTxLocalAdapter
>> [n
>> earOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
>> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
>> depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true,
>> recovery=false], super=IgniteTxAdapter [xidVer=Gr
>> idCacheVersion [topVer=120512802, order=1509032890671, nodeOrder=4],
>> writeVer=null, implicit=true, loc=true, threadId=208,
>> startTime=1509032942451, nodeId=f55eb4f4-57cb-4a6e-b1db-5f91b8a0f34e,
>> startVer=GridCacheVersion [topVer=120512802, order=1509032890671,
>> nodeOrder
>> =4], endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC,
>> timeout=1, sysInvalidate=false, sys=false, plc=2,
>> commitVer=GridCacheVersion [topVer=120512802, order=1509032890671,
>> nodeOrder=4], finalizing=NONE, invalidParts=null, state=PREPARING,
>> timedOut=fal
>> se, topVer=AffinityTopologyVersion [topVer=4, minorTopVer=8],
>> duration=10024ms, onePhaseCommit=false], size=1
>> class org.apache.ignite.IgniteCheckedException: Failed to commit
>> transaction:
>> GridNearTxLocal[id=f219e595f51--072e-e122--0004,
>> concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK,
>> invalid

Re: Java to .NET interop

[Pavel Tupitsyn]

Yes, I think this can be fixed. This is just the matter of IgniteServices
implementation, Java 9 is not related here.
I've filed a ticket https://issues.apache.org/jira/browse/IGNITE-6770

On Fri, Oct 27, 2017 at 5:52 AM, Gordon Reid (Nine Mile) <
gordon.r...@ninemilefinancial.com> wrote:

> Hi Pavel,
>
>
>
> Thanks for the quick reply. I have not explicitly tried to only deploy the
> service classes without the entity classes into the java classpath on the
> .NET side. Our entity and service classes are packaged into the same jar. I
> won’t investigate this further, as its just as much of an inconvenience
> regardless of what is in the jar. But it’s good to know that the .NET
> client only needs a new JAR when a service class changes.
>
>
>
> Do you think this is something that might be fixed when ignite supports
> java 9? It would be great to have no binary dependency on our java server
> build inside our .net client.
>
>
>
> Thanks,
>
> Gordon.
>
>
>
> *From:* Pavel Tupitsyn [mailto:ptupit...@apache.org]
> *Sent:* Thursday, October 26, 2017 7:43 PM
> *To:* user@ignite.apache.org
> *Subject:* Re: Java to .NET interop
>
>
>
> Hi Gordon,
>
>
>
> Entity Java classes are not needed in .NET client classpath.
>
> Can you give an example when that does not work for you?
>
>
>
> As for services, unfortunately, there is a limitation on Java side,
>
> Service class should be available on all nodes [1] [2].
>
>
>
> Thanks,
>
> Pavel
>
>
>
> [1] https://apacheignite.readme.io/docs/service-grid
>
> [2] https://issues.apache.org/jira/browse/IGNITE-975
>
>
>
> On Thu, Oct 26, 2017 at 9:51 AM, Gordon Reid (Nine Mile)  ninemilefinancial.com> wrote:
>
> Hi Igniters,
>
>
>
> We are running Ignite 2.2.0, we have a .NET client (runs in ignite client
> mode) and Java servers. We call Ignite Services running on the Java side,
> from the .NET client. We also access our memory grid entities from the .NET
> client. Currently it seems we need to package our java server jar, publish
> it to nuget, and then import this on the .NET side. If we don’t have the
> entity and service classes available on the .NET side’s Java classpath then
> we cannot communicate from the .NET side to the Java side. We are using the
> binary marshaller and simple name mapper.
>
>
>
> Is there any way around this requirement? It is quite a hassle creating
> this tight binary coupling between our .NET client and Java server.
>
>
>
> 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
>
>
>
>
>
>
>
> 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: when client node connect to server node, server node throws NotSerializableException

[Jeff Jiao]

hi guys,

can anyone give some advice...
what can you see from this exception server side log when client connect to
it:
Caused by: java.io.NotSerializableException:
org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl

why it says IgniteBinaryImpl is not serializable?



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

Re: Grid freezing

[Evgenii Zhuravlev]

In logs i see messages:

WARNING: Job is being cancelled because master task node left grid (as
there is no one waiting for results, job will not be failed over)

Most possible that it's a root cause of problem you've described earlier


2017-10-26 21:27 GMT+03:00 smurphy :

> Here is an additional log message that suggests that rolling back the
> transaction is not working.
> I do not know why the isolation level in this log is marked as
> READ_COMMITTED. All transactions are configured to be Optimistic and
> Serializable..:
>
>
> 2017-10-26 10:49:12,524 ERROR [dna-scan-engine 172.29.11.197]
> progress_monitor_1   {Log4JLogger.java:495} -  Failed to
> add
> cause to the end of cause chain (cause is printed here but will not be
> propagated to callee): class o.a.i.i.transactions.IgniteTx
> TimeoutCheckedException: Failed to acquire lock within provided timeout for
> transaction [timeout=1, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [part=311, val=311, hasVal
> Bytes=true], cacheId=-211228266, txKey=IgniteTxKey [key=KeyCacheObjectImpl
> [part=311, val=311, hasValBytes=true], cacheId=-211228266], val=[op=DELETE,
> val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
> entryProcessorsCol=null, ttl=-1, conflictExpireTi
> me=-1, conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtDetachedCacheEntry
> [super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=311, val=311, hasValBytes=true], val=null,
>  startVer=1509032890673, ver=GridCacheVersion [topVer=120512802,
> order=1509032890673, nodeOrder=4], hash=311, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=790731d7-c002-436f-ae3e-9a3bd7944581,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flag
> s=0, partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion
> [topVer=120512802, order=1509032890671, nodeOrder=4]]], explicitLock=false,
> dhtVer=null, last=false, nearEntries=0, clientFirst=false,
> node=790731d7-c002-436f-ae3e-9a3bd7944581]], nearLocallyMapped=false,
>  colocatedLocallyMapped=false, needCheckBackup=null, hasRemoteLocks=false,
> thread=,
> mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
> [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [part=311, val=311,
> hasValBytes=
> true], cacheId=-211228266, txKey=IgniteTxKey [key=KeyCacheObjectImpl
> [part=311, val=311, hasValBytes=true], cacheId=-211228266], val=[op=DELETE,
> val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1,
>  conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtDetachedCacheEntry
> [super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=311, val=311, hasValBytes=true], val=null,
> start
> Ver=1509032890673, ver=GridCacheVersion [topVer=120512802,
> order=1509032890673, nodeOrder=4], hash=311, extras=null, flags=0]]],
> prepared=0, locked=false, nodeId=790731d7-c002-436f-ae3e-9a3bd7944581,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0, p
> artUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion
> [topVer=120512802,
> order=1509032890671, nodeOrder=4]]], explicitLock=false, dhtVer=null,
> last=false, nearEntries=0, clientFirst=false,
> node=790731d7-c002-436f-ae3e-9a3bd7944581]], super=GridDhtTxLocalAdapter
> [n
> earOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
> depEnabled=false, txState=IgniteTxImplicitSingleStateImpl [init=true,
> recovery=false], super=IgniteTxAdapter [xidVer=Gr
> idCacheVersion [topVer=120512802, order=1509032890671, nodeOrder=4],
> writeVer=null, implicit=true, loc=true, threadId=208,
> startTime=1509032942451, nodeId=f55eb4f4-57cb-4a6e-b1db-5f91b8a0f34e,
> startVer=GridCacheVersion [topVer=120512802, order=1509032890671, nodeOrder
> =4], endVer=null, isolation=READ_COMMITTED, concurrency=OPTIMISTIC,
> timeout=1, sysInvalidate=false, sys=false, plc=2,
> commitVer=GridCacheVersion [topVer=120512802, order=1509032890671,
> nodeOrder=4], finalizing=NONE, invalidParts=null, state=PREPARING,
> timedOut=fal
> se, topVer=AffinityTopologyVersion [topVer=4, minorTopVer=8],
> duration=10024ms, onePhaseCommit=false], size=1
> class org.apache.ignite.IgniteCheckedException: Failed to commit
> transaction:
> GridNearTxLocal[id=f219e595f51--072e-e122--0004,
> concurrency=OPTIMISTIC, isolation=READ_COMMITTED, state=ROLLED_BACK,
> invalidate=false, rollbackOnly=true, nodeId=f55eb4f4
> -57cb-4a6e-b1db-5f91b8a0f34e, duration=10037]
> at
> org.apache.ignite.internal.processors.cache.distributed.
> near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:423)
> at
> org.apache.ignite.int