[jira] [Created] (IGNITE-1661) memory leak

[wjw465150 (JIRA)]

wjw465150 created IGNITE-1661:
-

 Summary: memory leak
 Key: IGNITE-1661
 URL: https://issues.apache.org/jira/browse/IGNITE-1661
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
 Environment: centos 6.3
Reporter: wjw465150


when use withExpiryPolicy cache,and CacheConfiguration.eagerTtl is set true, 
this will cause heap memory leak!
code sample:
IgniteCache cacheDefault = 
ignite.cache("default");
cache1 = cacheDefault.withExpiryPolicy(new 
CreatedExpiryPolicy(new Duration(TimeUnit.MINUTES, 30)));




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

Re: .Net: separate methods for async operations.

[Pavel Tupitsyn]

> I disagree here. I think consistency matters.
> Moreover, based on the previous .NET examples you have provided, I do not
see much difference between .NET and Java, other than different syntax

What really matters is consistency with the rest of .NET platform. There
are clear design guidelines:
https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
These guidelines are followed throughout standard APIs. Everyone is used to
them.

Really, there is no need to invent anything. It won't be better. "When in
Rome, do as the Romans do".

Thanks,


On Tue, Oct 13, 2015 at 8:56 AM, Vladimir Ozerov 
wrote:

> Dima,
>
> I do not like JSR 107 v1.1 approach. First, it is not user friendly.
> Second, it is prone to deadlock/starvation problems we are currently
> discussing in another thread because these "Collectors" are continuations
> essentially.
>
> On Tue, Oct 13, 2015 at 12:42 AM, Dmitriy Setrakyan  >
> wrote:
>
> > I just took a look at JSR 107, and looks like they are taking a different
> > (in my view not as elegant) route:
> >
> >
> https://github.com/jsr107/jsr107spec/blob/async/src/main/java/javax/cache/Cache.java
> >
> > Any thoughts on this?
> >
> > D.
> >
> > On Mon, Oct 12, 2015 at 11:11 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Well, if we asume that the most common usage will be
> > > IgniteCache.async().doSomething(), then yes - backwards transformation
> is
> > > not necessary.
> > >
> > > All in all this approach seems to be the most clean among other
> > suggested.
> > >
> > > On Mon, Oct 12, 2015 at 8:38 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > I mostly agree with your points except naming and hierarchy:
> > > >
> > > > 1. I don't like CacheAsync, it is ugly.
> > > >
> > > > 2. If IgniteCache extends AsyncCache then we can't use the same names
> > for
> > > > methods, we will be forced to use *blaAsync(...)* format
> > > > which is ugly for me as well. Also this will pollute sync API with
> > async
> > > > one, while we are trying to avoid that.
> > > >
> > > > Sergi
> > > >
> > > > 2015-10-12 20:28 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > On Mon, Oct 12, 2015 at 10:15 AM, Vladimir Ozerov <
> > > voze...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > > > The problem with this approach is that not all methods are async.
> > > E.g.
> > > > > > name(), lock(K), iterator(), etc.. So you should either mix sync
> > and
> > > > > async
> > > > > > methods in AsyncCache still, or expose only async methods.
> > > > >
> > > > >
> > > > > I think AsyncCache, or rather CacheAsync, should expose only async
> > > > methods.
> > > > > Moreover, should IgniteCache simply extend CacheAsync API?
> > > > >
> > > > >
> > > > > > In the latter case we will require backwards
> > > > > > transformation: IgniteCache AsyncCache.sync().
> > > > > >
> > > > >
> > > > > Not sure this is needed.
> > > > >
> > > > >
> > > > > > Consistency between platforms should have minimal priority. .Net
> > and
> > > > Java
> > > > > > are very different. For example we cannot even have "V Get(K)"
> > method
> > > > in
> > > > > > .Net cache. Instead we have "V TryGet(K, out bool)" because .Net
> > > > supports
> > > > > > structs and have full generics support and naive Java approach
> > simply
> > > > > > doesn't work here. Base concepts must be the same across
> platforms,
> > > but
> > > > > > methods signatures and grouping will be different.
> > > > > >
> > > > >
> > > > > I disagree here. I think consistency matters. Moreover, based on
> the
> > > > > previous .NET examples you have provided, I do not see much
> > difference
> > > > > between .NET and Java, other than different syntax. I think the
> same
> > > > > CacheAsync design can be applied to both.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 12, 2015 at 7:53 PM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > In my view we should not pollute sync APIs with all async
> > methods,
> > > > > > > definitely we have to separate them
> > > > > > > for better UX.
> > > > > > >
> > > > > > > Currently on Java we have IgniteAsyncSupport with method
> > > withAsync()
> > > > > > which
> > > > > > > returns the same sync API
> > > > > > > but that API works in broken manner. Instead it should look
> like
> > > the
> > > > > > > following IMO
> > > > > > >
> > > > > > > interface AsyncSupport {
> > > > > > > X async();
> > > > > > > }
> > > > > > >
> > > > > > > Where X will be an interface with respective async API.  For
> > > example
> > > > > for
> > > > > > > IngneCache we will have AsyncCache
> > > > > > > with all the respective async variants of all methods. Like
> this
> > > > > > >
> > > > > > > interface IgniteCache extends
> AsyncSupport>
> > {
> > > > > > > V get(K key);
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > interface AsyncCache {
> > > > > > > IgniteFuture get(K ke

hello

[姜 为]

Hello everyone, I want to to contribute to ignite and learning, nice to meet 
you!

Re: .Net: separate methods for async operations.

[Dmitriy Setrakyan]

On Mon, Oct 12, 2015 at 10:56 PM, Vladimir Ozerov 
wrote:

> Dima,
>
> I do not like JSR 107 v1.1 approach. First, it is not user friendly.
> Second, it is prone to deadlock/starvation problems we are currently
> discussing in another thread because these "Collectors" are continuations
> essentially.
>

Do we have a choice here? We will have to implement JSR107 anyway. Let's
just make sure that whatever approach we come up with does not contradict
JSR107 functionality.


>
> On Tue, Oct 13, 2015 at 12:42 AM, Dmitriy Setrakyan  >
> wrote:
>
> > I just took a look at JSR 107, and looks like they are taking a different
> > (in my view not as elegant) route:
> >
> >
> https://github.com/jsr107/jsr107spec/blob/async/src/main/java/javax/cache/Cache.java
> >
> > Any thoughts on this?
> >
> > D.
> >
> > On Mon, Oct 12, 2015 at 11:11 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Well, if we asume that the most common usage will be
> > > IgniteCache.async().doSomething(), then yes - backwards transformation
> is
> > > not necessary.
> > >
> > > All in all this approach seems to be the most clean among other
> > suggested.
> > >
> > > On Mon, Oct 12, 2015 at 8:38 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > I mostly agree with your points except naming and hierarchy:
> > > >
> > > > 1. I don't like CacheAsync, it is ugly.
> > > >
> > > > 2. If IgniteCache extends AsyncCache then we can't use the same names
> > for
> > > > methods, we will be forced to use *blaAsync(...)* format
> > > > which is ugly for me as well. Also this will pollute sync API with
> > async
> > > > one, while we are trying to avoid that.
> > > >
> > > > Sergi
> > > >
> > > > 2015-10-12 20:28 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > On Mon, Oct 12, 2015 at 10:15 AM, Vladimir Ozerov <
> > > voze...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > > > The problem with this approach is that not all methods are async.
> > > E.g.
> > > > > > name(), lock(K), iterator(), etc.. So you should either mix sync
> > and
> > > > > async
> > > > > > methods in AsyncCache still, or expose only async methods.
> > > > >
> > > > >
> > > > > I think AsyncCache, or rather CacheAsync, should expose only async
> > > > methods.
> > > > > Moreover, should IgniteCache simply extend CacheAsync API?
> > > > >
> > > > >
> > > > > > In the latter case we will require backwards
> > > > > > transformation: IgniteCache AsyncCache.sync().
> > > > > >
> > > > >
> > > > > Not sure this is needed.
> > > > >
> > > > >
> > > > > > Consistency between platforms should have minimal priority. .Net
> > and
> > > > Java
> > > > > > are very different. For example we cannot even have "V Get(K)"
> > method
> > > > in
> > > > > > .Net cache. Instead we have "V TryGet(K, out bool)" because .Net
> > > > supports
> > > > > > structs and have full generics support and naive Java approach
> > simply
> > > > > > doesn't work here. Base concepts must be the same across
> platforms,
> > > but
> > > > > > methods signatures and grouping will be different.
> > > > > >
> > > > >
> > > > > I disagree here. I think consistency matters. Moreover, based on
> the
> > > > > previous .NET examples you have provided, I do not see much
> > difference
> > > > > between .NET and Java, other than different syntax. I think the
> same
> > > > > CacheAsync design can be applied to both.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 12, 2015 at 7:53 PM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > In my view we should not pollute sync APIs with all async
> > methods,
> > > > > > > definitely we have to separate them
> > > > > > > for better UX.
> > > > > > >
> > > > > > > Currently on Java we have IgniteAsyncSupport with method
> > > withAsync()
> > > > > > which
> > > > > > > returns the same sync API
> > > > > > > but that API works in broken manner. Instead it should look
> like
> > > the
> > > > > > > following IMO
> > > > > > >
> > > > > > > interface AsyncSupport {
> > > > > > > X async();
> > > > > > > }
> > > > > > >
> > > > > > > Where X will be an interface with respective async API.  For
> > > example
> > > > > for
> > > > > > > IngneCache we will have AsyncCache
> > > > > > > with all the respective async variants of all methods. Like
> this
> > > > > > >
> > > > > > > interface IgniteCache extends
> AsyncSupport>
> > {
> > > > > > > V get(K key);
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > interface AsyncCache {
> > > > > > > IgniteFuture get(K key);
> > > > > > > }
> > > > > > >
> > > > > > > From implementation standpoint both interfaces can be
> implemented
> > > by
> > > > > the
> > > > > > > same class but for user API
> > > > > > > they will be conveniently separated. Implementation of every
> sync
> > > > > method
> > > > > > is
> > > > > > > trivial if we have
> > > > > > > async counterpart: just call get() on rece

Re: .Net: separate methods for async operations.

[Dmitriy Setrakyan]

On Tue, Oct 13, 2015 at 1:54 AM, Pavel Tupitsyn 
wrote:

> > I disagree here. I think consistency matters.
> > Moreover, based on the previous .NET examples you have provided, I do not
> see much difference between .NET and Java, other than different syntax
>
> What really matters is consistency with the rest of .NET platform. There
> are clear design guidelines:
> https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
> These guidelines are followed throughout standard APIs. Everyone is used to
> them.
>

Why can't we have both, parity in API and good design? I think .NET will be
slightly different, but overall, the AsyncCache approach which is being
discussed should work, no?

Really, there is no need to invent anything. It won't be better. "When
> in Rome, do as the Romans do".
>

Given that we are adding native support for Java, C#, and C++, we are
bigger than Rome already. We should be creating something like European
Union :)


>
> Thanks,
>
>
> On Tue, Oct 13, 2015 at 8:56 AM, Vladimir Ozerov 
> wrote:
>
> > Dima,
> >
> > I do not like JSR 107 v1.1 approach. First, it is not user friendly.
> > Second, it is prone to deadlock/starvation problems we are currently
> > discussing in another thread because these "Collectors" are continuations
> > essentially.
> >
> > On Tue, Oct 13, 2015 at 12:42 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > I just took a look at JSR 107, and looks like they are taking a
> different
> > > (in my view not as elegant) route:
> > >
> > >
> >
> https://github.com/jsr107/jsr107spec/blob/async/src/main/java/javax/cache/Cache.java
> > >
> > > Any thoughts on this?
> > >
> > > D.
> > >
> > > On Mon, Oct 12, 2015 at 11:11 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > wrote:
> > >
> > > > Well, if we asume that the most common usage will be
> > > > IgniteCache.async().doSomething(), then yes - backwards
> transformation
> > is
> > > > not necessary.
> > > >
> > > > All in all this approach seems to be the most clean among other
> > > suggested.
> > > >
> > > > On Mon, Oct 12, 2015 at 8:38 PM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > I mostly agree with your points except naming and hierarchy:
> > > > >
> > > > > 1. I don't like CacheAsync, it is ugly.
> > > > >
> > > > > 2. If IgniteCache extends AsyncCache then we can't use the same
> names
> > > for
> > > > > methods, we will be forced to use *blaAsync(...)* format
> > > > > which is ugly for me as well. Also this will pollute sync API with
> > > async
> > > > > one, while we are trying to avoid that.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2015-10-12 20:28 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > On Mon, Oct 12, 2015 at 10:15 AM, Vladimir Ozerov <
> > > > voze...@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > > > The problem with this approach is that not all methods are
> async.
> > > > E.g.
> > > > > > > name(), lock(K), iterator(), etc.. So you should either mix
> sync
> > > and
> > > > > > async
> > > > > > > methods in AsyncCache still, or expose only async methods.
> > > > > >
> > > > > >
> > > > > > I think AsyncCache, or rather CacheAsync, should expose only
> async
> > > > > methods.
> > > > > > Moreover, should IgniteCache simply extend CacheAsync API?
> > > > > >
> > > > > >
> > > > > > > In the latter case we will require backwards
> > > > > > > transformation: IgniteCache AsyncCache.sync().
> > > > > > >
> > > > > >
> > > > > > Not sure this is needed.
> > > > > >
> > > > > >
> > > > > > > Consistency between platforms should have minimal priority.
> .Net
> > > and
> > > > > Java
> > > > > > > are very different. For example we cannot even have "V Get(K)"
> > > method
> > > > > in
> > > > > > > .Net cache. Instead we have "V TryGet(K, out bool)" because
> .Net
> > > > > supports
> > > > > > > structs and have full generics support and naive Java approach
> > > simply
> > > > > > > doesn't work here. Base concepts must be the same across
> > platforms,
> > > > but
> > > > > > > methods signatures and grouping will be different.
> > > > > > >
> > > > > >
> > > > > > I disagree here. I think consistency matters. Moreover, based on
> > the
> > > > > > previous .NET examples you have provided, I do not see much
> > > difference
> > > > > > between .NET and Java, other than different syntax. I think the
> > same
> > > > > > CacheAsync design can be applied to both.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Oct 12, 2015 at 7:53 PM, Sergi Vladykin <
> > > > > > sergi.vlady...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > In my view we should not pollute sync APIs with all async
> > > methods,
> > > > > > > > definitely we have to separate them
> > > > > > > > for better UX.
> > > > > > > >
> > > > > > > > Currently on Java we have IgniteAsyncSupport with method
> > > > withAsync()
>

Re: .Net: separate methods for async operations.

[Vladimir Ozerov]

> Do we have a choice here? We will have to implement JSR107 anyway. Let's
> just make sure that whatever approach we come up with does not contradict
> JSR107 functionality.

As I understand from JSR107 mailing list, nobodody really understand what
the next version will be about. For now they are focused on maintenance
release and async operations are not planned here. Some event is planned at
the end of October at JavaOne which should boost further discussions.

As for async methods you mentioned, they were submitted recently into a
separate branch by Greg Luck and it is neither design draft, neither
proposed solution. Just some code without any official status.


On Tue, Oct 13, 2015 at 12:14 PM, Dmitriy Setrakyan 
wrote:

> On Mon, Oct 12, 2015 at 10:56 PM, Vladimir Ozerov 
> wrote:
>
> > Dima,
> >
> > I do not like JSR 107 v1.1 approach. First, it is not user friendly.
> > Second, it is prone to deadlock/starvation problems we are currently
> > discussing in another thread because these "Collectors" are continuations
> > essentially.
> >
>
> Do we have a choice here? We will have to implement JSR107 anyway. Let's
> just make sure that whatever approach we come up with does not contradict
> JSR107 functionality.
>
>
> >
> > On Tue, Oct 13, 2015 at 12:42 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > I just took a look at JSR 107, and looks like they are taking a
> different
> > > (in my view not as elegant) route:
> > >
> > >
> >
> https://github.com/jsr107/jsr107spec/blob/async/src/main/java/javax/cache/Cache.java
> > >
> > > Any thoughts on this?
> > >
> > > D.
> > >
> > > On Mon, Oct 12, 2015 at 11:11 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > wrote:
> > >
> > > > Well, if we asume that the most common usage will be
> > > > IgniteCache.async().doSomething(), then yes - backwards
> transformation
> > is
> > > > not necessary.
> > > >
> > > > All in all this approach seems to be the most clean among other
> > > suggested.
> > > >
> > > > On Mon, Oct 12, 2015 at 8:38 PM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > I mostly agree with your points except naming and hierarchy:
> > > > >
> > > > > 1. I don't like CacheAsync, it is ugly.
> > > > >
> > > > > 2. If IgniteCache extends AsyncCache then we can't use the same
> names
> > > for
> > > > > methods, we will be forced to use *blaAsync(...)* format
> > > > > which is ugly for me as well. Also this will pollute sync API with
> > > async
> > > > > one, while we are trying to avoid that.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2015-10-12 20:28 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > On Mon, Oct 12, 2015 at 10:15 AM, Vladimir Ozerov <
> > > > voze...@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > > > The problem with this approach is that not all methods are
> async.
> > > > E.g.
> > > > > > > name(), lock(K), iterator(), etc.. So you should either mix
> sync
> > > and
> > > > > > async
> > > > > > > methods in AsyncCache still, or expose only async methods.
> > > > > >
> > > > > >
> > > > > > I think AsyncCache, or rather CacheAsync, should expose only
> async
> > > > > methods.
> > > > > > Moreover, should IgniteCache simply extend CacheAsync API?
> > > > > >
> > > > > >
> > > > > > > In the latter case we will require backwards
> > > > > > > transformation: IgniteCache AsyncCache.sync().
> > > > > > >
> > > > > >
> > > > > > Not sure this is needed.
> > > > > >
> > > > > >
> > > > > > > Consistency between platforms should have minimal priority.
> .Net
> > > and
> > > > > Java
> > > > > > > are very different. For example we cannot even have "V Get(K)"
> > > method
> > > > > in
> > > > > > > .Net cache. Instead we have "V TryGet(K, out bool)" because
> .Net
> > > > > supports
> > > > > > > structs and have full generics support and naive Java approach
> > > simply
> > > > > > > doesn't work here. Base concepts must be the same across
> > platforms,
> > > > but
> > > > > > > methods signatures and grouping will be different.
> > > > > > >
> > > > > >
> > > > > > I disagree here. I think consistency matters. Moreover, based on
> > the
> > > > > > previous .NET examples you have provided, I do not see much
> > > difference
> > > > > > between .NET and Java, other than different syntax. I think the
> > same
> > > > > > CacheAsync design can be applied to both.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Oct 12, 2015 at 7:53 PM, Sergi Vladykin <
> > > > > > sergi.vlady...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > In my view we should not pollute sync APIs with all async
> > > methods,
> > > > > > > > definitely we have to separate them
> > > > > > > > for better UX.
> > > > > > > >
> > > > > > > > Currently on Java we have IgniteAsyncSupport with method
> > > > withAsync()
> > > > > > > which
> > > > > > > > returns the same 

[GitHub] ignite pull request: IGNITE-1642 .Net: Rename EventType members

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1642 .Net: Rename EventType members



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1642

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

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


commit 92790c9a512ecf3eaa6c75d50a5038ac8283f3d2
Author: ptupitsyn 
Date:   2015-10-13T10:00:12Z

Rename single events

commit 909df596465615b72e41493bd19c247934bca644
Author: ptupitsyn 
Date:   2015-10-13T10:03:09Z

wip

commit ce1393235e9a10268fafda90388ceb073e124fbe
Author: ptupitsyn 
Date:   2015-10-13T10:03:52Z

Remove FxCop suppressions

commit d35c69a3129bcdd36d52272465bb73870e3f4865
Author: ptupitsyn 
Date:   2015-10-13T10:10:29Z

Rename event collections




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

[jira] [Created] (IGNITE-1662) .Net: Improve docs for IEvents and IMessaging.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1662:
---

 Summary: .Net: Improve docs for IEvents and IMessaging.
 Key: IGNITE-1662
 URL: https://issues.apache.org/jira/browse/IGNITE-1662
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.5


Looks like our documentation in these classes is insufficient. User must have 
very clear undestanding on what will happen in case returning true or false in 
various use cases.



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

[jira] [Created] (IGNITE-1663) .Net: Check why node ID is nullable in IEvents and IMessaging interfaces.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1663:
---

 Summary: .Net: Check why node ID is nullable in IEvents and 
IMessaging interfaces.
 Key: IGNITE-1663
 URL: https://issues.apache.org/jira/browse/IGNITE-1663
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.5


It is not clear why we operate on node as "Guid?". Are there any use cases when 
it could be null?
If no, we must change signature to "Guid".



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

Re: hello

[Ivan Veselovskiy]

Hi, 姜为 ,

Welcome to the Ignite community!

Please properly subscribe to the dev list by sending email to
dev-subscr...@ignite.apache.org and following instructions in the reply.

For resources and information on how to get involved, you can use the
community section of the website:

https://ignite.apache.org/community/resources.html
https://ignite.apache.org/community/contribute.html

You should also get familiar with Ignite development process outlined on
our Wiki:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Also, pick any of the tickets in Ignite Jira and let the community know
that you wish to start working on it. Some of the tickets you can start on
are listed here:

https://ignite.apache.org/community/contribute.html#pick-ticket

If you have any questions, send them here.

On Tue, Oct 13, 2015 at 8:34 AM, 姜 为  wrote:

> Hello everyone, I want to to contribute to ignite and learning, nice to
> meet you!

[jira] [Created] (IGNITE-1664) .Net: Review generic type arguments in the API

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1664:
---

 Summary: .Net: Review generic type arguments in the API
 Key: IGNITE-1664
 URL: https://issues.apache.org/jira/browse/IGNITE-1664
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


* Make sure that order is correct (in -> out)
* Fix naming to be meaningful ("T, TR1, TR2" does not help with understanding)



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

IgniteEvents.remoteListen() semantics

[Vladimir Ozerov]

Igniters,

I was looking at IgniteEvents.remoteListen() and failed to understand how
it works. Can someone explain me semantics please?

1) What is the point of *local* listener in the method "*remote*Listen"?
Are we collecting events remotely and send them to the local node? If yes,
then this is not "remoteListen", it is "localListen" with additional remote
filters.

2) How does "IgnitePredicate rmtFilter" argument work? JavaDoc says:
"It will be auto-unsubsribed on the node where event occurred in case if it
returns {@code false}."
Is this a filter that stops working when "false" is returned? If yes, this
is not a filter, I am afraid. It doesn't filter anything. This is something
else I cannot name.

To the contrast please look at IgniteMessaging.remoteListen() - clean and
consistent method.

Looks like we need to rethink this API. The closest concept is continuous
queries. It has a remote filter (which is really a filter) and a local
listener.

I would remove/deprecate "remoteListen" method and do something like this:

UUID listen(IgniteInClosure locLsnr, @Nullable
IgnitePredicate rmtFilter, bool autoUnsubscribe);
bool stopListen(UUID id);

Thoughts?

Re: IgniteEvents.remoteListen() semantics

[Pavel Tupitsyn]

Related question:

What does first UUID arg mean in "IgniteBiPredicate locLsnr"?
It can either be event source node id, which is already included in Event
interface, or local node id, which does not make much sense.

On Tue, Oct 13, 2015 at 1:57 PM, Vladimir Ozerov 
wrote:

> Igniters,
>
> I was looking at IgniteEvents.remoteListen() and failed to understand how
> it works. Can someone explain me semantics please?
>
> 1) What is the point of *local* listener in the method "*remote*Listen"?
> Are we collecting events remotely and send them to the local node? If yes,
> then this is not "remoteListen", it is "localListen" with additional remote
> filters.
>
> 2) How does "IgnitePredicate rmtFilter" argument work? JavaDoc says:
> "It will be auto-unsubsribed on the node where event occurred in case if it
> returns {@code false}."
> Is this a filter that stops working when "false" is returned? If yes, this
> is not a filter, I am afraid. It doesn't filter anything. This is something
> else I cannot name.
>
> To the contrast please look at IgniteMessaging.remoteListen() - clean and
> consistent method.
>
> Looks like we need to rethink this API. The closest concept is continuous
> queries. It has a remote filter (which is really a filter) and a local
> listener.
>
> I would remove/deprecate "remoteListen" method and do something like this:
>
> UUID listen(IgniteInClosure locLsnr, @Nullable
> IgnitePredicate rmtFilter, bool autoUnsubscribe);
> bool stopListen(UUID id);
>
> Thoughts?
>



