[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374603#comment-17374603 ] Ivan Pavlukhin commented on IGNITE-12401: - [~atri], by mistake I assigned this ticket to myself. Unnasigned now. Feel free to assign it to yourself. Also I suggest to start (or resume) a discussion thread on d...@ignite.apache.org. The ticket looks abandoned and it is worth refreshing text queries track with the community. > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Atri Sharma >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12401: --- Assignee: (was: Ivan Pavlukhin) > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12401: --- Assignee: Ivan Pavlukhin (was: Yuriy Shuliha ) > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Ivan Pavlukhin >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374579#comment-17374579 ] Ivan Pavlukhin commented on IGNITE-12401: - Sorry, I cannot help here. So far from context =( > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Yuriy Shuliha >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-14172) Cool drawing ideas with pencil sketching
[ https://issues.apache.org/jira/browse/IGNITE-14172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin closed IGNITE-14172. --- Ignite Flags: (was: Docs Required,Release Notes Required) > Cool drawing ideas with pencil sketching > > > Key: IGNITE-14172 > URL: https://issues.apache.org/jira/browse/IGNITE-14172 > Project: Ignite > Issue Type: Bug > Environment: Cool drawing idea is one of the best channels for > amazing cool drawing ideas! This channel is created to provide you with the > most stunning and **[cool drawing > ideas|https://cooldrawingidea.com/cool-drawing-ideas-with-pencil-sketching/]. > We make videos on pencil sketch drawing, drawing nature and landscape, > drawing tutorials for beginners, 3d drawing, drawing animals, drawing > flowers, drawing birds, Drawing for kids, and Cartoon drawings. >Reporter: Cool drawing idea >Priority: Major > > **[Cool drawing idea|http://https://cooldrawingidea.com/] is one of the best > channels for amazing cool drawing ideas! This channel is created to provide > you with the most stunning and cool drawing ideas. We make videos on pencil > sketch drawing, drawing nature and landscape, drawing tutorials for > beginners, 3d drawing, drawing animals, drawing flowers, drawing birds, > Drawing for kids, and Cartoon drawings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14172) Cool drawing ideas with pencil sketching
[ https://issues.apache.org/jira/browse/IGNITE-14172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-14172. - Resolution: Invalid Closing this one as some kind of spam. > Cool drawing ideas with pencil sketching > > > Key: IGNITE-14172 > URL: https://issues.apache.org/jira/browse/IGNITE-14172 > Project: Ignite > Issue Type: Bug > Environment: Cool drawing idea is one of the best channels for > amazing cool drawing ideas! This channel is created to provide you with the > most stunning and **[cool drawing > ideas|https://cooldrawingidea.com/cool-drawing-ideas-with-pencil-sketching/]. > We make videos on pencil sketch drawing, drawing nature and landscape, > drawing tutorials for beginners, 3d drawing, drawing animals, drawing > flowers, drawing birds, Drawing for kids, and Cartoon drawings. >Reporter: Cool drawing idea >Priority: Major > > **[Cool drawing idea|http://https://cooldrawingidea.com/] is one of the best > channels for amazing cool drawing ideas! This channel is created to provide > you with the most stunning and cool drawing ideas. We make videos on pencil > sketch drawing, drawing nature and landscape, drawing tutorials for > beginners, 3d drawing, drawing animals, drawing flowers, drawing birds, > Drawing for kids, and Cartoon drawings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13623) Scaladoc not created during release process
[ https://issues.apache.org/jira/browse/IGNITE-13623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276953#comment-17276953 ] Ivan Pavlukhin commented on IGNITE-13623: - [~timonin.maksim], thank you for your effort! Figures look very promising to me but unfortunately I cannot do thorough review so far. I hope folks will step in. > Scaladoc not created during release process > --- > > Key: IGNITE-13623 > URL: https://issues.apache.org/jira/browse/IGNITE-13623 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.8, 2.9, 2.8.1 >Reporter: Aleksey Plekhanov >Assignee: Maksim Timonin >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > Scaladoc creation is broken (probably by IGNITE-11933). We have 3 release > assemblies without scaladoc now (2.8, 2.8.1, 2.9). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13623) Scaladoc not created during release process
[ https://issues.apache.org/jira/browse/IGNITE-13623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272964#comment-17272964 ] Ivan Pavlukhin commented on IGNITE-13623: - [~timonin.maksim], thank you for investigating this! I do not remember all details. I suppose there were issues with other jobs using different profile combinations. They were unable to proceed due to unneeded (for them) scaladoc step. Or perhaps the goal was to reduce build time. Is it really to good to create javadocs on _prepare-package_ phase? I would think about javadocs creation when some kind of _release_ profile is active. > Scaladoc not created during release process > --- > > Key: IGNITE-13623 > URL: https://issues.apache.org/jira/browse/IGNITE-13623 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.8, 2.9, 2.8.1 >Reporter: Aleksey Plekhanov >Assignee: Maksim Timonin >Priority: Blocker > > Scaladoc creation is broken (probably by IGNITE-11933). We have 3 release > assemblies without scaladoc now (2.8, 2.8.1, 2.9). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13903) Python thin client tests automation.
[ https://issues.apache.org/jira/browse/IGNITE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1728#comment-1728 ] Ivan Pavlukhin commented on IGNITE-13903: - [~ivandasch], thank you for including these changes. > Python thin client tests automation. > > > Key: IGNITE-13903 > URL: https://issues.apache.org/jira/browse/IGNITE-13903 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Attachments: .asf.yaml > > Time Spent: 10m > Remaining Estimate: 0h > > It would be nice to futher improve our development process of > python-thin-client > 1. Add docker-compose.yml to simplify local development > 2. Add tox.ini to simplify test running automation > 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13903) Python thin client tests automation.
[ https://issues.apache.org/jira/browse/IGNITE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254766#comment-17254766 ] Ivan Pavlukhin commented on IGNITE-13903: - [~ivandasch], I attached a minimal config file [^.asf.yaml]. Exact content might be updated if needed (e.g. description, homepage and labels). > Python thin client tests automation. > > > Key: IGNITE-13903 > URL: https://issues.apache.org/jira/browse/IGNITE-13903 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Attachments: .asf.yaml > > > It would be nice to futher improve our development process of > python-thin-client > 1. Add docker-compose.yml to simplify local development > 2. Add tox.ini to simplify test running automation > 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13903) Python thin client tests automation.
[ https://issues.apache.org/jira/browse/IGNITE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-13903: Attachment: .asf.yaml > Python thin client tests automation. > > > Key: IGNITE-13903 > URL: https://issues.apache.org/jira/browse/IGNITE-13903 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Attachments: .asf.yaml > > > It would be nice to futher improve our development process of > python-thin-client > 1. Add docker-compose.yml to simplify local development > 2. Add tox.ini to simplify test running automation > 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13903) Python thin client tests automation.
[ https://issues.apache.org/jira/browse/IGNITE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254586#comment-17254586 ] Ivan Pavlukhin commented on IGNITE-13903: - [~ivandasch], it is out of scope, but could you add .asf.yaml to this repo redirecting PR notifications? I added one for ignite-3 repo recently https://github.com/apache/ignite-3/blob/main/.asf.yaml as was discussed in http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Notifications-for-ignite-3-repository-td50725.html If you think that it is not good idea to do it in this ticket I will think about other option then. > Python thin client tests automation. > > > Key: IGNITE-13903 > URL: https://issues.apache.org/jira/browse/IGNITE-13903 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > > It would be nice to futher improve our development process of > python-thin-client > 1. Add docker-compose.yml to simplify local development > 2. Add tox.ini to simplify test running automation > 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13875) Configure notifications for ignite-3 git repository
[ https://issues.apache.org/jira/browse/IGNITE-13875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17253381#comment-17253381 ] Ivan Pavlukhin commented on IGNITE-13875: - Hi [~slava.koptilin]! Thank you for your review! Merged to ignite-3 main branch. > Configure notifications for ignite-3 git repository > --- > > Key: IGNITE-13875 > URL: https://issues.apache.org/jira/browse/IGNITE-13875 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 3.0 > > > Currently notifications for PRs in https://github.com/apache/ignite-3 > repository are sent to dev-list. Notifications can be configured similarly to > https://github.com/apache/ignite repository. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13875) Configure notifications for ignite-3 git repository
[ https://issues.apache.org/jira/browse/IGNITE-13875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251548#comment-17251548 ] Ivan Pavlukhin commented on IGNITE-13875: - .asf.yaml was added specifying destination mail lists for notifications. > Configure notifications for ignite-3 git repository > --- > > Key: IGNITE-13875 > URL: https://issues.apache.org/jira/browse/IGNITE-13875 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > Currently notifications for PRs in https://github.com/apache/ignite-3 > repository are sent to dev-list. Notifications can be configured similarly to > https://github.com/apache/ignite repository. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13875) Configure notifications for ignite-3 git repository
[ https://issues.apache.org/jira/browse/IGNITE-13875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-13875: --- Assignee: Ivan Pavlukhin > Configure notifications for ignite-3 git repository > --- > > Key: IGNITE-13875 > URL: https://issues.apache.org/jira/browse/IGNITE-13875 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > Currently notifications for PRs in https://github.com/apache/ignite-3 > repository are sent to dev-list. Notifications can be configured similarly to > https://github.com/apache/ignite repository. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13875) Configure notifications for ignite-3 git repository
Ivan Pavlukhin created IGNITE-13875: --- Summary: Configure notifications for ignite-3 git repository Key: IGNITE-13875 URL: https://issues.apache.org/jira/browse/IGNITE-13875 Project: Ignite Issue Type: Task Components: general Reporter: Ivan Pavlukhin Currently notifications for PRs in https://github.com/apache/ignite-3 repository are sent to dev-list. Notifications can be configured similarly to https://github.com/apache/ignite repository. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13436) Custom BinaryIdMapper is not working
[
https://issues.apache.org/jira/browse/IGNITE-13436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194268#comment-17194268
]
Ivan Pavlukhin commented on IGNITE-13436:
-
I suppose it is better to use originally reported ticket
https://issues.apache.org/jira/browse/IGNITE-13415
> Custom BinaryIdMapper is not working
>
>
> Key: IGNITE-13436
> URL: https://issues.apache.org/jira/browse/IGNITE-13436
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Evgeniy Rudenko
>Priority: Major
>
> {color:#1d1c1d}Custom BinaryIdMapper will not be used for
> org.apache.ignite.internal.binary.BinaryContext#createField unless cache.put
> operation was called before it. This happens because typeId2Mapper is not
> filled otherwise. {color}
> {color:#1d1c1d}[http://apache-ignite-users.70518.x6.nabble.com/Unable-to-read-fields-value-from-BinaryObject-td33925.html]{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13290) SpringTransactionManager adds support for REQUIRES_NEW transaction propagation
[ https://issues.apache.org/jira/browse/IGNITE-13290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-13290: Summary: SpringTransactionManager adds support for REQUIRES_NEW transaction propagation (was: SpringTransactionManager adds support for nested transactions) > SpringTransactionManager adds support for REQUIRES_NEW transaction propagation > -- > > Key: IGNITE-13290 > URL: https://issues.apache.org/jira/browse/IGNITE-13290 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8.1 >Reporter: YuJue Li >Priority: Minor > Fix For: 2.10 > > > If the transaction propagation of the outer method is REQUIRED, the > transaction propagation of the inner method is REQUIRES_NEW, the following > error will be prompted: > org.springframework.transaction.TransactionSuspensionNotSupportedException: > Transaction manager > [org.apache.ignite.transactions.spring.SpringTransactionManager] does not > support transaction suspension > But we see, Ignite's org.apache.ignite.transactions.Transaction, there are > suspend() and resume() methods, and the function is normal, so > SpringTransactionManager should support similar functions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13290) SpringTransactionManager adds support for nested transactions
[ https://issues.apache.org/jira/browse/IGNITE-13290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163251#comment-17163251 ] Ivan Pavlukhin commented on IGNITE-13290: - Hi [~liyuj], issue summary confuses with [NESTED|https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Propagation.html#NESTED] transaction propagation. But as I see from description the issue is mostly about REQUIRES_NEW support. I suggest to rename it to "SpringTransactionManager adds support for REQUIRES_NEW transaction propagation". What do you think? > SpringTransactionManager adds support for nested transactions > - > > Key: IGNITE-13290 > URL: https://issues.apache.org/jira/browse/IGNITE-13290 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8.1 >Reporter: YuJue Li >Priority: Minor > Fix For: 2.10 > > > If the transaction propagation of the outer method is REQUIRED, the > transaction propagation of the inner method is REQUIRES_NEW, the following > error will be prompted: > org.springframework.transaction.TransactionSuspensionNotSupportedException: > Transaction manager > [org.apache.ignite.transactions.spring.SpringTransactionManager] does not > support transaction suspension > But we see, Ignite's org.apache.ignite.transactions.Transaction, there are > suspend() and resume() methods, and the function is normal, so > SpringTransactionManager should support similar functions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin resolved IGNITE-12003.
-
Resolution: Duplicate
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer [^ThinClientCompactFooterDeserializationProblem.java].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125189#comment-17125189
]
Ivan Pavlukhin commented on IGNITE-13094:
-
[~ilyak], the patch looks good.
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Class locally deployed: class
> com.sonic.sample.springboot.controller.WebController
> 2020-05-28 07:00:48.890 WARN 8460 --- [p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback
> java.lang.ClassNotFoundException: ch.qos.logback
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_121]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_121]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> ~[na:1.8.0_121]
> at java.lang.C
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124222#comment-17124222
]
Ivan Pavlukhin commented on IGNITE-13094:
-
[~ilyak], the patch definitely makes things better and consequently can be
merged.
Still I suspect one potential problem (which existed before). From the code I
see that a case when a received class name does not ends with ".class" is legal
as well. And if we have a class named "org.example.classic.Foo" (not ending
with ".class") then it will be trimmed to "org.example". Perhaps a following
check could be more universal:
{code:java}
String className = ...;
if (className.endsWith(".class")) {
className = className.substring(0, className.length() - ".class".length());
}
{code}
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Cla
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123530#comment-17123530
]
Ivan Pavlukhin commented on IGNITE-13094:
-
Hi [~AK47Sonic],
I guess that server startup procedure matters here (binary distribution in your
case and Java code in my). And it turns out that Ilya caught the cause. But why
log classes need to be loaded remotely in the described case is not clear for
me (it still might be a technical detail I do not understand).
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Class locally deployed: class
> com.sonic.sample.springboot.controller.WebController
> 2020-05-28 07:00:48.890 WARN 8460 --- [p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback
> java.lang.ClassNotFoundException: ch.qos.logback
> at java.net.URLClassLoader.findCl
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17121062#comment-17121062
]
Ivan Pavlukhin commented on IGNITE-13094:
-
[~AK47Sonic], thank you for sharing the code. I tried to launch it and
everything worked fine. One unclear thing is how the Ignite server (or cluster)
is started and configured. I used the same xml config as _default-config.xml_
with enabled server mode.
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Priority: Major
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Class locally deployed: class
> com.sonic.sample.springboot.controller.WebController
> 2020-05-28 07:00:48.890 WARN 8460 --- [p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback
> java.lang.ClassNotFoundException: ch.qos.logback
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_121]
> at java.lang.ClassLoader.loadClass(ClassLoader.j
[jira] [Commented] (IGNITE-13094) java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
[
https://issues.apache.org/jira/browse/IGNITE-13094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120980#comment-17120980
]
Ivan Pavlukhin commented on IGNITE-13094:
-
[~AK47Sonic], lombok _provided_ scope in pom.xml looks suspicious to me. Can we
be really sure that logback is on classpath?
> java.lang.ClassNotFoundException: ch.qos.logback for distributed compute
>
>
> Key: IGNITE-13094
> URL: https://issues.apache.org/jira/browse/IGNITE-13094
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8.1
> Environment: Ignite 2.8.0
> Spring Boot 2.1.0.RELEASE
> Java 1.8
>Reporter: AK47Sonic
>Priority: Major
>
> I try to use spring boot (2.1.0.RELEASE) to run ignite.compute. As spring
> boot + lombok use logback as default, the following codes always throw
> exceptions (2020-05-28 07:00:48.979 WARN 8460 --- [ p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback). The result (28) could be returned. Seems we see log4j and
> log4j2 on official website. I try to use log4j2 to replace logback. And it
> works fine. Does ignite support logback for distributed compute? Or It is
> just a bug?
> {panel:title=pom.xml}
>
>
> org.springframework.boot
> spring-boot-starter-web
>
>
> org.springframework.boot
> spring-boot-starter-log4j
>
>
>
>
> org.apache.ignite
> ignite-core
> 2.8.0
>
>
> org.apache.ignite
> ignite-spring
> 2.8.0
>
>
> org.projectlombok
> lombok
> 1.18.12
> provided
>
>
> {panel}
> {panel:title=config.xml}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:util="http://www.springframework.org/schema/util";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:48500..48520
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
> {panel}
> {code:java}
> @Configuration
> @ImportResource(locations={"classpath:default-config.xml"})
> public class IgniteConfig {
> @Bean
> public Ignite ignite(IgniteConfiguration igniteConfiguration) {
> Ignite ignite = Ignition.start(igniteConfiguration);
> Ignition.setClientMode(true);
> return ignite;
> }
> }
> @Slf4j
> @RestController
> public class WebController {
> @Autowired
> private Ignite ignite;
> @GetMapping("/compute")
> public void compute() {
> Collection> calls = new ArrayList<>();
> // Iterate through all the words in the sentence and create Callable
> jobs.
> for (final String word : "Count characters using callable".split(" "))
> calls.add(word::length);
> // Execute collection of Callables on the grid.
> Collection res = ignite.compute().call(calls);
> // Add up all the results.
> int sum = res.stream().mapToInt(Integer::intValue).sum();
> log.info("Total number of characters is '" + sum + "'.");
> }
> }
> {code}
> {panel:title=Exception}
> 2020-05-28 07:00:48.786 INFO 8460 --- [nio-8080-exec-1]
> o.a.i.i.m.d.GridDeploymentLocalStore : Class locally deployed: class
> com.sonic.sample.springboot.controller.WebController
> 2020-05-28 07:00:48.890 WARN 8460 --- [p2p-#49]
> o.a.i.i.m.d.GridDeploymentCommunication : Failed to resolve class:
> ch.qos.logback
> java.lang.ClassNotFoundException: ch.qos.logback
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_121]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_121]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> ~[na:1.8.0_121]
> at java.lang
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118447#comment-17118447 ] Ivan Pavlukhin commented on IGNITE-10959: - [~mmuzaf], unfortunately I cannot help with GG tickets nowadays. [~jooger], [~tledkov-gridgain], [~amashenkov] possibly can help here. > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12999) Fix broken ZookeeperDiscoverySpiSslTest.testIgniteSslWrongPort
[
https://issues.apache.org/jira/browse/IGNITE-12999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12999:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix broken ZookeeperDiscoverySpiSslTest.testIgniteSslWrongPort
> --
>
> Key: IGNITE-12999
> URL: https://issues.apache.org/jira/browse/IGNITE-12999
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.9
>
>
> After merging
> [IGNITE-11094|https://issues.apache.org/jira/browse/IGNITE-11094] in
> {{cloneDiscoverySpi}} input parameter was obtained every time from
> {{getConfiguration()}}, but not from first node, as it should be. This
> behaviour leads to instant failure of multijvm tests
> {{GridCacheAtomicMultiJvmFullApiSelfTest}} and
> {{GridCachePartitionedMultiJvmFullApiSelfTest}}. After merging
> [IGNITE-12992|https://issues.apache.org/jira/browse/IGNITE-12992], this twist
> doesn't work and configuration cloned from first node, as it should. So we
> must set zk connection string explicitly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12993) Github notification integrations on new ASF infra feature
[
https://issues.apache.org/jira/browse/IGNITE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104230#comment-17104230
]
Ivan Pavlukhin commented on IGNITE-12993:
-
I suppose we can tweak GitHub labels later on easily.
> Github notification integrations on new ASF infra feature
> -
>
> Key: IGNITE-12993
> URL: https://issues.apache.org/jira/browse/IGNITE-12993
> Project: Ignite
> Issue Type: Task
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Recent github pull requests are not automatically linked to the jira tickets.
> Infra
> [advises|https://issues.apache.org/jira/browse/INFRA-20177?focusedCommentId=17090758&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17090758]
> creating a yaml configuration in the root of the repository with the
> settings for the github bot.
> Feature description:
> [https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories]
> According to the current github setup, I suggest the following initial
> configuration:
> {code:yaml}
> github:
> description: "Apache Ignite"
> homepage: https://ignite.apache.org/
> labels:
> - distributed-sql-database
> - iot
> - osgi
> - network-client
> - ignite
> - data-management-platform
> - big-data
> - cloud
> - database
> - network-server
> - hadoop
> - sql
> features:
> wiki: false
> issues: false
> projects: false
> enabled_merge_buttons:
> squash: true
> merge: false
> rebase: false
> notifications:
> commits: comm...@ignite.apache.org
> issues: notificati...@ignite.apache.org
> pullrequests: notificati...@ignite.apache.org
> jira_options: link label worklog
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12998) Fix a typo in CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/IGNITE-12998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12998: --- Assignee: Ivan Pavlukhin > Fix a typo in CONTRIBUTING.md > - > > Key: IGNITE-12998 > URL: https://issues.apache.org/jira/browse/IGNITE-12998 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > CoPDoC abbreviation should be spelled properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12998) Fix a typo in CONTRIBUTING.md
Ivan Pavlukhin created IGNITE-12998: --- Summary: Fix a typo in CONTRIBUTING.md Key: IGNITE-12998 URL: https://issues.apache.org/jira/browse/IGNITE-12998 Project: Ignite Issue Type: Task Reporter: Ivan Pavlukhin CoPDoC abbreviation should be spelled properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12976) Invalid SQL syntax for NULLS LAST / NULLS FIRST in IgniteQueryGenerator
[
https://issues.apache.org/jira/browse/IGNITE-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104184#comment-17104184
]
Ivan Pavlukhin commented on IGNITE-12976:
-
[~Kostyuckovich], the fix itself looks good. But there is a couple of moments
specific to Ignite development process which should be addressed:
# Each test class should be added to a test suite to run in CI. Here you can
use
https://github.com/apache/ignite/blob/master/modules/spring-data/src/test/java/org/apache/ignite/testsuites/IgniteSpringDataTestSuite.java
(and counterparts for different spring-data versions).
# Usually patches should be checked with TC bot (https://mtcga.gridgain.com/),
check an
[instruction|https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot#ApacheIgniteTeamcityBot-HowtocheckaPRwiththeTCBot].
Do not hesitate to ask if something is not clear.
> Invalid SQL syntax for NULLS LAST / NULLS FIRST in IgniteQueryGenerator
> ---
>
> Key: IGNITE-12976
> URL: https://issues.apache.org/jira/browse/IGNITE-12976
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.8
>Reporter: Mikhail Kostyuckovich
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite Spring Data's {{IgniteQueryGenerator}} (in all {{spring-data}} /
> {{spring-data-2.0}} / {{spring-data-2.2}} modules) generate invalid SQL when
> null handling other than native is used.
> Currently generated query - invalid:
> {{SELECT ... ORDER BY ... NULL FIRST ...}}
> {{SELECT ... ORDER BY ... NULL LAST ...}}
> Expected - valid:
> {{SELECT ... ORDER BY ... NULL*S* FIRST ...}}
> {{SELECT ... ORDER BY ... NULL*S* LAST ...}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12994) Move binary metadata to PDS storage folder
[
https://issues.apache.org/jira/browse/IGNITE-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104167#comment-17104167
]
Ivan Pavlukhin commented on IGNITE-12994:
-
[~sdanilov], I heard some rumors about moving binary metadata to Ignite
_metastorage_. You might be interested in this
http://apache-ignite-developers.2346864.n4.nabble.com/Asynchronous-registration-of-binary-metadata-td43021.html
> Move binary metadata to PDS storage folder
> --
>
> Key: IGNITE-12994
> URL: https://issues.apache.org/jira/browse/IGNITE-12994
> Project: Ignite
> Issue Type: Improvement
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
>
> Move binary metadata to PDS storage folder
> Motivation: On K8s deployment disk that is attached to container can not be
> accessible from other containers or outside of K8s. In case if support will
> need to drop persistence except data, there will be no way to recover due to
> binary metadata is required to process PDS files
> Current PDS files that are required to restore data:
> * {WORK_DIR}/db/\{nodeId}
> * {WORK_DIR}/db/wal/\{nodeId}
> * {WORK_DIR}/db/wal/archive/\{nodeId}
> Proposed implementation:
> If binary meta is already located at \{WORK_DIR}/db then start using it
> If no metadata been detected via new path then:
> # Check previous location
> # Copy metadata files to a new location
> # Delete previous binary metadata
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12554) Ignite instance couldn't be restarted if it's parent thread group has been called destroy once
[
https://issues.apache.org/jira/browse/IGNITE-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101559#comment-17101559
]
Ivan Pavlukhin commented on IGNITE-12554:
-
[~agoncharuk], I do not mind if you take it over. I have a great deal of doubts
that I will have a time for it in near future.
> Ignite instance couldn't be restarted if it's parent thread group has been
> called destroy once
> --
>
> Key: IGNITE-12554
> URL: https://issues.apache.org/jira/browse/IGNITE-12554
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: ha faculty
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Attachments: NodeRestartTesting.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am using an inhouse platform which manage the life cycle of ignite instance
> by calling ignition.start() and ignition.stop() from a web application.
> it could be started without issue for the first time. however, if it stop the
> ignite by calling ignition.stop() and followed by destroying the parent
> thread group which starting it.
> Calling ignition.start() in the 2nd time will throw the following exception
> Exception in thread "kickOff" java.lang.IllegalThreadStateExceptionException
> in thread "kickOff" java.lang.IllegalThreadStateException at
> java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867) at
> java.lang.Thread.init(Thread.java:405) at
> java.lang.Thread.init(Thread.java:349) at
> java.lang.Thread.(Thread.java:599) at
> org.apache.ignite.thread.IgniteThread.(IgniteThread.java:96) at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.start(StripedExecutor.java:474)
> at
> org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:121)
> at
> org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:80)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1842)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:565) at
> org.apache.ignite.Ignition.start(Ignition.java:305) at
> com.faculty.poc.ignite.app.NodeRestartTesting.run(NodeRestartTesting.java:60)
> at java.lang.Thread.run(Thread.java:748)
> Please find my demo code for this issue.
> Walk through into Ignite code, it should be caused by a static thread group
> created in IgniteThread class. (private static final ThreadGroup DFLT_GRP =
> new ThreadGroup("ignite")
> Destroyed the parent thread group which start the ignite instance will result
> in causing the DFLT_GRP go into destroyed state. Therefore, when Ignite was
> start ifor the 2nd time, this static thread group has been destroyed and no
> longer able to run the ignite.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12987) Remove TC badge from README.md
[ https://issues.apache.org/jira/browse/IGNITE-12987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12987: --- Assignee: Ivan Pavlukhin > Remove TC badge from README.md > -- > > Key: IGNITE-12987 > URL: https://issues.apache.org/jira/browse/IGNITE-12987 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently TC badge in main > [README|https://github.com/apache/ignite/blob/master/README.md] seems to be > not very useful because a build status is not seen directly (is says "no > permissions to get data"). Moreover TC results are not very representative > because integration tests are not stable by nature and we rely on TC bot > checks instead of plain TC status. > Let's remove this badge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12987) Remove TC badge from README.md
Ivan Pavlukhin created IGNITE-12987: --- Summary: Remove TC badge from README.md Key: IGNITE-12987 URL: https://issues.apache.org/jira/browse/IGNITE-12987 Project: Ignite Issue Type: Task Reporter: Ivan Pavlukhin Currently TC badge in main [README|https://github.com/apache/ignite/blob/master/README.md] seems to be not very useful because a build status is not seen directly (is says "no permissions to get data"). Moreover TC results are not very representative because integration tests are not stable by nature and we rely on TC bot checks instead of plain TC status. Let's remove this badge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12980) Use Apache Ignite logo with registered trade mark symbol in README.md
[ https://issues.apache.org/jira/browse/IGNITE-12980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12980: Ignite Flags: (was: Docs Required,Release Notes Required) > Use Apache Ignite logo with registered trade mark symbol in README.md > - > > Key: IGNITE-12980 > URL: https://issues.apache.org/jira/browse/IGNITE-12980 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Logo in the top of https://github.com/apache/ignite/blob/master/README.md > should have registered trademark symbol ® instead of unregistered one ™. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12980) Use Apache Ignite logo with registered trade mark symbol in README.md
Ivan Pavlukhin created IGNITE-12980: --- Summary: Use Apache Ignite logo with registered trade mark symbol in README.md Key: IGNITE-12980 URL: https://issues.apache.org/jira/browse/IGNITE-12980 Project: Ignite Issue Type: Task Reporter: Ivan Pavlukhin Logo in the top of https://github.com/apache/ignite/blob/master/README.md should have registered trademark symbol ® instead of unregistered one ™. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12980) Use Apache Ignite logo with registered trade mark symbol in README.md
[ https://issues.apache.org/jira/browse/IGNITE-12980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12980: --- Assignee: Ivan Pavlukhin > Use Apache Ignite logo with registered trade mark symbol in README.md > - > > Key: IGNITE-12980 > URL: https://issues.apache.org/jira/browse/IGNITE-12980 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > Logo in the top of https://github.com/apache/ignite/blob/master/README.md > should have registered trademark symbol ® instead of unregistered one ™. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12965) Redirect ignite-website GitHub notifications
[ https://issues.apache.org/jira/browse/IGNITE-12965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12965: --- Assignee: Ivan Pavlukhin > Redirect ignite-website GitHub notifications > > > Key: IGNITE-12965 > URL: https://issues.apache.org/jira/browse/IGNITE-12965 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > GitHub notifications for all Ignite repositories are sent to > notificati...@ignite.apache.org after INFRA-17351. But notifications for a > new ignite-website repository (https://github.com/apache/ignite-website) are > sent to d...@ignite.apache.org. These notifications should be sent to > notificati...@ignite.apache.org as well. > Apparently we can solve it on our side by editing .asf.yaml file according to > https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12965) Redirect ignite-website GitHub notifications
[ https://issues.apache.org/jira/browse/IGNITE-12965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12965: Description: GitHub notifications for all Ignite repositories are sent to notificati...@ignite.apache.org after INFRA-17351. But notifications for a new ignite-website repository (https://github.com/apache/ignite-website) are sent to d...@ignite.apache.org. These notifications should be sent to notificati...@ignite.apache.org as well. Apparently we can solve it on our side by editing .asf.yaml file according to https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories was:GitHub notifications for all Ignite repositories are sent to notificati...@ignite.apache.org after INFRA-17351. But notifications for a new ignite-website repository (https://github.com/apache/ignite-website) are sent to d...@ignite.apache.org. These notifications should be sent to notificati...@ignite.apache.org as well. > Redirect ignite-website GitHub notifications > > > Key: IGNITE-12965 > URL: https://issues.apache.org/jira/browse/IGNITE-12965 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Priority: Major > > GitHub notifications for all Ignite repositories are sent to > notificati...@ignite.apache.org after INFRA-17351. But notifications for a > new ignite-website repository (https://github.com/apache/ignite-website) are > sent to d...@ignite.apache.org. These notifications should be sent to > notificati...@ignite.apache.org as well. > Apparently we can solve it on our side by editing .asf.yaml file according to > https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12965) Redirect ignite-website GitHub notifications
Ivan Pavlukhin created IGNITE-12965: --- Summary: Redirect ignite-website GitHub notifications Key: IGNITE-12965 URL: https://issues.apache.org/jira/browse/IGNITE-12965 Project: Ignite Issue Type: Task Reporter: Ivan Pavlukhin GitHub notifications for all Ignite repositories are sent to notificati...@ignite.apache.org after INFRA-17351. But notifications for a new ignite-website repository (https://github.com/apache/ignite-website) are sent to d...@ignite.apache.org. These notifications should be sent to notificati...@ignite.apache.org as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12931) General error: "java.lang.ArrayIndexOutOfBound
[ https://issues.apache.org/jira/browse/IGNITE-12931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12931: Component/s: sql > General error: "java.lang.ArrayIndexOutOfBound > -- > > Key: IGNITE-12931 > URL: https://issues.apache.org/jira/browse/IGNITE-12931 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: icode >Priority: Blocker > Labels: B+Tree > Attachments: console.log > > > Hi guys! > I'm use ignite v2.8.0. I get the some error, please help me. Thanks. > I find like this error in mailling list, but it different. > Please see attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-12798. - Resolution: Not A Problem > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12798: Ignite Flags: (was: Docs Required,Release Notes Required) > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reopened IGNITE-12798: - > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12865) NPE occurs during CQ registration with cache node filter specified.
[
https://issues.apache.org/jira/browse/IGNITE-12865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076180#comment-17076180
]
Ivan Pavlukhin commented on IGNITE-12865:
-
[~PetrovMikhail], could you please provide a stack trace? From the first glance
it seems that there is a problem with {{filteredNode}} variable node usage in a
node filter in the test. By some reason it can be serialized and I suppose
deserialized not ready to use.
Will changing code in a following way fix the test?
{code}
Object filteredId = filteredNode.localNode().id();
filteredNode.createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setNodeFilter(node -> !node.id().equals(filteredId)));
{code}
> NPE occurs during CQ registration with cache node filter specified.
> ---
>
> Key: IGNITE-12865
> URL: https://issues.apache.org/jira/browse/IGNITE-12865
> Project: Ignite
> Issue Type: Bug
>Reporter: PetrovMikhail
>Priority: Minor
>
> NPE occurs during CQ registration if
> 1. Node that starts cache does not match cache node filter.
> 2. CQ is started on node that matches cache node filter.
> Reproducer:
> {code:java}
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx filteredNode = startGrid(0);
> IgniteEx cacheStoreNode = startGrid(1);
> filteredNode.cluster().state(ClusterState.ACTIVE);
> filteredNode.createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setNodeFilter(node ->
> !node.id().equals(filteredNode.localNode().id(;
> ContinuousQuery qry = new ContinuousQuery<>();
> qry.setLocalListener(evts -> {
> //No-op.
> });
> cacheStoreNode.cache(DEFAULT_CACHE_NAME).query(qry);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072764#comment-17072764
]
Ivan Pavlukhin commented on IGNITE-12832:
-
[~oleg-a-ostanin], it would be great to receive an approve from someone more
familiar than I with control utility code.
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070209#comment-17070209
]
Ivan Pavlukhin edited comment on IGNITE-12832 at 3/29/20, 4:53 AM:
---
[~oleg-a-ostanin], I left a couple of comments on
[GitHub|https://github.com/apache/ignite/pull/7566#pullrequestreview-383372451].
Also I did not noticed that added arguments are described in an utility help
output, should we add it?
was (Author: pavlukhin):
[~oleg-a-ostanin], I left a couple comments on
[GitHub|https://github.com/apache/ignite/pull/7566#pullrequestreview-383372451].
Also I did not noticed that added arguments are described in an utility help
output, should we add it?
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070209#comment-17070209
]
Ivan Pavlukhin commented on IGNITE-12832:
-
[~oleg-a-ostanin], I left a couple comments on
[GitHub|https://github.com/apache/ignite/pull/7566#pullrequestreview-383372451].
Also I did not noticed that added arguments are described in an utility help
output, should we add it?
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12833) JDBC thin client SELECT hangs under 2.8.0
[
https://issues.apache.org/jira/browse/IGNITE-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12833:
Component/s: jdbc
> JDBC thin client SELECT hangs under 2.8.0
> -
>
> Key: IGNITE-12833
> URL: https://issues.apache.org/jira/browse/IGNITE-12833
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, security
>Affects Versions: 2.8
>Reporter: Veena Mithare
>Priority: Major
> Labels: iep-41
> Attachments: JdbcSelectHangsIn2.8.0Mail.txt
>
>
> |
> |When security is enabled, and an update or select sql is issued from
> dbeaver, the security context in
> class GridIOManager ,
> method -createGridIoMessage -
> line - ctx.security().securityContext() returns the securitycontext of the
> thin client.
> The message generated out of createGridIoMessage is passed on to the next
> node.
> This is used in
> class - IgniteSecurityProcessor
> method - ( withContext)
> line - ctx.discovery().node(uuid)
> on the next node :
> @Override public OperationSecurityContext withContext(UUID nodeId)
> { return withContext( secCtxs.computeIfAbsent(nodeId,
>
> uuid -> nodeSecurityContext( marsh,
> U.resolveClassLoader(ctx.config()), ctx.discovery().node(uuid)
> ) ) ); }
> The ctx.discovery().node(uuid) used to
> determine the ClusterNode that is passed into nodeSecurityContext() returns
> null, since the uuid is that of the remote client id not the remote node id.
> Hence
> class: SecurityUtils.java
> method : nodeSecurityContext
> line : byte[] subjBytes =
> node.attribute(IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_V2);
> Throws null pointer exception since node is null.
> Related ticket :
> IGNITE-12579
>
> Related discussion :
> [http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html#a31847]|
> |
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067414#comment-17067414
]
Ivan Pavlukhin commented on IGNITE-12766:
-
[~slava.koptilin], the patch looks good to me. Thank you!
> Node startup can be broken in case of using Local cache with persistence
> enabled.
> -
>
> Key: IGNITE-12766
> URL: https://issues.apache.org/jira/browse/IGNITE-12766
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
> example) may result in the following exception when Local cache is used and
> persistence enabled.
> {code}
> [2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections[2020-03-05
> 16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: An error occurred during cache
> configuration loading from file [file=...] at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at
> org.apache.ignite.Ignition.start(Ignition.java:346) at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
> ... 18 moreCaused by: java.lang.ClassNotFoundException:
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
> java.lang.Class.forName0(Native Method) at
> java.lang.Class.forName(Class.java:348) at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8870) at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1826)
> at java.io.ObjectInputSt
[jira] [Commented] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17062089#comment-17062089
]
Ivan Pavlukhin commented on IGNITE-12766:
-
[~slava.koptilin], generally everything looks fine. Some comments:
# I suppose we can make nested {{GridCacheProcessor.LocalAffinityFunction}}
class _private_ and throw an exception from a constructor as it should not be
instantiated by calling the constructor.
# I noticed that nested affinity function class is listed in a file
classnames.properties (I forgot why is it needed), should not we add the new
class to this file as well?
# While it does not seem critical, but quite interesting, can we define
{{readResolve}} method and replace an instance of the old nested class with an
instance of the actual one?
> Node startup can be broken in case of using Local cache with persistence
> enabled.
> -
>
> Key: IGNITE-12766
> URL: https://issues.apache.org/jira/browse/IGNITE-12766
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
> example) may result in the following exception when Local cache is used and
> persistence enabled.
> {code}
> [2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections[2020-03-05
> 16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: An error occurred during cache
> configuration loading from file [file=...] at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at
> org.apache.ignite.Ignition.start(Ignition.java:346) at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
> ... 18 moreCaused by: java.lang.ClassNotFoundException:
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader
[jira] [Comment Edited] (IGNITE-12787) Remove obsolete Selector.open workaround code from GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-12787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061654#comment-17061654
]
Ivan Pavlukhin edited comment on IGNITE-12787 at 3/18/20, 11:44 AM:
[~amashenkov], is a resolved *openjdk* ticket a sufficient proof?
https://bugs.openjdk.java.net/browse/JDK-6427854
Here is a jdk8_b01 code
https://github.com/openjdk/jdk/blob/d2ac7a107e4af38df029fc19e37df25a4831514e/jdk/src/share/classes/sun/nio/ch/Util.java#L451
_volatile_ property seems to be the fix we are looking for.
was (Author: pavlukhin):
[~amashenkov], is a resolved **openjdk** ticket a sufficient proof?
https://bugs.openjdk.java.net/browse/JDK-6427854
Here is a jdk8_b01 code
https://github.com/openjdk/jdk/blob/d2ac7a107e4af38df029fc19e37df25a4831514e/jdk/src/share/classes/sun/nio/ch/Util.java#L451
_volatile_ property seems to be the fix we are looking for.
> Remove obsolete Selector.open workaround code from GridNioServer
>
>
> Key: IGNITE-12787
> URL: https://issues.apache.org/jira/browse/IGNITE-12787
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a code in {{GridNioServer}} aimed to workaround an old bug in JDK
> 1.5 which was fixed in 1.7.
> {code}
> static {
> // This is a workaround for JDK bug (NPE in Selector.open()).
> // http://bugs.sun.com/view_bug.do?bug_id=6427854
> try {
> Selector.open().close();
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> {code}
> Currently Java 8 is a minimal supported version. So, the workaround code can
> be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12787) Remove obsolete Selector.open workaround code from GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-12787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061654#comment-17061654
]
Ivan Pavlukhin commented on IGNITE-12787:
-
[~amashenkov], is a resolved **openjdk** ticket a sufficient proof?
https://bugs.openjdk.java.net/browse/JDK-6427854
Here is a jdk8_b01 code
https://github.com/openjdk/jdk/blob/d2ac7a107e4af38df029fc19e37df25a4831514e/jdk/src/share/classes/sun/nio/ch/Util.java#L451
_volatile_ property seems to be the fix we are looking for.
> Remove obsolete Selector.open workaround code from GridNioServer
>
>
> Key: IGNITE-12787
> URL: https://issues.apache.org/jira/browse/IGNITE-12787
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a code in {{GridNioServer}} aimed to workaround an old bug in JDK
> 1.5 which was fixed in 1.7.
> {code}
> static {
> // This is a workaround for JDK bug (NPE in Selector.open()).
> // http://bugs.sun.com/view_bug.do?bug_id=6427854
> try {
> Selector.open().close();
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> {code}
> Currently Java 8 is a minimal supported version. So, the workaround code can
> be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061604#comment-17061604
]
Ivan Pavlukhin commented on IGNITE-12543:
-
(y)
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061513#comment-17061513 ] Ivan Pavlukhin commented on IGNITE-12798: - [~rangerzhou], I guess that your problem is related to remote class loading. I suppose that when you start servers using ignite.sh server java processes do not have filter/listener classes on classpath. Classes need to be somehow delivered to servers, enabling _peer class loading_ might help (https://apacheignite.readme.io/docs/zero-deployment#peer-class-loading). Next potential problem might be using java lambdas for _filters_ and _listeners_, it worth trying anonymous classes if it does not work with lambdas. > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061496#comment-17061496
]
Ivan Pavlukhin commented on IGNITE-12543:
-
[~alex_pl], thank you for details. But will be a number of bytes transferred
over the wire adequate after fixing IGNITE-12625 or there still will be a size
explosion? Beforehand we observed an explosion when SQL columns of type
{{List}} had been transferred over the wire. The root cause is a
code fragment mentioned before:
{code: java}
// org.apacheignite.internal.binary.BinaryWriterExImpl.java
public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
if (po == null)
out.writeByte(GridBinaryMarshaller.NULL);
else {
byte[] poArr = po.array();
out.unsafeEnsure(1 + 4 + poArr.length +4);
out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
out.unsafeWriteInt(poArr.length);
out.writeByteArray(poArr);
out.unsafeWriteInt(po.start());
}
}
{code}
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061496#comment-17061496
]
Ivan Pavlukhin edited comment on IGNITE-12543 at 3/18/20, 8:31 AM:
---
[~alex_pl], thank you for details. But will be a number of bytes transferred
over the wire adequate after fixing IGNITE-12625 or there still will be a size
explosion? Beforehand we observed an explosion when SQL columns of type
{{List}} had been transferred over the wire. The root cause is a
code fragment mentioned before:
{code:java}
// org.apacheignite.internal.binary.BinaryWriterExImpl.java
public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
if (po == null)
out.writeByte(GridBinaryMarshaller.NULL);
else {
byte[] poArr = po.array();
out.unsafeEnsure(1 + 4 + poArr.length +4);
out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
out.unsafeWriteInt(poArr.length);
out.writeByteArray(poArr);
out.unsafeWriteInt(po.start());
}
}
{code}
was (Author: pavlukhin):
[~alex_pl], thank you for details. But will be a number of bytes transferred
over the wire adequate after fixing IGNITE-12625 or there still will be a size
explosion? Beforehand we observed an explosion when SQL columns of type
{{List}} had been transferred over the wire. The root cause is a
code fragment mentioned before:
{code: java}
// org.apacheignite.internal.binary.BinaryWriterExImpl.java
public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
if (po == null)
out.writeByte(GridBinaryMarshaller.NULL);
else {
byte[] poArr = po.array();
out.unsafeEnsure(1 + 4 + poArr.length +4);
out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
out.unsafeWriteInt(poArr.length);
out.writeByteArray(poArr);
out.unsafeWriteInt(po.start());
}
}
{code}
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060509#comment-17060509
]
Ivan Pavlukhin commented on IGNITE-12543:
-
[~alex_pl], I might have missed that the object size increases significantly
inside a storage. I mostly concerned about transferring over the wire (I
remember even some OOMs related to it) which is caused by
{{BinaryWriterExImpl.doWriteBinaryObject}} as well.
[~redcomet], [~sunghan.suh], can you confirm that in your case enormous size is
observed in a storage?
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12787) Remove obsolete Selector.open workaround code from GridNioServer
Ivan Pavlukhin created IGNITE-12787:
---
Summary: Remove obsolete Selector.open workaround code from
GridNioServer
Key: IGNITE-12787
URL: https://issues.apache.org/jira/browse/IGNITE-12787
Project: Ignite
Issue Type: Task
Components: general
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin
Fix For: 2.9
There is a code in {{GridNioServer}} aimed to workaround an old bug in JDK 1.5
which was fixed in 1.7.
{code}
static {
// This is a workaround for JDK bug (NPE in Selector.open()).
// http://bugs.sun.com/view_bug.do?bug_id=6427854
try {
Selector.open().close();
}
catch (IOException ignored) {
// No-op.
}
}
{code}
Currently Java 8 is a minimal supported version. So, the workaround code can be
removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12770) Add multiple hash index support.
[ https://issues.apache.org/jira/browse/IGNITE-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17058289#comment-17058289 ] Ivan Pavlukhin commented on IGNITE-12770: - [~arsen], do you assume that Ignite supports _single_ hash index? What index do you mean then? > Add multiple hash index support. > > > Key: IGNITE-12770 > URL: https://issues.apache.org/jira/browse/IGNITE-12770 > Project: Ignite > Issue Type: Wish >Reporter: Arsen Manucharyan >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12777) Incorrect query result with count(*) should return 0
[ https://issues.apache.org/jira/browse/IGNITE-12777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12777: Component/s: (was: compute) sql > Incorrect query result with count(*) should return 0 > > > Key: IGNITE-12777 > URL: https://issues.apache.org/jira/browse/IGNITE-12777 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.7.5, 2.7.6 > Environment: apache ignite 2.8.0 / 2.9.0 SNAPSHOT > uname -a: > Linux (hostname) 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC > 2018 x86_64 x86_64 x86_64 GNU/Linux > java: > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) >Reporter: yiteng.liu >Priority: Blocker > > Query on cache with parallelism > 1 will result in incorrect result; > add > > ||xml|| > | > > class="org.apache.ignite.configuration.CacheConfiguration" > name="parallelTemplate"> > > > > > type="org.apache.ignite.cache.CacheMode">PARTITIONED > > value="TRANSACTIONAL_SNAPSHOT"/> > > > > | > to default-config.xml > and create a table in sqlline > ||sql|| > |create table test3 > ( > ID BIGINT default 0 not null, > C1 VARCHAR(100) default '' not null, > C2 VARCHAR(32) default '' not null, > C3 DECIMAL(10,2) default 0.00 not null, > C4 TIMESTAMP, > C5 TIMESTAMP, > C6 VARCHAR(10) default '' not null, > primary key (C1, C2) > ) with "template=parallelTemplate,affinity_key=c1" ;| > > execute query: > > ||sql|| > |select count(*) from test3 > where C1 = 'CESHIZJBX_7789' > and C2 = '12345' > and C3 = 12.5;| > Results in incorrent result: > > sqlline version 1.3.0 > 0: jdbc:ignite:thin://127.0.0.1> create table test3 > . . . . . . . . . . . . . . . .> ( > . . . . . . . . . . . . . . . .> ID BIGINT default 0 not null, > . . . . . . . . . . . . . . . .> C1 VARCHAR(100) default '' not null, > . . . . . . . . . . . . . . . .> C2 VARCHAR(32) default '' not null, > . . . . . . . . . . . . . . . .> C3 DECIMAL(10,2) default 0.00 not null, > . . . . . . . . . . . . . . . .> C4 TIMESTAMP, > . . . . . . . . . . . . . . . .> C5 TIMESTAMP, > . . . . . . . . . . . . . . . .> C6 VARCHAR(10) default '' not null, > . . . . . . . . . . . . . . . .> primary key (C1, C2) > . . . . . . . . . . . . . . . .> ) with > "template=parallelTemplate,affinity_key=c1" ; > No rows affected (0.239 seconds) > 0: jdbc:ignite:thin://127.0.0.1> select count(*) from test3 > . . . . . . . . . . . . . . . .> where C1 = 'CESHIZJBX_7789' > . . . . . . . . . . . . . . . .> and C2 = '12345' > . . . . . . . . . . . . . . . .> and C3 = 12.5; > ++ > | COUNT(*) | > ++ > | 0 | > | 0 | > | 0 | > | 0 | > | 0 | > | 0 | > | 0 | > | 0 | > | 0 | > ++ > 9 rows selected (0.052 seconds) > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12770) Add multiple hash index support.
[ https://issues.apache.org/jira/browse/IGNITE-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056906#comment-17056906 ] Ivan Pavlukhin commented on IGNITE-12770: - [~arsen], could you please provide more details in a ticket description? What hash indexes are assumed? What are benefits of supporting multiple of them? > Add multiple hash index support. > > > Key: IGNITE-12770 > URL: https://issues.apache.org/jira/browse/IGNITE-12770 > Project: Ignite > Issue Type: Wish >Reporter: Arsen Manucharyan >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056753#comment-17056753
]
Ivan Pavlukhin commented on IGNITE-12766:
-
[~slava.koptilin], do you have already an idea how the problem could be fixed?
Will moving {{LocalAffinityFunction}} back just work?
> Node startup can be broken in case of using Local cache with persistence
> enabled.
> -
>
> Key: IGNITE-12766
> URL: https://issues.apache.org/jira/browse/IGNITE-12766
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
> example) may result in the following exception when Local cache is used and
> persistence enabled.
> {code}
> [2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections[2020-03-05
> 16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: An error occurred during cache
> configuration loading from file [file=...] at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at
> org.apache.ignite.Ignition.start(Ignition.java:346) at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
> ... 18 moreCaused by: java.lang.ClassNotFoundException:
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
> java.lang.Class.forName0(Native Method) at
> java.lang.Class.forName(Class.java:348) at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8870) at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1826)
> a
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17055633#comment-17055633 ] Ivan Pavlukhin commented on IGNITE-12549: - [~macrergate], I believe we can include it into 2.8.1 but as far as I know neither 2.8.1 branch was created neither scope was discussed. We cannot put fix version 2.8.1 immediately here because RESOLVED ticket status can be misleading if the patch will not appear in 2.8.1 by some reason. It seems that we can add 2.8.1 fix version only when the fix will be merged to 2.8.1 branch. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.9 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17054896#comment-17054896
]
Ivan Pavlukhin commented on IGNITE-12543:
-
[~sunghan.suh], thank you for your efforts. I must say that the proposed fix
cannot be applied as is. I run tests against PR and there are critical
failures. Here are results
[report|https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/7403/head&action=Latest].
And most illustrative one is a failure of [Binary
Objects|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BinaryObjects?branch=pull%2F7403%2Fhead&mode=builds]
test suite.
And actually the reason was already mentioned in comments.
bq. Initially the protocol was designed to be universal and able to serialize
objects of any complexity (nested objects, circular references).
Consider an example to make things clear.
{code:java}
// Node of a doubly linked list
class Node {
Node next, prev;
String val;
}
{code}
In a list of two elements we have 2 nodes having references to each other. Some
trick is needed to serialize such structure. In _Binary Object_ format it is
called _handles_. Let's call these 2 list elements A and B. In a serialized
form we can start writing A:
{noformat}
[prev:null, val:A, next:?]
{noformat}
Let's write A.next = B directly:
{noformat}
[prev:null, val:A, next:[prev:?, val:B, next:null]]
{noformat}
What should be written as B.prev = A? writing it directly as before will lead
to infinite recursion. So, a _handle_ (i.e. reference) is written. You can find
more details about _Binary Object_ format in a following
[article|https://cwiki.apache.org/confluence/display/IGNITE/Binary+object+format].
And returning to the issue we need to answer the question why more bytes than a
specific object takes is written during serialization. If we need to serialize
node B from the provided example we need to serialize node A as well. In
current implementation we simply take all bytes from top-most binary object. In
such fashion we can serialize and transfer objects of any structure safely.
Currently I do not have a simple solution in my mind how this issue could be
fixed while keeping the ability to serialize any object.
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-12549. - Fix Version/s: (was: 2.8.1) Resolution: Fixed [~macrergate], I merged PR to master. Thank you for contribution! By the way I left only 2.9 as fix version as it is resolved only in master for now. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.9 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12737) Incorrect annotation on TxDeadlockCauseTest
[
https://issues.apache.org/jira/browse/IGNITE-12737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17052584#comment-17052584
]
Ivan Pavlukhin commented on IGNITE-12737:
-
[~zzzadruga], some historical note. The test class was added in a suite as
disabled in IGNITE-7615 when it was found belonging to no suite. Invalid
`@Test` annotation was added later during migration to junit4.
But generally I think it would be great to fix and enable the test in CI.
> Incorrect annotation on TxDeadlockCauseTest
> ---
>
> Key: IGNITE-12737
> URL: https://issues.apache.org/jira/browse/IGNITE-12737
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolai Kulagin
>Priority: Minor
>
> Method TxDeadlockCauseTest#testCauseObject() have annotation
> {color:#ffab00}@Test{color}, but it is not a test case. As a result, JUnit
> can run no one test in this class and printed error.
> {code:java}
> java.lang.Exception: Method testCauseObject should have no parameters.{code}
> Most likely TxDeadlockCauseTest.class was commented on in the suite
> TxDeadlockDetectionTestSuite because of this.
> I suggest:
> 1. Delete the annotation {color:#ffab00}@Test{color};
> 2. Fix the tests in TxDeadlockCauseTest (3 tests look good, 1 test fails);
> 3. Uncomment the TxDeadlockCauseTest in the suite.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051037#comment-17051037 ] Ivan Pavlukhin commented on IGNITE-12549: - [~macrergate], sorry, I had a lack of time to check it. Will do in a couple of days. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.9, 2.8.1 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12725) Excessive backups performance suggestion.
[ https://issues.apache.org/jira/browse/IGNITE-12725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17049328#comment-17049328 ] Ivan Pavlukhin commented on IGNITE-12725: - [~zstan], LGTM. Thank you for contribution. Merged to master. > Excessive backups performance suggestion. > - > > Key: IGNITE-12725 > URL: https://issues.apache.org/jira/browse/IGNITE-12725 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.8.1 > > Time Spent: 20m > Remaining Estimate: 0h > > I found that performance suggestion for zeroing backups count is incorrect in > terms of proper cluster exploitation and easy way to loose your data. > Discussion in dev list [1]. I suggest simple remove this message. > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/Excessive-backups-performance-suggestion-td45658.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12731) Support expiry policy at a key value level for the thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17049090#comment-17049090 ] Ivan Pavlukhin commented on IGNITE-12731: - [~scriptnull], is not IGNITE-12399 exactly what you need? > Support expiry policy at a key value level for the thin clients > --- > > Key: IGNITE-12731 > URL: https://issues.apache.org/jira/browse/IGNITE-12731 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Vishnu Bharathi >Priority: Major > > Apache Ignite supports expiry policies at a cache > level ( [https://apacheignite.readme.io/docs/expiry-policies] ), so that all > the key-value pairs in the cache gets expired at a specific time. When asked > if there is a way to set expiry policy at a key value level in the user > mailing list ( > [http://apache-ignite-users.70518.x6.nabble.com/Expiry-policy-at-a-key-value-level-td31568.html] > ) got the below response > |Hello, > IgniteCache has a way to specify the expiry policy at key level for thick > clients via IgniteCache#withExpiryPolicy() facade. I think it may be > reasonable to add similar option to the thin clients protocol as well. Feel > free to open a ticket.| > Will it be ok to add this functionality to the core project? > To start with, I would like to know what components are involved in-order to > make this change. Is it just the thin client code or any other components are > also involved? > Would be greatly helpful, if someone could point me to the source files, code > paths etc. for implementing this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12656) Cleanup GridCacheProcessor from functionality not related to its responsibility
[
https://issues.apache.org/jira/browse/IGNITE-12656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047476#comment-17047476
]
Ivan Pavlukhin commented on IGNITE-12656:
-
[~slava.koptilin], I checked a description of {{GridCacheProcessor}} in
javadoc. Sounds good to me. Have not done thorough code review but did not
catch any problems during brief check.
> Cleanup GridCacheProcessor from functionality not related to its
> responsibility
> ---
>
> Key: IGNITE-12656
> URL: https://issues.apache.org/jira/browse/IGNITE-12656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, we have a couple of functionality in GridCacheProcessor not
> directly related to its responsibility, like:
> * initQueryStructuresForNotStartedCache
> * addRemovedItemsCleanupTask
> * setTxOwnerDumpRequestsAllowed
> * longTransactionTimeDumpThreshold
> * transactionTimeDumpSamplesCoefficient
> * longTransactionTimeDumpSamplesPerSecondLimit
> * broadcastToNodesSupportingFeature
> * LocalAffinityFunction
> * RemovedItemsCleanupTask
> * TxTimeoutOnPartitionMapExchangeChangeFuture
> * enableRebalance
> We need to move them to the right places and make GridCacheProcessor code
> cleaner.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047408#comment-17047408
]
Ivan Pavlukhin edited comment on IGNITE-12610 at 2/28/20 10:05 AM:
---
[~artsiom_panko], I left comments on
[GitHub|https://github.com/apache/ignite/pull/7385#pullrequestreview-366272724].
bq. By the way, some sys properties from static import are not used in
SysProperties.class and in Ignite at all
Good observation! I suggest to create a separate ticket to investigate/fix a
problem with unused properties.
was (Author: pavlukhin):
[~artsiom_panko], I left comments on
[GitHub|https://github.com/apache/ignite/pull/7385#pullrequestreview-366272724].
.bq By the way, some sys properties from static import are not used in
SysProperties.class and in Ignite at all
Good observation! I suggest to create a separate ticket to investigate/fix a
problem with unused properties.
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047408#comment-17047408
]
Ivan Pavlukhin commented on IGNITE-12610:
-
[~artsiom_panko], I left comments on
[GitHub|https://github.com/apache/ignite/pull/7385#pullrequestreview-366272724].
.bq By the way, some sys properties from static import are not used in
SysProperties.class and in Ignite at all
Good observation! I suggest to create a separate ticket to investigate/fix a
problem with unused properties.
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12715) Calcite integration. Secondary indexes support.
[ https://issues.apache.org/jira/browse/IGNITE-12715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042009#comment-17042009 ] Ivan Pavlukhin commented on IGNITE-12715: - [~rkondakov], out of curiosity, are you going to use Calcite materialized views here? > Calcite integration. Secondary indexes support. > --- > > Key: IGNITE-12715 > URL: https://issues.apache.org/jira/browse/IGNITE-12715 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > > Secondary indexes should be supported by Calcite-based engine as well as they > supported by the legacy H2 engine. At first we can use the old engine for > indexes maintenance (building, updating, etc). In this case Calcite engine > will only use indexes metadata for query planning and index scans for query > execution. On the next iteration we need to eliminate the old engine usage. > Approximate plan for indexes support implementation: > # Add indexes to schema and set up all schema listeners. > # Add Collation to planner's output trait set and check if generated plan is > properly chosen in accordance to index sort direction. > # Implement index scans with filtering > # Add Sort node to exec. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042000#comment-17042000 ] Ivan Pavlukhin commented on IGNITE-12549: - [~macrergate], approach with topology read lock looks fine to me. I left some comments on GitHub. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 2h > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12686) Deprecate obsolete configuration properties
[ https://issues.apache.org/jira/browse/IGNITE-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040824#comment-17040824 ] Ivan Pavlukhin commented on IGNITE-12686: - Merged to master. > Deprecate obsolete configuration properties > --- > > Key: IGNITE-12686 > URL: https://issues.apache.org/jira/browse/IGNITE-12686 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: newbie > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Following properties were discovered as obsolete (no usages in codebase): > * TransactionConfiguration.PessimisticTxLogSize > * TransactionConfiguration.PessimisticTxLogLinger > * CacheConfiguration.DefaultLockTimeout > Let's deprecate them. > Note that we are not going to remove them at this stage to avoid possible > compatibility issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12706) Bundle logback as optional lib
[ https://issues.apache.org/jira/browse/IGNITE-12706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040726#comment-17040726 ] Ivan Pavlukhin commented on IGNITE-12706: - [~koalalam], could you please provide more details about needed improvement? Is it about including jars to binary distribution? On what layer SLF4J is supposed to be used? > Bundle logback as optional lib > -- > > Key: IGNITE-12706 > URL: https://issues.apache.org/jira/browse/IGNITE-12706 > Project: Ignite > Issue Type: Improvement >Reporter: Koala Lam >Priority: Major > > To facilitate the use of SLF4J - need logback-core and logback-classic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12690) Remove deprecation from DataRegionMetrics and mark metrics API with IgniteExperimental
[ https://issues.apache.org/jira/browse/IGNITE-12690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040120#comment-17040120 ] Ivan Pavlukhin commented on IGNITE-12690: - [~mmuzaf], I suppose I am not the best person to do a review here because I have a little knowledge about Ignite metric APIs. I think [~nizhikov] and [~agura] are proper persons here. Nikolay, Andrey, could you please help? > Remove deprecation from DataRegionMetrics and mark metrics API with > IgniteExperimental > -- > > Key: IGNITE-12690 > URL: https://issues.apache.org/jira/browse/IGNITE-12690 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > According to the vote [1] results and the discussion thread [2] the following > needs to be done: > 1. Remove @deprecated from DataRegionMetric > 2. Mark new metrics API with @IgniteExperimental > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/RESULT-VOTE-Allow-or-prohibit-a-joint-use-of-deprecated-and-IgniteExperimental-td45863.html > [2] > http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039724#comment-17039724 ] Ivan Pavlukhin commented on IGNITE-12549: - [~macrergate], I need some more time to evaluate the proposed solution. You might ask someone else to review if you need it faster. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038929#comment-17038929 ] Ivan Pavlukhin commented on IGNITE-12549: - [~macrergate], I will take a look today. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12686) Deprecate obsolete configuration properties
[
https://issues.apache.org/jira/browse/IGNITE-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038495#comment-17038495
]
Ivan Pavlukhin commented on IGNITE-12686:
-
Same {{PDS (Indexing)}} failure as in master.
> Deprecate obsolete configuration properties
> ---
>
> Key: IGNITE-12686
> URL: https://issues.apache.org/jira/browse/IGNITE-12686
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Following properties were discovered as obsolete (no usages in codebase):
> * TransactionConfiguration.PessimisticTxLogSize
> * TransactionConfiguration.PessimisticTxLogLinger
> * CacheConfiguration.DefaultLockTimeout
> Let's deprecate them.
> Note that we are not going to remove them at this stage to avoid possible
> compatibility issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12686) Deprecate obsolete configuration properties
[ https://issues.apache.org/jira/browse/IGNITE-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12686: --- Assignee: Ivan Pavlukhin > Deprecate obsolete configuration properties > --- > > Key: IGNITE-12686 > URL: https://issues.apache.org/jira/browse/IGNITE-12686 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: newbie > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Following properties were discovered as obsolete (no usages in codebase): > * TransactionConfiguration.PessimisticTxLogSize > * TransactionConfiguration.PessimisticTxLogLinger > * CacheConfiguration.DefaultLockTimeout > Let's deprecate them. > Note that we are not going to remove them at this stage to avoid possible > compatibility issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17037802#comment-17037802
]
Ivan Pavlukhin commented on IGNITE-12610:
-
[~artsiom_panko], here are my comments:
# It is not good to call same code twice, please check
{{org.apache.ignite.internal.processors.query.h2.ConnectionManager}} static
initializer. It worth checking that other properties should be set in
{{IgniteH2Indexing}} as well.
# I think it is better to start an Ignite instance in test to check expected
property initialization in a wider context.
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12686) Deprecate obsolete configuration properties
[ https://issues.apache.org/jira/browse/IGNITE-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12686: Labels: newbie (was: ) > Deprecate obsolete configuration properties > --- > > Key: IGNITE-12686 > URL: https://issues.apache.org/jira/browse/IGNITE-12686 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Priority: Major > Labels: newbie > Fix For: 2.9 > > > Following properties were discovered as obsolete (no usages in codebase): > * TransactionConfiguration.PessimisticTxLogSize > * TransactionConfiguration.PessimisticTxLogLinger > * CacheConfiguration.DefaultLockTimeout > Let's deprecate them. > Note that we are not going to remove them at this stage to avoid possible > compatibility issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12686) Deprecate obsolete configuration properties
Ivan Pavlukhin created IGNITE-12686: --- Summary: Deprecate obsolete configuration properties Key: IGNITE-12686 URL: https://issues.apache.org/jira/browse/IGNITE-12686 Project: Ignite Issue Type: Bug Components: cache Reporter: Ivan Pavlukhin Fix For: 2.9 Following properties were discovered as obsolete (no usages in codebase): * TransactionConfiguration.PessimisticTxLogSize * TransactionConfiguration.PessimisticTxLogLinger * CacheConfiguration.DefaultLockTimeout Let's deprecate them. Note that we are not going to remove them at this stage to avoid possible compatibility issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10698) Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
[
https://issues.apache.org/jira/browse/IGNITE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-10698:
Fix Version/s: (was: 3.0)
2.9
> Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
> ---
>
> Key: IGNITE-10698
> URL: https://issues.apache.org/jira/browse/IGNITE-10698
> Project: Ignite
> Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Lev Kiselev
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.9
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> {noformat}
> @MXBeanDescription("Returns or kills transactions matching the filter
> conditions.")
> @MXBeanParametersNames(
> {
> "minDuration",
> "minSize",
> "prj",
> "consistentIds",
> "xid",
> "lbRegex",
> "limit",
> "order",
> "detailed",
> "kill"
> }
> )
> @MXBeanParametersDescriptions(
> {
> "Minimum duration (seconds).",
> "Minimum size.",
> "Projection (servers|clients).",
> "Consistent ids (separated by comma).",
> "Transaction XID.",
> "Label regexp.",
> "Limit a number of transactions collected on each node.",
> "Order by DURATION|SIZE.",
> "Show detailed description, otherwise only count.",
> "Kill matching transactions (be careful)."
> }
> )
> {noformat}
> Above looks pretty ugly and is very error prone due to messing names and
> descr order or number of strings.
> I would suggest to introduce individual parameters annotations and get them
> via mtd.getParamterAnnotations() at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12067) SQL: metrics of executions of user queries
[ https://issues.apache.org/jira/browse/IGNITE-12067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12067: Release Note: Introduce metrics to count number of successful and failed SQL queries > SQL: metrics of executions of user queries > -- > > Key: IGNITE-12067 > URL: https://issues.apache.org/jira/browse/IGNITE-12067 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Ivan Pavlukhin >Priority: Major > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Lets add: > - Counter of success executed user queries. > - Counter of failed executed user queries. > - Counter of cancelled user queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12678) GridLongList fails on add when created with explicit zero size
[ https://issues.apache.org/jira/browse/IGNITE-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036939#comment-17036939 ] Ivan Pavlukhin commented on IGNITE-12678: - [~korlov], could please fill in the ticket description? > GridLongList fails on add when created with explicit zero size > -- > > Key: IGNITE-12678 > URL: https://issues.apache.org/jira/browse/IGNITE-12678 > Project: Ignite > Issue Type: Bug > Components: data structures >Reporter: Konstantin Orlov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12674) Extend test coverage for binary types registration
[ https://issues.apache.org/jira/browse/IGNITE-12674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036938#comment-17036938 ] Ivan Pavlukhin commented on IGNITE-12674: - [~korlov], thank you for contribution! Merged to master. > Extend test coverage for binary types registration > -- > > Key: IGNITE-12674 > URL: https://issues.apache.org/jira/browse/IGNITE-12674 > Project: Ignite > Issue Type: Task > Components: binary >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12067) SQL: metrics of executions of user queries
[ https://issues.apache.org/jira/browse/IGNITE-12067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-12067. - Fix Version/s: 2.9 Resolution: Fixed [~amashenkov], thank you for review. I created a ticket for javadocs simplification IGNITE-12679. Merged to master. > SQL: metrics of executions of user queries > -- > > Key: IGNITE-12067 > URL: https://issues.apache.org/jira/browse/IGNITE-12067 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Ivan Pavlukhin >Priority: Major > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Lets add: > - Counter of success executed user queries. > - Counter of failed executed user queries. > - Counter of cancelled user queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12679) Simplify javadocs in SQL classes
Ivan Pavlukhin created IGNITE-12679: --- Summary: Simplify javadocs in SQL classes Key: IGNITE-12679 URL: https://issues.apache.org/jira/browse/IGNITE-12679 Project: Ignite Issue Type: Bug Components: sql Reporter: Ivan Pavlukhin Fix For: 2.9 Update javadocs according to comments in PR https://github.com/apache/ignite/pull/7412 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12610) Disable H2 object cache reliably
[
https://issues.apache.org/jira/browse/IGNITE-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036268#comment-17036268
]
Ivan Pavlukhin commented on IGNITE-12610:
-
[~artsiom_panko], thank you for the patch. I will check it by the end of this
week.
> Disable H2 object cache reliably
>
>
> Key: IGNITE-12610
> URL: https://issues.apache.org/jira/browse/IGNITE-12610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ivan Pavlukhin
>Assignee: Artsiom Panko
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be
> disabled by using "h2.objectCache" system property. There is a clear intent
> to disable this cache because the system property is set to "false" in
> {{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But
> apparently it is too late, because the property is read by H2 internals
> before it. Consequently the object cache is enabled by default.
> We need to set this property earlier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12624) Java thin client: Wrong typeId generation for system types
[
https://issues.apache.org/jira/browse/IGNITE-12624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036256#comment-17036256
]
Ivan Pavlukhin commented on IGNITE-12624:
-
[~alex_pl], the patch looks good to me.
> Java thin client: Wrong typeId generation for system types
> --
>
> Key: IGNITE-12624
> URL: https://issues.apache.org/jira/browse/IGNITE-12624
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Thin client generates wrong {{typeId}} for system types. This is caused by
> {{ClientMarshallerContext}} implementation, which always returns {{false}}
> for {{isSystemType}} method. These leads to {{typeId}} duplication for the
> same class and assertions when trying to get object by thick client.
> Reproducer:
> {code:java}
> thinClient.cache(DEFAULT_CACHE_NAME).put(1, CacheAtomicityMode.ATOMIC);
> thickClient.cache(DEFAULT_CACHE_NAME).get(1);
> {code}
> Assertion:
>
> {noformat}
> java.lang.AssertionError: Duplicate typeId [typeId=1984564222, cls=class
> org.apache.ignite.cache.CacheAtomicityMode, desc=BinaryClassDescriptor
> [cls=class org.apache.ignite.cache.CacheAtomicityMode, serializer=null,
> initialSerializer=null, mapper=BinaryInternalMapper
> [nameMapper=BinaryBaseNameMapper [isSimpleName=true],
> idMapper=BinaryBaseIdMapper [isLowerCase=true], checkOnZeroId=false],
> mode=OPTIMIZED, userType=false, typeId=329149470,
> typeName=org.apache.ignite.cache.CacheAtomicityMode, affKeyFieldName=null,
> ctor=null, writeReplacer=null, readResolveMtd=null, stableSchema=null,
> schemaReg=org.apache.ignite.internal.binary.BinarySchemaRegistry@167f45f8,
> registered=true, useOptMarshaller=true, excluded=false,
> stableSchemaPublished=false]]
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:775)
> at
> org.apache.ignite.internal.binary.BinaryUtils.resolveClass(BinaryUtils.java:1669)
> at
> org.apache.ignite.internal.binary.BinaryEnumObjectImpl.deserialize(BinaryEnumObjectImpl.java:178)
> at
> org.apache.ignite.internal.binary.BinaryEnumObjectImpl.value(BinaryEnumObjectImpl.java:284)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:176)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:136)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1814)
> {noformat}
> If we perform "put" operation with value of the same type from thick client
> before "get" operation, there is no assertion anymore, but {{typeId}} is
> still duplicated. And there is another issue: different marshallers can be
> used to marshal the same class for thin and thick clients, wrong class
> descriptor is returned for class name and there is assertion again.
> Reproducer:
> {code:java}
> thickClient.cache(DEFAULT_CACHE_NAME).put(3, Collections.emptyList());
> thinClient.cache(DEFAULT_CACHE_NAME).put(2, Collections.emptyList());
> thickClient.cache(DEFAULT_CACHE_NAME).get(2);
> {code}
> Assertion:
> {noformat}
> java.lang.AssertionError: OptimizedMarshaller should not be used here:
> java.util.Collections$EmptyList
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:865)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:792)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:176)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-8414) In-memory cache should use BLAT as their Affinity Topology
[ https://issues.apache.org/jira/browse/IGNITE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-8414. Assignee: (was: Eduard Shangareev) Resolution: Duplicate Baseline topology support for in-memory caches was introduced in IGNITE-8571 > In-memory cache should use BLAT as their Affinity Topology > -- > > Key: IGNITE-8414 > URL: https://issues.apache.org/jira/browse/IGNITE-8414 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > > Now in-memory caches use all active server nodes as affinity topology and it > changes with each node join and exit. What differs from persistent caches > behavior which uses BLAT (BaseLine Affinity Topology) as their affinity > topology. > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when a non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > To handle these problems we should make in-memory and persistent cache work > similar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-8414) In-memory cache should use BLAT as their Affinity Topology
[ https://issues.apache.org/jira/browse/IGNITE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036033#comment-17036033 ] Ivan Pavlukhin edited comment on IGNITE-8414 at 2/13/20 8:42 AM: - [~ascherbakov], [~akalashnikov], [~irakov], can you confirm that features described in this ticket are already implemented? Could you please resolve this ticket as a duplicate of one where it was already implemented? was (Author: pavlukhin): [~ascherbakov], [~akalashnikov], [~irakov], can confirm that features described in this ticket are already implemented? Could you please resolve this ticket as a duplicate of one where it was already implemented? > In-memory cache should use BLAT as their Affinity Topology > -- > > Key: IGNITE-8414 > URL: https://issues.apache.org/jira/browse/IGNITE-8414 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > > Now in-memory caches use all active server nodes as affinity topology and it > changes with each node join and exit. What differs from persistent caches > behavior which uses BLAT (BaseLine Affinity Topology) as their affinity > topology. > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when a non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > To handle these problems we should make in-memory and persistent cache work > similar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8414) In-memory cache should use BLAT as their Affinity Topology
[ https://issues.apache.org/jira/browse/IGNITE-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036033#comment-17036033 ] Ivan Pavlukhin commented on IGNITE-8414: [~ascherbakov], [~akalashnikov], [~irakov], can confirm that features described in this ticket are already implemented? Could you please resolve this ticket as a duplicate of one where it was already implemented? > In-memory cache should use BLAT as their Affinity Topology > -- > > Key: IGNITE-8414 > URL: https://issues.apache.org/jira/browse/IGNITE-8414 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > > Now in-memory caches use all active server nodes as affinity topology and it > changes with each node join and exit. What differs from persistent caches > behavior which uses BLAT (BaseLine Affinity Topology) as their affinity > topology. > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when a non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > To handle these problems we should make in-memory and persistent cache work > similar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12650) Mark MVCC with @IgniteExperimental annotation
[
https://issues.apache.org/jira/browse/IGNITE-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035279#comment-17035279
]
Ivan Pavlukhin commented on IGNITE-12650:
-
Public API related to MVCC:
* {{org.apache.ignite.cache.CacheAtomicityMode#TRANSACTIONAL_SNAPSHOT}}
*
{{org.apache.ignite.configuration.IgniteConfiguration#(get|set)MvccVacuumFrequency}}
*
{{org.apache.ignite.configuration.IgniteConfiguration#(get|set)MvccVacuumThreadCount}}
*
{{org.apache.ignite.configuration.TransactionConfiguration#(get|set)DeadlockTimeout}}
> Mark MVCC with @IgniteExperimental annotation
> -
>
> Key: IGNITE-12650
> URL: https://issues.apache.org/jira/browse/IGNITE-12650
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.8
>
>
> MVCC should be marked with the @IgniteExperimental annotation.
> * Beta version of Transactional SQL and MVCC
> * In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to
> allow users to experiment and share feedback.
> * This version of Transactional SQL and MVCC should not be considered for
> production.
> [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12590) MERGE INTO query is failing on Ignite client node
[
https://issues.apache.org/jira/browse/IGNITE-12590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035240#comment-17035240
]
Ivan Pavlukhin commented on IGNITE-12590:
-
[~tledkov-gridgain], I added a couple of comments on
[GitHub|https://github.com/apache/ignite/pull/7321], everything else looks good.
> MERGE INTO query is failing on Ignite client node
> -
>
> Key: IGNITE-12590
> URL: https://issues.apache.org/jira/browse/IGNITE-12590
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Precondition: server nodes (any amount), webconsole is running.
> 1. Create the table as following:
> CREATE TABLE USERPUBSTATICDATA (BOOK VARCHAR, DESK VARCHAR, TRADERS VARCHAR,
> REGION VARCHAR, LOB VARCHAR, EXCLUDE VARCHAR, TRANSIT VARCHAR,
> MAPBOOKTOTHISBOOK VARCHAR, CONSTRAINT USERPUBSTATICDATA_PK PRIMARY KEY
> (BOOK,DESK)) WITH "template=replicated"
> 2. Execute merge into query:
> MERGE INTO USERPUBSTATICDATA(BOOK, DESK, TRADERS, REGION, LOB, EXCLUDE,
> TRANSIT, MAPBOOKTOTHISBOOK) VALUES('CADOIS', 'FRT TOR', 'Robin Das/Dave
> Carlson', 'Toronto', 'FRT', null, null, 'CADOIS');
> Step 2 is successfull on Web Console and called on IgniteCache from the
> server node, but fails when called from the Ignite client node with exception:
> {code}
> javax.cache.CacheException: Invalid column name in KEYS clause of MERGE - it
> may include only key and/or affinity columns: BOOK
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12664) Failed to dump debug information. Failed to create string representation of binary object.
[
https://issues.apache.org/jira/browse/IGNITE-12664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035208#comment-17035208
]
Ivan Pavlukhin commented on IGNITE-12664:
-
It happens because to create a string representation of a binary object having
nested field serialized with OptimizedMarshaller we need to have a real class
on a classpath to convert that nested field to string. A rough scenario is as
follows:
Prepare 2 classes, Wrapper (should be serialized to BinaryObject) and Nested
(should be serialized by OptimizedMarshaller, e.g. make it Externalizable).
Create a Wrapper object and put a Nested object inside it.
Start server node with both classes available, put the object from previous
step into a cache.
Start client node with both classes unavailable, read the object from the
cache.withKeepBinary() and call toString() on the retrieved object.
An exception with cause ClassNotFoundException will be thrown.
> Failed to dump debug information. Failed to create string representation of
> binary object.
> --
>
> Key: IGNITE-12664
> URL: https://issues.apache.org/jira/browse/IGNITE-12664
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
>
> Logging long transactions warning fails:
> {noformat}
> Dec 12, 2019 12:18:09 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to dump debug information: class o.a.i.IgniteException: Failed
> to create string representation of binary object.
> class org.apache.ignite.IgniteException: Failed to create string
> representation of binary object.
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1021)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:761)
>
> Caused by: java.lang.ClassNotFoundException:
> org.springframework.security.core.authority.SimpleGrantedAuthority
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> {noformat}
> We are using replicated cache: Cache sessionsCache
> where MapSession is:
> {code}
> public final class MapSession implements ExpiringSession, Serializable {
> public static final int DEFAULT_MAX_INACTIVE_INTERVAL_SECONDS = 1800;
> private String id;
> private Map sessionAttrs;
> private long creationTime;
> private long lastAccessedTime;
> private int maxInactiveInterval;
> private static final long serialVersionUID = 7160779239673823561L;
> {code}
> and sessionAttrs contains SimpleGrantedAuthority.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
