[jira] [Created] (IGNITE-7818) Incorrect assertion in PDS page eviction method

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-7818:
-

 Summary: Incorrect assertion in PDS page eviction method
 Key: IGNITE-7818
 URL: https://issues.apache.org/jira/browse/IGNITE-7818
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksey Plekhanov


There is assertion in the method 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#removePageForReplacement:

 
{code:java}
assert relRmvAddr != INVALID_REL_PTR;{code}
Which seems potentially dangerous. In some rare cases, when count of 
interations more then 40% of allocated pages and all processed pages are 
aquired, the {{relRmvAddr}} variable will be uninitialized and 
{{AssertionException}} will be thrown. But it's a correct case and page to 
evict can be found later in the method {{tryToFindSequentially.}}

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7817) Spark 'close' API call hangs when executed within ignite service grid component

[Akshay Mhetre (JIRA)]

Akshay Mhetre created IGNITE-7817:
-

 Summary: Spark 'close' API call hangs when executed within ignite 
service grid component
 Key: IGNITE-7817
 URL: https://issues.apache.org/jira/browse/IGNITE-7817
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Akshay Mhetre


I am running a sprak job within ignite service grid. After job is done I am 
calling close() on spark session. This is working for stable version of 
ignite i.e. 2.3.0. However, its not working with 2.5.0-SNAPSHOT version. 
Please check detailed logs on this link : 

[http://apache-ignite-users.70518.x6.nabble.com/Spark-close-API-call-hangs-within-ignite-service-grid-td20252.html|http://example.com]
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-7816:
---

 Summary: DataFrame examples: wrong folder, hidden on TeamCity
 Key: IGNITE-7816
 URL: https://issues.apache.org/jira/browse/IGNITE-7816
 Project: Ignite
  Issue Type: Sub-task
  Components: documentation
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.4


1. Spark DataFrame examples are in 
{{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should be 
moved to {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.

2. Spark DataFrame examples not tested on Team City under Ignite Examples. 

https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Shipping SQL script + CSV files in Ignite examples

[Denis Magda]

Igniters,

To demonstrate Ignite SQL capabilities at different events, I usually:

   1. take an SQL script
   2. preload the data from the script with SQLLine tool that is already
   shipped in Ignite
   3. run DML operations from Web Console, code or other SQL tools

While SQLLine tool is available once Ignite is downloaded, the user has
to look for a sample SQL script and adapt it to Ignite SQL specification
(mostly DDL).

Let's ship a script or two in Ignite "examples" folder to facilitate the
user. In general, I would add :

   - DDL + DML script (.sql) that creates a schema and preloads data with
   INSERTS. The script will include a command that turns on/off the streaming
   mode that is in the development.
   - DDL script + CSV file with data. This set of scripts are useful for
   COPY command that should be supported soon.

Presently, I would definitely recommend to include the script below that
represents a world database of Cities and Countries. It shows how to define
affinity collocation, how to use Ignite WITH statement, etc:
https://github.com/dmagda/ignite_world_demo/blob/master/ignite_world.sql

Parts of this database are already in use in our SQL getting started.

As for CSV,  we can take that Cities+Countries files and convert INSERT
commands to CSV records.

Thoughts, ideas?

--
Denis

[jira] [Created] (IGNITE-7815) IgniteSpringBean implements SmartInitializingSingleton in version 2.3.2+

[Valeri Chibaev (JIRA)]

Valeri Chibaev created IGNITE-7815:
--

 Summary: IgniteSpringBean implements SmartInitializingSingleton in 
version 2.3.2+
 Key: IGNITE-7815
 URL: https://issues.apache.org/jira/browse/IGNITE-7815
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Valeri Chibaev


IgniteSpringBean changed the way it starts Ignite grid:
 * implements InitializingBean#afterPropertiesSet in version 2.3.1
 * implements SmartInitializingSingleton#afterSingletonsInstantiated in version 
2.3.2+

This cause problem in my code that uses spring cache 
@org.springframework.cache.annotation.Cacheable via 
org.apache.ignite.cache.spring.SpringCacheManager throwing error from spring 
bean initialisation:

 
{code:java}
Caused by: org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 'cacheManager' defined in class path resource 
[spring-inc-cache.xml]: Invocation of init method failed; nested exception is 
class org.apache.ignite.IgniteIllegalStateException: Ignite instance with 
provided name doesn't exist. Did you call Ignition.start(..) to start an Ignite 
instance? [name=mktrsk-ignite-grid]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1628)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:351)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
... 27 common frames omitted
Caused by: org.apache.ignite.IgniteIllegalStateException: Ignite instance with 
provided name doesn't exist. Did you call Ignition.start(..) to start an Ignite 
instance? [name=mktrsk-ignite-grid]
at org.apache.ignite.internal.IgnitionEx.grid(IgnitionEx.java:1312) 
~[ignite-core-2.3.3.jar!/:2.3.3]
at org.apache.ignite.Ignition.ignite(Ignition.java:530) 
~[ignite-core-2.3.3.jar!/:2.3.3]
at 
org.apache.ignite.cache.spring.SpringCacheManager.afterPropertiesSet(SpringCacheManager.java:328)
 ~[ignite-spring-2.3.3.jar!/:2.3.3]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1687)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1624)
 ~[spring-beans-4.3.9.RELEASE.jar!/:4.3.9.RELEASE]
... 34 common frames omitted
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Genetic algorithms contribution was accepted and to be merged soon

[Denis Magda]

Igniters,

It's a pleasure for me to announce that ASF and Ignite community officially
accepted the genetic algorithms to Ignite machine learning code base:
http://incubator.apache.org/ip-clearance/ga-grid-ignite.html

Thanks to Turik Campbell for the contribution and Ignite ML contributors
and commitors for taking care of the code review.

The code is about to be merged soon. As for know, please help to spread a
word:
https://twitter.com/denismagda/status/968253956286644224

--
Denis

Re: Next Steps: GA Grid: Request to contribute GA library to Apache Ignite

[Denis Magda]

Turik, All,

Congratulations, the vote passed by lazy consensus. Feel free to merge the
pull-request into the main code base. Oleg, Yuri, should help with this.

Ping me once this happens, I would discuss documentation and promotion
related questions.

Please help to brag about this:
https://twitter.com/denismagda/status/968253956286644224

--
Denis


On Fri, Feb 23, 2018 at 2:56 PM, techbysample  wrote:

> Denis,
>
> Great! Thanks for the update.
>
> Best,
> Turik Campbell
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[GitHub] ignite pull request #3447: IGNITE-7329 .NET: Thin client: SSL

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: REST: support getting objects from cache.

[Pavel Tupitsyn]

 > private int orgId;
> public int getOrganizationId() {...}

What an insane naming convention, who would do that? :)

Anyway, JSON field names should match binary metadata.
We have SQL via REST, so users would expect to use the same field names in
binary objects and SQL queries.


On Tue, Feb 27, 2018 at 12:41 AM, Denis Magda  wrote:

