[jira] [Created] (IGNITE-2425) BinaryObject.readField() called for an object Java array field reads objects class

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2425:
---

 Summary: BinaryObject.readField() called for an object Java array 
field reads objects class 
 Key: IGNITE-2425
 URL: https://issues.apache.org/jira/browse/IGNITE-2425
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Denis Magda
 Fix For: 1.6
 Attachments: ExampleNodeStartup.java

If there is a {{BinaryObject}} that has a field that refers to an array of some 
custom user objects then during the time {{BinaryObject.field()}} is called the 
class of this custom will be read. This can lead to {{ClassNotFoundException}} 
on a server side or another ones related.

In the attach example the following issue is demonstrated using 
{{BinaryObjectBuilder}} which class is not listed in classnames.properties.

 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2426) Document optimisitic (deadlock-free) transactions on readme.io

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2426:
---

 Summary: Document optimisitic (deadlock-free) transactions on 
readme.io
 Key: IGNITE-2426
 URL: https://issues.apache.org/jira/browse/IGNITE-2426
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Denis Magda
Priority: Critical
 Fix For: 1.6


There is a lack of documentation on how optimistic & serializable transactions 
work.

Basic documentation has to be added covering some specific cases in addition.

As an example, the test attached demonstrates the following.

Both tasks update cache with put operations only without reading and keeping 
entries's versions cause there is no any cache.get/getAll calls as a part of 
the transaction.
Each transaction has it's unique ID. So at the commit time when one transaction 
B tries to update an entry locking it before and sees that the entry is locked 
by some transaction A, started earlier (have smaller transaction ID), then 
transaction B will just wait until the lock is released and can proceed with 
the commit later. If this repeats for every entry of transactions and we 
haven't detected any conflict then both transactions succeeds. This is exactly 
what happens sometimes in your test.

However, if the transactions were using cache.get or related operations then 
during the commit time both transactions would be checking entry versions in 
addition before proceeding with the commit. In general if an entry version at 
commit time is different to the entry version at get time then a transaction 
fails. To see this in practice use cache.getAndPut() instead of cache.put() in 
the code. After applying this modification one of the transactions will always 
fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

回复: Re: about CacheTypeMetadata

[李玉珏]

Hi:

On the sample code, you only modify the XML part, the Java code section is not 
modified, omitted.

Sent from Mail Master



在2016年01月20日 17:41 ，Denis Magda写道：

Updated the docs. Thanks for pointing out.

On 1/16/2016 12:19 PM, 李玉珏@163 wrote:
> Hi：
>
> In the 1.5.0 version, I found that CacheTypeMetadata was abandoned and
> replaced by QueryEntity.
>
> I find that two classes of related instructions exist in the manual:
> https://apacheignite.readme.io/docs/sql-queries
> https://apacheignite.readme.io/docs/cache-queries
>
> I suggest deleting the instructions and sample code for
> CacheTypeMetadata, so as not to confuse the developer,
> CacheTypeMetadata only exists for the sake of backward compatibility.
>

Re: 回复: Re: about CacheTypeMetadata

[Denis Magda]

I've doubled checked both the pages and didn't find any usage of 
CacheTypeMetadata in Java code.


Please point out to a particular document and the code.


On 1/21/2016 11:55 AM, 李玉珏 wrote:

Hi:

On the sample code, you only modify the XML part, the Java code 
section is not modified, omitted.


Sent from Mail Master


在2016年01月20日 17:41 ，Denis Magda 写道：

Updated the docs. Thanks for pointing out.

On 1/16/2016 12:19 PM, 李玉珏@163 wrote:
> Hi：
>
> In the 1.5.0 version, I found that CacheTypeMetadata was
abandoned and
> replaced by QueryEntity.
>
> I find that two classes of related instructions exist in the
manual:
> https://apacheignite.readme.io/docs/sql-queries
> https://apacheignite.readme.io/docs/cache-queries
>
> I suggest deleting the instructions and sample code for
> CacheTypeMetadata, so as not to confuse the developer,
> CacheTypeMetadata only exists for the sake of backward
compatibility.
>

MyBatis and Apache Ignite integration

[dmagda]

Hi MyBatis community!

I'm a committer and PMC of Apache Ignite [1] project and writing to you on 
behalf of our community (+ CC-ed) to discuss an integration between our 
projects that should be useful for both sides.

In short, Apache Ignite is a high-performance, integrated and distributed 
in-memory platform for computing and transacting on large-scale data sets 
in real-time, orders of magnitude faster than possible with traditional 
disk-based or flash technologies.
Inside of our community we see a growing interest in a field of usage 
MyBatis along with Apache Ignite. There are use cases when developers/users 
wants to use Apache Ignite as MyBatis second level cache. Since such an 
interest is growing constantly we think that it's a right time to make this 
happen.

As I see MyBatis already supports second level cache for Redis, Hazelcast 
and Ehcache.

How do you usually add such components? Were they added by MyBatis guys or 
were developed by guys from Redis, Hazelcast, etc.? 

[1] https://ignite.apache.org/

Regards,
Denis

[jira] [Created] (IGNITE-2427) [Test] [Rare] CacheSerializableTransactionsTest.testGetRemoveTxNearCache2

[Vladimir Ershov (JIRA)]

Vladimir Ershov created IGNITE-2427:
---

 Summary: [Test] [Rare] 
CacheSerializableTransactionsTest.testGetRemoveTxNearCache2
 Key: IGNITE-2427
 URL: https://issues.apache.org/jira/browse/IGNITE-2427
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Vladimir Ershov


