Re: IGNITE-1355 Potential NPE in CacheAffinityProxy
I agree with proposed changes.
--Yakov
2015-11-25 16:35 GMT+03:00 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 --
> > >
> >
>
[GitHub] ignite pull request: IGNITE-1936 implemented spa behavior to ignit...
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 creating new cache\metadata. commit a2e00c28ca56b3faca7449333c03342bb007d20f Author: Andrey Date: 2015-10-20T07:32:47Z IGNITE-1710 update employee, car with random values commit 5427b87d2c5aa61c42ee77798d1c5938b22ee032 Author: Andrey Date: 2015-10-20T09:46:19Z IGNITE-1706 Fixed editor UI commit 87631e476d2b9881c063ecab8b43530af83914c2 Author: Alexey Kuznetsov Date: 2015-10-20T10:42:25Z IGNITE-1200 WIP on IGFS support. commit bd7b27d3f9016885f2ef3f36a40754d04aba8ad7 Author: Alexey Kuznetsov Date: 2015
Re: Check Ignite code base with Findbugs.
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: Update scala to 2.11.7 and spark to 1.5.2
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
[GitHub] ignite pull request: IGNITE-529: Fixed README
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
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
Re: Update scala to 2.11.7 and spark to 1.5.2
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: Check Ignite code base with Findbugs.
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?
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: Branch deletion prohibited
On Tue, Nov 24, 2015 at 05:53AM, Branko Čibej wrote: > On 23.11.2015 20:41, Konstantin Boudnik wrote: > > On Mon, Nov 23, 2015 at 09:08AM, Branko Čibej wrote: > >> On 23.11.2015 04:13, Konstantin Boudnik wrote: > >>> On Sun, Nov 22, 2015 at 02:16PM, Dmitriy Setrakyan wrote: > Cos, > > I believe this is the ticket: > https://issues.apache.org/jira/browse/INFRA-10798 > > This policy does seem myopic, would be great if Ignite could get an > exemption. > >>> Thanks! I already have sent email to the board where this discussion is > >>> going > >>> right now. Hopefully, this ban will be lifted soon. > >> The best way to get this changed is to invent a workflow that doesn't > >> delete important information. "Important" in this case meaning "always > >> knowing where a particular bit of code came from". Most "optimal" Git > >> workflows tend to happily rebase and squash such info out the window. > > How it is different if I take _all_ code in an SVN trunk, pack into a giant > > tarball, then create a fresh branch and commit that blob as a single commit? > > Not different at all. But my point is that Git allows you to do that > with one command, and many workflows based on Git actively encourage > (dare I say mandate) that sort of thing. Whereas it's less likely that > anyone using SVN would propose such a workflow, since it'd be such a > huge pain to follow. > > > The situation isn't git specific - it's people specific. Solving people > > problem with tech never works, really. > > That's why I wrote "Git workflows", not "Git"; workflows are invented by > people, not software. I agree that the prohibition on branch deletions > isn't a solution; it's a stopgap, which everyone admits. I believe we are in agreement here, just nibbling around the edges. Say, in Bigtop we aren't even discussing things like force-pushing master or release branches. On the other hand, what ppl are doing with their integration/dev branches is no one else business, really. > >> Case in point: when Ignite was incubating, we had an issue where we > >> could not track the IP of the JSR166 backports (ConcurrentHashMap et > >> al.), neither in the ASF repo (which was sort-of expected) nor in the > >> original GridGain repo, because info about the original import was lost. > >> We ended up having to remove those files and re-import them from the > >> canonical source, so that we could be certain about the license. In this > >> case, by sheer luck, the solution was simple. > > The assumption that it happened because of git is non consequential, > > actually. > > Most likely that was a result of some mundane reasons like moving > > repos/re-importing the code from one place to another, etc. Keep in mind, > > the > > code base is like 8 years old, and wasn't in git originally. Perhaps it was > > sitting in SVN and brought-up to git with fast-import, which shouldn't be > > used > > really. > > Did I say it's "because of Git"? I did not; I said it's because of the > workflows people tend to use with Git. Let's not make this a Git vs. SVN > debate, because it's not and the embers (not flames yet) are just > distracting from the topic. > > I guess my example wasn't well chosen; I should've looked for one that > happened recently in ASF code. > > > >> The ASF promises its users that we have complete oversight of the IP in > >> our released source and can easily audit any single byte of source all > >> the way to its original author. Deleting a branch in Git (and other > >> destructive changes) can make auditing extremely hard, in some cases > >> impossible. > >> > >> Granted that forbidding branch deletions isn't the only way to solve > >> this problem; but it certainly goes a long way towards fixing it. Now > >> it's up to *you* guys (i.e., every project at the ASF that uses Git > >> repos) to come up with a workflow that allows branch deletions but > >> doesn't lose the ability to audit the source; forbidding squashed merges > >> would probably do it, but I'm sure there are other ways. > > That sounds like tossing the problem from one side of the fence to another. > > PMC should be in control of the project IP and all other paraphernalia. PMC > > is > > responsible before the board for this type if policy commotions. I am not > > trying > > to dismiss the importance of the paper-trail for IP-related issues. All I am > > saying that disabling a perfectly valid functionality because there's a > > chance > > of somebody misusing it, is like UK prohibiting the sales of the > > butter-knives > > to the under aged: ludicrous at best. > > You'll note that the board told Infra to do this as a stopgap to prevent > "responsible PMCs" from further messing up our IP provenance. Clearly, > some PMCs are not responsible. It's painful that the restriction hurt > all PMCs. > > Instead of complaining to me, it'd be far more useful to work with those I am not really complaining, but having an interesting (to me at
Re: IGFS: properties to use for implicit mkdirs
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
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
[ANNOUNCE] CFP open for ApacheCon North America 2016
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: Necessity to have MBeanServerResource annotation
Got all of you thanks. Merged the changes from https://issues.apache.org/jira/browse/IGNITE-1800 Roman, thanks for the contribution! -- Denis On 11/25/2015 3:55 PM, Nikolay Tikhonov wrote: Artem right. The annotation should be removed in https://issues.apache.org/jira/browse/IGNITE-35 ticket. On Wed, Nov 25, 2015 at 12:34 PM, Yakov Zhdanov wrote: Thanks for clarifications, Artem! --Yakov 2015-11-25 12:27 GMT+03:00 Artem Shutak : Igniters, As I remember, support of the annotation has been deleted intentionally. I think Nik can shed light on this. By the way, currently, you can use IgniteInstanceResource annotation to get Ignite instance and getting MBeanServer. ignite.configuration().getMBeanServer() Thanks, -- Artem -- On Wed, Nov 25, 2015 at 12:19 PM, Yakov Zhdanov wrote: Guys, I don't think we should delete this since it is not hard at all to fix injection properly. --Yakov 2015-11-25 11:40 GMT+03:00 Denis Magda : Igniters, There is MBeanServerResource annotation available as a part of Ignite. However, according to this JIRA issue [1] its never processed at the kernel level. My understanding is that we should neither delete it nor deprecate but rather support at the kernel level injecting MBeanServer when the latter is specified in IgniteConfiguration. Any thoughts on this? [1] https://issues.apache.org/jira/browse/IGNITE-1800
[GitHub] ignite pull request: ignite-2005 Java client tests fixed
GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/264 ignite-2005 Java client tests fixed You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-2005 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/264.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 #264 commit fa2f44309f6e90085f2dcddf4d023fbcf2f59588 Author: agura Date: 2015-11-25T15:41:35Z ignite-2005 Java client tests fixed --- 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-2005) [Test failed] Ignite Java Client suite fails
Andrey Gura created IGNITE-2005:
---
Summary: [Test failed] Ignite Java Client suite fails
Key: IGNITE-2005
URL: https://issues.apache.org/jira/browse/IGNITE-2005
Project: Ignite
Issue Type: Test
Reporter: Andrey Gura
Assignee: Andrey Gura
Ignite Java Client suite can fail because
{{RouterFactorySelfTest.testRouterFactory}} test can affect next tests.
http://94.72.60.102/viewLog.html?buildId=574698&tab=buildResultsDiv&buildTypeId=Ignite_JavaClient
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Optional modules without README and apache license
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
[jira] [Created] (IGNITE-2004) Asynchronous execution of ContinuousQuery's remote filter
Denis Magda created IGNITE-2004: --- Summary: Asynchronous execution of ContinuousQuery's remote filter Key: IGNITE-2004 URL: https://issues.apache.org/jira/browse/IGNITE-2004 Project: Ignite Issue Type: Bug Components: cache Affects Versions: ignite-1.4 Reporter: Denis Magda Fix For: 1.6 Presently remote filters are executed synchronously an entry update. This leads to the limitation when it's disallowed to perform cache related operation in a filter body. It's required to add the ability to execute remote filters asynchronously. This will let to execute any kind of operations including cache operations directly in the filter body. The solution must be fault-tolerant. At least once execution of a filter in case of a failure works fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Igfs PURGE events: do we need them?
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/ .) 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. > > >
[jira] [Created] (IGNITE-2003) Some optional modules don't have Apache licenses file and README.txt
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)
Re: IGNITE-1355 Potential NPE in CacheAffinityProxy
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 --
> >
>
[GitHub] ignite pull request: IGNITE-1355 Potential NPE in CacheAffinityPro...
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: Necessity to have MBeanServerResource annotation
Artem right. The annotation should be removed in https://issues.apache.org/jira/browse/IGNITE-35 ticket. On Wed, Nov 25, 2015 at 12:34 PM, Yakov Zhdanov wrote: > Thanks for clarifications, Artem! > > --Yakov > > 2015-11-25 12:27 GMT+03:00 Artem Shutak : > > > Igniters, > > > > As I remember, support of the annotation has been deleted intentionally. > I > > think Nik can shed light on this. > > > > By the way, currently, you can use IgniteInstanceResource annotation to > get > > Ignite instance and getting MBeanServer. > > > > ignite.configuration().getMBeanServer() > > > > Thanks, > > -- Artem -- > > > > On Wed, Nov 25, 2015 at 12:19 PM, Yakov Zhdanov > > wrote: > > > > > Guys, I don't think we should delete this since it is not hard at all > to > > > fix injection properly. > > > > > > --Yakov > > > > > > 2015-11-25 11:40 GMT+03:00 Denis Magda : > > > > > > > Igniters, > > > > > > > > There is MBeanServerResource annotation available as a part of > Ignite. > > > > However, according to this JIRA issue [1] its never processed at the > > > > kernel level. > > > > > > > > My understanding is that we should neither delete it nor deprecate > but > > > > rather support at the kernel level injecting MBeanServer when the > > latter > > > is > > > > specified in IgniteConfiguration. > > > > > > > > Any thoughts on this? > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-1800 > > > > > > > > > >
[GitHub] ignite pull request: Ignite 1679
GitHub user iveselovskiy opened a pull request: https://github.com/apache/ignite/pull/262 Ignite 1679 You can merge this pull request into a Git repository by running: $ git pull https://github.com/iveselovskiy/ignite ignite-1679 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/262.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 #262 commit f7a08b5968e3d8345bdab09477b44acccb1e06c4 Author: iveselovskiy Date: 2015-11-16T18:38:01Z ignite-1639 commit 267e8a5a60b623c8dced0ddee98169c39ed8bff0 Author: iveselovskiy Date: 2015-11-18T13:27:22Z Merge branch 'master' of https://github.com/apache/ignite commit 668bf96d0b99392d561a8b6cea18e2c3dd9270e3 Author: iveselovskiy Date: 2015-11-20T13:04:49Z Revert "ignite-1639" This reverts commit f7a08b5968e3d8345bdab09477b44acccb1e06c4. commit c22eff5d093c9b969e7bd3b82d69f50d143e5c0e Author: iveselovskiy Date: 2015-11-23T12:51:00Z Merge branch 'master' of https://github.com/apache/ignite commit e099dba4c973bf47fa1e0a143dd7caec7e91ab40 Author: iveselovskiy Date: 2015-11-25T12:40:59Z IGNITE-1679: purge events made consistent. commit 6e43c3199b4ab39ac522502f48fc391d6b48a4d2 Author: iveselovskiy Date: 2015-11-25T12:41:45Z Merge branch 'master' of https://github.com/apache/ignite into ignite-1679 --- 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-2002) .Net: Data streamer does not work with peerClassLoadingEnabled
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-2001) Need to add cache name to the JdbcType bean
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 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-1999) .Net: ServiceExample quickly close after execution
Vasilisa Sidorova created IGNITE-1999: -- Summary: .Net: ServiceExample quickly close after execution Key: IGNITE-1999 URL: https://issues.apache.org/jira/browse/IGNITE-1999 Project: Ignite Issue Type: Bug Affects Versions: 1.5 Environment: Win7 64bit, MS Visual C++ 2010 Professional, Apache Ignite 1.5.0 build #83 Reporter: Vasilisa Sidorova Assignee: Pavel Tupitsyn Priority: Trivial Fix For: 1.6 ServiceExample quickly close after execution and it's difficult to read the results. Proposal: add Console.ReadKey() as for all others examples -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Necessity to have MBeanServerResource annotation
Thanks for clarifications, Artem! --Yakov 2015-11-25 12:27 GMT+03:00 Artem Shutak : > Igniters, > > As I remember, support of the annotation has been deleted intentionally. I > think Nik can shed light on this. > > By the way, currently, you can use IgniteInstanceResource annotation to get > Ignite instance and getting MBeanServer. > > ignite.configuration().getMBeanServer() > > Thanks, > -- Artem -- > > On Wed, Nov 25, 2015 at 12:19 PM, Yakov Zhdanov > wrote: > > > Guys, I don't think we should delete this since it is not hard at all to > > fix injection properly. > > > > --Yakov > > > > 2015-11-25 11:40 GMT+03:00 Denis Magda : > > > > > Igniters, > > > > > > There is MBeanServerResource annotation available as a part of Ignite. > > > However, according to this JIRA issue [1] its never processed at the > > > kernel level. > > > > > > My understanding is that we should neither delete it nor deprecate but > > > rather support at the kernel level injecting MBeanServer when the > latter > > is > > > specified in IgniteConfiguration. > > > > > > Any thoughts on this? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-1800 > > > > > >
Re: Update scala to 2.11.7 and spark to 1.5.2
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
Re: Necessity to have MBeanServerResource annotation
Igniters, As I remember, support of the annotation has been deleted intentionally. I think Nik can shed light on this. By the way, currently, you can use IgniteInstanceResource annotation to get Ignite instance and getting MBeanServer. ignite.configuration().getMBeanServer() Thanks, -- Artem -- On Wed, Nov 25, 2015 at 12:19 PM, Yakov Zhdanov wrote: > Guys, I don't think we should delete this since it is not hard at all to > fix injection properly. > > --Yakov > > 2015-11-25 11:40 GMT+03:00 Denis Magda : > > > Igniters, > > > > There is MBeanServerResource annotation available as a part of Ignite. > > However, according to this JIRA issue [1] its never processed at the > > kernel level. > > > > My understanding is that we should neither delete it nor deprecate but > > rather support at the kernel level injecting MBeanServer when the latter > is > > specified in IgniteConfiguration. > > > > Any thoughts on this? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-1800 > > >
Re: Necessity to have MBeanServerResource annotation
Guys, I don't think we should delete this since it is not hard at all to fix injection properly. --Yakov 2015-11-25 11:40 GMT+03:00 Denis Magda : > Igniters, > > There is MBeanServerResource annotation available as a part of Ignite. > However, according to this JIRA issue [1] its never processed at the > kernel level. > > My understanding is that we should neither delete it nor deprecate but > rather support at the kernel level injecting MBeanServer when the latter is > specified in IgniteConfiguration. > > Any thoughts on this? > > [1] https://issues.apache.org/jira/browse/IGNITE-1800 >
Necessity to have MBeanServerResource annotation
Igniters, There is MBeanServerResource annotation available as a part of Ignite. However, according to this JIRA issue [1] its never processed at the kernel level. My understanding is that we should neither delete it nor deprecate but rather support at the kernel level injecting MBeanServer when the latter is specified in IgniteConfiguration. Any thoughts on this? [1] https://issues.apache.org/jira/browse/IGNITE-1800