> Hi guys,
>
> 1. Alex, the point that Pavel tried to convey is that a user who will
> get/put data using REST doesn't care if the data will be deserialized on
> the server side. It just needs to work. So, the same user shouldn't know
> about the keepBinary parameter, just turn it on for REST protocol by
> default.
>
> 3. Vote for skipping this use case and throw a meaningful exception if it
> occurs so that the user can let us know if there is a demand.
>
>
>
> On Mon, Feb 26, 2018 at 7:12 AM, Alexey Kuznetsov  > wrote:
>
>> Vova, Pavel, Sergey,
>>
>> Thanks for you comments.
>>
>> 1) There one corner case with POJO objects in cache.
>> Binary marshaler convert by fields, not by getters. So if you have
>>
>> class Person {
>>   private int orgId;
>>  ...
>>
>>   public int getOrganizationId() {...}
>> }
>>
>> POJO will be transformed to {"organizationId": 1} JSON
>> binary will be transformed to  {"orgId": 1} JSON
>>
>> So in this case [keepBinary=true|false]  can make sense for end user.
>>
>> We can have keepBinary=true by default, and left an option to user if he
>> needs to transform POJO to JSON for some reason.
>> But I agree that double transformation is just a waste of CPU and memory
>> :)
>>
>> 3) How about to throw exception by default and output "$circular_ref" in
>> case of some option, for example, "allowCircularRefs=true".
>>
>>
>> On Mon, Feb 26, 2018 at 6:39 PM, Sergey Kozlov 
>> wrote:
>>
>> > Vova, Alexey
>> >
>> > 3) The exception is not enough for that case. We should return a proper
>> > error message in the json reply.
>> >
>> > On Mon, Feb 26, 2018 at 2:20 PM, Vladimir Ozerov 
>> > wrote:
>> >
>> > > My 50 cents:
>> > > 1) Agree with Pavel, not need to deserialize at all
>> > > 2) May be you see everything in the upper case because this is how
>> CREATE
>> > > TABLE works - every object name (table name, column name, etc.) are
>> > > converted to upper case by default. This is expected behavior of every
>> > SQL
>> > > engine. If you want to preserve cases please consider using qoutes
>> around
>> > > column names (e.g. CREATE TABLE "myTable"("myColumn" INT PRIMARY KEY).
>> > > 3) I think we should throw an exception in this case - objects with
>> > > recursive dependencies cannot be expressed in text form (whether this
>> is
>> > > XML, JSON or anything else).
>> > >
>> > > On Mon, Feb 26, 2018 at 10:00 AM, Pavel Tupitsyn <
>> ptupit...@apache.org>
>> > > wrote:
>> > >
>> > > > Hi Alexey,
>> > > >
>> > > > 1) IMO for this task you should ALWAYS work in binary mode.
>> > > > What is the use case for deserializing with a real class and then
>> > > > serializing to JSON?
>> > > > Looks like a waste of resources to me.
>> > > >
>> > > > 2) This should not be the case, please re-check your code.
>> > > > Binary meta preserves original case (stores field names as is), just
>> > > > checked this with 2.4 build.
>> > > >
>> > > > 3) JSON serializers typically handle this by adding special fields
>> ($id
>> > > and
>> > > > $ref in Json.NET, for example).
>> > > > But I believe this is a rare use case and can be skipped in initial
>> > > > implementation.
>> > > >
>> > > > Thanks,
>> > > > Pavel
>> > > >
>> > > > On Mon, Feb 26, 2018 at 7:38 AM, Alexey Kuznetsov <
>> > akuznet...@apache.org
>> > > >
>> > > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > I'm working on  IGNITE-7803 REST: Add support to get values
>> inserted
>> > > via
>> > > > > API or SQL[1]
>> > > > >
>> > > > > And found following issues:
>> > > > >
>> > > > > 1. First, if server node that will handle REST request does not
>> have
>> > > > class
>> > > > > of object that we want to get from cache I need to set
>> > > cache.keepBinary()
>> > > > > in order to avoid object deserialization and work directly with
>> > binary
>> > > > > metadata directly.
>> > > > >
>> > > > > But in some cases node could have class in classpath and user may
>> > need
>> > > to
>> > > > > use that class.
>> > > > >
>> > > > > How about to add option "keepBinary=true"  and let user handle
>> this
>> > by
>> > > > > himself?
>> > > > >
>> > > > > 2. Second, in binary metadata all names stored in upper case. So,
>> > > binary
>> > > > > object converted to JSON will be like: {"ID": 1, "NAME": "Alex",
>> > > > "SALARY":
>> > > > > 300}
>> > > > >
>> > > > > It is OK?
>> > > > >
>> > > > > 3. Should we handle circular references in binary objects? If yes,
>> > then
>> > > > > how?
>> > > > >
>> > > > >
>> > > > > [1]   https://issues.apache.org/jira/browse/IGNITE-7803
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > 

Re: MTCGA: Tests of the week

[Denis Magda]

Hi Dmitriy,

Could you share some statistics? How many tests were fixed or merged in
one? Just curiuos.

--
Denis

On Mon, Feb 26, 2018 at 9:36 AM, Dmitry Pavlov 
wrote:

> Hi Folks,
>
> Fixing the tests already brings some results. The number of falling tests
> in a single run was reduced. Thanks to all, especially to Peter Ivanov,
> Alexey Goncharuk, Pavel Kovalenko
>
> There are 4 tickets that were not picked up by community (list at the end
> of letter). Please look through and assign issue if you are able to help
> with this.
>
> Sincerely,
> Dmitriy Pavlov
>
>  - IGNITE-7791 -Ignite Client Nodes: failed test
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> - IGNITE-7789 - Ignite Client Nodes: failed test
> IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()
> - IGNITE-7708 - Ignite Compute has flaky failures in ConfigVariationTests
> - IGNITE-7692 - affinityCall and affinityRun may execute code on backup
> partitions
>

Re: REST: support getting objects from cache.

[Denis Magda]

Hi guys,

1. Alex, the point that Pavel tried to convey is that a user who will
get/put data using REST doesn't care if the data will be deserialized on
the server side. It just needs to work. So, the same user shouldn't know
about the keepBinary parameter, just turn it on for REST protocol by
default.

3. Vote for skipping this use case and throw a meaningful exception if it
occurs so that the user can let us know if there is a demand.



On Mon, Feb 26, 2018 at 7:12 AM, Alexey Kuznetsov 
wrote:

> Vova, Pavel, Sergey,
>
> Thanks for you comments.
>
> 1) There one corner case with POJO objects in cache.
> Binary marshaler convert by fields, not by getters. So if you have
>
> class Person {
>   private int orgId;
>  ...
>
>   public int getOrganizationId() {...}
> }
>
> POJO will be transformed to {"organizationId": 1} JSON
> binary will be transformed to  {"orgId": 1} JSON
>
> So in this case [keepBinary=true|false]  can make sense for end user.
>
> We can have keepBinary=true by default, and left an option to user if he
> needs to transform POJO to JSON for some reason.
> But I agree that double transformation is just a waste of CPU and memory :)
>
> 3) How about to throw exception by default and output "$circular_ref" in
> case of some option, for example, "allowCircularRefs=true".
>
>
> On Mon, Feb 26, 2018 at 6:39 PM, Sergey Kozlov 
> wrote:
>
> > Vova, Alexey
> >
> > 3) The exception is not enough for that case. We should return a proper
> > error message in the json reply.
> >
> > On Mon, Feb 26, 2018 at 2:20 PM, Vladimir Ozerov 
> > wrote:
> >
> > > My 50 cents:
> > > 1) Agree with Pavel, not need to deserialize at all
> > > 2) May be you see everything in the upper case because this is how
> CREATE
> > > TABLE works - every object name (table name, column name, etc.) are
> > > converted to upper case by default. This is expected behavior of every
> > SQL
> > > engine. If you want to preserve cases please consider using qoutes
> around
> > > column names (e.g. CREATE TABLE "myTable"("myColumn" INT PRIMARY KEY).
> > > 3) I think we should throw an exception in this case - objects with
> > > recursive dependencies cannot be expressed in text form (whether this
> is
> > > XML, JSON or anything else).
> > >
> > > On Mon, Feb 26, 2018 at 10:00 AM, Pavel Tupitsyn  >
> > > wrote:
> > >
> > > > Hi Alexey,
> > > >
> > > > 1) IMO for this task you should ALWAYS work in binary mode.
> > > > What is the use case for deserializing with a real class and then
> > > > serializing to JSON?
> > > > Looks like a waste of resources to me.
> > > >
> > > > 2) This should not be the case, please re-check your code.
> > > > Binary meta preserves original case (stores field names as is), just
> > > > checked this with 2.4 build.
> > > >
> > > > 3) JSON serializers typically handle this by adding special fields
> ($id
> > > and
> > > > $ref in Json.NET, for example).
> > > > But I believe this is a rare use case and can be skipped in initial
> > > > implementation.
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Mon, Feb 26, 2018 at 7:38 AM, Alexey Kuznetsov <
> > akuznet...@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm working on  IGNITE-7803 REST: Add support to get values
> inserted
> > > via
> > > > > API or SQL[1]
> > > > >
> > > > > And found following issues:
> > > > >
> > > > > 1. First, if server node that will handle REST request does not
> have
> > > > class
> > > > > of object that we want to get from cache I need to set
> > > cache.keepBinary()
> > > > > in order to avoid object deserialization and work directly with
> > binary
> > > > > metadata directly.
> > > > >
> > > > > But in some cases node could have class in classpath and user may
> > need
> > > to
> > > > > use that class.
> > > > >
> > > > > How about to add option "keepBinary=true"  and let user handle this
> > by
> > > > > himself?
> > > > >
> > > > > 2. Second, in binary metadata all names stored in upper case. So,
> > > binary
> > > > > object converted to JSON will be like: {"ID": 1, "NAME": "Alex",
> > > > "SALARY":
> > > > > 300}
> > > > >
> > > > > It is OK?
> > > > >
> > > > > 3. Should we handle circular references in binary objects? If yes,
> > then
> > > > > how?
> > > > >
> > > > >
> > > > > [1]   https://issues.apache.org/jira/browse/IGNITE-7803
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Apache Ignite 2.4 release

[Denis Magda]

Good question!

We've been waiting for a sign-off from Alexey Goncharuk and Sergey Kozlov
who are benchmarking and trying to address performance issues in
coopeartion.

Guys, please share your results and forecast.

--
Denis

On Sun, Feb 25, 2018 at 12:10 AM, Pavel Tupitsyn 
wrote:

> Igniters,
>
> Any update on the 2.4 release status? Anything else to merge there?
>
> Pavel
>
> On Mon, Feb 19, 2018 at 9:30 PM, Dmitriy Setrakyan 
> wrote:
>
> > On Mon, Feb 19, 2018 at 1:37 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Alex,
> > >
> > > You get me right. DEFAULT -> LOG_ONLY doesn't introduce any dramatic
> > > changes when comparing 2.3 to 2.4 - Ignite was unsafe out of the box in
> > > 2.3, and it is unsafe in 2.4 as well.
> > >
> > > The very problem is that we claim ourselves to be ACID, while in
> reality
> > we
> > > are only "AI" out of the box, because durability is not guaranteed due
> to
> > > zero backups and LOG_ONLY and consistency is not guaranteed due to
> > > PRIMARY_SYNC. Neither Cassandra, nor Mongo or any others claim
> themselves
> > > to be ACID, so it is not valid to refer to their defaults.
> > >
> >
> > Vladimir,
> > Ignite can be fully ACID, but at the same time have non-ACID defaults, as
> > long as we clearly document how to get ACID behavior. I do not see an
> issue
> > with it.
> >
> > D.
> >
>

[GitHub] ignite pull request #1876: IGNITE-4648

[SomeFire]

Github user SomeFire closed the pull request at:

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


---

MTCGA: Tests of the week

[Dmitry Pavlov]

Hi Folks,

Fixing the tests already brings some results. The number of falling tests
in a single run was reduced. Thanks to all, especially to Peter Ivanov,
Alexey Goncharuk, Pavel Kovalenko

There are 4 tickets that were not picked up by community (list at the end
of letter). Please look through and assign issue if you are able to help
with this.

Sincerely,
Dmitriy Pavlov

 - IGNITE-7791 -Ignite Client Nodes: failed test
IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
- IGNITE-7789 - Ignite Client Nodes: failed test
IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()
- IGNITE-7708 - Ignite Compute has flaky failures in ConfigVariationTests
- IGNITE-7692 - affinityCall and affinityRun may execute code on backup
partitions

[GitHub] ignite pull request #3572: IGNITE-7814 returned scala211.library.version par...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-7814 returned scala211.library.version parameter



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

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

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

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


commit 6ed05a814a84f6501dcd515ba6a89edba5303778
Author: Anton Kalashnikov 
Date:   2018-02-26T17:08:07Z

IGNITE-7814 returned scala211.library.version parameter




---

[jira] [Created] (IGNITE-7814) Lost scala211.library.version parameter

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-7814:
-

 Summary: Lost scala211.library.version parameter
 Key: IGNITE-7814
 URL: https://issues.apache.org/jira/browse/IGNITE-7814
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


How we can see in test 
https://ci.ignite.apache.org/viewLog.html?buildId=1109854#testNameId451522206339372479.
 We use

scala211.library.version but I see that some time ago it was renamed to 
scala.library.version at determination place.

I think we can't use scala.library.version parameter and we will should return 
scala211.library.version parameter because it is using at specific place for 
scala2.11 .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7813) Method org/apache/ignite/cache/hibernate/HibernateRegionFactory.start(Lorg/hibernate/boot/spi/SessionFactoryOptions;Ljava/util/Properties;)V is abstract

[Pavan Jadda (JIRA)]

Pavan Jadda created IGNITE-7813:
---

 Summary:  Method 
org/apache/ignite/cache/hibernate/HibernateRegionFactory.start(Lorg/hibernate/boot/spi/SessionFactoryOptions;Ljava/util/Properties;)V
 is abstract
 Key: IGNITE-7813
 URL: https://issues.apache.org/jira/browse/IGNITE-7813
 Project: Ignite
  Issue Type: Bug
  Components: hibernate
Affects Versions: 2.3
Reporter: Pavan Jadda