-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

[jira] [Created] (IGNITE-1665) .Net: Cache field IDs when deserializing objects.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1665:
---

 Summary: .Net: Cache field IDs when deserializing objects.
 Key: IGNITE-1665
 URL: https://issues.apache.org/jira/browse/IGNITE-1665
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.5


Profiliing deserialization of test "Address" object shows that we spend 
considerable amount of time (10-20%) inside field ID calculation. 

We already optimized this for writes using serialization "paths" concept where 
field hashing is replaced with strings reference equality checks. The same 
thing should be done for reads.



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

[GitHub] ignite pull request: IGNITE-1662 .Net: Improve docs for IEvents an...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1662 .Net: Improve docs for IEvents and IMessaging.



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1662

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

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


commit aacf842094077eef75bc5e06aaea662db9c23cd5
Author: ptupitsyn 
Date:   2015-10-13T10:32:00Z

Rename EventFilter to EventListener

commit 8a18edfd173e63da2f09f97780232b81c1c90151
Author: ptupitsyn 
Date:   2015-10-13T10:32:10Z

wip

commit 5a71c5f5a3f5369bdcf7c95dafab023556061730
Author: ptupitsyn 
Date:   2015-10-13T10:41:34Z

Rename EventFilter to EventListener

commit b7754368e6356664a4d0108fca913a9076056f00
Author: ptupitsyn 
Date:   2015-10-13T10:41:42Z

