[jira] [Created] (IGNITE-3986) Web console: Wrong defaults in special case

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3986:
-

 Summary: Web console: Wrong defaults in special case
 Key: IGNITE-3986
 URL: https://issues.apache.org/jira/browse/IGNITE-3986
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.8
Reporter: Vasiliy Sisko


On cache with configured cluster:
# Clear cluster and save cache,
# Clone cache,
# Set cluster in cache clone and save,
# Switch to source cache.
Source cache show configured cluster of clone cache.
On refresh of page source cache show empty clusters field.



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

[jira] [Created] (IGNITE-3985) Web Console: Refactor test database init in backend tests.

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-3985:
--

 Summary: Web Console: Refactor test database init in backend tests.
 Key: IGNITE-3985
 URL: https://issues.apache.org/jira/browse/IGNITE-3985
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 1.8
Reporter: Andrey Novikov
Priority: Minor
 Fix For: 1.8


Need simplify database init before test. As example may be  used 
modules/web-console/backend/test/unit/AuthService.test.js



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

[jira] [Created] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query

[Jason Man (JIRA)]

Jason Man created IGNITE-3984:
-

 Summary: NullPointerException in IgniteCacheProxy when creating 
continuous query
 Key: IGNITE-3984
 URL: https://issues.apache.org/jira/browse/IGNITE-3984
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Jason Man


Test attached.  This used to work fine in 1.6.  This seem to be related to this 
jira and PR:

https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284

Here's the scenario:
* First node starts with special attribute and creates a cache with the node 
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started.  When creating a 
continuous query to query the cache created by the first node, a 
NullPointerException is thrown.



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

Re: Default hash code generation strategy for new binary objects

[Dmitriy Setrakyan]

Agree with Denis.

   - by default, all non-transient key fields should participate in the
   hashcode generation
   - when working on DDL, then the primary key fields should participate in
   the hashcode
   - we should add a resolver to override the default behavior (please
   propose the interface in Jira)
   - we should print out a warning, only once per type, the the hashcode
   has been automatically generated based on which fields and which formula

D.

On Tue, Sep 27, 2016 at 5:42 PM, Denis Magda  wrote:

> Hi Alexander,
>
> Vladimir’s proposal sounds reasonable to me. However we must keep in mind
> one important thing. Binary objects were designed to address the following
> disadvantages a regular serializer, like optimized marshaller, has:
> necessity to deserialize an object on a server side every time it’s needed.
> necessity to hold an object in both serialized and deserialized forms on
> the server node.
> necessity to restart the whole cluster each time an object version is
> changed (new field is added or an old one is removed).
> If it will be needed to perform step 3 for a default implementation of the
> binary resolver just because the resolver has to consider new fields or
> ignore old ones then such an implementation sucks. Overall, the default
> implementation should use the reflection coming over all the fields a key
> has ignoring the ones that are marked with “transient” keyword. If a user
> wants to control the default resolver's logic then he can label all the
> fields that mustn’t be of a final has code value with “transient”. This has
> to be well-documented for sure.
>
> Makes sense?
>
> —
> Denis
>
> > On Sep 26, 2016, at 12:40 PM, Alexander Paschenko <
> alexander.a.pasche...@gmail.com> wrote:
> >
> > Hello Igniters,
> >
> > As DML support is near, it's critical that we agree on how we generate
> > hash codes for new keys in presence of binary marshaller. Actually,
> > this discussion isn't new - please see its beginning here:
> >
> > http://apache-ignite-developers.2346864.n4.nabble.
> com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-
> at-the-same-partition-by-default-td8042.html
> >
> > Still, I'm creating this new thread to make getting to the final
> > solution as simple and fast as possible.
> >
> > I remind everyone that the approach that has got the least critics was
> > the one proposed by Vladimir Ozerov:
> >
> > 
> > I think we can do the following:
> > 1) Add "has hash code" flag as Denis suggested.
> > 2) If object without a hash code is put to cache, throw an exception.
> > 3) Add *BinaryEqualsHashCodeResolver *interface.
> > 4) Add default implementation which will auto-generate hash code. *Print
> a
> > warning when auto-generation occurs*, so that user is aware that he is
> > likely to have problems with normal GETs/PUTs.
> > 5) Add another implementation which will use encoded string to calculate
> a
> > hash code. E.g. *new BinaryEqualsHashCodeResolver("{a} * 31 + {b}")*.
> > Originally proposed by Yakov some time ago.
> > 
> >
> > After that, Sergi suggested that instead of a "formula" we keep just a
> > list of the "fields" that participate in hash code evaluation, and
> > with that list, we simply calculate hash code just like IDE does -
> > with all its bit shifts and additions.
> >
> > I'm planning on settling down with this combined Vlad-Sergi approach.
> > Any objections?
> >
> > And an extra question I have: Vlad, you suggest that we both throw an
> > exception on cache code absence and that we might generate it as the
> > last resort. Do I understand you correctly that you suggest generating
> > random code only in context of SQL, but throw exception for keys
> > without codes on ordinary put?
> >
> > And yes, built-in hash codes for JDK types are supported as well as
> > items 1-2 from Vlad's list (there's already fixed issue of IGNITE-3633
> > for the flag and its presence check).
> >
> > - Alex
>
>

Re: Default hash code generation strategy for new binary objects

[Denis Magda]

Hi Alexander,

Vladimir’s proposal sounds reasonable to me. However we must keep in mind one 
important thing. Binary objects were designed to address the following 
disadvantages a regular serializer, like optimized marshaller, has:
necessity to deserialize an object on a server side every time it’s needed.
necessity to hold an object in both serialized and deserialized forms on the 
server node.
necessity to restart the whole cluster each time an object version is changed 
(new field is added or an old one is removed).
If it will be needed to perform step 3 for a default implementation of the 
binary resolver just because the resolver has to consider new fields or ignore 
old ones then such an implementation sucks. Overall, the default implementation 
should use the reflection coming over all the fields a key has ignoring the 
ones that are marked with “transient” keyword. If a user wants to control the 
default resolver's logic then he can label all the fields that mustn’t be of a 
final has code value with “transient”. This has to be well-documented for sure.

Makes sense?

—
Denis
 
> On Sep 26, 2016, at 12:40 PM, Alexander Paschenko 
>  wrote:
> 
> Hello Igniters,
> 
> As DML support is near, it's critical that we agree on how we generate
> hash codes for new keys in presence of binary marshaller. Actually,
> this discussion isn't new - please see its beginning here:
> 
> http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-td8042.html
> 
> Still, I'm creating this new thread to make getting to the final
> solution as simple and fast as possible.
> 
> I remind everyone that the approach that has got the least critics was
> the one proposed by Vladimir Ozerov:
> 
> 
> I think we can do the following:
> 1) Add "has hash code" flag as Denis suggested.
> 2) If object without a hash code is put to cache, throw an exception.
> 3) Add *BinaryEqualsHashCodeResolver *interface.
> 4) Add default implementation which will auto-generate hash code. *Print a
> warning when auto-generation occurs*, so that user is aware that he is
> likely to have problems with normal GETs/PUTs.
> 5) Add another implementation which will use encoded string to calculate a
> hash code. E.g. *new BinaryEqualsHashCodeResolver("{a} * 31 + {b}")*.
> Originally proposed by Yakov some time ago.
> 
> 
> After that, Sergi suggested that instead of a "formula" we keep just a
> list of the "fields" that participate in hash code evaluation, and
> with that list, we simply calculate hash code just like IDE does -
> with all its bit shifts and additions.
> 
> I'm planning on settling down with this combined Vlad-Sergi approach.
> Any objections?
> 
> And an extra question I have: Vlad, you suggest that we both throw an
> exception on cache code absence and that we might generate it as the
> last resort. Do I understand you correctly that you suggest generating
> random code only in context of SQL, but throw exception for keys
> without codes on ordinary put?
> 
> And yes, built-in hash codes for JDK types are supported as well as
> items 1-2 from Vlad's list (there's already fixed issue of IGNITE-3633
> for the flag and its presence check).
> 
> - Alex

