[jira] [Created] (IGNITE-4079) Web console-SQL: cache name is not displayed for default cache (cache name is null) in 'show query' dialog

2016-10-13 Thread Pavel Konstantinov (JIRA) 
Pavel Konstantinov created IGNITE-4079:
--

 Summary: Web console-SQL: cache name is not displayed for default 
cache (cache name is null) in 'show query' dialog
 Key: IGNITE-4079
 URL: https://issues.apache.org/jira/browse/IGNITE-4079
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Priority: Minor


We should display ''.

# choose  cache
# SCAN
# click on 'show query'




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

[jira] [Created] (IGNITE-4078) Web console: pie chart is not refreshed in coner case

2016-10-13 Thread Pavel Konstantinov (JIRA) 
Pavel Konstantinov created IGNITE-4078:
--

 Summary: Web console: pie chart is not refreshed in coner case
 Key: IGNITE-4078
 URL: https://issues.apache.org/jira/browse/IGNITE-4078
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Priority: Minor
 Attachments: IGNITE-4078.png

# execute SCAN
# open pie chart - you should see 'scan is not supported'
# write a valid query and Execute
Observed - no pie chart was painted, only legend is visible (see attachment)



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

[jira] [Created] (IGNITE-4077) Web console: 'export all' needs to be improved

2016-10-13 Thread Pavel Konstantinov (JIRA) 
Pavel Konstantinov created IGNITE-4077:
--

 Summary: Web console: 'export all' needs to be improved
 Key: IGNITE-4077
 URL: https://issues.apache.org/jira/browse/IGNITE-4077
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Priority: Minor


Currently opening the system dialog to save a file takes a very long time and 
during this time user thinks that 'export all' doesn't work.

I suggest to show some kind of dialog to show fetching progress. And during 
this time all UI elements of this query should not be available.



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

[jira] [Created] (IGNITE-4076) Web console: can not choose a cache by clicking on it

2016-10-13 Thread Pavel Konstantinov (JIRA) 
Pavel Konstantinov created IGNITE-4076:
--

 Summary: Web console: can not choose a cache by clicking on it
 Key: IGNITE-4076
 URL: https://issues.apache.org/jira/browse/IGNITE-4076
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Priority: Minor


# Open SQL page
# Create a second query
# Click by cache name

In my case the page is scrolled up instead of cache selecting.



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

Re: Cassandra store questions

2016-10-13 Thread Igor Rudyak 
Ok, thanks.

Igor

On Oct 13, 2016 4:37 PM, "Valentin Kulichenko" <
valentin.kuliche...@gmail.com> wrote:

> Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-4075
>
> -Val
>
> On Wed, Oct 12, 2016 at 6:45 PM, Igor Rudyak  wrote:
>
>> Hi Val,
>>
>> I don't have any objections - please create a ticket and link it to the
>> root ticket https://issues.apache.org/jira/browse/IGNITE-1371
>>
>> Igor
>>
>> On Wed, Oct 12, 2016 at 4:10 PM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>>> Hi Igor,
>>>
>>> 1. I still think we should do this. Loading nothing is very
>>> counterintuitive and prevents a newbie user from quick start. For large
>>> tables, when only part of the dataset is needed, user will explicitly
>>> specify the query, of course. Do you have objections? If no, I will create
>>> a ticket.
>>>
>>> 2. Got it, thanks.
>>>
>>> -Val
>>>
>>> On Mon, Oct 10, 2016 at 12:12 AM, Igor Rudyak  wrote:
>>>
 Hi Val,

 1) Well, it's not a problem to implement such default behavior, but
 there is one concern. In most cases, when you are using Cassandra as a
 persistent store you are going to store large amount of data, which is
 significantly bigger that amount of RAM in your Ignite cluster. In the such
 case it doesn't make sense to launch CQL query like "select * from
 my_table" cause:
a) You still will not be able to keep all data from Cassandra table
 in Ignite cache
b) All the data will be pulled from Cassandra table using only one
 thread - which is very slow

 2) Unfortunately it's not possible in Cassandra. For JDBC you are
 splitting table into chunks of 512 rows each, using sub-queries and
 ordering by primary keys. Such kind of things are not supported in
 Cassandra. Probably the only way to load data from Cassandra table in
 parallel, is to load it from some specified partitions (in parallel for
 each partition).


 Igor Rudyak

 On Fri, Oct 7, 2016 at 1:45 PM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:

