[ANNOUNCE] CFP open for ApacheCon North America 2016

[Rich Bowen]

Community growth starts by talking with those interested in your
project. ApacheCon North America is coming, are you?

We are delighted to announce that the Call For Presentations (CFP) is
now open for ApacheCon North America. You can submit your proposed
sessions at
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
for big data talks and
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
for all other topics.

ApacheCon North America will be held in Vancouver, Canada, May 9-13th
2016. ApacheCon has been running every year since 2000, and is the place
to build your project communities.

While we will consider individual talks we prefer to see related
sessions that are likely to draw users and community members. When
submitting your talk work with your project community and with related
communities to come up with a full program that will walk attendees
through the basics and on into mastery of your project in example use
cases. Content that introduces what's new in your latest release is also
of particular interest, especially when it builds upon existing well
know application models. The goal should be to showcase your project in
ways that will attract participants and encourage engagement in your
community, Please remember to involve your whole project community (user
and dev lists) when building content. This is your chance to create a
project specific event within the broader ApacheCon conference.

Content at ApacheCon North America will be cross-promoted as
mini-conferences, such as ApacheCon Big Data, and ApacheCon Mobile, so
be sure to indicate which larger category your proposed sessions fit into.

Finally, please plan to attend ApacheCon, even if you're not proposing a
talk. The biggest value of the event is community building, and we count
on you to make it a place where your project community is likely to
congregate, not just for the technical content in sessions, but for
hackathons, project summits, and good old fashioned face-to-face networking.

-- 
rbo...@apache.org
http://apache.org/

Re: Check Ignite code base with Findbugs.

[Konstantin Boudnik]

On Tue, Nov 24, 2015 at 10:50AM, Alexey Kuznetsov wrote:
> Igniters,
> 
> I've installed FindBugs plugin for Idea and run it on ignite-core module.
> 
> Well it found a lot... 1331 items...

Better than 100500, eh? :)

> Some of them are false-positive of course, but this plugin has quite handy
> grouping
>  and we could only check important groups like "Multithreading".
> 
> 
> Also FindBugs found a bunch of silly bugs like this in GridCacheAdapter:
> ---
> Nullcheck of res at line 5936 of value previously dereferenced
> 
> for (ComputeJobResult res : results) {
> line 5936 >>>  if (res.getException() == null && res != null)
> size += res.getData();
> }
> ---
> 
> I think it is worth to install this plugin and take a look.
> 
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com


signature.asc
Description: Digital signature

Re: Igfs PURGE events: do we need them?

[Konstantin Boudnik]

On Wed, Nov 25, 2015 at 04:54PM, Ivan V. wrote:
> Hi, Konstantin,
> "TRASH" (the name comes from
> org.apache.ignite.internal.processors.igfs.IgfsFileInfo#TRASH_ID Java
> constant) notion is only applicable to primary (IGFS) file system. This is
> a special "folder" that does not have file system path. When IGFS is
> running over a secondary Fs, TRASH also exists in the primary IGFS, but
> does not exist in the secondary Fs.
> In secondary Fs deletion is performed just through the ordinary Fs API. So,
> we *do not* employ any assumption regarding the TRASH existence and
> behavior in the secondary Fs.
> 
> As Dmitriy mentioned above, TRASH in primary Fs is needed for performance
> reasons: with it we delete file with only 1 transaction in Meta cache: we
> do not do any transactions in Data cache.
> (Similar technique is frequently applied frequently in real Fs deletion,
> like mv foo /tmp/ && rm -r /tmp/foo/ .)

I understand. However, I am wary about the potentially funny and inconsistent
cases when an _optional_ secondary file system is plugged in.

Cos