[jira] [Created] (IGNITE-3983) CacheBinaryAutoStoreExample get wrong result

[Vasilisa Sidorova (JIRA)]

Vasilisa  Sidorova created IGNITE-3983:
--

 Summary: CacheBinaryAutoStoreExample get wrong result
 Key: IGNITE-3983
 URL: https://issues.apache.org/jira/browse/IGNITE-3983
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
 Environment: Ubuntu 14.04, Win7, Apache Ignite 1.7.2
Reporter: Vasilisa  Sidorova
Priority: Critical


-
DESCRIPTION
-
CacheBinaryAutoStoreExample get wrong result
-
STEPS FOR REPRODUCE
-
# Build examples project
# Start H2 database TCP server using
# Start a few nodes using ExampleNodeStartup (it's stable reproducible with 
different numbers of nodes)
-
ACTUAL RESULT
-
{noformat}
>>> Populate database with data...

>>> Cache auto store example started...
>>> Read value: null
>>> Overwrote old value: null
>>> Read value: Person [id=25121642, orgId=1, lastName=Newton, firstName=Isaac, 
>>> salary=100.1, resume=English physicist and mathematician]
>>> Update salary in transaction...
>>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
>>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
>>> --
>>> Load data to cache from DB with custom SQL...
>>> Loaded cache entries: 3
>>> Load ALL data to cache from DB...
>>> Loaded cache entries: 0
{noformat}
-
EXPECTED RESULT
-
{noformat}
>>> Populate database with data...

>>> Cache auto store example started...
>>> Read value: null
>>> Overwrote old value: null
>>> Read value: Person [id=25121642, orgId=1, lastName=Newton, firstName=Isaac, 
>>> salary=100.1, resume=English physicist and mathematician]
>>> Update salary in transaction...
>>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
>>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
>>> --
>>> Load data to cache from DB with custom SQL...
>>> Loaded cache entries: 3
>>> Load ALL data to cache from DB...
>>> Loaded cache entries: 7
{noformat}
-
ADDITIONAL INFO
-
Isn't reproducible for previous versions



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

Adding Thrift binary protocol

[Maurice]

Dear community,

i was redirected from the users list, ofcourse, with the following:

i am looking for a way to make Ignite work in a polyglot software enviroment
using Apache Thrift as equalizer.
The additional ReST client is a give away, but i would like to have tcp/ip
level access to avoid http overhead.
I was thinking of using TcpCommunicationSpi with a modified IpcToNioAdapter.
Or is there a better, pluggable way of integrating a tcp based client
protocol, maybe like adding a netty tcp thrift module to ignite? 



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-Thrift-binary-protocol-tp11469.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[jira] [Created] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-3982:
---

 Summary: ODBC: Add documentation for added connection string 
attributes and features.
 Key: IGNITE-3982
 URL: https://issues.apache.org/jira/browse/IGNITE-3982
 Project: Ignite
  Issue Type: Task
  Components: odbc
Reporter: Igor Sapego






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

[GitHub] ignite pull request #1126: IGNITE-3868: Fix for Tableau connect using DSN.

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-3868: Fix for Tableau connect using DSN.



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

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

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

https://github.com/apache/ignite/pull/1126.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 #1126


commit b2f92954cc5adc3f35f2478e521b8c613035b4ee
Author: isapego 
Date:   2016-09-27T15:12:09Z

IGNITE-3868: Fix for Tableau connect using DSN.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1125: IGNITE-3280 .NET: Log4net integration

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-3280 .NET: Log4net integration



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

$ git pull https://github.com/ptupitsyn/ignite ignite-3280

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

https://github.com/apache/ignite/pull/1125.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 #1125


commit f1540e352feee9ec9580b63c5815c9bb6becb97a
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:07:35Z

Add log4net project

commit 5ecbdeb08e1bb5974153b344ce54aed0b9c9534e
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:08:40Z

Fix sln

commit cdf0bbedfbaddd3230c3b5ce1555275a93af0cc7
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:23:45Z

wip tests

commit 38b9047eb67a8c4461fdc1ae7163d893738bc5a9
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:31:54Z

Add log4net NuGet dependency

commit 1ac175c12027ccbcf8e0c6cacbaca9971815df8f
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:38:52Z

Fix csproj version

commit a70b529c93c631d4a578b2069c772efff227d481
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:41:17Z

wip

commit fd64e97ee425188e4b6288d7c5da96553e7de2c8
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:45:11Z

log level conversion

commit d05a65e9a20d60f4a557f36ee34efa545f67ac33
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:45:35Z

wip rename

commit 919731358df50c22ab8ec2c46e4f3402e6486254
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:45:52Z

Fix letter case in file name

commit b7a2f179477213364194e7145e26913a2f534762
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:58:02Z

Logger implemented

commit 77260828a8802b704df41431f3b6568f52c9eda5
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:04:33Z

wip tests

commit bfd9c5a0c74076967d1a43767b6bc89066618d28
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:05:56Z

wip

commit b7b914bd61c50197af993b0e68eca7409c709487
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:07:31Z

wip

commit c6f884b1abbe56fa34831ab3e098691d8066f2c4
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:07:59Z

wip

commit 41c2a2ae723802f664d9c5821848b95684963ff1
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:08:56Z

Sign the assembly

commit c76c09a6c35daa581964e1508f20e5587cde7e26
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:13:38Z

TestLogLevelConversion done

commit a4cdc58cb98cfcd5e9e6db30789e24c3a1e6955f
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:19:21Z

wip

commit 222dca2433bd7240eb161424bf4d83bca574f584
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:31:59Z

wip

commit 6f48519a0aba3025f0487bc2565dd273fc4d8468
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:41:02Z

wip

commit cc895d02c70b395e9cc3a08b5f7fbe9ab922f503
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:51:31Z

wip

commit 611f956aa981aea708d4f81276fb193fc32132bb
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:57:12Z

logger done

commit 798f3dc8e75389380c8d6ed00090d5313236f790
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:00:17Z

wip

commit b7d28dfa7dd042856155d1b864a044db26cb7b43
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:02:39Z

wip tests

commit f3f88bd2ec39109547ea6541c50277a9fad9f4ed
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:04:59Z

wip

commit e7552e2480065270aa22d89dac2da1c7ce46e41d
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:10:49Z

Tests done