Test fails very rare:
{noformat}
junit.framework.AssertionFailedError: expected:<3> but was:<1>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:86)
at junit.framework.TestCase.assertEquals(TestCase.java:253)
at 
org.apache.ignite.internal.processors.cache.CacheSerializableTransactionsTest.checkValue(CacheSerializableTransactionsTest.java:4187)
at 
org.apache.ignite.internal.processors.cache.CacheSerializableTransactionsTest.checkValue(CacheSerializableTransactionsTest.java:4171)
at 
org.apache.ignite.internal.processors.cache.CacheSerializableTransactionsTest.getRemoveTx(CacheSerializableTransactionsTest.java:3308)
at 
org.apache.ignite.internal.processors.cache.CacheSerializableTransactionsTest.testGetRemoveTxNearCache2(CacheSerializableTransactionsTest.java:3205)
{nofromat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Binary ID mapper that uses a simple name of classes.

[Artem Shutak]

Dmitriy,

Out-of-the-box Ignite wil have 2 IdMappers:
- BinaryLowerCaseIdMapper - converts all of the characters in given string
to lower case and then calls hashCode() for it.
- BinaryStraightIdMapper - just calls hashCode() for given string (without
converting to lower case).

May be BinaryStraightIdMapper is not the best name for this mapper. Please,
suggest another one if you have.

I agree, that current design with BinaryNameMapper and BinaryIdMapper looks
a little bit complex, but I don't see a better option to support all things
described in my previous email. Dmitriy, If you have, please, describe your
design in the ticket.

Lets focus on names of mappers in this thread.

Thanks,
-- Artem --

On Thu, Jan 21, 2016 at 6:10 AM, Dmitriy Setrakyan 
wrote:

> Artem,
>
> My suggestion was that instead of having 3 id mappers that do almost the
> same thing, have 1 ID mapper with additional configuration properties.
>
> BTW, I still don’t get what a straight ID mapper means.
>
> D.
>
> On Wed, Jan 20, 2016 at 9:45 AM, Artem Shutak 
> wrote:
>
> > Dmitriy,
> >
> > BinaryStraightIdMapper - calculate hash code for given strings (do not
> > change given string and call hashCode() for it). It's simplest IdMapper.
> It
> > would be nice if we will have it out-of-the-box.
> >
> > Could you please describe your approach in more details? Keep in mind,
> that
> > BinaryIdMapper is already a part of public API and, theoretically, a user
> > can write your own mapper to map class names to IDs (if he will have
> > collisions for own classes) and custom mapper should know nothing about
> > "simpleName" and "lowerCase" properties (for custom implementation).
> >
> > Lets me try to clarify current approach. At first, names classes and
> fileds
> > are processed by BinaryNameMapper and then these processed names pass to
> > BinaryIdMapper for id calculation.
> >
> > Keep in mind the following:
> > 1. It have to work with .Net.
> > 2. it have to work without .Net and have to work with full name of
> classes
> > (to fix IGNITE-2191).
> > 3. By some reasons, Ignite write *typeName* (for some types or for all,
> not
> > sure) at binary metadata.
> >
> > To support 1 and 2 we cannot always write full name or simple name at
> > metadata. So, we have to have method like *String typeName(String
> > fullClassName)* that returns processed class name (we have the one on
> > BinaryNameMapper).
> >
> > I want to repeat that this design are consistent with .Net where we
> already
> > have NameMapper and IdMapper.
> >
> > Thnaks,
> > -- Artem --
> >
> > On Wed, Jan 20, 2016 at 7:58 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > Looks too busy.
> > >
> > > Why not just have one ID mapper with config properties, like
> > > isSimpleName(), isLowerCase()?
> > >
> > > Also, what is a straight ID mapper?
> > >
> > > D.
> > >
> > > On Wed, Jan 20, 2016 at 4:01 AM, Artem Shutak 
> > > wrote:
> > >
> > > > Dmitriy, thanks for reminding me about this thread.
> > > >
> > > > According to found issues in process of working on IGNITE-2191, it
> was
> > > > decided to add new entity BinaryNameMapper (in addition to
> > > BinaryIdMapper)
> > > > as a property of BinaryConfiguration. So, we will have the same
> > > > configuration as we already have for .Net.
> > > >
> > > > So, we need to confirm names for BinaryNameMapper and
> BinaryIdMapper. I
> > > > propose the following:
> > > >
> > > > - BinarySimpleNameMapper / SimpleClassNameBinaryNameMapper /
> > > > BinarySimpleClassNameMapper - returns simple name of class.
> > > > - BinaryFullNameMapper / BinaryNoopNameMapper / NoopBinaryNameMapper
> /
> > > > BinaryOriginalNameMapper / StraightBinaryNameMapper - returns name
> > > without
> > > > changes.
> > > > - BinaryLowerCaseIdMapper - it was BinaryInternalIdMapper.
> > > > - BinaryStraightIdMapper - calculate hash code for given strings.
> > > >
> > > > I would chose BinarySimpleClassNameMapper, BinaryOriginalNameMapper,
> > > > BinaryLowerCaseIdMapper and BinaryStraightIdMapper names.
> > > >
> > > > Thanks,
> > > > -- Artem --
> > > >
> > > > On Wed, Jan 20, 2016 at 1:46 AM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > > > Artem, what name do you plan to give to the BinaryInternalIdMapper?
> > > > >
> > > > > On Fri, Jan 15, 2016 at 1:52 AM, Artem Shutak <
> ashu...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > All Binary-related classes start from Binary. So, it's not
> > > consistent.
> > > > > >
> > > > > > We should chose between *BinarySimpleNameIdMapper* and
> > > > > > *BinarySimpleClassNameIdMapper*.
> > > > > >
> > > > > > Also, I'd like to move default *BinaryInternalIdMapper* to public
> > > > package
> > > > > > (that uses full class name) and rename him accordingly. Any
> > > objections?
> > > > > >
> > > > > > -- Artem --
> > > > > >
> > > > > > On Thu, Jan 14, 2016 at 11:21 PM, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >
> > > > > > wrote:
> > > > > 

Re: supporting collection indexes

[Yakov Zhdanov]

This may be a good feature, but I don't think it will be widely used. I
understand that Ignite users want to have their objects stored exactly in
the format they are used in the application's BL, but in most cases I think
that users would benefit if they split they objects.

For performance considerations I would recommend to store these types
separately:
1. gets/puts to main-type  cache will be much faster - no excessive
serializations/deserializations and, most probably, network overhead.
2. dependent collection modification will be the fastest possible
4. colocation is still here - Ignite can store
3. collection item modification is seamless (let's say you need to modify
"count" of some row of the Order)

If we choose the way you suggest... Well, this makes me think of
Hibernate-like approaches with sessions, collections mappings and proxies.
I think this will require us to implement collection wrappers and proxies
in order to efficiently detect modifications. Btw, we can track such
changes with BinaryObjects methods - BinaryObject may act as a proxy.

Any thoughts?

--Yakov

2016-01-21 5:39 GMT+03:00 Dmitriy Setrakyan :

> Igniters,
>
> I would like us to consider support for indexes into collections (lists,
> sets) for object fields. I think we can support it by storing collections
> internally in a separate cache and create a special index for it.
>
> For example:
>
>- Create special type of index annotation and config for inner
>collections
>- Internally, store collection as an additional table with a synthetic
>foreign key.
>- Have user explicitly do a join between 2 tables when he needs to
>select something
>
> The only question I still have is how to handle modifications to
> collections. Our current cache access approach would require user to clone
> a collection whenever adding or removing elements in it, which can get
> quite expensive.
>
> Thoughts?
>
> D.
>

Re: Re: Re: about AOP development

[Vladimir Ershov]

Hi,

Yes, sure, I can take a look. Just send me, please, your full logs with
exception, and describe how exactly you reproduce it (how many nodes
started, which one is client and etc.).

Thanks!

On Thu, Jan 21, 2016 at 9:43 AM, 李玉珏 <18624049...@163.com> wrote:

> Hi:
>
> I understand your approach, it should be feasible, but not very elegant.
> If use ProxyFactory in spring. At runtime dynamically add interceptor,
> can solve the problem, but performance will influence.
>
> I switched to a different way of writing, using the Service mechanism,
> code has been updated to GitHub, throws NullException. I survey the
> reason, the problem is in service deployment process of marshal and
> unmarshal stage, because of AdvisedSupport's methodCache is transient,
> this may be a compatibility problem, also asks you to look at.
>
>
> Sent from Mail Master
>
>
> On 2016-01-20 22:20 , Vladimir Ershov  Wrote:
>
> As for the last step, let me correct myself:
>
>3. Start server Ignite node from spring context *AND *put spring jars
> inside classpath in *.sh file. Be sure, that both nodes are using the same
> xml context.
>
> On Wed, Jan 20, 2016 at 5:07 PM, Vladimir Ershov 
> wrote:
>
> > Hi!
> >
> > I've checked your code and spot an issue. The root cause, is using of
> > Autowired annotation, since it cause bean to be serialized on a client
> > side, and that leads ClassNotFoundException on the server side during
> bean
> > deserialization, since server was started from *.sh, without necessary
> > spring jars in the classpath.
> >
> > Good news here, that it could be fixed easily with those steps:
> >
> >1. Remove Autowired from transferred entities as ComputeGridJob
> >2. When you need an applicationContext, use
> >@SpringApplicationContextResource annotation.  You are need to use it
> in
> >your ComputeGridTask.
> >3. Start server Ignite node from spring context, or put spring jars
> >inside classpath in *.sh file.
> >
> > Also, you can simplify your solution for ComputeGridService by using
> > @ServiceResource. Take a look:
> > https://apacheignite.readme.io/docs/service-example
> >
> > Thanks!
> >
> > On Wed, Jan 20, 2016 at 6:07 AM, 李玉珏 <18624049...@163.com> wrote:
> >
> >> Hi:
> >> The relevant code on the GitHub, the address is:
> >> https://github.com/liyuj/computegrid
> >>
> >>
> >> Sent from Mail Master
> >>
> >>
> >>
> >> On 2016-01-20 04:32 , Dmitriy Setrakyan Wrote:
> >>
> >> The list does not support attachments. You can use pastebin [1] or gist
> >> [2]
> >> to paste your code and send the link here.
> >>
> >> [1] http://pastebin.com/
> >> [2] https://gist.github.com/
> >>
> >> D.
> >>
> >> On Tue, Jan 19, 2016 at 4:48 AM, 李玉珏@163 <18624049...@163.com> wrote:
> >>
> >> > Hi：
> >> >
> >> > I had just sent the code to the list.
> >> >
> >> > 在 16/1/19 20:39, Denis Magda 写道:
> >> >
> >> > Seems that peerClassLoading doesn't work for your case. Please share
> the
> >> >> source code of your example.
> >> >>
> >> >> --
> >> >> Denis
> >> >>
> >> >> On 1/18/2016 3:48 PM, 李玉珏@163 wrote:
> >> >>
> >> >>> Hi：
> >> >>>
> >> >>> I have already opened the peerClassLoading.
> >> >>> My practice is in eclipse create a java project, developed a
> >> >>> ComputeTaskSplitAdapter examples, then in the ComputeJobAdapter
> call
> >> >>> configured spring interceptors service. This example in eclipse
> >> operation
> >> >>> is no problem.
> >> >>>
> >> >>> But if I open a node in the command line by ignite.sh, it will
> prompt
> >> >>> the following error in the command line.
> >> >>>
> >> >>> In the default configuration file of ignite, the same configuration
> of
> >> >>> the peerClassLoading=true.
> >> >>>
> >> >>> 在 16/1/18 19:39, Yakov Zhdanov 写道:
> >> >>>
> >>  Can you please try enabling "peerClassLoading" and share the
> results
> >>  here?
> >> 
> >>  --Yakov
> >> 
> >>  2016-01-16 12:09 GMT+03:00 李玉珏@163 <18624049...@163.com>:
> >> 
> >>  Hi：
> >> >
> >> > In a distributed environment, if use the spring AOP programming,
> >> > generated
> >> > a class of byte code enhancement, then the error will be reported
> as
> >> > follows:
> >> >
> >> > java.lang.ClassNotFoundException:
> >> >
> demo.computegrid.ComputeGridService$$EnhancerBySpringCGLIB$$7b44b192
> >> >
> >> > This error I understand, this class does not exist on the remote
> >> node.
> >> > But the question is, is it a technical limitation of Ignite, or
> is
> >> it
> >> > the
> >> > way I use it，or is it a bug?
> >> >
> >> > I opened the peer class loading , the normal deployment I did not
> >> test,
> >> > but I estimate it will be the same error.
> >> >
> >> >
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >>
> >
> >
>
>
>
> 来自 *网易**手机号码邮箱* -- 手机号码就是邮箱帐号，了解详情> 
>

[jira] [Created] (IGNITE-2428) [Test] [Rare] IgniteClientReconnectFailoverTest.testReconnectComputeApi

[Vladimir Ershov (JIRA)]

Vladimir Ershov created IGNITE-2428:
---

 Summary: [Test] [Rare] 
IgniteClientReconnectFailoverTest.testReconnectComputeApi
 Key: IGNITE-2428
 URL: https://issues.apache.org/jira/browse/IGNITE-2428
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Vladimir Ershov


Test fails rarely.
{noformat}
org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node 
still alive?). Make sure that each GridComputeTask and GridCacheTransaction has 
a timeout set in order to prevent parties from waiting forever in case of 
network issues [nodeId=e2965abc-87ff-4f55-8c80-9c68fe30, 
addrs=[/127.0.0.1:47100]]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2464)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2105)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:1999)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1935)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1901)
at 
org.apache.ignite.internal.IgniteClientReconnectAbstractTest$BlockTpcCommunicationSpi.sendMessage(IgniteClientReconnectAbstractTest.java:435)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1077)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1146)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1240)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:609)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:501)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:678)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:403)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:406)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:379)
at 
org.apache.ignite.internal.IgniteComputeImpl.broadcast(IgniteComputeImpl.java:267)
at 
org.apache.ignite.internal.IgniteClientReconnectFailoverTest$3.call(IgniteClientReconnectFailoverTest.java:191)
at 
org.apache.ignite.internal.IgniteClientReconnectFailoverTest$3.call(IgniteClientReconnectFailoverTest.java:187)
at 
org.apache.ignite.internal.IgniteClientReconnectFailoverAbstractTest$1.call(IgniteClientReconnectFailoverAbstractTest.java:103)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: about AOP development