I am trying to implement Hibernate 2nd level cache with Apache Ignite. For 
this, I used following maven dependency in pom.xml based on Apache Ignite 
[official 
documentation|https://apacheignite-mix.readme.io/docs/hibernate-l2-cache]. I 
get the following exception when I run the application. I use this JHipster, 
Docker, and Apache Ignite. Code uploaded to 
[github|https://github.com/pavankjadda/ApacheIgnite-JHipster-Docker]

 

*Method 
org/apache/ignite/cache/hibernate/HibernateRegionFactory.start(Lorg/hibernate/boot/spi/SessionFactoryOptions;Ljava/util/Properties;)V
 is abstract*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: TeamCity. Ignite RDD tests

[Dmitry Pavlov]

I agree.

Alexey K, what do you think?

Sincerely,
Dmitriy Pavlov

пн, 26 февр. 2018 г. в 19:17, Nikolay Izhikov :

> Hello, Dmitriy.
>
> scalatest-maven-plugin doesn't handle "test" property.
> So when "scala" profile enabled it will execute all Scala Spark tests for
> any test plan.
>
> I propose to hide scalatest plugin declaration into profile "scala-test"
> [1]
>
> And enable it only for specific team city plans.
> I.e "Ignite RDD" and "Ignite RDD spark 2_10".
>
> Thoughts?
>
> [1] https://github.com/apache/ignite/pull/3570
>
> В Пн, 26/02/2018 в 14:35 +0300, Nikolay Izhikov пишет:
> > Hello, Dmitriy.
> >
> > I'm investigate issue and share results later today.
> >
> > В Пн, 26/02/2018 в 11:31 +, Dmitry Pavlov пишет:
> > > Hi Nikolay,
> > >
> > > Are there any news about these tests apperance in suites?
> > >
> > > It seems I've found one more example in
> > >
> https://ci.ignite.apache.org/viewLog.html?buildId=1106598=buildResultsDiv=IgniteTests24Java8_IgniteOSGi
> > > (other
> > > change PR run). I'm not sure that OSGI build configuration is
> appropriate
> > > suite to run these tests.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > чт, 22 февр. 2018 г. в 16:13, Nikolay Izhikov :
> > >
> > > > Dmitriy.
> > > >
> > > > OK, I get it.
> > > >
> > > > Looks like scala-test-plugin I added in IGNITE-7042 doesn't handle
> > > > `-Dtest=XXX` properly.
> > > > I will investigate and fixed it.
> > > >
> > > > В Чт, 22/02/2018 в 10:28 +, Dmitry Pavlov пишет:
> > > > > It seems that tests I've previously muted were started in wrong
> configs.
> > > > >
> > > > > Is it possible IgniteRDDSpec.IgniteRDD  became unit tests, which is
> > > >
> > > > started
> > > > > with code compile?
> > > > >
> > > > > This can be reason these tests appeared in suites which is not
> related to
> > > > > IgniteRDD, such as Scala Examples.
> > > > >
> > > > > чт, 22 февр. 2018 г. в 13:20, Nikolay Izhikov  >:
> > > > >
> > > > > > Hello, Dmitriy
> > > > > >
> > > > > > I'm looked in TeamCity but not sure what should I do.
> > > > > > Can you explain it to me, please?
> > > > > >
> > > > > > В Чт, 22/02/2018 в 10:13 +, Dmitry Pavlov пишет:
> > > > > > > Hi Nikolay,
> > > > > > >
> > > > > > > It seems
> > > > > > > IgniteRDDSpec.IgniteRDD  has appeared in configurations it is
> not
> > > > > >
> > > > > > expected
> > > > > > > to run.
> > > > > > >
> > > > > > > Please see investigations assigned to you. What can we change
> to
> > > >
> > > > avoid
> > > > > > > these tests to be included into run other suites?
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > пт, 16 февр. 2018 г. в 7:35, Nikolay Izhikov <
> nizhi...@apache.org>:
> > > > > > >
> > > > > > > > Hello, Igniters.
> > > > > > > >
> > > > > > > > I'm working on issue [1].
> > > > > > > >
> > > > > > > > Team City doesn't collect info about scalatest execution
> because of
> > > > > >
> > > > > > wrong
> > > > > > > > pom.xml
> > > > > > > > I'm fixed it in PR [3]
> > > > > > > >
> > > > > > > > It happens there is a 2 broken tests written in Scala - [4]
> > > > > > > >
> > > > > > > > 1. IgniteRDDSpec.IgniteRDD should successfully store data to
> ignite
> > > > > >
> > > > > > using
> > > > > > > > saveValues
> > > > > > > > 2. IgniteRDDSpec.IgniteRDD should successfully store data to
> ignite
> > > > > >
> > > > > > using
> > > > > > > > saveValues with inline transformation
> > > > > > > >
> > > > > > > > It seems they are been here for a while.
> > > > > > > > I propose to mute or disable it on TeamCity before merging
> my PR.
> > > > > > > > I've created ticket for fixing tests - [5].
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7042
> > > > > > > >
> > > > > > > > [2]
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> https://ci.ignite.apache.org/viewLog.html?buildId=1096059=buildResultsDiv=IgniteTests24Java8_IgniteRdd
> > > > > > > >
> > > > > > > > [3] https://github.com/apache/ignite/pull/3530
> > > > > > > >
> > > > > > > > [4]
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> https://ci.ignite.apache.org/viewLog.html?buildId=1095218=IgniteTests24Java8_IgniteRdd=testsInfo
> > > > > > > >
> > > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-7727

[GitHub] ignite pull request #3571: IGNITE-7531: Implemented copy, insert, batched in...

[pavel-kuznetsov]

GitHub user pavel-kuznetsov opened a pull request:

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

IGNITE-7531: Implemented copy, insert, batched insert benchmarks

https://issues.apache.org/jira/browse/IGNITE-7531

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

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

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

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


commit 4b2078a06230b921e19e9ac6912d93f48adae037
Author: Pavel Kuznetsov 
Date:   2018-02-07T14:39:18Z

IGNITE-7253: Implemented total time probe

commit ef4ac90ffa1141e80462aea7b6024477583e52b0
Author: Pavel Kuznetsov 
Date:   2018-02-08T16:12:59Z

IGNITE-7253: Implemented simple insert benchmark for upload

commit 31056439f36b5ffeebd45f2140c3750afb9a104e
Author: Pavel Kuznetsov 
Date:   2018-02-09T18:58:50Z

IGNITE-7253: Assert results of TotalTimeProbe is correct

commit d6e1e3f7d76cf612574d5b7e756fd01d0c161c90
Author: Pavel Kuznetsov 
Date:   2018-02-09T18:59:47Z

IGNITE-7253: Batch insert upload benchmark draft

commit 5175d69e5cbb6bc050dd87ccc213d526a40d61fa
Author: Pavel Kuznetsov 
Date:   2018-02-09T19:01:15Z

IGNITE-7253: Add missed configs for upload benchmarks

commit 53e3e58f69261361f7d50695f72aa42c91bfcbd7
Author: Pavel Kuznetsov 
Date:   2018-02-12T11:11:34Z

IGNITE-7253: add batch size parameter (sqlRange);
renamed total size parameter (sqlRange -> range)

commit 998c8f44a432f92c595d37ccacd160d007048311
Author: Pavel Kuznetsov 
Date:   2018-02-12T16:01:32Z

IGNITE-7253: moved queries to separated class; changed table schema

commit 400f564c011362acf151ecdc304ab5a021a69be6
Author: Pavel Kuznetsov 
Date:   2018-02-12T18:47:46Z

IGNITE-7253: renamed configuration names

commit 8727fc47e8dd7796e3df5e070bd9890708664e66
Author: Pavel Kuznetsov 
Date:   2018-02-13T14:10:24Z

Merge remote-tracking branch 'origin/master' into IGNITE-7531

commit 056e97c512ac35ef826eddcb360dd97bf41917be
Author: Pavel Kuznetsov 
Date:   2018-02-13T15:27:12Z

IGNITE-7253: added init method, added comment

commit eae7018b17f7dfc626b7159a38afcf95ac585913
Author: Pavel Kuznetsov 
Date:   2018-02-14T11:39:15Z

IGNITE-7253: added csv copy benchmark, updated comments

commit 3029cb55faeddcb4fa940a9f1592653d90853b7d
Author: Pavel Kuznetsov 
Date:   2018-02-14T14:56:54Z

IGNITE-7253: use full sync and 10M inserts, added configuration for csv
benchmark

commit f1f2f53837e52f4ca5400c94f8131878724419f5
Author: Pavel Kuznetsov 
Date:   2018-02-14T16:21:57Z

Merge remote-tracking branch 'origin/master' into IGNITE-7531

commit e1a91f9547c82ac622a2392e4b352de82d062d67
Author: Pavel Kuznetsov 
Date:   2018-02-15T14:31:58Z

IGNITE-7253: Don't place csv file in tmpfs; Added comments

commit 8ae1e8b95a7d4beb58af25bb08d26c60dfb7c6f2
Author: Pavel Kuznetsov 
Date:   2018-02-15T14:33:27Z

IGNITE-7253: Create table using thin driver

commit db68c889f9673543508f75b1d3470cbf6869f37f
Author: Pavel Kuznetsov 
Date:   2018-02-15T14:44:53Z

Merge remote-tracking branch 'origin/master' into IGNITE-7531
brings fixes for COPY command can't find table

commit 801cb9c6293308508c5929096ad5448e8c20fdff
Author: Pavel Kuznetsov 
Date:   2018-02-15T17:06:55Z

IGNITE-7253: updated configuration

commit b834f43bcdcaa08d501a512bc1d74974e82e7331
Author: Pavel Kuznetsov 
Date:   2018-02-20T11:22:32Z

IGNITE-7253: added persistence config;
added activation in base class

commit 0250b365384cab0ad8fdd581c6c7d6286f823aed
Author: Pavel Kuznetsov 
Date:   2018-02-20T12:08:43Z

IGNITE-7253: added combo configurations

commit 2b798df53160b66fc1e83708169349520b029f81
Author: Pavel Kuznetsov 
Date:   2018-02-20T12:10:09Z

IGNITE-7253: cosmetic changes

commit 934ea7275fc54b3f0e98665e3325b97aa6ce23bf
Author: Pavel Kuznetsov 
Date:   2018-02-20T13:52:42Z

IGNITE-7253: force drop and create table before test

commit 2a1580c88bcec009773c9aa9f5ae4c7b10767a9f
Author: Pavel Kuznetsov 
Date:   2018-02-20T18:45:13Z

IGNITE-7253: option to temporally disable wall while uploading;
fixed configuration

commit 7194461a25c1dfa4da37b8030f1a434395418849
Author: Pavel Kuznetsov 
Date:   2018-02-21T15:03:28Z

Merge remote-tracking branch 'origin/master' into IGNITE-7531

commit e28f2ab9d53e4f53aa4266ece7d81b74bd5bf0cd
Author: Pavel Kuznetsov 
Date:   2018-02-21T15:06:56Z

IGNITE-7253: added warmup logging

commit 

Re: TeamCity. Ignite RDD tests

[Nikolay Izhikov]

Hello, Dmitriy.

scalatest-maven-plugin doesn't handle "test" property.
So when "scala" profile enabled it will execute all Scala Spark tests for any 
test plan.

I propose to hide scalatest plugin declaration into profile "scala-test" [1]

And enable it only for specific team city plans.
I.e "Ignite RDD" and "Ignite RDD spark 2_10".

Thoughts?

[1] https://github.com/apache/ignite/pull/3570

В Пн, 26/02/2018 в 14:35 +0300, Nikolay Izhikov пишет:
> Hello, Dmitriy.
> 
> I'm investigate issue and share results later today.
> 
> В Пн, 26/02/2018 в 11:31 +, Dmitry Pavlov пишет:
> > Hi Nikolay,
> > 
> > Are there any news about these tests apperance in suites?
> > 
> > It seems I've found one more example in
> > https://ci.ignite.apache.org/viewLog.html?buildId=1106598=buildResultsDiv=IgniteTests24Java8_IgniteOSGi
> > (other
> > change PR run). I'm not sure that OSGI build configuration is appropriate
> > suite to run these tests.
> > 
> > Sincerely,
> > Dmitriy Pavlov
> > 
> > чт, 22 февр. 2018 г. в 16:13, Nikolay Izhikov :
> > 
> > > Dmitriy.
> > > 
> > > OK, I get it.
> > > 
> > > Looks like scala-test-plugin I added in IGNITE-7042 doesn't handle
> > > `-Dtest=XXX` properly.
> > > I will investigate and fixed it.
> > > 
> > > В Чт, 22/02/2018 в 10:28 +, Dmitry Pavlov пишет:
> > > > It seems that tests I've previously muted were started in wrong configs.
> > > > 
> > > > Is it possible IgniteRDDSpec.IgniteRDD  became unit tests, which is
> > > 
> > > started
> > > > with code compile?
> > > > 
> > > > This can be reason these tests appeared in suites which is not related 
> > > > to
> > > > IgniteRDD, such as Scala Examples.
> > > > 
> > > > чт, 22 февр. 2018 г. в 13:20, Nikolay Izhikov :
> > > > 
> > > > > Hello, Dmitriy
> > > > > 
> > > > > I'm looked in TeamCity but not sure what should I do.
> > > > > Can you explain it to me, please?
> > > > > 
> > > > > В Чт, 22/02/2018 в 10:13 +, Dmitry Pavlov пишет:
> > > > > > Hi Nikolay,
> > > > > > 
> > > > > > It seems
> > > > > > IgniteRDDSpec.IgniteRDD  has appeared in configurations it is not
> > > > > 
> > > > > expected
> > > > > > to run.
> > > > > > 
> > > > > > Please see investigations assigned to you. What can we change to
> > > 
> > > avoid
> > > > > > these tests to be included into run other suites?
> > > > > > 
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > > 
> > > > > > пт, 16 февр. 2018 г. в 7:35, Nikolay Izhikov :
> > > > > > 
> > > > > > > Hello, Igniters.
> > > > > > > 
> > > > > > > I'm working on issue [1].
> > > > > > > 
> > > > > > > Team City doesn't collect info about scalatest execution because 
> > > > > > > of
> > > > > 
> > > > > wrong
> > > > > > > pom.xml
> > > > > > > I'm fixed it in PR [3]
> > > > > > > 
> > > > > > > It happens there is a 2 broken tests written in Scala - [4]
> > > > > > > 
> > > > > > > 1. IgniteRDDSpec.IgniteRDD should successfully store data to 
> > > > > > > ignite
> > > > > 
> > > > > using
> > > > > > > saveValues
> > > > > > > 2. IgniteRDDSpec.IgniteRDD should successfully store data to 
> > > > > > > ignite
> > > > > 
> > > > > using
> > > > > > > saveValues with inline transformation
> > > > > > > 
> > > > > > > It seems they are been here for a while.
> > > > > > > I propose to mute or disable it on TeamCity before merging my PR.
> > > > > > > I've created ticket for fixing tests - [5].
> > > > > > > 
> > > > > > > Thoughts?
> > > > > > > 
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7042
> > > > > > > 
> > > > > > > [2]
> > > > > > > 
> > > > > 
> > > > > 
> > > 
> > > https://ci.ignite.apache.org/viewLog.html?buildId=1096059=buildResultsDiv=IgniteTests24Java8_IgniteRdd
> > > > > > > 
> > > > > > > [3] https://github.com/apache/ignite/pull/3530
> > > > > > > 
> > > > > > > [4]
> > > > > > > 
> > > > > 
> > > > > 
> > > 
> > > https://ci.ignite.apache.org/viewLog.html?buildId=1095218=IgniteTests24Java8_IgniteRdd=testsInfo
> > > > > > > 
> > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-7727

signature.asc
Description: This is a digitally signed message part

[GitHub] ignite pull request #3570: Introduce scala-test profile to hide scalatest-ma...

[nizhikov]

GitHub user nizhikov opened a pull request:

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

Introduce scala-test profile to hide scalatest-maven-plugin.



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

$ git pull https://github.com/nizhikov/ignite scala-test-profile

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

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


commit adf769dc5aecd8ec2d6ee814e9e0f3948d33ec88
Author: Nikolay Izhikov 
Date:   2018-02-26T16:13:42Z

Introduce scala-test profile to hide scalatest-maven-plugin.




---

[jira] [Created] (IGNITE-7812) Slow rebalancing in case of enabled persistence

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7812:


 Summary: Slow rebalancing in case of enabled persistence
 Key: IGNITE-7812
 URL: https://issues.apache.org/jira/browse/IGNITE-7812
 Project: Ignite
  Issue Type: Task
Reporter: Alexey Goncharuk


A user reported that rebalancing take significantly larger amounts of time when 
persistence is enabled even in LOG_ONLY mode.

Need to investigate how the performance of rebalancing may be increased.

Also, it would be great to estimate the benefit of file transfer for 
rebalancing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #2773: IGNITE-6005: Add ability to close datastructure i...

[nizhikov]

Github user nizhikov closed the pull request at:

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


---

Re: REST: support getting objects from cache.

[Alexey Kuznetsov]

Vova, Pavel, Sergey,

Thanks for you comments.

1) There one corner case with POJO objects in cache.
Binary marshaler convert by fields, not by getters. So if you have

class Person {
  private int orgId;
 ...

  public int getOrganizationId() {...}
}

POJO will be transformed to {"organizationId": 1} JSON
binary will be transformed to  {"orgId": 1} JSON

So in this case [keepBinary=true|false]  can make sense for end user.

We can have keepBinary=true by default, and left an option to user if he
needs to transform POJO to JSON for some reason.
But I agree that double transformation is just a waste of CPU and memory :)

