RE: Java to .NET interop

[Gordon Reid (Nine Mile)]

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) 
> 
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

Ignite Events Remote Filter

[rajivgandhi]

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/

cache closed or destroyed issue

[Pradeep Badiger]

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.

Re: Custom SecurityCredentialsProvider and SecurityCredentials

[vkulichenko]

Hi Frank,

Sorry for late response. SecurityCredentialsProvider is not used in Ignite
code because Ignite doesn't provide any implementations of SecurityProcessor
out of the box. If you want to make your cluster secure, you need to
implement it and configure as a part of your own custom plugin. There are
also 3rd party solutions like GridGain that provide such implementations as
paid offerings.

-Val



--
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

[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  >   > >>:
> > 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/ 
> >  
> >  > >

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

[Dmitry Pavlov]

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 >:
> > 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: Ignite in embeded mode in Spark running in dynamic mode

[vkulichenko]

Ranjit,

You can use it with Yarn or without Yarn. The point is that Ignite cluster
is independent from Spark cluster, i.e. runs in separate processes.

-Val



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

Re: ComputeGrid API in C++

[asingh]

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   


 





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

Re: Grid freezing

[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.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3255)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$5.applyx(GridNearTxLocal.java:1624)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$5.applyx(GridNearTxLocal.java:1614)
at

Re: Node and cluster maintenance best practice

[Denis Magda]

Follow the same process if you have the persistence enabled. Deactivate the 
cluster, terminate the nodes and do the upgrade.

If you want to upgrade nodes in a rolling upgrade fashion then look for 
features provided enterprise products built on top of Ignite.

—
Denis

> On Oct 23, 2017, at 6:57 AM, blackfield  wrote:
> 
> Thank you, Denis.
> 
> How about best practice for bringing down a node for maintenance (e.g.
> applying OS patch, hardware maintenance, etc)? 
> 
> 
> 
> --
> 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

[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  >:
> 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/ 
> 

Re: Ignite 2.0.0 GridUnsafe unmonitor

[Denis Magda]

+ dev list

Igniters, that’s a relevant point below. Newcomers to Ignite tend to stumble on 
deadlocks simply because the keys are passed in an unordered HashMap. Propose 
to do the following:
- update bulk operations Java doc.
- print out a warning if a HashMap is used and its exceeds one element.

Thoughts?

—
Denis

> On Oct 21, 2017, at 6:16 PM, dark  wrote:
> 
> Many people seem to be more likely to send Cache entries in bulk via a
> HashMap. 
> How do you expose a warning statement by checking if the TreeMap is putAll
> inside the code?
> 
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite 2.0.0 GridUnsafe unmonitor

[Denis Magda]

> Performance is definitely improving. However, the worry is whether or not
> OffHeap will be cleaned up properly and whether memory leaks will be caused
> by the cache meta information of the Ignite Java Heap.
> 
> Do you have any other concerns?

There is nothing I’m concerned about here.

—
Denis

> On Oct 21, 2017, at 7:57 AM, dark  wrote:
> 
> Thank you for your kind comments.
> 
> EagerTttl is usually useful. However, it did not match our situation.
> 
> We put 40k/s entry to ignite server node. If the backup option is enabled to
> prevent some loss of data, large cache entries will cause simultaneous
> expiration. (We expiry the Cache entry after 5 minutes without updating.) At
> this time, Eager's 500ms interval and 1000 expiry was not enough to continue
> the expiry efficiently, and there was an issue that keeps the
> ttl-cleanup-worker CPU. So we chose to keep Cache itself on time, destroy
> the cache itself and eliminate expiration costs.
> 
>  
> < Before : EagerTtl is true >
> 
>  
> < After : EagerTtl is false & cache destroy strategy >
> 
> Performance is definitely improving. However, the worry is whether or not
> OffHeap will be cleaned up properly and whether memory leaks will be caused
> by the cache meta information of the Ignite Java Heap.
> 
> Do you have any other concerns?
> 
> Thanks again for your reply. :)
> 
> 
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Grid freezing

[smurphy]

One thing that I see in the logs looks to me like a NullPointerException on
attempting to commit an optimistic/serializable transaction.
My reading of this excpetion is that an optimistic lock conflict is
correctly detected in prepare0 but that  eventually the code incorrectly
attempts to return this.ret which is null rather than an
IgniteTxOptimisticCheckedException...:



Oct 25 19:25:46 srvr.company apache-ignite[45092]: [19:25:46] (err) Failed
to execute compound future reducer: GridDhtTxPrepareFuture
[futId=2a3ec065f51-75e18206-0fee-4926-99be-bb6fee7b5828, err=null,
replied=1, mapped=1, reads=[], writes=[IgniteTxEntry [key=KeyCacheObjectImpl
[part=115, val=115, hasValBytes=true], cacheId=-211228266, txKey=IgniteTxKey
[key=KeyCacheObjectImpl [part=115, val=115, hasValBytes=true],
cacheId=-211228266], val=[op=UPDATE,
val=com.company.dna.scan.fragment.node.domain.Scan [idHash=1148364470,
hash=525731140, _fragmentIds=HashSet {}, _scannerGroupId=16,
_visibility=EXTERNAL, _scanUUID=d1a7a992-6ff2-4eb0-8398-06e45b15d08b,
_customerId=6779780, _customerMaxReached=false, _priority=1,
_scanStartedMsgSent=false, _empty=true, _idx=115, _canceled=true,
_scanId=45534, _version=2]], 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=false, entry=GridDhtCacheEntry [rdrs=[],
part=115, super=GridDistributedCacheEntry [super=GridCacheMapEntry
[key=KeyCacheObjectImpl [part=115, val=115, hasValBytes=true],
val=com.company.dna.scan.fragment.node.domain.Scan [idHash=582900940,
hash=-1150571357, _fragmentIds=HashSet {}, _scannerGroupId=16,
_visibility=EXTERNAL, _scanUUID=d1a7a992-6ff2-4eb0-8398-06e45b15d08b,
_customerId=6779780, _customerMaxReached=false, _priority=1,
_scanStartedMsgSent=true, _empty=true, _idx=115, _canceled=false,
_scanId=45534, _version=3], startVer=1508977480914, ver=GridCacheVersion
[topVer=120361566, order=1508977480909, nodeOrder=33], hash=115,
extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
[locs=[GridCacheMvccCandidate [nodeId=47680ca3-827f-4788-af9e-d73dd7b030e0,
ver=GridCacheVersion [topVer=120361566, order=1508977480913, nodeOrder=33],
threadId=111, id=396, topVer=AffinityTopologyVersion [topVer=39,
minorTopVer=0], reentry=null,
otherNodeId=7a2804c4-5fae-4258-b6e2-96e75a219ea7, otherVer=GridCacheVersion
[topVer=120361566, order=1508977480890, nodeOrder=39], mappedD
Oct 25 19:25:46 srvr.company apache-ignite[45092]: htNodes=null,
mappedNearNodes=null, ownerVer=null, serOrder=GridCacheVersion
[topVer=120361566, order=1508977480890, nodeOrder=39],
key=KeyCacheObjectImpl [part=115, val=115, hasValBytes=true],
masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=1,
locked=false, nodeId=null, locMapped=false, expiryPlc=null,
transferExpiryPlc=false, flags=0, partUpdateCntr=0,
serReadVer=GridCacheVersion [topVer=120361566, order=1508977480161,
nodeOrder=33], xidVer=null]], trackable=true, nearMiniId=2, last=true,
retVal=false, ret=null, lockKeys=[], forceKeysFut=null, locksReady=true,
invoke=false, timeoutObj=PrepareTimeoutObject [timeout=9976],
xid=GridCacheVersion [topVer=120361566, order=1508977480913, nodeOrder=33],
innerFuts=[], super=GridCompoundFuture
[rdc=o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture$1@38648d98,
initFlag=1, lsnrCalls=0, done=false, cancelled=false, err=null,
futs=[]]]java.lang.NullPointerException
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.implicitSingleResult(IgniteTxLocalAdapter.java:352)
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.createPrepareResponse(GridDhtTxPrepareFuture.java:875)
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:763)
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:103)
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:450)
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:278)
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.util.future.GridCompoundFuture.markInitialized(GridCompoundFuture.java:269)
Oct 25 19:25:46 srvr.company apache-ignite[45092]: at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1468)
Oct 25 19:25:46 srvr.company 

Re: Grid freezing

[smurphy]

log_1.txt
  
log_2.txt
  
log_3.txt
  

I don't see any nodes shutting down until 9 minutes after this particular
log..
But please see the attached are server logs for fuller details..





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

Re: Near Cache Topoolgy change causes NearCache to always miss.

[slava.koptilin]

Hi Tim,

I was able to reproduce the issue.
I've created the following jira ticket in order to track this:
https://issues.apache.org/jira/browse/IGNITE-6767

Thanks,
S.



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

Re: ComputeGrid API in C++

[Igor Sapego]

Hi,

You don't have to modify platforms/cpp/ignite/src/ignite.cpp.
Why won't you modify your code, where you start the node?

I mean, in *your application code* write something like this:

Ignite node = Ignition::Start("node1");
IgniteBinding binding = node.GetBinding();

binding.RegisterComputeFunc();

You don't have to modify method Ignition::Start() or any
other method for that.


Best Regards,
Igor

On Thu, Oct 26, 2017 at 5:31 PM, asingh  wrote:

> Hi Igor
>
> Shouldn't be a problem, given that the source code is there. I just want to
> make sure that I am doing it the right way. Currently, I have modified the
> main() method in platforms/cpp/ignite/src/ignite.cpp and added these two
> lines:
>
> IgniteBinding binding = ignite.GetBinding();
> binding.RegisterComputeFunc();
>
> Also, when would I use IgniteModuleInit()? Is it when the Call() method is
> implemented in a shared library?
>
> Thanks!
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: ComputeGrid API in C++

[asingh]

Hi Igor

Shouldn't be a problem, given that the source code is there. I just want to
make sure that I am doing it the right way. Currently, I have modified the
main() method in platforms/cpp/ignite/src/ignite.cpp and added these two
lines:

IgniteBinding binding = ignite.GetBinding();
binding.RegisterComputeFunc();

Also, when would I use IgniteModuleInit()? Is it when the Call() method is
implemented in a shared library?

Thanks!



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

Re: Grid freezing

[smurphy]

No - this is what the invocation looks like:

DequeuePortionsCallable job = new
DequeuePortionsCallable(ignitePortionDequeuer);
DequeuedPortionResponse response = _ignite.compute().call(job);




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

Re: Failed to query ignite

[Andrey Mashenkov]

Hi,

Thanks for reproducer.
I've make some changes and run test against 2.1, 2.2 and 2.3 version.
Test with affinity key fails on 2.1 and 2.2 versions and looks ok on 2.3
version.

Seems, there was a bug in 2.1 and it is already fixed in 2.3.

PFA repro.

On Thu, Oct 26, 2017 at 10:39 AM, iostream  wrote:

> One more thing to add - when I remove "affinityKey" from ID, I am able to
> query successfully. The error occurs when I set "ID" as my affinityKey. Is
> it a known bug?
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Andrey V. Mashenkov
package userlist;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;

/** */
public class AFTest extends GridCommonAbstractTest {

/** {@inheritDoc} */
@Override protected void beforeTest() throws Exception {
super.beforeTest();

startGrid(0);
}

/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
super.afterTest();

stopAllGrids();
}

/** */
public void testNoAffinityKey() throws Exception {
checkDDLQuery("CREATE TABLE Person (id BIGINT,name VARCHAR,PRIMARY KEY (id))" +
"WITH \"backups=1\"");
}

/** */
public void testWithAffinityKey() throws Exception {
checkDDLQuery("CREATE TABLE Person (id BIGINT,name VARCHAR,PRIMARY KEY (id))" +
"WITH \"backups=1,affinityKey=id\"");
}

/** */
public void checkDDLQuery(String sql) throws Exception {
ResultSet rs = null;

Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
try(Connection conn = DriverManager
.getConnection("jdbc:ignite:thin://127.0.0.1:10800/")) {

// create table
try (PreparedStatement stmt = conn.prepareStatement(sql)) {
stmt.executeUpdate();
}

// create table
try (PreparedStatement stmt = conn.prepareStatement(
"INSERT INTO Person (id,name) VALUES (?,?)")) {
stmt.setLong(1,1L);
stmt.setString(2,"John");
stmt.executeUpdate();
}

// Try to query
try (PreparedStatement stmt2 = conn.prepareStatement("select * from Person where id = ?")) {
stmt2.setObject(1, 1L);
rs = stmt2.executeQuery();

rs.next();

System.out.println(rs.getLong(1));
System.out.println(rs.getString(2));
}
}
}
}

Re: Ignite Web Session Clustering

[slava.koptilin]

Hello!

> our main project uses Jboss Seam 2.2.1.CR1, JSF 1.2_15, Facelets 1.1.14,
> Richfaces 
> 3.3.3, Hibernate 3.3.2, c3p0 0.9.1.2, Spring 3.1.3 and Servlet 2.5 (maybe
> we 
> can update the Servlet version, but not the others). 
Apache ignite has been officially tested with the following servlet
containers:
Apache Tomcat 7
Eclipse Jetty 9
Apache Tomcat 6
Oracle WebLogic >= 10.3.4

> As we're not using the most recent versions of those frameworks and there 
> are something like Seam contexts, do you think that our application is 
> suitable for Ignite Web Session Clustering? 
I think your application can be used with Ignite.
Anyway, the best way to know - is to try :)

