Choosing helper C++ libraries for interop.
Igniters, In upcoming interop efforts we will need concurrent collections and primitives in C++ layer. Obvious candidate is Boost, but it appears to be too heavy. Another library I found is Intel's TBB ( https://www.threadingbuildingblocks.org/) - it is open-source and pretty light. Does anyone has other ideas on this? Vladimir.
[jira] [Created] (IGNITE-925) We should correctly handle cross-cache query exceptions
Pavel Konstantinov created IGNITE-925: - Summary: We should correctly handle cross-cache query exceptions Key: IGNITE-925 URL: https://issues.apache.org/jira/browse/IGNITE-925 Project: Ignite Issue Type: Bug Components: cache Affects Versions: sprint-5 Reporter: Pavel Konstantinov Assignee: Sergi Vladykin Fix For: sprint-5 Grid with two nodes. Node1 contains cache1 with Type1 Node2 contains cache2 with Type2 Query: select * from 'cache1'.type1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Choosing C++ version for interop.
On Wed, May 20, 2015 at 12:01 AM, Vladimir Ozerov voze...@gridgain.com wrote: C++11 users can use C++03 projects, but not vice-versa. Are we sacrificing any features? (sorry, my C++ knowledge is limited). On Wed, May 20, 2015 at 9:52 AM, Dmitriy Setrakyan dsetrak...@apache.org wrote: On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov voze...@gridgain.com wrote: Igniters, We need to decide which C++ version to use in interop. Currently wide developer community is in progress of adopting C++11. But if we choose it, users might have problems if their CPP projects using older C++ revisions which are still very common. I think we should stick to C++03 revision for now. Thoughts? If we stick to this version, what are the consequences for users who run C++ 11? Vladimir.
Choosing C++ version for interop.
Igniters, We need to decide which C++ version to use in interop. Currently wide developer community is in progress of adopting C++11. But if we choose it, users might have problems if their CPP projects using older C++ revisions which are still very common. I think we should stick to C++03 revision for now. Thoughts? Vladimir.
Re: Choosing C++ version for interop.
On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov voze...@gridgain.com wrote: Igniters, We need to decide which C++ version to use in interop. Currently wide developer community is in progress of adopting C++11. But if we choose it, users might have problems if their CPP projects using older C++ revisions which are still very common. I think we should stick to C++03 revision for now. Thoughts? If we stick to this version, what are the consequences for users who run C++ 11? Vladimir.
Re: Choosing helper C++ libraries for interop.
Hi, I vote for Boost. From my understanding, it is the most comprehensive extension library, and very widely adopted. What do you mean by too heavy? - Did you try to use it and compare dll sizes? How big is the difference? - Does dll size really matter for us that much? Thanks, On Wed, May 20, 2015 at 9:20 AM, Vladimir Ozerov voze...@gridgain.com wrote: Igniters, In upcoming interop efforts we will need concurrent collections and primitives in C++ layer. Obvious candidate is Boost, but it appears to be too heavy. Another library I found is Intel's TBB ( https://www.threadingbuildingblocks.org/) - it is open-source and pretty light. Does anyone has other ideas on this? Vladimir. -- -- Pavel Tupitsyn GridGain Systems, Inc. www.gridgain.com
[jira] [Created] (IGNITE-926) Binary release should ends with -bin
Anton Vinogradov created IGNITE-926: --- Summary: Binary release should ends with -bin Key: IGNITE-926 URL: https://issues.apache.org/jira/browse/IGNITE-926 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Fwd: automatic patch validation on TC
Ok, I've reopened the root issue https://issues.apache.org/jira/browse/IGNITE-456 and will continue progress. If there is any objections, let me know. -- Artem -- On Tue, May 19, 2015 at 8:53 PM, Konstantin Boudnik c...@apache.org wrote: Here's two reasons why current approach is secure enough (and in fact has been used for some time on Apache build infrastructure): - only project contributors can manipulate JIRA: attaching, changing state, etc. Don't we trust our contributors? - if TC agents aren't running as privileged user - and they shouldn't be - malicious code won't do any harm to the system. Thoughts? Cos On Tue, May 19, 2015 at 04:47PM, Yakov Zhdanov wrote: Guys, It seems we need to stop any activity in this direction. I have just realized that automatic patch validation (at least in its form we agreed on) opens a huge security hole - anyone who attaches a patch to JIRA can execute literally any code (!) on our public TC - java/bash/binary/built-in OS/etc. Should I continue on what this can lead to? I think no. So, the only acceptable way is to assign committer to review a patch manually and then submit it to TC. Process in my view should be the following: 1. Contributor finishes with the task and attaches a patch to JIRA issue. 2. Committer picks up the issue and reviews the changes. 3. If changes are OK, committer submits them to TC in a separate branch. 4. After TC passes committer merges the changes to the target sprint branch. 5. JIRA issue gets closed. Thoughts? --Yakov 2015-05-05 23:31 GMT+03:00 Konstantin Boudnik c...@apache.org: Sergey and I had a good Skype call and everything seems to be resolved. The installed jira-cli tools work just fine http://bit.ly/1c2qmeH Attachments and comments do not need to be fetched using jira-cli. The proposed workflow for the automatic patching is explained at the bottom of dev-tools/src/main/groovy/jiraslurp.groovy please let me know if there are any questions about it. Sergey will see to make sure that we have parameterized builds, which will be triggered from the groovy script above. In fact, that is the last thing that is blocking the completion of this task. Looks like our off-line conversation with him helped to get the ball rolling! Cos On Wed, Apr 29, 2015 at 12:45PM, Yakov Zhdanov wrote: Cos, Does cli works on your local machine? Can you check if our JIRA allows remote API calls - Go to Administration - General Configuration and ensure Accept remote API calls in ON? Sergey tried it locally and it just hangs. --Yakov 2015-04-28 20:30 GMT+03:00 Konstantin Boudnik c...@apache.org: Hi Yakov. With jira-cli 3.9 one doesn't need to install anything on the server side. The older version of the tools work with JIRA backend. The newer version (not produced by Atlassian anymore) requires some additional stuff to be set. I will take a look at the agents' configuration later in the day and will get back to you here. Thanks, Cos On Tue, Apr 28, 2015 at 01:40PM, Yakov Zhdanov wrote: Cos, We still have problem while applying patch on TC. Attachments and comments cannot be fetched from Jira when using jira-cli on current agents. Can you please make sure that server side of jira-cli is properly installed? Do you know any other way to fetch that? --Yakov 2015-04-01 6:23 GMT+03:00 Konstantin Boudnik c...@apache.org: oops s/not/now/g Cos On Tue, Mar 31, 2015 at 06:58PM, Dmitriy Setrakyan wrote: On Tue, Mar 31, 2015 at 6:54 PM, Konstantin Boudnik c...@apache.org wrote: Thanks - that's great: not I'd be able to finish up the commenting part of the patch validation! Cos, I think some meaning was lost due to typos. Do you mean that you will be able to finish it or will not? Cos On Wed, Apr 01, 2015 at 12:00AM, Sergey Bachinskiy wrote: A A Hello Konstantin. A A I've installed lira-cli on all agents (7) - path of cli is A A /opt/jira-cli-3.9.0 A A On Wed, Mar 25, 2015 at 10:16 PM, Konstantin Boudnik c...@apache.org A A wrote:
Re: Choosing helper C++ libraries for interop.
Brane, I do not know in advance what exactly will be needed there, but it is _very_ likley that we will need thread-locals, atomics (both CAS and increments/decrements), java-like volatiles (i.e. membars), cirical sections, read-write locks and concurrent dictionaries. On Wed, May 20, 2015 at 12:27 PM, Branko Čibej br...@apache.org wrote: On 20.05.2015 09:40, Vladimir Ozerov wrote: This is not about resulting size of our lib. Moreover, we will not statically link it to Ignite because in this case users will have troubles when using both Boost and Ignite simultaneously. The problem is that if we use Boost, we will force users to have it on their machines during both build-time and runtime. And Boost is known to have dready dependencies between their modules. So if we use only concurrency module it might lead to transitive dependencies to lots other ones. Using any part of Boost also increases compile times dramatically because if its inter-module dependencies and its heavy usage of template programming. The first step is to design an API, before deciding on a helper library, which you may not even need. Talking about Boost or TBB or whatnot before you even know what kind of features you need to implement your API is, to put it mildly, just crazy. Real Programmers do not download 11 jars to use one external method ... -- Brane
Re: Choosing helper C++ libraries for interop.
On 20.05.2015 09:40, Vladimir Ozerov wrote: This is not about resulting size of our lib. Moreover, we will not statically link it to Ignite because in this case users will have troubles when using both Boost and Ignite simultaneously. The problem is that if we use Boost, we will force users to have it on their machines during both build-time and runtime. And Boost is known to have dready dependencies between their modules. So if we use only concurrency module it might lead to transitive dependencies to lots other ones. Using any part of Boost also increases compile times dramatically because if its inter-module dependencies and its heavy usage of template programming. The first step is to design an API, before deciding on a helper library, which you may not even need. Talking about Boost or TBB or whatnot before you even know what kind of features you need to implement your API is, to put it mildly, just crazy. Real Programmers do not download 11 jars to use one external method ... -- Brane
Re: Choosing C++ version for interop.
Brane, Thanks for clarifications, I mistakenly thought that smart pointers were introduced only in C++11. If they are already in C++03 of course we should take advantage of them. On Wed, May 20, 2015 at 12:08 PM, Branko Čibej br...@apache.org wrote: On 20.05.2015 09:47, Vladimir Ozerov wrote: I do not think we will sacrifice anything. C++11 has lots new features such as smart pointers and lamdas, but I do not see where we can use them on our public API. I would definitely recommend using C++03 (or C++98; the only differences are in the standard library). I would also very strongly recommend not depending on Boost unless it's absolutely unavoidable: Boost is lovely if you need it, but a huge albatross around the neck if you don't. C++03 is C++98+TR1 and does have both std::shared_ptr and std::weak_ptr whereas C++98 does not. Both have smart pointers (std:auto_ptr is a smart pointer). Note that C++98/03 is not completely source-compatible with C++11. You have to be very aware of that. For example: #define X world HelloX; is valid C++98 (and valid C as well), but not valid C++11 where the X is interpreted as a custom string suffix. So in order to maintain forward compatibility, you have to write Hello X; instead. This can be extremely painful to do in legacy code. For example, both Hazelcast and GigaSpaces has the following API for cache GET: boost::shared_ptrMyVal val = cacheMyKey, MyVal.get(); Ahem. This is not valid C++. Boost contributed smart poitners to C++11 To C++03. and we can implement it as follows now: std::shared_ptrMyVal val = cacheMyKey, MyVal.get(); I.e., with pure C++11 and no dependency on Boost. But in my opinion returning smart pointer from cache GET doesn't add any value comparing to returning unmanaged pointer, which user can wrap into smart pointer later if he really needs it: MyVal* val = cacheMyKey, MyVal.get(); And this is a memory leak. You can't just wrap a raw pointer in a shared pointer and go happily coding, expecting that you've got your memory problems solved. Let's say you do this: std::shared_ptrMyVal smartval(val); * When smartval goes out of scope, it deletes the value, making the reference inside the cache invalid. * When the value is ejected from the cache, smartval's pointer becomes invalid. Either return by value, or return a smart pointer: a constant shared_ptr if you're returning references to objects in the cache, or either auto_ptr or shared_ptr if you're returning copies allocated on the heap. Anything else is an accident waiting to happen. I think having less dependencies and greater backward compatibility outweight features like this. Having working code outweighs having more dependencies any day. And I'm already extremely happy that I won't have to review, fix or use that C++ code. :) -- Brane
Re: Choosing C++ version for interop.
On 20.05.2015 09:47, Vladimir Ozerov wrote: I do not think we will sacrifice anything. C++11 has lots new features such as smart pointers and lamdas, but I do not see where we can use them on our public API. I would definitely recommend using C++03 (or C++98; the only differences are in the standard library). I would also very strongly recommend not depending on Boost unless it's absolutely unavoidable: Boost is lovely if you need it, but a huge albatross around the neck if you don't. C++03 is C++98+TR1 and does have both std::shared_ptr and std::weak_ptr whereas C++98 does not. Both have smart pointers (std:auto_ptr is a smart pointer). Note that C++98/03 is not completely source-compatible with C++11. You have to be very aware of that. For example: #define X world HelloX; is valid C++98 (and valid C as well), but not valid C++11 where the X is interpreted as a custom string suffix. So in order to maintain forward compatibility, you have to write Hello X; instead. This can be extremely painful to do in legacy code. For example, both Hazelcast and GigaSpaces has the following API for cache GET: boost::shared_ptrMyVal val = cacheMyKey, MyVal.get(); Ahem. This is not valid C++. Boost contributed smart poitners to C++11 To C++03. and we can implement it as follows now: std::shared_ptrMyVal val = cacheMyKey, MyVal.get(); I.e., with pure C++11 and no dependency on Boost. But in my opinion returning smart pointer from cache GET doesn't add any value comparing to returning unmanaged pointer, which user can wrap into smart pointer later if he really needs it: MyVal* val = cacheMyKey, MyVal.get(); And this is a memory leak. You can't just wrap a raw pointer in a shared pointer and go happily coding, expecting that you've got your memory problems solved. Let's say you do this: std::shared_ptrMyVal smartval(val); * When smartval goes out of scope, it deletes the value, making the reference inside the cache invalid. * When the value is ejected from the cache, smartval's pointer becomes invalid. Either return by value, or return a smart pointer: a constant shared_ptr if you're returning references to objects in the cache, or either auto_ptr or shared_ptr if you're returning copies allocated on the heap. Anything else is an accident waiting to happen. I think having less dependencies and greater backward compatibility outweight features like this. Having working code outweighs having more dependencies any day. And I'm already extremely happy that I won't have to review, fix or use that C++ code. :) -- Brane
Re: Choosing C++ version for interop.
I do not think we will sacrifice anything. C++11 has lots new features such as smart pointers and lamdas, but I do not see where we can use them on our public API. For example, both Hazelcast and GigaSpaces has the following API for cache GET: boost::shared_ptrMyVal val = cacheMyKey, MyVal.get(); Boost contributed smart poitners to C++11 and we can implement it as follows now: std::shared_ptrMyVal val = cacheMyKey, MyVal.get(); I.e., with pure C++11 and no dependency on Boost. But in my opinion returning smart pointer from cache GET doesn't add any value comparing to returning unmanaged pointer, which user can wrap into smart pointer later if he really needs it: MyVal* val = cacheMyKey, MyVal.get(); I think having less dependencies and greater backward compatibility outweight features like this. On Wed, May 20, 2015 at 10:28 AM, Dmitriy Setrakyan dsetrak...@apache.org wrote: On Wed, May 20, 2015 at 12:01 AM, Vladimir Ozerov voze...@gridgain.com wrote: C++11 users can use C++03 projects, but not vice-versa. Are we sacrificing any features? (sorry, my C++ knowledge is limited). On Wed, May 20, 2015 at 9:52 AM, Dmitriy Setrakyan dsetrak...@apache.org wrote: On Tue, May 19, 2015 at 11:27 PM, Vladimir Ozerov voze...@gridgain.com wrote: Igniters, We need to decide which C++ version to use in interop. Currently wide developer community is in progress of adopting C++11. But if we choose it, users might have problems if their CPP projects using older C++ revisions which are still very common. I think we should stick to C++03 revision for now. Thoughts? If we stick to this version, what are the consequences for users who run C++ 11? Vladimir.
IgniteLogger.isQuiet() inconsistency
Hi, Igniters,
In process of investigation of a user request Disable ignite console logs
(
http://apache-ignite-users.70518.x6.nabble.com/Disable-ignite-console-logs-td310.html#a330),
I've found inconsistency at implementations of IgniteLogger.isQuiet():
- Javadoc of the method says:
/**
* Tests whether {@code info} and {@code debug} levels are turned off.
*
* @return Whether {@code info} and {@code debug} levels are turned off.
*/
- IgniteJclLogger.isQuiet() implementation corresponds to javadoc.
- isQuiet() implementations for Log4JLogger and JavaLogger don't correspond
to javadoc and quite option related to IGNITE_QUITE system variable.
For me, the implementation of Log4JLogger is better and we should change
javadoc and change implementation of IgniteJclLogger accordingly. I've
filed a bug on it: https://issues.apache.org/jira/browse/IGNITE-923.
Any objections?
-- Artem --
Re: Choosing helper C++ libraries for interop.
Brane, the API has already been designed. In the best case all functionality available in Java should be available in non-Java stuff (if there are no technology limitations). I would not care about compile time - Boost increases it, of course, but does not make compilation infinite. Functionality, stability and developer convenience seem to be more important. GridGain had its CPP stuff using Boost with ~4-5 min compilation on rather weak machine. However, given that client will be completely reapproached and should be less complex I would think whether we need any third party library at all. --Yakov 2015-05-20 12:27 GMT+03:00 Branko Čibej br...@apache.org: On 20.05.2015 09:40, Vladimir Ozerov wrote: This is not about resulting size of our lib. Moreover, we will not statically link it to Ignite because in this case users will have troubles when using both Boost and Ignite simultaneously. The problem is that if we use Boost, we will force users to have it on their machines during both build-time and runtime. And Boost is known to have dready dependencies between their modules. So if we use only concurrency module it might lead to transitive dependencies to lots other ones. Using any part of Boost also increases compile times dramatically because if its inter-module dependencies and its heavy usage of template programming. The first step is to design an API, before deciding on a helper library, which you may not even need. Talking about Boost or TBB or whatnot before you even know what kind of features you need to implement your API is, to put it mildly, just crazy. Real Programmers do not download 11 jars to use one external method ... -- Brane
Re: Choosing helper C++ libraries for interop.
There is one thing you could do, depending on which parts of Boost you need. Boost has a tool to extract only the headers you actually need and puts the extracted declarations into a custom namespace. If your dependencies are header-only, you can include those bits in the Ignite sources. That way, users won't have to install Boost, and it avoids version mismatch and DLL hell. -- Brane On 20.05.2015 15:53, Yakov Zhdanov wrote: Brane, the API has already been designed. In the best case all functionality available in Java should be available in non-Java stuff (if there are no technology limitations). I would not care about compile time - Boost increases it, of course, but does not make compilation infinite. Functionality, stability and developer convenience seem to be more important. GridGain had its CPP stuff using Boost with ~4-5 min compilation on rather weak machine. However, given that client will be completely reapproached and should be less complex I would think whether we need any third party library at all. --Yakov 2015-05-20 12:27 GMT+03:00 Branko Čibej br...@apache.org: On 20.05.2015 09:40, Vladimir Ozerov wrote: This is not about resulting size of our lib. Moreover, we will not statically link it to Ignite because in this case users will have troubles when using both Boost and Ignite simultaneously. The problem is that if we use Boost, we will force users to have it on their machines during both build-time and runtime. And Boost is known to have dready dependencies between their modules. So if we use only concurrency module it might lead to transitive dependencies to lots other ones. Using any part of Boost also increases compile times dramatically because if its inter-module dependencies and its heavy usage of template programming. The first step is to design an API, before deciding on a helper library, which you may not even need. Talking about Boost or TBB or whatnot before you even know what kind of features you need to implement your API is, to put it mildly, just crazy. Real Programmers do not download 11 jars to use one external method ... -- Brane
Re: Ignite on Zeppelin (ZEPPELIN-63)
On Wed, May 20, 2015 at 3:56 AM, moon soo Lee m...@apache.org wrote: Hi, Really appreciate for driving ignite-zeppelin integration. If it is okay, i'd love to spend this week for prototyping interpreter for ignite. Thanks Moon, sounds good! Please let us know if you have any questions setting up or configuring Ignite. You can post them to the Ignite dev list. Also, if you need any help with coding along the way, we will be glad to help you complete the coding or testing as well. Thanks, moon On 2015년 5월 20일 (수) at 오후 4:03 Dmitriy Setrakyan dsetrak...@apache.org wrote: On Tue, May 19, 2015 at 10:44 PM, Corneau Damien cornead...@apache.org wrote: I remember some discussions about naming of JDBC based interpreters, and also some JDBC template interpreter (to use as base). I know some of those discussions were raised in your issue. Except for that, I remember that moon wanted to help on that issue, if he is too busy, there is of course no problem with Ignite community making an interpreter, we welcome contributions :) I really think it will make a great demo at IMC conference in June, so I would prefer to get it done. To the least, we can add the interpreter, and then figure out what to call it outside of this ticket. Let us see if there are any takers within the Ignite community to help with the implementation. On Wed, May 20, 2015 at 1:40 AM, Dmitriy Setrakyan dsetrak...@apache.org wrote: Hi, I want to raise question on Ignite JDBC-based interpreter on top of Zeppelin. As I mentioned before, we would like to get that integration before end of May, so we can present it on the IMC summit coming up in June. The ticket has been filed, but there was little activity on it, given that everyone is probably busy. Would you be interested if someone from the Ignite community picks it up and implements it? Here is the link to the ticket: https://issues.apache.org/jira/browse/ZEPPELIN-63 D.
[VOTE] Apache Ignite 1.1.0 release (RC7)
Guys, We have uploaded release candidate to https://dist.apache.org/repos/dist/dev/incubator/ignite/1.1.0-rc7/ Tag name is ignite-1.1.0-incubating-rc7 RC7 changes: Fixed unexpected LICENSE, NOTICE and DEPENDENCIES files in sources zip. Fixed LICENSE, NOTICE files content inside ignite-core jar. Binaries names now ends with -bin. Aggregate project and all its artifacts names contains apache prefix. And many more changes which are described in devnotes (link below). DEVNOTES https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/ignite-1.1.0-incubating-rc7 RELEASENOTES https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/ignite-1.1.0-incubating-rc7 Please start voting. +1 - to accept Apache Ignite (incubating) 1.1.0 0 - don't care either way -1 - DO NOT accept Apache Ignite (incubating) 1.1.0 (explain why) This vote will go for 72 hours. --Yakov
Re: Fwd: automatic patch validation on TC
There's user ignite-ci, that I created a while ago, but it isn't mandatory to use it of course ;) On Thu, May 21, 2015 at 12:23AM, Artiom Shutak wrote: I've created new Jira user without granting him some additional privileges. The user cannot move jira status, but he can add any attachment under this user. I see at least one bad scenario: hacker can just monitor for new Patch available tickets and attach a bad patch. As a result, the test builds will run with bad patch. A hacker can not attach anything unless he has contributor's permissions. I think, for example, we should approve to attach files with patch extensions for contributors only (Somebody knows can we do that?), or just manually run all test builds for attached to TC file or link on file. I am not sure what does it solve? Isn't that enough to impose limits on who can attach/change JIRA state? Cos Thoughts? -- Artem -- On Wed, May 20, 2015 at 4:26 PM, Yakov Zhdanov yzhda...@gridgain.com wrote: I still insist that this should be implemented with great care. Cos, can you please provide information on which projects used same approach? Don't we trust our contributors? Well, you never know how they store the password and how strong it is. if TC agents aren't running as privileged user - and they shouldn't be - malicious code won't do any harm to the system. Ignite tests should be able to do a lot of operations - establish network connections, accept incoming connections, start processes and access file system. In order to address possible issues we need to: 1. limit the tests scenarios launched on patch attach. 2. backup TC workers state once a day and store several days history to quickly restore the state. -- Yakov Zhdanov, Director RD *GridGain Systems* www.gridgain.com 2015-05-19 20:53 GMT+03:00 Konstantin Boudnik c...@apache.org: Here's two reasons why current approach is secure enough (and in fact has been used for some time on Apache build infrastructure): - only project contributors can manipulate JIRA: attaching, changing state, etc. Don't we trust our contributors? - if TC agents aren't running as privileged user - and they shouldn't be - malicious code won't do any harm to the system. Thoughts? Cos On Tue, May 19, 2015 at 04:47PM, Yakov Zhdanov wrote: Guys, It seems we need to stop any activity in this direction. I have just realized that automatic patch validation (at least in its form we agreed on) opens a huge security hole - anyone who attaches a patch to JIRA can execute literally any code (!) on our public TC - java/bash/binary/built-in OS/etc. Should I continue on what this can lead to? I think no. So, the only acceptable way is to assign committer to review a patch manually and then submit it to TC. Process in my view should be the following: 1. Contributor finishes with the task and attaches a patch to JIRA issue. 2. Committer picks up the issue and reviews the changes. 3. If changes are OK, committer submits them to TC in a separate branch. 4. After TC passes committer merges the changes to the target sprint branch. 5. JIRA issue gets closed. Thoughts? --Yakov 2015-05-05 23:31 GMT+03:00 Konstantin Boudnik c...@apache.org: Sergey and I had a good Skype call and everything seems to be resolved. The installed jira-cli tools work just fine http://bit.ly/1c2qmeH Attachments and comments do not need to be fetched using jira-cli. The proposed workflow for the automatic patching is explained at the bottom of dev-tools/src/main/groovy/jiraslurp.groovy please let me know if there are any questions about it. Sergey will see to make sure that we have parameterized builds, which will be triggered from the groovy script above. In fact, that is the last thing that is blocking the completion of this task. Looks like our off-line conversation with him helped to get the ball rolling! Cos On Wed, Apr 29, 2015 at 12:45PM, Yakov Zhdanov wrote: Cos, Does cli works on your local machine? Can you check if our JIRA allows remote API calls - Go to Administration - General Configuration and ensure Accept remote API calls in ON? Sergey tried it locally and it just hangs. --Yakov 2015-04-28 20:30 GMT+03:00 Konstantin Boudnik c...@apache.org: Hi Yakov. With jira-cli 3.9 one doesn't need to install anything on the server side. The older version of the tools work with JIRA backend. The newer version (not produced by Atlassian anymore) requires some additional stuff to be set. I will take a look at the agents' configuration later in
Re: Ignite on Zeppelin (ZEPPELIN-63)
Hi Moon! as mentor on both projects but more as as just somebody who's really curious to see this happen I'd be really excited to help with prototyping wrt. testing/etc. Please share your work ASAP. I'm so anxious to get my hands on it! Thanks, Roman. On Wed, May 20, 2015 at 3:56 AM, moon soo Lee m...@apache.org wrote: Hi, Really appreciate for driving ignite-zeppelin integration. If it is okay, i'd love to spend this week for prototyping interpreter fo= r ignite. Thanks, moon On 2015=EB=85=84 5=EC=9B=94 20=EC=9D=BC (=EC=88=98) at =EC=98=A4=ED=9B=84= 4:03 Dmitriy Setrakyan dsetrak...@apache.org wrote: On Tue, May 19, 2015 at 10:44 PM, Corneau Damien cornead...@apache.org wrote: I remember some discussions about naming of JDBC based interpreters, a= nd also some JDBC template interpreter (to use as base). I know some of those discussions were raised in your issue. Except for that, I remember that moon wanted to help on that issue, if= he is too busy, there is of course no problem with Ignite community making an interpreter, we welcome contributions :) I really think it will make a great demo at IMC conference in June, so I would prefer to get it done. To the least, we can add the interpreter, a= nd then figure out what to call it outside of this ticket. Let us see if th= ere are any takers within the Ignite community to help with the implementati= on. On Wed, May 20, 2015 at 1:40 AM, Dmitriy Setrakyan dsetrak...@apache.org wrote: Hi, I want to raise question on Ignite JDBC-based interpreter on top of Zeppelin. As I mentioned before, we would like to get that integration before = end of May, so we can present it on the IMC summit coming up in June. The ticket has been filed, but there was little activity on it, give= n that everyone is probably busy. Would you be interested if someone from t= he Ignite community picks it up and implements it? Here is the link to the ticket: https://issues.apache.org/jira/browse/ZEPPELIN-63 D.
Re: Fwd: automatic patch validation on TC
On Wed, May 20, 2015 at 6:26 AM, Yakov Zhdanov yzhda...@gridgain.com wrote: I still insist that this should be implemented with great care. I tend to agree with Cos here. Let's implement this feature. If we get some malicious contributor attaching bad patches, we will catch it very quickly and remove him/her from Jira. All it takes to catch something like this is a normal patch review by a committer, which is part of Ignite standard development process. Cos, can you please provide information on which projects used same approach? Don't we trust our contributors? Well, you never know how they store the password and how strong it is. Again, don't think it is an issue. if TC agents aren't running as privileged user - and they shouldn't be - malicious code won't do any harm to the system. Ignite tests should be able to do a lot of operations - establish network connections, accept incoming connections, start processes and access file system. In order to address possible issues we need to: 1. limit the tests scenarios launched on patch attach. 2. backup TC workers state once a day and store several days history to quickly restore the state. And again, if something bad happens, we can deal with it in a normal fashion. I personally think that we are worrying about something that will never happen. My preference is to get this feature out as soon as possible so our contributors have a normal path to execute builds on TeamCity. D.
Re: Ignite on Zeppelin (ZEPPELIN-63)
Hi, I'll be happy to help with Ignite-Zeppelin integration. It would be great if you assign the ticket to me. On Wed, May 20, 2015 at 1:56 PM, moon soo Lee m...@apache.org wrote: Hi, Really appreciate for driving ignite-zeppelin integration. If it is okay, i'd love to spend this week for prototyping interpreter for ignite. Thanks, moon On 2015년 5월 20일 (수) at 오후 4:03 Dmitriy Setrakyan dsetrak...@apache.org wrote: On Tue, May 19, 2015 at 10:44 PM, Corneau Damien cornead...@apache.org wrote: I remember some discussions about naming of JDBC based interpreters, and also some JDBC template interpreter (to use as base). I know some of those discussions were raised in your issue. Except for that, I remember that moon wanted to help on that issue, if he is too busy, there is of course no problem with Ignite community making an interpreter, we welcome contributions :) I really think it will make a great demo at IMC conference in June, so I would prefer to get it done. To the least, we can add the interpreter, and then figure out what to call it outside of this ticket. Let us see if there are any takers within the Ignite community to help with the implementation. On Wed, May 20, 2015 at 1:40 AM, Dmitriy Setrakyan dsetrak...@apache.org wrote: Hi, I want to raise question on Ignite JDBC-based interpreter on top of Zeppelin. As I mentioned before, we would like to get that integration before end of May, so we can present it on the IMC summit coming up in June. The ticket has been filed, but there was little activity on it, given that everyone is probably busy. Would you be interested if someone from the Ignite community picks it up and implements it? Here is the link to the ticket: https://issues.apache.org/jira/browse/ZEPPELIN-63 D. -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
[jira] [Created] (IGNITE-929) IgniteCache.close should not delete the cache from the cluster
Alexey Goncharuk created IGNITE-929: --- Summary: IgniteCache.close should not delete the cache from the cluster Key: IGNITE-929 URL: https://issues.apache.org/jira/browse/IGNITE-929 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk Fix For: sprint-5 Need to introduce IgniteCache.destroy() method instead. close() method should be implemented differently for LOCAL and distributed caches * For LOCAL cache close() should be equivalent to destroyCache() * For distributed caches close(), if called on clients, should close client cache, but not destroy cache on the whole cluster. * For distributed caches close(), if called on a server node, should be a no-op TCK should run with LOCAL cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Indexing primitive types
Igniters (especially Sergi), What happens if I use Java primitives like Doubles as values? Are they indexed? I just created a simple example which loads some data and executes this query: 'select max(_val) from Double'. Indexes are not created and the speed of the query is the same as the speed of full cache iteration. I can't find any configuration properties to tweak this behavior. Also I see this in GridQueryProcessor.processAnnotationsInClass() method: if (U.isJdk(cls)) return; So it looks like all JDK classes are simply ignored. Is this on purpose? I think primitives should be indexed by default if they are provided in CacheConfiguration.setIndexedTypes(). -- Val
Re: Fwd: automatic patch validation on TC
On 20.05.2015 21:36, Dmitriy Setrakyan wrote: On Wed, May 20, 2015 at 6:26 AM, Yakov Zhdanov yzhda...@gridgain.com wrote: I still insist that this should be implemented with great care. I tend to agree with Cos here. Let's implement this feature. If we get some malicious contributor attaching bad patches, we will catch it very quickly and remove him/her from Jira. All it takes to catch something like this is a normal patch review by a committer, which is part of Ignite standard development process. Exactly. This is one of the reasons why we make our repository, Jira, commit notifications etc. public. Any number of projects have automatic patch validation, and I've yet to hear about a single attack or exploit that got in through that channel. -- Brane
Re: [CLOSED][VOTE] Apache Ignite 1.1.0 release (RC5)
Please use the subject tag [RESULT][VOTE] for votes that are complete, regardless of the vote result; and [CANCELLED][VOTE] for votes that are cancelled for any reason. Nobody uses [CLOSED][VOTE] anywhere. -- Brane
clear() method and near cache
Igniters, Current implementation of clear() method doesn't clear entries if there are near readers for them. This makes this method ultimately unusable if near cache is configured (behavior is unpredictable and counterintuitive). At the same time, the purpose of the method is to invalidate the whole cache and I assume that in most cases this is done in exclusive mode (there is no sense to execute it concurrently with transactions, for example). So why don't we clear all DHT and near caches in this method? (Of course, it should be properly documented) Thoughts? -- Val
Read-only mode for transactional cache
Igniters, As we all know, transactional cache updates persistence store from a client node, while loads are still done on primary node. But it's not always possible to have a database connection on client. There is a workaround - send a closure to server node and start a transaction there. You can do the same with gets, but what if you want to utilize near cache? Now it's achievable only by disabling consistency check and removing store from client. The use case looks more than valid for me, so I suggest to improve usability here and add a special read-only mode for transactional cache. In this mode updates are not allowed, but we do not create the store and we fix consistency check appropriately. And in addition: currently if we disable consistency check on one of the nodes, other nodes still check it - this looks incorrect. I think it should be excluded everywhere. Thoughts? -- Val
[jira] [Created] (IGNITE-928) Array out of bounds in IgniteUtils.filterReachable
Mario Ivankovits created IGNITE-928:
---
Summary: Array out of bounds in IgniteUtils.filterReachable
Key: IGNITE-928
URL: https://issues.apache.org/jira/browse/IGNITE-928
Project: Ignite
Issue Type: Bug
Components: general
Environment: Ignite 1.0.5
Reporter: Mario Ivankovits
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
Regards,
Mario
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
