[jira] [Created] (IGNITE-3893) void type is not part of 'primitiveMap' in IgniteUtils class , this is causing class not found exception for void.
Benakaraj K S created IGNITE-3893: - Summary: void type is not part of 'primitiveMap' in IgniteUtils class , this is causing class not found exception for void. Key: IGNITE-3893 URL: https://issues.apache.org/jira/browse/IGNITE-3893 Project: Ignite Issue Type: Bug Components: compute Affects Versions: 1.5.0.final Reporter: Benakaraj K S I am doing dynamic code generation inside IgniteCallable which i am broadcasting to all the nodes(this is to achieve Dynamic pojo support for IgniteCache) using bytebuddy , my dynamically generated pojo class has setter methods with return type void, I am getting ClassNotFoundException : void while generating Dynamic pojo, when i debugged i got to know that the problem(?) is that, void is not part of 'primitiveMap' in IgniteUtils class. Is there a reason for not having it in this MAP?. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3384) Docker container for Ignite Web Console
[ https://issues.apache.org/jira/browse/IGNITE-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-3384: --- Assignee: (was: Pavel Konstantinov) > Docker container for Ignite Web Console > > > Key: IGNITE-3384 > URL: https://issues.apache.org/jira/browse/IGNITE-3384 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Afanasiev > Fix For: 1.8 > > > In order to accelerate deployment and development of web console I want > create 2 docker containers: > 1. for build frontend SPA and provide static files, wich serve it by nginx > (name: web-console-frontend); > 2. for backend with nodejs and related dependencies (name: > web-console-backend). > And create docker compose file for simpler manangment with follow > configuration: > - mongo db container with external volume for persisting data; > - web-console-backend linked with mongo container and localy serve ports for > frontend; > - web-console-frontend expose 80/443 nginx port and translate all request to > web-console-backend, aslo serve SPA files. > Agent will be connect throught web-console-frontend container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3421) Add ability to configure maxIterCnt property in GridCacheQueryManager
[ https://issues.apache.org/jira/browse/IGNITE-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489058#comment-15489058 ] Roman Shtykh commented on IGNITE-3421: -- [~agura] Andrey, thanks a lot for reviewing! I have changed the names as you suggested. It may be a good idea to discuss it on dev list, but I don't think I can properly reason this question, since it looks to me like this is a property of a cache. What would be the reason to have it system-wide? > Add ability to configure maxIterCnt property in GridCacheQueryManager > - > > Key: IGNITE-3421 > URL: https://issues.apache.org/jira/browse/IGNITE-3421 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.6 >Reporter: Nikolay Tikhonov >Assignee: Roman Shtykh > Fix For: 1.8 > > > The number of open iterator limited by constant > GridCacheQueryManager#MAX_ITERATORS. Need to add ability to change the value. > Also need to correct error message (see GridCacheQueryManager#executeQuery). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3172) Ignite-Cassandra serializers
[ https://issues.apache.org/jira/browse/IGNITE-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-3172. > Ignite-Cassandra serializers > > > Key: IGNITE-3172 > URL: https://issues.apache.org/jira/browse/IGNITE-3172 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Igor Rudyak >Assignee: Igor Rudyak > Fix For: 1.8 > > > Ignite-Cassandra module should contain only "standard" serializer based on > Java serialization mechanism. > It should be a separate module in Ignite project for all other alternative > implementations of serializers (based on Kryo, providing compression, > encryption and etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3172) Ignite-Cassandra serializers
[ https://issues.apache.org/jira/browse/IGNITE-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489051#comment-15489051 ] ASF GitHub Bot commented on IGNITE-3172: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/956 > Ignite-Cassandra serializers > > > Key: IGNITE-3172 > URL: https://issues.apache.org/jira/browse/IGNITE-3172 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Igor Rudyak >Assignee: Igor Rudyak > Fix For: 1.8 > > > Ignite-Cassandra module should contain only "standard" serializer based on > Java serialization mechanism. > It should be a separate module in Ignite project for all other alternative > implementations of serializers (based on Kryo, providing compression, > encryption and etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3421) Add ability to configure maxIterCnt property in GridCacheQueryManager
[
https://issues.apache.org/jira/browse/IGNITE-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487693#comment-15487693
]
Andrey Gura edited comment on IGNITE-3421 at 9/14/16 1:06 AM:
--
[~roman_s]
Roman, I've reviewed your pull request. Looks good for me. But I think that
{{CacheConfiguration.getMaximumQueryIteratorCount()}} and
{{CacheConfiguration.setMaximumQueryIteratorCount()}} should be renamed to
{{CacheConfiguration.getMaxQueryIteratorsCount()}} and
{{CacheConfiguration.setMaxQueryIteratorsCount()}} for the sake of uniformity
with other methods' names in {{CacheConfiguration}} class (using {{Max}} word
and plural for {{Iterators}}).
Also I'm not sure that we should provide ability to configure maximum iterators
count per cache. May be one system property will be enough for this purposes.
What about discussion this question on dev list?
was (Author: agura):
[~roman_s]
Roman, I've reviewed your pull request. Looks good for me. But I think that
{{CacheConfiguration.getMaximumQueryIteratorCount()}} and
{{CacheConfiguration.setMaximumQueryIteratorCount()}} should be renamed to
{{CacheConfiguration.getMaxQueryIteratorsCount()}} and
{{CacheConfiguration.setMaxQueryIteratorsCount()}} for the sake of uniformity
with other methods' names in {{CacheConfiguration}} class (using {{Max}} word
and plural for {{Iterators}}).
> Add ability to configure maxIterCnt property in GridCacheQueryManager
> -
>
> Key: IGNITE-3421
> URL: https://issues.apache.org/jira/browse/IGNITE-3421
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
>Assignee: Roman Shtykh
> Fix For: 1.8
>
>
> The number of open iterator limited by constant
> GridCacheQueryManager#MAX_ITERATORS. Need to add ability to change the value.
> Also need to correct error message (see GridCacheQueryManager#executeQuery).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3892) BinaryWriterExImpl.doWriteClass is incorrect
Valentin Kulichenko created IGNITE-3892:
---
Summary: BinaryWriterExImpl.doWriteClass is incorrect
Key: IGNITE-3892
URL: https://issues.apache.org/jira/browse/IGNITE-3892
Project: Ignite
Issue Type: Bug
Components: binary
Affects Versions: 1.7
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.8
Here is the problematic code:
{code}
if (desc.registered())
out.unsafeWriteInt(desc.typeId());
else {
out.unsafeWriteInt(GridBinaryMarshaller.UNREGISTERED_TYPE_ID);
doWriteString(val.getClass().getName());
}
{code}
If class is not registered, {{val.getClass().getName()}} is written. But
{{val}} is already a {{Class}} instance, so it should be {{val.getName()}}.
Need to create a test and fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3807) IgniteSpiContext registers message listeners incorrectly
[
https://issues.apache.org/jira/browse/IGNITE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488060#comment-15488060
]
Saikat Maitra commented on IGNITE-3807:
---
[~vkulichenko]
Hi Valentin,
Thank you for reviewing the PR. I will update the PR as per review feedback.
Regards
Saikat
> IgniteSpiContext registers message listeners incorrectly
>
>
> Key: IGNITE-3807
> URL: https://issues.apache.org/jira/browse/IGNITE-3807
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
> Fix For: 1.8
>
>
> {{IgniteSpiContext}} implementation provided by {{GridManagerAdapter}} uses
> {{ctx.io().addMessageListener(..)}} method to register message listeners.
> This is incorrect, because this creates a listener for internal Ignite
> messages, not for user messages. Thus, when user tries to send a message on
> this topic, the listener is not invoked. To fix this,
> {{ctx.io().addUserMessageListener(..)}} method should be used instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches
[ https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487999#comment-15487999 ] Saikat Maitra commented on IGNITE-3303: --- [~avinogradov] Thank you Anton for reviewing the changes. 1. I will update the files to be compatible with JDK7 2. The test failed while processing large batch of events with Timeout exceptions. I added strict checking for each event for large batch with test timeout of 10 secs. I will validate further and try to reproduce it in local and Teamcity. 3. I have used static inner class for IgniteContext and passing igniteCfgFile as param. I am changing the implementation to avoid static inner class. 4. During testing I was facing error as not every event was consumed from IgniteSource when evtBuf was non-static. I will check it further if evtBuf can be replaced with non-static variable. 5. Yes, the ignite instance is not the cause of the exceptions. The Ignite instance used inside IgniteSource is the Singleton object. Regards Saikat > Apache Flink Integration - Flink source to run a continuous query against one > or multiple caches > > > Key: IGNITE-3303 > URL: https://issues.apache.org/jira/browse/IGNITE-3303 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Saikat Maitra >Assignee: Saikat Maitra > Attachments: testFlinkIgniteSourceWithLargeBatch.log > > > Apache Flink integration > +++ *Ignite as a bidirectional Connector* +++ > As a Flink source => run a continuous query against one or multiple > caches [4]. > Related discussion : > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3891) Enable writing hostname, rather than ipaddress for zookeeper discovery
John Watson created IGNITE-3891: --- Summary: Enable writing hostname, rather than ipaddress for zookeeper discovery Key: IGNITE-3891 URL: https://issues.apache.org/jira/browse/IGNITE-3891 Project: Ignite Issue Type: Improvement Components: ignite-zookeeper Affects Versions: 1.7 Environment: docker Reporter: John Watson We are using ignite in docker, with zookeeper discovery. We need to be able to use the hostname, rather than the ip address, since the container-visible ip address is not externally usable. We would like an option in the TcpDiscoveryZookeeperIpFinder to use the hostname, rather than ipaddress. This change would impact line 231, where currently the ip address is being written. We suggest adding an option to the class to use the hostname, rather than the ip address. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487958#comment-15487958
]
Nikolay Tikhonov commented on IGNITE-3164:
--
[~sboikov]
Yes, you are right. It's make sense send new value on originating node only
when {{get}} method is called.
> Add an option to send resulting value instead of entry processor in
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
> Labels: important
> Fix For: 1.8
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes.
> In transactional cache this can lead to inconsistent cache, because we invoke
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
> override current default behavior.
> We also need to update documentation, especially provide the explanation of
> EP behavior in atomic and transactional caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3471) Do not send previous value to client node for invoke() when possible
[
https://issues.apache.org/jira/browse/IGNITE-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487923#comment-15487923
]
Nikolay Tikhonov edited comment on IGNITE-3471 at 9/13/16 6:09 PM:
---
Implementing that entry processor is invoked only on owner nodes. In this case
new value will be kept on primary node and will be sent to originating node, if
get method was explicitly called.
was (Author: ntikhonov):
Implementing that entry processor is invoked only on owner nodes. In cases when
entry processor doesn't modify then an entry value will not be sent to
originating node.
> Do not send previous value to client node for invoke() when possible
>
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Tikhonov
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to
> near node and apply EntryProcessor locally to get a return value. This can
> induce a significant overhead when cache value is much larger than entry
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> cache.get(key); // This should actually get the current cache value from
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3471) Do not send previous value to client node for invoke() when possible
[
https://issues.apache.org/jira/browse/IGNITE-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487923#comment-15487923
]
Nikolay Tikhonov commented on IGNITE-3471:
--
Implementing that entry processor is invoked only on owner nodes. In cases when
entry processor doesn't modify then an entry value will not be sent to
originating node.
> Do not send previous value to client node for invoke() when possible
>
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Tikhonov
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to
> near node and apply EntryProcessor locally to get a return value. This can
> induce a significant overhead when cache value is much larger than entry
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> cache.get(key); // This should actually get the current cache value from
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3054) Rework client connection handling from thread-per-client to NIO model.
[ https://issues.apache.org/jira/browse/IGNITE-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487839#comment-15487839 ] Dmitry Karachentsev commented on IGNITE-3054: - * Fixed bugs that lead to ExecutionTimeout of the tests. * Now SSL works OK, but on Linux machine often receive exceptions on handshake, like: *"javax.net.ssl.SSLException: Received fatal alert: "* with random codes, or real reasons, but it looks like data mess on connection process. Exactly the same issue like [here|http://stackoverflow.com/questions/34671460/getting-various-sslexceptions-when-running-loadtest-on-an-ssl-enabled-url-call]. Trying to understand the nature of that error. > Rework client connection handling from thread-per-client to NIO model. > -- > > Key: IGNITE-3054 > URL: https://issues.apache.org/jira/browse/IGNITE-3054 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Dmitry Karachentsev > Fix For: 1.8 > > > Currently both servers and clients has the same operational model - > thread-per-connection. While being more or less fine for servers, this could > be a problem for clients when their total number is too high (e.g. 1000 or > even more). > We should rework client handling model and employ standard NIO technique: one > or several acceptor threads + thread pool to server requests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider
[ https://issues.apache.org/jira/browse/IGNITE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487746#comment-15487746 ] Pavel Tupitsyn commented on IGNITE-3199: .NET part reworked: 1) Extension ID support added. 2) Everything related to AspNet is moved out of the Core. Collection and session data classes are merged. > .NET: ASP.NET Session-State Store Provider > -- > > Key: IGNITE-3199 > URL: https://issues.apache.org/jira/browse/IGNITE-3199 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 1.8 > > > See https://msdn.microsoft.com/en-us/library/ms178587.aspx > Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3421) Add ability to configure maxIterCnt property in GridCacheQueryManager
[
https://issues.apache.org/jira/browse/IGNITE-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487693#comment-15487693
]
Andrey Gura commented on IGNITE-3421:
-
[~roman_s]
Roman, I've reviewed your pull request. Looks good for me. But I think that
{{CacheConfiguration.getMaximumQueryIteratorCount()}} and
{{CacheConfiguration.setMaximumQueryIteratorCount()}} should be renamed to
{{CacheConfiguration.getMaxQueryIteratorsCount()}} and
{{CacheConfiguration.setMaxQueryIteratorsCount()}} for the sake of uniformity
with other methods' names in {{CacheConfiguration}} class (using {{Max}} word
and plural for {{Iterators}}).
> Add ability to configure maxIterCnt property in GridCacheQueryManager
> -
>
> Key: IGNITE-3421
> URL: https://issues.apache.org/jira/browse/IGNITE-3421
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
>Assignee: Roman Shtykh
> Fix For: 1.8
>
>
> The number of open iterator limited by constant
> GridCacheQueryManager#MAX_ITERATORS. Need to add ability to change the value.
> Also need to correct error message (see GridCacheQueryManager#executeQuery).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3883) ODBC: Parameter binding does not work with PDO.
[ https://issues.apache.org/jira/browse/IGNITE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487694#comment-15487694 ] Igor Sapego commented on IGNITE-3883: - Ok, it seems, like PDO uses [data-at-execution dialog|https://msdn.microsoft.com/en-us/library/ms716238(v=vs.85).aspx] which is not currently supported by our ODBC driver. I'm going now try and implement it properly. > ODBC: Parameter binding does not work with PDO. > --- > > Key: IGNITE-3883 > URL: https://issues.apache.org/jira/browse/IGNITE-3883 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 1.7 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: odbc > Fix For: 1.8 > > > By some reason, parameter binding does not work with PDO. Investigate and fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3810) FileSwapSpaceSpi can hang when large value is written
[
https://issues.apache.org/jira/browse/IGNITE-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487507#comment-15487507
]
Valentin Kulichenko commented on IGNITE-3810:
-
Dmitriy, can we automatically increase the queue size in this case? This
definitely should not hang. At the very least we should throw an exception with
a proper message, but this is not good either because the fix will require full
cluster restart.
> FileSwapSpaceSpi can hang when large value is written
> -
>
> Key: IGNITE-3810
> URL: https://issues.apache.org/jira/browse/IGNITE-3810
> Project: Ignite
> Issue Type: Bug
> Components: swap
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Dmitriy Govorukhin
> Fix For: 1.8
>
> Attachments: SwapSpaceTest.java
>
>
> Test reproducing the issue is attached.
> Weirdly, the value of size {{1024 * 1024 - 48}} is successfully written, but
> when it is only one byte bigger, the swap space hangs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3621) Make GridCacheTtlManager singleton
[
https://issues.apache.org/jira/browse/IGNITE-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487491#comment-15487491
]
Andrey Martianov commented on IGNITE-3621:
--
[~ascherbakov], could you please reassign this issue to me (if you don't have
progress on it)
> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Alexei Scherbakov
> Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra
> thread. This can cause to extra hundreds of threads (redundant context
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept
> off-head. At least, this issue needs discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2539) NPE at RendezvousAffinityFunction
[ https://issues.apache.org/jira/browse/IGNITE-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487490#comment-15487490 ] Dmitriy Govorukhin commented on IGNITE-2539: [~sboikov] Please look my change, if you will try reproduce apply only commit that have test. > NPE at RendezvousAffinityFunction > - > > Key: IGNITE-2539 > URL: https://issues.apache.org/jira/browse/IGNITE-2539 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ershov >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 1.8 > > Attachments: ignite.log > > Original Estimate: 4h > Remaining Estimate: 4h > > RendezvousAffinityFunction#assignPartition throws NPE, probably due to > simultaneous topology change and cache stop. We should write a test and fix > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3890) IGFS: Flatten IgfsInputStream inheritance hierarchy.
[ https://issues.apache.org/jira/browse/IGNITE-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3890. --- > IGFS: Flatten IgfsInputStream inheritance hierarchy. > > > Key: IGNITE-3890 > URL: https://issues.apache.org/jira/browse/IGNITE-3890 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.7 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Minor > Fix For: 1.8 > > > It is too complex for now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1075) IgniteDataStreamer doesn't throw an exception if there are no data nodes
[
https://issues.apache.org/jira/browse/IGNITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak reassigned IGNITE-1075:
Assignee: Alexander Belyak
> IgniteDataStreamer doesn't throw an exception if there are no data nodes
>
>
> Key: IGNITE-1075
> URL: https://issues.apache.org/jira/browse/IGNITE-1075
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Alexander Belyak
>Priority: Critical
> Labels: Usability
>
> If you call {{addData}} method, but there are no data nodes, you will never
> know about it. Looks like it is returned in a future, but it's
> counterintuitive to call it on each operation just to check for exception.
> Probably we should print out these errors in logs as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487456#comment-15487456 ] Dmitriy Govorukhin commented on IGNITE-3727: [~sboikov] Solved all problems, please look my change. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance
[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487453#comment-15487453
]
Dmitriy Govorukhin commented on IGNITE-1678:
Hi [~sboikov], I corrected comments, move all code in one branch
(ignite-1678-2). Also added benchmark.
> IgniteAtomicSequence: make following reservations in advance
>
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 1.8
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3890) IGFS: Flatten IgfsInputStream inheritance hierarchy.
Vladimir Ozerov created IGNITE-3890: --- Summary: IGFS: Flatten IgfsInputStream inheritance hierarchy. Key: IGNITE-3890 URL: https://issues.apache.org/jira/browse/IGNITE-3890 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.7 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Priority: Minor Fix For: 1.8 It is too complex for now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3858) IGFS: Support direct PROXY mode invocation in methods: create / append
[ https://issues.apache.org/jira/browse/IGNITE-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3858. --- > IGFS: Support direct PROXY mode invocation in methods: create / append > -- > > Key: IGNITE-3858 > URL: https://issues.apache.org/jira/browse/IGNITE-3858 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Reporter: Taras Ledkov >Assignee: Taras Ledkov > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3376) IGFS: Allow direct PROXY mode invocations.
[ https://issues.apache.org/jira/browse/IGNITE-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487368#comment-15487368 ] Vladimir Ozerov commented on IGNITE-3376: - Outstanding issues: - open - create/append > IGFS: Allow direct PROXY mode invocations. > -- > > Key: IGNITE-3376 > URL: https://issues.apache.org/jira/browse/IGNITE-3376 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Critical > Labels: roadmap > > Currently we do not have special handling for PROXY mode. So we will either > hit AssertionError during dev, or will go to incorrect code path in > productions systems. > We need to fix that - PROXY mode should be handled correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3859) IGFS: Support direct PROXY mode invocation in method: open
[ https://issues.apache.org/jira/browse/IGNITE-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3859. --- > IGFS: Support direct PROXY mode invocation in method: open > -- > > Key: IGNITE-3859 > URL: https://issues.apache.org/jira/browse/IGNITE-3859 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Reporter: Taras Ledkov >Assignee: Taras Ledkov > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3889) Sql function class is required on client even if it is not used at runtime
Semen Boikov created IGNITE-3889: Summary: Sql function class is required on client even if it is not used at runtime Key: IGNITE-3889 URL: https://issues.apache.org/jira/browse/IGNITE-3889 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.7 Reporter: Semen Boikov Now ignite tries to load sql function classes on all nodes including clients at cache start up (CacheConfiguration.getSqlFunctionClasses). Need to investigate if it is possible to avoid cache start error, and fail with error only if function is really used on client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3860) Improve distributed SQL support.
[ https://issues.apache.org/jira/browse/IGNITE-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3860: Labels: important (was: ) > Improve distributed SQL support. > > > Key: IGNITE-3860 > URL: https://issues.apache.org/jira/browse/IGNITE-3860 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.7 >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Critical > Labels: important > Fix For: 1.8 > > > Now we do not process subqueries containing aggregate functions or group bys > in FROM clause. Also we do not correctly process UNIONs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2592) Aggregation query with subquery returns incorrect result
[ https://issues.apache.org/jira/browse/IGNITE-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2592. --- > Aggregation query with subquery returns incorrect result > > > Key: IGNITE-2592 > URL: https://issues.apache.org/jira/browse/IGNITE-2592 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Critical > Fix For: 1.8 > > > Issue is discussed here: > http://apache-ignite-users.70518.x6.nabble.com/SQL-query-result-variation-td2889.html > Here is the code that reproduces it: > https://gist.github.com/anonymous/8e2af218598e46577b2a -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3860) Improve distributed SQL support.
[ https://issues.apache.org/jira/browse/IGNITE-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3860: Affects Version/s: 1.7 > Improve distributed SQL support. > > > Key: IGNITE-3860 > URL: https://issues.apache.org/jira/browse/IGNITE-3860 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.7 >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Critical > Labels: important > Fix For: 1.8 > > > Now we do not process subqueries containing aggregate functions or group bys > in FROM clause. Also we do not correctly process UNIONs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2592) Aggregation query with subquery returns incorrect result
[ https://issues.apache.org/jira/browse/IGNITE-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-2592. - Resolution: Duplicate See IGNITE-3860. > Aggregation query with subquery returns incorrect result > > > Key: IGNITE-2592 > URL: https://issues.apache.org/jira/browse/IGNITE-2592 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Critical > Fix For: 1.8 > > > Issue is discussed here: > http://apache-ignite-users.70518.x6.nabble.com/SQL-query-result-variation-td2889.html > Here is the code that reproduces it: > https://gist.github.com/anonymous/8e2af218598e46577b2a -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3860) Improve distributed SQL support.
[ https://issues.apache.org/jira/browse/IGNITE-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487207#comment-15487207 ] Vladimir Ozerov commented on IGNITE-3860: - Closed duplicate ticket IGNITE-2592. > Improve distributed SQL support. > > > Key: IGNITE-3860 > URL: https://issues.apache.org/jira/browse/IGNITE-3860 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.7 >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Critical > Labels: important > Fix For: 1.8 > > > Now we do not process subqueries containing aggregate functions or group bys > in FROM clause. Also we do not correctly process UNIONs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3860) Improve distributed SQL support.
[ https://issues.apache.org/jira/browse/IGNITE-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3860: Component/s: SQL > Improve distributed SQL support. > > > Key: IGNITE-3860 > URL: https://issues.apache.org/jira/browse/IGNITE-3860 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.7 >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Critical > Labels: important > Fix For: 1.8 > > > Now we do not process subqueries containing aggregate functions or group bys > in FROM clause. Also we do not correctly process UNIONs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3860) Improve distributed SQL support.
[ https://issues.apache.org/jira/browse/IGNITE-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3860: Fix Version/s: 1.8 > Improve distributed SQL support. > > > Key: IGNITE-3860 > URL: https://issues.apache.org/jira/browse/IGNITE-3860 > Project: Ignite > Issue Type: Bug > Components: SQL >Affects Versions: 1.7 >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Critical > Labels: important > Fix For: 1.8 > > > Now we do not process subqueries containing aggregate functions or group bys > in FROM clause. Also we do not correctly process UNIONs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3887) IGFS: Encapsulate IgfsPath root.
[
https://issues.apache.org/jira/browse/IGNITE-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3887:
Summary: IGFS: Encapsulate IgfsPath root. (was: IGFS: Encapsulate IgfsPath
root .)
> IGFS: Encapsulate IgfsPath root.
>
>
> Key: IGNITE-3887
> URL: https://issues.apache.org/jira/browse/IGNITE-3887
> Project: Ignite
> Issue Type: Task
> Components: IGFS
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.8
>
>
> Currently we have some trash in {{IgfsPath}} class:
> 1) {{root()}} method;
> 2) {{new IgfsPath()}} which also creates a root;
> 3) {{isSame()}} method which simply delegates to {{equals()}}.
> Let's deprecate all these things and create consistent public static final
> ROOT singleton.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3888) Web Console: move feedbacks with basic validators to mixins
Alexey Kuznetsov created IGNITE-3888: Summary: Web Console: move feedbacks with basic validators to mixins Key: IGNITE-3888 URL: https://issues.apache.org/jira/browse/IGNITE-3888 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 1.7 Reporter: Alexey Kuznetsov Assignee: Dmitriy Shabalin Fix For: 1.8 Move required, min and max feedbacks from basic inputs to mixins. Other way they don't visible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487067#comment-15487067 ] Alexey Kuznetsov edited comment on IGNITE-3729 at 9/13/16 12:43 PM: Please rework package name to mixin (see mixin java-class, you will need to introduce java-package mixin) was (Author: kuaw26): # Please rework package name to mixin (see mixin java-class, you will need to introduce java-package mixin) # In case of error feedback should be shown (empty, invalid package, java keyword used) > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Maxim Afanasiev >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit
[
https://issues.apache.org/jira/browse/IGNITE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487084#comment-15487084
]
Semen Boikov commented on IGNITE-1525:
--
Hi Anton,
I think that at least it makes sense to add tests for nethods which return
boolean (putIfAbsent/remove). If tests will fail, then we need to understand
why, probably it can be easily fixed as part of this fix.
Thanks!
> Return value for cache operation can be lost with onePhaseCommit
>
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.8
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value
> is not received, but transaction executes 'check backup' step and finishes
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also
> added one more test to check return value
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3887) IGFS: Encapsulate IgfsPath root .
Vladimir Ozerov created IGNITE-3887:
---
Summary: IGFS: Encapsulate IgfsPath root .
Key: IGNITE-3887
URL: https://issues.apache.org/jira/browse/IGNITE-3887
Project: Ignite
Issue Type: Task
Components: IGFS
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
Fix For: 1.8
Currently we have some trash in {{IgfsPath}} class:
1) {{root()}} method;
2) {{new IgfsPath()}} which also creates a root;
3) {{isSame()}} method which simply delegates to {{equals()}}.
Let's deprecate all these things and create consistent public static final ROOT
singleton.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487067#comment-15487067 ] Alexey Kuznetsov edited comment on IGNITE-3729 at 9/13/16 12:25 PM: # Please rework package name to mixin (see mixin java-class, you will need to introduce java-package mixin) # In case of error feedback should be shown (empty, invalid package, java keyword used) was (Author: kuaw26): # Please rework package name to mixin (see mixin java-class, you will need to introduce java-package mixin) # In case of error feedback should be shown > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Maxim Afanasiev >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487067#comment-15487067 ] Alexey Kuznetsov edited comment on IGNITE-3729 at 9/13/16 12:23 PM: # Please rework package name to mixin (see mixin java-class, you will need to introduce java-package mixin) # In case of error feedback should be shown was (Author: kuaw26): # Please rework package name to mixin # In case of error feedback should be shown > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Maxim Afanasiev >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-3729: Assignee: Maxim Afanasiev (was: Alexey Kuznetsov) # Please rework package name to mixin # In case of error feedback should be shown > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Maxim Afanasiev >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2539) NPE at RendezvousAffinityFunction
[ https://issues.apache.org/jira/browse/IGNITE-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-2539: -- Assignee: Dmitriy Govorukhin (was: Semen Boikov) > NPE at RendezvousAffinityFunction > - > > Key: IGNITE-2539 > URL: https://issues.apache.org/jira/browse/IGNITE-2539 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ershov >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 1.8 > > Attachments: ignite.log > > Original Estimate: 4h > Remaining Estimate: 4h > > RendezvousAffinityFunction#assignPartition throws NPE, probably due to > simultaneous topology change and cache stop. We should write a test and fix > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-104) Need to enable thread-per-partition mode for atomic caches
[
https://issues.apache.org/jira/browse/IGNITE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov reassigned IGNITE-104:
Assignee: Yakov Zhdanov
> Need to enable thread-per-partition mode for atomic caches
> --
>
> Key: IGNITE-104
> URL: https://issues.apache.org/jira/browse/IGNITE-104
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Yakov Zhdanov
>Priority: Critical
>
> Currently messages are processed in any order for atomic caches. We can add
> ordered processing by assigning a thread per partition. This way we will be
> able to remove any locking as well.
> {{Cache.invoke()}} method would be able to invoke the EntryProcessor on
> primary and backup independently. Right now we only invoke the EntryProcessor
> only on the primary node and the send the computed value to the backup node,
> which may be expensive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-104) Need to enable thread-per-partition mode for atomic caches
[
https://issues.apache.org/jira/browse/IGNITE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov updated IGNITE-104:
-
Assignee: (was: Yakov Zhdanov)
> Need to enable thread-per-partition mode for atomic caches
> --
>
> Key: IGNITE-104
> URL: https://issues.apache.org/jira/browse/IGNITE-104
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Dmitriy Setrakyan
>Priority: Critical
>
> Currently messages are processed in any order for atomic caches. We can add
> ordered processing by assigning a thread per partition. This way we will be
> able to remove any locking as well.
> {{Cache.invoke()}} method would be able to invoke the EntryProcessor on
> primary and backup independently. Right now we only invoke the EntryProcessor
> only on the primary node and the send the computed value to the backup node,
> which may be expensive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (IGNITE-3767) Web Console: create reusable dialog for node selection
[ https://issues.apache.org/jira/browse/IGNITE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reopened IGNITE-3767: > Web Console: create reusable dialog for node selection > -- > > Key: IGNITE-3767 > URL: https://issues.apache.org/jira/browse/IGNITE-3767 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 1.7 >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 1.8 > > > In several places (for example on SQL screen) we need to select some node > where some task will be executed. > We need a reusable dialog that will display all nodes and will allow to > select only one and return that node to calling code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3314) Implement Serializable in org.apache.ignite.cache.store.cassandra.datasource.DataSource
[ https://issues.apache.org/jira/browse/IGNITE-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-3314. > Implement Serializable in > org.apache.ignite.cache.store.cassandra.datasource.DataSource > --- > > Key: IGNITE-3314 > URL: https://issues.apache.org/jira/browse/IGNITE-3314 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Igor Rudyak >Assignee: Igor Rudyak >Priority: Minor > Fix For: 1.8 > > > Current implementation of > org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource doesn't > implement Serializable, thus for distributed Ignite clusters, > CassandraCacheStoreFactory could only be setup through Spring XML file, but > not from code. > New version of > org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource should > implement Serializable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3314) Implement Serializable in org.apache.ignite.cache.store.cassandra.datasource.DataSource
[ https://issues.apache.org/jira/browse/IGNITE-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486937#comment-15486937 ] ASF GitHub Bot commented on IGNITE-3314: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/974 > Implement Serializable in > org.apache.ignite.cache.store.cassandra.datasource.DataSource > --- > > Key: IGNITE-3314 > URL: https://issues.apache.org/jira/browse/IGNITE-3314 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Igor Rudyak >Assignee: Igor Rudyak >Priority: Minor > Fix For: 1.8 > > > Current implementation of > org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource doesn't > implement Serializable, thus for distributed Ignite clusters, > CassandraCacheStoreFactory could only be setup through Spring XML file, but > not from code. > New version of > org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource should > implement Serializable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit
[
https://issues.apache.org/jira/browse/IGNITE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486880#comment-15486880
]
Anton Vinogradov edited comment on IGNITE-1525 at 9/13/16 10:32 AM:
All comments fixed, TC and benchs checked.
putIfAbsent can be checked as separate issue.
was (Author: avinogradov):
All comments fixed, TC and benchs checked.
> Return value for cache operation can be lost with onePhaseCommit
>
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.8
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value
> is not received, but transaction executes 'check backup' step and finishes
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also
> added one more test to check return value
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit
[
https://issues.apache.org/jira/browse/IGNITE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486880#comment-15486880
]
Anton Vinogradov edited comment on IGNITE-1525 at 9/13/16 10:28 AM:
All comments fixed, TC and benchs checked.
was (Author: avinogradov):
All comments fixed, TC and benchs checked,
> Return value for cache operation can be lost with onePhaseCommit
>
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.8
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value
> is not received, but transaction executes 'check backup' step and finishes
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also
> added one more test to check return value
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1915) .NET: Ignite as Entity Framework Second-Level Cache
[ https://issues.apache.org/jira/browse/IGNITE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486739#comment-15486739 ] Pavel Tupitsyn commented on IGNITE-1915: Let's merge IGNITE-3199 first to reuse Java EntryProcessor approach from there (EntryProcessor is used to increase entity set versions). > .NET: Ignite as Entity Framework Second-Level Cache > --- > > Key: IGNITE-1915 > URL: https://issues.apache.org/jira/browse/IGNITE-1915 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net, roadmap > Fix For: 1.8 > > > Entity Framework is #1 ORM for .NET > We should provide easy solution to boost Entity Framework performance with > Ignite. > EF5 and EF6 have different 2nd level cache mechanisms (EF5 has a built-in > one, EF6 requies more customization or a 3rd party lib like > https://efcache.codeplex.com/). For now, let's do EF6 only. > This should be in a separate assembly and a separate NuGet package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2649) Ignition.localIgnite() unreliable under Gateways and cause wrong components deserialization.
[
https://issues.apache.org/jira/browse/IGNITE-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2649.
---
> Ignition.localIgnite() unreliable under Gateways and cause wrong components
> deserialization.
>
>
> Key: IGNITE-2649
> URL: https://issues.apache.org/jira/browse/IGNITE-2649
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Labels: 1.6, community
> Fix For: 1.8
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> We can get something like this:
> {noformat}
> java.lang.IllegalArgumentException: This method should be accessed under
> org.apache.ignite.thread.IgniteThread
> at org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1252)
> at org.apache.ignite.Ignition.localIgnite(Ignition.java:531)
> at org.project.MyPojo.readResolve(MyPojo.java:123)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:746)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1564)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readObject(BinaryReaderExImpl.java:1086)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:827)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:734)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1564)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:1908)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadMap(BinaryUtils.java:1892)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1595)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1644)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:734)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:537)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:135)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1757)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:629)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:421)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:337)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:196)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:266)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4774)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4758)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1391)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:865)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486730#comment-15486730 ] Dmitriy Govorukhin commented on IGNITE-3727: In my test, i just check that listener executing in same thread if sync mode, or another thread in async mode. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486716#comment-15486716 ] Dmitriy Govorukhin edited comment on IGNITE-3727 at 9/13/16 9:05 AM: - Hi [~sboikov], 1,2,3 understood and fix it soon. about 'why you did not add tests for 'sendOrdered' method?', in previous comment i said that i added in IgniteMessagingConfigVariationFullApiTestSuite async mode and this suit cover all cases for send message include send sendOrdered. But if you think that need add it to my test i can do it. was (Author: dmitriygovorukhin): 1,2,3 understood and fix it soon. about 'why you did not add tests for 'sendOrdered' method?', in previous comment i said that i added in IgniteMessagingConfigVariationFullApiTestSuite async mode and this suit cover all cases for send message include send sendOrdered. But if you think that need add it to my test i can do it. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Afanasiev updated IGNITE-3729: Assignee: Alexey Kuznetsov (was: Maxim Afanasiev) > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486716#comment-15486716 ] Dmitriy Govorukhin commented on IGNITE-3727: 1,2,3 understood and fix it soon. about 'why you did not add tests for 'sendOrdered' method?', in previous comment i said that i added in IgniteMessagingConfigVariationFullApiTestSuite async mode and this suit cover all cases for send message include send sendOrdered. But if you think that need add it to my test i can do it. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2396) Dynamic cache changes are not tracked by service processor
[ https://issues.apache.org/jira/browse/IGNITE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov closed IGNITE-2396. > Dynamic cache changes are not tracked by service processor > -- > > Key: IGNITE-2396 > URL: https://issues.apache.org/jira/browse/IGNITE-2396 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk > Labels: community > Fix For: 1.7 > > > Currently service processor handles only discovery node join/leave/fail > events. Now consider the following two scenarios: > - > - N nodes are started. Topology version is (N, 0) > - A dynamic cache is created. Topology version is (N, 1) > - An affinity singleton service is deployed. > On step (3), when assignment is calculated, service processor uses topology > version (N, 0) (see > org.apache.ignite.internal.processors.service.GridServiceProcessor.DeploymentListener#onDeployment). > As a result, no affinity nodes are returned for assignment and service is > not deployed. > - > - N nodes are started. Topology version is (N, 0) > - An affinity singleton service is deployed. > - A dynamic cache is created. Topology version is (N, 1) > On step (3) custom discovery event is generated, but it is not handled by > service processor, so no reassignment logic is triggered and service is not > deployed. > Proposed solution is as follows: > - Use a correct topology version for service deployment > (ctx.discovery().topologyVersionEx()). > - Event listener should handle custom events that trigger dynamic cache > start and stop. > - Additionally need to investigate whether reassignment logic should be in > any way synchronized with the partition exchange future completion. > org.apache.ignite.internal.processors.service.IgniteServiceDynamicCachesSelfTest > is added to master. Need to add it to the services test suite once the fix > is implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2396) Dynamic cache changes are not tracked by service processor
[ https://issues.apache.org/jira/browse/IGNITE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov resolved IGNITE-2396. -- Resolution: Fixed Assignee: (was: Dmitriy Govorukhin) Fix Version/s: (was: 1.8) 1.7 Test pass now, added it in suite. I think issues in service processor were fixed as part of affinity assignment refactoring in 1.7. > Dynamic cache changes are not tracked by service processor > -- > > Key: IGNITE-2396 > URL: https://issues.apache.org/jira/browse/IGNITE-2396 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk > Labels: community > Fix For: 1.7 > > > Currently service processor handles only discovery node join/leave/fail > events. Now consider the following two scenarios: > - > - N nodes are started. Topology version is (N, 0) > - A dynamic cache is created. Topology version is (N, 1) > - An affinity singleton service is deployed. > On step (3), when assignment is calculated, service processor uses topology > version (N, 0) (see > org.apache.ignite.internal.processors.service.GridServiceProcessor.DeploymentListener#onDeployment). > As a result, no affinity nodes are returned for assignment and service is > not deployed. > - > - N nodes are started. Topology version is (N, 0) > - An affinity singleton service is deployed. > - A dynamic cache is created. Topology version is (N, 1) > On step (3) custom discovery event is generated, but it is not handled by > service processor, so no reassignment logic is triggered and service is not > deployed. > Proposed solution is as follows: > - Use a correct topology version for service deployment > (ctx.discovery().topologyVersionEx()). > - Event listener should handle custom events that trigger dynamic cache > start and stop. > - Additionally need to investigate whether reassignment logic should be in > any way synchronized with the partition exchange future completion. > org.apache.ignite.internal.processors.service.IgniteServiceDynamicCachesSelfTest > is added to master. Need to add it to the services test suite once the fix > is implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486543#comment-15486543 ] Maxim Afanasiev edited comment on IGNITE-3729 at 9/13/16 7:30 AM: -- 1. ignite-form-field___label is element by BEM methodology. ignite-form-field-password is block that contains label element with ignite-form-field___label class. 2. Others form-field mixins are correctly named. 3. small-label not under form tag for better granuality of css class composition. 4. small-label is modifiсator for settings-row class. it is separate by one undescore. was (Author: mafanasiev): 1. ignite-form-field___label is element by BEM methodology. ignite-form-field-password is block that contains label element with ignite-form-field__label class. 2. Others form-field mixins are correctly named. 3. small-label not under form tag for better granuality of css class composition. 4. small-label is modifiсator for settings-row class. it is separate by one undescore. > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Maxim Afanasiev >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3886) .NET: Build script
Pavel Tupitsyn created IGNITE-3886: -- Summary: .NET: Build script Key: IGNITE-3886 URL: https://issues.apache.org/jira/browse/IGNITE-3886 Project: Ignite Issue Type: Task Components: platforms Reporter: Pavel Tupitsyn Fix For: 1.8 Create a build script with powershell or cake http://cakebuild.net/. Currently, we have our build completely automated on TeamCity. However, it should be possible to build everything (jars, dlls, NuGet) locally with a single command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486543#comment-15486543 ] Maxim Afanasiev commented on IGNITE-3729: - 1. ignite-form-field__label is element by BEM methodology. ignite-form-field-password is block that contains label element with ignite-form-field__label class. 2. Others form-field mixins are correctly named. 3. small-label not under form tag for better granuality of css class composition. 4. small-label is modifiсator for settings-row class. it is separate by one undescore. > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Maxim Afanasiev >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3885) .NET: Describe development process on Wiki
[ https://issues.apache.org/jira/browse/IGNITE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-3885: --- Issue Type: Task (was: Bug) > .NET: Describe development process on Wiki > -- > > Key: IGNITE-3885 > URL: https://issues.apache.org/jira/browse/IGNITE-3885 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: .NET > Fix For: 1.8 > > > Ignite wiki: > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Home > Add .NET development process page: > * Coding guidelines (naming conventions, etc) > * Project structure > * Code inspections, how to run locally and on TC > * Test coverage > * How to build (AnyCPU nuances, NuGet, embedded CPP part, Java, etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3884) .NET: Describe development process on Wiki
Pavel Tupitsyn created IGNITE-3884: -- Summary: .NET: Describe development process on Wiki Key: IGNITE-3884 URL: https://issues.apache.org/jira/browse/IGNITE-3884 Project: Ignite Issue Type: Bug Components: platforms Reporter: Pavel Tupitsyn Priority: Minor Fix For: 1.8 Ignite wiki: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Home Add .NET development process page: * Coding guidelines (naming conventions, etc) * Project structure * Code inspections, how to run locally and on TC * Test coverage * How to build (AnyCPU nuances, NuGet, embedded CPP part, Java, etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3885) .NET: Describe development process on Wiki
Pavel Tupitsyn created IGNITE-3885: -- Summary: .NET: Describe development process on Wiki Key: IGNITE-3885 URL: https://issues.apache.org/jira/browse/IGNITE-3885 Project: Ignite Issue Type: Bug Components: platforms Reporter: Pavel Tupitsyn Priority: Minor Fix For: 1.8 Ignite wiki: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Home Add .NET development process page: * Coding guidelines (naming conventions, etc) * Project structure * Code inspections, how to run locally and on TC * Test coverage * How to build (AnyCPU nuances, NuGet, embedded CPP part, Java, etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3882) Web console: Invalid focus moving on edit of typeahead field.
[ https://issues.apache.org/jira/browse/IGNITE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-3882: - Assignee: Vasiliy Sisko (was: Alexey Kuznetsov) > Web console: Invalid focus moving on edit of typeahead field. > - > > Key: IGNITE-3882 > URL: https://issues.apache.org/jira/browse/IGNITE-3882 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 1.8 > > > Domain page -> Domain model for SQL query. > # Configure some field. > # Change created field. > On change of data type focus move to begin on every symbol change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3882) Web console: Invalid focus moving on edit of typeahead field.
[ https://issues.apache.org/jira/browse/IGNITE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin resolved IGNITE-3882. -- Resolution: Fixed Assignee: Alexey Kuznetsov (was: Dmitriy Shabalin) > Web console: Invalid focus moving on edit of typeahead field. > - > > Key: IGNITE-3882 > URL: https://issues.apache.org/jira/browse/IGNITE-3882 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 1.8 > > > Domain page -> Domain model for SQL query. > # Configure some field. > # Change created field. > On change of data type focus move to begin on every symbol change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3882) Web console: Invalid focus moving on edit of typeahead field.
[ https://issues.apache.org/jira/browse/IGNITE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486369#comment-15486369 ] Dmitriy Shabalin commented on IGNITE-3882: -- Repaired lost directive retain selection. pls check it > Web console: Invalid focus moving on edit of typeahead field. > - > > Key: IGNITE-3882 > URL: https://issues.apache.org/jira/browse/IGNITE-3882 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 1.8 > > > Domain page -> Domain model for SQL query. > # Configure some field. > # Change created field. > On change of data type focus move to begin on every symbol change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