Thanks!



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

Re: ComputeGrid API in C++

[Igor Sapego]

You need to have the same code on all C++ nodes to be able
to execute it remotely. In other words, you need to register
classes you want to invoke remotely on all three nodes.

Is that a problem for you?

Best Regards,
Igor

On Wed, Oct 25, 2017 at 6:35 PM, asingh  wrote:

> So, here is what I am trying to do:
> 1. Launch ignite node on one Linux machine
> 2. Launch another ignite node on second Linux machine
> 3. On one of the two machines, run the compute_example containing
> PrintWords() class and have its Call() method invoked via
> compute.RunAsync()
> on all three machines in parallel.
>
> All three ignite nodes use the same xml that I had attached earlier.
>
> I was not able to have the example dispatch the calls to the independent
> ignite nodes, without explicitly registering the PrintWords class in
> ignite's main function.
>
> I am sure there is a better way to do this, but I need some help in
> figuring
> out how!
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Java to .NET interop

[Pavel Tupitsyn]

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) <
gordon.r...@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
>

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

[Alexey Popov]

Hi Anand,

>In regards to your comment on cache will not get updated using invoke. How 
>do I ensure that the new computed value gets stored in the cache. 
>The first goal is to iterate through the cache and update a specific data 
>field in the cache in the fastest way possible. 
>The second goal is to - the cache has writethrough/writebehind enabled and 
>hence the updates will need to be propagated to the database as well. 