wip

commit ce8be519db4fb3459cebb30806f0dfd742315180
Author: ptupitsyn 
Date:   2015-10-13T10:59:43Z

wip docs

commit f5aa262380d726d53bf0a71e92a9a6b28c6f0973
Author: ptupitsyn 
Date:   2015-10-13T11:02:37Z

wip

commit d5b8db127215ede9f0a1d0f3c1af838e7665bf6c
Author: ptupitsyn 
Date:   2015-10-13T11:15:03Z

wip

commit b9a1a1ebb3c467d51a308790f6623a422050be72
Author: ptupitsyn 
Date:   2015-10-13T11:43:08Z

wip

commit 42e529c64ffe8e0010b7820a1bc79aeafc21d226
Author: ptupitsyn 
Date:   2015-10-13T11:45:26Z

wip

commit 7d2a9b865d5242b00632db2810108d495f89129a
Author: ptupitsyn 
Date:   2015-10-13T12:02:35Z

wip

commit d3c055d2b812262bae4bdc61db6f1c0f08a9697e
Author: ptupitsyn 
Date:   2015-10-13T12:02:41Z

wip

commit a737804af6134a13290395a42821c4f2ed0965ef
Author: ptupitsyn 
Date:   2015-10-13T12:04:03Z

wip




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

