[jira] [Created] (IGNITE-2539) NPE at RendezvousAffinityFunction

[Vladimir Ershov (JIRA)]

Vladimir Ershov created IGNITE-2539:
---

 Summary: NPE at RendezvousAffinityFunction
 Key: IGNITE-2539
 URL: https://issues.apache.org/jira/browse/IGNITE-2539
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ershov
Priority: Critical


RendezvousAffinityFunction#assignPartition throws NPE, probably due to 
simultaneous topology change and  cache stop. We should write a test and fix 
this.



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

Re: Ticket IGNITE-1497

[Andrey Gura]

Hi Thorsten!

IGNITE-2080 should fix this problem. Fix was merged into master branch
yesterday.
So you can build latest Ignite from sources and try to run it on your
device.

Please, let me know about result.

Thanks!


On Wed, Feb 3, 2016 at 12:35 PM, Yakov Zhdanov  wrote:

> Hello Thorsten!
>
> I am not working on this ticket and most probably will not have time to
> start in nearest future.
>
> I am CCing project's dev list. Andrey Gura, can you please respond -
> whether this issue is fixed or not with
> https://issues.apache.org/jira/browse/IGNITE-2080 fix?
>
> --Yakov
>
> 2016-02-03 10:47 GMT+03:00 :
>
> > Hello,
> >
> > I've seen that you are assigned to the Apache Ignite Ticket IGNITE-1497
> > (Support CPU architectures different from x86/x64).
> > I'm am actually trying to run Ignite on an Raspberry PI 2 for my Master
> > Dissertation and figured out, that the JVM crashes if I connect two
> Ignite
> > Nodes with the error described in the ticket.
> > Are you working on this ticket? And do you know when a fixed version of
> > Ignite will be available for download?
> >
> > Thank you for your time.
> >
> > Kind Regards,
> > Thorsten Raff
> >
> > _
> > Sent from http://apache-ignite-users.70518.x6.nabble.com
> >
> >
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

Re: [jira] [Commented] (IGNITE-1523) Need to always serialize user objects with configured marshaller

[Anton Vinogradov]

Val,

I've fixed some cases related to this issue.
In case you know what is left please describe it at issue and assign to me

On Tue, Feb 2, 2016 at 9:20 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Anton,
>
> If you're working in this issue, can you please assign it to yourself?
>
> -Val
>
> -- Forwarded message --
> From: Anton Vinogradov (JIRA) 
> Date: Tue, Feb 2, 2016 at 4:43 AM
> Subject: [jira] [Commented] (IGNITE-1523) Need to always serialize user
> objects with configured marshaller
> To: valentin.kuliche...@gmail.com
>
>
>
> [
>
> https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15128185#comment-15128185
> ]
>
> Anton Vinogradov commented on IGNITE-1523:
> --
>
> Fixed unmarshalling of Enum
> Fixed unmarshalling of CacheStoreFactory within CacheConfiguration
> All new checks added to GridCacheReplicatedPreloadSelfTest
>
> > Need to always serialize user objects with configured marshaller
> > 
> >
> > Key: IGNITE-1523
> > URL: https://issues.apache.org/jira/browse/IGNITE-1523
> > Project: Ignite
> >  Issue Type: Improvement
> >  Components: general
> >Reporter: Valentin Kulichenko
> >Assignee: Valentin Kulichenko
> >Priority: Critical
> >  Labels: important, user-request
> > Fix For: 1.6
> >
> >
> > Currently some components (at least discovery) use {{JdkMarshaller}} for
> all objects.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

[jira] [Created] (IGNITE-2540) GridNioServer.processWrite() generates garbage.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2540:
---

 Summary: GridNioServer.processWrite() generates garbage.
 Key: IGNITE-2540
 URL: https://issues.apache.org/jira/browse/IGNITE-2540
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.6


New ArrayList is created and then extended to at least 10 elements on each 
write event. 

Fix is fairly simple - keep this list as a field.



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

Re: Full API coverage enhancement

[Artem Shutak]

Igniters,

I thought a little bit more and think we need to add a support for the
following permutations too (I've added these to the jira description):
- We should also test with Serializable, Externalizable, and plain Pojos
for keys and values.
- The Pojo in the above test should contain an enum value
- We should also test Enums as keys and Enums as values
- All operations should have single-key and multi-key operations

Maybe someone see any other permutation to be supported?

-- Artem --

On Tue, Feb 2, 2016 at 10:05 PM, Artem Shutak  wrote:

> Dmitriy,
>
> There is a branch at my fork and a pull request at Ignite. See comment
> about pull request at the ticket (PR-446).
>
> But I have to notice that the branch under hard development and you it can
> not work (have compilation or test errors) at some moments.
>
> Good luck!
>
> -- Artem --
>
> On Tue, Feb 2, 2016 at 9:45 PM, Dmitriy Setrakyan 
> wrote:
>
>> Artem,
>>
>> This is great. I have noticed from the ticket that you have created some
>> initial suite already. Is there a branch I can look at it?
>>
>> D.
>>
>> On Tue, Feb 2, 2016 at 10:02 AM, Artem Shutak 
>> wrote:
>>
>> > Igniters,
>> >
>> > I'm working on an enhancement of Full API coverage [1] [2].
>> >
>> > Ignite already has Full API test, but currently it's hard to test all
>> > configuration combinations.
>> >
>> > Feel free to add comments in the jira if you have any thought.
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-2521
>> > [2]
>> https://cwiki.apache.org/confluence/display/IGNITE/Implementing+Tests
>> >
>> > Thanks,
>> > -- Artem --
>> >
>>
>
>

[jira] [Created] (IGNITE-2541) Potential NPE in GridCacheUpdateAtomicResult

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2541:
---

 Summary: Potential NPE in GridCacheUpdateAtomicResult
 Key: IGNITE-2541
 URL: https://issues.apache.org/jira/browse/IGNITE-2541
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.6


Problematic place - GridCacheUpdateAtomicResult.updateCntr

It is Long, but passed to constructor is long. Furthermore, some callees of 
ctor might pass null there.



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

Re: Ticket IGNITE-1497

[Yakov Zhdanov]

Hello Thorsten!

I am not working on this ticket and most probably will not have time to
start in nearest future.

I am CCing project's dev list. Andrey Gura, can you please respond -
whether this issue is fixed or not with
https://issues.apache.org/jira/browse/IGNITE-2080 fix?

--Yakov

2016-02-03 10:47 GMT+03:00 :

> Hello,
>
> I've seen that you are assigned to the Apache Ignite Ticket IGNITE-1497
> (Support CPU architectures different from x86/x64).
> I'm am actually trying to run Ignite on an Raspberry PI 2 for my Master
> Dissertation and figured out, that the JVM crashes if I connect two Ignite
> Nodes with the error described in the ticket.
> Are you working on this ticket? And do you know when a fixed version of
> Ignite will be available for download?
>
> Thank you for your time.
>
> Kind Regards,
> Thorsten Raff
>
> _
> Sent from http://apache-ignite-users.70518.x6.nabble.com
>
>

Powered by Ignite logo

[Anton Vinogradov]

Igniters,

I'd like to add "Powered by Ignite" logo files to
https://www.apache.org/foundation/press/kit/poweredBy
but I have no such permissions.

Only ASF Members can do it.

"Powered by Ignite" logo files located at /x1/home/sboikov/pb (at
people.apache.org)

Could someone from ASF Members copy them to directory
/x1/www/www.apache.org/content/foundation/press/kit/poweredBy

Thanks.

[jira] [Created] (IGNITE-2542) SQL: NPE in GridMergeIndex

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2542:
---

 Summary: SQL: NPE in GridMergeIndex
 Key: IGNITE-2542
 URL: https://issues.apache.org/jira/browse/IGNITE-2542
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Assignee: Sergi Vladykin
 Fix For: 1.6


The following NPE was detected in the latest version of Ignite.

{noformat}
[19:43:07,249][SEVERE][pub-#9%null%][GridJobWorker] Failed to execute job due 
to unexpected runtime exception 
[jobId=5003a84a251-c08c1735-63cd-4126-8b2b-20b2c86b6b9b, ses=GridJobSessionImpl 
[ses=GridTaskSessionImpl 
[taskName=o.a.i.i.processors.cache.query.jdbc.GridCacheQueryJdbcTask, 
dep=LocalDeployment [super=GridDeployment [ts=1454459447257, depMode=SHARED, 
clsLdr=sun.misc.Launcher$AppClassLoader@8f8acd0, 
clsLdrId=9d7e984a251-c08c1735-63cd-4126-8b2b-20b2c86b6b9b, userVer=0, loc=true, 
sampleClsName=java.lang.String, pendingUndeploy=false, undeployed=false, 
usage=0]], 
taskClsName=o.a.i.i.processors.cache.query.jdbc.GridCacheQueryJdbcTask, 
sesId=3003a84a251-5b26f849-8f0b-4f17-9ea4-225f76870e8c, 
startTime=1454460082285, endTime=9223372036854775807, 
taskNodeId=5b26f849-8f0b-4f17-9ea4-225f76870e8c, 
clsLdr=sun.misc.Launcher$AppClassLoader@8f8acd0, closed=false, cpSpi=null, 
failSpi=null, loadSpi=null, usage=1, fullSup=false, 
subjId=5b26f849-8f0b-4f17-9ea4-225f76870e8c, mapFut=IgniteFuture 
[orig=GridFutureAdapter [resFlag=0, res=null, startTime=1454460082292, 
endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
jobId=5003a84a251-c08c1735-63cd-4126-8b2b-20b2c86b6b9b]]
javax.cache.CacheException: Failed to run reduce query locally.
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:673)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$2.iterator(IgniteH2Indexing.java:956)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:61)
at 
org.apache.ignite.internal.processors.cache.query.jdbc.GridCacheQueryJdbcTask$JdbcDriverJob.execute(GridCacheQueryJdbcTask.java:240)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6397)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:503)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:456)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1166)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1770)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:821)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:784)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMergeIndexUnsorted$1.hasNext(GridMergeIndexUnsorted.java:97)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMergeIndex$IteratorCursor.next(GridMergeIndex.java:327)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMergeIndex$FetchingCursor.next(GridMergeIndex.java:358)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:614)
... 16 more
{noformat}



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