1. Just don't forget to call entry.setValue(val) at the final step of your
invoke() to store an updated value:

cache.invoke(key, (entry, args) -> { 
Fact val = entry.getValue(); 
// do some logic 
val.setAmount(val.getAmt1() +
val.getAmt2()); 
// save results
entry.setValue(val);
return val; 
}); 
It would not add any visible processing time.
You could try batch requests here with invokeAll() (as you have in your code
before) to achieve a better performance.

2. All such updates should be automatically propagated by Ignite to DB via
CacheStore if you have writethrough enabled.

Thanks,
Alexey



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

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

[Jeff Jiao]

just in case you don't see my replies, I will put all of these in one msg.

yes, PIgniteCacheStoreFactory implements javax.cache.configuration.Factory, 
and this factory extends Serializable. 
like I said " I already created my own factory to create the cache store to 
avoid Serialization problem." and I really need to inject properties to the
cacheStore when factory create it. 
without the custom factory, it cannot start any nodes b/c my own cacheStore
doesn't implements Serializable. 

The problem I had is when I start a client node to connect to a running 
server node, on server node throws exception and client node looks fine, 
this is wierd... why the connection trigger the exception.. 





from the the bottom part of server side log, we can see that "Caused by:
java.io.NotSerializableException:
org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl"