[jira] [Created] (IGNITE-1666) Fallback for full scan query does not work

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-1666:
---

 Summary: Fallback for full scan query does not work
 Key: IGNITE-1666
 URL: https://issues.apache.org/jira/browse/IGNITE-1666
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
Reporter: Andrey Gura
Assignee: Andrey Gura


Fallback for full scan query doesn't work.

Steps to reproduce (all in one thread):

1. Start N nodes, create cache and populate some entries to cache.
2. Stop some node.
3. Get iterator on the cache and fetch all entries one by one.
4. Repeat from step 2.

On some iteration scan query fails with exception: 

{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
Query execution failed: GridCacheQueryBean [qry=GridCacheQueryAdapter 
[type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false, 
metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0, 
avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0, 
keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null, trans=null]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1614)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
at 
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.init(CacheWeakQueryIteratorsHolder.java:228)
at 
org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:180)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.doTest(CacheIteratorWhileRemovalSelfTest.java:135)
at 
org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.testFullScanIterator(CacheIteratorWhileRemovalSelfTest.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
Caused by: class org.apache.ignite.IgniteCheckedException: Query execution 
failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
clause=null, filter=null, part=null, incMeta=false, 
metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0, 
avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0, 
keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null, trans=null]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:276)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
... 14 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN, 
clsName=null, clause=null, filter=null, part=null, incMeta=false, 
metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0, 
avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0, 
keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null, 
trans=null], nodeId=203d0a36-8587-4a32-aa51-3332d126d002]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:390)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryFuture.onNodeLeft(GridCacheDistributedQueryFuture.java:146)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$3.onEven

[GitHub] ignite pull request: ignite-1666 Fallback for full scan query does...

[agura]

GitHub user agura opened a pull request:

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

ignite-1666 Fallback for full scan query does not work

PR contains only test for reproducing issue 
https://issues.apache.org/jira/browse/IGNITE-1666

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

$ git pull https://github.com/agura/incubator-ignite ignite-1666

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

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


commit e6b372a223bd55f6ff090c63ce14afc97fbff83d
Author: agura 
Date:   2015-10-13T13:58:39Z

ignite-1666 Fallback for full scan query does not work




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

[GitHub] ignite pull request: IGNITE-1647: Implemented SqlFieldQuery

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-1647: Implemented SqlFieldQuery



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

$ git pull https://github.com/isapego/ignite ignite-1647

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

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


commit cfd3355414b0fe425b8cba5dd032715ae5f6837f
Author: isapego 
Date:   2015-10-02T16:52:26Z

IGNITE-1610: Implemented portable reader and writer for iterators.

commit 61410e8ea4a1dba5c8122ad519d375f085f65bed
Author: isapego 
Date:   2015-10-05T09:35:49Z

Revert "IGNITE-1610: Implemented portable reader and writer for iterators."

This reverts commit cfd3355414b0fe425b8cba5dd032715ae5f6837f.

commit 7a0cb1e54fb6f91e60ea52911f1938ce8896191b
Author: isapego 
Date:   2015-10-08T10:26:26Z

Merge branch 'ignite-1282' of https://github.com/apache/ignite into 
ignite-1282

commit 059a19ecfaf80560bf4215b181abb814f59975fd
Author: isapego 
Date:   2015-10-09T13:01:45Z

Merge branch 'ignite-1282' of https://github.com/apache/ignite into 
ignite-1282

commit 39404cfa82ec53de8cdcbd9735e6c8e5e116adee
Author: isapego 
Date:   2015-10-13T15:40:30Z

IGNITE-1647 Implemented SqlFieldQuery




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

Fwd: .Net: separate methods for async operations.

[Raul Kripalani]

I like this approach.