> Currently we have fix of https://issues.apache.org/jira/browse/IGNITE-1679
> that makes PURGE events enabled for all files.
> I still not quite realize how this functionality will be used by customers,
> but now it is repaired: once merged, you will be able to use it.
> 
> On Tue, Nov 24, 2015 at 2:52 AM, Dmitriy Setrakyan 
> wrote:
> 
> > Cos,
> >
> > The main reason soft delete was added is performance. Without soft-delete,
> > the delete operation would have to wait until a file is fully deleted from
> > a folder, which may take time.
> >
> > As far as secondary FS handling it, IGFS does not require a secondary FS,
> > so we should account for cases when IGFS is running stand-alone.
> >
> > Thoughts?
> >
> > D.
> >
> > On Mon, Nov 23, 2015 at 11:00 PM, Konstantin Boudnik 
> > wrote:
> >
> > > Let me ask a different question: what's the point of having the concept
> > of
> > > TRASH?
> > >
> > > Here's an example why I think the 'soft' delete would only complicate
> > > thing.
> > > Suppose IGFS is sitting on top of HDFS and both have 'Trash' enabled.
> > Now,
> > > the file is getting soft-deleted from IGFS and is moved to TRASH folder.
> > > But
> > > in HDFS it is also a move to a place which doesn't have any special
> > meaning
> > > for HDFS.
> > >
> > > Even worst, if IFGS TRASH is linked to HDFS .Trash. HDFS has it's own
> > > policy
> > > on how to clean that up, which is likely to be different from that on
> > IGFS.
> > > Often enough, HDFS .Trash is simply disabled. This discrepancy is going
> > to
> > > create a situation when a file should still be in TRASH, but the
> > secondary
> > > FS
> > > has already purged it.
> > >
> > > And what if yet another secondary file system like S3 has yet another
> > > policy
> > > around their own trash, which they don't even have, I believe?
> > >
> > > Where I am going with this is pretty straight forward: let's drop the
> > > soft-delete support and let the secondary FS to deal with it. If there's
> > no
> > > secondary FS configured - the content of deleted file will have to
> > > retrieved
> > > by other means.
> > >
> > > Thoughts?
> > >   Cos
> > >
> > > On Fri, Nov 20, 2015 at 07:15PM, Ivan V. wrote:
> > > > Hi, dev,
> > > > need opinions on the question discussed in
> > > > https://issues.apache.org/jira/browse/IGNITE-1679  (IGFS: Purge event
> > is
> > > > inconsistent).
> > > > In short: in Igfs we have "soft" delete that moves the deleted file or
> > > > folder to special "TRASH" folder.
> > > > Special async worker walks inside TRASH and removes the items
> > > permanently.
> > > > When an item is completely removed, an event of type
> > > > org.apache.ignite.events.EventType#EVT_IGFS_FILE_PURGED  is fired.
> > > > But such events are now fired only for files, and only in case if such
> > > file
> > > > was deleted itself, but not a part of a folder sub-tree. It's quite
> > > obvious
> > > > that such behavior is not quite consistent, so we should either get rid
> > > of
> > > > PURGE events at all, or make them consistent.
> > > > In the latter case it would be good to have answer to the question:
> > what
> > > > are real  use cases when we may need the purge events ? (Now they seem
> > to
> > > > be used in tests only).
> > > > If we don't have such real use cases, are there any objections to get
> > rid
> > > > of the purge events at all?
> > > > Thanks in advance.
> > >
> >


signature.asc
Description: Digital signature

Re: Update scala to 2.11.7 and spark to 1.5.2

[Konstantin Boudnik]

Did Spark do it again and bumped the SDK version inside of a subminor release?
I guess it's time to simply get over the fact that some people just never learn 
;(

Cos

On Tue, Nov 24, 2015 at 04:53PM, Alexey Kuznetsov wrote:
> Hi!
> 
> How about to update dependencies?
> 
> scala to 2.11.7 and spark to 1.5.2
> 
> Any objections?
> 
> If no I will create issue and update.
> -- 
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com


signature.asc
Description: Digital signature

Re: Update scala to 2.11.7 and spark to 1.5.2

[Alexey Kuznetsov]

Cos, not sure that I understand what do you mean...

I looked into sparck pom.xml and see that they also use scala 2.11.7
 and also in scala 2.11.7 release notes I see "A 300x more embeddable Scala
REPL, brought to you by a team effort with Apache Spark. "

Scala 2.11.7 is a bugfix update and I think it is safe to update Ignite
from scala 2.11.2 to scala 2.11.7

Could you tell us what is wrong from your point of view?

On Thu, Nov 26, 2015 at 9:33 AM, Konstantin Boudnik  wrote:

> Did Spark do it again and bumped the SDK version inside of a subminor
> release?
> I guess it's time to simply get over the fact that some people just never
> learn ;(
>
> Cos
>
> On Tue, Nov 24, 2015 at 04:53PM, Alexey Kuznetsov wrote:
> > Hi!
> >
> > How about to update dependencies?
> >
> > scala to 2.11.7 and spark to 1.5.2
> >
> > Any objections?
> >
> > If no I will create issue and update.
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Check Ignite code base with Findbugs.

[Alexey Kuznetsov]

Cos, that was only ONE module checked :)

And who knows what FindBugs will find when I start it over whole project.
:)