3) How about to throw exception by default and output "$circular_ref" in
case of some option, for example, "allowCircularRefs=true".


On Mon, Feb 26, 2018 at 6:39 PM, Sergey Kozlov  wrote:

> Vova, Alexey
>
> 3) The exception is not enough for that case. We should return a proper
> error message in the json reply.
>
> On Mon, Feb 26, 2018 at 2:20 PM, Vladimir Ozerov 
> wrote:
>
> > My 50 cents:
> > 1) Agree with Pavel, not need to deserialize at all
> > 2) May be you see everything in the upper case because this is how CREATE
> > TABLE works - every object name (table name, column name, etc.) are
> > converted to upper case by default. This is expected behavior of every
> SQL
> > engine. If you want to preserve cases please consider using qoutes around
> > column names (e.g. CREATE TABLE "myTable"("myColumn" INT PRIMARY KEY).
> > 3) I think we should throw an exception in this case - objects with
> > recursive dependencies cannot be expressed in text form (whether this is
> > XML, JSON or anything else).
> >
> > On Mon, Feb 26, 2018 at 10:00 AM, Pavel Tupitsyn 
> > wrote:
> >
> > > Hi Alexey,
> > >
> > > 1) IMO for this task you should ALWAYS work in binary mode.
> > > What is the use case for deserializing with a real class and then
> > > serializing to JSON?
> > > Looks like a waste of resources to me.
> > >
> > > 2) This should not be the case, please re-check your code.
> > > Binary meta preserves original case (stores field names as is), just
> > > checked this with 2.4 build.
> > >
> > > 3) JSON serializers typically handle this by adding special fields ($id
> > and
> > > $ref in Json.NET, for example).
> > > But I believe this is a rare use case and can be skipped in initial
> > > implementation.
> > >
> > > Thanks,
> > > Pavel
> > >
> > > On Mon, Feb 26, 2018 at 7:38 AM, Alexey Kuznetsov <
> akuznet...@apache.org
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm working on  IGNITE-7803 REST: Add support to get values inserted
> > via
> > > > API or SQL[1]
> > > >
> > > > And found following issues:
> > > >
> > > > 1. First, if server node that will handle REST request does not have
> > > class
> > > > of object that we want to get from cache I need to set
> > cache.keepBinary()
> > > > in order to avoid object deserialization and work directly with
> binary
> > > > metadata directly.
> > > >
> > > > But in some cases node could have class in classpath and user may
> need
> > to
> > > > use that class.
> > > >
> > > > How about to add option "keepBinary=true"  and let user handle this
> by
> > > > himself?
> > > >
> > > > 2. Second, in binary metadata all names stored in upper case. So,
> > binary
> > > > object converted to JSON will be like: {"ID": 1, "NAME": "Alex",
> > > "SALARY":
> > > > 300}
> > > >
> > > > It is OK?
> > > >
> > > > 3. Should we handle circular references in binary objects? If yes,
> then
> > > > how?
> > > >
> > > >
> > > > [1]   https://issues.apache.org/jira/browse/IGNITE-7803
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > >
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-7811) ODBC: Implement connection fail over

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-7811:
---

 Summary: ODBC: Implement connection fail over
 Key: IGNITE-7811
 URL: https://issues.apache.org/jira/browse/IGNITE-7811
 Project: Ignite
  Issue Type: Bug
Reporter: Igor Sapego






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3569: IGNITE-7809 : Fixed tests.

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-7809 : Fixed tests.



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

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

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

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


commit 4925ffc10ce8e8287980eaec38b587512568a302
Author: Alexey Goncharuk 
Date:   2018-01-17T12:26:03Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in PageSnapshot

commit bcd68a058683b2f17b7ac60471b6e7aab3e4f6de
Author: Pavel Tupitsyn 
Date:   2018-01-17T12:38:20Z

IGNITE-7301 .NET: Baseline topology

This closes #3352

commit 66b96316a7775ce8a6e2ff4475185d5929e4998b
Author: devozerov 
Date:   2018-01-17T12:54:17Z

Merge branch 'master' into ignite-2.4

commit 268481c1cf7fe57df24be130eb67c3e3a13afe01
Author: Alexey Goncharuk 
Date:   2018-01-17T13:50:34Z

IGNITE-7453 Use GridUnsafe.cleanDirectBuffer in WalStat

commit db0cd105719c8ae713b13b34d9dca0a8cd45d377
Author: Pavel Tupitsyn 
Date:   2018-01-17T14:05:25Z

IGNITE-6776 .NET: Thin client: Add SQL & LINQ example

This closes #3390