[李玉珏]

Hi：

I am at home now, can not reproduce.

Do not need to cluster, to get the code to run directly, you can reproduce.

If you use the AOP spring technology, through the following code:

ClusterGroup cg = ignite.cluster().forServers();
IgniteCompute compute = ignite.compute(cg);
IgniteServices svcs = ignite.services(cg);
Service service = (Service)ac.getBean("computeGridService");
svcs.deployNodeSingleton("computeGridService", service);

Will throw an nullexception.

address is：https://github.com/liyuj/computegrid


在 16/1/21 19:40, Vladimir Ershov 写道:

Hi,

Yes, sure, I can take a look. Just send me, please, your full logs with
exception, and describe how exactly you reproduce it (how many nodes
started, which one is client and etc.).

Thanks!

On Thu, Jan 21, 2016 at 9:43 AM, 李玉珏 <18624049...@163.com> wrote:


Hi:

I understand your approach, it should be feasible, but not very elegant.
If use ProxyFactory in spring. At runtime dynamically add interceptor,
can solve the problem, but performance will influence.

I switched to a different way of writing, using the Service mechanism,
code has been updated to GitHub, throws NullException. I survey the
reason, the problem is in service deployment process of marshal and
unmarshal stage, because of AdvisedSupport's methodCache is transient,
this may be a compatibility problem, also asks you to look at.