On Thu, Nov 26, 2015 at 9:31 AM, Konstantin Boudnik  wrote:

> On Tue, Nov 24, 2015 at 10:50AM, Alexey Kuznetsov wrote:
> > Igniters,
> >
> > I've installed FindBugs plugin for Idea and run it on ignite-core module.
> >
> > Well it found a lot... 1331 items...
>
> Better than 100500, eh? :)
>
> > Some of them are false-positive of course, but this plugin has quite
> handy
> > grouping
> >  and we could only check important groups like "Multithreading".
> >
> >
> > Also FindBugs found a bunch of silly bugs like this in GridCacheAdapter:
> > ---
> > Nullcheck of res at line 5936 of value previously dereferenced
> >
> > for (ComputeJobResult res : results) {
> > line 5936 >>>  if (res.getException() == null && res != null)
> > size += res.getData();
> > }
> > ---
> >
> > I think it is worth to install this plugin and take a look.
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: IGFS: properties to use for implicit mkdirs

[Konstantin Boudnik]

On Wed, Nov 25, 2015 at 09:26PM, Ivan V. wrote:
> umask is 0002 on my Linux. (This is why the middle directories have 775
> permission in the above experiment. 022 would lead to 755.)

Yeah, sorry - that's what I was going to say and the mixed up with my own ;)

Looks like the proposed fix makes sense, actually. Thanks for taking time
walking me through.