[GitHub] ignite pull request: ignite-2080 Data alignment issues with Unsafe

[agura]

Github user agura closed the pull request at:

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


---
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: about AOP development

[李玉珏]

Hi：

I found the ignite-aop module on github, and I asked what the module is 
to do?

In addition, this module does not have a document.

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











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

Re: About the Jira https://issues.apache.org/jira/browse/IGNITE-1481

[Ken Cheng]

Hi Andrey Gura,

Please help do a code review.
All related test cases passed without break.

http://204.14.53.151/viewLog.html?buildId=107343=buildResultsDiv=IgniteTests_IgniteDataGrid

Thanks,
kcheng

On Wed, Feb 3, 2016 at 7:47 PM, Ken Cheng  wrote:

> Here is the PR https://github.com/apache/ignite/pull/449
>
> Please help to review it.
>
> Thanks,
> kcheng
>
> On Wed, Feb 3, 2016 at 7:45 PM, Ken Cheng  wrote:
>
>> Yes, that's Andrey's proposal.
>>
>> I created the PR, right now it's run Tests.
>>
>> Thanks,
>> kcheng
>>
>> On Wed, Feb 3, 2016 at 6:34 PM, Alexey Goncharuk <
>> alexey.goncha...@gmail.com> wrote:
>>
>>> +1 for printing out a warning and ignoring the affinity function from the
>>> configuration. There is no other way to 'fix' the configuration other
>>> than
>>> remove the wrong affinity function, so it can be done at startup time
>>> right
>>> away.
>>>
>>> 2016-02-03 9:43 GMT+03:00 Ken Cheng :
>>>
>>> > I prefer to throw a IgniteCheckerException.
>>> >
>>> > Thanks,
>>> > kcheng
>>> >
>>> > On Wed, Feb 3, 2016 at 2:41 PM, Ken Cheng 
>>> wrote:
>>> >
>>> > > Hi Andrey Gura,
>>> > >
>>> > >
>>> > > What's the expected behavior when the cache mode is "Local" but
>>> affinity
>>> > > function is not  "LocalAffinityFunction"?
>>> > >
>>> > > 1: Throw an exception?
>>> > > 2: or change the affinity function rudely as "LocalAffinityFunction"
>>> and
>>> > > log the warning message at same time?
>>> > >
>>> > >
>>> > > Thanks,
>>> > > kcheng
>>> > >
>>> > > On Wed, Feb 3, 2016 at 10:35 AM, Ken Cheng 
>>> wrote:
>>> > >
>>> > >> Hi Andrey Gura,
>>> > >>
>>> > >> Thank you very much! I would study this part of code first.
>>> > >>
>>> > >> Thanks,
>>> > >> kcheng
>>> > >>
>>> > >> On Mon, Feb 1, 2016 at 6:37 PM, Andrey Gura 
>>> wrote:
>>> > >>
>>> > >>> Ken,
>>> > >>>
>>> > >>> cache configuration validation and initialization occurs in
>>> > >>> GridCacheProcessor class (methods validate() and initialize()).
>>> > >>>
>>> > >>> From my point of view two changes should be made:
>>> > >>>
>>> > >>> - during cache intialization LocalAffinityFunction should be set to
>>> > cache
>>> > >>> configuration if cache mode is LOCAL;
>>> > >>> - warning about ignoring affinity function parameter should be
>>> moved
>>> > from
>>> > >>> validate() method to intialize() method.
>>> > >>>
>>> > >>> I hope this will help you.
>>> > >>>
>>> > >>> On Mon, Feb 1, 2016 at 12:12 PM, Ken Cheng 
>>> > wrote:
>>> > >>>
>>> > >>> > Hi Andrey Gura,
>>> > >>> >
>>> > >>> > I am very new to Ignite, I am going to pick up
>>> > >>> > https://issues.apache.org/jira/browse/IGNITE-1481.
>>> > >>> >
>>> > >>> > Can you please give more hint?
>>> > >>> >
>>> > >>> >
>>> > >>> >
>>> > >>> >
>>> > >>> > Thanks,
>>> > >>> > kcheng
>>> > >>> >
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>> --
>>> > >>> Andrey Gura
>>> > >>> GridGain Systems, Inc.
>>> > >>> www.gridgain.com
>>> > >>>
>>> > >>
>>> > >>
>>> > >
>>> >
>>>
>>
>>
>

Re: About the Jira https://issues.apache.org/jira/browse/IGNITE-1481

[Ken Cheng]

Here is the PR https://github.com/apache/ignite/pull/449

Please help to review it.

Thanks,
kcheng

On Wed, Feb 3, 2016 at 7:45 PM, Ken Cheng  wrote:

> Yes, that's Andrey's proposal.
>
> I created the PR, right now it's run Tests.
>
> Thanks,
> kcheng
>
> On Wed, Feb 3, 2016 at 6:34 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> +1 for printing out a warning and ignoring the affinity function from the
>> configuration. There is no other way to 'fix' the configuration other than
>> remove the wrong affinity function, so it can be done at startup time
>> right
>> away.
>>
>> 2016-02-03 9:43 GMT+03:00 Ken Cheng :
>>
>> > I prefer to throw a IgniteCheckerException.
>> >
>> > Thanks,
>> > kcheng
>> >
>> > On Wed, Feb 3, 2016 at 2:41 PM, Ken Cheng  wrote:
>> >
>> > > Hi Andrey Gura,
>> > >
>> > >
>> > > What's the expected behavior when the cache mode is "Local" but
>> affinity
>> > > function is not  "LocalAffinityFunction"?
>> > >
>> > > 1: Throw an exception?
>> > > 2: or change the affinity function rudely as "LocalAffinityFunction"
>> and
>> > > log the warning message at same time?
>> > >
>> > >
>> > > Thanks,
>> > > kcheng
>> > >
>> > > On Wed, Feb 3, 2016 at 10:35 AM, Ken Cheng 
>> wrote:
>> > >
>> > >> Hi Andrey Gura,
>> > >>
>> > >> Thank you very much! I would study this part of code first.
>> > >>
>> > >> Thanks,
>> > >> kcheng
>> > >>
>> > >> On Mon, Feb 1, 2016 at 6:37 PM, Andrey Gura 
>> wrote:
>> > >>
>> > >>> Ken,
>> > >>>
>> > >>> cache configuration validation and initialization occurs in
>> > >>> GridCacheProcessor class (methods validate() and initialize()).
>> > >>>
>> > >>> From my point of view two changes should be made:
>> > >>>
>> > >>> - during cache intialization LocalAffinityFunction should be set to
>> > cache
>> > >>> configuration if cache mode is LOCAL;
>> > >>> - warning about ignoring affinity function parameter should be moved
>> > from
>> > >>> validate() method to intialize() method.
>> > >>>
>> > >>> I hope this will help you.
>> > >>>
>> > >>> On Mon, Feb 1, 2016 at 12:12 PM, Ken Cheng 
>> > wrote:
>> > >>>
>> > >>> > Hi Andrey Gura,
>> > >>> >
>> > >>> > I am very new to Ignite, I am going to pick up
>> > >>> > https://issues.apache.org/jira/browse/IGNITE-1481.
>> > >>> >
>> > >>> > Can you please give more hint?
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>> > Thanks,
>> > >>> > kcheng
>> > >>> >
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> Andrey Gura
>> > >>> GridGain Systems, Inc.
>> > >>> www.gridgain.com
>> > >>>
>> > >>
>> > >>
>> > >
>> >
>>
>
>

Re: About the Jira https://issues.apache.org/jira/browse/IGNITE-1481

[Alexey Goncharuk]

+1 for printing out a warning and ignoring the affinity function from the
configuration. There is no other way to 'fix' the configuration other than
remove the wrong affinity function, so it can be done at startup time right
away.

2016-02-03 9:43 GMT+03:00 Ken Cheng :

> I prefer to throw a IgniteCheckerException.
>
> Thanks,
> kcheng
>
> On Wed, Feb 3, 2016 at 2:41 PM, Ken Cheng  wrote:
>
> > Hi Andrey Gura,
> >
> >
> > What's the expected behavior when the cache mode is "Local" but affinity
> > function is not  "LocalAffinityFunction"?
> >
> > 1: Throw an exception?
> > 2: or change the affinity function rudely as "LocalAffinityFunction" and
> > log the warning message at same time?
> >
> >
> > Thanks,
> > kcheng
> >
> > On Wed, Feb 3, 2016 at 10:35 AM, Ken Cheng  wrote:
> >
> >> Hi Andrey Gura,
> >>
> >> Thank you very much! I would study this part of code first.
> >>
> >> Thanks,
> >> kcheng
> >>
> >> On Mon, Feb 1, 2016 at 6:37 PM, Andrey Gura  wrote:
> >>
> >>> Ken,
> >>>
> >>> cache configuration validation and initialization occurs in
> >>> GridCacheProcessor class (methods validate() and initialize()).
> >>>
> >>> From my point of view two changes should be made:
> >>>
> >>> - during cache intialization LocalAffinityFunction should be set to
> cache
> >>> configuration if cache mode is LOCAL;
> >>> - warning about ignoring affinity function parameter should be moved
> from
> >>> validate() method to intialize() method.
> >>>
> >>> I hope this will help you.
> >>>
> >>> On Mon, Feb 1, 2016 at 12:12 PM, Ken Cheng 
> wrote:
> >>>
> >>> > Hi Andrey Gura,
> >>> >
> >>> > I am very new to Ignite, I am going to pick up
> >>> > https://issues.apache.org/jira/browse/IGNITE-1481.
> >>> >
> >>> > Can you please give more hint?
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > Thanks,
> >>> > kcheng
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Andrey Gura
> >>> GridGain Systems, Inc.
> >>> www.gridgain.com
> >>>
> >>
> >>
> >
>

[GitHub] ignite pull request: IGNITE-2465: Assertion in load cache closure ...

[asfgit]

Github user asfgit closed the pull request at:

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


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

snapshot transaction isolation

[Dmitriy Setrakyan]

Igniters,

I keep hearing questions from users about the snapshot isolation. Currently
ignite provides Optimistic and Pessimistic

transactions [1]. This modes ensure that transactional values are
consistent with each other on 1st access of each value.

However, some use cases require that transactional values are consistent
with each other not at 1st access, but at transaction start time. After
giving it some thought, I think we can support it with minimal effort, if
we add a few restrictions. For example, we can easily support it if users
specify all the keys at the beginning of the transaction, for example

   1. User tells Ignite which keys he/she plans to transact on
   2. Ignite preemptively acquires locks on all these keys
   3. After locks are acquired, user has assurance that values will not
   change outside of this transaction and are consistent with teacher.
   4. Locks are released upon commit

The above algorithm will also perform better, as the initial looks will be
acquired in bulk, and not individually.

Thoughts?

[1]
https://apacheignite.readme.io/docs/transactions#optimistic-and-pessimistic

Re: Review request

[Vladimir Ozerov]

As per cache - I hardly understand affected logic, so my review wouldn't
help much here.

As per the rest changes - looks good for me. I also see garbage from NIO
and "force keys" as huge memory hotspots. The only problem is
GridCompoundFuture:

if (futs == null)
futs = new ArrayList<>();

futs.add(fut);


Things like this are proven to be anti-pattern in terms of memory
allocations, because on the last line you effectively allocate Object[10],
while usually you will have much less child futures. We could delay
allocation of array if we store the very first child future as direct
reference. And only second added future should lead to ArrayList
allocation. This should positively affect lots operations with "compound
semantics" and single cache key involved (e.g. single puts/gets).

On Mon, Feb 1, 2016 at 9:08 PM, Yakov Zhdanov  wrote:

> No visible changes to throughput and latency on our common configuration,
> but allocation pressure reduced up to 20% in put-get benchmarks.
>
> --Yakov
>
> 2016-02-01 20:02 GMT+03:00 Dmitriy Setrakyan :
>
> > Any preliminary performance numbers?
> >
> > On Mon, Feb 1, 2016 at 8:52 AM, Yakov Zhdanov 
> wrote:
> >
> > > Vladimir Ozerov and Alex Goncharuk, can you please take a look at PR
> and
> > > provide comments? Other reviewers are welcome, too! =)
> > >
> > > https://github.com/apache/ignite/pull/422
> > >
> > > I did some changes to decrease allocation pressure and fixed force keys
> > > request not to be sent if rebalancing has already been successfully
> > > completed on operation's topology version.
> > >
> > > --Yakov
> > >
> >
>

Re: Full API coverage enhancement

[Artem Shutak]

Dmitriy,

Actually, I don't have a list with all the permutations.