commit c9ec04ed668d11a955b66771de39d1f9c166e2a6
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:31:22Z

Tests fixed

commit f7f4c2b8b319cd3d258aba1e72c4dff26e17f9e4
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:40:47Z

Add nuspec

commit 0e40da8a88aa223c77ae5c355c51bc7760484395
Author: Pavel Tupitsyn 
Date:   2016-09-27T15:05:21Z

wip

commit 404fbc77555aa1c7a117aa621ae5f3b29d0a7d08
Author: Pavel Tupitsyn 
Date:   2016-09-27T15:06:35Z

wip

commit d672ab03f90493c1510092af5444b13d78292c58
Author: Pavel Tupitsyn 
Date:   2016-09-27T15:10:34Z

fix sln




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please

[jira] [Created] (IGNITE-3981) GridTestProperties should be test instance member.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3981:
---

 Summary: GridTestProperties should be test instance member.
 Key: IGNITE-3981
 URL: https://issues.apache.org/jira/browse/IGNITE-3981
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






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

[jira] [Created] (IGNITE-3980) Process failing Binary Object Queries tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3980:
---

 Summary: Process failing Binary Object Queries tests.
 Key: IGNITE-3980
 URL: https://issues.apache.org/jira/browse/IGNITE-3980
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






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

Re: Merge small test suites into one big suite.

[Anton Vinogradov]

Correct, 1+ minute seems to be a problem.
We can add special TC suite which will compile sources and use it as
dependency for each another TC suite.
It can be more suitable than combine suites.

On Tue, Sep 27, 2016 at 4:33 PM, Vladimir Ozerov 
wrote:

> Anton,
>
> What metrics do you need? Most probably everything already can be found in
> logs.
>
> E.g.:
> http://172.25.1.150:8111/viewLog.html?buildId=323412;
> buildTypeId=IgniteTests_Gce=buildLog#_focus=2450
>
> Highlights:
> - p2p stuff build took 40s
> - ignite-core took ~1m to compile
>
>
> On Tue, Sep 27, 2016 at 4:30 PM, Anton Vinogradov <
> avinogra...@gridgain.com>
> wrote:
>
> > Guys, lets continue discussion after we gain metrics.
> > Simplest check is to create accumulated TC task (which will run all test
> > suites) and check how fast is it.
> >
> > On Tue, Sep 27, 2016 at 4:09 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com
> > >
> > wrote:
> >
> > > I see following possible ways of optimize compilation:
> > >
> > > 1. Build ALL once and after that run tests (may be complicated to
> > > implement).
> > >
> > > 2. We could tune test compilation steps by specifying only needed
> modules
> > > in maven command.
> > > If we running test for ignite-core, lets compile only ignite-core and
> do
> > > not compile scala.
> > > This will require to take a look to all suites build steps.
> > >
> > > On Tue, Sep 27, 2016 at 7:54 PM, Anton Vinogradov <
> > > avinogra...@gridgain.com>
> > > wrote:
> > >
> > > > First of all we should undestand how many time we spend on
> compilation.
> > > > Im not sure that compilation required for test takes more than 20
> > secons.
> > > >
> > > > Even minimal Java build (with excluded Scala, Javadoc, etc) takes
> over
> > 5
> > > >
> > > > Don't mix up project build and compilation required for tests.
> > > >
> > > > But I see that each test spends time on this:
> > > > Step 3/5: Build P2P classes (Maven) (33s)
> > > > Is it necessary ?
> > > >
> > > > On Tue, Sep 27, 2016 at 3:50 PM, Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > wrote:
> > > >
> > > > > +1 for reusing built binaries.
> > > > >
> > > > > * Even minimal Java build (with excluded Scala, Javadoc, etc) takes
> > > over
> > > > 5
> > > > > minutes
> > > > > * There are almost 100 suites currently
> > > > >
> > > > > So we waste around 1 hour of agents time for each full TC run.
> > > > >
> > > > > Joining small suites also makes sense, even with reused binaries,
> > > because
> > > > > of other kinds of overhead (checkout).
> > > > >
> > > > > On Tue, Sep 27, 2016 at 3:38 PM, Alexey Kuznetsov <
> > > > akuznet...@gridgain.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I would merge them only if they ALL are "green".
> > > > > >
> > > > > > or
> > > > > >
> > > > > > May be better solution - build ONCE and REUSE binaries for test?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Sep 27, 2016 at 7:25 PM, Vladimir Ozerov <
> > > voze...@gridgain.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > Currently we have about 60-70 test suites on Team City. When I
> > look
> > > > at
> > > > > > > results I see this:
> > > > > > >
> > > > > > > Ignite 150 Clients -> 1 test -> 6m
> > > > > > > Ignite AWS -> 10 tests -> 11m
> > > > > > > Ignite GCE -> 1 test -> 3m
> > > > > > > Ignite Geospacial Indexing -> 11 tests -> 4m
> > > > > > > Ignite IGFS Examples -> 1 test -> 3m
> > > > > > > Ignite Logging -> 1 test -> 3m
> > > > > > >
> > > > > > > Etc.
> > > > > > >
> > > > > > > It is natural to split tests by their modules. But in this case
> > we
> > > > > spend
> > > > > > > most of the time on compiling the project over and over again
> > just
> > > to
> > > > > run
> > > > > > > several tests. It consumes lots of TeamCity resources. Both CPU
> > for
> > > > > > > compilation, and disk for logs.
> > > > > > >
> > > > > > > I think we can safely merge all these tine suites into one
> single
> > > > suite
> > > > > > and
> > > > > > > call it "Ignite Integrations". This will save us a lot of time.
> > > > > > >
> > > > > > > Note that I mean not each and every integration module, but
> only
> > > > > modules
> > > > > > > where we have no more than a 1-2 dozens of tests.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > Vladimir.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alexey Kuznetsov
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>

[GitHub] ignite pull request #1123: Ignite 3978

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Merge small test suites into one big suite.

[Vladimir Ozerov]

Anton,

What metrics do you need? Most probably everything already can be found in
logs.

E.g.:
http://172.25.1.150:8111/viewLog.html?buildId=323412=IgniteTests_Gce=buildLog#_focus=2450

Highlights:
- p2p stuff build took 40s
- ignite-core took ~1m to compile


On Tue, Sep 27, 2016 at 4:30 PM, Anton Vinogradov 
wrote:

> Guys, lets continue discussion after we gain metrics.
> Simplest check is to create accumulated TC task (which will run all test
> suites) and check how fast is it.
>
> On Tue, Sep 27, 2016 at 4:09 PM, Alexey Kuznetsov  >
> wrote:
>
> > I see following possible ways of optimize compilation:
> >
> > 1. Build ALL once and after that run tests (may be complicated to
> > implement).
> >
> > 2. We could tune test compilation steps by specifying only needed modules
> > in maven command.
> > If we running test for ignite-core, lets compile only ignite-core and do
> > not compile scala.
> > This will require to take a look to all suites build steps.
> >
> > On Tue, Sep 27, 2016 at 7:54 PM, Anton Vinogradov <
> > avinogra...@gridgain.com>
> > wrote:
> >
> > > First of all we should undestand how many time we spend on compilation.
> > > Im not sure that compilation required for test takes more than 20
> secons.
> > >
> > > Even minimal Java build (with excluded Scala, Javadoc, etc) takes over
> 5
> > >
> > > Don't mix up project build and compilation required for tests.
> > >
> > > But I see that each test spends time on this:
> > > Step 3/5: Build P2P classes (Maven) (33s)
> > > Is it necessary ?
> > >
> > > On Tue, Sep 27, 2016 at 3:50 PM, Pavel Tupitsyn 
> > > wrote:
> > >
> > > > +1 for reusing built binaries.
> > > >
> > > > * Even minimal Java build (with excluded Scala, Javadoc, etc) takes
> > over
> > > 5
> > > > minutes
> > > > * There are almost 100 suites currently
> > > >
> > > > So we waste around 1 hour of agents time for each full TC run.
> > > >
> > > > Joining small suites also makes sense, even with reused binaries,
> > because
> > > > of other kinds of overhead (checkout).
> > > >
> > > > On Tue, Sep 27, 2016 at 3:38 PM, Alexey Kuznetsov <
> > > akuznet...@gridgain.com
> > > > >
> > > > wrote:
> > > >
> > > > > I would merge them only if they ALL are "green".
> > > > >
> > > > > or
> > > > >
> > > > > May be better solution - build ONCE and REUSE binaries for test?
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Sep 27, 2016 at 7:25 PM, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > Currently we have about 60-70 test suites on Team City. When I
> look
> > > at
> > > > > > results I see this:
> > > > > >
> > > > > > Ignite 150 Clients -> 1 test -> 6m
> > > > > > Ignite AWS -> 10 tests -> 11m
> > > > > > Ignite GCE -> 1 test -> 3m
> > > > > > Ignite Geospacial Indexing -> 11 tests -> 4m
> > > > > > Ignite IGFS Examples -> 1 test -> 3m
> > > > > > Ignite Logging -> 1 test -> 3m
> > > > > >
> > > > > > Etc.
> > > > > >
> > > > > > It is natural to split tests by their modules. But in this case
> we
> > > > spend
> > > > > > most of the time on compiling the project over and over again
> just
> > to
> > > > run
> > > > > > several tests. It consumes lots of TeamCity resources. Both CPU
> for
> > > > > > compilation, and disk for logs.
> > > > > >
> > > > > > I think we can safely merge all these tine suites into one single
> > > suite
> > > > > and
> > > > > > call it "Ignite Integrations". This will save us a lot of time.
> > > > > >
> > > > > > Note that I mean not each and every integration module, but only
> > > > modules
> > > > > > where we have no more than a 1-2 dozens of tests.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>

Re: Merge small test suites into one big suite.

[Anton Vinogradov]

Guys, lets continue discussion after we gain metrics.
Simplest check is to create accumulated TC task (which will run all test
suites) and check how fast is it.

On Tue, Sep 27, 2016 at 4:09 PM, Alexey Kuznetsov 
wrote:

> I see following possible ways of optimize compilation:
>
> 1. Build ALL once and after that run tests (may be complicated to
> implement).
>
> 2. We could tune test compilation steps by specifying only needed modules
> in maven command.
> If we running test for ignite-core, lets compile only ignite-core and do
> not compile scala.
> This will require to take a look to all suites build steps.
>
> On Tue, Sep 27, 2016 at 7:54 PM, Anton Vinogradov <
> avinogra...@gridgain.com>
> wrote:
>
> > First of all we should undestand how many time we spend on compilation.
> > Im not sure that compilation required for test takes more than 20 secons.
> >
> > Even minimal Java build (with excluded Scala, Javadoc, etc) takes over 5
> >
> > Don't mix up project build and compilation required for tests.
> >
> > But I see that each test spends time on this:
> > Step 3/5: Build P2P classes (Maven) (33s)
> > Is it necessary ?
> >
> > On Tue, Sep 27, 2016 at 3:50 PM, Pavel Tupitsyn 
> > wrote:
> >
> > > +1 for reusing built binaries.
> > >
> > > * Even minimal Java build (with excluded Scala, Javadoc, etc) takes
> over
> > 5
> > > minutes
> > > * There are almost 100 suites currently
> > >
> > > So we waste around 1 hour of agents time for each full TC run.
> > >
> > > Joining small suites also makes sense, even with reused binaries,
> because
> > > of other kinds of overhead (checkout).
> > >
> > > On Tue, Sep 27, 2016 at 3:38 PM, Alexey Kuznetsov <
> > akuznet...@gridgain.com
> > > >
> > > wrote:
> > >
> > > > I would merge them only if they ALL are "green".
> > > >
> > > > or
> > > >
> > > > May be better solution - build ONCE and REUSE binaries for test?
> > > >
> > > >
> > > >
> > > > On Tue, Sep 27, 2016 at 7:25 PM, Vladimir Ozerov <
> voze...@gridgain.com
> > >
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > Currently we have about 60-70 test suites on Team City. When I look
> > at
> > > > > results I see this:
> > > > >
> > > > > Ignite 150 Clients -> 1 test -> 6m
> > > > > Ignite AWS -> 10 tests -> 11m
> > > > > Ignite GCE -> 1 test -> 3m
> > > > > Ignite Geospacial Indexing -> 11 tests -> 4m
> > > > > Ignite IGFS Examples -> 1 test -> 3m
> > > > > Ignite Logging -> 1 test -> 3m
> > > > >
> > > > > Etc.
> > > > >
> > > > > It is natural to split tests by their modules. But in this case we
> > > spend
> > > > > most of the time on compiling the project over and over again just
> to
> > > run
> > > > > several tests. It consumes lots of TeamCity resources. Both CPU for
> > > > > compilation, and disk for logs.
> > > > >
> > > > > I think we can safely merge all these tine suites into one single
> > suite
> > > > and
> > > > > call it "Ignite Integrations". This will save us a lot of time.
> > > > >
> > > > > Note that I mean not each and every integration module, but only
> > > modules
> > > > > where we have no more than a 1-2 dozens of tests.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Vladimir.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > >
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Merge small test suites into one big suite.

[Alexey Kuznetsov]

I see following possible ways of optimize compilation:

1. Build ALL once and after that run tests (may be complicated to
implement).

2. We could tune test compilation steps by specifying only needed modules
in maven command.
If we running test for ignite-core, lets compile only ignite-core and do
not compile scala.
This will require to take a look to all suites build steps.

On Tue, Sep 27, 2016 at 7:54 PM, Anton Vinogradov 
wrote:

> First of all we should undestand how many time we spend on compilation.
> Im not sure that compilation required for test takes more than 20 secons.
>
> Even minimal Java build (with excluded Scala, Javadoc, etc) takes over 5
>
> Don't mix up project build and compilation required for tests.
>
> But I see that each test spends time on this:
> Step 3/5: Build P2P classes (Maven) (33s)
> Is it necessary ?
>
> On Tue, Sep 27, 2016 at 3:50 PM, Pavel Tupitsyn 
> wrote:
>
> > +1 for reusing built binaries.
> >
> > * Even minimal Java build (with excluded Scala, Javadoc, etc) takes over
> 5
> > minutes
> > * There are almost 100 suites currently
> >
> > So we waste around 1 hour of agents time for each full TC run.
> >
> > Joining small suites also makes sense, even with reused binaries, because
> > of other kinds of overhead (checkout).
> >
> > On Tue, Sep 27, 2016 at 3:38 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com
> > >
> > wrote:
> >
> > > I would merge them only if they ALL are "green".
> > >
> > > or
> > >
> > > May be better solution - build ONCE and REUSE binaries for test?
> > >
> > >
> > >
> > > On Tue, Sep 27, 2016 at 7:25 PM, Vladimir Ozerov  >
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > Currently we have about 60-70 test suites on Team City. When I look
> at
> > > > results I see this:
> > > >
> > > > Ignite 150 Clients -> 1 test -> 6m
> > > > Ignite AWS -> 10 tests -> 11m
> > > > Ignite GCE -> 1 test -> 3m
> > > > Ignite Geospacial Indexing -> 11 tests -> 4m
> > > > Ignite IGFS Examples -> 1 test -> 3m
> > > > Ignite Logging -> 1 test -> 3m
> > > >
> > > > Etc.
> > > >
> > > > It is natural to split tests by their modules. But in this case we
> > spend
> > > > most of the time on compiling the project over and over again just to
> > run
> > > > several tests. It consumes lots of TeamCity resources. Both CPU for
> > > > compilation, and disk for logs.
> > > >
> > > > I think we can safely merge all these tine suites into one single
> suite
> > > and
> > > > call it "Ignite Integrations". This will save us a lot of time.
> > > >
> > > > Note that I mean not each and every integration module, but only
> > modules
> > > > where we have no more than a 1-2 dozens of tests.
> > > >
> > > > Thoughts?
> > > >
> > > > Vladimir.
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[GitHub] ignite pull request #1124: IGNITE-3873: Added configs for WiX to generate OD...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-3873: Added configs for WiX to generate ODBC installers.



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

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

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

https://github.com/apache/ignite/pull/1124.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 #1124


commit 8d66eadcfa7b84fa871654d406d18e8b8cc01617
Author: isapego 
Date:   2016-09-23T18:04:33Z

IGNITE-3873: First version of the x86 install config.

commit 98cb20f3fbc4a2433c043f2e3ac477a245d23152
Author: isapego 
Date:   2016-09-23T18:12:11Z

IGNITE-3873: Renamed.

commit e2b910e177be4b25b4860293c78186cff56c1cb7
Author: isapego 
Date:   2016-09-23T18:29:59Z

IGNITE-3873: Added 64-bit installer.

commit 398e8a1ba4a6d59e040bfd3cff5d0e865fb3205c
Author: isapego 
Date:   2016-09-26T18:03:15Z

IGNITE-3873: Added to version update.

commit 7910a4984d24c98103fe2b350494d433bc921e2c
Author: isapego 
Date:   2016-09-27T12:59:07Z

IGNITE-3873: Readme edited.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Merge small test suites into one big suite.

[Pavel Tupitsyn]

+1 for reusing built binaries.

* Even minimal Java build (with excluded Scala, Javadoc, etc) takes over 5
minutes
* There are almost 100 suites currently

So we waste around 1 hour of agents time for each full TC run.

Joining small suites also makes sense, even with reused binaries, because
of other kinds of overhead (checkout).

On Tue, Sep 27, 2016 at 3:38 PM, Alexey Kuznetsov 
wrote:

> I would merge them only if they ALL are "green".
>
> or
>
> May be better solution - build ONCE and REUSE binaries for test?
>
>
>
> On Tue, Sep 27, 2016 at 7:25 PM, Vladimir Ozerov 
> wrote:
>
> > Igniters,
> >
> > Currently we have about 60-70 test suites on Team City. When I look at
> > results I see this:
> >
> > Ignite 150 Clients -> 1 test -> 6m
> > Ignite AWS -> 10 tests -> 11m
> > Ignite GCE -> 1 test -> 3m
> > Ignite Geospacial Indexing -> 11 tests -> 4m
> > Ignite IGFS Examples -> 1 test -> 3m
> > Ignite Logging -> 1 test -> 3m
> >
> > Etc.
> >
> > It is natural to split tests by their modules. But in this case we spend
> > most of the time on compiling the project over and over again just to run
> > several tests. It consumes lots of TeamCity resources. Both CPU for
> > compilation, and disk for logs.
> >
> > I think we can safely merge all these tine suites into one single suite
> and
> > call it "Ignite Integrations". This will save us a lot of time.
> >
> > Note that I mean not each and every integration module, but only modules
> > where we have no more than a 1-2 dozens of tests.
> >
> > Thoughts?
> >
> > Vladimir.
> >
>
>
>
> --
> Alexey Kuznetsov
>

Re: Merge small test suites into one big suite.

[Anton Vinogradov]

First of all we should undestand how many time we spend on compilation.
Im not sure that compilation required for test takes more than 20 secons.

Even minimal Java build (with excluded Scala, Javadoc, etc) takes over 5

Don't mix up project build and compilation required for tests.

But I see that each test spends time on this:
Step 3/5: Build P2P classes (Maven) (33s)
Is it necessary ?

On Tue, Sep 27, 2016 at 3:50 PM, Pavel Tupitsyn 
wrote:

> +1 for reusing built binaries.
>
> * Even minimal Java build (with excluded Scala, Javadoc, etc) takes over 5
> minutes
> * There are almost 100 suites currently
>
> So we waste around 1 hour of agents time for each full TC run.
>
> Joining small suites also makes sense, even with reused binaries, because
> of other kinds of overhead (checkout).
>
> On Tue, Sep 27, 2016 at 3:38 PM, Alexey Kuznetsov  >
> wrote:
>
> > I would merge them only if they ALL are "green".
> >
> > or
> >
> > May be better solution - build ONCE and REUSE binaries for test?
> >
> >
> >
> > On Tue, Sep 27, 2016 at 7:25 PM, Vladimir Ozerov 
> > wrote:
> >
> > > Igniters,
> > >
> > > Currently we have about 60-70 test suites on Team City. When I look at
> > > results I see this:
> > >
> > > Ignite 150 Clients -> 1 test -> 6m
> > > Ignite AWS -> 10 tests -> 11m
> > > Ignite GCE -> 1 test -> 3m
> > > Ignite Geospacial Indexing -> 11 tests -> 4m
> > > Ignite IGFS Examples -> 1 test -> 3m
> > > Ignite Logging -> 1 test -> 3m
> > >
> > > Etc.
> > >
> > > It is natural to split tests by their modules. But in this case we
> spend
> > > most of the time on compiling the project over and over again just to
> run
> > > several tests. It consumes lots of TeamCity resources. Both CPU for
> > > compilation, and disk for logs.
> > >
> > > I think we can safely merge all these tine suites into one single suite
> > and
> > > call it "Ignite Integrations". This will save us a lot of time.
> > >
> > > Note that I mean not each and every integration module, but only
> modules
> > > where we have no more than a 1-2 dozens of tests.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>

[GitHub] ignite pull request #1123: Ignite 3978

[devozerov]

GitHub user devozerov opened a pull request:

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

Ignite 3978



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

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

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