> Hi Igor,
>
> Thanks for response!
>
> 1. It's a bit inconsistent with other store implementations we have in
> the product and actually I find this counterintuitive. Why don't we just
> load all the data available in the table? Explicit query is useful when 
> you
> want to customize this and load subset of data based on some criteria. If
> this is not possible for some reason, then I would at least throw an
> exception in case query is not specified.
>
> 2. Is it possible to automatically split the data in bulks and load
> them in parallel? We do this in the JDBC store, for example.
>
> -Val
>
> On Thu, Oct 6, 2016 at 11:00 PM, Igor Rudyak 
> wrote:
>
>> Hi Val,
>>
>> 1) If you'll call loadCache(null) it will do nothing. You need to
>> provide at least one CQL query.
>>
>> 2) It depends. If you'll provide more than one CQL query, it will use
>> separate thread for each of the queries (max number of threads limited to
>> the number of CPU cores). But for each provided CQL query it will use 
>> only
>> one thread to load all the data returned by the query. Also it will run 
>> the
>> same CQL query from ALL Ignite nodes to load the same data, which is bad.
>> That's because loadCache method will be executed on each Ignite node. As
>> you see, it's not very efficient way to load data from Cassandra just by
>> specifying CQL query. The ticket I created, is all about how to load data
>> from one table (or from multiple tables as well) in parallel by
>> partitioning it. Such a way each Ignite node will be responsible to load
>> data from the specific partition range of Cassandra table, which is much
>> more efficient. To support such kind of cache warm-up you should design
>> your Cassandra table specific way - there should be some mapping from
>> Ignite partition to the set of Cassandra partitions. Yes I have plans to
>> implement this.
>>
>> Igor Rudyak
>>
>>
>> On Thu, Oct 6, 2016 at 10:19 AM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>>> Hi Igor,
>>>
>>> I've got couple of quick questions about the Cassandra store.
>>>
>>>1. In [1] you suggested to provide an explicit query as a
>>>parameter for loadCache() method, because otherwise user was always 
>>> getting
>>>empty result. Is this a requirement to provide the query? What if I 
>>> just
>>>call loadCache(null)?
>>>2. There is a ticket [2] about parallel load in Cassandra store.
>>>Does it mean that currently it loads only in a single threaded 
>>> fashion? If
>>>so, do you have any plans to implement this improvement?
>>>
>>>

Re: Cassandra store questions

2016-10-13 Thread Valentin Kulichenko 
Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-4075

-Val

On Wed, Oct 12, 2016 at 6:45 PM, Igor Rudyak  wrote:

> Hi Val,
>
> I don't have any objections - please create a ticket and link it to the
> root ticket https://issues.apache.org/jira/browse/IGNITE-1371
>
> Igor
>
> On Wed, Oct 12, 2016 at 4:10 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Hi Igor,
>>
>> 1. I still think we should do this. Loading nothing is very
>> counterintuitive and prevents a newbie user from quick start. For large
>> tables, when only part of the dataset is needed, user will explicitly
>> specify the query, of course. Do you have objections? If no, I will create
>> a ticket.
>>
>> 2. Got it, thanks.
>>
>> -Val
>>
>> On Mon, Oct 10, 2016 at 12:12 AM, Igor Rudyak  wrote:
>>
>>> Hi Val,
>>>
>>> 1) Well, it's not a problem to implement such default behavior, but
>>> there is one concern. In most cases, when you are using Cassandra as a
>>> persistent store you are going to store large amount of data, which is
>>> significantly bigger that amount of RAM in your Ignite cluster. In the such
>>> case it doesn't make sense to launch CQL query like "select * from
>>> my_table" cause:
>>>a) You still will not be able to keep all data from Cassandra table
>>> in Ignite cache
>>>b) All the data will be pulled from Cassandra table using only one
>>> thread - which is very slow
>>>
>>> 2) Unfortunately it's not possible in Cassandra. For JDBC you are
>>> splitting table into chunks of 512 rows each, using sub-queries and
>>> ordering by primary keys. Such kind of things are not supported in
>>> Cassandra. Probably the only way to load data from Cassandra table in
>>> parallel, is to load it from some specified partitions (in parallel for
>>> each partition).
>>>
>>>
>>> Igor Rudyak
>>>
>>> On Fri, Oct 7, 2016 at 1:45 PM, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>>
 Hi Igor,

 Thanks for response!

 1. It's a bit inconsistent with other store implementations we have in
 the product and actually I find this counterintuitive. Why don't we just
 load all the data available in the table? Explicit query is useful when you
 want to customize this and load subset of data based on some criteria. If
 this is not possible for some reason, then I would at least throw an
 exception in case query is not specified.

 2. Is it possible to automatically split the data in bulks and load
 them in parallel? We do this in the JDBC store, for example.

 -Val

 On Thu, Oct 6, 2016 at 11:00 PM, Igor Rudyak  wrote:

> Hi Val,
>
> 1) If you'll call loadCache(null) it will do nothing. You need to
> provide at least one CQL query.
>
> 2) It depends. If you'll provide more than one CQL query, it will use
> separate thread for each of the queries (max number of threads limited to
> the number of CPU cores). But for each provided CQL query it will use only
> one thread to load all the data returned by the query. Also it will run 
> the
> same CQL query from ALL Ignite nodes to load the same data, which is bad.
> That's because loadCache method will be executed on each Ignite node. As
> you see, it's not very efficient way to load data from Cassandra just by
> specifying CQL query. The ticket I created, is all about how to load data
> from one table (or from multiple tables as well) in parallel by
> partitioning it. Such a way each Ignite node will be responsible to load
> data from the specific partition range of Cassandra table, which is much
> more efficient. To support such kind of cache warm-up you should design
> your Cassandra table specific way - there should be some mapping from
> Ignite partition to the set of Cassandra partitions. Yes I have plans to
> implement this.
>
> Igor Rudyak
>
>
> On Thu, Oct 6, 2016 at 10:19 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Hi Igor,
>>
>> I've got couple of quick questions about the Cassandra store.
>>
>>1. In [1] you suggested to provide an explicit query as a
>>parameter for loadCache() method, because otherwise user was always 
>> getting
>>empty result. Is this a requirement to provide the query? What if I 
>> just
>>call loadCache(null)?
>>2. There is a ticket [2] about parallel load in Cassandra store.
>>Does it mean that currently it loads only in a single threaded 
>> fashion? If
>>so, do you have any plans to implement this improvement?
>>
>> [1] http://apache-ignite-users.70518.x6.nabble.com/Cannot-qu
>> ery-on-a-cache-using-Cassandra-as-a-persistent-store-td7870.html
>> [2] https://gridgain.freshdesk.com/helpdesk/tickets/2180
>>
>> Thanks,
>> Val
>>
>
>

[jira] [Created] (IGNITE-4075) Cassandra store should load all available data when no parameters are provided in loadCache()

2016-10-13 Thread Valentin Kulichenko (JIRA) 
Valentin Kulichenko created IGNITE-4075:
---

 Summary: Cassandra store should load all available data when no 
parameters are provided in loadCache()
 Key: IGNITE-4075
 URL: https://issues.apache.org/jira/browse/IGNITE-4075
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.7
Reporter: Valentin Kulichenko


Currently, the Cassandra store loads nothing if no explicit query is provided. 
This is very counterintuitive and confusing. Other store implementation load 
all the available data in this case, and I think we should fix it consistently 
for Cassandra store.



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

[GitHub] ignite pull request #1159: IGNITE-4054 Add debug to trace HadoopMapReducePla...

2016-10-13 Thread tledkov-gridgain 
GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4054  Add debug to trace HadoopMapReducePlanner results



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

$ git pull https://github.com/gridgain/apache-ignite ignite-4054

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

https://github.com/apache/ignite/pull/1159.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1159


commit a4c63ae113931615e940ada2411ebce32dba5db8
Author: iveselovskiy 
Date:   2016-09-30T07:45:13Z

IGNITE-3998: IGFS: Enabled 
IgfsAbstractSelfTest.testCreateConsistencyMultithreaded. This closes #1129.

commit a12298c0baf19407f3110ba3c4f0aab88b67946d
Author: Igor Sapego 
Date:   2016-09-30T08:00:51Z

IGNITE-3868: ODBC: Fixed connection string parsing. This closes #1051.