At first, we need to split in our discussion test cases and Ignite
configuration which should be covered.

For example, new Full Api test cases for cache are based on old Full Api
test cases. So, it need to think what the test cases was not covered before.

About Ignite configurations, I'm going to add permutation for each
IgniteConfiguration and CacheConfiguration property.

By the way, the jira contains the following list of permutation (feel free
to add something):

The following tests should be added (for functional blocks):

   1. Interceptor
   2. Queries: continuous, scan, SQL, fields and text queries.
   3. cache events
   4. We should also test with Serializable, Externalizable, and plain
   Pojos for keys and values.
   5. The Pojo in the above test should contain an enum value
   6. We should also test Enums as keys and Enums as values
   7. All operations should have single-key and multi-key operations

New tests should cover all combinations for following properties:

   1. cache modes
   2. operation from client nodes and server nodes
   3. store enabled/disabled
   4. evicts sycn/non-sync
   5. eviction policies
   6. near on/off
   7. marshallers (+ Binary marshaller with different mappers)
   8. keys and values - externalizable, serializable, binaryzable, "none of
   previous"
   9. classes available on servers: true/false
   10. Peer loading on/off
   11. Affinity functions
   12. expiry policies


Thanks,
-- Artem --

On Wed, Feb 3, 2016 at 6:14 PM, Dmitriy Setrakyan 
wrote:

> Artem, I think it is best to specify all the permutations here, so others
> can make additional suggestions. Otherwise, we cannot get a full picture.
>
> Thanks,
> D.
>
> On Wed, Feb 3, 2016 at 2:02 AM, Artem Shutak  wrote:
>
> > Igniters,
> >
> > I thought a little bit more and think we need to add a support for the
> > following permutations too (I've added these to the jira description):
> > - We should also test with Serializable, Externalizable, and plain Pojos
> > for keys and values.
> > - The Pojo in the above test should contain an enum value
> > - We should also test Enums as keys and Enums as values
> > - All operations should have single-key and multi-key operations
> >
> > Maybe someone see any other permutation to be supported?
> >
> > -- Artem --
> >
> > On Tue, Feb 2, 2016 at 10:05 PM, Artem Shutak 
> > wrote:
> >
> > > Dmitriy,
> > >
> > > There is a branch at my fork and a pull request at Ignite. See comment
> > > about pull request at the ticket (PR-446).
> > >
> > > But I have to notice that the branch under hard development and you it
> > can
> > > not work (have compilation or test errors) at some moments.
> > >
> > > Good luck!
> > >
> > > -- Artem --
> > >
> > > On Tue, Feb 2, 2016 at 9:45 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > > wrote:
> > >
> > >> Artem,
> > >>
> > >> This is great. I have noticed from the ticket that you have created
> some
> > >> initial suite already. Is there a branch I can look at it?
> > >>
> > >> D.
> > >>
> > >> On Tue, Feb 2, 2016 at 10:02 AM, Artem Shutak 
> > >> wrote:
> > >>
> > >> > Igniters,
> > >> >
> > >> > I'm working on an enhancement of Full API coverage [1] [2].
> > >> >
> > >> > Ignite already has Full API test, but currently it's hard to test
> all
> > >> > configuration combinations.
> > >> >
> > >> > Feel free to add comments in the jira if you have any thought.
> > >> >
> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-2521
> > >> > [2]
> > >> https://cwiki.apache.org/confluence/display/IGNITE/Implementing+Tests
> > >> >
> > >> > Thanks,
> > >> > -- Artem --
> > >> >
> > >>
> > >
> > >
> >
>

[GitHub] ignite pull request: GridNearLockRequestV2 example implementation.

[ilantukh]

Github user ilantukh closed the pull request at:

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


---
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: About the Jira https://issues.apache.org/jira/browse/IGNITE-1481

[Ken Cheng]

Sorry, my fault I forget to add the new junit to test suit. I committed
again.

Thanks,
kcheng

On Wed, Feb 3, 2016 at 10:17 PM, Ken Cheng  wrote:

> Hi All,
>
> For this PR, I added a new Junit test file file, but I found it's not
> executed from TeamCity build log.
>
> How to add this new file to test suit?
>
> Thanks,
> kcheng
>
> On Wed, Feb 3, 2016 at 8:41 PM, Ken Cheng  wrote:
>
>> Hi Andrey Gura,
>>
>> Please help do a code review.
>> All related test cases passed without break.
>>
>>
>> http://204.14.53.151/viewLog.html?buildId=107343=buildResultsDiv=IgniteTests_IgniteDataGrid
>>
>> Thanks,
>> kcheng
>>
>> On Wed, Feb 3, 2016 at 7:47 PM, Ken Cheng  wrote:
>>
>>> Here is the PR https://github.com/apache/ignite/pull/449
>>>
>>> Please help to review it.
>>>
>>> Thanks,
>>> kcheng
>>>
>>> On Wed, Feb 3, 2016 at 7:45 PM, Ken Cheng  wrote:
>>>
 Yes, that's Andrey's proposal.

 I created the PR, right now it's run Tests.

 Thanks,
 kcheng

 On Wed, Feb 3, 2016 at 6:34 PM, Alexey Goncharuk <
 alexey.goncha...@gmail.com> wrote:

> +1 for printing out a warning and ignoring the affinity function from
> the
> configuration. There is no other way to 'fix' the configuration other
> than
> remove the wrong affinity function, so it can be done at startup time
> right
> away.
>
> 2016-02-03 9:43 GMT+03:00 Ken Cheng :
>
> > I prefer to throw a IgniteCheckerException.
> >
> > Thanks,
> > kcheng
> >
> > On Wed, Feb 3, 2016 at 2:41 PM, Ken Cheng 
> wrote:
> >
> > > Hi Andrey Gura,
> > >
> > >
> > > What's the expected behavior when the cache mode is "Local" but
> affinity
> > > function is not  "LocalAffinityFunction"?
> > >
> > > 1: Throw an exception?
> > > 2: or change the affinity function rudely as
> "LocalAffinityFunction" and
> > > log the warning message at same time?
> > >
> > >
> > > Thanks,
> > > kcheng
> > >
> > > On Wed, Feb 3, 2016 at 10:35 AM, Ken Cheng 
> wrote:
> > >
> > >> Hi Andrey Gura,
> > >>
> > >> Thank you very much! I would study this part of code first.
> > >>
> > >> Thanks,
> > >> kcheng
> > >>
> > >> On Mon, Feb 1, 2016 at 6:37 PM, Andrey Gura 
> wrote:
> > >>
> > >>> Ken,
> > >>>
> > >>> cache configuration validation and initialization occurs in
> > >>> GridCacheProcessor class (methods validate() and initialize()).
> > >>>
> > >>> From my point of view two changes should be made:
> > >>>
> > >>> - during cache intialization LocalAffinityFunction should be set
> to
> > cache
> > >>> configuration if cache mode is LOCAL;
> > >>> - warning about ignoring affinity function parameter should be
> moved
> > from
> > >>> validate() method to intialize() method.
> > >>>
> > >>> I hope this will help you.
> > >>>
> > >>> On Mon, Feb 1, 2016 at 12:12 PM, Ken Cheng  >
> > wrote:
> > >>>
> > >>> > Hi Andrey Gura,
> > >>> >
> > >>> > I am very new to Ignite, I am going to pick up
> > >>> > https://issues.apache.org/jira/browse/IGNITE-1481.
> > >>> >
> > >>> > Can you please give more hint?
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> > >>> > Thanks,
> > >>> > kcheng
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Andrey Gura
> > >>> GridGain Systems, Inc.
> > >>> www.gridgain.com
> > >>>
> > >>
> > >>
> > >
> >
>


>>>
>>
>

Re: about AOP development

[Dmitriy Setrakyan]

This module enables grid-enabling standard Java methods using @Gridify
annotation in conjunction with some AOP framework.  However, AOP is no
longer a popular technology, and we thought that having documentation at
Javadoc level should suffice.

D.

On Wed, Feb 3, 2016 at 3:45 AM, 李玉珏@163 <18624049...@163.com> wrote:

> Hi：
>
> I found the ignite-aop module on github, and I asked what the module is to
> do?
> In addition, this module does not have a document.
>
> 在 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:

Re: [jira] [Commented] (IGNITE-1523) Need to always serialize user objects with configured marshaller

[Valentin Kulichenko]

Anton,

Where can I see the changes?

-Val

On Wed, Feb 3, 2016 at 12:01 AM, Anton Vinogradov 
wrote:

> Val,
>
> I've fixed some cases related to this issue.
> In case you know what is left please describe it at issue and assign to me
>
> On Tue, Feb 2, 2016 at 9:20 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Anton,
> >
> > If you're working in this issue, can you please assign it to yourself?
> >
> > -Val
> >
> > -- Forwarded message --
> > From: Anton Vinogradov (JIRA) 
> > Date: Tue, Feb 2, 2016 at 4:43 AM
> > Subject: [jira] [Commented] (IGNITE-1523) Need to always serialize user
> > objects with configured marshaller
> > To: valentin.kuliche...@gmail.com
> >
> >
> >
> > [
> >
> >
> https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15128185#comment-15128185
> > ]
> >
> > Anton Vinogradov commented on IGNITE-1523:
> > --
> >
> > Fixed unmarshalling of Enum
> > Fixed unmarshalling of CacheStoreFactory within CacheConfiguration
> > All new checks added to GridCacheReplicatedPreloadSelfTest
> >
> > > Need to always serialize user objects with configured marshaller
> > > 
> > >
> > > Key: IGNITE-1523
> > > URL: https://issues.apache.org/jira/browse/IGNITE-1523
> > > Project: Ignite
> > >  Issue Type: Improvement
> > >  Components: general
> > >Reporter: Valentin Kulichenko
> > >Assignee: Valentin Kulichenko
> > >Priority: Critical
> > >  Labels: important, user-request
> > > Fix For: 1.6
> > >
> > >
> > > Currently some components (at least discovery) use {{JdkMarshaller}}
> for
> > all objects.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.4#6332)
> >
>

Proxy serialization issue

[Valentin Kulichenko]

Igniters,

I fixed java.lang.reflect.Proxy serialization in both optimized and binary
marshaller. Can someone familiar with marshalling code review my changes
before I merge? Patch is attached to the ticket [1].

[1] https://issues.apache.org/jira/browse/IGNITE-2450

Thanks!

-Val

Re: Full API coverage enhancement

[Alexey Kuznetsov]

Artem, could you describe (in general) how are you going to describe
permutations?

Are you going to run tests with all possible combinations of all possible
properties?

Along time ago I implemented smth. similar (not in java)  and
 I created framework where I could describe nested rules of what I want to
investigate and
 engine that read that rules and iterate over all possible combination of
rules and execute some action.

Maybe this will be useful to you.


On Wed, Feb 3, 2016 at 10:40 PM, Artem Shutak  wrote:

> Dmitriy,
>
> Actually, I don't have a list with all the permutations.
>
> At first, we need to split in our discussion test cases and Ignite
> configuration which should be covered.
>
> For example, new Full Api test cases for cache are based on old Full Api
> test cases. So, it need to think what the test cases was not covered
> before.
>
> About Ignite configurations, I'm going to add permutation for each
> IgniteConfiguration and CacheConfiguration property.
>
> By the way, the jira contains the following list of permutation (feel free
> to add something):
>
> The following tests should be added (for functional blocks):
>
>1. Interceptor
>2. Queries: continuous, scan, SQL, fields and text queries.
>3. cache events
>4. We should also test with Serializable, Externalizable, and plain
>Pojos for keys and values.
>5. The Pojo in the above test should contain an enum value
>6. We should also test Enums as keys and Enums as values
>7. All operations should have single-key and multi-key operations
>
> New tests should cover all combinations for following properties:
>
>1. cache modes
>2. operation from client nodes and server nodes
>3. store enabled/disabled
>4. evicts sycn/non-sync
>5. eviction policies
>6. near on/off
>7. marshallers (+ Binary marshaller with different mappers)
>8. keys and values - externalizable, serializable, binaryzable, "none of
>previous"
>9. classes available on servers: true/false
>10. Peer loading on/off
>11. Affinity functions
>12. expiry policies
>
>
> Thanks,
> -- Artem --
>
> On Wed, Feb 3, 2016 at 6:14 PM, Dmitriy Setrakyan 
> wrote:
>
> > Artem, I think it is best to specify all the permutations here, so others
> > can make additional suggestions. Otherwise, we cannot get a full picture.
> >
> > Thanks,
> > D.
> >
> > On Wed, Feb 3, 2016 at 2:02 AM, Artem Shutak 
> wrote:
> >
> > > Igniters,
> > >
> > > I thought a little bit more and think we need to add a support for the
> > > following permutations too (I've added these to the jira description):
> > > - We should also test with Serializable, Externalizable, and plain
> Pojos
> > > for keys and values.
> > > - The Pojo in the above test should contain an enum value
> > > - We should also test Enums as keys and Enums as values
> > > - All operations should have single-key and multi-key operations
> > >
> > > Maybe someone see any other permutation to be supported?
> > >
> > > -- Artem --
> > >
> > > On Tue, Feb 2, 2016 at 10:05 PM, Artem Shutak 
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > There is a branch at my fork and a pull request at Ignite. See
> comment
> > > > about pull request at the ticket (PR-446).
> > > >
> > > > But I have to notice that the branch under hard development and you
> it
> > > can
> > > > not work (have compilation or test errors) at some moments.
> > > >
> > > > Good luck!
> > > >
> > > > -- Artem --
> > > >
> > > > On Tue, Feb 2, 2016 at 9:45 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >
> > > > wrote:
> > > >
> > > >> Artem,
> > > >>
> > > >> This is great. I have noticed from the ticket that you have created
> > some
> > > >> initial suite already. Is there a branch I can look at it?
> > > >>
> > > >> D.
> > > >>
> > > >> On Tue, Feb 2, 2016 at 10:02 AM, Artem Shutak  >
> > > >> wrote:
> > > >>
> > > >> > Igniters,
> > > >> >
> > > >> > I'm working on an enhancement of Full API coverage [1] [2].
> > > >> >
> > > >> > Ignite already has Full API test, but currently it's hard to test
> > all
> > > >> > configuration combinations.
> > > >> >
> > > >> > Feel free to add comments in the jira if you have any thought.
> > > >> >
> > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-2521
> > > >> > [2]
> > > >>
> https://cwiki.apache.org/confluence/display/IGNITE/Implementing+Tests
> > > >> >
> > > >> > Thanks,
> > > >> > -- Artem --
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Full API coverage enhancement

[Dmitriy Setrakyan]

Thanks Artem! In your view, how many combinations of the configuration
properties will be tested together. I don’t think we can afford to test
every possible combination.

On Wed, Feb 3, 2016 at 7:40 AM, Artem Shutak  wrote:

> Dmitriy,
>
> Actually, I don't have a list with all the permutations.
>
> At first, we need to split in our discussion test cases and Ignite
> configuration which should be covered.
>
> For example, new Full Api test cases for cache are based on old Full Api
> test cases. So, it need to think what the test cases was not covered
> before.
>
> About Ignite configurations, I'm going to add permutation for each
> IgniteConfiguration and CacheConfiguration property.
>
> By the way, the jira contains the following list of permutation (feel free
> to add something):
>
> The following tests should be added (for functional blocks):
>
>1. Interceptor
>2. Queries: continuous, scan, SQL, fields and text queries.
>3. cache events
>4. We should also test with Serializable, Externalizable, and plain
>Pojos for keys and values.
>5. The Pojo in the above test should contain an enum value
>6. We should also test Enums as keys and Enums as values
>7. All operations should have single-key and multi-key operations
>
> New tests should cover all combinations for following properties:
>
>1. cache modes
>2. operation from client nodes and server nodes
>3. store enabled/disabled
>4. evicts sycn/non-sync
>5. eviction policies
>6. near on/off
>7. marshallers (+ Binary marshaller with different mappers)
>8. keys and values - externalizable, serializable, binaryzable, "none of
>previous"
>9. classes available on servers: true/false
>10. Peer loading on/off
>11. Affinity functions
>12. expiry policies
>
>
> Thanks,
> -- Artem --
>
> On Wed, Feb 3, 2016 at 6:14 PM, Dmitriy Setrakyan 
> wrote:
>
> > Artem, I think it is best to specify all the permutations here, so others
> > can make additional suggestions. Otherwise, we cannot get a full picture.
> >
> > Thanks,
> > D.
> >
> > On Wed, Feb 3, 2016 at 2:02 AM, Artem Shutak 
> wrote:
> >
> > > Igniters,
> > >
> > > I thought a little bit more and think we need to add a support for the
> > > following permutations too (I've added these to the jira description):
> > > - We should also test with Serializable, Externalizable, and plain
> Pojos
> > > for keys and values.
> > > - The Pojo in the above test should contain an enum value
> > > - We should also test Enums as keys and Enums as values
> > > - All operations should have single-key and multi-key operations
> > >
> > > Maybe someone see any other permutation to be supported?
> > >
> > > -- Artem --
> > >
> > > On Tue, Feb 2, 2016 at 10:05 PM, Artem Shutak 
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > There is a branch at my fork and a pull request at Ignite. See
> comment
> > > > about pull request at the ticket (PR-446).
> > > >
> > > > But I have to notice that the branch under hard development and you
> it
> > > can
> > > > not work (have compilation or test errors) at some moments.
> > > >
> > > > Good luck!
> > > >
> > > > -- Artem --
> > > >
> > > > On Tue, Feb 2, 2016 at 9:45 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >
> > > > wrote:
> > > >
> > > >> Artem,
> > > >>
> > > >> This is great. I have noticed from the ticket that you have created
> > some
> > > >> initial suite already. Is there a branch I can look at it?
> > > >>
> > > >> D.
> > > >>
> > > >> On Tue, Feb 2, 2016 at 10:02 AM, Artem Shutak  >
> > > >> wrote:
> > > >>
> > > >> > Igniters,
> > > >> >
> > > >> > I'm working on an enhancement of Full API coverage [1] [2].
> > > >> >
> > > >> > Ignite already has Full API test, but currently it's hard to test
> > all
> > > >> > configuration combinations.
> > > >> >
> > > >> > Feel free to add comments in the jira if you have any thought.
> > > >> >
> > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-2521
> > > >> > [2]
> > > >>
> https://cwiki.apache.org/confluence/display/IGNITE/Implementing+Tests
> > > >> >
> > > >> > Thanks,
> > > >> > -- Artem --
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Review request

[Dmitriy Setrakyan]

On Wed, Feb 3, 2016 at 7:02 AM, Vladimir Ozerov 
wrote:

> As per cache - I hardly understand affected logic, so my review wouldn't
> help much here.
>
> As per the rest changes - looks good for me. I also see garbage from NIO
> and "force keys" as huge memory hotspots. The only problem is
> GridCompoundFuture:
>
> if (futs == null)
> futs = new ArrayList<>();
>
> futs.add(fut);
>
>
> Things like this are proven to be anti-pattern in terms of memory
> allocations, because on the last line you effectively allocate Object[10],
> while usually you will have much less child futures. We could delay
> allocation of array if we store the very first child future as direct
> reference. And only second added future should lead to ArrayList
> allocation. This should positively affect lots operations with "compound
> semantics" and single cache key involved (e.g. single puts/gets).
>

Vova,
I couldn’t agree more. Can we try it out and see what kind of GC or
performance improvement we get?


> On Mon, Feb 1, 2016 at 9:08 PM, Yakov Zhdanov  wrote:
>
> > No visible changes to throughput and latency on our common configuration,
> > but allocation pressure reduced up to 20% in put-get benchmarks.
> >
> > --Yakov
> >
> > 2016-02-01 20:02 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Any preliminary performance numbers?
> > >
> > > On Mon, Feb 1, 2016 at 8:52 AM, Yakov Zhdanov 
> > wrote:
> > >
> > > > Vladimir Ozerov and Alex Goncharuk, can you please take a look at PR
> > and
> > > > provide comments? Other reviewers are welcome, too! =)
> > > >
> > > > https://github.com/apache/ignite/pull/422
> > > >
> > > > I did some changes to decrease allocation pressure and fixed force
> keys
> > > > request not to be sent if rebalancing has already been successfully
> > > > completed on operation's topology version.
> > > >
> > > > --Yakov
> > > >
> > >
> >
>

Re: Review request

[Yakov Zhdanov]

I think we should not allocate list at all! We can just add listener to
added futures!:) and the semantics will be preserved!

However this will not work if we want to iterate over the added ones.
Number of unfinished futures will be still available through listener calls
count. Let me review.

If this doesn't work, we can maintain an array on our own.

And the last point.. This GC impact should be measured. What happen if you
add a reference to future and reference to collection?

Yakov
On Feb 3, 2016 7:44 PM, "Dmitriy Setrakyan"  wrote:

> On Wed, Feb 3, 2016 at 7:02 AM, Vladimir Ozerov 
> wrote:
>
> > As per cache - I hardly understand affected logic, so my review wouldn't
> > help much here.
> >
> > As per the rest changes - looks good for me. I also see garbage from NIO
> > and "force keys" as huge memory hotspots. The only problem is
> > GridCompoundFuture:
> >
> > if (futs == null)
> > futs = new ArrayList<>();
> >
> > futs.add(fut);
> >
> >
> > Things like this are proven to be anti-pattern in terms of memory
> > allocations, because on the last line you effectively allocate
> Object[10],
> > while usually you will have much less child futures. We could delay
> > allocation of array if we store the very first child future as direct
> > reference. And only second added future should lead to ArrayList
> > allocation. This should positively affect lots operations with "compound
> > semantics" and single cache key involved (e.g. single puts/gets).
> >
>
> Vova,
> I couldn’t agree more. Can we try it out and see what kind of GC or
> performance improvement we get?
>
>
> > On Mon, Feb 1, 2016 at 9:08 PM, Yakov Zhdanov 
> wrote:
> >
> > > No visible changes to throughput and latency on our common
> configuration,
> > > but allocation pressure reduced up to 20% in put-get benchmarks.
> > >
> > > --Yakov
> > >
> > > 2016-02-01 20:02 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Any preliminary performance numbers?
> > > >
> > > > On Mon, Feb 1, 2016 at 8:52 AM, Yakov Zhdanov 
> > > wrote:
> > > >
> > > > > Vladimir Ozerov and Alex Goncharuk, can you please take a look at
> PR
> > > and
> > > > > provide comments? Other reviewers are welcome, too! =)
> > > > >
> > > > > https://github.com/apache/ignite/pull/422
> > > > >
> > > > > I did some changes to decrease allocation pressure and fixed force
> > keys
> > > > > request not to be sent if rebalancing has already been successfully
> > > > > completed on operation's topology version.
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > >
> >
>

