[jira] [Created] (IGNITE-3253) Web console: adding a new cache from Model screnn doesn't work
Pavel Konstantinov created IGNITE-3253: -- Summary: Web console: adding a new cache from Model screnn doesn't work Key: IGNITE-3253 URL: https://issues.apache.org/jira/browse/IGNITE-3253 Project: Ignite Issue Type: Bug Components: UI Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov # create several caches # open Model screen and add a new (first) model, do not save # click on Add link on Caches label - the first of existing cache will be opened instead of creation a new cache item. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3252) Web console: add validator to Package field in Import metadata dialog
Pavel Konstantinov created IGNITE-3252: -- Summary: Web console: add validator to Package field in Import metadata dialog Key: IGNITE-3252 URL: https://issues.apache.org/jira/browse/IGNITE-3252 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov Priority: Minor Currently this field shows error message in case of invalid value, but the field has no red frame and triangle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3251) Implement field validator "positive power of 2"
Vasiliy Sisko created IGNITE-3251: - Summary: Implement field validator "positive power of 2" Key: IGNITE-3251 URL: https://issues.apache.org/jira/browse/IGNITE-3251 Project: Ignite Issue Type: Sub-task Components: wizards Affects Versions: 1.7 Reporter: Vasiliy Sisko Priority: Minor Validation with showing of red frame and triangle. F.e. Cluster - Swap - "Read stripe size" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3250) Web console: incorrect Undo behavior in corner case
Pavel Konstantinov created IGNITE-3250: -- Summary: Web console: incorrect Undo behavior in corner case Key: IGNITE-3250 URL: https://issues.apache.org/jira/browse/IGNITE-3250 Project: Ignite Issue Type: Bug Components: UI Reporter: Pavel Konstantinov Assignee: Dmitriyff Priority: Minor # open any section with checkboxes # enable any checkbox - Undo buttons in the section and on the top level are become enabled # disable the same checkbox - Undo still enabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3249) Web console: unexpected 'Unsaved changes'
Pavel Konstantinov created IGNITE-3249: -- Summary: Web console: unexpected 'Unsaved changes' Key: IGNITE-3249 URL: https://issues.apache.org/jira/browse/IGNITE-3249 Project: Ignite Issue Type: Bug Components: UI Reporter: Pavel Konstantinov Assignee: Dmitriyff Priority: Minor # remove all clusters # create new cluster # save # change Discovery to Static, DON"T save # remove # add new cluster - unexpected 'unsaved changes' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: API for asynchronous execution.
Hello, I'd like to suggest making the point about the callback execution ordering more prominent in the Ignite documentation and/or the javadocs of @IgniteAsyncCallback. I think the documentation should emphasize the fact that the events for the same keys are guaranteed to be delivered in-order, despite the asynchronous execution of the callback. Without such guarantee, the applicability of the async callback feature would be very limited. Thanks Andrey > Date: Tue, 29 Mar 2016 19:22:50 +0300 > Subject: Re: API for asynchronous execution. > From: ntikho...@gridgain.com > To: dev@ignite.apache.org > > Vova, > > 1) As far as I remember, we enforce ordering of updates for the same key, > > right? If yes, then stalled filter invoke for update #1 will stall all > > further updates. > > > > Invocation of filter will be implemented in thread-partition style for > supporting ordering of updates. > > > > 2) Listener notification is final stage of update. To the contrast remote > > filter is intermediate stage. It means that you will have to maintain some > > kind of beckpressure control for it's async invocations. If there are too > > much concurrent invokes, you will eventually block system pool waiting for > > some invokes to finish. Ultimately it means that user cannot execute any > > other cache operations inside the filter irrespecitve of whether it is > > synchronous or async. > > Having these limitations in place - what is the reason to have async remote > > filter? > > From my point of view, neither remote filter, nor invoke are valid use > > cases for async execution. > > > > Main reason async execution to allow users use cache operations in remote > filter.
Re: Docker image for Ignite 1.6.0 release pull request
Updated Dockerfile/PR - reduce the generated Docker image size from 1.061GB to 885MB. -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Docker-image-for-Ignite-1-6-0-release-pull-request-tp9276p9282.html Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
Not supported -np (no pause) parameter for Ignite 1.6.0 release
Tried to create an issue myself from Ignite JIRA, looks like I don't have
enough permissions to do it.
So post it here:
/apache-ignite-fabric-1.6.0-bin/bin$ ./ignite.sh -np
Invalid arguments: -np
Usage:
./ignite.sh [?]|[path {-v}{-np}]|[-i]
Where:
?, /help, -help, - show this message.
-v - verbose mode (quiet by default).
-np - no pause on exit (pause by default)
-nojmx - disable JMX monitoring (enabled by default)
-i - interactive mode (choose configuration file from
list).
path- path to Spring XML configuration file.
Path can be absolute or relative to IGNITE_HOME.
Spring file should contain one bean definition of Java type
'org.apache.ignite.configuration.IgniteConfiguration'. Note that bean will
be
fetched by the type and its ID is not used./
So, what if I don't have a Spring configuration file to provide, but still
want to use either -np or -v?
--
View this message in context:
http://apache-ignite-developers.2346864.n4.nabble.com/Not-supported-np-no-pause-parameter-for-Ignite-1-6-0-release-tp9281.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
[jira] [Created] (IGNITE-3248) IGFS: Improve dual stream operations performance.
Vladimir Ozerov created IGNITE-3248: --- Summary: IGFS: Improve dual stream operations performance. Key: IGNITE-3248 URL: https://issues.apache.org/jira/browse/IGNITE-3248 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.6 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.7 We need to minimize amount of network trips for stream operations in DUAL mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3247) IGFS: Optimize non-stream client operations.
Vladimir Ozerov created IGNITE-3247: --- Summary: IGFS: Optimize non-stream client operations. Key: IGNITE-3247 URL: https://issues.apache.org/jira/browse/IGNITE-3247 Project: Ignite Issue Type: Sub-task Components: IGFS Affects Versions: 1.6 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Priority: Critical Fix For: 1.7 It is necessary to optimize operations which do not involve any streaming: - summary() - setTimes() - affinity() - size() - exists() - update() - rename() - delete() - mkdris() - listPaths() - listFiles() - info() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3246) IGFS: Create infrastructure for remote client operations.
Vladimir Ozerov created IGNITE-3246: --- Summary: IGFS: Create infrastructure for remote client operations. Key: IGNITE-3246 URL: https://issues.apache.org/jira/browse/IGNITE-3246 Project: Ignite Issue Type: Sub-task Components: IGFS Affects Versions: 1.6 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.7 Need to create all infrastructure code to handle remote client IGFS operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3245) IGFS: Optimize performance for client nodes.
Vladimir Ozerov created IGNITE-3245: --- Summary: IGFS: Optimize performance for client nodes. Key: IGNITE-3245 URL: https://issues.apache.org/jira/browse/IGNITE-3245 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.6 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Priority: Critical Fix For: 1.7 *Problem* Ignite can work in two modes - server (default) and client. Both modes provide transparent cache API. IGFS heavily rely on cache operations and sometimes perform lots of them with assumption that metadata is located on the same node, so these operations are cheap and do not require any cross-node communication. But when user works with IGFS from client node, this code could be very inefficient because even single operation could cause many network round trips between a client and a server. *Solution* Provide special implementations of IGFS operations which will delegate the whole execution to the server, thus leaving only a single network round trip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Docker image for Ignite 1.6.0 release pull request
Hi, guys, what about the following https://github.com/apache/ignite/pull/757? Is already someone from DataGrid/Ignite working on official docker image for 1.6.0 release, or you can take a look into the pull request above I've submitted. -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Docker-image-for-Ignite-1-6-0-release-pull-request-tp9276.html Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