To me, the current API is messy and hacky, and even "spiritually"
contradictory, may I say. The whole raison d'être of the current approach
seems to be to achieve parity of APIs of IgniteCompute, IgniteMessaging,
etc. in sync and async modes. However, truth of the matter is that we only
end up honouring half of the API in async mode: the method entry point and
parameters. The method return type is basically ignored, because all
methods in async mode return null since the "virtual" return type is now a
Future that the user must obtain with a separate code. To me, this is a
code smell.

Moreover, I would argue that keeping a state (even if in a ThreadLocal)
also makes certain use cases impossible or buggy, like Nikita illustrated,
e.g. passing IgniteCache, IgniteCompute, etc down the stack.

In fact, keeping a state in async mode and not in sync is problematic
because – to the eyes of the user – they're always interacting with the
neutral interfaces IgniteCompute, IgniteCache, etc. They have no indication
of when a state is being kept and when not – only through documentation,
common sense and human memory – something that's error-prone.

Obviously the verbosity and fluency of user's code is also a factor to
consider, but to me it is secondary. The above points are enough to
advocate changing the async APIs.

Finally, looking to the future, the current approach does make Ignite
difficult to integrate with Reactive Streams. So it's great we're
discussing it.

@Sergey, the approach you propose would entail adding Async interface
variants for each functionality. This is a step in the opposite direction
of the spirit of the current API, am I correct? Since this is a change in
direction, I would like for most of the team to approve or disapprove.

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Mon, Oct 12, 2015 at 5:53 PM, Sergi Vladykin 
wrote:

> In my view we should not pollute sync APIs with all async methods,
> definitely we have to separate them
> for better UX.
>
> Currently on Java we have IgniteAsyncSupport with method withAsync() which
> returns the same sync API
> but that API works in broken manner. Instead it should look like the
> following IMO
>
> interface AsyncSupport {
> X async();
> }
>
> Where X will be an interface with respective async API.  For example for
> IngneCache we will have AsyncCache
> with all the respective async variants of all methods. Like this
>
> interface IgniteCache extends AsyncSupport> {
> V get(K key);
> }
>
>
> interface AsyncCache {
> IgniteFuture get(K key);
> }
>
> From implementation standpoint both interfaces can be implemented by the
> same class but for user API
> they will be conveniently separated. Implementation of every sync method is
> trivial if we have
> async counterpart: just call get() on received future.
>
> From documentation point of view we just have to write on each method that
> it is a async variant of some
> method on main API like following:
>
>/**
>  * Asynchronous variant of method {@link IgniteCache#get(Object)}.
>  */
>
> This way we will not need to maintain the same docs for all sync and async
> methods.
>
> Sorry, I'm not an expert in .Net but I believe this approach will fit .Net
> as well, so it can be consistent across platforms.
>
> Sergi
>
>
>
> 2015-10-12 19:10 GMT+03:00 Dmitriy Setrakyan :
>
> > Do I understand correctly that you are suggesting adding "Async(..)"
> > counterparts for all the synchronous methods?
> >
> > Are there any objections about this? If we do it in .NET, then we might
> as
> > well do it in Java, because in my view the same reasoning can be made for
> > Java. This will cause significant proliferation of Async methods. For
> > example just on IgniteCache API, we will have to add about 40 Async()
> > methods.
> >
> > D.
> >
> >
> >
> > On Mon, Oct 12, 2015 at 3:45 AM, Vladimir Ozerov 
> > wrote:
> >
> > > No. "await" is actually return from the method immediately. Let me show
> > it
> > > again:
> > >
> > > async Task GetAndMultiply() {
> > > Task res =  cache.GetAsync(1);
> > >
> > > await res;
> > >
> > > return res.Result * res.Result;
> > > }
> > >
> > > maps to the following pseudo-code in Java:
> > >
> > > Future getAndMultiply() {
> > > Future res =  cache.getAsync(1);
> > >
> > > return res.chain((f) => {
> > > return f.get() * f.get();
> > > });
> > > }
> > >
> > >
> > >
> > > On Mon, Oct 12, 2015 at 1:36 PM, Yakov Zhdanov 
> > > wrote:
> > >
> > > > Is current thread blocked until "await" instruction is completed in
> > > > parallel thread?
> > > >
> > > > --Yakov
> > > >
> > > > 2015-10-12 10:41 GMT+03:00 Vladimir Ozerov :
> > > >
> > > > > Example with Get() operation:
> > > > >
> > > > > async Task GetAndMultiply() {
> > > > >

Re: .Net: separate methods for async operations.

[Dmitriy Setrakyan]

On Tue, Oct 13, 2015 at 9:19 AM, Raul Kripalani  wrote:

> I like this approach.
>
> To me, the current API is messy and hacky, and even "spiritually"
> contradictory, may I say. The whole raison d'être of the current approach
> seems to be to achieve parity of APIs of IgniteCompute, IgniteMessaging,
> etc. in sync and async modes. However, truth of the matter is that we only
> end up honouring half of the API in async mode: the method entry point and
> parameters. The method return type is basically ignored, because all
> methods in async mode return null since the "virtual" return type is now a
> Future that the user must obtain with a separate code. To me, this is a
> code smell.
>
> Moreover, I would argue that keeping a state (even if in a ThreadLocal)
> also makes certain use cases impossible or buggy, like Nikita illustrated,
> e.g. passing IgniteCache, IgniteCompute, etc down the stack.
>
> In fact, keeping a state in async mode and not in sync is problematic
> because – to the eyes of the user – they're always interacting with the
> neutral interfaces IgniteCompute, IgniteCache, etc. They have no indication
> of when a state is being kept and when not – only through documentation,
> common sense and human memory – something that's error-prone.
>
> Obviously the verbosity and fluency of user's code is also a factor to
> consider, but to me it is secondary. The above points are enough to
> advocate changing the async APIs.
>
> Finally, looking to the future, the current approach does make Ignite
> difficult to integrate with Reactive Streams. So it's great we're
> discussing it.
>
> @Sergey, the approach you propose would entail adding Async interface
> variants for each functionality. This is a step in the opposite direction
> of the spirit of the current API, am I correct? Since this is a change in
> direction, I would like for most of the team to approve or disapprove.
>

I personally like Sergey's design. I actually don't see it as a step in the
opposite direction. I think it achieves the same goal, but in a much
cleaner fashion. Moreover, it seems to be .NET-friendly as well.


>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Mon, Oct 12, 2015 at 5:53 PM, Sergi Vladykin 
> wrote:
>
> > In my view we should not pollute sync APIs with all async methods,
> > definitely we have to separate them
> > for better UX.
> >
> > Currently on Java we have IgniteAsyncSupport with method withAsync()
> which
> > returns the same sync API
> > but that API works in broken manner. Instead it should look like the
> > following IMO
> >
> > interface AsyncSupport {
> > X async();
> > }
> >
> > Where X will be an interface with respective async API.  For example for
> > IngneCache we will have AsyncCache
> > with all the respective async variants of all methods. Like this
> >
> > interface IgniteCache extends AsyncSupport> {
> > V get(K key);
> > }
> >
> >
> > interface AsyncCache {
> > IgniteFuture get(K key);
> > }
> >
> > From implementation standpoint both interfaces can be implemented by the
> > same class but for user API
> > they will be conveniently separated. Implementation of every sync method
> is
> > trivial if we have
> > async counterpart: just call get() on received future.
> >
> > From documentation point of view we just have to write on each method
> that
> > it is a async variant of some
> > method on main API like following:
> >
> >/**
> >  * Asynchronous variant of method {@link IgniteCache#get(Object)}.
> >  */
> >
> > This way we will not need to maintain the same docs for all sync and
> async
> > methods.
> >
> > Sorry, I'm not an expert in .Net but I believe this approach will fit
> .Net
> > as well, so it can be consistent across platforms.
> >
> > Sergi
> >
> >
> >
> > 2015-10-12 19:10 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Do I understand correctly that you are suggesting adding "Async(..)"
> > > counterparts for all the synchronous methods?
> > >
> > > Are there any objections about this? If we do it in .NET, then we might
> > as
> > > well do it in Java, because in my view the same reasoning can be made
> for
> > > Java. This will cause significant proliferation of Async methods. For
> > > example just on IgniteCache API, we will have to add about 40 Async()
> > > methods.
> > >
> > > D.
> > >
> > >
> > >
> > > On Mon, Oct 12, 2015 at 3:45 AM, Vladimir Ozerov  >
> > > wrote:
> > >
> > > > No. "await" is actually return from the method immediately. Let me
> show
> > > it
> > > > again:
> > > >
> > > > async Task GetAndMultiply() {
> > > > Task res =  cache.GetAsync(1);
> > > >
> > > > await res;
> > > >
> > > > return res.Result * res.Result;
> > > > }
> > > >
> > > > maps to the following pseudo-code in Java:
> > > >
> > > > Future getAndMultiply()

IGFS: properties to use for implicit mkdirs

[Ivan Veselovskiy]

Currently we have #create, #append , #mkdirs operations that implicitly
create parent directories if they are absent.
Now #mkdirs uses the properties passed in for the implicitly created
directories if they are not null, and uses default properties (with 0777
permission flag) if the properties are not given.
#create & #append use for the implicitly created directories properties
passed in for newly created file, if the passed in properties are not null,
and use default properties (with 0777 permission flag) if they are not
given.
The question is: wouldn't it be more logical to always use defaults for the
implicitly created directories?

Re: .Net: separate methods for async operations.

[Sergi Vladykin]

Raul,

Yes, my design is an attempt to address exactly the problems you've
mentioned (get rid of state, better type safety, cleaner code).
I'm not an expert in reactive streams, but I believe Future is the most low
level feature possible here, so higher level abstractions
can be build using it.

Sergi


2015-10-13 19:32 GMT+03:00 Dmitriy Setrakyan :

> On Tue, Oct 13, 2015 at 9:19 AM, Raul Kripalani  wrote:
>
> > I like this approach.
> >
> > To me, the current API is messy and hacky, and even "spiritually"
> > contradictory, may I say. The whole raison d'être of the current approach
> > seems to be to achieve parity of APIs of IgniteCompute, IgniteMessaging,
> > etc. in sync and async modes. However, truth of the matter is that we
> only
> > end up honouring half of the API in async mode: the method entry point
> and
> > parameters. The method return type is basically ignored, because all
> > methods in async mode return null since the "virtual" return type is now
> a
> > Future that the user must obtain with a separate code. To me, this is a
> > code smell.
> >
> > Moreover, I would argue that keeping a state (even if in a ThreadLocal)
> > also makes certain use cases impossible or buggy, like Nikita
> illustrated,
> > e.g. passing IgniteCache, IgniteCompute, etc down the stack.
> >
> > In fact, keeping a state in async mode and not in sync is problematic
> > because – to the eyes of the user – they're always interacting with the
> > neutral interfaces IgniteCompute, IgniteCache, etc. They have no
> indication
> > of when a state is being kept and when not – only through documentation,
> > common sense and human memory – something that's error-prone.
> >
> > Obviously the verbosity and fluency of user's code is also a factor to
> > consider, but to me it is secondary. The above points are enough to
> > advocate changing the async APIs.
> >
> > Finally, looking to the future, the current approach does make Ignite
> > difficult to integrate with Reactive Streams. So it's great we're
> > discussing it.
> >
> > @Sergey, the approach you propose would entail adding Async interface
> > variants for each functionality. This is a step in the opposite direction
> > of the spirit of the current API, am I correct? Since this is a change in
> > direction, I would like for most of the team to approve or disapprove.
> >
>
> I personally like Sergey's design. I actually don't see it as a step in the
> opposite direction. I think it achieves the same goal, but in a much
> cleaner fashion. Moreover, it seems to be .NET-friendly as well.
>
>
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
> > On Mon, Oct 12, 2015 at 5:53 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > In my view we should not pollute sync APIs with all async methods,
> > > definitely we have to separate them
> > > for better UX.
> > >
> > > Currently on Java we have IgniteAsyncSupport with method withAsync()
> > which
> > > returns the same sync API
> > > but that API works in broken manner. Instead it should look like the
> > > following IMO
> > >
> > > interface AsyncSupport {
> > > X async();
> > > }
> > >
> > > Where X will be an interface with respective async API.  For example
> for
> > > IngneCache we will have AsyncCache
> > > with all the respective async variants of all methods. Like this
> > >
> > > interface IgniteCache extends AsyncSupport> {
> > > V get(K key);
> > > }
> > >
> > >
> > > interface AsyncCache {
> > > IgniteFuture get(K key);
> > > }
> > >
> > > From implementation standpoint both interfaces can be implemented by
> the
> > > same class but for user API
> > > they will be conveniently separated. Implementation of every sync
> method
> > is
> > > trivial if we have
> > > async counterpart: just call get() on received future.
> > >
> > > From documentation point of view we just have to write on each method
> > that
> > > it is a async variant of some
> > > method on main API like following:
> > >
> > >/**
> > >  * Asynchronous variant of method {@link IgniteCache#get(Object)}.
> > >  */
> > >
> > > This way we will not need to maintain the same docs for all sync and
> > async
> > > methods.
> > >
> > > Sorry, I'm not an expert in .Net but I believe this approach will fit
> > .Net
> > > as well, so it can be consistent across platforms.
> > >
> > > Sergi
> > >
> > >
> > >
> > > 2015-10-12 19:10 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Do I understand correctly that you are suggesting adding "Async(..)"
> > > > counterparts for all the synchronous methods?
> > > >
> > > > Are there any objections about this? If we do it in .NET, then we
> might
> > > as
> > > > well do it in Java, because in my view the same reasoning can be made
> > for
> > > > Java. This will cause

[GitHub] ignite pull request: Ignite 1526 IBM JDK is not fully supported by...

[agura]

GitHub user agura opened a pull request:

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

Ignite 1526 IBM JDK is not fully supported by the platfrom



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

$ git pull https://github.com/agura/incubator-ignite ignite-1526

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

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


commit 516c72492bbeaf7238e2326257136f2a3d963031
Author: agura 
Date:   2015-10-12T16:07:30Z

ignite-1526 IBM JDK is not fully supported by the platfrom

commit 746422bd31f575728284de6272d3298ab0a7d002
Author: agura 
Date:   2015-10-13T17:59:44Z

ignite-1526 IBM JDK is not fully supported by the platfrom




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

[GitHub] ignite pull request: IGNITE-1635 Added reproduciable unit-test for...

[ashutakGG]

GitHub user ashutakGG opened a pull request:

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

IGNITE-1635 Added reproduciable unit-test for the bug

https://issues.apache.org/jira/browse/IGNITE-1635

Added reproduciable unit-test for the bug.

Also added test for https://issues.apache.org/jira/browse/IGNITE-1616, but 
test do not reproduce the issue.

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

$ git pull https://github.com/ashutakGG/incubator-ignite ignite-1635-test

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

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


commit c399b99a9890d348a610af820dbbae515e2e1173
Author: ashutak 
Date:   2015-10-13T16:07:44Z

IgniteFailoverSelfTest

commit 7146a964d83070a28295ba52b31e0422c3f8721e
Author: ashutak 
Date:   2015-10-13T17:28:14Z

extract abstract restart test

commit e2fe9ae094dfaef6e030ff6135a063b5c7e2a2aa
Author: ashutak 
Date:   2015-10-13T18:37:48Z

add CacheNearDisabledTransactionalWriteReadRestartSelfTest

commit ed0873f78872978412354e635ddb82d05903a7f9
Author: ashutak 
Date:   2015-10-13T18:38:41Z

typo

commit 3d182a9cb2288b95af43884e3e03fe248415325c
Author: ashutak 
Date:   2015-10-13T18:43:41Z

add test suite




---
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: IGFS concurrency issue

[Konstantin Boudnik]

Ah, that makes sense - sorry I jumped to obviously wrong conclusion based on
existing HDFS secondary storage implementation.

Cos

On Tue, Oct 13, 2015 at 09:41AM, Vladimir Ozerov wrote:
> Cos,
> 
> We are trying to keep IGFS decoupled from HDFS. Instead, we define IGFS as
> an in-memory file system which could optionally be a cache some secondary
> file system. And HDFS is one of these file systems.
> 
> For this reason we cannot rely on any specific behavior of particular
> secondary file system.
> 
> 
> On Tue, Oct 13, 2015 at 8:14 AM, Konstantin Boudnik  wrote:
> 
> > Thanks Vladimir.  In the case of HDFS, the global lock for conflicting
> > simultaneous changes ie
> >
> > mkdir /a/b/c
> > together with
> > mv /a/b /a/d
> >
> > will trigger the NN global lock on the file system so the latter operation
> > won't start until the former is completed. Hence, the point of my
> > confusion is
> > why IGFS is adding an additional lock on top of what the secondary file
> > system
> > does anyway. Sorry, if I haven't expressed myself in a better way from the
> > beginning.
> >
> > Cos
> >
> > On Thu, Oct 08, 2015 at 11:33AM, Vladimir Ozerov wrote:
> > > Cos,
> > >
> > > Initially IGFS was designed to support concurrent structural updates.
> > E.g.,
> > > creation of directories /A/C/D and /E/F/G can be performed concurrently.
> > > Now we revealed that it might cause concurrency issues in case of
> > > conflicting updates.
> > >
> > > To fix this problem we now perform every update holding a kind of global
> > > file system lock. This doesn't affect file read/write operations - they
> > > still can be performed concurrently of course. The question was whether
> > > this could cause severe performance degradation or not. If we assume that
> > > in average Hadoop jobs file operations dominate over structural
> > operations
> > > on directories, then it should not cause any significant performance
> > issues.
> > >
> > > Vladimir.
> > >
> > > On Wed, Oct 7, 2015 at 10:38 PM, Konstantin Boudnik 
> > wrote:
> > >
> > > > On Wed, Oct 07, 2015 at 09:11AM, Vladimir Ozerov wrote:
> > > > > Cos,
> > > > > Yes, no long-time locking is expected here.
> > > >
> > > > Sorry, I musta be still dense from the jet-lag: could you put in a bit
> > more
> > > > details? Thanks in advance!
> > > >
> > > > Cos
> > > >
> > > > > On Wed, Oct 7, 2015 at 6:57 AM, Konstantin Boudnik 
> > > > wrote:
> > > > >
> > > > > > IIRC NN should be locking on these ops anyway, shouldn't it? The
> > > > situation
> > > > > > is
> > > > > > no different if multiple clients are doing these operations
> > > > > > near-simultaneously. Unless I missed something here...
> > > > > >
> > > > > > On Thu, Sep 24, 2015 at 11:28AM, Sergi Vladykin wrote:
> > > > > > > May be just check that they are not parent-child within the tx?
> > > > > > >
> > > > > > > Sergi
> > > > > > > Igniters,
> > > > > > >
> > > > > > > We revealed concurrency problem in IGFS and I would like to
> > discuss
> > > > > > > possible solutions to it.
> > > > > > >
> > > > > > > Consider the following file system structure:
> > > > > > > root
> > > > > > > |-- A
> > > > > > > |   |-- B
> > > > > > > |   |   |-- C
> > > > > > > |   |-- D
> > > > > > >
> > > > > > > ... two concurrent operations in different threads:
> > > > > > > T1: move(/A/B, /A/D);
> > > > > > > T2: move(/A/D, /A/B/C);
> > > > > > >
> > > > > > > ... and how IGFS handles it now:
> > > > > > > T1: verify that "/A/B" and "/A/D" exist, they are not
> > child-parent to
> > > > > > each
> > > > > > > other, etc. -> OK.
> > > > > > > T2: do the same for "A/D" and "A/B/C" -> OK.
> > > > > > > T1: get IDs of "/A", "/A/B" and "/A/D" to lock them later inside
> > tx.
> > > > > > > T2: get IDs of "/A", "/A/D", "/A/B" and "/A/B/C" to lock them
> > later
> > > > > > inside
> > > > > > > tx.
> > > > > > >
> > > > > > > T1: Start pessimistic tx, lock IDs of "/A", "/A/B", "/A/D",
> > perform
> > > > move
> > > > > > ->
> > > > > > > OK.
> > > > > > > root
> > > > > > > |-- A
> > > > > > > |   |-- D
> > > > > > > |   |   |-- B
> > > > > > > |   |   |   |-- C
> > > > > > >
> > > > > > > T2: Start pessimistic tx, lock IDs of "/A", "/A/D", "/A/B" and
> > > > > > > "/A/B/C" (*directory
> > > > > > > structure already changed at this time!*), perform move -> OK.
> > > > > > > root
> > > > > > > |-- A
> > > > > > > B
> > > > > > > |-- D
> > > > > > > |   |-- C
> > > > > > > |   |   |-- B (loop!)
> > > > > > >
> > > > > > > File system is corrupted. Folders B, C and D are not reacheable
> > from
> > > > > > root.
> > > > > > >
> > > > > > > To fix this now we additionaly check if directory structure is
> > still
> > > > > > > valid *inside
> > > > > > > transaction*. It works, no more corruptions. But it requres
> > taking
> > > > locks
> > > > > > on
> > > > > > > the whole paths *including root*. So move, delete and mkdirs
> > > > opeartions
> > > > > > *can
> > > > > > > no longer be concurrent*.
> > > > > > >
> > > > > > > Probably 

IGNITE-1371

[Igor Rudyak]

Hi guys,

I am working on IGNITE-1371
 issue and almost done
with it. Could you please assign me appropriate right to the issue, so that
I'll be able to create a patch and send it to you.


Thanks,
Igor Rudyak

Re: IGNITE-1371

[Konstantin Boudnik]

Welcome Igor.

I have assigned the ticket to you and added you to the contributors' group.
Please consider subscribing to this list as well, so you'll be able to receive
the emails from it, and write into it without a moderator's approval.

Thanks,
  Cos

On Tue, Oct 13, 2015 at 02:47PM, Igor Rudyak wrote:
> Hi guys,
> 
> I am working on IGNITE-1371
>  issue and almost done
> with it. Could you please assign me appropriate right to the issue, so that
> I'll be able to create a patch and send it to you.
> 
> 
> Thanks,
> Igor Rudyak


signature.asc
Description: Digital signature

[VOTE] Establishing duration of Apache Ignite Chair rotation

[Konstantin Boudnik]

Hi!

As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I propose
that we adopt a rule allowing for a Apache Ignite Chair rotation on a yearly
basis. The proposed policy is this:
  - a position of an Apache Ignite Chair gets elected for a year
  - after a year passes it is expected of the active Chair to start a
[DISCUSS] email thread on priv...@ignite.apache.org asking PMC members to
make a nomination for the next year
  - it is perfectly acceptable for the active chair to nominate him or
herself
  - there is no limit on the number of terms that one person can serve as an
Apache Ignite Chair.

Each term, however is exactly one year.

  [ ] +1 Adopt the Apache Ingite Chair rotation policy
  [ ] +0
  [ ] -1 Do not adopt the proposed policy (please provide a reason)

This VOTE will be held open for at least 72 hours.

Thanks,
  Cos


signature.asc
Description: Digital signature

Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

[Nikita Ivanov]

+1

--
Nikita Ivanov


On Tue, Oct 13, 2015 at 3:30 PM, Konstantin Boudnik  wrote:

> Hi!
>
> As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I
> propose
> that we adopt a rule allowing for a Apache Ignite Chair rotation on a
> yearly
> basis. The proposed policy is this:
>   - a position of an Apache Ignite Chair gets elected for a year
>   - after a year passes it is expected of the active Chair to start a
> [DISCUSS] email thread on priv...@ignite.apache.org asking PMC
> members to
> make a nomination for the next year
>   - it is perfectly acceptable for the active chair to nominate him or
> herself
>   - there is no limit on the number of terms that one person can serve as
> an
> Apache Ignite Chair.
>
> Each term, however is exactly one year.
>
>   [ ] +1 Adopt the Apache Ingite Chair rotation policy
>   [ ] +0
>   [ ] -1 Do not adopt the proposed policy (please provide a reason)
>
> This VOTE will be held open for at least 72 hours.
>
> Thanks,
>   Cos
>

Re: IGNITE-1371

[Igor Rudyak]

Cool, thanks Konstantin.

Regards,
Igor Rudyak

On Tue, Oct 13, 2015 at 2:58 PM, Konstantin Boudnik  wrote:

> Welcome Igor.
>
> I have assigned the ticket to you and added you to the contributors' group.
> Please consider subscribing to this list as well, so you'll be able to
> receive
> the emails from it, and write into it without a moderator's approval.
>
> Thanks,
>   Cos
>
> On Tue, Oct 13, 2015 at 02:47PM, Igor Rudyak wrote:
> > Hi guys,
> >
> > I am working on IGNITE-1371
> >  issue and almost
> done
> > with it. Could you please assign me appropriate right to the issue, so
> that
> > I'll be able to create a patch and send it to you.
> >
> >
> > Thanks,
> > Igor Rudyak
>

Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

[Dmitriy Setrakyan]

+1 (binding)

On Tue, Oct 13, 2015 at 3:30 PM, Konstantin Boudnik  wrote:

> Hi!
>
> As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I
> propose
> that we adopt a rule allowing for a Apache Ignite Chair rotation on a
> yearly
> basis. The proposed policy is this:
>   - a position of an Apache Ignite Chair gets elected for a year
>   - after a year passes it is expected of the active Chair to start a
> [DISCUSS] email thread on priv...@ignite.apache.org asking PMC
> members to
> make a nomination for the next year
>   - it is perfectly acceptable for the active chair to nominate him or
> herself
>   - there is no limit on the number of terms that one person can serve as
> an
> Apache Ignite Chair.
>
> Each term, however is exactly one year.
>
>   [ ] +1 Adopt the Apache Ingite Chair rotation policy
>   [ ] +0
>   [ ] -1 Do not adopt the proposed policy (please provide a reason)
>
> This VOTE will be held open for at least 72 hours.
>
> Thanks,
>   Cos
>

[jira] [Created] (IGNITE-1667) Load metadata: we should handle case when connection with DB was lost after user clicked Save

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1667:
--

 Summary: Load metadata: we should handle case when connection with 
DB was lost after user clicked Save
 Key: IGNITE-1667
 URL: https://issues.apache.org/jira/browse/IGNITE-1667
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


1) load metadat from any DB
2) start Load metadata again from the same DB
3) go to step where need to choose tables
4) click Save and stop\kill DB when you will get confirmation to overwrite 
existent tables. 