Re: Transformers in SCAN queries

[Valentin Kulichenko]

Dmitry,

The main difference in my view is that you lose pagination when sending
results from servers to client. What if one wants to iterate through all
entries in cache?

On Wed, Feb 3, 2016 at 9:47 PM, Dmitriy Setrakyan 
wrote:

> Valentin,
>
> Wouldn’t the same effect be achieved by broadcasting a closure to the
> cluster and executing scan-query on every node locally?
>
> D.
>
> On Wed, Feb 3, 2016 at 9:17 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igniters,
> >
> > I keep getting requests from our users to add optional transformers to
> SCAN
> > queries. This will allow to iterate through cache, but do not transfer
> > whole key-value pairs across networks (e.g., get only keys). The feature
> > looks useful and I created a ticket [1].
> >
> > I am struggling with the design now. The problem is that I wanted to
> extend
> > existing ScanQuery object for this, but this seems to be impossible
> because
> > it already extends Query> and thus can iterate only
> > through entries.
> >
> > The only option I see now is to create a separate query type, copy-paste
> > everything from ScanQuery and add *mandatory* transformer. Something like
> > this:
> >
> > ScanTransformQuery extends Query {
> > IgniteBiPredicate filter;
> > IgniteClosure, R> transformer;
> > int part;
> > ...
> > }
> >
> > Thoughts? Does anyone has other ideas?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-2546
> >
> > -Val
> >
>