> On Mon, Nov 23, 2015 at 10:48 PM, Konstantin Boudnik  wrote:
> 
> > May I ask what's is the output of umask command on your system?
> >
> > Cos
> >
> > P.S. I have a hunch though it is 0022
> >
> > On Mon, Nov 23, 2015 at 02:01PM, Ivan V. wrote:
> > > Hi, Konstantin,
> > >
> > > >Perhaps more logical would be to do what Unix does: if permissions
> > aren't
> > > explicitly set during creation, those should be inherited from the
> > parent.
> > >
> > > as per my observations on Linux, the implicitly created directories take
> > > default permissions 0777 & ~umask but not inherit them from parent.
> > > E.g.
> > >  /bin/mkdir -m 700 a
> > >  /bin/mkdir -p -m 770 a/b/c/d
> > >
> > > gives the following result:
> > >  a700
> > >  a/b  775
> > >  a/b/c775
> > >  a/b/c/d  770
> > >
> > > ('touch' Unix command does not have ability to create parent
> > directories.)
> > > Or you mean a behavior of a built-in system function, but not the
> > standard
> > > commands?
> > >
> > > Currently suggested patch (see
> > > https://issues.apache.org/jira/browse/IGNITE-1637) fixes the behavior
> > > exactly as it is implemented in HDFS (because main function of IGFS is to
> > > be a replacement or a caching layer over HDFS):
> > > 
> > >
> > > If a file is created, the created directories get
> > > org.apache.hadoop.fs.permission.FsPermission#getDirDefault (0777)
> > > permission. Umask *is* applied to the created file, but is *not *applied
> > to
> > > the created directories.
> > >
> > > If a directory is created, all the parent directories are created with
> > the
> > > same permission that is requested for the directory itself. The only
> > > exception is that "wx" (write and execute) permissions are explicitly
> > added
> > > for the owner on the parent directories to be able to write child
> > > directories. Umask *is* applied to all the created directories.
> > > If umask conflicts with the added permissions , the added permissions
> > take
> > > priority.
> > > 
> > >
> > > Though, there is no problem to re-implement this in another way. Just
> > would
> > > like to make sure we have a proposal that is argued and agreed over the
> > > community.
> > >
> > > On Sat, Nov 21, 2015 at 6:37 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > On Fri, Nov 20, 2015 at 7:05 PM, Konstantin Boudnik 
> > > > wrote:
> > > >
> > > > > On Tue, Oct 13, 2015 at 08:01PM, Ivan Veselovskiy wrote:
> > > > > > 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?
> > > > >
> > > > > Looks like this is way to late, but still... Perhaps more logical
> > would
> > > > be
> > > > > to
> > > > > do what Unix does: if permissions aren't explicitly set during
> > creation,
> > > > > those should be inherited from the parent.
> > > > >
> > > > > Does it makes sense?
> > > > >
> > > >
> > > > Makes sense to me.
> > > >
> > > >
> > > > >   Cos
> > > > >
> > > >
> >


signature.asc
Description: Digital signature

[GitHub] ignite pull request: IGNITE-529: Fixed README

[shroman]

GitHub user shroman opened a pull request:

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

IGNITE-529: Fixed README



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

$ git pull https://github.com/shroman/ignite ignite-529-readme

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

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


commit 739ba495cd2913ac8dc581a428c6ca3a07d744e4
Author: shtykh_roman 
Date:   2015-11-26T02:40:48Z

IGNITE-529: Fixed README




---
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: properties to use for implicit mkdirs

[Ivan V.]

umask is 0002 on my Linux. (This is why the middle directories have 775
permission in the above experiment. 022 would lead to 755.)

On Mon, Nov 23, 2015 at 10:48 PM, Konstantin Boudnik  wrote:

> May I ask what's is the output of umask command on your system?
>
> Cos
>
> P.S. I have a hunch though it is 0022
>
> On Mon, Nov 23, 2015 at 02:01PM, Ivan V. wrote:
> > Hi, Konstantin,
> >
> > >Perhaps more logical would be to do what Unix does: if permissions
> aren't
> > explicitly set during creation, those should be inherited from the
> parent.
> >
> > as per my observations on Linux, the implicitly created directories take
> > default permissions 0777 & ~umask but not inherit them from parent.
> > E.g.
> >  /bin/mkdir -m 700 a
> >  /bin/mkdir -p -m 770 a/b/c/d
> >
> > gives the following result:
> >  a700
> >  a/b  775
> >  a/b/c775
> >  a/b/c/d  770
> >
> > ('touch' Unix command does not have ability to create parent
> directories.)
> > Or you mean a behavior of a built-in system function, but not the
> standard
> > commands?
> >
> > Currently suggested patch (see
> > https://issues.apache.org/jira/browse/IGNITE-1637) fixes the behavior
> > exactly as it is implemented in HDFS (because main function of IGFS is to
> > be a replacement or a caching layer over HDFS):
> > 
> >
> > If a file is created, the created directories get
> > org.apache.hadoop.fs.permission.FsPermission#getDirDefault (0777)
> > permission. Umask *is* applied to the created file, but is *not *applied
> to
> > the created directories.
> >
> > If a directory is created, all the parent directories are created with
> the
> > same permission that is requested for the directory itself. The only
> > exception is that "wx" (write and execute) permissions are explicitly
> added
> > for the owner on the parent directories to be able to write child
> > directories. Umask *is* applied to all the created directories.
> > If umask conflicts with the added permissions , the added permissions
> take
> > priority.
> > 
> >
> > Though, there is no problem to re-implement this in another way. Just
> would
> > like to make sure we have a proposal that is argued and agreed over the
> > community.
> >
> > On Sat, Nov 21, 2015 at 6:37 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Fri, Nov 20, 2015 at 7:05 PM, Konstantin Boudnik 
> > > wrote:
> > >
> > > > On Tue, Oct 13, 2015 at 08:01PM, Ivan Veselovskiy wrote:
> > > > > 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?
> > > >
> > > > Looks like this is way to late, but still... Perhaps more logical
> would
> > > be
> > > > to
> > > > do what Unix does: if permissions aren't explicitly set during
> creation,
> > > > those should be inherited from the parent.
> > > >
> > > > Does it makes sense?
> > > >
> > >
> > > Makes sense to me.
> > >
> > >
> > > >   Cos
> > > >
> > >
>

EntryProcessor execution semantics

[Andrey Kornev]

Hello,

I'd like to ask the community members to share their thoughts/opinions on the 
following subject.

JCache provides a way to atomically execute one or more actions against a cache 
entry using the Entry Processor mechanism. The Cache interface exposes an 
invoke() method that takes a key of the cache entry to be acted upon and an 
instance of the EntryProcessor interface as its parameters. When invoked, the 
entry processor will be passed an instance of JCache's MutableEntry which gives 
the processor exclusive access to the cache entry for the duration of the 
EntryProcessor.process() call. Great feature for delta updates, in-place 
compute, coordination/agreement (a la zookeeper), and so on!

Now, if one were to put his Ignite user hat on, what execution semantics would 
you as a user expect? Specifically,
1) the EntryProcessor is executed on the key's primary node as well as all 
backup nodes.
2) the EntryProcessor is executed only on the key's primary node.
3) something else.