Observed: no error message will appear during loading(overwriting)



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

[jira] [Created] (IGNITE-1668) Types metadata list is empty after successful load from DB

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1668:
--

 Summary: Types metadata list is empty after successful load from DB
 Key: IGNITE-1668
 URL: https://issues.apache.org/jira/browse/IGNITE-1668
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko


1) Load metadata from DB including tables with out PK
2) Switch metadata list to view only invalid items
3) Remove all
4) Load from DB metadata only for valid tables

Observed - metadata list is empty after load.



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

[jira] [Created] (IGNITE-1669) We have broken UI for query result with many (in my case 40) columns

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1669:
--

 Summary: We have broken UI for query result with many (in my case 
40) columns
 Key: IGNITE-1669
 URL: https://issues.apache.org/jira/browse/IGNITE-1669
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov


Query for using with test-drive-sql
{code}
select 
Rand() as rnd1,
Rand() as rnd2,
Rand() as rnd3,
Rand() as rnd4,
Rand() as rnd5,
Rand() as rnd6,
Rand() as rnd7,
Rand() as rnd8,
Rand() as rnd9,
Rand() as rnd10,
Rand() as rnd11,
Rand() as rnd12,
Rand() as rnd13,
Rand() as rnd14,
Rand() as rnd15,
Rand() as rnd16,
Rand() as rnd17,
Rand() as rnd18,
Rand() as rnd19,
Rand() as rnd20,
Rand() as rnd1,
Rand() as rnd2,
Rand() as rnd3,
Rand() as rnd4,
Rand() as rnd5,
Rand() as rnd6,
Rand() as rnd7,
Rand() as rnd8,
Rand() as rnd9,
Rand() as rnd10,
Rand() as rnd11,
Rand() as rnd12,
Rand() as rnd13,
Rand() as rnd14,
Rand() as rnd15,
Rand() as rnd16,
Rand() as rnd17,
Rand() as rnd18,
Rand() as rnd19,
Rand() as rnd20
from Car
order by rnd6
{code}



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