Sent from Mail Master


On 2016-01-20 22:20 , Vladimir Ershov  Wrote:

As for the last step, let me correct myself:

3. Start server Ignite node from spring context *AND *put spring jars
inside classpath in *.sh file. Be sure, that both nodes are using the same
xml context.

On Wed, Jan 20, 2016 at 5:07 PM, Vladimir Ershov 
wrote:


Hi!

I've checked your code and spot an issue. The root cause, is using of
Autowired annotation, since it cause bean to be serialized on a client
side, and that leads ClassNotFoundException on the server side during

bean

deserialization, since server was started from *.sh, without necessary
spring jars in the classpath.

Good news here, that it could be fixed easily with those steps:

1. Remove Autowired from transferred entities as ComputeGridJob
2. When you need an applicationContext, use
@SpringApplicationContextResource annotation.  You are need to use it

in

your ComputeGridTask.
3. Start server Ignite node from spring context, or put spring jars
inside classpath in *.sh file.

Also, you can simplify your solution for ComputeGridService by using
@ServiceResource. Take a look:
https://apacheignite.readme.io/docs/service-example

Thanks!

On Wed, Jan 20, 2016 at 6:07 AM, 李玉珏 <18624049...@163.com> wrote:


Hi:
The relevant code on the GitHub, the address is:
https://github.com/liyuj/computegrid


Sent from Mail Master



On 2016-01-20 04:32 , Dmitriy Setrakyan Wrote:

The list does not support attachments. You can use pastebin [1] or gist
[2]
to paste your code and send the link here.

[1] http://pastebin.com/
[2] https://gist.github.com/

D.

On Tue, Jan 19, 2016 at 4:48 AM, 李玉珏@163 <18624049...@163.com> wrote:


Hi：

I had just sent the code to the list.

在 16/1/19 20:39, Denis Magda 写道:

Seems that peerClassLoading doesn't work for your case. Please share

the

source code of your example.

--
Denis

On 1/18/2016 3:48 PM, 李玉珏@163 wrote:


Hi：

I have already opened the peerClassLoading.
My practice is in eclipse create a java project, developed a
ComputeTaskSplitAdapter examples, then in the ComputeJobAdapter

call

configured spring interceptors service. This example in eclipse

operation

is no problem.

But if I open a node in the command line by ignite.sh, it will

prompt

the following error in the command line.

In the default configuration file of ignite, the same configuration

of

the peerClassLoading=true.

在 16/1/18 19:39, Yakov Zhdanov 写道:


Can you please try enabling "peerClassLoading" and share the

results

here?

--Yakov

2016-01-16 12:09 GMT+03:00 李玉珏@163 <18624049...@163.com>:

Hi：

In a distributed environment, if use the spring AOP programming,
generated
a class of byte code enhancement, then the error will be reported

as

follows:

java.lang.ClassNotFoundException:


demo.computegrid.ComputeGridService$$EnhancerBySpringCGLIB$$7b44b192

This error I understand, this class does not exist on the remote

node.

But the question is, is it a technical limitation of Ignite, or

is

it

the
way I use it，or is it a bug?

I opened the peer class loading , the normal deployment I did not

test,

but I estimate it will be the same error.











来自 *网易**手机号码邮箱* -- 手机号码就是邮箱帐号，了解详情> 

[GitHub] ignite pull request: IGNITE-2419 manage memory overhead in resourc...

[DoudTechData]

GitHub user DoudTechData opened a pull request:

https://github.com/apache/ignite/pull/414

IGNITE-2419 manage memory overhead in resource requests to YARN

implements memory overhead property in ClusterProperties.
use property for requesting memory in ApplicationMaster.
Simplify/factorize properties loading in ClusterProperties

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/DoudTechData/ignite jira-2419

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/414.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #414


commit 38c17b70a9d7b419e34544d9771ebfc12e534791
Author: Edouard Chevalier 
Date:   2016-01-21T12:33:31Z

implements memory overhead and factorize properties loading.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: What is jdbc:ignite:cfg ??

[Konstantin Boudnik]

On Wed, Jan 20, 2016 at 03:32PM, Andrey Gura wrote:
> Dmitry,
> 
> We can suggest to Zepplin comunity introduce parameters per
> notebook/paragraph that can be passed to interpreter.
> 
> The second option is adding some keywords that can be parsed by
> interpreter.
> 
> I think that Val's suggestion is more suitable at this moment.

I actually like Val's ideas as well. What he is proposing is the way to
improve UX of the product. See, more and more ppl - especially in this
FastData arena - aren't developers. They won't know an exception even if you
hit them over the head with one. Hence, whenever an exception is thrown in the
UI like Zeppelin, that's the end of the world for most of them.

Ideally, we need to go an extra mile to hide all this complexity as much as
possible. In fact, the complexity is what killing all these cool technologies.
In order to run some simple linear regression calculation, one has to be an
expert in Unix, Java, system integration, and god knows what else ;) 

Cos

> On Wed, Jan 20, 2016 at 1:10 AM, Dmitriy Setrakyan 
> wrote:
> 
> > Can we just start a different client connection per-notebook? This way user
> > can specify different default cache per notebook, no?
> >
> > Andrey, we already have the explanation for why it does not work. Can you
> > provide some ideas on what needs to happen to make it work?
> >
> > D.
> >
> > On Tue, Jan 19, 2016 at 11:22 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Andrey,
> > >
> > > My answers are inline...
> > >
> > > On Tue, Jan 19, 2016 at 4:14 AM, Andrey Gura  wrote:
> > >
> > > > Val,
> > > >
> > > > I have a couple of questions:
> > > >
> > > > 1. What cache should be used by JDBC driver for query execution when no
> > > > cache name in JDBC URL? I see only one option: any user cache. But it
> > can
> > > > bring some random behavior. Caches can be created/deleted dynamically
> > and
> > > > JDBC connection can refer to removed cache.
> > > >
> > >
> > > If cache name is not provided in the URL, all cache names have to be
> > > provided in the query (except the default cache if it exists). If one of
> > > the names refers to non-existing cache, exception will be thrown. Default
> > > cache is not different from this standpoint - if the query contains a
> > type
> > > without cache name specified and default cache doesn't exist, exception
> > is
> > > thrown as well.
> > >
> > >
> > > >
> > > > 2. How user should refer to default cache in queries in case when some
> > > non
> > > > default cache name used as connection parameter?
> > > >
> > >
> > > This is something that is not possible now anyway, right? Actually, I've
> > > never seen an example of the default cache being used, especially if
> > > multiple caches are used. So I would not sacrifice usability to support
> > > this use case. If one wants to query the default cache, leave it blank in
> > > the URL and explicitly specify names of all other caches.
> > >
> > >
> > > >
> > > >
> > > >
> > > > On Tue, Jan 19, 2016 at 12:47 AM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > I think we can just remove the requirement of having the default
> > cache
> > > > when
> > > > > no cache name is provided in the JDBC URL. I don't see any reason to
> > > > refuse
> > > > > connection in this case, because if query doesn't properly specify
> > > cache
> > > > > names for all participating types, the exception will be thrown
> > anyway.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -Val
> > > > >
> > > > > On Mon, Jan 18, 2016 at 6:35 AM, Andrey Gura 
> > > wrote:
> > > > >
> > > > > > Cos,
> > > > > >
> > > > > > if cache name isn't specified in JDBC URL then default cache will
> > be
> > > > > used.
> > > > > >
> > > > > > If default cache isn't created then driver will throw exception
> > with
> > > > > > "Client is invalid. Probably cache name is wrong" message.
> > > > > >
> > > > > > You can use workaround and just create default cache. I understand
> > > that
> > > > > > this solution is not what you want :)
> > > > > >
> > > > > > I don't have any idea about how to avoid using cache name because
> > > > Ignite
> > > > > > API requires named cache instance in order to execute query.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 16, 2016 at 10:44 AM, Konstantin Boudnik <
> > c...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks Andrey.
> > > > > > >
> > > > > > > I think option one is a bad UX, cause creating an interpreter
> > isn't
> > > > > > >  a) a simple button click (might be improved later on by Z.
> > folks)
> > > > > > >  b) what if I have 25 different caches and the equal number of
> > > > > > interpreters
> > > > > > > and need to make a change to all of them?
> > > > > > >
> > > > > > > The second option sounds good, yet the interpreter still needs to
> > > > have
> > > > > a
> > > > > > > particular cache name in the configuration, which now looks weird
> 