Unfortunately JCache spec doesn't provide much details on this feature. Ignite 
documentation is silent, too.

Thanks
Andrey
  

[GitHub] ignite pull request: IGNITE-1936 implemented spa behavior to ignit...

[Dmitriyff]

GitHub user Dmitriyff opened a pull request:

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

IGNITE-1936 implemented spa behavior to ignite console



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

$ git pull https://github.com/Dmitriyff/ignite ignite-1936

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

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


commit 8c176b43785db675535795d3307a0249386d6895
Author: Andrey 
Date:   2015-10-16T10:10:32Z

Merge remote-tracking branch 'origin/ignite-843-rc1' into ignite-843-rc1

commit e4078904f2ef611d1dd0fb1030b7c281023a24f1
Author: Andrey 
Date:   2015-10-16T10:36:19Z

IGNITE-843 Hide token

commit d0945a1096acb030022315a4a8e7f6d7dd5ea5e6
Author: Alexey Kuznetsov 
Date:   2015-10-16T10:54:05Z

IGNITE-1705 Fixed x-axis labels in special case. Fixed clear history on 
query change.

commit c7cf31cd3f02b42145cdf328e6ac819cb7fd73b8
Author: AKuznetsov 
Date:   2015-10-16T16:16:48Z

IGNITE-843 Fixed load metadata logic in case of agent not started. Tweaked 
loading indicator options.

commit dbfc76fad6a9c55c837c4c0cf0c3da24858c97fc
Author: Andrey 
Date:   2015-10-19T02:49:38Z

IGNITE-1707 Hide copy to clipboard button if browser not support this.

commit 8203c32faf06a355af21e39c2de2a95aaab995dc
Author: Alexey Kuznetsov 
Date:   2015-10-19T03:20:57Z

Merge branches 'ignite-843-rc1' and 'master' of 
https://git-wip-us.apache.org/repos/asf/ignite into ignite-843-rc1

commit e80d624a559778b65352c88d6453db7bdf43c840
Author: Alexey Kuznetsov 
Date:   2015-10-19T03:23:21Z

IGNITE-1714 Added "model" to default package name.

commit c6abe820672acffd5b82106212b796e8d807ac3a
Author: Alexey Kuznetsov 
Date:   2015-10-19T07:29:32Z

IGNITE-1705 Fixed X-axis in special case.

commit 09fe9b66ea8117fdb510301547859100301a06e5
Author: Andrey 
Date:   2015-10-19T08:57:09Z

IGNITE-1713 Fixed npe on missed notebook.

commit 07805f61b0f7384396ba8fb7012bd324ee35bdb7
Author: Andrey 
Date:   2015-10-19T09:07:02Z

IGNITE-1711 Save notebook on remove paragraph.

commit 7fc27c0d774611c10e84da9356411fe0bf3eaccd
Author: Andrey 
Date:   2015-10-19T09:47:07Z