what does this mean? is it related to I store BinaryObject as value?





I tried to comment out this part, the exception I saw on server node 
before doesn't appear this time... 
so it looks like Cache Factory/Store problem... but why... 

 
 
 
 
 
 
 
 
 
 
 
 
 



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

Re: Failed to query ignite

[iostream]

One more thing to add - when I remove "affinityKey" from ID, I am able to
query successfully. The error occurs when I set "ID" as my affinityKey. Is
it a known bug?



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

Re: Cannot find schema for object with compact footer

[zshamrock]

Yes, I suppose so, as it fails in the integration test, which uses the ignite
client, so the client node.



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

Re: Grid freezing

[Evgenii Zhuravlev]

Is it possible that you run DequeuePortionsCallable with timeout?

Evgenii

2017-10-26 6:40 GMT+03:00 smurphy :

> I added a transaction timeout of 1 millis and a transation size of 100
> (transaction is Optimistic and Serializable)...
>
> I see no TransactionTimeoutExceptions, just the following:
> CacheException: class org.apache.ignite.IgniteInterruptedException: Got
> interrupted while waiting for future to complete..
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Java to .NET interop

[Gordon Reid (Nine Mile)]

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

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

[Jeff Jiao]

ok I tried to comment out this part, the exception I saw on server node
before doesn't appear this time...
so it looks like Cache Factory/Store problem... but why...

















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