https://github.com/apache/ignite/pull/1123.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 #1123


commit 29acb33293c3d3130e16b7ff4d6b7ae260b7b78b
Author: Alexey Kuznetsov 
Date:   2016-09-27T10:15:38Z

Fixed typos.

commit c2a3f11ca14cf9f9cf5bd2d6e2a87764f7cda5a7
Author: Andrey Martianov 
Date:   2016-09-20T14:41:49Z

ignite-3621 Use single ttl cleanup worker thread for all caches

(cherry picked from commit 1bc6058)

commit 39fc5477c19cbe2b2116aaf575a2d0a9c9a618b1
Author: tledkov-gridgain 
Date:   2016-09-27T11:48:18Z

IGNITE-3639: IGFS: Removed BufferedOutputStream from 
LocalIgfsSecondaryFileSystem because it doesn't give any performance benefit.

commit 5cffd3c3d6cb006e3745c314d6f85a066e6a0f06
Author: vozerov-gridgain 
Date:   2016-09-27T12:13:21Z

IGNITE-3661: First attempt to move ignored and flaky tests into a single 
suite. Applied to web-session module.

commit 0e0f015f3ef6233f91c27e08e1ff296becbab93a
Author: vozerov-gridgain 
Date:   2016-09-27T12:46:40Z

IGNITE-3978: Processed S3 tests.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-3979) .NET: Reorganize test suites

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3979:
--

 Summary: .NET: Reorganize test suites
 Key: IGNITE-3979
 URL: https://issues.apache.org/jira/browse/IGNITE-3979
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 1.8


Considerations:
* Ignite.NET has core module and a bunch of optional modules (LINQ, ASP.NET, 
NLog, log4net, EntityFramework)
* Good design is to have a separate test project per module
* TeamCity spends considerable amount of time just to build sources (Java build 
takes 4 minutes)

Therefore, we should have separate test modules, but combine some of them on 
TeamCity.

For example, all optional modules can be combined into one TeamCity suite.



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

[jira] [Created] (IGNITE-3978) Process failing AWS tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3978:
---

 Summary: Process failing AWS tests.
 Key: IGNITE-3978
 URL: https://issues.apache.org/jira/browse/IGNITE-3978
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






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

Re: Merge small test suites into one big suite.

[Alexey Kuznetsov]

I would merge them only if they ALL are "green".

or

May be better solution - build ONCE and REUSE binaries for test?



On Tue, Sep 27, 2016 at 7:25 PM, Vladimir Ozerov 
wrote:

> Igniters,
>
> Currently we have about 60-70 test suites on Team City. When I look at
> results I see this:
>
> Ignite 150 Clients -> 1 test -> 6m
> Ignite AWS -> 10 tests -> 11m
> Ignite GCE -> 1 test -> 3m
> Ignite Geospacial Indexing -> 11 tests -> 4m
> Ignite IGFS Examples -> 1 test -> 3m
> Ignite Logging -> 1 test -> 3m
>
> Etc.
>
> It is natural to split tests by their modules. But in this case we spend
> most of the time on compiling the project over and over again just to run
> several tests. It consumes lots of TeamCity resources. Both CPU for
> compilation, and disk for logs.
>
> I think we can safely merge all these tine suites into one single suite and
> call it "Ignite Integrations". This will save us a lot of time.
>
> Note that I mean not each and every integration module, but only modules
> where we have no more than a 1-2 dozens of tests.
>
> Thoughts?
>
> Vladimir.
>



-- 
Alexey Kuznetsov

Merge small test suites into one big suite.

[Vladimir Ozerov]

Igniters,

Currently we have about 60-70 test suites on Team City. When I look at
results I see this:

Ignite 150 Clients -> 1 test -> 6m
Ignite AWS -> 10 tests -> 11m
Ignite GCE -> 1 test -> 3m
Ignite Geospacial Indexing -> 11 tests -> 4m
Ignite IGFS Examples -> 1 test -> 3m
Ignite Logging -> 1 test -> 3m

Etc.

It is natural to split tests by their modules. But in this case we spend
most of the time on compiling the project over and over again just to run
several tests. It consumes lots of TeamCity resources. Both CPU for
compilation, and disk for logs.

I think we can safely merge all these tine suites into one single suite and
call it "Ignite Integrations". This will save us a lot of time.

Note that I mean not each and every integration module, but only modules
where we have no more than a 1-2 dozens of tests.

Thoughts?

Vladimir.

[jira] [Created] (IGNITE-3977) Process failing OSGI tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3977:
---

 Summary: Process failing OSGI tests.
 Key: IGNITE-3977
 URL: https://issues.apache.org/jira/browse/IGNITE-3977
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






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

[jira] [Created] (IGNITE-3976) Process failing SPI tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3976:
---

 Summary: Process failing SPI tests.
 Key: IGNITE-3976
 URL: https://issues.apache.org/jira/browse/IGNITE-3976
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






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

[jira] [Created] (IGNITE-3975) Process failing streamer tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3975:
---

 Summary: Process failing streamer tests.
 Key: IGNITE-3975
 URL: https://issues.apache.org/jira/browse/IGNITE-3975
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






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

[jira] [Created] (IGNITE-3974) Process failing ZooKeeper tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3974:
---

 Summary: Process failing ZooKeeper tests.
 Key: IGNITE-3974
 URL: https://issues.apache.org/jira/browse/IGNITE-3974
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






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

[jira] [Created] (IGNITE-3973) Nodes can form separate clusters with TcpDiscoveryMulticastIpFinder

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-3973:


 Summary: Nodes can form separate clusters with 
TcpDiscoveryMulticastIpFinder
 Key: IGNITE-3973
 URL: https://issues.apache.org/jira/browse/IGNITE-3973
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.7
Reporter: Semen Boikov
Assignee: Semen Boikov
Priority: Critical
 Fix For: 1.8


Currently TcpDiscoveryMulticastIpFinder on start sends mcast address request 
and stops wait when at least one remote address is received.
This scenario is possible:
- 4 nodes start concurrently
- node1 receive first address of node2, node2 from node1
- node3 receive first address of node4, node4 from node3
- node1/node2 and node3/node4 can form separate clusters



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

[jira] [Created] (IGNITE-3972) Continuous query events could be lost on backup node when primary leaves.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3972:
---

 Summary: Continuous query events could be lost on backup node when 
primary leaves.
 Key: IGNITE-3972
 URL: https://issues.apache.org/jira/browse/IGNITE-3972
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Andrew Mashenkov
 Fix For: 1.8


Consider the following scenario:
1) One node in topology;
2) PARTITIONED cache with 1 backup;
3) Continuous query is set on the cache;

If another node joins the cluster, it will handle some updates. If it leaves 
the topology, the first node must flush it's own events from backup queue thus 
ensuring that no events are lost.

But this doesn't happen because 
{{GridContinuousProcessor.addBackupNotification}} method perform lookup only on 
remote infos map, while handler is local and hence located in local infos map.



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

[GitHub] ignite pull request #1122: IGNITE-3957: clear swap space when cache is destr...

[amartianov]

GitHub user amartianov opened a pull request:

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

IGNITE-3957: clear swap space when cache is destroyed



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

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

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

