[jira] [Created] (IGNITE-7818) Incorrect assertion in PDS page eviction method
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 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 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&page=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
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 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
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
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
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3447 ---
Re: REST: support getting objects from cache.
> 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 >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Alexey Kuznetsov >> > > > > >> > > > >> > > >> > >> > >> > >> > -- >> > Sergey Kozlov
Re: MTCGA: Tests of the week
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.
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
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
Github user SomeFire closed the pull request at: https://github.com/apache/ignite/pull/1876 ---
MTCGA: Tests of the week
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...
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 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 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
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&tab=buildResultsDiv&buildTypeId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgniteRdd > > > > > > > > > > > > > > > > [3] https://github.com/apache/ignite/pull/3530 > > > > > > > > > > > > > > > > [4] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=1095218&buildTypeId=IgniteTests24Java8_IgniteRdd&tab=testsInfo > > > > > > > > > > > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-7727
[GitHub] ignite pull request #3571: IGNITE-7531: Implemented copy, insert, batched in...
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 8f950ff1fbf2b37c4288d4e357f32cdb29dc927b Author: Pavel Kuznetsov Date: 2018-02-23T19:38:34Z IGNITE-7253: Sql data streamer support for upload benchmarks commit 30bfbfa7cae4382d7f7c176506079932695f3a99 Author: Pavel Kuznetsov Date: 2018-02-24T20:14:47Z Merge remote-tracking branch 'origin/master' into IGNITE-7531 commit
Re: TeamCity. Ignite RDD tests
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&tab=buildResultsDiv&buildTypeId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgniteRdd > > > > > > > > > > > > > > [3] https://github.com/apache/ignite/pull/3530 > > > > > > > > > > > > > > [4] > > > > > > > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=1095218&buildTypeId=IgniteTests24Java8_IgniteRdd&tab=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...
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 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...
Github user nizhikov closed the pull request at: https://github.com/apache/ignite/pull/2773 ---
Re: REST: support getting objects from cache.
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 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.
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 closes #3384. commit 2f5997788ccff265a088921210f561985f640517 Author: Dmitriy Govorukhin Date: 2018-01-19T11:46:38Z IGNITE-7471 fix npe commit 7adce10750704cc50cbf54fa7020aa3b20da87cb Author: Oleg Ignatenko Date: 2018-01-19T11:59:01Z IGNITE-7454 Wrong package in IgniteExamplesMLTestSuite this closes #3393 (cherry picked from commit cb1233a) commit 25e91b60694c589
[GitHub] ignite pull request #3492: IGNITE-7398 Disabled MBean registration for cache...
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
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...
Github user isapego closed the pull request at: https://github.com/apache/ignite/pull/3552 ---
Re: REST: support getting objects from cache.
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
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&tab=buildResultsDiv&buildTypeId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgniteRdd > > > > > > > > > > > > [3] https://github.com/apache/ignite/pull/3530 > > > > > > > > > > > > [4] > > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=1095218&buildTypeId=IgniteTests24Java8_IgniteRdd&tab=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
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&tab=buildResultsDiv&buildTypeId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgniteRdd > > > > > > > > > > [3] https://github.com/apache/ignite/pull/3530 > > > > > > > > > > [4] > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=1095218&buildTypeId=IgniteTests24Java8_IgniteRdd&tab=testsInfo > > > > > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-7727
Re: REST: support getting objects from cache.
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
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...
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]
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 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&branch_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 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)
[jira] [Created] (IGNITE-7808) Automate Docker images build
Peter Ivanov created IGNITE-7808: Summary: Automate Docker images build Key: IGNITE-7808 URL: https://issues.apache.org/jira/browse/IGNITE-7808 Project: Ignite Issue Type: Improvement Reporter: Peter Ivanov Assignee: Peter Ivanov Introduce and document process and tools for automated Docked images build based on release tag. Include both Ignite and Web Console images. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #3566: Ignite 7686-2: Licenses fix
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 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 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)