IGNITE-843 Add placeholder for sql

commit 8417fd7e81afefdd31fb23b0962fea054fb8c7c7
Author: Alexey Kuznetsov 
Date:   2015-10-19T10:07:03Z

Merge remote-tracking branch 'origin/ignite-843-rc1' into ignite-843-rc1

commit 7c5c2df74d3a22dd7680bfe5aea34034e18bbb99
Author: Andrey 
Date:   2015-10-19T11:22:43Z

IGNITE-1673 Show proper message if node missing on sql.

commit bc7a4de1624741359bc1011ff5a6232fdbdf2440
Author: Alexey Kuznetsov 
Date:   2015-10-19T11:43:01Z

Merge remote-tracking branch 'origin/ignite-843-rc1' into ignite-843-rc1

commit 939473f9975d3063b944ecd71e0a829033c9d6af
Author: Alexey Kuznetsov 
Date:   2015-10-19T12:09:30Z

IGNITE-1714 Fixed java and xml code generation. Fixed load metadata from 
DB. Reorganized summary ZIP content. Added pom.xml and README.txt generation.

commit 7413de17224b46ef9b64797ad9195ad77f409e7d
Author: Alexey Kuznetsov 
Date:   2015-10-19T12:11:12Z

IGNITE-1714 Minor.

commit 61ebc19cc9c319ad796571a32cf64b6d42d36be9
Author: Alexey Kuznetsov 
Date:   2015-10-20T01:44:17Z

Merge branches 'ignite-843-rc1' and 'master' of 
https://git-wip-us.apache.org/repos/asf/ignite into ignite-843-rc1

commit 432e5566ba5214b86b7ed8b43a9cfc38e9eaedec
Author: vsisko 
Date:   2015-10-20T02:00:12Z

IGNITE-1649 Additional checks.

commit 3507435e3163aca5834f6b35d3a5bf83e6b1aaa7
Author: Andrey 
Date:   2015-10-20T03:42:53Z

IGNITE-1687 Minor improvement

commit 4c35575b2e6c10cd563ad2b5d0024ea9ffe947d4
Author: Alexey Kuznetsov 
Date:   2015-10-20T04:06:08Z

IGNITE-1714 Added support for JDBC drivers in pom.xml and fixed java code 
generation of datasources.

commit 4cc2dc98a1365b87f5b201d555748f718584e3fc
Author: Alexey Kuznetsov 
Date:   2015-10-20T04:06:28Z

Merge remote-tracking branch 'origin/ignite-843-rc1' into ignite-843-rc1

commit a362b8b7a10b18a399301a08589faf913ef2497b
Author: Andrey 
Date:   2015-10-20T04:45:07Z

IGNITE-1710 update employee, car with random values

commit f234578c581e8e6584a77b56dd8c2a36581b4565
Author: Andrey 
Date:   2015-10-20T07:32:40Z

IGNITE-1709 Select cluster\cache when 

Optional modules without README and apache license

[Vasilisa Sidorova]

Dear Igniters,
we have following optional modules without README.txt and apache-2.0.txt
license files:

README.txt is not found:
ignite-jms11
ignite-kafka
ignite-mqtt
ignite-zookeeper

apache-2.0.txt is not found:
ignite-jms11
ignite-mqtt
ignite-zookeeper

I've filed the issue https://issues.apache.org/jira/browse/IGNITE-2003

We are close to the release 1.5. So it will be great if the contributors
(who added modules above) fixed it according to
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Checklistbeforepush

Otherwise it takes more time for others contributors to write documentation
about unknown modules.

Vasilisa

Re: Update scala to 2.11.7 and spark to 1.5.2

[Alexey Kuznetsov]

Igniters,

I've updated scala dependencies to latest stable one: scala to 2.11.7 and
spark to 1.5.2
TeamCity and QA smoke test passed.
I've merged changes to ignite-1.5.

On Tue, Nov 24, 2015 at 6:06 PM, Alexey Kuznetsov 
wrote:

> I created issue for that:
> https://issues.apache.org/jira/browse/IGNITE-1989
>
> On Tue, Nov 24, 2015 at 5:01 PM, Alexey Kuznetsov  > wrote:
>
>> Yes, I successfully build it locally,but not run tests on TC.
>>
>> On Tue, Nov 24, 2015 at 4:56 PM, Sergey Kozlov 
>> wrote:
>>
>>> Hi Alexey
>>>
>>> Have you tried to build Apache Ignite with suggested changes?
>>>
>>> On Tue, Nov 24, 2015 at 12:53 PM, Alexey Kuznetsov <
>>> akuznet...@gridgain.com>
>>> wrote:
>>>
>>> > Hi!
>>> >
>>> > How about to update dependencies?
>>> >
>>> > scala to 2.11.7 and spark to 1.5.2
>>> >
>>> > Any objections?
>>> >
>>> > If no I will create issue and update.
>>> > --
>>> > Alexey Kuznetsov
>>> > GridGain Systems
>>> > www.gridgain.com
>>> >
>>>
>>>
>>>
>>> --
>>> Sergey Kozlov
>>>
>>
>>
>>
>> --
>> Alexey Kuznetsov
>> GridGain Systems
>> www.gridgain.com
>>
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-2001) Need to add cache name to the JdbcType bean

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2001:
--

 Summary: Need to add cache name to the JdbcType bean
 Key: IGNITE-2001
 URL: https://issues.apache.org/jira/browse/IGNITE-2001
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


{code}



{code}



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

[jira] [Created] (IGNITE-2000) .Net: MessagingExample get exception after second execution

[Vasilisa Sidorova (JIRA)]

Vasilisa  Sidorova created IGNITE-2000:
--

 Summary: .Net: MessagingExample get exception after second 
execution
 Key: IGNITE-2000
 URL: https://issues.apache.org/jira/browse/IGNITE-2000
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.5
 Environment: Win7 64bit, MS Visual C++ 2010 Professional, Apache 
Ignite 1.5.0 build #83
Reporter: Vasilisa  Sidorova
 Fix For: 1.5


-
STEPS FOR REPRODUCE
-
# Build .Net project
# Run Apache.Ignite.exe remote node:
{noformat}
Apache.Ignite.exe -IgniteHome="%IGNITE_HOME%" 
-springConfigUrl=platforms\dotnet\examples\config\example-compute.xml 
-assembly=[path_to_Apache.Ignite.ExamplesDll.dll]
{noformat}
# Run MessagingExample
# Run MessagingExample once again
-
ACTUAL RESULT
-
The exception appears after example running:
{noformat}
System.InvalidOperationException was unhandled by user code
  HResult=-2146233079
  Message=Invalid attempt made to decrement the event's count below zero.
  Source=mscorlib
  StackTrace:
   at System.Threading.CountdownEvent.Signal()
   at Apache.Ignite.ExamplesDll.Messaging.LocalListener.Invoke(Guid nodeId, 
Int32 message) in 
C:\work_vsidorova\Ignite\ignite-last\platforms\dotnet\examples\Apache.Ignite.ExamplesDll\Messaging\LocalListener.cs:line
 54
   at 
Apache.Ignite.Core.Impl.Messaging.MessageListenerHolder.<>c__DisplayClass1`1.b__0(Guid
 id, Object msg)
   at 
Apache.Ignite.Core.Impl.Messaging.MessageListenerHolder.Invoke(IBinaryStream 
input)
   at 
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.<>c__DisplayClass80.b__7f()
   at 
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.SafeCall[T](Func`1 func, 
Boolean allowUnitialized)
  InnerException: 
{noformat}
-
EXPECTED RESULT
-
Example execute without any exception any times



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

[jira] [Created] (IGNITE-2002) .Net: Data streamer does not work with peerClassLoadingEnabled

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-2002:
---

 Summary: .Net: Data streamer does not work with 
peerClassLoadingEnabled
 Key: IGNITE-2002
 URL: https://issues.apache.org/jira/browse/IGNITE-2002
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
Priority: Critical
 Fix For: 1.6


Add  to spring config, 
run streamer tests or examples, there are exceptions in Java and flush hangs.



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

[jira] [Created] (IGNITE-2003) Some optional modules don't have Apache licenses file and README.txt