commit 5e7ef8644ad824b87d4797e59133eb783ff8b098
Author: vozerov-gridgain 
Date:   2016-10-03T07:37:25Z

Merge branch 'ignite-1.6.9' into ignite-1.6.10

commit 59b46d3e6ea073d054ca2262d676b055a74bbb1f
Author: vozerov-gridgain 
Date:   2016-10-03T07:40:04Z

IGNITE-2881: Fixed SPI queries.

commit 0b66d2d7b695cf370a4b8a717844ad67742c6090
Author: sboikov 
Date:   2016-10-03T09:04:03Z

ignite-3601 Do not check version on commit for read-only serializable 
transactions.

commit 9f211e413332931f0fb1190744ddd7c7f38fd213
Author: tledkov-gridgain 
Date:   2016-10-03T09:26:12Z

IGNITE-3645: IGFS: Local secondary: Implemented update() operation. This 
closes #1003.

commit fa698d6fcfde0006423ef009337dbef58ac62515
Author: vozerov-gridgain 
Date:   2016-10-03T10:33:12Z

Fixed TcpDiscoverySnapshotHistoryTest intermittent failures caused by 
multicast IP finder.

commit bba019fd5076412ca43c10a32fd300b6031ccd0b
Author: vozerov-gridgain 
Date:   2016-10-03T14:25:20Z

IGNITE-3980: Processed failing tests in query suites. This closes #1137.

commit a92f20b5cc75e6b80b2731da0192723526b0c1dc
Author: vozerov-gridgain 
Date:   2016-10-04T11:10:26Z

IGNITE-3597: Removed static work directory.

commit 23461b8d33922772ef8e7217e9e87b3f3b0b37b1
Author: vozerov-gridgain 
Date:   2016-10-06T07:14:59Z

IGNITE-4001: Timeouts for threads in Ignite pools. This closes #1130.

commit b94b0aeae4c42b1d35128c6b1de97e3fa318d497
Author: tledkov-gridgain 
Date:   2016-10-06T07:22:50Z

IGNITE-3163 IGFS: Added working directory support to 
IgniteHadoopIgfsSecondaryFileSystem. This closes #1030. This closes #1058. This 
closes #1132.

commit e6317e01fa8a0de03e15dcdd84a575c6b06ce701
Author: vozerov-gridgain 
Date:   2016-10-06T09:03:48Z

IGNITE-3593 .NET: IgniteConfiguration.WorkDirectory has no effect. This 
closes #903. This closes #1145.

commit 952be8b995050b34379006dd6e739da3fe3b49e3
Author: Dmitriy Govorukhin 
Date:   2016-10-07T12:00:09Z

Squashed commit of the following:

commit 566881b695b8bc00e618fe9a9b4c86a8fd563cc1
Author: sboikov 
Date:   Fri Oct 7 13:08:38 2016 +0300

minor

commit 7fe88a1cb21f794ee55a176ab36d895cbf916528
Author: Dmitriy Govorukhin 
Date:   Thu Oct 6 11:11:24 2016 +0300

ignite-update-notifier fix after review

(cherry picked from commit a10d2ff)

commit f2de749f958a3b18dc479f8a5517d7bf9362b933
Author: Dmitriy Govorukhin 
Date:   Tue Oct 4 12:12:08 2016 +0300

ignite-2079-2 optimize import and change url path

(cherry picked from commit 830a3cf)

commit 0d1be85ad55b0aa91224690d6c112ae92e8bc0a9
Author: Dmitriy Govorukhin 
Date:   Thu Sep 29 19:54:54 2016 +0300

update-notifier remove parse xml, now parse like properties

(cherry picked from commit 9ecaa29)

commit e43bca6fb4528a7fc0dcb804a74fca1c59d7468b
Author: Dmitriy Govorukhin 
Date:   Tue Sep 27 17:07:21 2016 +0300

remove dom parser

(cherry picked from commit d1653b2)

commit b9c776a8423471706ecb1dc6176b38f23e799077
Author: Anton Vinogradov 
Date:   2016-10-10T08:52:57Z

IGNITE-3235 Failed to initialize primitive boolean cache property of 
superclass

commit f9a0676fad7fd6c23e3c91c10d7e0412ccb27c06
Author: vozerov-gridgain 
Date:   2016-10-11T07:23:01Z