Re: Marking fixed JIRAs against releases

[Konstantin Boudnik]

There might be a way to enforce it on the JIRA side, I just have no idea, to
be honest. The best way is to file INFRA and ask them to help

Cos

On Tue, Jan 19, 2016 at 04:12PM, Yakov Zhdanov wrote:
> Cos, very good catch.
> 
> 1. Agree with Dmitry that it would be better to enforce version is set on
> close/resolution.
> 2. As far as already closed tickets let's have everyone review tickets
> closed by himself and put proper fixVersion.
> 
> --Yakov
> 
> 2016-01-19 9:53 GMT+03:00 Dmitriy Setrakyan :
> 
> > Cos, to my knowledge, the release notes are generated by searching for a
> > fix version, so the tickets you are pointing out will likely be missed.
> >
> > Generally speaking all fixed tickets should have a fix version. Let’s make
> > sure that we follow this rule going forward. (Any way to enforce it?)
> >
> > D.
> >
> > On Mon, Jan 18, 2016 at 3:50 PM, Konstantin Boudnik 
> > wrote:
> >
> > > Guys,
> > >
> > > as a fall-out from another conversation I've ran the following search on
> > > JIRA
> > >
> > > project = ignite and status in (Fixed, Closed) and fixVersion is null
> > >
> > > and we have 150 (yes, some of them are dups and won't fixes) closed/fixed
> > > tickets without explicit fixVersion on them. How do we keep track of what
> > > is a
> > > particular release and what's not? How the Release Notes are generated?
> > >
> > > Regards,
> > >   Cos
> > >
> >


signature.asc
Description: Digital signature

[jira] [Created] (IGNITE-2429) CPP: Add examples for the ODBC.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-2429:
---

 Summary: CPP: Add examples for the ODBC.
 Key: IGNITE-2429
 URL: https://issues.apache.org/jira/browse/IGNITE-2429
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.6


We need to implement examples that will show how to use our ODBC driver.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2430) BinaryObject: Inconsistent field type name is returned for Collections

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2430:
---

 Summary: BinaryObject: Inconsistent field type name is returned 
for Collections
 Key: IGNITE-2430
 URL: https://issues.apache.org/jira/browse/IGNITE-2430
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Denis Magda
 Fix For: 1.6


Run this code below and you will see that different field type name is returned 
for objects of the same type. There is a bug in 
{{BinaryObjectBuilderImpl.serializeTo}} method.

{noformat}
BinaryObjectBuilder root = ignite.binary().builder("some_objects");
root.setField("bi", new BigInteger(String.valueOf(Long.MAX_VALUE) + 
"1"), BigInteger.class);
root.setField("bd", new BigDecimal(String.valueOf(Long.MAX_VALUE) + 
"1.1"), BigDecimal.class);

List list = new ArrayList<>();
list.add(Integer.MAX_VALUE);

root.setField("l", list); //<- here: Collection
root.setField("al", Arrays.asList(Integer.MAX_VALUE)); //<- 
here: Object

BinaryObject binaryObject = root.build();

System.out.println(binaryObject.type().fieldTypeName("l"));
System.out.println(binaryObject.type().fieldTypeName("al"));
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: supporting collection indexes

[Sergi Vladykin]

I think this feature can be implemented.

As far as I understand user will not need to clone the collection or do
anything else from what he does now.
We well have to drop all the collection items from that separate table and
add them again on update. Of course we can try to apply some heuristics
like comparing contents of old collection and new one and add/drop changed
items.

Anyways complex things like collection proxy looks like an overkill here,
since as Yakov already pointed out the actual value of this feature will be
quite limited. Lets keep it simple.

Sergi

2016-01-21 13:37 GMT+03:00 Yakov Zhdanov :