commit c214db879101aa5660e2a50b11cd20964c0bc114
Author: Andrey Gura 
Date:   2018-01-17T12:42:41Z

ignite-7450 FileWriteAheadLogManager always uses RandomAccessFileIOFactory 
now

commit 75c27d5e49d7458e46eb46e6f87a445c3f1320ea
Author: Alexey Kuznetsov 
Date:   2018-01-18T02:25:19Z

IGNITE-7274 Web Console: Support multiple statements on Queries screen.
(cherry picked from commit 1926783)

commit 36cc822935387b2150e690c29bc6992dca0563f7
Author: Dmitriy Shabalin 
Date:   2018-01-18T04:49:08Z

IGNITE-7306 Web Console: Fixed export data from tables.
(cherry picked from commit 1bb60ec)

commit d753298b4012894b56f5c9218325211cd84a21d5
Author: Peter Ivanov 
Date:   2018-01-18T06:18:53Z

IGNITE-7107 Apache Ignite RPM packages

* added changelog to package specification

This closes #3396

commit 63445893f1bc75dc9777184499f7eabc1d4e51b1
Author: Denis Mekhanikov 
Date:   2018-01-18T08:36:18Z

IGNITE-3935 Use PeerDeployAware for streamer transformer - Fixes #3378.

Signed-off-by: Alexey Goncharuk 

commit f3f9f2a24b23027cf0c835140322e41a788932ae
Author: Pavel Tupitsyn 
Date:   2018-01-18T09:05:12Z

IGNITE-7413 Fix SqlDmlExample

This closes #3389

commit 1daa7c41bf1460a4d9a2b0c26a7a317f2fca3fb7
Author: Alexey Kuznetsov 
Date:   2018-01-18T10:14:53Z

IGNITE-7461 UI tools: Actualized data storage configuration.
(cherry picked from commit 577e632)

commit cf0080210d24d9dd8b057f959446fac5f8a4ca01
Author: dpavlov 
Date:   2018-01-18T10:53:29Z

IGNITE-7380 Implemented pluggable Direct IO - Fixes #3226.

Signed-off-by: Alexey Goncharuk 

commit dd06d0bd7ef266bfbe156e858b312d1ac86e8982
Author: Pavel Tupitsyn 
Date:   2018-01-18T12:55:49Z

IGNITE-7465 .NET: Fix SqlDdlExample failure with standalone node

commit 57479ec564e1761716da3d5f9feb7a64c396a9f9
Author: Pavel Tupitsyn 
Date:   2018-01-18T13:45:54Z

.NET: Fix CacheLocalTest.TestTxDeadlockDetection

commit bd6be8a4653322905a3b63850c7e033ce3801ce5
Author: Pavel Tupitsyn 
Date:   2018-01-18T18:25:05Z

.NET: Thin client: Fix OP_BINARY_TYPE_GET schema passing format

commit 97564d160586d6d57d300937e6b8877994e35fc7
Author: rkondakov 
Date:   2018-01-19T08:24:51Z

IGNITE-6456: Ability to separately enable or disable JDBC, ODBC and thin 
client endpoints. This closes #3309.

commit d50274ca8875c9680c12e8786ac355a787ba95e0
Author: Yakov Zhdanov 
Date:   2018-01-18T17:57:17Z

Javadoc enhancements - added @see

commit cb2d3cf22388ab19fb2d34ae5bdfc8f1b608db75
Author: Dmitriy Govorukhin 
Date:   2018-01-18T14:14:26Z

IGNITE-7471 Use soft reference for checkpoint entry contents to avoid 
excessive memory usage

commit 3965923369870bb4e8e57e3332c1a1eb1e5f5ed3
Author: rkondakov 
Date:   2018-01-19T09:00:55Z

IGNITE-6772: SQL exception messages became more informative. This closes 
#3342.

commit ba68cb0fa87f776fcd0499d030c333f182611f41
Author: devozerov 
Date:   2018-01-19T09:03:52Z

Merge remote-tracking branch 'origin/ignite-2.4' into ignite-2.4

commit b54c0c8786bd74aa0abb208f537c29f0c4be4b1e
Author: tledkov-gridgain 
Date:   2018-01-19T09:09:34Z

IGNITE-7248: JDBC: fixed schema resolution for streaming mode. This 

[GitHub] ignite pull request #3492: IGNITE-7398 Disabled MBean registration for cache...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3502: IGNITE-7632 Fixed NPE in update igfs metrics

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3552: IGNITE-7362: Fixed PDO issue when working with OD...

[isapego]

Github user isapego closed the pull request at:

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


---

Re: REST: support getting objects from cache.

[Sergey Kozlov]

Vova, Alexey

3) The exception is not enough for that case. We should return a proper
error message in the json reply.

On Mon, Feb 26, 2018 at 2:20 PM, Vladimir Ozerov 
wrote:

> My 50 cents:
> 1) Agree with Pavel, not need to deserialize at all
> 2) May be you see everything in the upper case because this is how CREATE
> TABLE works - every object name (table name, column name, etc.) are
> converted to upper case by default. This is expected behavior of every SQL
> engine. If you want to preserve cases please consider using qoutes around
> column names (e.g. CREATE TABLE "myTable"("myColumn" INT PRIMARY KEY).
> 3) I think we should throw an exception in this case - objects with
> recursive dependencies cannot be expressed in text form (whether this is
> XML, JSON or anything else).
>
> On Mon, Feb 26, 2018 at 10:00 AM, Pavel Tupitsyn 
> wrote:
>
> > Hi Alexey,
> >
> > 1) IMO for this task you should ALWAYS work in binary mode.
> > What is the use case for deserializing with a real class and then
> > serializing to JSON?
> > Looks like a waste of resources to me.
> >
> > 2) This should not be the case, please re-check your code.
> > Binary meta preserves original case (stores field names as is), just
> > checked this with 2.4 build.
> >
> > 3) JSON serializers typically handle this by adding special fields ($id
> and
> > $ref in Json.NET, for example).
> > But I believe this is a rare use case and can be skipped in initial
> > implementation.
> >
> > Thanks,
> > Pavel
> >
> > On Mon, Feb 26, 2018 at 7:38 AM, Alexey Kuznetsov  >
> > wrote:
> >
> > > Hi,
> > >
> > > I'm working on  IGNITE-7803 REST: Add support to get values inserted
> via
> > > API or SQL[1]
> > >
> > > And found following issues:
> > >
> > > 1. First, if server node that will handle REST request does not have
> > class
> > > of object that we want to get from cache I need to set
> cache.keepBinary()
> > > in order to avoid object deserialization and work directly with binary
> > > metadata directly.
> > >
> > > But in some cases node could have class in classpath and user may need
> to
> > > use that class.
> > >
> > > How about to add option "keepBinary=true"  and let user handle this by
> > > himself?
> > >
> > > 2. Second, in binary metadata all names stored in upper case. So,
> binary
> > > object converted to JSON will be like: {"ID": 1, "NAME": "Alex",
> > "SALARY":
> > > 300}
> > >
> > > It is OK?
> > >
> > > 3. Should we handle circular references in binary objects? If yes, then
> > > how?
> > >
> > >
> > > [1]   https://issues.apache.org/jira/browse/IGNITE-7803
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: TeamCity. Ignite RDD tests

[Nikolay Izhikov]

Hello, Dmitriy.

I'm investigate issue and share results later today.