[jira] [Created] (IGNITE-1670) "Loading..." overlay has incorrect position (right-top) - should be in the center of the tabe

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1670:
--

 Summary: "Loading..." overlay has incorrect position (right-top)  
- should be in the center of the tabe
 Key: IGNITE-1670
 URL: https://issues.apache.org/jira/browse/IGNITE-1670
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov


Execute any valid SQL query in table result view mode



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

[jira] [Created] (IGNITE-1671) Charts has broken position under Firefox

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1671:
--

 Summary: Charts has broken position under Firefox
 Key: IGNITE-1671
 URL: https://issues.apache.org/jira/browse/IGNITE-1671
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov


Please see attachment



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

[GitHub] ignite pull request: IGNITE-1622 - Fixed cache.clear() with near c...

[vkulichenko]

GitHub user vkulichenko opened a pull request:

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

IGNITE-1622 - Fixed cache.clear() with near cache



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

$ git pull https://github.com/vkulichenko/incubator-ignite ignite-1622

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

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


commit 2a400ae2aee1d2fbb163e46bbf7a9cbc7bc64ded
Author: Valentin Kulichenko 
Date:   2015-10-14T05:08:10Z

IGNITE-1622 - Fixed cache.clear() with near cache




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

[jira] [Created] (IGNITE-1672) The first column of exported table has fully qualified name, but others columns aren't

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1672:
--

 Summary: The first column of exported table has fully qualified 
name, but others columns aren't
 Key: IGNITE-1672
 URL: https://issues.apache.org/jira/browse/IGNITE-1672
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov


{code}
test-drive-car.PARKING.PARKINGNAME  MAXCARIDCNT
Parking 1   91  6
Parking 10  99  16
Parking 2   93  12
Parking 3   75  6
Parking 4   97  9
Parking 5   98  12
Parking 6   84  6
Parking 7   82  13
Parking 8   85  9
Parking 9   94  11

{code}



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

Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

[Denis Magda]

+1 (binding)

On 10/14/2015 1:30 AM, Konstantin Boudnik wrote:

Hi!

As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I propose
that we adopt a rule allowing for a Apache Ignite Chair rotation on a yearly
basis. The proposed policy is this:
   - a position of an Apache Ignite Chair gets elected for a year
   - after a year passes it is expected of the active Chair to start a
 [DISCUSS] email thread on priv...@ignite.apache.org asking PMC members to
 make a nomination for the next year
   - it is perfectly acceptable for the active chair to nominate him or
 herself
   - there is no limit on the number of terms that one person can serve as an
 Apache Ignite Chair.

Each term, however is exactly one year.

   [ ] +1 Adopt the Apache Ingite Chair rotation policy
   [ ] +0
   [ ] -1 Do not adopt the proposed policy (please provide a reason)

This VOTE will be held open for at least 72 hours.

Thanks,
   Cos