IGNITE-4041: Created separate processor for thread pools and refactored IO 
manager. This closes #1150.

commit

[jira] [Created] (IGNITE-4074) Refactor future operations in PlatformTarget

2016-10-13 Thread Pavel Tupitsyn (JIRA) 
Pavel Tupitsyn created IGNITE-4074:
--

 Summary: Refactor future operations in PlatformTarget
 Key: IGNITE-4074
 URL: https://issues.apache.org/jira/browse/IGNITE-4074
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 1.8






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

[GitHub] ignite pull request #1158: IGNITE-4073: OFFHEAP cache context method isOffHe...

2016-10-13 Thread AMashenkov 
GitHub user AMashenkov opened a pull request:

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

IGNITE-4073: OFFHEAP cache context method isOffHeapEnabled() return false



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

$ git pull https://github.com/gridgain/apache-ignite ignite-4073

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

https://github.com/apache/ignite/pull/1158.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1158


commit c7eed8859202b99cc64b7f6d6efe46acf71ad72a
Author: Denis Magda 
Date:   2016-07-13T11:19:51Z

IGNITE-3440: Ignite Services: ServiceTopologyCallable is executed before 
system cache is started
(cherry picked from commit 06b24a9)

commit 2b5067b528bf6442450b0c16d0bfb1437ea41e1a
Author: Denis Magda 
Date:   2016-07-15T06:35:41Z

IgniteDataStreamer: fixed JavaDoc
(cherry picked from commit 2537e0f)

commit 89fd76fa2e85cfa1c06fbd5151086f958aefa685
Author: Andrey Novikov 
Date:   2016-07-15T09:54:21Z

IGNITE-3446 Visor CMD: improve usability for batch mode.
(cherry picked from commit 4897315)

commit 2f78346e0e3d6a1cb9483b66144175c826a1ff5f
Author: sboikov 
Date:   2016-07-01T09:16:56Z

ignite-1088 Implemented store for multi jvm tests
(cherry picked from commit f91b699)

commit ade57eaf5b77f779642be424d8cdf858a327ce2d
Author: sboikov 
Date:   2016-07-05T04:43:51Z

ignite-1088 Implemented store for multi jvm tests (fixed NPE)
(cherry picked from commit d31a476)

commit d2198a1df0e5c907434ec1a465eb118823723439
Author: sboikov 
Date:   2016-07-04T18:08:24Z

ignite-1089 Fixed tests for multi jvm mode. This closes #846.
(cherry picked from commit bf57413)

commit a648e88c14295bf2c45b8e200eb5a3137997e131
Author: sboikov 
Date:   2016-07-15T13:26:00Z

ignite-1089 Fixed tests for multi jvm mode. This closes #846.
(cherry picked from commit bf57413)

commit 8d6273780bdb63397dfddaf7b7c1e65a8b717e8d
Author: sboikov 
Date:   2016-07-15T13:40:31Z

Added more info in assert message.

commit 4f97444c1e6ac29648dd96bc93f878e1d2c3e784
Author: Denis Magda 
Date:   2016-07-18T12:21:46Z

IGNITE-3455: Entry placed on C++ side is not found on Java side
(cherry picked from commit 84e83c9)

commit e1195296ddc883c0a980f64bf0d80c26ef78b233
Author: sboikov 
Date:   2016-07-13T09:29:33Z

ignite-3392 Added test.
(cherry picked from commit a056954)

commit 46f42723ac76c025863d7a9250de3eec1eca524a
Author: sboikov 
Date:   2016-07-13T09:41:18Z

ignite-3413 Use cache node filter for continuous query registration
(cherry picked from commit 89d64e7)

commit 590dffbe47d015db36710ba7708fd7d83269329f
Author: sboikov 
Date:   2016-07-19T10:35:59Z

ignite-3465 Do not call super.toString for not-initialized BinaryObjectImpl.
(cherry picked from commit 78d7c13)

commit 279de8f7c51dc93480bf64231321c451c7c11780
Author: vozerov-gridgain 
Date:   2016-07-19T12:54:27Z

IGNITE-3416: CPP: Fixed string deserialization performance issue.

commit 1dc8bcc20d89eb4172c4b1c8f718419f059c6cc2
Author: vozerov-gridgain 
Date:   2016-07-19T12:16:21Z

