IgniteCache method replace(key,newVal) behave different with replace(key,oldVal,newVal)

2016-05-16 Thread 张鹏鹏
Are there some different between the IgniteCache  two replace methods?

In my test:

If I call the replace(key,newVal),it's ok.
but if I call replace(key,oldVal,newVal) ,there is an exception throws.

org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
(retry update if possible).:
[542c87f7-1972-4682-9ae9-5fd603a33cd3:6b90e675-c55d-4734-9de7-44301670f64e]

It's the config:


  
  
  
  
  
  
  
  
  

  



  




  


  

  
openid
yyyappid
virtualcurrency
  


  

  

  
  

  

  




Is there something wrong?


Re: Ignite Aggregation query

2016-05-16 Thread Sergi Vladykin
There is no limitation (other than java heap size) but it must be some sane
number if you want to have sane performance.

BTW, you can find these docs helpful:
https://apacheignite.readme.io/docs/sql-queries#performance-and-usability-considerations

Sergi

2016-05-17 2:45 GMT+03:00 diopek :

> Ignite has any restriction for the maximum number of tokens to be used
> within
> IN (...) clause as Oracle IN clause does?
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Aggregation-query-tp4968p4978.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Get client node instance

2016-05-16 Thread arthi
Hi Igor,

I was wondering if the ODBC driver that will come up in v1.6 is thread safe?
Can we do a connection pooling using this driver from our calling
application level?

I am just trying to see if we can go with the ODBC driver to connect to the
grid instead of the c++ client API.

Thanks,
Arthi



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


Re: Get client node instance

2016-05-16 Thread arthi
thanks Igor,

The application is in C++. I was hoping if I could create a shared memory
with ignite instance and share it with other process that get trigged on
user requests. Is this a possibility?

The developer tried it, but seems like it did not work. May be we are
missing something. Let me know if we should share the code.

Thanks for the help,
Arthi



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


Ignite non unique table mapping problem

2016-05-16 Thread Zhengqingzheng
Hi there,
I am trying to import a table which has no unique index, so there will be one 
key to many values mapping.
I am wondering is there any support of such situation. I know that in redis, I 
can use zadd( score, value) to store a list as value.
But I did not see any similar support in Ignite.

Cheers,
Kevin



Re: Cache Refresh Options

2016-05-16 Thread Dmitriy Setrakyan
Murthy, would setting a simple TTL for entries work for you?

Here is more info:
https://apacheignite.readme.io/docs/expiry-policies

D.

On Fri, May 13, 2016 at 2:03 PM, Murthy Kakarlamudi 
wrote:

> Hi,
>What are my options to refresh ignite cache from underlying persistent
> store on a scheduled basis. My use case is I have a server node that loads
> data from underlying store to cache and I have a couple of client nodes
> that perform computations reading cache data. I understand using Eviction
> Policy and read-through, my client nodes can get the latest data, but I
> cannot afford a database call during my computation.
>
> As my computation happens during business hours, I was wondering if I can
> refresh my cache during non-business hours. Does Ignite have any support
> for such scheduled refreshes?
>
> Thanks,
> Murthy.
>


Re: Client Connection to Ignite takes time

2016-05-16 Thread Dmitriy Setrakyan
The documentation currently does not look complete for the upcoming 1.6
release. We should add version 1.6 of the documentation and add
Transactions and other CPP improvements there.

Igor, given that you are contributing most of the CPP functionality, do you
think you can update the docs?

D.

On Mon, May 16, 2016 at 4:46 AM, Denis Magda  wrote:

> Hi Arthi,
>
> Yes, there is a dedicated documentation created for Ignite C++ API. Please
> refer to it for more details:
> https://apacheignite-cpp.readme.io/docs/
>
> —
> Denis
>
> On May 11, 2016, at 12:01 PM, arthi 
> wrote:
>
> Thanks Denis.
>
> I think we should try this. Is there an C++ API we could use to get the
> ignite client node instance from the  grid to run SQL queries?
>
> Thanks,
> Arthi
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Client-Connection-to-Ignite-takes-time-tp4739p4870.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com
> .
>
>
>


Re: ODBC Driver and Reporting Tool Usage

2016-05-16 Thread Dmitriy Setrakyan
Hi Dillip,

I think it would be possible, but I am not sure if anyone in the community
will have time to get to it soon.

Would you be interested in contributing something like this? I think a
video of Ignite with Tableau will be extremely useful.

D.

On Sat, May 14, 2016 at 5:01 AM, Dillip Sahoo 
wrote:

> Hello Igor,
> Along with ODBC driver in v1.6, is it also possible to put some video on
> Youtube explaining, how ODBC can be used along with few famous reporting
> tools in a stable manner. (something done by Gridgrain for Ignite with
> Zeppelin integration).
>
> I think you would be already testing many reporting tools on top of new
> ODBC
> driver.
> How about recording the successful tests, putting some of that on Youtube?
>
> If possible, a video starting steps on how to setup Ignite on Linux ending
> with reports running on Tableau. Sorry for asking too much.
> But for sure, this will increase adaptability.
>
> Thanks,
> Dillip
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/ODBC-Driver-and-Reporting-Tool-Usage-tp4943.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Ignite Aggregation query

2016-05-16 Thread diopek
Ignite has any restriction for the maximum number of tokens to be used within
IN (...) clause as Oracle IN clause does?



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


Re: Ignite Aggregation query