https://github.com/apache/ignite/pull/1122.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 #1122


commit 6e101bda907d0f95bbfb5c9fa1361995fb7eb8bf
Author: Andrey Martianov 
Date:   2016-09-27T09:59:54Z

IGNITE-3957: clear swap space when cache is destroyed




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1121: Ignite 3597 1

[devozerov]

GitHub user devozerov opened a pull request:

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

Ignite 3597 1



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

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

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

https://github.com/apache/ignite/pull/1121.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 #1121


commit f535b3f9fefbb7d09ec2ef0f4b890cdef3b58449
Author: vozerov-gridgain 
Date:   2016-09-27T08:19:12Z

Added method to calculate work dir.

commit f59dafb4cc5bb22e6c5c6cb7413c83cf53573de9
Author: vozerov-gridgain 
Date:   2016-09-27T08:41:25Z

WIP.

commit e48d54d78e3deffa90cfef9469112c7e82cbc66d
Author: vozerov-gridgain 
Date:   2016-09-27T08:45:55Z

WIP on Hadoop part.

commit b1456188cecb974c7eb6f1d48fa4bfc91722c502
Author: vozerov-gridgain 
Date:   2016-09-27T08:54:43Z

WIP on Hadoop part.

commit e11b641d589f460845135042cb81a91d125f9289
Author: vozerov-gridgain 
Date:   2016-09-27T09:08:20Z

WIP on logger.

commit e2335df2841fd3511aced2d5ee8761bad6b095e3
Author: vozerov-gridgain 
Date:   2016-09-27T09:16:37Z

Work directory support for Hadoop jobs.

commit b80e52d292aa89fd86d985e4d66dd780f70071c1
Author: vozerov-gridgain 
Date:   2016-09-27T10:03:09Z

Removed work dir altogether.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-3971) Web console: Add links to documentaiton on section tooltips

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3971:
-

 Summary: Web console: Add links to documentaiton on section 
tooltips
 Key: IGNITE-3971
 URL: https://issues.apache.org/jira/browse/IGNITE-3971
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.8
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko






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

[GitHub] ignite pull request #1120: ignite-1.7.2

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1120: ignite-1.7.2

[sboikov]

GitHub user sboikov opened a pull request:

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

ignite-1.7.2



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

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

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

https://github.com/apache/ignite/pull/1120.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 #1120


commit 5ff9e5e8c95ea0fe37d281a7ff46e148469f952a
Author: Saikat Maitra 
Date:   2016-09-26T22:28:51Z

IGNITE-3807 IgniteSpiContext registers message listeners incorrectly




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-3970) .NET: Cyrillic 'C' letter in code

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3970:
--

 Summary: .NET: Cyrillic 'C' letter in code
 Key: IGNITE-3970
 URL: https://issues.apache.org/jira/browse/IGNITE-3970
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.7
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.8


The following places have Cyrillic 'C' instead of English 'C' in code:

* СlusterNodeFilterApplyCallbackDelegate
* СlusterNodeFilterApply
* Comments in ICompute



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

[GitHub] ignite pull request #1119: GG-11547 - RWLock tags

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

GG-11547 - RWLock tags



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

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

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

https://github.com/apache/ignite/pull/1119.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 #1119


commit d05b0798061bcda82d4c53f1da069d60b8d4d255
Author: Alexey Goncharuk 
Date:   2016-08-29T10:30:00Z

DB-X - Improved test for BPlusTree

commit 119a934d9023ba0910b74c352446eb2b5ffc0364
Author: EdShangGG 
Date:   2016-08-29T12:53:40Z

Merge remote-tracking branch 'ignite-gg/ignite-db-x' into GG-11422

commit ced571761c49a12d2cda5e993e7968b8a41edd90
Author: Alexey Goncharuk 
Date:   2016-08-29T14:56:50Z

DB-X - Improved test for BPlusTree

commit 96893ae0d857f700a0f0337868adbbfa32d0cb08
Author: sboikov 
Date:   2016-08-29T10:48:45Z

ignite-db-x-free

commit 744b47530a390858051679f46c6a8f9292bef36d
Author: Ilya Lantukh 
Date:   2016-08-29T15:58:44Z

gg-11429 : WIP.

commit eb043450ac67fb51c5275d71982951a7b44c9392
Author: sboikov 
Date:   2016-08-29T20:10:22Z

ignite-db-x-free

commit aa35d593108e8f70c676422204841f664dc6a96a
Author: sboikov 
Date:   2016-08-30T06:43:12Z

Merge remote-tracking branch 'remotes/community/ignite-db-x' into 
ignite-db-x-gg-11133

commit ff8aade442c70b4a4c5b466d5774bd51ebf8228a
Author: sboikov 
Date:   2016-08-30T06:46:45Z

ignite-db-x-gg-11133

commit bce50acab2451d9eb71cf817749d690d0cf6af34
Author: sboikov 
Date:   2016-08-30T06:48:44Z

Merge remote-tracking branch 'remotes/community/ignite-db-x' into 
ignite-gg-11428

commit f9f52111753938e6851e1e258c89e6a04fec3a50
Author: Alexey Goncharuk 
Date:   2016-08-30T07:27:34Z

Merge branch 'ignite-gg-11336' of https://github.com/gridgain/apache-ignite 
into ignite-gg-11336

commit d07a98fae2cc4f90c34c96e9838b5ccaaaeb073d
Author: Alexey Goncharuk 
Date:   2016-08-30T07:31:31Z

Merge ignite-gg-11336 into ignite-db-x

commit 773206adcc7fb7b1e3edcc634a0b57af50b07e48
Author: sboikov 
Date:   2016-08-30T07:33:23Z

Merge remote-tracking branch 'remotes/community/ignite-db-x' into 
ignite-db-x-free1

commit 8164491ec7aac142f5f6e9bdef7b79d654a35e66
Author: Sergi Vladykin 
Date:   2016-08-30T07:41:16Z

ignite-db-x - test for tree

commit b6abe05878b13256b9ff3804865b45164a7b2b40
Author: Alexey Goncharuk 
Date:   2016-08-30T07:49:14Z

Merge branch 'ignite-db-x' of https://github.com/gridgain/apache-ignite 
into ignite-db-x-gg-11133

commit 72ff74be3efcfe4ddf8bf657217b580c19a0cd5c
Author: Alexey Goncharuk 
Date:   2016-08-30T09:47:51Z

DB-X - Fixed data streamer hanging

commit 43295a6b7791deced1fd8dc74348ad160e24f563
Author: EdShangGG 
Date:   2016-08-30T10:10:07Z

Merge remote-tracking branch 'ignite-gg/ignite-db-x' into GG-11422

commit f24648cad7d89f5cda4d4bfea08029c5af311d6b
Author: Alexey Goncharuk 
Date:   2016-08-30T10:41:17Z

Merge branch ignite-db-x into ignite-gg-10882

commit c1394cdfcfb6f605db3e7258fbcf5b60092c5906
Author: Sergi Vladykin 
Date:   2016-08-30T11:47:33Z

Merge branch 'ignite-db-x' of https://github.com/gridgain/apache-ignite 
into ignite-db-x