[Vasilisa Sidorova (JIRA)]

Vasilisa  Sidorova created IGNITE-2003:
--

 Summary: Some optional modules don't have Apache licenses file and 
README.txt
 Key: IGNITE-2003
 URL: https://issues.apache.org/jira/browse/IGNITE-2003
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
 Environment: Apache Ignite 1.5.0 build #84
Reporter: Vasilisa  Sidorova
Priority: Critical
 Fix For: 1.5


README.txt is absent for:

ignite-jms11
ignite-kafka
ignite-mqtt
ignite-zookeeper

apache-2.0.txt is absent for:

ignite-jms11
ignite-mqtt
ignite-zookeeper

Please, add it



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

[GitHub] ignite pull request: IGNITE-1355 Potential NPE in CacheAffinityPro...

[ashutakGG]

GitHub user ashutakGG opened a pull request:

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

IGNITE-1355 Potential NPE in CacheAffinityProxy (throw Exception if cache 
doesn't exist)

https://issues.apache.org/jira/browse/IGNITE-1355 (Potential NPE in 
CacheAffinityProxy)

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

$ git pull https://github.com/ashutakGG/incubator-ignite 
ignite-1355-exception

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

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


commit 2c9efe004d0264693263d57b77a1265e702e4abe
Author: ashutak 
Date:   2015-11-24T14:21:21Z

partial fix

commit 4ba864250679597b332ba28f5488f199e72b0f03
Author: ashutak 
Date:   2015-11-25T10:40:19Z

map-methods

commit 05730721975f1eaab9fe63d3400abd1bead3fb5e
Author: ashutak 
Date:   2015-11-25T10:58:14Z

javadoc.




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

Re: IGNITE-1355 Potential NPE in CacheAffinityProxy

[Artem Shutak]

Igniters,

I've fixed the issue according to the last discussed approach [1].

I've faced with the following API issues:
- IgniteCluster and Affinity interfaces have the same methods:
mapKeysToNodes and mapKeyToNode, which use the same implementation.
- The both methods in both interfaces say that they return special value in
case when cache doesn't exist (empty map for 'mapKeysToNodes' and null for
'mapKeyToNode').

I want do the following (already did in my PR [1]):
1. Deprecate the methods in IgniteCluster interface.
2. Change javadoc of the methods on Affinity interface. Javadoc will say
that an exception will be thrown if cache does not exist.

The problem is the point 2 breaks backward compatibility. But as I see from
the methods implementation, they can throw IgniteException in some cases
now, so a user should already have processing of the exception. So, I think
we can do these changes.

Thoughts?

[1] https://github.com/apache/ignite/pull/263

Thanks,
-- Artem --

On Thu, Nov 12, 2015 at 4:10 PM, Yakov Zhdanov  wrote:

> Any cache can be destroyed after proxy is created, so any cache may become
> unexistent at any moment. So, I would still allow proxy creation for
> unexistent caches, but throw an exception if cache does not exist at the
> moment of proxy method call.
>
> --Yakov
>
> 2015-11-12 16:01 GMT+03:00 Artem Shutak :
>
> > Igniters,
> >
> > I'm working on https://issues.apache.org/jira/browse/IGNITE-1355.
> >
> > I want to hear a community opinion what should do Ignite in case when
> user
> > uses Affinity for nonexistent cache? Current implementation returns
> > AffinityProxy on a call of Ignite.affinity("nonexistent_cache") and
> > AffinityProxy throws NPE on a call of any method if cache has not been
> > created yet.
> >
> > I see next possible decisions:
> > - Ignite.affinity("nonexistent_cache") can return 'null' instead of
> > AffinityProxy like Ignite does it for Ignite.cache("nonexistent_cache").
> > But it breaks backward compatibility.
> > - AffinityProxy methods can return a special value like 0 for
> > 'partitions()' method  and empty array for
> 'primaryPartitions(ClusterNode)'
> > method.
> > - AffinityProxy methods can throw Exception that cache does not exist.
> >
> > I vote for the second one.
> >
> > Thoughts?
> >
> > Thanks,
> > -- Artem --
> >
>