IGNITE-3414: Hadoop: implemented new weight-based map-reduce planner.

commit ecc77b0180b3b16303988e1dc187b53e7b96a111
Author: vozerov-gridgain 
Date:   2016-07-19T13:09:06Z

IGNITE-3414: Hadoop: implemented new weight-based map-reduce planner.

commit 51add5049c9603a143a1a8f9233d94f92c8394da
Author: Pavel Tupitsyn 
Date:   2016-07-19T14:11:46Z

IGNITE-3511: .NET: Fixed AffinityFunctionBase.cs placement, added missing 
Package-Info.cs files.

commit 5ec99e8d987d7c966a55b8138aade6643decd5dd
Author: Valentin Kulichenko 
Date:   2016-07-19T23:01:32Z

IGNITE-3470 - Support EXPIRED events in continuous queries

commit d767e518bf7844e3dcdb3f3fdc02da5ecc1b4f54
Author: Valentin Kulichenko 
Date:   2016-07-07T07:05:16Z

Revert IGNITE-2949 due to broken compatibility

commit 7140ee9ded458e5aedd1c5a9852204337fc3
Author: Valentin Kulichenko 
Date:   2016-07-19T23:23:27Z

Revert IGNITE-2949 due to broken compatibility

commit 6b8020d3ffef55039d0afa55ed5925d9fdb914d2
Author: Sergi Vladykin 
Date:   2016-07-13T17:19:25Z

ignite-3254 - fixed
(cherry picked from commit 4d2be72)

commit 11c7e8fe53461f84924e5c29893865191f236c8c
Author: Anton Vinogradov 
Date:   2016-07-20T08:31:14Z

Documentation fix

commit 9b55658749d0e2a869bbb3614034d8aa1f0e95c1

[jira] [Created] (IGNITE-4073) OFFHEAP cache context isOffHeapEnabled return false

2016-10-13 Thread Andrew Mashenkov (JIRA) 
Andrew Mashenkov created IGNITE-4073:


 Summary: OFFHEAP cache context isOffHeapEnabled return false
 Key: IGNITE-4073
 URL: https://issues.apache.org/jira/browse/IGNITE-4073
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Andrew Mashenkov
Priority: Critical


Cache context method isOffHeapEnabled() and isSwapOrOffheapEnabled() return 
false for OFFHEAP_TIRED memory model, but useOffheapEntry() returns true.

I't seems to be a bug, because, really, entries are put to off-heap.

Due to this bug, TtlManager could not correctly evict expired entries that can 
result in OOME.




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

[jira] [Created] (IGNITE-4072) Web console: Disable Anotation variant of "Query metadata" when POJO is disabled.

2016-10-13 Thread Vasiliy Sisko (JIRA) 
Vasiliy Sisko created IGNITE-4072:
-

 Summary: Web console: Disable Anotation variant of "Query 
metadata" when POJO is disabled.
 Key: IGNITE-4072
 URL: https://issues.apache.org/jira/browse/IGNITE-4072
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 1.8
Reporter: Vasiliy Sisko
 Fix For: 1.8


On model page:
# Uncheck "Generate POJO classes"
# Select Anotation variant of "Query metadata" field.
# Input invalid java class names in "Key type" and "Value type" fields.
# Switch preview generation to Java.

Generated code is invalid and should not be possible.
cache.setIndexedTypes(
6adved.class, 
WRONG_NAME.class
);



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

Re: Improve "direct" serialization

2016-10-13 Thread Vladimir Ozerov 
Writes can be optimized even further:
1) Write to *ByteBuffer *as long as there is a place in it.
2) When it is full - invoke a callback which will submit it to the socket,
reset position to 0, and continue marshaling.

This way we can probably get rid of write "state" at all.

On Thu, Oct 13, 2016 at 1:17 PM, Vladimir Ozerov 
wrote:

> Folks,
>
> I went through our so-called "direct serialization" and appears to be not
> very efficient to me. We never write message length. As a result we have to
> constantly track what was written and what was not, and whether we have a
> room for the next write. The same goes for reader. As a result even single
> "writeInt" is surrounded with multiple checks and writes.
>
> It looks like we can make our algorithm much more simple, straightforward
> and efficient if we add two things to every message:
> - Message length
> - Flag indicating whether it was written fully or not.
>
> If message was written fully to the buffer, we do no need to perform any
> checks during deserialization. To read int it is enough to call
> *ByteBuffer.getInt()*. To read byte array it is enough to call
> *ByteBuffer.getByte()*, etc. Simple and fast.
>
> And only if message was split into pieces on either send or receive sides,
> which should not happen often, we may want to fallback to current
> implementation. Or may be we may copy such message  to a separate buffer
> and still read them without any boundaries checks and "incrementStates".
>
> Thoughts?
>
> Vladimir.
>

[jira] [Created] (IGNITE-4071) Web console: Focus lost from key type on input.

2016-10-13 Thread Vasiliy Sisko (JIRA) 
Vasiliy Sisko created IGNITE-4071:
-

 Summary: Web console: Focus lost from key type on input.
 Key: IGNITE-4071
 URL: https://issues.apache.org/jira/browse/IGNITE-4071
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 1.8
Reporter: Vasiliy Sisko
Assignee: Maxim Afanasiev
 Fix For: 1.8


On model page:
# Uncheck "Generate POJO classes" checkbox.
# Try to input into "Key type" field.
After every input field lost focus.



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

Improve "direct" serialization

2016-10-13 Thread Vladimir Ozerov 
Folks,

I went through our so-called "direct serialization" and appears to be not
very efficient to me. We never write message length. As a result we have to
constantly track what was written and what was not, and whether we have a
room for the next write. The same goes for reader. As a result even single
"writeInt" is surrounded with multiple checks and writes.

It looks like we can make our algorithm much more simple, straightforward
and efficient if we add two things to every message:
- Message length
- Flag indicating whether it was written fully or not.

If message was written fully to the buffer, we do no need to perform any
checks during deserialization. To read int it is enough to call
*ByteBuffer.getInt()*. To read byte array it is enough to call
*ByteBuffer.getByte()*, etc. Simple and fast.

And only if message was split into pieces on either send or receive sides,
which should not happen often, we may want to fallback to current
implementation. Or may be we may copy such message  to a separate buffer
and still read them without any boundaries checks and "incrementStates".

Thoughts?

Vladimir.

[jira] [Created] (IGNITE-4070) .NET: Introduce transformers to SCAN queries

2016-10-13 Thread Pavel Tupitsyn (JIRA) 
Pavel Tupitsyn created IGNITE-4070:
--

 Summary: .NET: Introduce transformers to SCAN queries
 Key: IGNITE-4070
 URL: https://issues.apache.org/jira/browse/IGNITE-4070
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 1.8


Same thing in .NET as IGNITE-2546. 



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

[jira] [Created] (IGNITE-4069) Web console: error triangle icon is not displayed for some fields

2016-10-13 Thread Pavel Konstantinov (JIRA) 
Pavel Konstantinov created IGNITE-4069:
--

 Summary: Web console: error triangle icon is not displayed for 
some fields
 Key: IGNITE-4069
 URL: https://issues.apache.org/jira/browse/IGNITE-4069
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
Priority: Minor


For example this can be reproduced  on CollisionSPI fields for case FIFO.



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

[jira] [Created] (IGNITE-4068) Web console: Extended actions in dropdown menus should contain base action.

2016-10-13 Thread Vasiliy Sisko (JIRA) 
Vasiliy Sisko created IGNITE-4068:
-

 Summary: Web console: Extended actions in dropdown menus should 
contain base action.
 Key: IGNITE-4068
 URL: https://issues.apache.org/jira/browse/IGNITE-4068
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.8
Reporter: Vasiliy Sisko
 Fix For: 1.8


F.e. Dropdown for remove button should contain remove action too.



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

[jira] [Created] (IGNITE-4067) Web console: add 'SqlEscapeAll' to import model from DB UI

2016-10-13 Thread Pavel Konstantinov (JIRA) 
Pavel Konstantinov created IGNITE-4067:
--

 Summary: Web console: add 'SqlEscapeAll' to import model from DB UI
 Key: IGNITE-4067
 URL: https://issues.apache.org/jira/browse/IGNITE-4067
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Pavel Konstantinov
Priority: Minor


Currently we have this option only in Cache configuration screen.
But will be useful to have the same on import model from DB UI.



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