В Пн, 26/02/2018 в 11:31 +, Dmitry Pavlov пишет:
> Hi Nikolay,
> 
> Are there any news about these tests apperance in suites?
> 
> It seems I've found one more example in
> https://ci.ignite.apache.org/viewLog.html?buildId=1106598=buildResultsDiv=IgniteTests24Java8_IgniteOSGi
> (other
> change PR run). I'm not sure that OSGI build configuration is appropriate
> suite to run these tests.
> 
> Sincerely,
> Dmitriy Pavlov
> 
> чт, 22 февр. 2018 г. в 16:13, Nikolay Izhikov :
> 
> > Dmitriy.
> > 
> > OK, I get it.
> > 
> > Looks like scala-test-plugin I added in IGNITE-7042 doesn't handle
> > `-Dtest=XXX` properly.
> > I will investigate and fixed it.
> > 
> > В Чт, 22/02/2018 в 10:28 +, Dmitry Pavlov пишет:
> > > It seems that tests I've previously muted were started in wrong configs.
> > > 
> > > Is it possible IgniteRDDSpec.IgniteRDD  became unit tests, which is
> > 
> > started
> > > with code compile?
> > > 
> > > This can be reason these tests appeared in suites which is not related to
> > > IgniteRDD, such as Scala Examples.
> > > 
> > > чт, 22 февр. 2018 г. в 13:20, Nikolay Izhikov :
> > > 
> > > > Hello, Dmitriy
> > > > 
> > > > I'm looked in TeamCity but not sure what should I do.
> > > > Can you explain it to me, please?
> > > > 
> > > > В Чт, 22/02/2018 в 10:13 +, Dmitry Pavlov пишет:
> > > > > Hi Nikolay,
> > > > > 
> > > > > It seems
> > > > > IgniteRDDSpec.IgniteRDD  has appeared in configurations it is not
> > > > 
> > > > expected
> > > > > to run.
> > > > > 
> > > > > Please see investigations assigned to you. What can we change to
> > 
> > avoid
> > > > > these tests to be included into run other suites?
> > > > > 
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > > 
> > > > > пт, 16 февр. 2018 г. в 7:35, Nikolay Izhikov :
> > > > > 
> > > > > > Hello, Igniters.
> > > > > > 
> > > > > > I'm working on issue [1].
> > > > > > 
> > > > > > Team City doesn't collect info about scalatest execution because of
> > > > 
> > > > wrong
> > > > > > pom.xml
> > > > > > I'm fixed it in PR [3]
> > > > > > 
> > > > > > It happens there is a 2 broken tests written in Scala - [4]
> > > > > > 
> > > > > > 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite
> > > > 
> > > > using
> > > > > > saveValues
> > > > > > 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite
> > > > 
> > > > using
> > > > > > saveValues with inline transformation
> > > > > > 
> > > > > > It seems they are been here for a while.
> > > > > > I propose to mute or disable it on TeamCity before merging my PR.
> > > > > > I've created ticket for fixing tests - [5].
> > > > > > 
> > > > > > Thoughts?
> > > > > > 
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7042
> > > > > > 
> > > > > > [2]
> > > > > > 
> > > > 
> > > > 
> > 
> > https://ci.ignite.apache.org/viewLog.html?buildId=1096059=buildResultsDiv=IgniteTests24Java8_IgniteRdd
> > > > > > 
> > > > > > [3] https://github.com/apache/ignite/pull/3530
> > > > > > 
> > > > > > [4]
> > > > > > 
> > > > 
> > > > 
> > 
> > https://ci.ignite.apache.org/viewLog.html?buildId=1095218=IgniteTests24Java8_IgniteRdd=testsInfo
> > > > > > 
> > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-7727

signature.asc
Description: This is a digitally signed message part

Re: TeamCity. Ignite RDD tests

[Dmitry Pavlov]

Hi Nikolay,

Are there any news about these tests apperance in suites?

It seems I've found one more example in
https://ci.ignite.apache.org/viewLog.html?buildId=1106598=buildResultsDiv=IgniteTests24Java8_IgniteOSGi
(other
change PR run). I'm not sure that OSGI build configuration is appropriate
suite to run these tests.

Sincerely,
Dmitriy Pavlov

чт, 22 февр. 2018 г. в 16:13, Nikolay Izhikov :

> Dmitriy.
>
> OK, I get it.
>
> Looks like scala-test-plugin I added in IGNITE-7042 doesn't handle
> `-Dtest=XXX` properly.
> I will investigate and fixed it.
>
> В Чт, 22/02/2018 в 10:28 +, Dmitry Pavlov пишет:
> > It seems that tests I've previously muted were started in wrong configs.
> >
> > Is it possible IgniteRDDSpec.IgniteRDD  became unit tests, which is
> started
> > with code compile?
> >
> > This can be reason these tests appeared in suites which is not related to
> > IgniteRDD, such as Scala Examples.
> >
> > чт, 22 февр. 2018 г. в 13:20, Nikolay Izhikov :
> >
> > > Hello, Dmitriy
> > >
> > > I'm looked in TeamCity but not sure what should I do.
> > > Can you explain it to me, please?
> > >
> > > В Чт, 22/02/2018 в 10:13 +, Dmitry Pavlov пишет:
> > > > Hi Nikolay,
> > > >
> > > > It seems
> > > > IgniteRDDSpec.IgniteRDD  has appeared in configurations it is not
> > >
> > > expected
> > > > to run.
> > > >
> > > > Please see investigations assigned to you. What can we change to
> avoid
> > > > these tests to be included into run other suites?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пт, 16 февр. 2018 г. в 7:35, Nikolay Izhikov :
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I'm working on issue [1].
> > > > >
> > > > > Team City doesn't collect info about scalatest execution because of
> > >
> > > wrong
> > > > > pom.xml
> > > > > I'm fixed it in PR [3]
> > > > >
> > > > > It happens there is a 2 broken tests written in Scala - [4]
> > > > >
> > > > > 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite
> > >
> > > using
> > > > > saveValues
> > > > > 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite
> > >
> > > using
> > > > > saveValues with inline transformation
> > > > >
> > > > > It seems they are been here for a while.
> > > > > I propose to mute or disable it on TeamCity before merging my PR.
> > > > > I've created ticket for fixing tests - [5].
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7042
> > > > >
> > > > > [2]
> > > > >
> > >
> > >
> https://ci.ignite.apache.org/viewLog.html?buildId=1096059=buildResultsDiv=IgniteTests24Java8_IgniteRdd
> > > > >
> > > > > [3] https://github.com/apache/ignite/pull/3530
> > > > >
> > > > > [4]
> > > > >
> > >
> > >
> https://ci.ignite.apache.org/viewLog.html?buildId=1095218=IgniteTests24Java8_IgniteRdd=testsInfo
> > > > >
> > > > > [5] https://issues.apache.org/jira/browse/IGNITE-7727

Re: REST: support getting objects from cache.

[Vladimir Ozerov]

My 50 cents:
1) Agree with Pavel, not need to deserialize at all
2) May be you see everything in the upper case because this is how CREATE
TABLE works - every object name (table name, column name, etc.) are
converted to upper case by default. This is expected behavior of every SQL
engine. If you want to preserve cases please consider using qoutes around
column names (e.g. CREATE TABLE "myTable"("myColumn" INT PRIMARY KEY).
3) I think we should throw an exception in this case - objects with
recursive dependencies cannot be expressed in text form (whether this is
XML, JSON or anything else).

On Mon, Feb 26, 2018 at 10:00 AM, Pavel Tupitsyn 
wrote:

> Hi Alexey,
>
> 1) IMO for this task you should ALWAYS work in binary mode.
> What is the use case for deserializing with a real class and then
> serializing to JSON?
> Looks like a waste of resources to me.
>
> 2) This should not be the case, please re-check your code.
> Binary meta preserves original case (stores field names as is), just
> checked this with 2.4 build.
>
> 3) JSON serializers typically handle this by adding special fields ($id and
> $ref in Json.NET, for example).
> But I believe this is a rare use case and can be skipped in initial
> implementation.
>
> Thanks,
> Pavel
>
> On Mon, Feb 26, 2018 at 7:38 AM, Alexey Kuznetsov 
> wrote:
>
> > Hi,
> >
> > I'm working on  IGNITE-7803 REST: Add support to get values inserted via
> > API or SQL[1]
> >
> > And found following issues:
> >
> > 1. First, if server node that will handle REST request does not have
> class
> > of object that we want to get from cache I need to set cache.keepBinary()
> > in order to avoid object deserialization and work directly with binary
> > metadata directly.
> >
> > But in some cases node could have class in classpath and user may need to
> > use that class.
> >
> > How about to add option "keepBinary=true"  and let user handle this by
> > himself?
> >
> > 2. Second, in binary metadata all names stored in upper case. So, binary
> > object converted to JSON will be like: {"ID": 1, "NAME": "Alex",
> "SALARY":
> > 300}
> >
> > It is OK?
> >
> > 3. Should we handle circular references in binary objects? If yes, then
> > how?
> >
> >
> > [1]   https://issues.apache.org/jira/browse/IGNITE-7803
> >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>

[IGNITE-5714] Design proposal of suspend/resume for pessimistic tx

[Aleksey Kuznetsov]

Hello Igniters!

Currently we have suspension/resuming implemented for optimistic
transactions [1].
Unless suspend/resume isn't supported for pessimistic tx JTA isn't fully
supported [4].

I’m working on a ticket "Suspension/resuming for pessimistic transactions"
[2].
Goal of the ticket is to support transaction suspend/resume for pessimistic
transactions.

# Benefits of suspending/resuming transaction.

  1. Full JTA standart support.
  2. Increase of throughput in high-load scenarios.
  Suspend operation would allow to release Ignite threads and
optionally perform some other logic.

Note, current API has got suspend/resume only for optimistic transactions,
which confuses users.

# Real life example.

Consider the following scenario:

  1. Application starts Ignite transaction.
  2. Business logic is executed inside transaction.
  3. For commit/rollback application need approval message from external
agent.
  4. Currently, thread inside Ignite is idle until approval is received.
  4a. When suspend/resume support is implemented, application can perform
suspend and release thread inside Ignite.