[jira] [Created] (IGNITE-2546) Need to introduce transformers to SCAN queries

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2546:
---

 Summary: Need to introduce transformers to SCAN queries
 Key: IGNITE-2546
 URL: https://issues.apache.org/jira/browse/IGNITE-2546
 Project: Ignite
  Issue Type: Improvement
Reporter: Valentin Kulichenko
 Fix For: 1.6






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

[jira] [Created] (IGNITE-2547) Expand node with metadata for current selected cache

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-2547:


 Summary: Expand node with metadata for current selected cache
 Key: IGNITE-2547
 URL: https://issues.apache.org/jira/browse/IGNITE-2547
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Reporter: Alexey Kuznetsov
Priority: Minor


In current implementation we show all caches metadata collapsed, but it make 
sense to expand node for current selected cache.



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

Re: Transformers in SCAN queries

[Dmitriy Setrakyan]

Valentin,

Wouldn’t the same effect be achieved by broadcasting a closure to the
cluster and executing scan-query on every node locally?

D.

On Wed, Feb 3, 2016 at 9:17 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igniters,
>
> I keep getting requests from our users to add optional transformers to SCAN
> queries. This will allow to iterate through cache, but do not transfer
> whole key-value pairs across networks (e.g., get only keys). The feature
> looks useful and I created a ticket [1].
>
> I am struggling with the design now. The problem is that I wanted to extend
> existing ScanQuery object for this, but this seems to be impossible because
> it already extends Query> and thus can iterate only
> through entries.
>
> The only option I see now is to create a separate query type, copy-paste
> everything from ScanQuery and add *mandatory* transformer. Something like
> this:
>
> ScanTransformQuery extends Query {
> IgniteBiPredicate filter;
> IgniteClosure, R> transformer;
> int part;
> ...
> }
>
> Thoughts? Does anyone has other ideas?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-2546
>
> -Val
>

Transformers in SCAN queries

[Valentin Kulichenko]

Igniters,

I keep getting requests from our users to add optional transformers to SCAN
queries. This will allow to iterate through cache, but do not transfer
whole key-value pairs across networks (e.g., get only keys). The feature
looks useful and I created a ticket [1].

I am struggling with the design now. The problem is that I wanted to extend
existing ScanQuery object for this, but this seems to be impossible because
it already extends Query> and thus can iterate only
through entries.

The only option I see now is to create a separate query type, copy-paste
everything from ScanQuery and add *mandatory* transformer. Something like
this:

ScanTransformQuery extends Query {
IgniteBiPredicate filter;
IgniteClosure, R> transformer;
int part;
...
}

Thoughts? Does anyone has other ideas?

[1] https://issues.apache.org/jira/browse/IGNITE-2546

-Val

Re: [jira] [Commented] (IGNITE-1523) Need to always serialize user objects with configured marshaller

[Anton Vinogradov]

Val,

Please see commit 28a5247d37ba65bdcb6119f97023f32d511b5f1e at master.

On Thu, Feb 4, 2016 at 3:53 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Anton,
>
> Where can I see the changes?
>
> -Val
>
> On Wed, Feb 3, 2016 at 12:01 AM, Anton Vinogradov <
> avinogra...@gridgain.com>
> wrote:
>
> > Val,
> >
> > I've fixed some cases related to this issue.
> > In case you know what is left please describe it at issue and assign to
> me
> >
> > On Tue, Feb 2, 2016 at 9:20 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Anton,
> > >
> > > If you're working in this issue, can you please assign it to yourself?
> > >
> > > -Val
> > >
> > > -- Forwarded message --
> > > From: Anton Vinogradov (JIRA) 
> > > Date: Tue, Feb 2, 2016 at 4:43 AM
> > > Subject: [jira] [Commented] (IGNITE-1523) Need to always serialize user
> > > objects with configured marshaller
> > > To: valentin.kuliche...@gmail.com
> > >
> > >
> > >
> > > [
> > >
> > >
> >
> https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15128185#comment-15128185
> > > ]
> > >
> > > Anton Vinogradov commented on IGNITE-1523:
> > > --
> > >
> > > Fixed unmarshalling of Enum
> > > Fixed unmarshalling of CacheStoreFactory within CacheConfiguration
> > > All new checks added to GridCacheReplicatedPreloadSelfTest
> > >
> > > > Need to always serialize user objects with configured marshaller
> > > > 
> > > >
> > > > Key: IGNITE-1523
> > > > URL:
> https://issues.apache.org/jira/browse/IGNITE-1523
> > > > Project: Ignite
> > > >  Issue Type: Improvement
> > > >  Components: general
> > > >Reporter: Valentin Kulichenko
> > > >Assignee: Valentin Kulichenko
> > > >Priority: Critical
> > > >  Labels: important, user-request
> > > > Fix For: 1.6
> > > >
> > > >
> > > > Currently some components (at least discovery) use {{JdkMarshaller}}
> > for
> > > all objects.
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v6.3.4#6332)
> > >
> >
>

Re: Transformers in SCAN queries

[Dmitriy Setrakyan]

On Wed, Feb 3, 2016 at 10:28 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Dmitry,
>
> The main difference in my view is that you lose pagination when sending
> results from servers to client. What if one wants to iterate through all
> entries in cache?
>

I see. Perhaps we should fix the pagination for compute instead of adding
transformers for queries?


>
> On Wed, Feb 3, 2016 at 9:47 PM, Dmitriy Setrakyan 
> wrote:
>
> > Valentin,
> >
> > Wouldn’t the same effect be achieved by broadcasting a closure to the
> > cluster and executing scan-query on every node locally?
> >
> > D.
> >
> > On Wed, Feb 3, 2016 at 9:17 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > I keep getting requests from our users to add optional transformers to
> > SCAN
> > > queries. This will allow to iterate through cache, but do not transfer
> > > whole key-value pairs across networks (e.g., get only keys). The
> feature
> > > looks useful and I created a ticket [1].
> > >
> > > I am struggling with the design now. The problem is that I wanted to
> > extend
> > > existing ScanQuery object for this, but this seems to be impossible
> > because
> > > it already extends Query> and thus can iterate only
> > > through entries.
> > >
> > > The only option I see now is to create a separate query type,
> copy-paste
> > > everything from ScanQuery and add *mandatory* transformer. Something
> like
> > > this:
> > >
> > > ScanTransformQuery extends Query {
> > > IgniteBiPredicate filter;
> > > IgniteClosure, R> transformer;
> > > int part;
> > > ...
> > > }
> > >
> > > Thoughts? Does anyone has other ideas?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-2546
> > >
> > > -Val
> > >
> >
>