commit f9b2211c7bf5054985fc5e34a157c53f87703785
Author: Alexey Goncharuk 
Date:   2016-08-30T13:10:23Z

Merge branch ignite-gg-11133 into ignite-db-x

commit 6c368f88c36d1779ef7af7ea6f8b946ee71b8929
Author: EdShangGG 
Date:   2016-08-30T13:37:54Z

GG-11422 Implement page checksums for page store
-minor changes

commit 585f468c1e9270e2fd898aeab6bbd490db8650d6
Author: Alexey Goncharuk 
Date:   2016-08-30T13:53:56Z

Merge branch ignite-db-x into ignite-gg-11428

commit b1b67041ea8c136ae6b50dba0ccee9132877b14b
Author: Ilya Lantukh 
Date:   2016-08-30T13:57:35Z

gg-11429 : WIP.

commit 121d2c44fa6a5e1f64597e085fbf138524145dea
Author: Alexey Goncharuk 
Date:   2016-08-30T14:34:06Z

Added test + minors changes.

commit 686181a7a873fe56efdddbeb67d1368f3eb60f70
Author: Alexey Goncharuk 
Date:   2016-08-30T14:51:46Z

Merge branch 'ignite-db-x' of https://github.com/gridgain/apache-ignite 
into ignite-gg-10882

commit 

[GitHub] ignite pull request #1118: Ignite 3235

[anton-vinogradov]

GitHub user anton-vinogradov opened a pull request:

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

Ignite 3235



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

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

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

https://github.com/apache/ignite/pull/1118.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 #1118


commit 150e0d3b3ab1b01483b5e44ff28198a51fa35e68
Author: vozerov-gridgain 
Date:   2016-06-02T08:47:38Z

IGNITE-3228: Minor fix.

commit 0d623830e0d67be5f0874f704155367d2d9de45b
Author: vozerov-gridgain 
Date:   2016-06-05T17:57:15Z

IGFS-3246: IGFS: Infrastructure for client optimizations.

commit 14c80a162419931f589f23dae60f2590f0f425a6
Author: vozerov-gridgain 
Date:   2016-06-05T18:19:40Z

Merge remote-tracking branch 'upstream/gridgain-7.6.1' into gridgain-7.6.1

commit fdc3aa6e6f1f163351ef1200e18faed7db96d218
Author: vozerov-gridgain 
Date:   2016-06-05T18:00:53Z

IGNITE-3247: IGFS:  Optimized non-stream client operations.

commit 6f99b14ea00bd99ec07014f4cda3f43edc562da7
Author: vozerov-gridgain 
Date:   2016-06-05T18:04:03Z

IGNITE-3248: Optimized fileIds() usage.

commit dc34b6f11b1b850ad6cdfcaa3d34e27e9c6deebf
Author: Denis Magda 
Date:   2016-06-06T07:31:59Z

IGNITE-3240: fixed serialization of String and other primitive arrays by 
CacheObjectBinaryProcessorImpl

(cherry picked from commit 9e9252c2e4ed7380b3933909ac297f6618708980)

commit 3d3bf080bbb5d5a35a9a6cb641a7b1b11867b538
Author: vozerov-gridgain 
Date:   2016-06-06T07:36:26Z

IGNITE-3247: IGFS:  Minor fixes after merge.

commit 4799b2601e5928bbb6854f462ae02a6f8935852d
Author: vozerov-gridgain 
Date:   2016-06-06T07:36:45Z

Merge remote-tracking branch 'upstream/gridgain-7.6.1' into gridgain-7.6.1

commit 4e82af8a57d7a627e4d019273f8c5a40574694d3
Author: sboikov 
Date:   2016-06-06T11:23:02Z

ignite-3212 More debug logging on exchange timeout. Fixed issue in 
GridCacheTxRecoveryFuture with message send failure and late discovery event.

commit 4804db9ca806ee7c743f5f54d6eac37163513759
Author: vozerov-gridgain 
Date:   2016-06-06T12:40:59Z

IGNITE-3256: IGFS: Removed "exists" check during input stream close.

commit d4046dc46c0b6e4f122ef45147dd44c09e4c283c
Author: vozerov-gridgain 
Date:   2016-06-06T12:50:13Z

IGNITE-3257: IGFS: FileSystemConfiguration.DFLT_INIT_DFLT_PATH_MODES has 
been changed to "false".

commit 3cabdcf026fd528fdae305ec2ed832d6ad603cb0
Author: vozerov-gridgain 
Date:   2016-06-06T14:50:58Z

IGNITE-3258: IGFS: Secondary file system input stream is opened only when 
it is really needed.

commit 33b0eb24dc7daebc13c07eb967e5b4ed7171ae55
Author: vozerov-gridgain 
Date:   2016-06-06T15:10:36Z

IGNITE-3259: Delete worker is not started on client nodes any more.

commit a60bb3b658bb6d4688e07e0e4d07aff6a976c6a3
Author: vozerov-gridgain 
Date:   2016-06-08T11:54:37Z

Merge remote-tracking branch 'upstream/gridgain-7.6.1' into gridgain-7.6.1

commit c300448b94ed0d3f847197d1bbe67c31165c6ae6
Author: vozerov-gridgain 
Date:   2016-06-06T15:12:42Z

IGNITE-3260: IGFS: Delete messages are no longer passed.

commit 4273950458a9bb2f83d5fc0489da49aa1fa1dfaf
Author: vozerov-gridgain 
Date:   2016-06-08T08:50:22Z

IGNITE-3274: Hadoop: Fixed NPE in BasicUserNameMapper.

commit 177ebd5c75b38e772e8889fa3589d86ab3fa8f70
Author: vozerov-gridgain 
Date:   2016-06-08T11:41:49Z

IGNITE-3264: IGFS: Reworked output stream.

commit 7761e5f573d9f39b5cc542f3d67bacab4e66609a
Author: vozerov-gridgain 
Date:   2016-06-08T12:13:33Z

IGNITE-3264: IGFS: Reworked output stream.

commit 17020cc81edbb6a75b45f35bdbb28c70c951a667
Author: Igor 
Date:   2016-06-09T23:38:41Z

IGNITE-3238 Javadoc Warning due to cassandra libs usage

commit 2040c3dda9dd5b4796797ed37a0fc01890dcb861
Author: Vladislav Pyatkov 
Date:   2016-06-13T10:13:54Z

IGNITE-2616 - NonHeap memory usage metrics don't work as expected.
Reviewed and merged by Denis Magda.

commit 320c1aafdaaa0b5325f32566cb48fcbef455f69d
Author: MaBiao 
Date:   2016-06-13T10:39:37Z

IGNITE-3304: Fix parameter error in class GridServiceProcessor.
Reviewed and merged by Denis Magda.

commit 4f8ba17b412af8d32812ffba39e7dc2a2326ecf8
Author: Kristian Rosenvold 
Date:   2016-06-13T11:32:20Z

Mysql support broken in 

[jira] [Created] (IGNITE-3969) Hadoop: Add installation instructions for MapR to readme.io.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3969:
---

 Summary: Hadoop: Add installation instructions for MapR to 
readme.io.
 Key: IGNITE-3969
 URL: https://issues.apache.org/jira/browse/IGNITE-3969
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.8






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