2016-05-16 Thread Dmitriy Setrakyan
Both should work, but the 1st one does not require creation of a temporary
table, so prefer the 1st one.

On Mon, May 16, 2016 at 1:12 PM, diopek  wrote:

> Can you please advise, which SQL group-by query would be better practice,
> perform better?
>
> (1)
> *select A, B, SUM(C) from MyCache where
> MyCache.id IN ()
> group by A, B*
>
> or,
> (2)
> by first storing IDs to be joined into some temporary cache as setting ID
> as
> affinity key to co-locate the data with MyCache
>
> and then do a cross-cache join query as the following;
>
> *select A, B, SUM(C) from MyCache, TempCache where
> MyCache.id = TempCache.id
> group by A, B*
>
> (1) or (2) ?
>
>
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Aggregation-query-tp4968p4974.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Can't stop Ignite instance using Ignition.stopAll() or Ignition.kill() until writeBehindFlushFrequency passed

2016-05-16 Thread zshamrock
 

And then it is hanging for about 5 minutes after each IT case.
Does the picture above help somehow?

How I can do a thread dump? I've tried to use jstack, although could not
find anything meaningful in the report it has produced.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Can-t-stop-Ignite-instance-using-Ignition-stopAll-or-Ignition-kill-until-writeBehindFlushFrequency-pd-tp4837p4976.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.


Re: Clear cache from Visor throws an exception

2016-05-16 Thread zshamrock
Hi, Denis. Not yet. Will try to test it tomorrow.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Clear-cache-from-Visor-throws-an-exception-tp4848p4975.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.


Re: Ignite Aggregation query

2016-05-16 Thread diopek
Can you please advise, which SQL group-by query would be better practice,
perform better?

(1)
*select A, B, SUM(C) from MyCache where 
MyCache.id IN ()
group by A, B*

or, 
(2)
by first storing IDs to be joined into some temporary cache as setting ID as
affinity key to co-locate the data with MyCache

and then do a cross-cache join query as the following;

*select A, B, SUM(C) from MyCache, TempCache where 
MyCache.id = TempCache.id
group by A, B*

(1) or (2) ?





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


Re: Custom GridSecurityProcessor plugin question

2016-05-16 Thread Anand Kumar Sankaran
Hi Denis

Thanks!

I was doing two things wrong.

GridSecurityProcessor.enabled() was returning false and my security processor 
implemented both DiscoverySpiNodeAuthenticator and GridSecurityProcessor

Once I fixed both, authenticateNode was getting called.

I think for my requirements (prevent a node from joining and not fine grained 
entitlement), validateNode is sufficient (and using ClusterNode.attribute to 
pass in parameters).  A quick test along those lines seem to work.

I need to add a few comments to 
http://smartkey.co.uk/development/securing-an-apache-ignite-cluster explaining 
this.

--
anand

From: Denis Magda 
Reply-To: "user@ignite.apache.org" 
Date: Monday, May 16, 2016 at 6:13 AM
To: "user@ignite.apache.org" 
Subject: Re: Custom GridSecurityProcessor plugin question

Hi Anand,

GridSecurityProcessor.authenticateNode(…) has to be called on your side. Please 
double check that GridSecurityProcessor.enabled() returns true. If it returns 
true then your GridSecurityProcessor will be registered in 
GridDiscoveryManager.start() method.

If this doesn’t happen please debug GridDiscoveryManager.start() method at the 
place when discovery SPI authenticator is set and places where 
DiscoverySpiNodeAuthenticator.authenticateNode is used and share the results 
with us.

—
Denis

On May 16, 2016, at 12:01 AM, Anand Kumar Sankaran 
mailto:anand.sanka...@workday.com>> wrote:

I went past this.  Turns out if everything is ok, validateNode has to return 
null ☹.

That brings me to another question.  validateNode callback only provides us 
with the ClusterNode. We were thinking the information needed to let a node 
join the cluster or not would be part of a custom SecurityCredentials object, 
which is available only at the authenticateNode level and not the validateNode.

If I want to prevent a node from joining the cluster, and if validateNode is 
the way to do it, should I add custom node attributes to ClusterNode and use 
that information?

--
thanks

anand

From: Anand Kumar Sankaran 
mailto:anand.sanka...@workday.com>>
Reply-To: "user@ignite.apache.org" 
mailto:user@ignite.apache.org>>
Date: Friday, May 13, 2016 at 10:22 PM
To: "user@ignite.apache.org" 
mailto:user@ignite.apache.org>>
Subject: Custom GridSecurityProcessor plugin question

Hi

I following the instructions in 
http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/
 and implemented a custom GridSecurityProcessor plugin.  I got Ignite to 
recognize the custom provider and the provider is returning my custom 
GridSecurityProcessor like this:

@Nullable
@Override
@SuppressWarnings("unchecked")
public  T createComponent(PluginContext ctx, Class cls) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
called for class " + cls.toString());
if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning TenantGroupSecurityProcessor");
return (T) new TenantGroupSecurityProcessor();
}
else {
System.out.println("TenantGroupSecurityPluginProvider:createComponent 
returning null");
return null;
}
}

All is fine when the first node starts up.  When the second node starts up, 
TenantGroupSecurityProcessor.authenticateNode does not get called, but 
TenantGroupSecurityProcessor.validateNode gets called which is implemented like 
this:


@Nullable
@Override
public IgniteNodeValidationResult validateNode(ClusterNode node) {
System.out.println("TenantGroupSecurityProcessor:validateNode called");
return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access 
Denied");
}


Because of this, the second node is unable to join the cluster and it dies.

[22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: 
GridManagerAdapter [enabled=true, 
name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
clientReconnectDisabled=false]
  at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
  at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
  at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
  at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
  at 
o

Re: Ignite Aggregation query

2016-05-16 Thread Dmitriy Setrakyan
Ignite SQL queries are ANSI-99 compliant and do support “group-by” clause.
I think this is the most natural way to achieve your use case.

You can find more information on Ignite SQL queries here:
https://apacheignite.readme.io/docs/sql-queries

D.

On Mon, May 16, 2016 at 11:41 AM, diopek  wrote:

> As side note, currently when we do such aggregation using Oracle database,
> we
> put all the keys for the records that needs to be aggregated into some
> session based global temp table and do a join with original table. What is
> the best way to achieve such aggregation using Ignite?
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Aggregation-query-tp4968p4971.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Ignite Aggregation query

2016-05-16 Thread diopek
As side note, currently when we do such aggregation using Oracle database, we
put all the keys for the records that needs to be aggregated into some
session based global temp table and do a join with original table. What is
the best way to achieve such aggregation using Ignite? 



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


Re: Get client node instance

2016-05-16 Thread Igor Sapego
Arthi,

Well, there would be significant performance gain if you would
not start new client process for every request and then terminate it
but rather start node once in the same process that currently starts
new process. I'm not sure if it's possible for you. What is the language
of the application that starts C++ client now?


Best Regards,
Igor

On Mon, May 16, 2016 at 8:48 PM, arthi 
wrote:

> Hi Igor,
>
> we invoke it by some other application every time the user needs to make
> request and then
> its terminated
>
> Thanks,
> Arthi
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Get-client-node-instance-tp4897p4967.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Ignite Deadlock

2016-05-16 Thread levaly
Unfortunately, I don't have the problematic instance running anymore, so I
cannot provide the logs or thread dumps.

I will wait for a week for release of version 1.6, and I hope it will
resolve this issue.
If I manage to reproduce the problem, I will add the logs.

Thanks.



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


Ignite Aggregation query

2016-05-16 Thread diopek
Currently we need to aggregate (group by) data which is distributed on Ignite
partitioned cache.
What is the best practice do such aggregation on such data grid,
For example, by passing SQL group by clause as scanQuery  or using compute
affinityRun or mapReduce etc. Please advise. Thanks



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


Re: Get client node instance

2016-05-16 Thread arthi
Hi Igor,

we invoke it by some other application every time the user needs to make
request and then
its terminated

Thanks,
Arthi



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


Re: Get client node instance

2016-05-16 Thread Igor Sapego
Arthi,

It seems to me like we have some misunderstanding here.
Let me provide my understanding of your usecase so you could
correct me if I'm wrong.

You have the client application which is written in C++ and has
to handle multiple concurrent requests from multiple users.

Now, do you invoke the process of your application once and
use it for multiple requests or do you invoke it by some other
application every time you user needs to make request and then
its terminated?

Best Regards,
Igor

On Mon, May 16, 2016 at 7:08 PM, arthi 
wrote:

> Hi Igor,
>
> Yes, I can, but, how do I get handle to the client node instance when a new
> user request comes in?
> Each user request invokes the C++ dll.
>
> Thanks,
> Arthi
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Get-client-node-instance-tp4897p4963.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Unexpected performance issue with SQL query followed by error

2016-05-16 Thread Alexei Scherbakov
Hi,

I think your query should be rewritten for correct index usage.
Ignite has some known pitfalls concerning index usage [1].
Also, join order is sensitive to index configuration.
FIrst specify joins using indexes.

Could you provide your business model pojos and current indexes
configuration?

[1]
https://apacheignite.readme.io/docs/sql-queries#performance-and-usability-considerations

2016-05-09 14:23 GMT+03:00 jan.swaelens :

> I tried to defined the grouped indexes but I see no result on the explain
> plan nor on the actual run. This must mean that either I am doing something
> wrong or that something is going wrong.
>
> First attempt I annotated the fields on the objects, for example an extract
> of the Activity pojo:
>
> //** Value for activityId. */
> @QuerySqlField(orderedGroups={@QuerySqlField.Group(name =
> "Activity_idx", order = 0, descending = true)})
> private long activityId;
>
> /** Value for realizationId. */
> @QuerySqlField(orderedGroups={@QuerySqlField.Group(name =
> "Activity_idx", order = 1, descending = true)})
> private Long realizationId;
>
> /** Value for kernelId. */
> @QuerySqlField(orderedGroups={@QuerySqlField.Group(name =
> "Activity_idx", order = 2, descending = true)})
> private Long kernelId;
>
> /** Value for removefromworklist. */
> @QuerySqlField(orderedGroups={@QuerySqlField.Group(name =
> "Activity_idx", order = 3, descending = true)})
> private boolean removefromworklist;
>
> /** Value for lastactivityId. */
> @QuerySqlField(orderedGroups={@QuerySqlField.Group(name =
> "Activity_idx", order = 4, descending = true)})
> private Long lastactivityId;/
>
> Since that did not work I also had an attempt to define it on the cache
> configuration (query entity):
>
> /QueryIndex gIdx = new QueryIndex();
> idxs.add(gIdx);
> gIdx.setName("Activity_idx");
>
> Collection gFields = new ArrayList<>();
> gFields.add("activityId");
> gFields.add("realizationId");
> gFields.add("kernelId");
> gFields.add("removefromworklist");
> gFields.add("lastactivityId");
> gIdx.setFieldNames(gFields, true);/
>
>
> Could it be that the field aliases I use are causing this? Or something
> else
> I am missing?
>
> tx
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Unexpected-performance-issue-with-SQL-query-followed-by-error-tp4726p4846.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 

Best regards,
Alexei Scherbakov


Re: Get client node instance

2016-05-16 Thread Igor Sapego
Arthi,

Why do you create one client node per user request? Can you create
a node on application start and then just use this node instance when
you need to make a request?


Best Regards,
Igor

On Mon, May 16, 2016 at 6:41 PM, arthi 
wrote:

> Hi Igor,
>
> this is my usecase - I use the ignite data grid to store my business data
> in
> memory. My client application needs to run SQL queries on this data. Every
> client request in the application will be translated to multiple SQL
> queries. The application needs to support 400-500 concurrent users.
> My client application is written in C++.
>
> My grid can grow to have terabytes of data across 30-40 server nodes.
>
> The SLA for the one request/response is < 30 sec. My SQL queries come back
> faster, its the ignite client joining time I would want to reduce. I create
> one client node per user request and that instance is used to execute the
> multiple SQL queries to get the response.
>
> what is the best that is possible in terms of client join time? Can it be
> <1-2 secs? My servers are Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with
> 256GB RAM and 40 cores, the n/w between the nodes is high speed too.
>
> Thanks,
> Arthi
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Get-client-node-instance-tp4897p4960.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Get client node instance

2016-05-16 Thread arthi
Hi Igor,

Yes, I can, but, how do I get handle to the client node instance when a new
user request comes in?
Each user request invokes the C++ dll.

Thanks,
Arthi



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


Re: Get client node instance

2016-05-16 Thread Igor Sapego
I mean startup of the client application.

Best Regards,
Igor

On Mon, May 16, 2016 at 7:18 PM, Igor Sapego  wrote:

> Arthi,
>
> Why do you create one client node per user request? Can you create
> a node on application start and then just use this node instance when
> you need to make a request?
>
>
> Best Regards,
> Igor
>
> On Mon, May 16, 2016 at 6:41 PM, arthi  > wrote:
>
>> Hi Igor,
>>
>> this is my usecase - I use the ignite data grid to store my business data
>> in
>> memory. My client application needs to run SQL queries on this data. Every
>> client request in the application will be translated to multiple SQL
>> queries. The application needs to support 400-500 concurrent users.
>> My client application is written in C++.
>>
>> My grid can grow to have terabytes of data across 30-40 server nodes.
>>
>> The SLA for the one request/response is < 30 sec. My SQL queries come back
>> faster, its the ignite client joining time I would want to reduce. I
>> create
>> one client node per user request and that instance is used to execute the
>> multiple SQL queries to get the response.
>>
>> what is the best that is possible in terms of client join time? Can it be
>> <1-2 secs? My servers are Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with
>> 256GB RAM and 40 cores, the n/w between the nodes is high speed too.
>>
>> Thanks,
>> Arthi
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-ignite-users.70518.x6.nabble.com/Get-client-node-instance-tp4897p4960.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>


Re: Get client node instance

2016-05-16 Thread arthi
Hi Igor,

this is my usecase - I use the ignite data grid to store my business data in
memory. My client application needs to run SQL queries on this data. Every
client request in the application will be translated to multiple SQL
queries. The application needs to support 400-500 concurrent users.
My client application is written in C++.

My grid can grow to have terabytes of data across 30-40 server nodes. 

The SLA for the one request/response is < 30 sec. My SQL queries come back
faster, its the ignite client joining time I would want to reduce. I create
one client node per user request and that instance is used to execute the
multiple SQL queries to get the response.

what is the best that is possible in terms of client join time? Can it be
<1-2 secs? My servers are Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with
256GB RAM and 40 cores, the n/w between the nodes is high speed too.

Thanks,
Arthi



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


Re: Custom GridSecurityProcessor plugin question

2016-05-16 Thread Denis Magda
Hi Anand,

GridSecurityProcessor.authenticateNode(…) has to be called on your side. Please 
double check that GridSecurityProcessor.enabled() returns true. If it returns 
true then your GridSecurityProcessor will be registered in 
GridDiscoveryManager.start() method.

If this doesn’t happen please debug GridDiscoveryManager.start() method at the 
place when discovery SPI authenticator is set and places where 
DiscoverySpiNodeAuthenticator.authenticateNode is used and share the results 
with us.

—
Denis

> On May 16, 2016, at 12:01 AM, Anand Kumar Sankaran 
>  wrote:
> 
> I went past this.  Turns out if everything is ok, validateNode has to return 
> null L.
>  
> That brings me to another question.  validateNode callback only provides us 
> with the ClusterNode. We were thinking the information needed to let a node 
> join the cluster or not would be part of a custom SecurityCredentials object, 
> which is available only at the authenticateNode level and not the 
> validateNode.
>  
> If I want to prevent a node from joining the cluster, and if validateNode is 
> the way to do it, should I add custom node attributes to ClusterNode and use 
> that information?
>  
> --
> thanks
>  
> anand
>  
> From: Anand Kumar Sankaran 
> Reply-To: "user@ignite.apache.org" 
> Date: Friday, May 13, 2016 at 10:22 PM
> To: "user@ignite.apache.org" 
> Subject: Custom GridSecurityProcessor plugin question
>  
> Hi
>  
> I following the instructions in 
> http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/ 
> 
>  and implemented a custom GridSecurityProcessor plugin.  I got Ignite to 
> recognize the custom provider and the provider is returning my custom 
> GridSecurityProcessor like this:
>  
> @Nullable
> @Override
> @SuppressWarnings("unchecked")
> public  T createComponent(PluginContext ctx, Class cls) {
> System.out.println("TenantGroupSecurityPluginProvider:createComponent 
> called for class " + cls.toString());
> if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
> System.out.println("TenantGroupSecurityPluginProvider:createComponent 
> returning TenantGroupSecurityProcessor");
> return (T) new TenantGroupSecurityProcessor();
> }
> else {
> System.out.println("TenantGroupSecurityPluginProvider:createComponent 
> returning null");
> return null;
> }
> }
>  
> All is fine when the first node starts up.  When the second node starts up, 
> TenantGroupSecurityProcessor.authenticateNode does not get called, but 
> TenantGroupSecurityProcessor.validateNode gets called which is implemented 
> like this:
>  
> @Nullable
> @Override
> public IgniteNodeValidationResult validateNode(ClusterNode node) {
> System.out.println("TenantGroupSecurityProcessor:validateNode called");
> return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access 
> Denied");
> }
>  
>  
> Because of this, the second node is unable to join the cluster and it dies.
>  
> [22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
> reconCnt=10, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
>   at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
>   at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1485)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
>   at org.apache.ignite.Ignition.start(Ignition.java:346)
>   at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Access Denied
>

Re: Ignite Deadlock

2016-05-16 Thread Denis Magda
Hi,

First of all, what is the reason of why you need to interact with caches using 
JNI? Probably we could recommend you some other approach that is simple and 
safer.

Second, it’s hard to tell why ignite1 gets into a deadlock without the 
following:
- logs from all the nodes;
- thread dumps of all the nodes.
- configuration you use.

Please this info if you need an assistance.

Finally, I would recommend switching to ignite 1.5 or wait for a week or so for 
ignite 1.6.

—
Denis

> On May 15, 2016, at 3:59 PM, John  wrote:
> 
> 
> Hi.
> 
> I have 2 ignite instances that use IgniteCache to store some cache values.
> The cache is configured with replication on, so both instances have the same 
> data. 
> 
> Since I am running JNI code to get the cache values, it sometimes (on rare 
> occasions) crashes, which in turn kills the ignite instance. I have an 
> external script that starts the failed ignite instance as soon as it crashes.
> 
> I was expecting the non crashed ignite instance (ignite1) to quickly update 
> the crashed instance (ignite2) and both to continue working as usual. 
> 
> This was exactly what was going on for a few days, until one time, ignite2 
> has crashed, and ignite1 seems to get into a deadlock. As soon as ignite2 got 
> back up, it failed to recognize ignite1, and failed to replicate from it. Any 
> client connections to ignite instances stopped working as well.
> 
> I am seeing this error in the log:
> 
> Failed to wait for initial partition map exchange. Possible reasons are: 
>   ^-- Transactions in deadlock.
>   ^-- Long running transactions (ignore if this is the case).
>   ^-- Unreleased explicit locks.
> 
> and also:
> 
> Local node has detected failed nodes and started cluster-wide procedure. To 
> speed up failure detection please see 'Failure Detection' section under 
> javadoc for 'TcpDiscoverySpi'
> 
> 
> I am using ignite v1.4
> Any suggestions or ideas will be highly appreciated.
> 
> Thanks!
> 



Re: Clear cache from Visor throws an exception

2016-05-16 Thread Denis Magda
Have you tried the latest nightly? Has the issue disappeared on your side?

—
Denis

> On May 11, 2016, at 9:23 PM, zshamrock  wrote:
> 
> Could it be because of the cache store implementation classes I use? That
> some of them trigger this exception?
> 
> I will try the latest nightly build you've mentioned, and report you about
> the results.
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Clear-cache-from-Visor-throws-an-exception-tp4848p4880.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.



Re: Get client node instance

2016-05-16 Thread Igor Sapego
Hi Arthi,

In current implementation, node instance (i.e. Ignite instance) can not be
shared between different processes. Can you describe your use case
a bit more? Which start up time would be acceptable in your case? Are you
starting client node on the startup of the application or are you starting
it
whenever you need to make requests?

Best Regards,
Igor

On Mon, May 16, 2016 at 7:05 AM, arthi 
wrote:

> Hi Igor,
>
> Is this possible?
>
> My C++ client application will need to create multiple requests to access
> the data grid for executing SQL queries.
>
> There could be 400-500 concurrent requests on high load. If I could re-use
> the same client node instance (or may balance across a set of client node
> instances), my topology will be stable. I will not be altering the topology
> for every incoming request for a new client. The time taken to join the
> cluster as a client takes 4-5 seconds, and on concurrent load, even greater
> (10-20 seconds).
>
> will shared memory help? Can you please provide sample code to do this?
>
> Please advice.
>
> Thanks,
> Arthi
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Get-client-node-instance-tp4897p4946.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>


Re: Ignite Still waiting for initial partition map exchange problem

2016-05-16 Thread Denis Magda
Hi Kevin,

> My first observation is that, the client side keeps running without doing any 
> write through actions to the database;

Client does write-through to a database only if it’s a coordinator of an Ignite 
transaction or writes to a transaction cache. In other cases server nodes are 
responsible for writing data to the storage. How do you detect that there are 
no updates into the storage? Don’t you use write-behind mode that postpones 
sync with database?

Second, I cannot get into the cmd interface to check cache or node information 
(running ./ignitevisorcmd.sh),

Try to use the same configuration file that is used by your server nodes. If 
this doesn’t help create thread dumps and check where the visor is hanging.

Also I see that you specified big Java heap size. Such big heap size can lead 
to long GC pauses and to the situation when a node is kicked out of the 
cluster. If you expect to store more than 10 GB of cache data on every node 
then I would suggest switching to off-heap caches [1] and tune GC properly [2]. 
In addition refer to similar discussions [3] and [4]

[1] https://apacheignite.readme.io/docs/off-heap-memory
[2]  
https://apacheignite.readme.io/docs/jvm-and-system-tuning#jvm-tuning-for-clusters-with-off_heap-caches
 

[3] 
http://apache-ignite-users.70518.x6.nabble.com/Cluster-size-for-Terrabytes-of-data-tp4857.html
 

[4] 
http://apache-ignite-users.70518.x6.nabble.com/Slow-data-loading-and-high-very-memory-usage-issues-tp4798.html
 


—
Denis

> On May 11, 2016, at 4:11 PM, Zhengqingzheng  wrote:
> 
> Hi Vladimir,
> The warning message disappeared. However, there are some other abnormal 
> behavior occurred.
> My first observation is that, the client side keeps running without doing any 
> write through actions to the database;
>  
> Second, I cannot get into the cmd interface to check cache or node 
> information (running ./ignitevisorcmd.sh),
> After typing open command, and select the default ‘0’ configure file, It will 
> stop at:
> [20:50:55]
> [20:50:55] Quiet mode.
> [20:50:55]   ^-- Logging to file 
> '/opt/apache-ignite-bin/work/log/ignite-dc2a77e5.0.log'
> [20:50:55]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or 
> "-v" to ignite.{sh|bat}
> [20:50:55]
> [20:50:55] OS: Linux 3.13.0-24-generic amd64
> [20:50:55] VM information: OpenJDK Runtime Environment 1.7.0_95-b00 Oracle 
> Corporation OpenJDK 64-Bit Server VM 24.95-b01
> [20:50:55] Configured plugins:
> [20:50:55]   ^-- None
> [20:50:55]
> [20:50:55] Security status [authentication=off, tls/ssl=off]
>  
> No further information occurred
>  
> The latest log file shows information like this:
> [20:49:28,368][INFO][main][IgniteKernal]
>  
> >>>__   
> >>>   /  _/ ___/ |/ /  _/_  __/ __/ 
> >>>  _/ // (7 7// /  / / / _/   
> >>> /___/\___/_/|_/___/ /_/ /___/  
> >>>
> >>> ver. 1.5.0-final#20151229-sha1:f1f8cda2
> >>> 2015 Copyright(C) Apache Software Foundation
> >>>
> >>> Ignite documentation: http://ignite.apache.org 
>  
> [20:49:28,370][INFO][main][IgniteKernal] Config URL: 
> file:/opt/apache-ignite-bin/config/default-config.xml
> [20:49:28,370][INFO][main][IgniteKernal] Daemon mode: off
> [20:49:28,371][INFO][main][IgniteKernal] OS: Linux 3.13.0-24-generic amd64
> [20:49:28,371][INFO][main][IgniteKernal] OS user: root
> [20:49:28,371][INFO][main][IgniteKernal] Language runtime: Java Platform API 
> Specification ver. 1.7
> [20:49:28,371][INFO][main][IgniteKernal] VM information: OpenJDK Runtime 
> Environment 1.7.0_95-b00 Oracle Corporation OpenJDK 64-Bit Server VM 24.95-b01
> [20:49:28,372][INFO][main][IgniteKernal] VM total memory: 44.0GB
> [20:49:28,372][INFO][main][IgniteKernal] Remote Management [restart: on, 
> REST: on, JMX (remote: on, port: 49115, auth: off, ssl: off)]
> [20:49:28,372][INFO][main][IgniteKernal] IGNITE_HOME=/opt/apache-ignite-bin
> [20:49:28,372][INFO][main][IgniteKernal] VM arguments: [-Xms1g, -Xmx1g, 
> -XX:+AggressiveOpts, -XX:MaxPermSize=256m, -DIGNITE_QUIET=true, 
> -DIGNITE_SUCCESS_FILE=/opt/apache-ignite-bin/work/ignite_success_aecbd7da-db6b-4e53-ae30-cde30062da2e,
>  -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49115, 
> -Dcom.sun.management.jmxremote.authenticate=false, 
> -Dcom.sun.management.jmxremote.ssl=false, 
> -DIGNITE_HOME=/opt/apache-ignite-bin, -DIGNITE_PROG_NAME=./ignite.sh, 
> -Xmx48g, -Xms46g]
> [20:49:28,372][INFO][main][IgniteKernal] Configured caches 
> ['ignite-marshaller-sys-cache', 'ignite-sys-cache', 
> 'ignite-atomics-sys-cache', 'default']
> [20:49:28,375][INFO][main][IgniteKernal] 3-rd party licenses can be found at: 
> /opt/apache-ignite-bin/l

Re: Client Connection to Ignite takes time

2016-05-16 Thread Denis Magda
Hi Arthi,

Yes, there is a dedicated documentation created for Ignite C++ API. Please 
refer to it for more details:
https://apacheignite-cpp.readme.io/docs/ 


—
Denis

> On May 11, 2016, at 12:01 PM, arthi  
> wrote:
> 
> Thanks Denis.
> 
> I think we should try this. Is there an C++ API we could use to get the
> ignite client node instance from the  grid to run SQL queries?
> 
> Thanks,
> Arthi
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Client-Connection-to-Ignite-takes-time-tp4739p4870.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.



Re: Cache Refresh Options

2016-05-16 Thread Murthy Kakarlamudi
Awesome. Thanks much Pavel.
On May 16, 2016 5:01 AM, "Pavel Tupitsyn"  wrote:

> Ignite does have built-in scheduling capabilities, please see
> https://apacheignite.readme.io/docs/cron-based-scheduling
>
> Pavel.
>
> On Mon, May 16, 2016 at 11:52 AM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
>> Hi,
>>
>> Ignite has no build in scheduling capabilities. However, it's very easy
>> to add them to your application.
>> Just deploy service[1] to your server node and use something
>> like ScheduledThreadPoolExecutor
>> for running load task on schedule.
>>
>> Did this help?
>>
>> [1] https://apacheignite.readme.io/docs/service-grid
>>
>>
>> 2016-05-14 0:03 GMT+03:00 Murthy Kakarlamudi :
>>
>>> Hi,
>>>What are my options to refresh ignite cache from underlying
>>> persistent store on a scheduled basis. My use case is I have a server node
>>> that loads data from underlying store to cache and I have a couple of
>>> client nodes that perform computations reading cache data. I understand
>>> using Eviction Policy and read-through, my client nodes can get the latest
>>> data, but I cannot afford a database call during my computation.
>>>
>>> As my computation happens during business hours, I was wondering if I
>>> can refresh my cache during non-business hours. Does Ignite have any
>>> support for such scheduled refreshes?
>>>
>>> Thanks,
>>> Murthy.
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov
>>
>
>


Re: Cache Refresh Options

2016-05-16 Thread Murthy Kakarlamudi
It sure does. Thanks.
On May 16, 2016 4:52 AM, "Alexei Scherbakov" 
wrote:

> Hi,
>
> Ignite has no build in scheduling capabilities. However, it's very easy to
> add them to your application.
> Just deploy service[1] to your server node and use something
> like ScheduledThreadPoolExecutor
> for running load task on schedule.
>
> Did this help?
>
> [1] https://apacheignite.readme.io/docs/service-grid
>
>
> 2016-05-14 0:03 GMT+03:00 Murthy Kakarlamudi :
>
>> Hi,
>>What are my options to refresh ignite cache from underlying persistent
>> store on a scheduled basis. My use case is I have a server node that loads
>> data from underlying store to cache and I have a couple of client nodes
>> that perform computations reading cache data. I understand using Eviction
>> Policy and read-through, my client nodes can get the latest data, but I
>> cannot afford a database call during my computation.
>>
>> As my computation happens during business hours, I was wondering if I can
>> refresh my cache during non-business hours. Does Ignite have any support
>> for such scheduled refreshes?
>>
>> Thanks,
>> Murthy.
>>
>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>


Re: Cache Refresh Options

2016-05-16 Thread Alexei Scherbakov
Cool, didn't knew what

2016-05-16 12:00 GMT+03:00 Pavel Tupitsyn :

> Ignite does have built-in scheduling capabilities, please see
> https://apacheignite.readme.io/docs/cron-based-scheduling
>
> Pavel.
>
> On Mon, May 16, 2016 at 11:52 AM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
>> Hi,
>>
>> Ignite has no build in scheduling capabilities. However, it's very easy
>> to add them to your application.
>> Just deploy service[1] to your server node and use something
>> like ScheduledThreadPoolExecutor
>> for running load task on schedule.
>>
>> Did this help?
>>
>> [1] https://apacheignite.readme.io/docs/service-grid
>>
>>
>> 2016-05-14 0:03 GMT+03:00 Murthy Kakarlamudi :
>>
>>> Hi,
>>>What are my options to refresh ignite cache from underlying
>>> persistent store on a scheduled basis. My use case is I have a server node
>>> that loads data from underlying store to cache and I have a couple of
>>> client nodes that perform computations reading cache data. I understand
>>> using Eviction Policy and read-through, my client nodes can get the latest
>>> data, but I cannot afford a database call during my computation.
>>>
>>> As my computation happens during business hours, I was wondering if I
>>> can refresh my cache during non-business hours. Does Ignite have any
>>> support for such scheduled refreshes?
>>>
>>> Thanks,
>>> Murthy.
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov
>>
>
>


-- 

Best regards,
Alexei Scherbakov


Re: Cache Refresh Options

2016-05-16 Thread Pavel Tupitsyn
Ignite does have built-in scheduling capabilities, please see
https://apacheignite.readme.io/docs/cron-based-scheduling

Pavel.

On Mon, May 16, 2016 at 11:52 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:

> Hi,
>
> Ignite has no build in scheduling capabilities. However, it's very easy to
> add them to your application.
> Just deploy service[1] to your server node and use something
> like ScheduledThreadPoolExecutor
> for running load task on schedule.
>
> Did this help?
>
> [1] https://apacheignite.readme.io/docs/service-grid
>
>
> 2016-05-14 0:03 GMT+03:00 Murthy Kakarlamudi :
>
>> Hi,
>>What are my options to refresh ignite cache from underlying persistent
>> store on a scheduled basis. My use case is I have a server node that loads
>> data from underlying store to cache and I have a couple of client nodes
>> that perform computations reading cache data. I understand using Eviction
>> Policy and read-through, my client nodes can get the latest data, but I
>> cannot afford a database call during my computation.
>>
>> As my computation happens during business hours, I was wondering if I can
>> refresh my cache during non-business hours. Does Ignite have any support
>> for such scheduled refreshes?
>>
>> Thanks,
>> Murthy.
>>
>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>


Re: Cache Refresh Options

2016-05-16 Thread Alexei Scherbakov
Hi,

Ignite has no build in scheduling capabilities. However, it's very easy to
add them to your application.
Just deploy service[1] to your server node and use something
like ScheduledThreadPoolExecutor
for running load task on schedule.

Did this help?

[1] https://apacheignite.readme.io/docs/service-grid


2016-05-14 0:03 GMT+03:00 Murthy Kakarlamudi :

> Hi,
>What are my options to refresh ignite cache from underlying persistent
> store on a scheduled basis. My use case is I have a server node that loads
> data from underlying store to cache and I have a couple of client nodes
> that perform computations reading cache data. I understand using Eviction
> Policy and read-through, my client nodes can get the latest data, but I
> cannot afford a database call during my computation.
>
> As my computation happens during business hours, I was wondering if I can
> refresh my cache during non-business hours. Does Ignite have any support
> for such scheduled refreshes?
>
> Thanks,
> Murthy.
>



-- 

Best regards,
Alexei Scherbakov


Re: Eviction Events with offheap values

2016-05-16 Thread Alexei Scherbakov
Andrey, thanks for the clarification.

Abraham, it seems EvictionPolicy is not appropriate solution for your case.
BTW, why user session expiration logic is related to cache size ?
In case user sessions expire by timeout the more appropriate solution would
be listening to
EVT_CACHE_OBJECT_EXPIRED event.
You can also set eager expiration by calling
CacheConfiguration.setEagerTtl(true)
to make Ignite expire values automatically.

Did this help?


2016-05-13 19:49 GMT+03:00 Andrey Gura :

> Alexei, Abraham,
>
> Eviction policy configuration doesn't make sense for OFFHEAP_TIERED mode.
> Eviction policy works only for on heap entries in order to evict entries to
> offheap.
>
> For eviction of entries from offheap memory Ignite internaly uses other
> LRU eviction policy and there is no way to change this behaviour via
> configuration.
>
> On Thu, May 12, 2016 at 7:14 PM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
>> Hi,
>>
>> I was not able to reproduce your case.
>> In my test I have correct old value on eviction event.
>> Please provide a reproducer.
>>
>> BTW: what are you trying to accomplish? Generally events are not very
>> good for cluster performance and may not be delivered in case of the
>> listener node failure.
>>
>> 2016-05-10 9:26 GMT+03:00 abraham :
>>
>>> Hi,
>>>
>>> I am re-posting an earlier message to which I did not get any replies
>>> because I was not subscribed to the mailing list:
>>>
>>> I am trying to get the values from the eviction events. This works fine
>>> with
>>> the ONHEAP_TIERED version but not with OFFHEAP_VALUES and OFFHEAP_TIERED
>>> -
>>> in that cases the hasOldValue is true but the actual value is null.
>>>
>>> What we are trying to accomplish is to persist entries to a database only
>>> when they either get removed, expired or evicted because the max cache
>>> size
>>> is reached and it looks like those events are the only way to accomplish
>>> this.
>>>
>>> A quick glance at the code would suggest that in the
>>> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager one
>>> could replace line 708 from
>>>
>>> CacheObject oldVal = recordable ? entry.rawGet() : null;
>>>
>>> to
>>>
>>> CacheObject oldVal = recordable ? entry.rawGetOrUnmarshal(false) : null;
>>>
>>> to get the values attached to the events. Would that work?
>>>
>>> Thanks,
>>>
>>> Abraham
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-ignite-users.70518.x6.nabble.com/Eviction-Events-with-offheap-values-tp4853.html
>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov
>>
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>



-- 

Best regards,
Alexei Scherbakov


Re: Data Nucleus plugin extensions aren't loaded by the grid class loader

2016-05-16 Thread georgeg
I've attached the log from the node, it contains also the exception
apache_ignite_jdo_error.txt

  

The executed code in the task is:

.
//properties with persistence manager factory class and database connection 

Properties properties = new Properties();

properties.setProperty("javax.jdo.PersistenceManagerFactoryClass",

"org.datanucleus.api.jdo.JDOPersistenceManagerFactory");
properties.setProperty("javax.jdo.option.ConnectionDriverName",
"com.mysql.jdbc.Driver");

//here add other properties for the database connection as user and host,
but for reproducing the error not necessary

PersistenceManagerFactory persistenceManagerFactory = JDOHelper

.getPersistenceManagerFactory(properties);


The data nucleus jars are copied in the libs folder of the node, there is
one node and the task is deployed from eclipse environment.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Data-Nucleus-plugin-extensions-aren-t-loaded-by-the-grid-class-loader-tp4928p4947.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.