Re: About the Jira https://issues.apache.org/jira/browse/IGNITE-1481

[Ken Cheng]

Yes, that's Andrey's proposal.

I created the PR, right now it's run Tests.

Thanks,
kcheng

On Wed, Feb 3, 2016 at 6:34 PM, Alexey Goncharuk  wrote:

> +1 for printing out a warning and ignoring the affinity function from the
> configuration. There is no other way to 'fix' the configuration other than
> remove the wrong affinity function, so it can be done at startup time right
> away.
>
> 2016-02-03 9:43 GMT+03:00 Ken Cheng :
>
> > I prefer to throw a IgniteCheckerException.
> >
> > Thanks,
> > kcheng
> >
> > On Wed, Feb 3, 2016 at 2:41 PM, Ken Cheng  wrote:
> >
> > > Hi Andrey Gura,
> > >
> > >
> > > What's the expected behavior when the cache mode is "Local" but
> affinity
> > > function is not  "LocalAffinityFunction"?
> > >
> > > 1: Throw an exception?
> > > 2: or change the affinity function rudely as "LocalAffinityFunction"
> and
> > > log the warning message at same time?
> > >
> > >
> > > Thanks,
> > > kcheng
> > >
> > > On Wed, Feb 3, 2016 at 10:35 AM, Ken Cheng 
> wrote:
> > >
> > >> Hi Andrey Gura,
> > >>
> > >> Thank you very much! I would study this part of code first.
> > >>
> > >> Thanks,
> > >> kcheng
> > >>
> > >> On Mon, Feb 1, 2016 at 6:37 PM, Andrey Gura 
> wrote:
> > >>
> > >>> Ken,
> > >>>
> > >>> cache configuration validation and initialization occurs in
> > >>> GridCacheProcessor class (methods validate() and initialize()).
> > >>>
> > >>> From my point of view two changes should be made:
> > >>>
> > >>> - during cache intialization LocalAffinityFunction should be set to
> > cache
> > >>> configuration if cache mode is LOCAL;
> > >>> - warning about ignoring affinity function parameter should be moved
> > from
> > >>> validate() method to intialize() method.
> > >>>
> > >>> I hope this will help you.
> > >>>
> > >>> On Mon, Feb 1, 2016 at 12:12 PM, Ken Cheng 
> > wrote:
> > >>>
> > >>> > Hi Andrey Gura,
> > >>> >
> > >>> > I am very new to Ignite, I am going to pick up
> > >>> > https://issues.apache.org/jira/browse/IGNITE-1481.
> > >>> >
> > >>> > Can you please give more hint?
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> > >>> > Thanks,
> > >>> > kcheng
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Andrey Gura
> > >>> GridGain Systems, Inc.
> > >>> www.gridgain.com
> > >>>
> > >>
> > >>
> > >
> >
>

Fwd: Ticket IGNITE-1497

[Andrey Gura]

Thorsten,

good news! I'll close IGNITE-1497 ticket.

Thanks a lot!

-- Forwarded message --
From: Thorsten Raff 
Date: Wed, Feb 3, 2016 at 8:20 PM
Subject: Re: Ticket IGNITE-1497
To: Andrey Gura 


Hi Andrey,

I have built ignite from source and connected one Raspberry Pi node and one
node on a desktop PC together and it worked.

Thank you very much for your help.

Regards,
Thorsten

2016-02-03 11:40 GMT+01:00 Andrey Gura :

> Hi Thorsten!
>
> IGNITE-2080 should fix this problem. Fix was merged into master branch
> yesterday.
> So you can build latest Ignite from sources and try to run it on your
> device.
>
> Please, let me know about result.
>
> Thanks!
>
>
> On Wed, Feb 3, 2016 at 12:35 PM, Yakov Zhdanov 
> wrote:
>
>> Hello Thorsten!
>>
>> I am not working on this ticket and most probably will not have time to
>> start in nearest future.
>>
>> I am CCing project's dev list. Andrey Gura, can you please respond -
>> whether this issue is fixed or not with
>> https://issues.apache.org/jira/browse/IGNITE-2080 fix?
>>
>> --Yakov
>>
>> 2016-02-03 10:47 GMT+03:00 :
>>
>> > Hello,
>> >
>> > I've seen that you are assigned to the Apache Ignite Ticket IGNITE-1497
>> > (Support CPU architectures different from x86/x64).
>> > I'm am actually trying to run Ignite on an Raspberry PI 2 for my Master
>> > Dissertation and figured out, that the JVM crashes if I connect two
>> Ignite
>> > Nodes with the error described in the ticket.
>> > Are you working on this ticket? And do you know when a fixed version of
>> > Ignite will be available for download?
>> >
>> > Thank you for your time.
>> >
>> > Kind Regards,
>> > Thorsten Raff
>> >
>> > _
>> > Sent from http://apache-ignite-users.70518.x6.nabble.com
>> >
>> >
>>
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>




-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

[jira] [Created] (IGNITE-2543) ODBC: Tables look up should return tables from other caches as well.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-2543:
---

 Summary: ODBC: Tables look up should return tables from other 
caches as well.
 Key: IGNITE-2543
 URL: https://issues.apache.org/jira/browse/IGNITE-2543
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.6


Currently ODBC {{SQLTables}} function only returns tables from current cache. 
Should return from any.



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

[jira] [Created] (IGNITE-2544) ODBC: It should be available to make requests to default (null) cache.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-2544:
---

 Summary: ODBC: It should be available to make requests to default 
(null) cache.
 Key: IGNITE-2544
 URL: https://issues.apache.org/jira/browse/IGNITE-2544
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.6


I propose to treat empty cache name as if user wants to connect to null-cache.



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

[jira] [Created] (IGNITE-2545) GridCompoundFuture: Allocate ArrayList only if there are >1 futures.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2545:
---

 Summary: GridCompoundFuture: Allocate ArrayList only if there are 
>1 futures.
 Key: IGNITE-2545
 URL: https://issues.apache.org/jira/browse/IGNITE-2545
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
 Fix For: 1.6


*Problem*
When GridCompoundFuture is created, empty emoty ArrayList for child futures is 
allocated immediately. When the very first child future is added, ArrayList 
automatically expands to Object[10]. 
But in most cases we will have much less than 10 futures, and quite often there 
will be only one.

*Proposal*
1) Run base put/get benchmarks with a single key and several nodes and estimate 
amount of child futures. This case be as easy as adding System.out() to 
GridCompoundFuture.init() method which will print list size.
2) Depending on the result we should do one of the following:
- Allocate ArrayList only after second future is added;
- Or allocate ArrayList with fewer amount of elemnts (say, 4) - this depends on 
what we will see in during tests.

This should be fairly simple to check and implement.



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

[GitHub] ignite pull request: IGNITE-1144 Queue and Set affinity run and ca...

[oddodaoddo]

GitHub user oddodaoddo opened a pull request:

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

IGNITE-1144 Queue and Set affinity run and call function additions



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

$ git pull https://github.com/oddodaoddo/ignite master

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

https://github.com/apache/ignite/pull/453.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 #453


commit 394a023f234c48cb78b633aec342bed938aecea8
Author: Oddo Da 
Date:   2016-02-03T18:33:01Z

Queue and Set affinity run and call function additions




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