> This may be a good feature, but I don't think it will be widely used. I
> understand that Ignite users want to have their objects stored exactly in
> the format they are used in the application's BL, but in most cases I think
> that users would benefit if they split they objects.
>
> For performance considerations I would recommend to store these types
> separately:
> 1. gets/puts to main-type  cache will be much faster - no excessive
> serializations/deserializations and, most probably, network overhead.
> 2. dependent collection modification will be the fastest possible
> 4. colocation is still here - Ignite can store
> 3. collection item modification is seamless (let's say you need to modify
> "count" of some row of the Order)
>
> If we choose the way you suggest... Well, this makes me think of
> Hibernate-like approaches with sessions, collections mappings and proxies.
> I think this will require us to implement collection wrappers and proxies
> in order to efficiently detect modifications. Btw, we can track such
> changes with BinaryObjects methods - BinaryObject may act as a proxy.
>
> Any thoughts?
>
> --Yakov
>
> 2016-01-21 5:39 GMT+03:00 Dmitriy Setrakyan :
>
> > Igniters,
> >
> > I would like us to consider support for indexes into collections (lists,
> > sets) for object fields. I think we can support it by storing collections
> > internally in a separate cache and create a special index for it.
> >
> > For example:
> >
> >- Create special type of index annotation and config for inner
> >collections
> >- Internally, store collection as an additional table with a synthetic
> >foreign key.
> >- Have user explicitly do a join between 2 tables when he needs to
> >select something
> >
> > The only question I still have is how to handle modifications to
> > collections. Our current cache access approach would require user to
> clone
> > a collection whenever adding or removing elements in it, which can get
> > quite expensive.
> >
> > Thoughts?
> >
> > D.
> >
>

Pool size limits

[Vasiliy Sisko]

Hello.

I found that IgniteConfiguration.utilityCachePoolSize and
IgniteConfiguration.marshCachePoolSize are limited by a constant
IgniteConfiguration.DFLT_SYSTEM_MAX_THREAD_CNT that is equals to
DFLT_PUBLIC_THREAD_CNT and does not used any more.

IgnitionEx:1661:
utilityCacheExecSvc = new IgniteThreadPoolExecutor(
"utility",
cfg.getGridName(),
>>myCfg.getUtilityCacheThreadPoolSize(),
>>DFLT_SYSTEM_MAX_THREAD_CNT,
myCfg.getUtilityCacheKeepAliveTime(),
new
LinkedBlockingQueue(DFLT_SYSTEM_THREADPOOL_QUEUE_CAP));

marshCacheExecSvc = new IgniteThreadPoolExecutor(
"marshaller-cache",
cfg.getGridName(),
>>myCfg.getMarshallerCacheThreadPoolSize(),
>>DFLT_SYSTEM_MAX_THREAD_CNT,
myCfg.getMarshallerCacheKeepAliveTime(),
new
LinkedBlockingQueue(DFLT_SYSTEM_THREADPOOL_QUEUE_CAP));

We can configure these properties more then default limit and catch runtime
exception.

DFLT_PUBLIC_THREAD_CNT configure default value of
IgniteConfiguration.pubPoolSize.

I think we should limit these pool sizes by value of
IgniteConfiguration.pubPoolSize, f.e.:

utilityCacheExecSvc = new IgniteThreadPoolExecutor(
"utility",
cfg.getGridName(),
myCfg.getUtilityCacheThreadPoolSize(),
>>myCfg.getPublicThreadPoolSize(),
myCfg.getUtilityCacheKeepAliveTime(),
new
LinkedBlockingQueue(DFLT_SYSTEM_THREADPOOL_QUEUE_CAP));

marshCacheExecSvc = new IgniteThreadPoolExecutor(
"marshaller-cache",
cfg.getGridName(),
myCfg.getMarshallerCacheThreadPoolSize(),
>>myCfg.getPublicThreadPoolSize(),
myCfg.getMarshallerCacheKeepAliveTime(),
new
LinkedBlockingQueue(DFLT_SYSTEM_THREADPOOL_QUEUE_CAP));

Thoughts?

-- 
Vasiliy Sisko
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-2431) Add new fields in cluster connector configuration.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2431:
-

 Summary: Add new fields in cluster connector configuration.
 Key: IGNITE-2431
 URL: https://issues.apache.org/jira/browse/IGNITE-2431
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


Check changes in ConnectorConfiguration class and move these changes to site.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

ignite cache process entry should inject source?

[姜 为]

Hi Igniters,

I’m using Ignite cache store objects.  The object use Externalizable 
interface 
to serialization  and deserialization. 
When object has field use @SpringSource will not inject.

Should add resource inject to Ignite cache?

example :

class Entey implements Externalizable {
  @SpringSource(“springSource")
   private Service service;
  

   public void read… and write...
   } 

Ignite cache process entry should inject source?

[姜 为]

Hi Igniters,

I’m using Ignite cache store objects.  The object use Externalizable 
interface 
  to serialization  and deserialization. 
When object has field use @SpringSource will not inject.

Should add resource inject to Ignite cache?

example :

class Entey implements Externalizable {
@SpringSource(“springSource")
 private Service service;


 public void read… and write...
 }

[jira] [Created] (IGNITE-2432) Ignite cache CacheObjectImpl should inject resource after unmarshal

[wmz7year (JIRA)]

wmz7year created IGNITE-2432:


 Summary: Ignite cache CacheObjectImpl should inject resource after 
unmarshal
 Key: IGNITE-2432
 URL: https://issues.apache.org/jira/browse/IGNITE-2432
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5
Reporter: wmz7year
Assignee: wmz7year


Ignite cache elements not inject resources.

example :
class Entey implements Externalizable {
   @SpringSource(“springSource")
private Service service;


public void read… and write...
}

IgniteCache.get(key)Entey.service null be null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: ignite-2432

[wmz7year]

GitHub user wmz7year opened a pull request:

https://github.com/apache/ignite/pull/415