# How pessimistic transaction works.

When we perform put/get operations in pessimistic transactions, lock
request is sent to remote nodes by `GridNearLockRequest`.
Request contains thread id `IgniteTxAdapter#threadId`, in which operation
was performed.
In pessimistic mode, multiple transaction objects are created - on
primary, on backup nodes, and on originating node:
`GridNearTxLocal`, `GridDhtTxLocal`, `GridNearTxRemote`, `GridDhtTxRemote`.

Thread id is used in logic on these nodes.
For instance, to check whether thread has successfully locked the key,
after lock acquisition attempt.
Or to check whether active transaction exists.

# Main challenge for implementation.

I've analysed implementation approaches and see the core issue:

The essential problem with suspending/resuming lies in thread id field
transferred to remote nodes during put/get operations.

Imagine, we want to suspend transaction and resume it in another thread.
See code snippet below:

```
tx = ignite.transactions().txStart(PESSIMISTIC, SERIALIZABLE);

cache.put(1, 1);

tx.suspend();


// In another thread.
tx.resume(); // Thread id will be changed in transaction instance.
```

Original thread id is transferred and saved on remote node.
After resuming thread id on local node differs from remote node.
I want to avoid one more network round trip to change thread Id on remote
node after transaction resuming.

# Design proposal.

Transaction id (`xid`) can be used instead of thread id on remote nodes.
The following solution is possible for the ticket :

Replace thread id by transaction id for sending to remote nodes.
Thread id will be removed from the following classes:
`IgniteTxAdapter`, `GridDistributedTxPrepareRequest`,
`GridDistributedTxFinishRequest`, `GridDistributedTxFinishResponse`,
`GridDistributedTxPrepareRequest`.

I haven't removed thread id completely from code. Thread id is moved to
`GridNearTxLocal`.
We still need it in near local transaction for many reasons, for example to
assure only thread started transaction can suspend it in
`GridNearTxLocal#suspend()`.
In future we can remove thread id completely. I propose to study this
question in another ticket.

Also, thread id is remained in `GridDistributedLockRequest`.
Lock request used by cache locks and it need to transfer thread id to
remote nodes.
For example to use cache locks along with cache operations put/get, see
`GridNearTxLocal#updateExplicitVersion`.
As for pessimistic transaction, thread id in `GridDistributedLockRequest`
is set to `UNDEFINED_THREAD_ID`, which means we must not use it remotely.

Note, that if user suspends transaction and forgets to resume it,
transaction would be rolled back once timeout has occurred.

In my design when transaction is suspended, all locked keys remain locked.

Please see my prototype of proposal implementation [3].

Proposed changes are relatively small.
They ensure consistency of information about locks, if thread Id will be
changed within one transaction (by suspend/resume).
There will be used correct id for locks on remote nodes. It also requires
painstaking work, but changes will not affect the logic of oher components.

Tell me please what do you think? Any suggestions and comments will be
helpful.

If you agree with my design I also will do benchmarking.

[1] https://issues.apache.org/jira/browse/IGNITE-5712
[2] https://issues.apache.org/jira/browse/IGNITE-5714
[3] https://github.com/apache/ignite/pull/2789
[4] Section 3.2.3
http://download.oracle.com/otn-pub/jcp/jta-1.1-spec-oth-JSpec/jta-1_1-spec.pdf
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #3568: Removed default data region creation for client n...

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

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

Removed default data region creation for client nodes.

Added meaningful exception if there's no data region for the cache.

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

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

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

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


commit cf2b82cd884fc87c220f55bf073c9cf11951aafe
Author: mcherkasov 
Date:   2018-02-01T17:12:49Z

Removed default data region creation for client nodes.
Added meaningful exception if there's no data region for the cache.




---

Test testJobIdCollision to use multiple JVMs [IGNITE-4706]

[Maxim Muzafarov]

Hi all,

I'm triyng to clarify for myseft issue [1] of rewriting this test case to
use multiple JVMs. I'm trying to reproduce it using steps described here
[2]:
As I correct understand issue description, I'm runing testJobIdCollision
and expecting to get exception:
"Received computation request with duplicate job ID"
, but I've got:
"Job has already been hold [ctx=GridJobContextImpl
[jobId=f7e74a1d161-08edbe47-9b65-4ed2-8d0c-a8a1a673, timeoutObj=null,
attrs={}]]"

So, does this test-case actual or can be removed? Or we should use
another IgniteCallable
like othis one: IgniteWalRecoveryTest.LoadRunnable [4]?

Also, IgniteClusterProcessProxy#forNodeId [3] doesn't implemented yet.
Brief search for some JIRA's of implementation this method doesn't return
anything.
What should we do with this?



[1] https://issues.apache.org/jira/browse/IGNITE-4706
[2] https://issues.apache.org/jira/browse/IGNITE-1384
[3]
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/multijvm/IgniteClusterProcessProxy.java#L204
[4]
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/wal/IgniteWalRecoveryTest.java#L1552

[jira] [Created] (IGNITE-7810) Web console: replace Roboto slab font with Roboto regular

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-7810:


 Summary: Web console: replace Roboto slab font with Roboto regular
 Key: IGNITE-7810
 URL: https://issues.apache.org/jira/browse/IGNITE-7810
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov


Since the Roboto slab font is considered deprecated, it should be replaced with 
Roboto regular.

What to do:
1. Replace global font on  with Roboto.
2. Look for Roboto slab in other place and remove it too.
3. Remove Roboto slab from dependencies, if applicable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Ignite-7640 Refactor DiscoveryDataClusterState to be immutable (Done)

[Александр Меньшиков]

Hi to all.

I have done issue ignite-7640. Please review.


JIRA: https://issues.apache.org/jira/browse/IGNITE-7640
PR: https://github.com/apache/ignite/pull/3515
TC:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3515%2Fhead
 CR: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-492

[jira] [Created] (IGNITE-7809) Ignite PDS 2 & PDS 2 Direct IO: stable failures of IgniteWalFlushDefaultSelfTest

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-7809:
--

 Summary: Ignite PDS 2 & PDS 2 Direct IO: stable failures of 
IgniteWalFlushDefaultSelfTest
 Key: IGNITE-7809
 URL: https://issues.apache.org/jira/browse/IGNITE-7809
 Project: Ignite
  Issue Type: Task
  Components: persistence
Affects Versions: 2.4
Reporter: Dmitriy Pavlov
Assignee: Ilya Lantukh
 Fix For: 2.5


Probably after last WAL default changes 'IGNITE-7594 Fixed performance drop 
after WAL optimization for FSYNC' 2 tests in 2 build configs began to fail

   Ignite PDS 2 (Direct IO) [ tests 2 ]  
 IgnitePdsNativeIoTestSuite2: 
IgniteWalFlushDefaultSelfTest.testFailAfterStart (fail rate 13,0%) 
 IgnitePdsNativeIoTestSuite2: 
IgniteWalFlushDefaultSelfTest.testFailWhileStart (fail rate 13,0%) 

   Ignite PDS 2 [ tests 2 ]  
 IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailAfterStart 
(fail rate 8,4%) 
 IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailWhileStart 
(fail rate 8,4%) 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3566: Ignite 7686-2: Licenses fix

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-7807) SQL TX: Store lock info inside tuples

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7807:
---

 Summary: SQL TX: Store lock info inside tuples
 Key: IGNITE-7807
 URL: https://issues.apache.org/jira/browse/IGNITE-7807
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov


We need to store lock info inside tuples. Otherwise, touching a lot of entries 
would lead to OOME. Also we should rework our locking logic - instead of trying 
to enlist ourselves in every entry, we should stop on the very first locked 
entry and wait for it's release.

Suggested fix: 
1) Check for {{lock_id}} field of an entry
2) If it is empty, CAS own XID
3) If it is not empty, check fo TX LOG to see if transaction is still active; 
if not - CAS itself
4) If failed to install own version - stop locking and wait for release
5) When transaction commits, no locks are released explicilty. Instead, it is 
responsibility of the next locker to check TX LOG and undesrantnad whether 
entry could be locked or not
6) When lock is acquired, create new version of an entry with lock info



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7806) SQL TX: Backup update protocol

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-7806:
---

 Summary: SQL TX: Backup update protocol
 Key: IGNITE-7806
 URL: https://issues.apache.org/jira/browse/IGNITE-7806
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Vladimir Ozerov


Currently TX SQL protocol works as follows:
1) Lock request is sent to {{PRIMARY}} node where updates are applied 
immediately.
2) Updated values are stored in-memory
3) When commit command is issued, updates are propagated to {{BACKUP}}s.

This requires data to be stored in memory at some point. We should design 
better protocol which will allow for updates to be propagated to backups 
efficiently.

Ticket is related (or may be even duplicates) to IGNITE-7186.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)