 ignite-2432



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/wmz7year/ignite ignite-2432

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/415.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #415


commit 562a5e16a5d239ef66144aa927b5537388a413b5
Author: wmz7year 
Date:   2016-01-22T06:46:07Z

Fix ignite-2432




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: ignite cache process entry should inject source?

[Denis Magda]

Hi,

Spring resource injection is considered to be used only for Ignite 
Compute Jobs.


It's quite expensive operation to inject a resource for a CacheEntry 
cause this logic will be called for every entry stored in a cache.


Why do you need to inject the resource into a CacheEntry? What do you 
try to achieve?


Regards,
Denis

On 1/22/2016 6:26 AM, 姜 为 wrote:

Hi Igniters,

I’m using Ignite cache store objects.  The object use Externalizable 
interface
 to serialization  and deserialization.
When object has field use @SpringSource will not inject.

Should add resource inject to Ignite cache?

example :

class Entey implements Externalizable {
   @SpringSource(“springSource")
private Service service;
   


public void read… and write...
}

Re: ignite cache process entry should inject source?

[姜 为]

Hi Denis,

I try to use Ignite cache to store the service object. 
The object use Externalizable interface and has a @Autowired field.

When different node use this object, the @Autowired field will be 
null,even @SpringResources on the field.

The field like JPA interface , it can’t be serialization.

Wei Jiang


> 在 2016年1月22日，下午2:58，Denis Magda  写道：
> 
> Hi,
> 
> Spring resource injection is considered to be used only for Ignite Compute 
> Jobs.
> 
> It's quite expensive operation to inject a resource for a CacheEntry cause 
> this logic will be called for every entry stored in a cache.
> 
> Why do you need to inject the resource into a CacheEntry? What do you try to 
> achieve?
> 
> Regards,
> Denis
> 
> On 1/22/2016 6:26 AM, 姜 为 wrote:
>> Hi Igniters,
>>  
>>  I’m using Ignite cache store objects.  The object use Externalizable 
>> interface
>> to serialization  and deserialization.
>>  When object has field use @SpringSource will not inject.
>> 
>>  Should add resource inject to Ignite cache?
>> 
>>  example :
>> 
>>  class Entey implements Externalizable {
>>   @SpringSource(“springSource")
>>private Service service;
>>   
>>public void read… and write...
>>}
> 

Re: ignite cache process entry should inject source?

[Denis Magda]

Hi Wei Jiang,

You can inject @SpringResource and @SpringApplicationContextResource 
into Ignite Service or Ignite Compute. This feature is not supported for 
individual cache entries, at least because of performance reasons.

@Autowired is unsupported for both Ignite services and computes.

So if you need to process the entries inside of Ignite Compute or Ignite 
Service then just inject a resource there using one of the annotations 
above.


The main point here is that all the nodes have to be started as a part 
of spring app context or have to have a reference to it.

Please refer to org.apache.ignite.IgniteSpring for more info.

Regards,
Denis

On 1/22/2016 10:07 AM, 姜 为 wrote:

Hi Denis,

I try to use Ignite cache to store the service object.
The object use Externalizable interface and has a @Autowired field.

When different node use this object, the @Autowired field will be 
null,even @SpringResources on the field.

The field like JPA interface , it can’t be serialization.

Wei Jiang



在 2016年1月22日，下午2:58，Denis Magda  写道：

Hi,

Spring resource injection is considered to be used only for Ignite Compute Jobs.

It's quite expensive operation to inject a resource for a CacheEntry cause this 
logic will be called for every entry stored in a cache.

Why do you need to inject the resource into a CacheEntry? What do you try to 
achieve?

Regards,
Denis

On 1/22/2016 6:26 AM, 姜 为 wrote:

Hi Igniters,

I’m using Ignite cache store objects.  The object use Externalizable 
interface
 to serialization  and deserialization.
When object has field use @SpringSource will not inject.

Should add resource inject to Ignite cache?

example :

class Entey implements Externalizable {
   @SpringSource(“springSource")
private Service service;
   
public void read… and write...

}

Re: ignite cache process entry should inject source?

[姜 为]

Hi Denis,

How about provide an option for this?

Ignite cache user can chose enable or disable inject resources.

Wei Jiang

> 在 2016年1月22日，下午3:22，Denis Magda  写道：
> 
> Hi Wei Jiang,
> 
> You can inject @SpringResource and @SpringApplicationContextResource into 
> Ignite Service or Ignite Compute. This feature is not supported for 
> individual cache entries, at least because of performance reasons.
> @Autowired is unsupported for both Ignite services and computes.
> 
> So if you need to process the entries inside of Ignite Compute or Ignite 
> Service then just inject a resource there using one of the annotations above.
> 
> The main point here is that all the nodes have to be started as a part of 
> spring app context or have to have a reference to it.
> Please refer to org.apache.ignite.IgniteSpring for more info.
> 
> Regards,
> Denis
> 
> On 1/22/2016 10:07 AM, 姜 为 wrote:
>> Hi Denis,
>>  
>>  I try to use Ignite cache to store the service object.
>>  The object use Externalizable interface and has a @Autowired field.
>>  
>>  When different node use this object, the @Autowired field will be 
>> null,even @SpringResources on the field.
>> 
>>  The field like JPA interface , it can’t be serialization.
>> 
>> Wei Jiang
>> 
>> 
>>> 在 2016年1月22日，下午2:58，Denis Magda  写道：
>>> 
>>> Hi,
>>> 
>>> Spring resource injection is considered to be used only for Ignite Compute 
>>> Jobs.
>>> 
>>> It's quite expensive operation to inject a resource for a CacheEntry cause 
>>> this logic will be called for every entry stored in a cache.
>>> 
>>> Why do you need to inject the resource into a CacheEntry? What do you try 
>>> to achieve?
>>> 
>>> Regards,
>>> Denis
>>> 
>>> On 1/22/2016 6:26 AM, 姜 为 wrote:
 Hi Igniters,

I’m using Ignite cache store objects.  The object use Externalizable 
 interface
 to serialization  and deserialization.
When object has field use @SpringSource will not inject.
 
Should add resource inject to Ignite cache?
 
example :
 
class Entey implements Externalizable {
   @SpringSource(“springSource")
private Service service;
   public void read… and write...
}
>